As we kicked off our Evolving to Security Decision Support series, the point we needed to make was the importance of enterprise visibility to the success of your security program. Given all the moving pieces in your environment – including the usage of various clouds (SaaS and IaaS), mobile devices, containers, and eventually IoT devices – it’s increasingly hard to know where all your critical data is and how it’s being used.

So enterprise visibility is necessary, but not sufficient. You still need to figure out whether and how you are being attacked, as well as whether and how data and/or apps are being misused. Nobody gets credit just for knowing where you can be attacked. You get credit for stopping attacks and protecting critical data. Ultimately that’s all that matters. The good news is that many organizations already collect extensive security data (thanks, compliance!), so you have a base to work with. It’s really just a matter of turning all that security data into actual intelligence you can use for security decision support.

The History of Security Monitoring

Let’s start with some historical perspective on how we got here, and why many organizations already perform extensive security data collection. It all started in the early 2000s with deployment of the first SIEM, deployed to make sense of the avalanche of alerts coming from firewalls and intrusion detection gear. You remember those days, right?

SIEM evolution was driven by the need to gather logs and generate reports to substantiate controls (thanks again, compliance!). So the SIEM products focused more on storing and gathering data than actually making sense of it. You could generate alerts on things you knew to look for, which typically meant you got pretty good at finding attacks you had already seen. But you were pretty limited in ability to detect attacks you hadn’t seen.

SIEM technology continues to evolve, but mostly to add scale and data sources to keep up with the number of devices and amount of activity to be monitored. But that doesn’t really address the fact that many organizations don’t want more alerts – they want better alerts. To provide better alerts, two separate capabilities have come together in an interesting way:

1. Threat Intelligence: SIEM rules were based on looking for what you had seen before, so you were limited in what you could look for. What if you could leverage attacks other companies have seen and look for those attacks, so you could anticipate what’s coming? That’s the driver for external threat intelligence.
2. Security Analytics: The other capability isn’t exactly new – it’s using advanced math to look at the security data you’ve already collected to profile normal behaviors, and then look for stuff that isn’t normal and might be malicious. Call it anomaly detection, machine learning, or whatever – the concept is the same. Gather a bunch of security data, build mathematical profiles of normal activity, then look for activity that isn’t normal.

Let’s consider both these capabilities to gain a better understanding how they work, and then we’ll be able to show how powerful integrating them can be for generating better alerts.

Threat Intel Identifies What Could Happen

Culturally, over the past 20 years, security folks were generally the kids who didn’t play well in the sandbox. Nobody wanted to appear vulnerable, so data breaches and successful attacks were the dirty little secret of security. Sure, they happen, but not to us. Yeah, right. There were occasional high-profile issues (like SQL*Slammer) which couldn’t be swept under the rug, but they hit everyone so weren’t that big a deal.

But over the past 5 years a shift has occurred within security circles, borne out of necessity as most such things are. Security practitioners realized no one is perfect, and we can collectively improve our ability to defend ourselves by sharing information about adversary tactics and specific indicators from those attacks. This is something we dubbed “benefiting from the misfortune of others” a few years ago. Everyone benefits because once one of us is attacked, we all learn about that attack and can look for it. So the modern threat intelligence market emerged.

In terms of the current state of threat intel, we typically see the following types of data shared within commercial services, industry groups/ISACs, and open source communities:

• Bad IP Addresses: IP addresses which behave badly, for instance by participating in a botnet or acting as a spam relay, should probably be blocked at your egress filter, because you know no good will come from communicating with that network. You can buy a blacklist of bad IP addresses, probably the lowest-hanging fruit in the threat intel world.
• Malware Indicators: Next-generation attack signatures can be gathered and shared to look for activity representative of typical attacks. You know these indicate an attack, so being able to look for them within your security monitors helps keep your defenses current.

The key value of threat intel is to accelerate the human, as described in our Introduction to Threat Operations research. But what does that even mean? To illustrate a bit, let’s consider retrospective search. This involves being notified of a new attack via a threat intel feed, and using those indicators to mine your existing security data to see if you saw this attack before you knew to look for it: retrospective search. Of course it would be better to detect the attack when it happens, but the ability to go back and search for new indicators in old security data shortens the detection window.

Another use of threat intel is to refine your hunting process. This involves having a hunter learn about a specific adversary’s tactics, and then undertake a hunt for that adversary. It’s not like the adversary is going to send out a memo detailing its primary TTPs, so threat intel is the way to figure out what they are likely to do. This makes the hunter much more efficient (“accelerating the human”) by focusing on typical tactics used by likely adversaries.

Much of the threat intel available today is focused on data to be pumped into traditional controls, such as SIEM and egress filters. There is an emerging need for intel on new areas of exposure including the cloud, IoT, and mobility. As more attacks leverage these new attack vectors, more data becomes available, making us all better. But in the meantime there is a clear gap in the data available to feed these emerging technologies.

Yet effectively leveraging threat intel alone cannot realize the full potential of Security Decision Support. Knowing what could happen is very helpful. But you still end up with a long list of stuff to triage and potentially remediate, and little real context to prioritize those efforts. That’s where analytics comes in.

Analytics Identifies What Is Happening

The SIEM has historically been algorithmically challenged because its correlation engine was designed to alert on activity you knew to look for. It doesn’t help much with stuff you haven’t seen. Thus, as happens in markets like security, new approaches emerged to fill the gaps in incumbent technologies. Security analytics is a case in point.

Security analytics is conceptually simple. Use advanced math to establish a baseline of activity in the mass of collected security data. Then look for situations which could indicate malicious activity or misuse of critical systems or data. In reality, of course, it’s anything but simple.

The basic technology underlying security analytics tools is anomaly detection. You remember that, right? Security analytics vendors come up with fancy terms, but at its core this isn’t new. We have been looking for anomalies in our security data for over a decade. Remember Network-Based Anomaly Detection (NBAD)? We certainly do (being security historians and all) and that was the first “security analytics” offering we remember.

To be clear, NBAD worked and still does. The technology has been wrapped up into a variety of different offerings so there aren’t really stand-alone NBAD companies anymore, but the approach has evolved and morphed into what we now call security analytics. So what’s different now? First, you can analyze a lot more data, a lot more efficiently. Instead of just looking at network flow records (like in the NBAD days), you can now look at detailed network packet data, endpoint telemetry, log activity from pretty much all devices and applications in use, and even potentially transaction data, and then build a baseline to learn what is normal activity in your environment.

Most enterprise networks are pretty complicated (and getting more so), so building a baseline across a number of seemingly unrelated security data sources is challenging. So to simplify things a bit you can start by looking at different use cases to chunk up the universe of activity into a manageable set to get a reasonable place to start.

For example you might want to find compromised devices. One way to do that is to look for devices doing strange things which could indicate misuse. Typically someone in Finance shouldn’t be reconnoitering devices in Engineering. Or vice-versa. That’s not normal, and as such should probably be investigated. So paying attention to device behavior to detect malware is a common use for security analytics.

Along with device behavior, you could also expand the purview of analysis to include broader insider threats by building a baseline for how specific employees use their devices (called User Behavior Analytics: UBA). Then when an employee does something funky, like connecting to the finance system from a tablet at home, you can flag that as something to look at.

You could extend that use case to broader analysis by adding data from physical access systems (to see when an employee is in the office), as well as HR records (an employee under investigation, or considered a flight risk). Or you could look at employee usage of specific applications, especially the ones accessing critical proprietary corporate data. From all this data you can profiling employee usage and transaction patterns. That provides a baseline to help identify activity which should be investigated.

Security analytics provides you not with a list of things to look for (like threat intel or threat modeling), but a list of things happening in your environment, providing more actionable alerts which likely warrant investigation.

Yet security analytics on its own also doesn’t rise to the standard of Security Decision Support. The analytics can identify things you need to look for, but you still don’t have a sense of importance or prioritization relative to the other things the analytics platform is alerting on. So we need to ask a few more questions of the system to understand how to make better decisions.

Driving Security Decisions

Now that you have an understanding of which attacks are being used in the wild (via threat intel) and which systems/users/applications are potentially being misused, the next step is to use that context to drive action. But what action? How do you prioritize all the things (both internal and external) that should be looked at? You need to balance the following to effectively decide which actions will be most impactful in your environment:

• Asset/Data Value: There are corporate systems and data which are important to your company. When this kind of stuff is compromised, heads roll – probably yours. So obviously you are going to prioritize potential situations involving these systems or users above others. This is a subjective measure of value, so it requires a bunch of discussion with senior management to understand the values of various systems. But if you want to stay employed you need to factor asset value into the mix – you don’t have the resources or time to do everything.
• Confidence: False positives hurt you by wasting time on stuff which turns out to be nothing. Reducing this wasted time is possible by tracking the confidence you have in your data/intel sources and analytical techniques. Obviously if a specific intel source sends you crap, you should not jump when it alerts. Likewise if a bunch of alerts based on a user’s mobile activity turn out to be much ado about nothing, you should de-emphasize that source over time. Yet if you do find something via retrospective search that indicates an attack, that should be high-priority since you know the attack is legitimate and happening in your environment.
• Internal Skills/Resources: The industry is making progress at automating some security activities, but there still seems to be an infinite amount of work to do. You also need to consider the skills at your disposal to prioritize. If you are weak at Tier 1 response because your front-line staffers keep getting poached by consulting firms, you may want to send alerts that might be urgent directly to Tier 2. Similarly, if you know your Tier 3 folks get into deep water on file-less attacks, you may want to just quarantine those devices until your external forensics team can take a look.

This kind of process requires the ability to measure effectiveness of both threat intel and analytics over time. A gut feel isn’t the best tool to determine which sources work best. The sooner you start quantifying value the better. Not just for better prioritization but also to save money. If you are spending money on sources or analytics platforms which don’t provide value, stop.

By leveraging threat intel and more advanced security analytics, we have narrowed the aperture of all the things you could look at, to help identify what you need to look at. We won’t claim this makes your to-do list manageable, but every bit helps. By focusing on likely attacks (according to threat intel) on devices which are acting abnormally, while considering the value of the asset being attacked and your confidence in the data, it’s far more likely you will focus on the attacks which matter.

This is what Security Decision Support is all about. Enabling you to make the best use of your available resources by working smarter, leveraging technology and external resources to improve the effectiveness of your security team.

To wrap up this series our next post will focus on how better and more contextual alerts can favorably impact security operations, and which integrations are required to make that vision a reality.