Intro
If you're reading my blog, you're probably already familiar with the Kill Chain (KC). Briefly, it's a generalized model of the stages an adversary has to go through to carry out a targeted attack. It's been around for several years now, and just seems to become more popular over time. It's a great model that captures a complex subject and presents it in a simple way. I'm a big fan.I've been thinking recently about the process that we as defenders have to go through to protect our networks against attacks (targeted or otherwise). Many papers and articles have been written on the subject, and most of us probably know the highlights: we make policies, we enforce the policies using both technical and non-technical means, we monitor our networks and we respond to incidents. The process is actually quite complex, though, and I began to think of how I would create a model to show it visually.
After a bit of pondering, it struck me that I was essentially trying to create the defender's counterpart to the Kill Chain. That is, we already know the stages an attacker has to go through to carry out an attack; now we need a model that shows the stages a defender must go through to protect against these attacks. One of the reasons the KC is so popular is that's it's very straightforward. I mean, literally, it's a line. So I thought, what would it look like if I applied it to defense?
The Defense Chain
The result is what I (rather clumsily) termed, "the Defense Chain" (DC). |
| The Defense Chain |
Let's examine the phases in more detail.
Plan
Before you can begin to protect your network, you first must figure out some key things, like what exactly you wish to protect, and what you're trying to protect it from. In the Plan phase, you do things like identifying your assets and creating your security and incident response policies to help protect them. This is also where you begin to decide what types of protective controls you will need (firewalls, endpoint protection, network proxies, etc), how you will deploy them, how you will monitor the entire system (because prevention always fails), and who's going to do all this work.
If you've ever been involved in the creation of a security program before, you'll know there are a lot of things to plan here. So many things, in fact, that I'm not even going to try to list them all. Just know that the planning phase is probably the most important piece of the Defense Chain, because everything else depends on it.
Build
Compared to planning, building is often fairly straightforward. During this phase, you assemble teams, learn skills and create or acquire the technical tools necessary to carry out your plans.
Did you catch what I just did there? It's vitally important that you build teams and skills *before* you try to build the technical parts of the solutions. Not everyone needs to be an expert, though you certainly need a few of those to guide you, but everyone involved needs to have enough of a background to know what they're doing and why they're doing it.
It's also worth pointing out that the "Build" phase isn't something you just do one time and then forget about it. Rather, you should be constantly growing your teams' skills and experience. You also need to have someone looking over your controls to be sure they are operating efficiently, and to update and improve them as needed.
Monitor
The monitor phase is where you actually operate the technical solutions and perform periodic reviews and drills to exercise your policies and plans. This could include just making sure the endpoint security solution you chose is working well, ensuring that packet loss on the NSM/ESM systems is within acceptable levels, or running table top incident response exercises to make sure everyone knows what to do.
This phase is probably where you spend the majority of your time.
Detect
I probably don't need to explain this phase much to my readers. The detect phase is where you check the output of your NSM/ESM systems, validate the alerts or do some proactive hunting through the data to find evil. This could also include fielding user queries about "weird" things on their computers or suspicious emails they received.
Respond
This is another phase I probably don't have to explain much here. Once you have found evil, you need to exercise those incident response plans you developed in the Plan phase. Investigate, contain and remediate! Kick out the bad guys and bring the affected assets back into normal operation.
Report
The Report phase is all about gathering information about your successes and failures, analyzing it to make recommendations for improvement, and communicating this to the right people. Typically, reporting is a followup to an incident response, but you would also do this for other reasons (e.g., to review a red team engagement or an auditors' findings).
Not everything is a formal report, either. Sometimes your "report" might be a presentation, a post to an internal blog, or even an email. The key is that you communicate findings and recommendation to the right people in whatever way makes it easiest for them to digest the information.
Improve
Security programs are not static! You need to constant improve you skills, your tools and your procedures to keep ahead of the bad guys. That's what this phase is all about. After the successes, failures and recommendations have been documented and reported, you need to make sure you act on them. So many organizations skip this step, and although it might make less work in the short term, it makes more work in the long term as they play keep-up with threats that have advanced beyond the organization's ability to protect themselves.
Conclusion
There you have it. In 10 minutes or less, my thoughts on a model of how an organization successfully defends itself against attacks. I don't claim that the Defense Chain model really contains anything new. Rather, I hope to just provide a simple visual guide to all the things you need to do, in rough order, and layed out in a way that makes it easy to visualize how all the phases flow and work together.
I know my readers deal with these sorts of things every day. Please, leave a comment below to let me know what you think. I'm eager to hear comments, questions and criticisms!
So, does it mean the attacker gets to interrupt it, just like the defender gets to cut the kill chain?
ReplyDeleteGood question. I think that's where the similarity breaks down a bit. The Kill Chain is a model of an individual attack, so the defender has the chance to disrupt that attack. Although the attacker can try again, of course, so it's as though the defender has parried on thrust, but the fencing match continues.
DeleteHowever, if you reverse the roles, it's different. The Defense Chain is more of a continuing process than an individual action, so it's difficult to interrupt. I think disrupting the DC would be more of a catastrophic event. Certainly we have seen this before (HBGary being unable to continue operations, for example) but it's pretty rare.
I think a better way of looking at it would be that the attacker doesn't disrupt the entire Defense Chain, but instead circumvents some part of it to allow their attack to be successful.
Now what seems like a REALLY interesting question is "What methods could an attacker use to circumvent each stage?" Most of the traditional attacker toolkit is oriented towards the "Monitor" (send exploits against production systems), "Detect" (stealth and evasion) and "Respond" (persistence) phases. What could they do, for example, against the "Plan" or "Build" phases?
>Now what seems like a REALLY interesting question is "What methods could an attacker use to
Delete>circumvent each stage?
Exactly -- this is what I thought of first. How can an attacker counter each stage?
One thing often not talked about is attackers going directly after your monitoring tools. Take a SIEM offline, or with stolen credentials remove access, etc...
DeleteGood point, Anonymous. When I hear of people doing their NSM monitoring via SPAN ports, my first thought usually isn't "Oh, you're going to oversubscribe your port and miss packets" (though it probably should be). Instead, I think, "Sweet! The attackers get to turn that off for you!"
Delete>> "Sweet! The attackers get to turn that off for you!"
DeleteI would love it if an attacker could give me 100% acknowledgement of their presence by disabling a SPAN port!
>> One thing often not talked about is attackers going directly after your monitoring tools. Take a SIEM offline, or with stolen credentials remove access, etc...
We don't often talk about threats with minimal risk in this community. There are too many other important issues to juggle.
With good monitoring, I'd hope that having a SPAN port go down wouldn't be your first indication of trouble anyway. That's *if* the port goes down. An attacker worried about stealth could just reconfigure it to leave out the traffic they generate, so the attached sensor won't do anything as obvious as going completely dark.
DeleteYou may think this is an unlikely scenario, and perhaps you would be correct. As a detection guy, I'm always aware of the holes in my detection strategy, and worry about them being exploited. Also, having had experience chasing skilled, determined attackers around a large enterprise, I can say for certain that this type of activity is well within their capabilities.
At a certain point, if your ability to monitor their activities begins to hamper an adversary's actions, your monitoring infrastructure is more likely to become a target. Defend it.
Nailed it! Thanks.
ReplyDeleteThe notion of "prevention always fails" needs an update in my opinion. How about "prevention always fails, but better prevention fails far less often"? Thinking about it a bit, comprehensively outlining what better prevention really means sounds like a rather large topic.
ReplyDeletePlanning can be easier if you are more aware of what is likely to break, or be used against you. For starters, to focus your efforts, do you know the top 3 ways your organization gets breached? No, how about organizations in your industry? For example, think breaches of internet-facing assets, watering holes, and phishing. Within each of those 3 categories, do you know exactly how those breaches are happening, and why? Can you name the top X ways your internet-facing assets or Windows clients get breached for the past Y years? What CVEs or techniques were used, and why did those work? Usually the fixes aren't rocket science, but might take considerable effort to address or roll out.
There does seem to be some pillars or foundational concepts that really work for prevention and defense. It seems that they (e.g. patching, least privilege, multi-factor auth in the right spots, smart use of crypto, network segmentation, etc) lack enough sex appeal to get adequate coverage.
@sharpesecurity
@sharpesecurity, you're exactly right. Better prevention fails less often. It's definitely worth doing all you can to prevent incidents in the first place. Your IR team is the *last* line of defence, not the first!
DeleteAlso, when you talk about planning, it sounds to me like you're saying that planning should be informed by both friendly intelligence (information about your own environment and IR history) and threat intelligence (who your adversaries are, what they want and how they go about getting it). Couldn't agree more!
>"prevention always fails, but better prevention fails far less often"
Delete"prevention always fails, but better prevention is more expensive and thus fails more expensively"