When we revisited the Security Monitoring Team of Rivals it became obvious that the overlap between SIEM and security analytics has passed a point of no return. So with a Civil War brewing our key goal is to determine what will be your strategic platform for security monitoring. This requires you to shut out the noise of fancy analytics and colorful visualizations, and focus on the problem you are trying to solve now, with an eye to how it will evolve in the future. That means getting back to use cases. The cases for security monitoring tend to fall into three major buckets:

1. Security alerts
2. Forensics and Response
3. Compliance reporting

Let’s go into each of these to make sure you have a clear handle on success today, and how each will change in the future. After we work through the use cases, we’ll cover pros and cons of how each combatant (SIEM vs. Security Analytics) addresses them. As you can see, there isn’t really any clean way to categorize the players, so let’s just jump into cases.

Security Alerts

Traditional SIEM was based on looking for patterns you knew to be attacks. You couldn’t detect things that you didn’t yet recognize as attacks yet, and keeping the rules current to keep pace with dynamic attacks was a challenge. So many customers didn’t receive the value they needed. In response a new generation of security analytics products appeared to apply advanced mathematical techniques to security data, identifying and analyzing anomalous activity, giving customers hope that they would be able to detect attacks not covered by their existing rules.

Today to have a handle on success any security monitoring platform needs the ability to detect and alert on the following attack vectors:

• Commodity Malware: Basically these are known attacks, likely with a Metasploit module available to allow even the least sophisticated attackers to use them. Although not sexy, this kind of attack is still prevalent because adversaries don’t use advanced attacks unless they need to.
• Advanced Attacks: You make the assumption that you haven’t seen an advanced attack before, thus you are very unlikely to have a rule in your security monitoring platform to find it.
• User Behavior Analysis: Another way to pinpoint attacks is to look for strange user activity. At some point in an attack, a device will be compromised and that device will act in an anomalous way, which provides an opportunity to detect it.
• Insider Threat Detection: The last use case we’ll describe overlaps with UBA because it’s about figuring out if you have a malicious insider stealing data or causing damage. The insider tends to be a user (thus the overlap with UBA). Yet this use case is less about malware (because the user is already within the perimeter) and more about profiling employee behavior and looking for signs of malicious intent, such as reconnaissance and exfiltration.

But the telemetry used to drive security monitoring tools today is much broader than in the past. The first generation of the technology – SIEM – was largely driven by log data and possibly some network flows and vulnerability information. Now, given the disruption of cloud and mobility, a much broader set of data is needed. For instance there are SaaS applications in your environment, which you need to factor into your security monitoring. There are likely IoT devices as well, whether they be work floor sensors or multi-function printers with operating systems which can be compromised. Those also need to be watched. And finally, mobile endpoints are full participants in the technology ecosystem nowadays, so gathering telemetry from those devices is an important aspect of monitoring as well.

So aside from the main attack vectors, the fact that corporate data lies both inside the perimeter and across a bunch of SaaS services and mobile devices, makes it much harder to build a comprehensive security monitoring environment. We described this need for enterprise visibility in our Security Decision Support series.

Forensics and Response

The forensics and response use case comes into play after an attack, when the organization is trying to figure out what happened and assess damage. The key functions required for response tend to be sophisticated search and the ability to drill down into an attack quickly and efficiently. Skilled responders are very scarce, so they need to leverage technology where possible to streamline their efforts.

But given the scarcity of responders, a heavy dose of enrichment (adding threat intel to case files) and even potential attack remediation must be increasingly automated. So it’s not just about equipping the responders – it’s about helping scale their activity.

Compliance Reporting

This use case is primarily focused on providing the information needed to make the auditor go away as quickly as possible, with minimal customization and tuning of reports. Every organization has to deal with different compliance and regulatory hierarchies, as well as internal controls reporting, so success entails having the tool handle mapping specific controls to regulations, and substantiating that the controls are actually in place and operational.

Seems pretty simple, right? It is until you have to spend two days in Excel cleaning up the stuff that came from your tool. You could pay an assessor to go through all your stuff and make sense of things, but that may not be the best use of your or their time – nor can you ensure they’ll reach the right conclusions regarding your controls.

As we look to the future, compliance reporting won’t change that much. But the data you need to feed into a platform to generate your substantiation will expand substantially. It’s all about visibility as mentioned above. As your organization embraces cloud computing and mobility, you will need to make sure you have logs and appropriate telemetry from the controls protecting functions to ensure you can substantiate your security activity.

Assessing the Combatants

Given the backdrop of these use cases and what’s needed for the future, we need to perform a general assessment of SIEM and security analytics. To be clear this isn’t an apples to apples comparison – there is already significant functional overlap between a SIEM and what is in a security analytics product. The overlap will only accelerate until there really is no functional difference between a SIEM and a security analytics tool. Basically it will just be security monitoring, regardless of what it’s called.

Given this overlap, we still need some way to categorize the players. The underlying means of analyzing data makes a useful way to distinguish an incumbent from a new entrant. To drill down, a system built on a rules engine is SIEM, while a tool based on a (Big Data-centric) analytical platform would be a new entrant. But this gets a bit murky, because no current tool really only uses rules, and every analytics product has the option to use rules.

But nomenclature aside, if we go back to the attacks described above, here is how each class of security monitor handles attacks:

• Commodity Malware: You know what these attacks are so traditional rules-based alerting works well. As long as you keep them up to date. A bit counter-intuitively, new entrants can have trouble with these attacks because they don’t always show up as anomalous behavior. To draw an analogy, this is why endpoint AV signatures are still useful: behavioral models can miss old attacks.
• Advanced Attacks: The new entrants begin to shine for handling advanced attacks because they don’t need to look specifically for individual attacks like rules-based systems do. The behavioral and machine learning models underlying analytics engines do need to be updated periodically, but if you are worried about an advanced adversary a rules-based system definitely won’t suffice.
• User Behavioral Analysis: UBA requires integration with the corporate identity store so you can associate specific devices with users, but leverages modern analytics to detect advanced attacks. This makes UBA difficult with a traditional SIEM.
• Insider Threat Detection: The major difference between UBA and insider threat detection is its specificity to an organization. UBA tends to look for generically anomalous behavior, while insider threat tools are more tuned towards the inner workings of a specific organization. This tends to involve integration of physical security and HR systems because there are many triggers for recognizing malicious employee intent.

To net it out, for the security alerting use case, a rules-based system will be limited beyond commodity malware. Detecting advanced attacks and profiling users (either for a UBA or insider threat use case) requires higher-level analytics. So any tool you are considering from here on needs the ability to handle broader analytics.

Thinking about forensics and response, the maturity of incumbents tends to make their tools more adept at the response use case because they collect broader security data and have better search and drill-down experiences – they’ve been doing it longer. But the gap is closing rapidly as new entrants focus on reaching feature parity with incumbent SIEM vendors.

Finally, for compliance reporting, incumbents have been cranking out auditor reports for well over a decade and have all those bases covered. Although this is another area where the gap between incumbents and new entrants is closing. First because compliance reporting is fairly mechanical, and once the security control to mandate mapping is integrated into the product, the reports more or less pop out. No, it’s not that simple, and there is still need for customers to customize reports, but it isn’t rocket surgery.

So where does this leave us as the Civil War continues to smolder? Right back where we started. The use cases continue to evolve, as do the tools. Clearly an organization worried about advanced attacks will favor a monitoring platform with an underlying analytics engine, while those who tend to prioritize response and compliance reporting may favor incumbents. But of course it’s not quite that simple.

Given the overlap between SIEM and security analytics for all the applicable use cases, a cursory look at use cases is insufficient to even narrow down your short list. We need to dig into the requirements of the various platforms – regardless of whether a tool started as SIEM or emerged as a security analytics offering. As platforms consolidate you need to look at a single set of capabilities moving forward. We’ll tackle that in our next post.