0

The company I work for (Manufacturing) are upgrading their Physical Access Control (PAC) System, and it will come with logging that can be fed into the our SIEM tool(LogRhythm).

Does anyone have any anecdotal evidence or Use Cases that this additional logging data has proven useful/valuable to them?

I can envisage using it to check against rules such as; if a user logs on a terminal at HO, they will have swiped in too. I'm just not convinced that this is fool proof, as people might remote onto machines.

Points to note: We're a global company collecting logs from across the world. The PAC system is only at one site. On a tight budget, and I want to make sure that I'm not wasting time.

Thanks

1
  • 1
    It isn't full proof no, nothing is. SIEM provides you with information, the more information it can provide you with the better. It may help you build a better picture. To expand on your own example,if you have someone swiping in at point A, you can tie that into a terminal logon in point be 2 minutes later. The terminal logs off 4 minutes later and then the same person swipes out at point A 2 minutes after that . Commented Jun 30, 2016 at 15:10

1 Answer 1

3

This data comes in handy when (if) you'd have to perform incident response. Consider the following scenario: "Employee John Doe has logged into a system at HO and immediately after data is erased." Your SIEM should be able to detail what occurred:

date: 06/30/16 11:45EST
username jdoe
MAC ADDR 00:00:00:00:00:0a
HOST IP 192.168.1.100
ACCESSED -> This machine, that machine

This data gets correlated and you should be able to determine the who, what, when, where and the how. This is SIEM. Now imagine the same scenario where username jdoe creates chaos, without being in the building. What happened, did someone else use his credentials, was his account compromised. With PAC being sent to SIEM, your SIEM appliance should be able to correlate all the events:

date 06/30/2016 11:45EST
Employee John Doe
Door Front Door East Wing
date: 06/30/16 11:45EST
username jdoe
MAC ADDR 00:00:00:00:00:0a
HOST IP 192.168.1.100
ACCESSED -> This machine, that machine

From an incident response/forensics (DFIR) perspective, you are guaranteed (legally in some instances), that you have the necessary information to act on the information. "John Doe should be arrested/fired/etc as we see he used his card to enter the building and erase data" (Smart data gathered quickly) Versus: "John Doe should be arrested/fired/etc since he erased data. We see this via his username logins." You could open yourself up to potential legalities. If you have it, log it.

2
  • Thanks - This is a good perspective with a use case. I can see how it would work well for building a case in forensics. Commented Jul 1, 2016 at 7:38
  • 1
    @CallumMcCormick I use QRadar heavily, one of my rule sets is to create a reference set (object) of users, say daytime. In this ruleset I have times (business hours) where I create triggered events: "If daytime (users) log in during non business hours do X Y X" This rule monitors all sorts of access to network, wireless, printers, doors, etc. As a baseline to all deployments (my company does a managed SIEM) it's one of the first rules I create. Hours, holidays, weekends.
    – munkeyoto
    Commented Jul 1, 2016 at 12:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .