As we described in the introduction to the series, security monitoring has been around for a long time, and it’s evolving quickly. But one size doesn’t fit all, and if you are deploying a Team of Rivals, they will need to coexist for a while. And either the old guard evolves to meet the needs, or the new guard will supplant them. But in the meantime, you have to figure out how to solve the problem: Detecting advance attackers in your environment.
We can’t claim to be historians, but the concept behind Lincoln’s Team of Rivals(Hat tip to Doris Kearns Goodwin) seems applicable to this situation. To briefly describe the concept, President Lincoln needed to make a divisive political environment work. So he named rivals to his Cabinet to make sure everyone has accountability for the success of his administration. There are parallels to security, in that the security program first and foremost must protect critical data. That means the primary focus must be on prevention/detection the attacks, while always ensuring the ability to respond and generate compliance reporting. It seems that different tools (right now anyway) specialize at different aspects of the security program, but ultimately they must work together. Thus, the need for a Team of Rivals.
So how do you get these tools to work together? Especially since it’s not in their best interests really. Most SIEM vendors are working on a security analytics strategy, so they aren’t going to be enthused to work with a third party analytics offering that may replace them. Likewise the security analytics vendors want to marginalize the old guard as quickly as possible, leveraging the SIEMs capabilities in data collection/aggregation efforts and then doing the heavy lifting from a analytics standpoint and delivering the value themselves.
As always, trying to outsmart vendors is a waste of time. By focusing on solving the organization’s problems and then picking technologies, the path forward appears. That means starting with the use cases and letting that drive what data needs to be collected and how it should be analyzed.
Revisiting Adversaries
Whenever evaluating security use cases, we always recommend starting with adversaries. Your security architecture, controls and monitors need to factor in the tactics of the attacker since you have neither the time nor the resources to address every possible attack vector. We’ve done a lot of research on this (presented in the CISO Guide to Advanced Attackers), but in a nutshell the adversaries can be broken up into a few different groupings:
- External actors
- Insider threats
- Auditors
You can break external actors into a bunch of different categories, but for the purposes of this research that would be overkill. We just know the external actor needs to gain a foothold in the environment by compromising a device, moving laterally to achieve their mission, and then connecting to a command and control network for further instructions and ultimately exfiltration. This is your typical adversary in the hoodie wearing a mask that you see in every vendor presentation. And yes, that was sarcasm.
Insiders are a bit harder to isolate because in many cases they are authorized to access the data, so detecting misuse requires more nuance and likely some human intervention to validate the attack. In this case, you’ll need to look for signs of unauthorized access, privilege escalation, and ultimately exfiltration.
The third major category is auditors. OK, don’t laugh too hard. Clearly auditors are not a traditional adversary, but rather a constituency that you need to factor into your data aggregation and reporting efforts. These folks are predominately concerned with their check lists. So you’ll need to make sure to substantiate the work as opposed to just focusing on the results.
Using the right tool for the job
You already have a SIEM, so you may as well use it. Clearly the strength of the SIEM is going to be in data aggregation, simple correlation, forensics/response and reporting. So what kinds of data do you need? A lot of the stuff we’ve talked about for years.
- Network telemetry, with metadata from the network packet streams at a minimum;
- Endpoint activity, including processes and data that flows through the device’s network stack;
- Server/Data Center logs and change control data;
- Identity Data, especially information regarding privilege escalation and account creation;
- Application logs, most particularly useful are access logs and bulk data transfers;
- Threat Intelligence to identify attacks seen in the wild, but not necessarily by your organization quite yet.
This is not brain surgery and for the most part, you are already doing this. The use cases to find simple attacks have been deployed and still require tuning, but should work adequately. The key in leveraging the SIEM is to use it for what it’s good at, which is aggregation, simple correlation (of indicators you know to look for), searching and reporting. SIEM’s strength is not going to looking for patterns within massive data volumes, so you need a Rival to provide those capabilities.
Let’s consider adding security analytics to the mix, but the term is pretty horribly defined by the industry. Any product that does computation on security data now seems to be positioned as a security analytics product. So what do we believe sets security analytics apart? Basically, security analytics involves using a set of purpose-built algorithms to analyze massive amounts of data to look for specific patterns of misuse/activity.
There are a variety of approaches and even more algorithms that can look for these patterns. So we believe the best approach to categorize analytics approaches is based on the use cases, not the underlying math. We explain why below. We’ll make the assumption that the vendor chooses the right algorithms and compute models to address the use case, otherwise their tech won’t work and Mr. Market will grind them to dust.
Security Analytics Use Cases
If we think about security analytics from the standpoint of use cases, we have a few that bubble to the top. Just to be clear, there are a lot of ways to think about applying math to a security problem, so you can certainly quibble with our somewhat simplistic categorization. But these are the use cases that we hear about most frequently, so we’ll start with these three.
Advanced attack detection
The need for advanced analytics to detect advanced attacks is really driven by the fact that existing monitoring platforms are driven by rules, meaning that you need to know what you are looking for. As we all know nowadays, the attackers don’t follow a specific playbook so looking for yesterday’s attacks in your security data doesn’t work very well. The data to drive advanced attack detection comes from traditional logs, endpoint and network telemetry. There is a lot of religion about which data source is most reliable, but per usual we don’t/won’t play favorites. We think all of the data sources are important and over time, we expect any vendor in the advanced detection business is going to broaden their analysis beyond their initial area of focus.
User Behavior Analysis
UBA has a lot in common with advanced attack detection, but focuses specifically on the behavior of the users. The idea is that at some point, every attack involves compromising a user and as such the user is the best place to detect attacks. This type of analysis is complicated by the reality that users interact with systems both internal and external to your organization. Yes, those pesky users continue to use SaaS service which may not provide adequate visibility for you. Additionally the same users may connect using multiple devices. So you’ve got to go beyond a device-centric perspective, rather evaluate behavior across many devices to understand a user’s typical behavior and then look for abnormal activity. Compound this with the fact that users also access systems in many different locations, so that further complicates the analysis. UBA is driven by a number of different collection techniques, including but not limited to log analysis, endpoint telemetry, mobile device analysis, and geolocation. Network data can also be factored into the analysis if the users run through a proxy (either on prem or within the cloud) to ensure inspection of their activity.
Insider Threat
The final use case we’ll highlight involves looking specifically for malicious insiders, who are authorized to access data sources. As with the first two, the analysis involves user behavior and also network telemetry, but can also involve internal system access (especially Finance and HR systems) as well as physical access. The analytics need to be customized specifically for the organization due to the access variances between organizations. Additionally legitimate use can have a lot of different meanings, so the data inputs are not necessarily consistent and the signs of misuse must be tuned and optimized to a much greater degree, increasing the deployment time and customization required.
Yet, there is value in this use case. It turns out that every attack involves not just a compromised device (a point made above), but also an insider using that device. So the insider threat folks tend to claim their solutions can find attackers whether they are internal or external. Though obviously the point of detection would be later in the attack cycle given that the insider needs to start acting maliciously for these tools to detect the attack.
The Reality of SA Use Cases
If we are being a little more creative, we could add cognitive analysis, web behavior, identity analytics, application usage, cloud security analytics and a variety of others to the list of use cases. But that starts to become overkill because all of these use cases leverage advanced mathematical analysis on aggregated data to answer security questions. The use cases only seem to differ relative to the data you feed into the analytics machine. So basically you can paint the use cases in a variety of different ways, but at the end of the day all of these use cases overlap and we expect all of the vendors will roll out solutions to all of the user cases in the near term.
In the heat of a buying cycle, you will hear a lot about this mathematical technique or that one. Unless you are a PhD in math, it’s not clear to us that the nuances of the different approaches will help you decide which product to choose, if any. None of us at Securosis are PhD’s in Math, so we get back to what we can understand and that’s the general concepts driving detection via security analytics.
In this morass of advanced math and technical mumbo jumbo, we tend to forget that detecting attacks is pretty straight forward. It’s about looking for patterns that reflect an active threat actor in your environment. You roughly follow the kill chain, looking for things like recon, privilege escalation, command and control traffic, and exfiltration. Obviously the sooner you detect an attack, the more likely you can intervene before a data breach. Clearly it’s easier said than done, but let’s not unnecessarily overcomplicate the decision.
Coexistence
If we return to the need to use the right tool for the job, security analytics offerings aren’t really built to provide a clear means to search and pivot on an alert from a forensics and incident response standpoint. It also doesn’t easily lend itself to compliance reporting. That’s not saying that the tools can’t extend their functionality and grow into those requirements.
But at this point in time (early 2017), these tools aren’t built to address all of the use cases required of security monitoring. So from a pragmatic standpoint, it’s not either/or right now. It’s both. So you are going to need these disparate security tools to work together for the foreseeable future. That means looking for the logical integration points, including:
- Data: The SIEM has been collecting and aggregating security data for a long time. So messing with that doesn’t make a lot of sense. The model for extraction into a security analytics tool can be taken from the business intelligence world. Data to feed the more advanced analysis was taken from existing corporate data stores and moved into a data model that was built to facilitate the analytics. Yet this extraction process can be resource intensive, so ensure there is sufficient automation of data movement.
- Alerts: You’ll be getting alerts from both systems. Once an alert fires, what then? You need to determine which system is going to be the system of record and where your operations folks and responders will spend their time. In a lot of cases, organizations choose to centralize their alerts in the SIEM and rely on the ability to jump into the analytics platform as needed when drilling down into a relevant alert.
Heterogeneity
One of the features of the security market is that over time consolidation and partnership mean the bigger security vendors typically have an offering in pretty much every security category. SIEM and security analytics is no different. The question remains whether you go with one vendor or multiple? Is this a market where the best of breed argument should be considered? The answer depends on the problem you are trying to solve. Many SIEM vendors are offering security analytics capabilities, either via separate offerings or partnerships with smaller companies. As we mentioned before, inevitably the upstart security analytics players will add SIEM capabilities because that market is just too big to ignore. So what does that mean to enterprises?
We’ll run the risk of sounding like a broken record, but get back to your requirements. If you can get the security analytics you need to address your use cases from your incumbent SIEM vendor, that’s kind of a no-brainer. Likewise, if a security analytics vendor has many proof points of detecting attacks that are relevant to your environment (as determined during adversary analysis), you roll with that offering and coexist with your existing SIEM.
But even if you go with a single vendor right now, you must plan for heterogeneity. That means ensuring flexible integration between monitoring technologies. You’ll be adding cloud security monitoring in the near term, which throws the analytics decision into limbo. Furthermore, the only thing we can guarantee is that your attack surface will be different tomorrow and the adversaries will be better, so at some point and new analytics offering may make sense. You don’t want to paint yourself into a corner by not being able to access your data at any point.
By the way, heterogeneity doesn’t necessarily just pertain to analytics vendors and SIEM. Given the severe (and increasing) skills gap in finding security professionals, you may consider a service provider for some of these functions. Given the advanced nature and customization required for security analytics, we recommend looking at services that provide traditional SIEM capabilities. Keeping the SIEM tuned to detect attacks and having the service provider add use cases isn’t really their forte, based on our research.
But operating the system and making sure data gets to the right place is a reasonable expectation for most service providers. Regardless, when entering any service provider relationship care and diligence is required to ensure proper handoffs for alerts and ensure access to the SIEM data to facilitate forensics and incident response when the security analytics product fires an alert.
We’ll wrap up the series with the next post to focus on what this data-driven software-defined future of security monitoring looks like in practice.
- Mike Rothman (0) Comments Subscribe to our daily email digestfrom Security Analytics Team of Rivals: Coexistence Amongst Rivals
No comments:
Post a Comment