Proactive defense as a cybersecurity first principle using adversary playbooks
Have you ever come across an idea to solve a problem that was so crystal clear in your mind, that it was such an obvious step to take to eliminate an obstacle, that you just knew that as soon as people heard about it, adoption of it would be swift and unambiguous and we would all move on to the next thing?
- Don’t iron the shirt you are wearing.
- Never draw to an inside straight.
- Never get involved in a land war in Asia.
- Take the Covid 19 vaccine.
- Throw 25 years of cybersecurity best practices away in favor of first principles
And then later, you’re shocked that the entire world hasn’t followed your lead?
I run across a lot of these ideas in my line of work, as I'm sure you do, too. And I’ve generated a few myself over the years. I’ve run global SOC operations for several companies in my career, and I’ve always asked my boss to move operations to Key West, you know, for reasons. But I refuse to give up on a couple of joint concepts called “proactive defense” and “adversary playbooks.” They represent the idea that instead of attempting to block each individual tool that bad guys use to break into our networks as the network defender’s ultimate objective, we instead build proactive defensive plans designed specifically to defeat the goal of whatever the bad guys are trying to accomplish. We do that by building adversary playbooks for all known adversary campaigns and use them to facilitate the automation of collection, sharing, and distributing of prevention controls to our security stacks.
Proactive defense origin.
When I'm learning something new, I find it useful to understand the history of the thing. It allows me to grasp why the idea exists, the changes made to the idea over time, and then I can understand why we are in the current state. So permit me a little history lesson.
I was the Palo Alto Networks CSO from 2013 until 2019. One of the first tasks that the CEO, Mark McLaughlin, gave me was to build, from scratch, a public facing intelligence organization that we eventually named Unit 42. The guy that I hired to run that organization is Ryan Olson, who is still working there as Vice President of Threat Intelligence.
As I’ve mentioned in previous essays and podcasts, the intelligence process is straightforward. You decide what intelligence questions you need answered, collect information that might help you answer those questions, create intelligence products that attempt to answer those intelligence questions with the information you collected, and then seek feedback from your customers as to whether the answers were satisfactory. Rinse and repeat. It’s not called the intelligence lifecycle for nothing.
As Ryan and I were deciding what Unit 42 was going to do, we had to describe in detail the intelligence questions that the new group was going to tackle. We quickly arrived at the concept of adversary playbooks. Although it took us many years to describe them in a way that wasn’t confusing to the non-initiated, the general concept at a high level was a no-brainer.
Flashback: the genius of the original intrusion kill chain paper.
Ryan and I are fans of the 2010 Lockeed Martin Intrusion Kill Chain paper. It outlined a fundamental shift in defensive strategy. Before publication, most network defenders deployed a general purpose defense-in-depth architecture that was passive. We installed common prevention and detection schemes that we designed to impact classes of attack tools like specific malware or phishing techniques. We layered them in our architecture so that if the first tool deployed failed, the second tool would kick in. If that one failed, then the third one would step in, on and on, with turtles all the way down or until we ran out of tools. By passive, I mean that the prevention controls deployed didn’t focus on defeating any specific bad guy. They were general purpose tools designed to defeat “any” adversary, like a fence that keeps everybody out, like an old firewall rule that blocks all ports except port 80, like blocking a common tool that many bad guys use like Mimikatz. We didn’t actively design them to block any specific operators and the techniques that we knew they were using at every stage of the attack sequence.
The genius of the kill chain paper was the realization that blocking general purpose bad guy tools was not the defender’s ultimate objective. Doing that is important, obviously, but the first principle goal was to prevent the success of the adversary's campaign. For over twenty years, the network defender community had been operating under a perceived conventional truism. As Peter Mackenzie and Tilly Travers (both from Sophos) described it in 2020, “The standard cybersecurity maxim is that defenders need to be right all the time [meaning they have to block all of the bad guy tools], while an attacker only needs to be right once [use one tool that isn’t blocked].”
With the kill chain paper, the Lockheed Martin researchers flipped that maxim on its head. The typical adversary attack sequence might contain anywhere between 30 and 300 steps depending on how complicated the campaign is. The attacker has to deploy each of those steps correctly and precisely. No mistakes can be made. If the defender can disrupt any of those steps, they have successfully broken or “killed” the intrusion sequence or “chain.” That makes it possible for defenders to design defensive plans specifically to prevent the success of known attack campaigns from the likes of the
- N3tw0rm (hacktivism)
- APT40 (cyber crime)
- BlackMatter (Ransomware)
or nation state actors like
- Stone Panda (China)
- Cozy Bear (Russia)
- the LAZARUS Group (North Korea)
- Charming Kitten (Iran)
- Equation Group (United States)
In other words, you just don’t deploy a prevention control for a newly discovered piece of malware. You deploy a series of controls designed to stop the entire attack sequence of a known adversary campaign. This leverages the attacker’s common practice of not replacing entire attack sequences when they improve their code. Typically, they upgrade a piece of it somewhere along the kill chain. The benefit to the defender is that even if the attacker installs something new that you have no protections for, like a zero day exploit, the other defensive controls already deployed in other areas along the kill chain (like delivery, command and control, lateral movement, and exfiltration) will prevent the success of the adversary campaign.
Like I said: genius.
Adversary playbooks, Unit 42 and the Cyber Threat Alliance.
As Ryan and I were building Unit 42, we decided that the main question the team would be answering is, what are the attack campaigns for all active bad guy groups? We called that collection of campaign intelligence “adversary playbooks” and it was purely an effort to make the Palo Alto Networks’ product more effective. As with other orchestration platforms from Checkpoint, Cisco, and Fortinet, Palo Alto Networks offered a way to block cyber adversaries across multiple points on the intrusion kill chain. The trick for Unit 42 was to establish the initial adversary playbook for all active campaigns, keep them up to date when changes happened, and deploy them into the backend Palo Alto Networks infrastructure that automatically creates prevention controls for the product line and delivers them to the customer in real time. Ryan and I quickly realized that even with a large intelligence team, doing this intelligence work manually was never going to cut it. We needed automation.
About the same time, the Fortinet CEO, Ken Xi, made a handshake deal with my boss to establish the first ever ISAC (Information Sharing and Analysis Center) for security vendors that eventually turned into the Cyber Threat Alliance. Mark turned to me, handed me this dripping bag of chaos and distrust (because, you know, security-vendor-competitors are famous for loving each other), and told me, “don’t let this fail.”
As a group, the members of the Cyber Threat Alliance decided to distinguish themselves from what other ISACs were sharing by rethinking the intelligence sharing paradigm. Instead of sharing intelligence in formats like PDFs and spreadsheets that humans had to read, they instead agreed on a format for the security vendor community that facilitated the automation of every vendor’s back end architecture, their ability to create prevention and detection controls for their own products. The Cyber Threat Alliance agreed on a subset of STIX (Structured Threat Information Expression) that had become the de facto standard for the community on storing threat intelligence.
Ryan and his Unit 42 developers built the first beta version of the sharing platform. Palo Alto Networks made it open source and gave it to the now not-for-profit Cyber Threat Alliance. Since then, the Cyber Threat Alliance has evolved the platform to version 2.X, called Magellan, and the system of automatically sharing threat intelligence amongst security vendors has been running for several years now.
What is an adversary playbook?
At a high level, an adversary playbook consists of several intelligence components. First, it represents an acknowledgement that cyber adversaries are not robots. People are behind the design of each and every attack campaign trying to accomplish some goal. But, an adversary playbook is not about attributing the campaigns to actual people or organizations. For example, it’s not important that we know that a specific attack sequence originated from the Russian General Staff Main Intelligence Directorate (GRU). It’s interesting for sure, but that kind of attribution doesn’t help the commercial, academic, and most government network defenders prevent the success of the campaign. I mean, what do you do with that information? That kind of attribution is best left to government intelligence agencies who might be able to determine it with some confidence and also do something with it once they do. For the rest of us, what is important is giving names, like Fancy Bear, to the group behind these observable and repeating patterns. We do this because the kinds of attack sequences that Fancy Bear uses are not the same as the kinds of attack sequences that say Wicked Panda or Charming Kitten or the Lazarus Group uses. Sometimes they overlap with a common tool but the entire attack sequence is generally not the same.
Second, the adversary playbook recognizes that any particular group might run more than one attack campaign. As I said earlier in the essay, for the most part, adversary groups don’t run completely distinct attack sequences. In other words, groups like Sandworm don’t typically run campaign one with a sequence like A-B-C-D-E and campaign two with an entirely unique attack sequence like V-W-X-Y-Z. Campaign two is more likely to be A-B-Z-D-E, a tweak to campaign one. This is not always true but it’s common.
Third, the adversary playbook uses a standard language to describe each step in the attack sequence to facilitate collection, sharing, and prevention control distribution. At Unit 42 and the Cyber Threat Alliance, they have agreed to use the naming conventions in the MITRE ATT&CK® framework and to store that intelligence with the STIX standard.
Current state of proactive defense and adversary playbooks.
I left Palo Alto Networks in 2019 and my influence over Unit 42 and the Cyber Threat Alliance stopped there. Before I left, Ryan and I published our current thinking of the proactive defense and adversary playbook concepts in a white paper published in the fall 2020 edition of “The Cyber Defense Review” distributed by the Army Cyber Institute.
If I do say so myself, the paper is really good (see below for the link to the paper). Unfortunately, the idea hasn’t caught on. Palo Alto Networks has moved away from the idea and has never really implemented the concept in their products. Unit 42 still collects intelligence on adversary campaigns but the Palo Alto Networks product set doesn’t organize their threat protection against known adversaries. They still organize around blocking and detecting technical tools and techniques with less regard to what the adversary is doing across the kill chain.
The same goes for the Cyber Threat Alliance. Members are required to share a minimum volume of intelligence everyday and have a fully functioning automated sharing platform designed to collect and share adversary campaigns. They mostly only share intrusion kill chain indicator-of-compromise artifacts with no relation to the adversary campaign: malware hashes and samples, URLs, IP address, ports, mutexes, email headers, plus other network traffic indicators. That’s not a bad thing. It just stops short of the original vision. That also means that the Cyber Threat Alliance members haven’t embraced the proactive defense / adversary playbook model either. Palo Alto Networks isn’t the only one. Check Point, Cisco, Fortinet, and the other thirty-two members are still doing it in the old passive defense-in-depth way. Don’t get me wrong. Automated sharing between security vendors is still way better then every one of their collective customers trying to do it manually on their own. At least this way, each vendor is automatically generating product protections for their customers with the new intelligence.
Still the right idea.
If you’re reading this, you’ve probably already bought into the general idea that intrusion kill chain prevention is a viable first principle infosec strategy. You may not have deployed it yourself, but you see value in the proactive defense idea. It’s one thing to agree to a principle though. It’s quite another to put into practice. When Ryan and I started down this path in 2013, it took us a while just to get our heads around what needed to be done. And then, it took even longer to build something close to what we needed. Adversary playbooks may not be the perfect solution that we need for deploying an intrusion kill chain prevention strategy, but there is nothing else out there right now that can operate at scale. If you are looking to pursue this idea, adversary playbooks are the path. And the thing is, we are so close. It wouldn’t take much to bump the security industry in this general direction.
What needs to be done?
It starts with you. Begin organizing your own threat intelligence around the idea of proactive defense and adversary playbooks. Start with one adversary group and work up from there. At the end of the day, you are looking for several working components:
- What are all the controls deployed for every data island that you maintain designed to thwart the cyber crime adversary group called Fin11?
- Automate the process of collecting new threat intelligence on FIN11 and have analysts regularly review the collection for the purpose of deploying new proactive controls.
- Automate the process of deploying newly designed FIN11 controls to the security stack on every data island.
Next are the vendors. They aren’t going to get there on their own unless there is a consensus built within their customer base. Apply pressure on them. At every opportunity, ask them why they don’t have this capability. They should be able to tell you that, for the products that you have installed from them, here is a list of the security controls across the kill chain for the likes of N3tw0rm (hacktivism), APT40 (cyber crime), BlackMatter (Ransomware) and all of the nation state groups. If you find a vendor that is leaning in the right direction, buy them and kick every other vendor out that refuses to even consider the idea. Also, pressure the vendors that supply your current security stack to join the Cyber Threat Alliance. Threaten to drop them if they don’t. This makes the entire community safer.
Don’t forget your industry’s cyber intelligence sharing organizations: the ISACs (Information Sharing and Analysis Centers) and the ISAOs (Information Sharing and Analysis Organizations). Encourage them to build the automation that will allow them to share threat intelligence with other iSACs similar to the Cyber Threat Alliance model. Better yet, encourage them to use the Cyber Threat Alliance as the hub for all sharing between ISACs. I know that we all have issues with helping vendors. But that’s not what this is about. This is about deploying security controls around the world as fast as possible for any newly discovered threat. The vendors already have a way to do that for their customer base. We are just choosing to leverage that capability.
Finally, poke and prod your government’s security leaders and organizations. In the U.S, these are the key players.
- Jen Easterly: CISA Director (Cybersecurity and Infrastructure Security Agency)
- General Paul Nakasone: Commander of the United States Cyber Command, Director of the National Security Agency (NSA), and Chief of the Central Security Service.
- Anne Neuberger: Deputy National Security Adviser for cyber and emerging technology, internal coordinator for President Biden’s cyber-focused executive order
- Chris Inglis: the National Cyber Director, the president’s top cyber adviser and coordinator.
At every opportunity, engage them about this idea. Get them talking about it at a high level so that they can spread it around their circles.
If indeed the intrusion kill chain prevention strategy is an infosec first principle, and you all know that I think it is, then the proactive defense / adversary playbook idea can’t be abandoned. As a community, we must embrace it, or something like it, or we will have left a giant opportunity on the table for reducing the probability of material impact to our organizations due to a cyber attack.
S1E1: 6 APR 2020: Your Security Stack is Moving: SASE is Coming.
S1E6: 11 MAY: Cybersecurity First Principles
S1E8: 26 MAY: Cybersecurity first principles: intrusion kill chains.
S1E10: 08 JUN: Cybersecurity first principles - DevSecOps
S1E12: 22 JUN: Cybersecurity first principles - intelligence operations
“21 Stupid Warning Labels That Will Make You Feel like a Genius.” Reader’s Digest. Reader’s Digest. June 16, 2020.
“Biden’s Cybersecurity Team Gets Crowded at the Top.” by Garrett Graff, WIRED, 17 July 2021.
“HOW OUR SHARING WORKS,” Cyber Threat Alliance, accessed 24 August 2021.
"Implementing Intrusion Kill Chain Strategies by Creating Defensive Campaign Adversary Playbooks," by Rick Howard, Ryan Olson, and Deirdre Beard (Editor), The Cyber Defense Review, Fall 2020.
"Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains,” by Eric Hutchins, Michael Cloppert, and Rohan Amin, Lockheed Martin Corporation, 2010.
“Introduction to STIX,” Oasis, accessed 19 May 2020.
“It’s Time to Get off the Treadmill: Why You Should Understand Adversary Playbooks.” by Rick Howard, CSO Online, 6 September 6 2018.
“MITRE ATT&CK® Navigator,” MITRE, accessed November 5, 2019.
“October 2018 Integrated Cyber Day2 Keynote Rick Howard.” by Rick Howard, YouTube, IACD COnference, 2018.
“Offensive and Defensive Playbooks,” by Rick Howard, Linked-In, 2017.
“STIX 2.0 Finish Line,” by John Wunder, MITRE Blog, 12 April 2017.
“STIX - Structured Threat Information Expression (Archive) | STIX Project Documentation.” 2021. Github.io. 2021.
“The Cyber Kill Chain is making us dumber: A Rebuttal,” by Rick Howard, Linked-In, 2017.
“The Future of Intelligence Sharing: Adversary Playbooks.” by Rick Howard, Linked-In, 2018.
“The Pragmatic Adversary: The Criminal Ecosystem and How to Stop Them with Playbooks,” by Ryan Olson, Ignite 2017, 2017.
“The Princess Bride (1987) - IMDb.” 2020. IMDb. 2020.
“UNIT 42 PLAYBOOK VIEWER.” 2021. Github.io. 2021. .
“What is the MITRE ATT&CK Framework?” by Chris Brook, Data Insider, DigitalGuardian, 24 October 2019.