Posted under: Research and Analysis
As we revisited the Security Monitoring Team of Rivals, it’s obvious that the overlap between SIEM and security analytics is past the point of no return. Thus with a Civil War brewing, the 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 that problem will evolve in the future. That means getting back to the use cases. The use cases for security monitoring tend to fall into three major buckets:
- Security alerts
- Compliance reporting
Let’s go into each of these use cases and make sure you have a clear handle on success today and how that use case is going to change in the future. After we go through the use cases, we’ll then cover the pros and cons of how each combatant (SIEM and Security Analytics) addresses the use cases. As you can see, there isn’t really a clean way to categorize the players, so let’s just jump into the use cases.
Traditional SIEM was based on looking for patterns you knew to be attacks. You couldn’t detect things that you didn’t know to be attacks yet, and keeping the rules current to keep pace with dynamic attacks was a challenge. Thus many customers didn’t receive the value they needed. In turn, a new generation of security analytics products appeared to apply advanced mathematical techniques to analyze security data and identify anomalous activity, giving customers hope that they’d be able to detect attacks not covered by their existing rules.
To get a handle on success today, any security monitoring platform needs to be able 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 in an attack. Although not sexy, this kind of attack is still prevalent as adversaries won’t use advanced attacks – unless they have 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 Behavioral Analysis: Another way to pinpoint attacks is to look for strange activity on the part of users. At some point in an attack, a device will be compromised and that device will act in an anomalous way, which provides the opportunity for you to detect it.
- Insider Threat Detection: The last use case we’ll describe overlaps with UBA, since it’s about figuring out if you have a malicious insider steal data or doing damage. The insider tends to be a user (thus the overlap with UBA). Yet, this use case is less about malware (since the user is already within the perimeter) and more about profiling employee behavior and looking for signs of malicious intent, like reconnaissance and exfiltration.
Yet the telemetry used to drive the 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 required to analyze. For instance, there are SaaS applications being used in your environment and you need to factor that behavior into your security monitoring environment. There are likely IoT devices as well, whether they be work floor sensors or multi-function printers that have operating systems and can be compromised. Those also need to be watched. And finally, mobile endpoints are full participants in the technology ecosystem nowadays, and gathering telemetry from those devices is an important aspect of monitoring moving forward as well.
So aside from the main attack vectors, the reality that corporate data lies both within the perimeter and in a bunch of SaaS services and mobile devices makes it that much harder to build a comprehensive security monitoring environment. We described this need for enterprise visibility in the Security Decision Support series.
Forensics and Response
The forensics and response use case comes into play after the 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 a very scarce resource and they need to leverage technology where possible to streamline their efforts.
Yet, given the scarcity of responders, a heavy dose of enrichment (adding threat intel to the case file) and even the potential remediation of the attack must increasingly be automated. So it’s not just about equipping the responders, it’s about helping them scale their activity.
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 the reports. Every organization has to deal with different compliance and regulatory hierarchies, as well as internal controls reporting, so success involves having the tool handle the mapping between specific controls and the regulation, and generating the substantiation 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 comes from your tool. Though you could pay the assessor to go through all of your stuff and make sense of things, but that may not be the best use of your time, nor can you really ensure they’ll draw the right conclusions regarding the controls in place.
As we look to the future, compliance reporting doesn’t change that much. But the data you need to feed into the platform to generate the substantiation will does expand rather substantially. It’s all about visibility, as we described mentioned above. As your organization embraces cloud computing and mobility, you will need to make sure you have logs and the appropriate telemetry from the controls protecting those functions to ensure you can substantiate your security activity.
Assessing the Combatants
So given the backdrop of these use cases and what’s needed in the future, we need to do a general assessment of SIEM and security analytics. To be clear, this isn’t an apples to apples comparison, since there is already significant functional overlap between what is called a SIEM and what is in a security analytics product. The overlap will only accelerate until there really isn’t a functional difference between a SIEM and a security analytics tool. Basically it’ll just be security monitoring, regardless of what it’s called.
Given this overlap, we do need some way to categorize the players. It seems that the underlying means of analyzing data is a useful means of distinguishing an incumbent versus a new entrant. To drill down, a system built on a rules engine would represent SIEM, and a tool based on a (Big Data-centric) analytical platform would be a new entrant. Though this can be murky since no tool only uses rules anymore and every analytics product has the ability to use rules. Do you see what we mean when we refer to overlap?
But nomenclature aside, if we go back to the attacks described above, here is how each class of security monitor handles the attacks:
- Commodity malware: Since you know what these attacks are, traditional rules-based alerting will work well. As long as you keep the rules up to date. In what is a bit counter-intuitive, new entrants can have trouble with these attacks since they don’t always show up as anomalous behavior. To draw an analogy, this is why endpoint AV signatures are still useful since behavioral models can miss old attacks.
- Advanced attacks: The new entrants start to really shine when handling advanced attacks because they don’t need to be looking specifically for an attack like a rules-based system.The behavioral and machine learning models underlying the analytics engines do need to be updated periodically for currency, but if you are worried about an advanced adversary, a rules-based system won’t suffice.
- User Behavioral Analysis: UBA requires integration with the corporate identity store so you can associate specific devices with users, but leverages the same underlying analytics common to detect advanced attacks. This means that UBA is difficult with a traditional SIEM.
- Insider Threat Detection: The major difference between UBA and insider threat detection is the 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 the integration of some physical security systems and HR systems, since there are many triggers to determining malicious intent on the part of an employee.
To net it out, for the security alerting use case, a rules-based system will be rather limited in extending much 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 that you are considering from here on, must have the ability to do broader analytics.
If we think about forensics and response, the maturity of the incumbents tends to make these tools more adept at the response use case, since they collect a broader set of security data and have better search and drill down experiences mostly because they’ve been doing it longer. But the gap is closing rapidly as the new entrants focus their efforts on reaching feature parity with the incumbent SIEM vendors.
Finally for compliance reporting, the incumbents have been cranking out auditor reports for well over a decade and have all of those bases covered. Although this is another area where the gap between the incumbents and the new entrants is closing. First of all, because compliance reporting is pretty mechanical and once the security control to mandate mapping is integrated into the product, the reports kind of pop out. No, it’s not that simple and there is still a need for customers to customize their reports a bit, but this isn’t really rocket surgery. And yes, we intentionally mixed metaphors.
So where does this leave us as the Civil War continues to smolder? Basically right where we started. The use cases continue to evolve, but so do the tools. Clearly an organization worried about advanced attacks will favor a monitoring platform with an underlying analytics engine driving it, while those that tend to prioritize response and compliance reporting may favor the incumbent. But, of course, it’s not that simple.
Given the overlap happening between SIEM and security analytics for all of 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 platforms – regardless of whether a tool started as a SIEM or emerged as a security analytics offering. As the platforms consolidate, you need to look at a single set of capabilities moving forward. We’ll tackle that in our next post.
*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by firstname.lastname@example.org (Securosis). Read the original post at: http://securosis.com/blog/secmon-state-of-the-union-focusing-on-use-cases