By Tom Chmielarski, RSA Practice Lead, Advanced Cyber Defense Services (Americas)
A great way to get value out of a SIEM, a log management platform, or even a syslog server you can query is to spend the time to document use cases for monitoring. For simplicity I’m going to say SIEM here but I do mean all of those other options too. Monitoring use cases should not be specific to your SIEM but should be specific to the data you have (and, to a lesser extent, data you want to have) and the types of events your organization wants to detect. It’s never too late to define and implement good use cases but it is simpler to do when you’re first setting up a SIEM.
Before I talk more about use cases I’d like to contrast the use case approach with the more common “install it and go” approach to implementing a SIEM. Often an organization will buy a SIEM, sometimes with a high-level objective of monitoring security data or to address an audit finding, without a clear understanding of how they will use it. The SIEM will often be bought, installed by the vendor, and the security team expects to have security monitoring “solved.” That often doesn’t work out very well, and the security team realizes that to get value out of the SIEM it requires time and effort: learning the SIEM and knowing what to do with it.
A SIEM is a tool: to be useful to your organization you need to know how to use the tool and the vendor’s installation of it for you is not a substitute. I call this problem, which is not unique to SIEMs, as the “Puppy Problem.” A puppy in the store looks cute and everyone wants it. When you get the puppy home you realize that you must feed it, walk it, get it toys, and pay attention to it: caring for a puppy is a lot of work and someone looking at the puppy in the store may not consider all of the work. So too, someone about to purchase an expensive SIEM product may not consider all of the effort needed to make a SIEM work, including that you still need to know what you want your SIEM to find.
This brings us, in a rather round-about fashion, to detection use cases. A list of use cases should be created to describe all of the “things” you want to find, and the SIEM is the tool you are (mostly) using to do detection. These use cases can be organized by threat types or technology areas, such as “Authentication” and “Firewall.” An example of an authentication use case may be:
“Identify any account authenticating (success or failure) to more than 5 computers within a 5 minute period.”
This is a fairly simple use case, requiring only basic aggregation and count functionality of authentication data.
Developing use cases should be a repeating exercise and should certainly be a byproduct of incident response efforts. When an incident is discovered, and the cause identified, part of the analysis is to ask “how could we have found this sooner?” The answer may become a use case. Brain storming sessions, in which people discuss any idea, even if impractical, can find great new use cases.
Finding use cases for a given type of data requires an understanding of that data. If we use VPN data as an example we can easily identify the use case of:
“An account fails VPN authentication more than 3 times in a 10 minute period”
We can get this based on basic assumptions of what is in the VPN data. If we do not know our data well we may not realize that the VPN client is also logging the computer name of each client. That fact opens up new possibilities such as:
“A user authenticates via VPN with two different computers in a 12 hour period”
…as well as:
“A VPN connection is established with a computer not in the asset management system and not known to the Antivirus server, meaning it’s non-standard or non-company.”
For every type of data to have in your SIEM you should spend some time learning what is in that data and document a few use cases to identify intrusion, misuse, or anything else you are concerned about detecting.
Another use case, more complex, would be:
“Identify any account belonging to a user in one business unit authenticating to a workstation or laptop in a different business unit.”
This use case requires the contextual awareness between account and business unit which can probably be found within LDAP or Active Directory. It also requires an association of a computer to a business unit, which requires an asset management database or a record of which user (and associated business) typically uses that computer. As part of documenting use cases you can also identify the contextual and correlating data required to make it work so you can address any gaps as part of your security strategy.
It is important – a lesson I’ve learned the hard way – to rank the use cases by importance and difficulty. It is quite possible that you have a very important use case which is also very hard to implement and several important use cases that are easy to implement. Implementing the easier ones first will give some quick-wins and show value right away rather than struggling over the most important, but heinously difficult one for weeks.
Lastly, developing use cases depends on knowing what you want to find and, of equal importance, what has business value to be found. A brainstorming session can easily come up with many interesting things (such as “Lets find all devices that are webcams based on vendor MAC address using DHCP logs!”) but if finding these things are not actionable or offer no business value then you’re ultimately wasting time. (If you’re developing analysis skills are you truly wasting time though?)
There are, of course many ways to construct and organize a list of use cases but hopefully this has given you some inspiration to do use the approach, or the motivation to go-back and review the use cases you’ve already documented to look for improvements.
Tom Chmielarski is Practice Lead within the RSA Advanced Cyber Defense Practice serving the Americas. Tom has over 15 years of IT experience, primarily in security, spanning operations, incident response, malware, forensics, data analysis, and strategy. He has experience in the Defense, Industrial Controls, Electronics manufacturing sectors. He is a subject matter expert in incident response, security monitoring, forensics, malware, and data analysis.