Using Expiring Lists in LogRhythm 7

As a multi-billion dollar company that makes everything, Acme Labs are rightly paranoid about the threats and resulting risks that they face. Just imagine if someone got a hold of their IP and used it for nefarious purposes.

But, like most enterprises today, Acme addresses their cyber-threats in many ways—one bing internal and external compliance mandates such as Sarbanes-Oxley (specificially the use case that any privileged access is granted to a user, it is revoked within 24 hours).

Sounds simple to do—but is it? Could the LogRhythm Security Intelligence Platform meet the challenge? Well, this post would probably be up there for some Darwin-Blog-type award if the answer were no. On this occasion, I’ll hopefully avoid an unwanted nomination. And conveniently, in a surprising turn of events, the use case below utilizes functionality in the recently released LogRhythm 7 version. What are the chances!

Auto-Expiring Lists and List Administration

First up is auto-expiring lists. In this enhancement, we can now “auto-magically” expire values from a list—any list and any metadata value. Even better, we can manage and view all of this from within our WebUI.

Let’s go through our use case with an example. Suppose privileged access has been granted to a user (such as W.Coyote being added as a local Windows or Domain Admin, a SQL sysadm, root acces, etc.).

When that happened, LogRhythm ran a SmartResponse to add the user in question to a specific user list (PAG Host). So move your eyes (or head, or shuffle the laptop along—they all work) and you’ll see an expiring column set to 10 minutes. This is a new LogRhythm 7 enhancement that provides the ability to not only keep lists up to date with fresh, relevant information (great for threat lists), but in this case, we can also use it as a timed trigger.

Ten minutes after privileged access has been granted, we’ll expire the user from the list. A key thing to note here is that we generate another log when the value (i.e., the user who has been granted privileged access) has met its time to live (TTL) and should have been revoked already.



Multiple SmartResponse

Next up: The ability to run multiple SmartResponse upon an alarm being generated. In this case, I’m adding the user to one list—the host they’ve performed the activity to on another list whenever they are granted privileged access using a simple rule of Common Event = User Added to Group and a list of known privileged groups (e.g., Doman Admins, sysadm, etc.).

But the possibilities around this feature are immense—a great example being using our library of existing SmartResponse (e.g., when there’s a Security Malware alert on a host). Well, now we can use our Isolate Host plugin, our Labs Forensic dump plugin, and send the email to a user confirming their host is pwned and to start packing their things up. All that action can happen at the result of a single security operations mouse click.


Risk-Based Priority Enhancements

Our LogRhythm RBP was a powerful configuration element before, but in version 7, this has launched into orbit in terms of the power and flexibility available. Enterprises today are concerned with risk and are using LogRhythm to understand, track and visualize that risk. The enhancements to RBP make this feature even more powerful and fine-grained. We can help organizations manage their risk better than ever before.


In this example use case, we can configure our SmartResponse plugin to use a risk of 0 and then apply a filter to our dashboards to filter out low-risk events. This way, we still leverage the power of AI Engine, RBP and SmartResponse, but we use our prioritization to only show high RBP value events and alarms to our analyst for response. No one wants “death by alarms.” LogRhythm’s RBP prioritizes the alarm data that you need to act upon.


The LogRhythm AI Engine and its Magic Ability to do the Time Warp

This isn’t a new feature, as such, but it’s just really cool and it was pivotal in making this use case work. In this AI Engine correlation rule, we first look for that expiring list value (the top block)—specifically the user who was granted access.

In rule block two, we then search the previous ten minutes to see if, during that time, the access was revoked for the user who has expired from our list. If not, we generate an alarm. While that sounds simple, there’s some really clever mechanics going on to provide the powerful ability to look forward and backward in time (relativity permitting).

This functionality uses advanced features, such as our temporal chain normalizer order log data in the correct manner, even if received out of sequence. It took a couple of minutes to create using our AI Engine canvas to drag and drop the rule blocks.


And finally, in case you missed it, here it is—the alert if we fail to revoke privileged access within the appropriate timeframe.


This use case shows the power of the LogRhythm 7 platform. The concept can be adapted for a multitude of scenarios (e.g., third-party temporary account access, scheduled maintenance windows, someone being away on lunch too long, etc.).