For this example, consider a scenario where server machines with critical data reside in a secure area. Only users in a specialized group are allowed physical access to the server room by swiping a badge on a card reader and user login permissions to the servers.
Assumption: This example assumes a policy against remote logins to the server room machines.
We want to monitor and correlate user access to the server room (badge swipes) and user logins on the server machines, and take action (e-mail notification) if our access policies are violated. Some examples of policy violations that we want to catch are:
Cases where someone logged into a server but no badge swipe is registered. This could indicate policy violations such as remote logins or unauthorized server room entry.
There is no matching badge swipe ID for a server console login (someone stole a user’s badge to enter the server room, then logged in to the server with a different user ID).
This example assumes a pre-populated active list with values with a schema appropriate for storing information about user IDs. The active list keys off of user identifiers from various sources (such as user login, e-mail address, phone number) and map these variants to the same unique user ID (UUID).
The UUID can then be used as a variable in a rule for correlating user login IDs with badge IDs. The example shows how to create this rule, which leverages the user information collected in the active list.