Breaking Cyber Kill Chains®

The “cyber kill chain®”¹ is a model for framing an incident response/analysis capability that was developed by Lockheed Martin’s Computer Incident Response Team. It is a useful framework for talking about and reasoning about why and how we do things in security. The term “kill chain” is admittedly violent when you consider that we're talking about an environment in which, ideally, nothing of the sort is happening. But the framework is useful, as we shall see. Think of the cyber kill chain as an attack chain, the path that an intruder takes to penetrate information systems over time to execute an attack on a target.

The framework breaks down the stages of a hack as follows:

• Reconnaissance - studying public information about the target, the target's environment, software mix, practices and software loadout
• Weaponization - preparing a backdoor and a penetration plan intended to deliver a successful attack
• Delivery - launching the attack and injecting the backdoor
• Exploitation - triggering the backdoor
• Installation - installing the backdoor as a bootstrap and any additional remote access tools
• Command and Control - use of the tools to establish remote access
• Actions on Objectives - collecting and exfiltrating information, or other actions against the target

The time to start collecting more information about your network, servers and systems is a couple of months before someone exfiltrates your customer database

By breaking the chain of causality at any point, we avoid the consequences of the subsequent non-events. That's a very powerful concept! And it really argues strongly that our intuitive response to computer security is pretty common sense: doing whatever we can at the early stages of the sequence of events saves us grief later; we are right to put most of our effort into our front-line defenses. Think about it this way: if your anti-virus software is even only 50% effective, that wipes out 50% of the potential problems you might have to deal with later on – at much greater cost.

The cyber kill chain is also a good model for explaining to management why you might want to front-load your blocking efforts. As we look at each stage of the kill chain, we can talk about the various technologies that are available to us and the cost of failure and response at that stage.

Significance of Failure

It's useful to point at this table and say, “We want to do a few things here, so that we don't get there.”

This also segues nicely into an analysis of what we can do to prepare for things going wrong at each stage of the kill chain. Some of the conclusions may seem a bit counter-intuitive but they're actually more important for all that:

Preparing for Trouble

I've often talked to IT professionals who turn off audit trails and logging on the grounds that they're not going to have time to do any analysis against it so there's no point collecting it. But kill chain analysis tells us that we might need data that can only be collected in advance of something going wrong. The time to start collecting more information about your network, servers and systems is a couple of months before someone exfiltrates your customer database, because (hopefully) you'll have a better chance of figuring out what happened so it doesn't happen again, and so you can shorten your disaster response cycle. If you end up having to call in consultants to unwind a disaster response, you may be able to cut a few zeroes from the right side of their invoice. So even if your ground reality is that you're not going to set up a complete system log analysis capability, you may want to do a needs analysis for tools that you should pre-position, so that they are there when you need them. That's when not if.

By breaking the chain of causality at any point, we avoid the consequences of the subsequent non-events

A complete network monitoring approach is crucial for reining in the time spent dealing with incidents, by providing traffic data and log information, as well as helping detect and track initial outbreaks as they occur. Part of what makes this a hard problem is the need to search backward and forward in time: when you detect that something has gone wrong now, you need to be able to go back in time to see how it happened then, and figure out what else happened between then and now. You stress every aspect of your system, from prevention at endpoints to vulnerability management, up through malware detection, log and event correlation. A product like Tenable’s SecurityCenter Continuous View™ can provide all this functionality. See Ron Gula’s blog post on Identifying the Weakest Links in Cyber Kill Chains for more detail about SecurityCenter's metrics and kill chain dashboards.

The final place where you can use the kill chain model is as an abstract framework for training and assessing your organizational readiness. At each stage of the kill chain, you can hypothesize a reasonably realistic failure, and do a paper-drill assessment to compare your capabilities against what you might want. Don't make the process adversarial; use it as a way of moving into a gap analysis. For example, consider a hypothetical case: one of the engineers left the company and may be going to a competitor (he’s acting squirrelly). Some reasonable questions to ask about this scenario are:

• Do we have any capability to tell if the engineer took source code?
• Do we have the ability to retrieve a list of files the engineer may have taken in the last 30 days?

Both of those questions might be answered with improved logging on some servers; check and see whether you currently collect enough information. If you walk through a plausible scenario like this one, it will help you define what you think are reasonable expectations and capabilities — you might decide you need even tighter data controls than just improved logging. But if you just decided a few years ago that “our firewall logs are pretty good,” you may now realize that's not enough.

Walking through a few paper-drill assessments lets you go back to management with some plausible scenarios that aren't FUD (fear, uncertainty and doubt); they're based on “if:then” scenarios and you can reasonably explore the trade-offs that are exposed.

In a previous life, I did incident responses on some fairly significant breaches. When you're called in to help fix a disaster, one characteristic always emerges: many wrong decisions were made in the past. After all, you don't get called in as an incident response consultant by organizations that have top-notch configuration management, network access tracking, server logging, and tamper detection. If you asked, “Do you have the firewall logs?” the response would typically be, “Uh, some of them.” It's a truism that there's never enough data, and the reason that it's true is exposed by kill chain analysis. Eventually you may find yourself in a state where you lack the critical information you need in order to go further. Then what?

¹ CYBER KILL CHAIN is a registered trademark of Lockheed Martin Corporation.