As we described in the introduction to this series, security monitoring has been around for a long time and is evolving quickly. But one size doesn’t fit all, so if you are deploying a Team of Rivals they will need to coexist for a while. Either the old guard evolves to meet modern needs, or the new guard will supplant them. But in the meantime you need to figure out how to solve a problem: detecting advanced attackers in your environment.

We don’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. Briefly, President Lincoln needed to make a divisive political organization work. So he named rivals to his Cabinet, making sure everyone was accountable for the success of his administration. There are parallels in security, notably that the security program must, first and foremost, protect critical data. So the primary focus must be on detection and prevention of attacks, while ensuring the ability to respond and generate compliance reports. Different tools (today, at least) specialize in different aspects of the security problem, and fit in a security program different places, but ultimately they must work together. Thus the need for a Team of Rivals.

How can you get these very different and sometimes oppositional tools to work together? Especially because that may not be in their best interest. Most SIEM vendors are working on a security analytics strategy, so they aren’t likely to be enthusiastic about working with a third-party analytics offering… which may someday replace them. Likewise, security analytics vendors want to marginalize the old guard as quickly as possible, leveraging SIEM capabilities for data collection/aggregation and then taking over the heavy analytics lifting from to deliver value independently.

As always, trying to outsmart vendors is a waste of time. Focus on identifying the organization’s problems, and then choose technologies to address them. That means starting with use cases, letting them drive which data must be collected and how it should be analyzed.

Revisiting Adversaries

When evaluating security use cases we always recommend starting with adversaries. Your security architecture, controls, and monitors need to factor in the tactics of your likely attackers, because you don’t have the time or resources to address every possible attack. We have researched this extensively, and presented our findings in The CISO’s Guide to Advanced Attackers), but in a nutshell, adversaries can be broken up into a few different groups:

1. External actors
2. Insider threats
3. Auditors

You can break external actors into a bunch of subcategories, but for this research that would be overkill. We know an external actor needs to gain a foothold in the environment by compromising a device, move laterally to achieve their mission, and then connect to a command and control network for further instructions and exfiltration. This is your typical adversary in a hoodie, wearing a mask, as featured in every vendor presentation.

Insiders are a bit harder to isolate because they are often authorized to access the data, so detecting misuse requires more nuance – and likely human intervention to validate an attack. In this case you need to look for signs of unauthorized access, privilege escalation, and ultimately exfiltration.

The third major category is auditors. Okay, don’t laugh too hard. Auditors are not proper adversaries, but instead a constituency you need to factor into your data aggregation and reporting efforts. These folks are predominately concerned with checklists. So you’ll need to make sure to substantiate the work instad of just focusing on results.

Using the right tool for the job

You already have a SIEM, so you may as well use it. The strength of a SIEM is in data aggregation, simple correlation, forensics & response, and reporting. But what kinds of data do you need? A lot of the stuff we have been talking about for years.

• Network telemetry, with metadata from the network packet streams at minimum
• Endpoint activity, including processes and data flowing through a device’s network stack
• Server and data center logs, and change control data
• Identity data, especially regarding privilege escalation and account creation
• Application logs – the most useful are access logs and logs of bulk data transfers
• Threat Intelligence to identify attacks seen in the wild, but not necessarily by your organization, yet

This is not brain surgery, and you are doing much of it already. Monitors to find simple attacks have been deployed and still require tuning, but should work adequately. The key is to leverage the SIEM for what it’s good at: aggregation, simple correlation (of indicators you know to look for), searching, and reporting. SIEM’s strength is not finding patterns within massive volumes of data, so you need a Rival for that.

Let’s add security analytics to the mix, even though the industry has defined the term horribly. Any product that analyzes security data now seems to be positioned as a security analytics product. So how do we define “security analytics” products? Security analytics uses a set of purpose-built algorithms to analyze massive amounts of data, searching for anomalous patterns indicating misuse or activity.

There are a variety of approaches, and even more algorithms, which can look for these patterns. We find the best way to categorize analytics approaches is to focus on use cases rather than the underlying math, and we will explain why below. We will assume 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 in terms of use cases, a few bubble up to the top. There are many ways to apply math to a security problem, so you are welcome to quibble with our simplistic categories. But we’ll focus on the three use cases we hear about most often.

Advanced Attack Detection

We need advanced analytics to detect advanced attacks because older monitoring platforms are driven by rules – you need to know what you are looking for. Unfortunately, as we have all learned, modern attackers don’t follow a single playbook, so looking for yesterday’s attacks is lousy strategy. Advanced attack detection is based on data from traditional logs, as well as endpoint and network telemetry. There is plenty of religion about which data sources are most reliable, but we try not to br distracted by it. We find all the data sources important at least sometimes, so we expect any advanced detection vendor to broaden their analysis beyond their initial focus.

User Behavior Analysis

UBA has a lot in common with advanced attack detection, but focuses on user behavior. The insight is that at some point every attack involves compromising a user, so users are the best place to detect attacks. This analysis is complicated by the fact that users interact with systems both inside and outside your organization. Yes, those pesky users continue to use SaaS service which may not provide you adequate visibility. And they may connect with multiple devices. So you need to get past a device-centric perspective, and evaluate behavior across many devices to understand a user’s typical behavior and recognize abnormal activity. And users access systems from many different locations, which further complicates 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 for users running through a proxy (either on-premise or within the cloud) to enable activity inspection.

Insider Threat

The final use case we will highlight involves looking specifically for malicious insiders, with authorized access to data. As with the other two, this analysis considers user behavior and network telemetry, but may also involve internal system access (especially Finance and HR systems) as well as physical access. Analytics must be customized to the organization, to account for variation in access patterns. Legitimate use can have many different meanings, so the data inputs are not necessarily consistent, and the indicators of misuse must be tuned and optimized much more, increasing deployment time and required customization.

But there is value in this use case. Every attack involves not just a compromised device, as pointed out 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. But detection occurs later in the attack cycle – after the insider starts misbehaving.

The Reality of Security Analytics Use Cases

Being a bit more creative, we could add cognitive analysis, web behavior, identity analytics, application usage, cloud security analytics, and a variety of other use cases. But that becomes overkill, because these use cases all leverage advanced mathematical analysis of aggregated data. The use cases differ mostly on which data you feed the analysis. At the end of the day they all overlap, so we expect all security analytics vendors to roll out solutions addressing all useful use cases soon enough.

In the heat of a buying cycle you will hear a lot about this and that mathematical technique. Unless you have a Ph.D. in Mathematics, this may be pure distraction. We prefer to stick with what we understand: the general concepts driving detection.

In this morass of advanced math and technical mumbo jumbo, it’s easy to forget that detecting attacks is pretty straightforward (not easy, but conceptually simple). You need to look for patterns which indicate an active threat actor. Follow the kill chain, looking for things such as reconnaissance, privilege escalation, command and control traffic, and exfiltration. The sooner you detect an attack, the more likely you can intervene before a data breach. Easier said than done, but don’t overcomplicate the decision.

Coexistence

Returning to the right tool for the job, security analytics offerings aren’t really designed to provide a clear way to search for and pivot on an alert, for forensics and incident response. They also don’t lend themselves to easy compliance reporting. That does not mean the tools cannot extend their functionality, growing into those requirements over time.

But today in early 2017, analytics tools aren’t built to address all the use cases for security monitoring. You cannot yet choose one or the other – you will need both to work together for the foreseeable future. That means looking for logical integration points, including:

1. Data: Your SIEM has been collecting and aggregating security data for a long time. Messing with it now doesn’t make much sense. Extracting data to drive security analytics is much like data extraction for non-security business intelligence. Extraction can be time-consuming so ensure you automate it sufficiently.
2. Alerts: You will be getting alerts from both systems, so you need to figure out what will happen when an alert fires. Which system will be the system of record? Where will operations folks and responders spend the majority of their time? Organizations often centralize alerting around the SIEM, and jump into the analytics platform to drill down into relevant alerts.

Heterogeneity

One feature of the security market is that consolidation and partnership continuously drive larger security vendors to offer something in pretty much every product category. SIEM and security analytics are no different. The question is whether you will go with one vendor, or several. Is this a market for the best of breed? Your answer depends on which problem you are trying to solve. Many SIEM vendors offer security analytics capabilities, either via separate offerings or partnerships with smaller companies. As we mentioned earlier, inevitably upstart security analytics players will add SIEM capabilities because that market is too big to ignore. But what does that mean to enterprises?

At risk of sounding like a broken record, go back to your requirements. If you can get the security analytics you need for your use cases from your SIEM vendor, then that’s a no-brainer. Likewise, if a security analytics vendor offers proof points for detecting relevant attacks you have highlighted during adversary analysis, roll with that offering and coexist with your existing SIEM.

But even if you go with a single vendor today, plan for heterogeneity. Ensure flexible integration between monitoring technologies. You will add cloud security monitoring soon, if you don’t have it already, and that may reopen your analytics decision. The only thing we can guarantee is that your attack surface will be different tomorrow and adversaries will be better, so at some point a new analytics offering may make sense. Don’t paint yourself into a corner by losing any access to your data.

By the way, heterogeneity doesn’t pertain only to analytics vendors and SIEM. Given the severe (and increasing) skills gap we see when searching for security professionals, you mights consider a service provider for some of these functions. Considering the advanced nature of, and customization required for, security analytics, we recommend evaluating services which provide traditional SIEM capabilities. Keeping a SIEM tuned to detect attacks and having a service provider add use cases isn’t really their forte.

But operating the system and making sure data gets to the right place is a reasonable expectation for a service provider. Regardless, with any service provider, care and diligence are required – in this case pay attention to proper alert handoffs and access to SIEM data for facilitate forensics and incident response.

We will wrap up this series with our next post, focused on what this data-driven anda software-defined future of security monitoring looks like in practice.