As we discussed in Defining TI, threat intelligence can help detect attacks earlier by benefiting from the misfortune of others and looking for attack patterns being used against higher profile targets. This is necessary because you simply cannot prevent everything. No way, no how. So you need to get better and faster at responding. The first step is improving detection to shorten the window between compromise and discovery of compromise.

Before we jump into how – the meat of this series – we need to revisit what your security monitoring process can look like with threat intelligence.

TI+SM

We will put the cart a bit before the horse. We will assume you already collect threat intelligence as described in the last post. But of course you cannot just wake up and find compelling TI. You need to build a process and ecosystem to get there, but we haven’t described them in any detail yet. But we will defer that discussion a little, until you understand the context of the problem to solve, and then the techniques for systematically gathering TI will make more sense.

Let’s dig into specific aspects of the process map:

Aggregate Security Data

The steps involved in aggregating security data are fairly straightforward. You need to enumerate devices to monitor in your environment, scope out the kinds of data you will get from them, and define collection policies and correlation rules – all described in gory detail in Network Security Operations Quant. Then you can move on to actively collecting data and storing it in a repository to allow flexible, fast, and efficient analysis and searching.

Security Analytics

The security monitoring process now has two distinct sources to analyze, correlate, and alert on: external threat intelligence and internal security data.

1. Automate TI integration: Given the volume of TI information and its rate of change, the only way to effectively leverage external TI is to automate data ingestion into the security monitoring platform; you also need to automatically update alerts, reports, and dashboards.
2. Baseline environment: You don’t really know what kinds of attacks you are looking for yet, so you will want to gather a baseline of ‘normal’ activity within your environment and then look for anomalies, which may indicate compromise and warrant further investigation.
3. Analyze security data: The analysis process still involves normalizing, correlating, reducing, and tuning the data and rules to generate useful and accurate alerts.
4. Alert: When a device shows one or more indicators of compromise, an alert triggers.
5. Prioritize alerts: Prioritize alerts based on the number, frequency, and types of indicators which triggered them; use these priorities to decide which devices to further investigate, and in what order. Integrated threat intelligence can help by providing additional context, allowing responders to prioritize threats so analysts can investigate the highest risks first.
6. Deep collection: Depending on the priority of the alert you might want to collect more detailed telemetry from the device, and perhaps start capturing network packet data to and from it. This data can facilitate validation and identification of compromise, and facilitate forensic investigation if it comes to that.

Action

Once you have an alert, and have gathered data about the device and attack, you need to determine whether it was actually compromised or the alert was a false positive. If a device has been compromised you need to escalate – either to an operations team for remediation/clean-up, or to an investigation team for more thorough incident response and analysis. To ensure both processes improve constantly you should learn from each validation step: critically evaluate the intelligence, as well as the policy and/or rule that triggered the alert.

For a much deeper discussion of how to Leverage TI in Security Monitoring check out our paper.

Useful TI

We are trying to detect attacks faster in this use case (rather than working on preventing or investigating them), so the most useful types of TI are strong indicators of problems. Let’s review some data sources from our last post, along with how they fit into this use case:

• Compromised Devices: The most useful kind of TI is a service telling you there is a cesspool of malware on your network. This “smoking gun” can be identified by a number of different indicators, as we will detail below. But if you can get a product to identify those devices wih analytics on TI data, it saves you considerable effort analyzing and identifying suspicious devices yourself.

Of course you cannot always find a smoking gun, so specific TI data types are helpful for detecting attacks:

• File Reputation: Folks pooh-pooh file reputation, but the fact is that a lot of malware still travels around through the tried and true avenue of file transmission. It is true that polymorphic malware makes it much harder to match signatures, but it’s not impossible; so tracking the presence of files can be helpful for detecting attacks and pinpointing the extent of an outbreak – as we will discuss in detail in our next post.
• Indicators of Compromise: The shiny new term for an attack signature is indicator of compromise. But whatever you call it an IoC is a handy machine-readable means of identifying registry, configuration, and system file changes that indicate what malicious code does to devices. This kind of detailed telemetry from endpoints and networks enables you to detect attacks as they happen.
• IP reputation: At this point, given the popularity of spoofing addresses, we cannot recommend making a firm malware/clean judgement based only on IP reputation, but if the device is communicating with known bad addresses and showing other indicators (which can be identified through the wonders of correlation – as a SIEM does) you have more evidence of compromise.
• C&C Patterns: The last TI data source for this use case is a behavioral analog of IP reputation. You don’t necessarily need to worry about where the device is communicating to – instead you can focus on how it’s communicating. There are known means of polling DNS to find botnet controllers which can be identified and detected by monitoring network traffic (either on the device or at the egress point).

Of course your monitoring tool must understand how to parse these specific patterns and indicators, which is a good segue to integration.

SIEM-tegration

The discussion so far begs one question: how and where should you use TI data? We suggest you start with your existing tool, which is likely a SIEM of some sort (or a shiny cousin: a security monitoring/analytics platform). To understand the leverage points we need to recall what SIEM does in the first place.

Basically, SIEM looks for patterns in security data via correlation and other fancy math techniques. Though a major restriction of SIEM technology is you need to know what to look for in the data, and that involves building complex rules to look for specific attack scenarios/threat models. Many organizations spend considerable time and money figuring out these complex rules, and then spend even more time and money tuning system to produce some semblance of actionable alerts. And if you ask SOC (Security Operations Center) staff, they will be happy to explain (colorfully) that many of the alerts – even after significant tuning – turn out to be false positives.

Availability of the data types described above changes what you should be looking for – at least initially. If you know there are a handful (or a couple handfuls) of attacks prevalent in the wild at any given moment, you should look for those. This approach is far more efficient and effective than looking for every possible attack.

But this only works if you can keep the rules up to date with the latest threat intelligence reflecting the latest attacks. Unless you have some kind of savant who can parse a threat intelligence feed and build SIEM rules instantly, you will need to automate loading and rule building in your monitoring tool. We discussed the emergence of standards like STIX and TAXXI to facilitate the integration of threat feeds into your security monitoring platform in our last post. But even without standards, many TI providers have built custom integrations to feed data into the leading SIEM and security analytics products/services, to extract value from data.

Actionable TI

Why is this approach better than just looking for patterns like privilege escalation or reconnaissance, as we learned in SIEM school? Because TI data represents attacks that are happening right now in other networks. Attacks you won’t see (or know to look for) until it’s too late. In a security monitoring context, leveraging TI enables you to focus your validation/triage efforts, shorten the window between compromise and detection, and ultimately make better use of scarce resources which need to be directed at the most important current risk. That is what we’d call actionable intelligence.