Attacks/Breaches

12/2/2014
10:30 AM
Sean Mason
Sean Mason
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Leveraging The Kill Chain For Awesome

There are good reasons the Kill Chain is being used by some of the most successful information security teams around. Here are three.

I first learned about the Kill Chain when I was working with the organization known as the Defense Industrial Base, made up of the largest US government contractors. I recall a briefing we had on the KC, and when I went back to work the following week, I was frantically drawing the KC model on my whiteboard and exclaiming to co-workers that it was the greatest thing ever… but I didn’t know why.

The reality was, we were in our infancy as a security operations center and incident response team, let alone as a security organization hit with the new realities of the cyberworld. As such, we were just learning what others, like Lockheed Martin, had considered fundamentals by that point. It would be a couple years later, when I had moved on and my current team was looking to evolve our internal SOC and IR processes, that I truly saw the power of the Kill Chain. Let’s discuss three awesome ways to use the KC.

Detection
When it comes to enterprise detection, the Kill Chain is useful for understanding what your capabilities are, as well as your gaps in coverage by tools and threat actors. Simply put, not all detection tools are able to detect on all indicator types, nor are they able to cover all steps in the KC.

Step 1: By first laying out all of the indicator types by KC phase, you begin to paint a useful picture.

Step 2: By identifying which indicators can be used by each tool, by KC phase, you understand the capabilities of each tool.

Step 3: Aggregating together your detection tools will give you a holistic view of where your gaps lie or, in many cases, overlap. For example, you may find that your organization is only capable of detecting adversaries during KC7 Actions on Objectives and/or perhaps have zero visibility into KC3 Delivery. Among other things, understanding your capabilities at such a granular level can help you focus investment spend properly.

Step 4: Finally, by performing the same exercise by threat actors, you can better understand the visibility gaps and seek out intelligence to successfully plug those gaps.

Post-Incident Analysis
I’ve seen many different flavors of post-incident meetings over the years. Most are nothing but organized chaos where countless things are thrown around, and a decision is made to purchase some technology perceived as a panacea so that the incident won’t happen again. While some usefulness may come of that meeting, where I’ve seen post-incident reviews excel is by leveraging the Kill Chain model to systematically break down the attack. Using the KC as a framework to answer questions as to how the attack played out, and dissecting each step for what the adversary did and why it worked, may provide a wealth of understanding of the attack, the actor, and what should be done afterwards.

Communication
Have you ever tried to explain to the C-suite how an attack happened? It can be challenging. However, the Kill Chain offers a simple and powerful way to look at a very complex situation and tell a story. In a world driven by PowerPoint presentations, you can easily explain the concepts of the KC in terms that everyone will understand, without getting technical, and follow a linear approach to explain the details of the attack to your audience. While I don’t fully agree with the example below, here is a real-world use case that shows how powerful the KC can be to explain the complex Target breach to US Senators, an audience that would have very little technology background.

(Source: 'A 'Kill Chain' Analysis of the 2013 Target Data Breach,' March 26, 2014; US Senate Committee on Commerce, Science, and Transportation)
(Source: "A 'Kill Chain' Analysis of the 2013 Target Data Breach," March 26, 2014; US Senate Committee on Commerce, Science, and Transportation)

Detractors
Detractors of the Kill Chain (see Deconstructing The Cyber Kill Chain) will generally state two things: It can’t be used to look at issues other than external attacks, and since a lot of things happen during KC7 Actions of Objectives, it is too broad. While technically correct, the Kill Chain provides a solid and proven framework that can be augmented to fit different use cases. In the case of an insider breach, an employee would perform internal “Reconnaissance,” “Exploit” control weaknesses, possibly “Install” software, and most definitely look to achieve the “Actions on Objectives.” As for the argument that KC7 is too broad, I’ve seen teams take liberties with KC7 and enhance it with a few sub-steps for even deeper granularity.

There is a reason the Kill Chain is being used by some of the most successful information security teams around. It is a powerful tool for any security organization that is able to harness its true potential and resolve highly complex attack scenarios. Like any tool, though, it can and should be modified as appropriate to fit an organization's specific needs.

Sean Mason is the Vice President of Incident Response for Resolution1 Security. After serving his commitment to the US Air Force, he has spent his career with Fortune 500 companies (GE, Monsanto, Harris & CSC) where he has worked in a variety of IT & industry verticals, ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
12/4/2014 | 7:58:28 AM
Kill Chain controversy
I was surprised at how passionate supporters and detractors of the Kill Chain are in their views! Any thoughts on why that is? 
WebAuthn, FIDO2 Infuse Browsers, Platforms with Strong Authentication
John Fontana, Standards & Identity Analyst, Yubico,  9/19/2018
Turn the NIST Cybersecurity Framework into Reality: 5 Steps
Mukul Kumar & Anupam Sahai, CISO & VP of Cyber Practice and VP Product Management, Cavirin Systems,  9/20/2018
NSS Labs Files Antitrust Suit Against Symantec, CrowdStrike, ESET, AMTSO
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-7907
PUBLISHED: 2018-09-26
Some Huawei products Agassi-L09 AGS-L09C100B257CUSTC100D001, AGS-L09C170B253CUSTC170D001, AGS-L09C199B251CUSTC199D001, AGS-L09C229B003CUSTC229D001, Agassi-W09 AGS-W09C100B257CUSTC100D001, AGS-W09C128B252CUSTC128D001, AGS-W09C170B252CUSTC170D001, AGS-W09C229B251CUSTC229D001, AGS-W09C331B003CUSTC331D0...
CVE-2018-3972
PUBLISHED: 2018-09-26
An exploitable code execution vulnerability exists in the Levin deserialization functionality of the Epee library, as used in Monero 'Lithium Luna' (v0.12.2.0-master-ffab6700) and other cryptocurrencies. A specially crafted network packet can cause a logic flaw, resulting in code execution. An attac...
CVE-2018-17538
PUBLISHED: 2018-09-26
Axon (formerly TASER International) Evidence Sync 3.15.89 is vulnerable to process injection.
CVE-2018-11763
PUBLISHED: 2018-09-25
In Apache HTTP Server 2.4.17 to 2.4.34, by sending continuous, large SETTINGS frames a client can occupy a connection, server thread and CPU time without any connection timeout coming to effect. This affects only HTTP/2 connections. A possible mitigation is to not enable the h2 protocol.
CVE-2018-14634
PUBLISHED: 2018-09-25
An integer overflow flaw was found in the Linux kernel's create_elf_tables() function. An unprivileged local user with access to SUID (or otherwise privileged) binary could use this flaw to escalate their privileges on the system. Kernel versions 2.6.x, 3.10.x and 4.14.x are believed to be vulnerabl...