This tip is part of SearchSecurity.com's Security School lesson, Using SIEM technology to improve security management...
processes. For more information, visit the lesson page; for additional learning resources, visit the Security School Course Catalog page.
Security information and event management (SIEM) has been a much-maligned technology through the years. Between complaints of complexity and an excessive requirement for professional services, many enterprises have been disappointed by their experience implementing SIEM for security monitoring.
That was then, and this is now. To be fair, technology is no longer the reason why enterprises struggle to succeed with their SIEM implementations. The leading SIEM platforms have undergone a "brain transplant," migrating to purpose-built data stores that provide adequate performance and scale. System connectors and log aggregators, once clunky and unreliable, are now more effective, making data collection relatively straightforward.
But there is still a rub with SIEM, and any technology that relies on a rules-based policy. The SIEM must know what it's looking for. The magic SIEM box won't auto-magically identify an attack that takes advantage of a new method or vulnerability few if any have ever seen before.
To be clear, SIEM still plays an important role in attack detection. But for it to succeed in detecting both known and unknown attack types, an organization must build a set of policies to look for attack conditions and indicators in its environment, and consistently monitor for those conditions.
So how do you go about building these policies? And waiting for a unicorn to deliver them to your mailroom isn't really a realistic alternative. Let's map out a fairly simple process to build effective SIEM policies.
Collect everything (within reason)
Without having sufficient data collected, there isn't much for the SIEM to analyze. So the first step is to collect the right data. What does that mean? Start with the obviously stuff, like network, security and server device logs. This data is plentiful and easy to get. Next, climb the stack and start pulling logs from the application infrastructure (databases, applications). SIEM ninjas also pull in various other data sources, including identity data, network flows, vulnerability scan results, and configuration data.
When it comes to SIEM systems, the more data, the better. Collect everything, if you can. If it's necessary to prioritize data collection, look at collecting data from the most important technology assets, namely devices in protected environments and those handling regulated data. Also pay attention to those systems that handle critical intellectual property.
Building the rules
Setting up a SIEM rule base is an iterative process. That means it happens relatively slowly and needs to be refined/tuned over a long period of time. A lot of folks get "analysis paralysis" when starting the process because there are millions of possible rules that can be set up. Thus, at Securosis, we advocate thinking about clear and present danger to determine the rules that should be defined first.
In modeling the process, start with an important asset. Put yourself in the role of the adversary, and try to monitor something you would want to steal.
- Model the threat: If you were the attacker, how would you break in and steal the data? Model the attack and then enumerate that vector within the SIEM tool. Don't forget about exfiltration because that provides another opportunity to detect the attack before the data is gone. Go into this process with realistic expectations because the threat model won't be right. It won't be complete or even comprehensive. The important thing is simply to start the threat modeling process, and this is as good a place as any.
- Refine the rules: Launch the attack against yourself. There are a ton of readily available tools to hack your environment, so use them. Then monitor what your SIEM does. Does it fire the right alert, and does it do so when it needs to? Does the alert provide sufficient information to assist a responder in figuring out what happened and triaging the situation? If not, go back to step one and refine the rules until it does.
- Optimize the thresholds: Over time, it will become increasingly clear whether the SIEM alerts occur too often, or not often enough. From there, tune the thresholds appropriately. This is always a balance; if the thresholds are too tight, noise is minimized, but it's easier to miss an attack. And vice-versa if alerts occur too often.
- Wash, rinse, repeat: Once the initial set of rules for that specific attack is implemented and optimized, move onto the next attack vector, and so forth, repeating the process when modeling each threat.
By the way, this process is never done. There are always new attacks to model and new indicators to monitor. It's always important to follow the security news to find out what kind of attacks are in vogue. Recent threat research reports like Mandiant Corp.'s APT1 report now include clear indicators that every organization can (and should) look for using its SIEM. Armed with threat intelligence and a comprehensive data collection environment, there are no more excuses: it's time to start looking for the advanced attacks that continue to emerge.
Also keep in mind that as time goes on, it will be necessary to add new data types to the SIEM, which will require revisiting all the SIEM rules. For instance, network packet traffic, if captured and sent to the SIEM, will provide a wealth of new information that can be mined. How will being able to look at the actual network traffic affect how the process of looking for a certain attack? What other rules can be added to detect the attack faster? These aren't trivial questions; looking at the SIEM rules every time a data source is added (or taken away, for that matter) can make the difference in how quickly an attack is detected, or if it's detected at all.
The most important aspect of the process is consistency. SIEM is NOT a "set it and forget it" technology. It requires significant care and feeding -- not just now, but the entirety of its operational life. If you have any illusions otherwise, you'll find yourself horribly disappointed.
About the author:
Mike Rothman is president of Securosis, an independent information security research and consulting firm. Having spent over 15 years as an end-user advocate for global enterprises and mid-sized businesses, Rothman's role is to educate and stimulate thought-provoking discussion on how information security contributes to core business imperatives. Rothman previously was the first network security analyst at META Group, held executive level positions with CipherTrust and TruSecure, and was a founder of SHYM Technology.