Understanding the true identity of your users is crucial to securing your organization. Often times, you might be left struggling with this task, especially when users have multiple identifiers.
To address this challenge, you need a solution that helps you manage all of your identifiers and can attach these identifiers to the appropriate user. LogRhythm simplifies the identity challenge with identifiers using application programming interfaces (APIs).
Tracking Identities and Access
Let’s explore a real-life scenario: I was onsite to test a proof of concept (PoC) in an organization that wanted to know who was coming in and out of its building, as well as who was attempting to access areas or doors that they shouldn’t. The challenge I had was that the door access system was (as many are) a non-domain linked application — essentially a standalone application that creates random IDs and assigns these IDs to a name you enter.
For example, let’s say you log into the application, create a new user, assign a name (e.g., John Doe), and assign which doors users can access. The system then creates an Access Card ID. This information is stored in a SQL database. Each time a user accesses a door, this access (whether successful or not) would be logged in the system. The SQL table looked a little like this:
So, what’s the challenge? All I had to do was bring in the logs of that SQL database and I could easily determine which doors the user accesses, as well as the user who made the attempt. This is all documented in the logs, right? Well, yes and no. There’s more to this than meets the eye.
Understanding TrueIdentity
LogRhythm can synchronize with an organization’s domain to tie a user’s domain login (e.g., “logrhythm\J.Doe”) to his or her actual identity (i.e., John Doe). This is called TrueIdentity™. TrueIdentity is useful because the solution lets you add multiple identifiers to a user’s identity.
Figure 1: LogRhythm TrueIdentity Allows You to Add Multiple Identifiers to a User’s Identity
In Figure 1, my identity is Jonathan Zulberg. Under my identity, I have multiple identifiers (e.g., jz, jz_github, jz_pastebin, etc.)
Why do we do this? Let’s say I decide to go rogue at LogRhythm and I want to hit the company where it hurts — the coffee! I not only empty the coffee in the canteen, but also in the kitchen storage room. I then hold the coffee ransom by posting on Twitter that if the company ever wants to see the coffee again, it needs to pay 1 bitcoin.
So, how would TrueIdentity help in this instance? To gain access to the kitchen store room, I would use my access card, which would be logged in the system as 11111111, and the Twitter account would be logged as coming from jz_twitter. Assume for a moment my access card ID and my Twitter nickname were added as identifiers to my name. TrueIdentity would log both events as originating from Jonathan Zulberg, even though my name isn’t mentioned in either logs. I’m busted!
TrueIdentity is also useful for searching. Now that I am considered suspicious, a LogRhythm analyst could conduct a search against all activity by Jonathan Zulberg (my identity). All the activity I performed would display, such as the doors I swiped, emails I sent, and computers I logged into. While each log would contain a different identifier, each would be part of my identity. Think of the possibilities! You could add a whole identity to a list, a correlation rule, a report, and more.
Adding Identifiers with TrueIdentity
Keeping the above information in mind, I thought about how I could apply TrueIdentity to my real-life scenario and had a bright idea. My plan was to add the access IDs in the database as identifiers under all the users in TrueIdentity. The door access system, which I mentioned above, was standalone. This means it has no link to a user’s identity in the domain, even though in the logs it contained:
I needed a way to tie the access ID 111111111 to John Doe’s user identity in the domain (logrhythm\J.Doe). This way, each time I saw Access Card 111111111 swipe on a door, I could verify that it was John Doe swiping. And if I wanted to search against all activity John Doe performed, his door access would come back, too.
LogRhythm makes this easy to do for a single user. Just go to the user’s name in TrueIdentity, click Add Identifier, and then add the identifier you want. However, when you have 16,000 users and some have multiple cards with access to different geographic locations, doing this one by one isn’t possible.
Developing a Script
I’m no stranger to asking for help when I need it. Bruce Deakyne, one of LogRhythm’s technical product managers, has a penchant for all things API and PowerShell. To his credit, Bruce understood the challenge quickly and got to work whipping up a PowerShell script.
The script that Bruce wrote (copied below) does a simple yet amazing thing — it scans a CSV (which would come from an export from the database) and tries to identify the name within the CSV to a name added to TrueIdentity. If I detected the same name in TrueIdentity as I do in the CSV export, the access ID (identifier) is added to the user’s identity.
However, there are some caveats:
1. I can get an export from the database that contains the name and the associated card ID.
2. The name in the database corresponds to something unique that I can identify the user in TrueIdentity.
Caveat No. 2 is critical. In my example table below, I have two users: Jane Doe and John Doe.
If the table looked like this instead:
How should I know to assign access ID 111111111 to John Doe and not Jane Doe? In this case, I would need something like a middle name or a middle initial to keep the two identities distinct, so I can add the right card to the right user.
Assuming both caveats above are met, it’s really as simple as populating and running the script. In fact, Bruce added a little variable that allows you to run the script without making any changes. This enables you to review the log for errors before committing to changes.
LogRhythm users only need to populate the following areas in the script below and ensure the exported CSV resides in the same location as the script itself:
$IdentityApiUrl = “http://localhost:8505/lr-admin-api/identities”
$ApiKey = “insert API key here” —If you don’t know where to get this or how to create this, read my post here on the LogRhythm Community
$CsvPath = “insert CSV filename here (e.g., BadgeID.CSV)” — Put the CSV in the same location as this script
$LogFile = “name of log file (e.g., LR_Identity_Badge.log)” — This is the name of the log file which allows you to review the progress or errors
# We’ll use these to form the “unique Id” for each record
$IdentityProperties = $(“nameFirst”, “nameLast”)
$CsvProperties = $(“FirstName”, “LastName”) — This is the columns in the CSV, which the script will scan to try and identify matching users within True Identity
# The CSV column name(s) of the Identifier to add
$CsvIdentifiers = $(“e.g., BadgeID”) — This is the identifier in the CSV to add when we find a match
# List of Entity Names
# If empty, will find Identities in all Entities
# Entity Names can be found in Deployment Manager –> Entities –> Select & Right Click Entity –> Properties (be sure the correct Entity Name shows up…client console does strange selection sometimes).
# Example: $Entities = $(“Primary Site”, “Americas”)
$Entities = $(“Enter Entity Here”) — If you have multiple entities configured in LogRhythm which synch to different domains, choose the Entity to scan; if not. scan them all by entering them here
# Preview Mode — If set to True, does not add the Identifier
# Logs what the result would be
$Preview = $True — True = don’t make changes // False = make changes
It sounds simple, but the script is complex and does a lot of clever things. First, it uses the LogRhythm API to gather a list of all users added to TrueIdentity. Then it scans the CSV looking for a name match using regex comparing the name in the CSV to the list of users pulled via the API. Once the scan is complete, the script then begins to meticulously add the identifiers to each detected identity. If it cannot find a match for a user, then that user is skipped, the error is logged, and the script continues.
If there are multiple card IDs for a given user, then each card is added to that user. The script can run multiple times and won’t add the same identifier to the same user to avoid duplicates. Therefore, you can set up a periodic export of the CSV to a location and schedule a task to run the script that looks for and adds the changes.
The Results: Immediate Visibility of Door Access
Once I executed the script and it scanned all 16,000 users, of which 15,800+ users had their card ID added to their identity, I immediately saw the logs of every door being accessed by every user. I then created two alarms. The first triggered if I saw any user accessing specific doors after hours, and the second only triggered after a previous AI Engine Compromise/Suspicious Event occurred. For example, this second alarm could trigger if first an identity accessed a server that it shouldn’t and then that same identity accessed a door he or she shouldn’t.
The next step is to develop a SmartResponse™ automation rule to disable the card upon attempted access to a sensitive zone. With a few simple tweaks, this script can be used to add a host of identifiers to large volumes of users quickly and safely.
Using APIs isn’t the only way to solve this issue. The LogRhythm Labs team developed a SmartResponse plug-in called “Extra Context” that is available in the LogRhythm Community and allows you to automate the same alarm, but as a contextual SmartResponse plug-in in the web user interface portion of the product.