Evolving to Security Decision Support: Data to Intelligence

Posted under: Research and Analysis

As we kicked off the Evolving to Security Decision Support series, the point we needed to make is 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 really know where your critical data is and how it’s being used.

Though enterprise visibility is necessary, but not sufficient. You still have to figure out if/how you are being attacked and if/how data and/or apps are being misused. Ultimately no one gets any credit 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 do extensive security data collection (thanks compliance!), so you have a base to work with. It’s really just a matter of turning all of that security data into actual intelligence that you can use for security decision support.

The History of Security Monitoring

Let’s start by providing some historical perspective on how we got here, and why many organizations already do extensive security data collection. It all started in the early 2000s with deployment of the first SIEM, which was really 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!). Thus the SIEM products focused 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 have already seen. But you were pretty limited in the ability to detect the attacks you haven’t seen.

SIEM technology continues to evolve, but mostly to add scale and data sources to keep up with the number of devices and activity that need to be monitored. Yet, that doesn’t really help address the issue that many organizations don’t want more alerts, they want better alerts. In order to get those better alerts, two separate capabilities have come together in an interesting way:

1. Threat Intelligence: Since SIEM rules were based on looking for what you’ve seen before, you were limited in what you could look for – unless you’ve seen it. What if you could leverage attacks other companies have seen and then look for those attacks, so you could basically know what’s coming? That’s the underlying concept 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 may be malicious in nature. Call it anomaly detection, machine learning, or whatever – the concept is the same. Gather a bunch of security data, build mathematical profiles of activity patterns, then look for activity that isn’t normal.

Let’s go into both of these capabilities to gain a better understanding how they work and then we’ll be able to show how powerful integrating the two can be to generating those better alerts.

Threat Intel Identifies What Could Happen

Culturally for most of the past 20 years, security folks were the kids that didn’t play well in the sandbox. No one wanted to appear vulnerable, so data breaches and successful attacks were the dirty little secret of security. Sure it happened, but not to us. Yeah right. Still there would be very high profile issues (like SQL*Slammer) that couldn’t be swept under the rug, but they hit everyone so it wasn’t that big of a deal.

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

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

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

The key value of threat intel is to accelerate the human as we described in our Introduction to Threat Operations research. But what does that even mean? To illustrate a bit let’s consider retrospective search. Basically 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’ve seen this attack before you knew to look for it – ergo 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 clearly shortens the detection window.

Another use of threat intel is to refine your hunting process. This involves having the 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 (and yes, accelerates the human) by focusing on the typical tactics used by likely adversaries.

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

Yet, effectively leveraging threat intel does not 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 of the incumbent technologies. Security analytics is a case in point.

In concept, security analytics is pretty simple. Use advanced math to establish a baseline of activity in the morass of collected security data. Then look for situation that could indicate malicious activity or misuse of critical systems/data. In reality, it’s anything but simple.

The general technology underlying security analytics tools is anomaly detection. You remember that, right? The security analytics vendors can come up with fancy terms, but at its core, this isn’t new. In fact, we’ve 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 can 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? Firstly, you can analyze a lot more data, a lot more efficiently. As opposed to just looking at network flow records (like in the NBAD days), you can look at detailed network packet data, endpoint telemetry, logging activity from pretty much all of the devices and applications in use, and even potentially transaction data and then build the 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 that give you a reasonable place to start.

For example, you may want to find compromised devices. One way to do that is to look for devices that are doing strange things that could indicate misuse. Typically someone in your finance group shouldn’t be doing recon on devices in the engineering area. Or vice-versa. That’s not normal, and as such should probably be investigated. So paying attention to device behavior to detect malware is certainly a common use for security analytics.

Along with device behavior, you could also expand the purview of the analysis to look at broader insider threats by building a baseline for how specific employees use their devices (called user behavior analytics - UBA). Then when the 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 a broader analysis by adding data from physical access systems (to see when the employee is in the office), as well as HR records (an employee is under investigation and has become a flight risk). Or you could look at the usage by employees of specific applications, especially the ones accessing critical (and proprietary) corporate data. From all this data you can profiling the employee’s usage and transaction patterns. That gives you the baseline to look for activity that should be investigated.

Thus security analytics provides you not with a list of things you should look for (like threat intel or threat modeling), rather a list of things that are happening in your environment, providing more actionable alerts that most 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 now we need to ask a few more questions of the system to really 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 amongst all of the things (both internal and external) that should be looked at? Basically you need to balance the following to be able to effectively decide on what actions will be most impactful on your environment:

• Asset/Data Value: There are corporate systems and data that are pretty important to your company. When this kind of stuff is compromised, heads roll – probably yours. So obviously you are going to prioritize potential situations with these systems or users above most things. This is a subjective measure of value and requires a bunch of discussion with senior management to understand the value of the systems. But if you want to stay employed, you have to factor asset value into the mix since you don’t have the resources or time to get everything done.
• Confidence: False positives hurt you by wasting time on stuff that turns out to be nothing. Reducing this wasted time is done by tracking the confidence you have in your data/intel sources and analytical techniques. Obviously if a specific intel source sends you crap, then you should maybe 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, then you should minimize that source over time. Yet, if you do find something via retrospective search that indicates an attack, then that should be pretty high priority since you know the attack is legit and you know it’s happening in your environment.
• Internal Skills/Resources: The industry is making progress in automating some security activities, but there still seems to be an infinite amount of work to do. You also need to balance the reality of the skills at your disposal to prioritize. If you are weak at Tier 1 of your response because the front line staffers keep getting poached by consulting firms, then you may want to send alerts that may be urgent directly to Tier 2. Similarly, if you know the Tier 3 folks get into deep water on file-less attacks, then 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 really what you should be using to determine which sources work best. So the sooner you start working on quantifying value, the better. Not just from being able to prioritize better, but also to save money. If you are spending money on sources or analytics platforms that don’t provide value, maybe you should stop doing that.

By leveraging threat intel and more advanced security analytics, we’ve narrowed the aperture of all of the things you could look at, and helped you identify what you need to look at. We aren’t going to claim that this makes your to-do list manageable, but every bit helps. By focusing on likely attacks (based on threat intel) on those devices that are acting abnormally while considering the value of the asset being attacked and the confidence you have in the data, it’s far more likely you’ll focus on the attacks that 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.

As we wrap up the series, our next piece will focus on how better, more contextual alerts can favorably impact security operations and what integrations are required to make that vision a reality.

- Mike Rothman
(0) Comments
Subscribe to our daily email digest

The post Evolving to Security Decision Support: Data to Intelligence appeared first on Security Boulevard.

from Evolving to Security Decision Support: Data to Intelligence