What Do You Get When You Cross a Pyramid With A Chain?

In my last post, I described what I call the Pyramid of Pain, a simple model to visualize the effect that your use of different types of indicators can have on an adversary's operations.  I think that single post probably got more positive feedback than anything I've ever blogged about before.  I got a lot of great ideas for future posts by reading the comments people made on Twitter, so thanks everyone for the feedback.

One recurring theme has to do with the interaction between the Pyramid and the concept of the Cyber Kill Chain put forth by Hutchins, Cloppert and Amin.  If you're not familiar with the idea behind the Kill Chain, I recommend you take a break right now and go read these articles before proceeding.

How the Pyramid and the Kill Chain Fit Together

Gizah Pyramids ["All Gizah Pyramids.jpg", Liberator, Ricardo,
http://commons.wikimedia.org/wiki/File:All_Gizah_Pyramids.jpg,
Checked 2013-03-06]

Let me start by making a clear statement:  The Pyramid is not a replacement for the Kill Chain, it is a complement.  The Kill Chain model shows the various states an adversary must move through to complete their objective(s).  At each phase, you have the opportunity to detect their actions using certain indicators.  This is where the Pyramid comes in: it serves as a guide for knowing how to prioritize your limited detection resources in order to achieve the maximum benefit.

The Cyber Kill Chain ["Security Intelligence: Attacking the Cyber Kill Chain", Cloppert, Michael, http://computer-forensics.sans.org/blog/2009/10/14/security-intelligence-attacking-the-kill-chain/, Checked 2013-03-06]

To see how you might combine these two concepts, let's examine some use cases from one of the Kill Chain phases.

Bringing the Pain to Reconnaissance

The first phase of the Kill Chain is all about information gathering to plan the attack.  This can involve anything from probes and scans to find potential weak entry points to examining publicly available information to map out the sorts of valuable information they might expect to find once they are inside. 

Let's examine that latter use case.  Since we are talking about indicators you might be able to detect, that probably means we are limited to discussing the adversary's direct interactions with our own systems (e.g. our web servers or other Internet facing infrastructure.  Things like checking the Google caches or examining SEC filings are not likely to leave indicators where we can see them, so they don't really count here.)

Starting at the lower level of the Pyramid, you could try to keep track of all the IPs that you know the adversary uses for reconnaissance operations, but this is not likely to be very effective.  You may potentially be tracking hundreds of individual IPs, each of which may only be used for a short time.  This is a lot of effort on your part to manage that data, and it is likely to generate a significant amount of false positive alerts which will consume analyst time.  

The adversary has effective countermeasures against this, too.  They can rent access to a botnet, giving them thousands of throwaway IPs, or they could simply use any of a number of anonymizing services such as Tor, I2P or even a VPN.  The best part (the worst for you) is that not only are these easy to use, but they are usually free or very low cost. It costs you a lot of resources to effectively track at this level, and it's free and easy for the attacker to counter your efforts.  Sound like a win?

Moving up the Pyramid, though, makes things a bit moe complicated for the attacker.  Detecting the network artifacts of their tools (e.g., a distinctive URL pattern or User Agent string they use when spidering your website) puts the burden on them to change up their toolset.  Once your monitoring structure is in place, creating new signatures for new tools is usually not too difficult, and can be done at only an incremental cost to you.  

If you can move even further up, perhaps operating at the TTP level, you're forcing the adversary to rewrite their playbook, something that is extremely time consuming for them.  Again, there will be a cost associated with gaining the ability to operate at this level, but once you pay it, the costs for future detections are likely to be incremental.  In other words, once you reach that plateau, you can stay there with modest resources.  On the other hand, every time you force the adversary to relearn new TTPs, they pay the cost.  Again, and again and again.

Integrating the Models

The preceding is really just a cursory review of a couple use cases, but it shows the value in combining the Pyramid and the Kill Chain.  Ultimately, though, you must do the actual integration yourself, using your own detection program's capabilities along with your own threat intelligence.  

I recommend starting with a single threat domain (a specific actor or group if you're dealing with targeted attacks, or for something more general, a topic like "Banking Trojans").  Comb through your intel for that domain and organize your indicator types by Kill Chain phases.  Some indicator types may fit in more than one phase, and that's fine.  You may discover gaps or ambiguities in your data, and that's OK, too.  Note these issues and follow up later.  

Once you have your indicator data arranged by Kill Chain phase, you essentially have a dossier on how that threat acts as it tries to accomplish its missions.  

Now revisit each Kill Chain phase in your dossier, and rank the indicator types according to their position on the Pyramid.  This is not entirely a precise mapping, so don't be discouraged if you have to make some best guesses.  Also, don't worry so much right now about whether you have any detection platforms in place that cold actually detect those types in those phases.  That's the next step.

After prioritizing the indicators for each phase according to the Pyramid, go back through and mark the ones you are currently detecting.  Also take note of the ones you have the technology to detect now, but may not actually be detecting (e.g., you have access to DMZ web server logs, but you are not currently mining them for indicators of hostile activity).  What you have marked are both your current detection stance and your likely candidates for short term improvements.  Anything that is not marked is a potential candidate for medium or long term improvement (depending on your detection needs and resources).

The End Result

If you've been following closely, you may have already figured out what all this is driving to, but just in case, I'll spell it out.  By sorting and prioritizing your Kill Chain dossier on a threat and applying the Pyramid to the potential indicators you have, you have developed a detection plan for that threat across your Enterprise.  

I cannot overstate the importance of this plan.  As a living document, you should constantly revisit it to update the intel and revise the priorities and detection capabilities that went into the analysis as your own detection program changes over time.  The document captures not only your current state, but also your goals and gaps.  It's a reference for where you are and a roadmap for where you want to go.  What's more, the compilation of detection plans for all your key threats will make your detection program leaner and more effective, because you'll be operating on actual data about your detection posture rather than guesses and generalizations.

The Thrilling Conclusion

Ok, I lied.  It's not really that thrilling.  But it is important. The combination of the Kill Chain methodology to organize your threat indicators and the Pyramid of Pain to prioritize your detection of them is an extremely powerful one.  The resulting document not only shows you a "snapshot in time" of your DFIR effectiveness against that threat, but also points out gaps which are potential areas for growth and improvement.  It is these plans which help an organization realize the full potential of the intel-driven model of detection and response.  Everything else is just a guess.