Daniel Dallmann, Senior Information Security Engineer, is a guest blogger from Payworks and a valued LogRhythm contributor. Dan was on the SOAR Customer Panel at LogRhythm’s third annual user conference, RhythmWorld, and was generous enough to share some of the tagging schema he presented at the conference with our blog readers.
If you’re a LogRhythm user, you’ve probably dabbled quite a bit in Case Management on a day-to-day basis. Whether you’re grinding through alarms or working on reported issues and incidents, Case Management provides the tools you need to collaborate, store evidence, initiate playbooks, and work through the incident management process.
But what about the tagging section in the Case Management editor?
If you haven’t explored Case Tags in some way or another, you’re not alone. A quick poll of the RhythmWorld 2019 SOAR User Panel audience demonstrated that many LogRhythm users aren’t using the feature even though they would like to. They just don’t know where to start.
Introduction to LogRhythm Case Tags
LogRhythm’s Case Tags feature is extremely flexible and dynamic. With the feature, you can tag anything you want, how you want it. My team was first introduced to the Case Management Tags in this blog post on the topic. We saw the level of detail we could add to our cases and incidents using tags and were inspired to use a tagging schema.
Being a small- to mid-size enterprise (SME), we found the taxonomy described in LogRhythm’s blog post to be quite advanced for the departmental reporting we needed at the time. So, we brainstormed about what type of information we found most valuable at a high level, not only to improve the analysis process, but to also provide insights into the types of cases the security operations center (SOC) worked on.
How We Built a Tagging Taxonomy
Using Case Tags can be extremely powerful, but without a properly defined schema and guidelines for tagging, it can quickly turn to chaos. Tags are only as effective if they are consistent.
Our team worked together to create a taxonomy like the diagram below. At a high level, we came up with a set of primary attributes that were assigned a prefix, such as 1_, to make them easy to identify.
Every case we create follows a step-by-step Case Tagging playbook, which states that each case should have one or more of the primary case classifications, and one of the sub-classifications when applicable.
As a case progresses, you can include one or more of the related sub-classifications that will also have a prefix to indicate what primary classification it derived from. If a sub-classification doesn’t exist, then you might consider making one for tracking and reporting purposes.
How I Use “Dynamic Tags” to Improve Filtering
Along with a primary taxonomy, you can also use what I refer to as dynamic tags. Dynamic tags relate to a person, asset, entity, or environment and are created by simply tagging a username, email address, identity, computer, or asset name.
Dynamic tags offers many benefits. They help your team dig deeper into cases that are related to a specific user or asset, and build a great foundation for contextual case search and reporting.
Workflow and Use Case
Let’s walk through a real-world scenario of how an analyst would use tagging on a day-to-day basis.
You receive an alarm for suspicious web browsing activity on one of your users’ endpoints. You haven’t received any other corroborating alarms, but this isn’t the first alarm you’ve received like this today.
After an initial drill-down and review of the alarm’s logs, you determine that this activity needs additional analysis. Because this isn’t the first occurrence in the environment today, you create a case to track your work and the activity.
Since the case is primarily technical in nature, you add the [1_TECHNICAL] threat tag. Using the information you’ve gathered, you also believe it could be related to malware, so you add the [T_MALWARE] tag.
- You assign the asset and individuals involved with dynamic tags so you can assign each of those attributes with the case. Your dynamic tags are: [janedoe], [email@example.com], [desktop-a135v].
Next, you run a search for the events and logs associated with the attributes and the dynamic tags. After more thorough investigation, you note that there’s no other corroborating evidence to suggest user or computer compromise. You continue to research and eventually identify that it was a false positive and add the [1_FALSEPOS] tag.
You’ve already seen this alarm for twice for two different assets today, so you determine that a configuration change to the AI Engine™ rule should be made to help reduce false positive alarms. You add an Exclude filter to the AI Engine rule and attach the [1_EXCEPTION] tag to the case.
- You add the related notes and evidence to the case and close it!
After you’ve had the chance to go through this process a few times, you will be able to reference the tags you’ve added to previous cases that will help your team:
- Quickly find related occurrence during investigation.
- Create department-level reporting to summarize the behaviors of different users, computers, and environments.
- Have more visibility to events that can drive operation costs. For example, tagging can help you filter how many malware cases resulted in a computer being rebuilt after it was scanned.
Tips for Building Your own Taxonomy
Here are a few tips that can help you build your own taxonomy. You can even use these tips to build on the above example.
Check out LogRhythm’s blog. The post about optimizing performance with Case Management can provide additional ideas and concepts.
Simplicity reigns supreme. Keep the number of tags to a minimum to start, especially if your tagging system is going to be manual.
However, there’s always room for automation using LogRhythm APIs and SmartResponse™ automations. LogRhythm has several resources like the SmartResponse™ Automation Plugin Library to familiarize you with the plugins they support.
Team collaboration is key. Work with your team of analysts to develop an effective tagging system. See tip 1 to help get your team started.
Attach a prefix to your static tags. This will make them easily identifiable.
Identify what criteria you will use consistently as a dynamic tag. Consider people, usernames, computer, or asset names. To start, I recommend you avoid storing file integrity checksums (md5, sha1, sha256) as tags. This method can quickly get messy and may not provide immediate value.
Take advantage of Case Management dashboards and widgets that allow you to mix and match tags. For example, how many malware-related cases resulted in a computer rebuild, or how many cases have a false positive alarm that also resulted in a configuration change to reduce future false positive notifications.
Create a Case Playbook **that outlines how and when to use the tagging system. Playbooks provide an easy-to-use reference guide within the platform. Have analysts use the playbook a few times so they can quickly grasp the concept and consider making a diagram like the I shared above to make things easier and quicker.
What taxonomy are you using in your organization? Please let us know in the comments below and provide feedback. We also encourage you to share your own tagging schema or questions with other LogRhythm users in Community.
Dan is a valued LogRhythm contributor and has earned 40 Community badges.