As we get back into Network-Based Threat Intelligence, let’s briefly revisit our first two posts. We started by highlighting the Kill Chain, which delved into the typical attack process used by advanced malware to achieve the attacker’s mission, which usually entails some kind of data exfiltration. Next we asked the 5 key questions (who, what, where, when, and how) to identify indicators of an advanced malware attack that can be captured by monitoring network traffic. With these indicators we can deploy sensors to monitor network traffic, and hopefully to identify devices exhibiting bad behavior, before real damage and exfiltration occur. That’s the concept behind the Early Warning System.

Deployment

As described, network-based threat intelligence requires monitoring key network segments for indicators of attack traffic (typically command and control). Many organizations have extensive and sprawling network infrastructure, so you probably cannot monitor everything initially. So it’s about initial prioritization of networks to give yourself the best chance to get the Quick Win and hopefully break the Data Breach Triangle. So where do you start?

The first and easiest place to start monitoring the network is your egress pipes to the Internet. Today’s malware systematically uses downloaders to get the latest and greatest attack code, which means the compromised device need to communicate with the outside world at some point. This Internet communication offers your best opportunity to identify devices as compromised, if you monitor your egress networks and can isolate these communications. Besides providing an obvious choke point for identification of command and control traffic, egress connections tend to be lower bandwidth than a internal network segments, making egress monitoring more practical than full internal monitoring.

We have long advocated full network packet capture, in order to enable advanced analytics and forensics on network traffic. As part of our React Faster and Better research, we named the Full Packet Capture Sandwich: deploying network capture devices on the perimeter and in front of particularly critical data stores. This approach is totally synergistic with network-based threat intelligence, since you will be capturing the network traffic and can look for command and control indicators that way. Of course, if full packet capture isn’t deployed (perhaps because it’s beyond the sophistication of your operations team), you can just monitor the networks using purpose-built sensors looking specifically for these indicators. Obviously real-time network-based threat intelligence feeds integrated into the system are critical in this scenario, as you only get one chance to identify C&C traffic because you aren’t capturing it.

Another place for network traffic monitoring is internal DNS infrastructure. As described previously in the series, DNS request patterns can indicate domain generation algorithms and/or automated (rather than human) connection requests to the C&C network. Unless your organization is a telecom carrier you won’t have access to massive amounts of DNS traffic, but large enterprises running their own DNS can certainly identify trends and patterns within their infrastructure by monitoring DNS.

Finally, in terms of deployment, you will always have the push/pull of inline vs. out-of-band approaches to network security. Remember that network-based threat intelligence is a largely reactive approach for identifying and finding command and control traffic which indicates a compromised device. In fact the entire Early Warning System concept is based on shortening the window between compromise and detection, rather than an effort to prevent compromise. Of course it would it even better to be able to identify C&C traffic on the egress pipe and block it, preventing compromised devices from communicating with attackers.

But we need to be cautious with the bane of every security practitioner: the false positive. So before you block traffic or kill an IP session, you need to be sure you are right. Of course most organizations want the ability to disrupt attack traffic, but very few actually do. Most “active network controls”, including network-based malware detection devices, are implemented in monitoring/alerting mode, because most practitioners consider impacting a legitimate connection far worse than missing an attack.

A jury of (network) peers

So you have deployed network monitors – what now? How can we get that elusive Quick Win to show immediate value from network-based threat intelligence? You want to identify compromised devices based on communication patterns. But you don’t want to wrongly convict or disrupt innocent devices, so let’s dust off an analogy dating back to the anti-spam battles: the jury. During the early spam battles, analyzing email to identify unsolicited messages (spam) involved a number of analysis techniques (think 30-40) used to determine intent. None of those techniques is 100% reliable alone, but in combination, using a reasonable algorithm to properly weigh techniques effectiveness, spam could be detected with high reliability. That “spam cocktail” still underlies many of the email security products in use today.

You will use the same approach to weigh all network-based malware indicators to determine whether a device is compromised or not, based on what you see from the network. It’s another cocktail approach, where each jury member looks at a different indicator to determine guilt or innocence. The jury foreman – your analysis algorithm – makes the final determination of compromise. By analyzing all the traffic from your key devices, you should be able to identify the clearly compromised ones. This type of detection provides the initial Quick Win. You had a compromised device that you didn’t know was compromised until you monitored the traffic it generated. That’s a win for monitoring & analysis!

You should worry about whether you will find anything with this approach. In just about any reasonably-sized enterprise, the network will show a handful to a few dozen compromised devices. Nothing personal, folks, but we have yet to come across an environment of a few thousand machines without any compromised devices. It’s just statistics. Employees click on stuff, and that’s all she wrote. The real question is how well you know which devices are compromised and how severe the issues are – how quickly do you have to take action?

Intelligence-driven focus

Once you have identified which devices you believe have been compromised, your incident response process kicks in. Given resource constraints, it would likely be impractical to fully investigate every device, analyze each one, isolate the malware in use, and search for those indicators elsewhere in your environment. So you will need to make tough choices about where to focus first. The good news is that you will be able to leverage your network-based threat intelligence, along with other internal data, to generate a fairly clear picture of what to focus on. Let’s roughly prioritize which compromised devices to deal with first:

1. Critical devices: Devices with access to protected information and/or particularly valuable intellectual property should bubble up to the top. Fast. If a device on a protected and segmented network shows indications of compromise, that’s BAD and needs to be dealt with immediately. Even if the device is dormant, traffic on a protected network that looks like command and control is smoke, and you need to act quickly to ensure the fire doesn’t spread. Or enjoy your disclosure activities…
2. Active malicious devices: If you see device behavior which indicates an active attack (perhaps doing recon, moving laterally within the environment, blasting bits at internal resources, or exfiltrating data), that’s your next order of business. Even if the device isn’t considered critical, if you don’t deal with it promptly, it might find an exploitable hole to compromise a higher-value device. So investigate and remediate these devices next.
3. Dormant devices: These devices show behavior consistent with command and control (typically staying in communication with a C&C network), but aren’t really doing anything yet. Given the number of other fires raging in your environment, you may not want to remediate devices immediately. But that decision is somewhat controversial, so we will handle it separately.

These priorities are fairly coarse but should be sufficient. You don’t want a complicated multi-tier rating system, which is too involved to use on a daily basis. And keep in mind that intelligence can provide a decent idea of the specific adversary behind an attack, as well as a better idea of motive. Depending on what you know of the attacker (hacktivist vs. organized crime syndicate, for example), this may be another filter to determine urgency of response and best path for remediation.

To remediate or not

It may be hard to believe but there are real scenarios where you may not want to immediately remediate a compromised device. The first – and easiest to justify – is when it is part of an ongoing investigation and either HR or law enforcement has mandated that the device be observed and otherwise left alone. At that point the decision is no longer in your hands, and the ramifications of an actively compromised device on your network don’t fall in your lap. Well, ultimately it will, but you will at least be able to point the finger at someone else as you get thrown under the bus.

Another scenario where remediation may not be the best course of action is when you need to study and profile the malware, and its command and control traffic, through direct observation. Obviously you need a sophisticated security program to undertake a detailed malware analysis process (as described in Malware Analysis Quant), but clearly understanding and identifying indicators of compromise can help identify other compromised devices, and enable you to deploy workarounds and other infrastructure protections, such as IPS rules and HIPS signatures.

That said, in most cases you will just want to pull the device off the network as quickly as possible, pull a forensic image, and then reimage it. That’s usually the only way to ensure the device is clean before letting it back into the general population. If you are going to follow any of the observational scenarios, however, they and your decision tree need to be documented and agreed on as part of your incident response plan.

Communicating the win

As we discussed in Building the Early Warning System, your success stories won’t tell themselves, so when the process succeeds – likely early on – you will need to publicize it and identify how network-based threat intelligence helped to identify compromised devices well before traditional means of finding successful attacks. Let’s excerpt a bit from that research to illuminate what we’re talking about:

There are two key areas to focus on. The first is finding proof of an attack in progress, which you successfully remediate thanks to threat intelligence and the EWS. This illustrates that you will be compromised, so success is a matter of containing the damage and preventing data loss. The value of the EWS is in shortening the window between exploit and detection. If you can definitively say that you get threat intel on emerging attacks (particularly on competitors or partners) and then evaluate whether action needs to be taken, that allays the fear of senior management that Security has no idea what’s happening until it is already over – too late. Even better if you can discuss how preemptive workarounds and remediations, implemented in response to threat intelligence, blocked an actual attack. Finally, to whatever degree you quantify the time you spend remediating issues and cleaning up compromises, you can show how much you saved by using external feeds to refine your efforts and prioritize your activities.

Every security investment is scrutinized for value, but the good news is that network-based threat intelligence can provide immediate and measurable benefit in terms of identifying compromised devices. It is incumbent on you to tell the stories and show how the intelligence was instrumental in improving security.

Integrating with other enterprise systems

As compelling as network-based threat intelligence is, before you can provide value and increase your security program’s effectiveness, you need to integrate with other enterprise security systems. For instance, you will want to be able to send alerts about indicators of compromise to your SIEM or other alerting system, in order to kick off the investigation process. Likewise, the ability to configure workarounds such as IPS blocking rules based on network indicators provides the ability not merely to identify compromised devices, but also to block C&C or exfiltration traffic. Obviously false positives are a concern – as with any blocking rule – but the ability to disrupt the attackers can provide significant value. Likewise, integration with Network Access Control could shift a device flagged as potentially compromised onto a quarantine network until it can be investigated and remediated. All these integrations take the data from concept to action, and contribute directly to containing the damage from compromised devices.

In terms of forensics, network-based threat intelligence could integrate with a full packet capture/network forensics platform. In this use case, when a device shows potential compromise, its traffic could be captured for forensic analysis. This would provide the proverbial smoking gun, as well as the basis to investigate the malware, as described above. This enables you to be more precise and efficient about what traffic to capture, and ultimately what to investigate.

Remember that the objective of an Early Warning System is to shorten the windows between compromise, detection, and remediation. By integrating network-based threat intelligence with more active security controls, it is possible to contain damage more effectively than waiting for the FBI, Secret Service, or your local law enforcement organization to let you know you have a problem. With that we wrap up this short Network-Based Threat Intelligence series. We will compile the posts into a paper in the very near term, so you still have an opportunity to provide feedback via comments on the blog post…