Guest author Jason Holcomb is a Digital Bond alumnus who is now a Senior Security Consultant for Lockheed Martin’s Energy and Cyber Services group where he is responsible for providing critical infrastructure security consulting services and integrating ICS security intelligence into the Palisade TM product line.

As a global security company, Lockheed Martin is the target of a broad array of cyber attacks ranging from nuisance-level probes to targeted, sophisticated intrusion attempts by well-trained and organized adversaries. The LM-CIRT manages security events on the company network that spans all 50 states and the globe. To gain an advantage over our adversaries, the LM-CIRT developed the Cyber Kill Chain, a set of sequential events that make up an advanced attack. The idea is to understand the discrete steps that an attacker must progress through to meet their objectives. Of course when I learned about the Cyber Kill Chain [pdf] my first inclination was to examine it in the context of Industrial Control Systems (ICS) to determine what is applicable or what we can learn from it. So that will be the goal in this series of posts.

To start things off, let’s look at exactly what makes up the Cyber Kill Chain. The figure below illustrates the concept and gives a brief explanation of each step.

ICS Security

Perhaps you have heard the old adage that the attacker only has to be right once but the defender has to be right every time. The Cyber Kill Chain disputes this concept and enables a defender to identify and learn from each phase of the attack. For an attacker, there is cost associated with changing the tools and techniques used in the various phases. So even if the exploit is different or a 0day is used, there is high likelihood that the tools and techniques used in other phases will remain the same.  As a network defender, identifying this puts the advantage back in your court. There is something to learn from each phase – you can examine each step to determine if your defenses are adequate. This may include exercises like sandboxing the exploit or malware to learn more about how it works. If you have a “Late Phase Detection”, you look at earlier phases to find indicators. If you have an “Early Phase Detection”, you look down the chain to learn more about the attacker’s methods and objectives. This is where you can really start using the Cyber Kill Chain concept to your advantage and tuning your defense in depth strategy accordingly.

For ICS, the Cyber Kill Chain allows you to use intelligence from all your company networks and enables you to start asking questions such as:

  • What delivery mechanisms are possible for the ICS network?
  • Will my current defenses prevent or even detect the exploitation or installation phases?
  • What outbound communication could be used as a command and control channel?

Better to answer these questions now than to have an innovative adversary answer them for us.  Unfortunately, many ICS networks are not currently in a position to detect or prevent an attack that makes it to the delivery phase of the Cyber kill Chain. Attack indicators all throughout the phases may go unnoticed. Most ICS networks still rely heavily on perimeter defenses and often do not have the capability to see what is really happening on the network from a security perspective – a concept I like to call “security visibility”, or lack thereof in most cases.

When performing security assessments, I look at different attack scenarios and ask the question “what is the most likely path an attacker could use to compromise this network?” One of the common scenarios is a recursive cycle of the Cyber Kill Chain – a malicious actor successfully executes the attack process on the business network and then starts again at the reconnaissance phase and makes their way into the ICS. This enables you to analyze how different security controls mitigate the risk of this attack and help the asset owner understand why a particular un-patched server in an ICS DMZ is so dangerous. And that’s just the business network attack path – perhaps more interesting is how an attacker can be creative to get to the delivery phase of the Cyber Kill Chain for ICS.

One remaining question is whether the kill chain steps could be different for ICS. For example: Are the phases different if an exploit or malware is not needed for an attacker to act on their objectives, perhaps using unauthenticated protocols? Certainly the defense implications for these phases would change in this scenario. Even so, my opinion on the Cyber Kill Chain is that we can indeed learn from and apply it to ICS. If nothing else, we can use it as a reference to help measure security visibility but I think there is applicability and benefit beyond that as well using an intelligence-driven security approach.

Stay tuned as we continue to explore the Cyber Kill Chain over a series of posts looking at how we can increase security visibility, what might be different in an “ICS Cyber Kill Chain”, and perhaps even a case study based on the kill chain steps.


Guest author Jason Holcomb is a Digital Bond alumnus who is now a Senior Security Consultant for Lockheed Martin’s Energy and Cyber Services group where he is responsible for providing critical infrastructure security consulting services and integrating ICS security intelligence into the Palisade TM product line.

In Part 1 of this series we introduced the Lockheed Martin CIRT Cyber Kill Chain and examined whether there was something useful to be learned from it for ICS networks. In that post we concluded that there was applicability but questioned how the phases may be different in ICS.  This post goes step-by-step through the first three phases (Reconnaissance, Weaponization, and Delivery) and attempts to answer that question. For each phase we’ll provide the definition taken from the Hutchins-Cloppert-Amin paper and then examine it in the context of an ICS attack.

Reconnaissance – Research, identification and selection of targets, often represented as crawling Internet websites such as conference proceedings and mailing lists for email addresses, social relationships, or information on specific technologies.

The sources of information may differ slightly for ICS but the concepts still apply. This step is invisible most of the time but here are two potential detection mechanisms for the reconnaissance phase related to ICS:

1.)   Web Analytics – How aware are you of search engine referrals that land at your company’s public-facing web site? How about searches on the site itself? And to take it even a step further – what about searches on your intranet? If you see terms related to SCADA, your vendors, or system information, it may be worth taking that data (IP, user agent strings, etc) and correlating across other Cyber Kill Chain steps. This is information that most corporate IT teams can easily extract.

2.)   SCADA Honeynet – The SCADA Honeynet Project can function as a “canary”, an early warning that an attacker is conducting online reconnaissance activities. The SCADA Honeynet simulates ICS protocols and interfaces and can be used to detect attempted attacks beyond the reconnaissance phase as well.

Weaponization – Coupling a remote access trojan with an exploit into a deliverable payload, typically by means of an automated tool (weaponizer). Increasingly in IT environments, client application data files such as Adobe Portable Document Format (PDF) or Microsoft Office documents serve as the weaponized deliverable.

I don’t see a lot of difference for ICS in this phase but do have this observation: most current tools and techniques make the control center systems (HMIs, Historians, Engineering Workstations, etc) more of an initial target than the field devices. It’s not that exploiting at the device level isn’t possible – several recent events such as Boreas, Stuxnet, and the Beresford Siemens vulnerabilities clearly show that there is an opportunity at the PLC level. It’s just that, for this phase, the servers and workstations are an easier target for a weaponized payload such as a PDF file. Attacking the PLCs and IEDs is likely a subsequent action but may or may not be required to meet the attacker’s objectives.

Delivery – Transmission of the weapon to the targeted environment. The three most prevalent delivery vectors for weaponized payloads by APT actors, for the years 2004-2010, are email attachments, compromised websites, and USB removable media.

Here is our first significant difference for ICS. Very few ICS networks allow email or web browsing so those mechanisms are not likely for a direct delivery; however, they could be used to get to the business network where the attacker can attempt to move laterally and/or repeat the kill chain phases iteratively to gain access to the ICS.

USB, on the other hand, is a viable delivery mechanism for ICS based on our observation and the Stuxnet precedent for ICS. This is the most likely delivery mechanism for a non-iterative, direct ICS attack. A topic that I find increasingly interesting is the idea of a physical compromise as the delivery mechanism – e.g. manual insertion of the payload by accessing an unmanned remote location. The objective for this type of attack may not even be related to the control system, the ICS network may just be a conduit for accessing more lucrative information on the business network.

Since performing security assessments for ICS networks on a regular basis, I have strongly held that analysis of attack scenarios is a good way to help validate security controls and supplement traditional compliance and assessment activities. Keep in mind, however, that attack scenarios and the Cyber Kill Chain focus on intentional attacks, which are just one of many risks that should be considered when securing an ICS network. You still need all the foundational elements of a good security program – strong policies and procedures, technical controls, physical security, etc.  The Cyber Kill Chain does not replace these foundational security elements but it can clearly lend additional perspective and be a central part of an intelligence-driven security approach for any network, including ICS.

Image by rochdale