An adversary has successfully carried out a cyber-attack, the proverbial stuff has hit the fan, and it’s all hands on deck to figure out what happened. Unfortunately, it’s not until this type of incident response happens that organizations perform any type of analysis. The silver lining is that these situations can provide invaluable understanding of the threats facing an environment; however, they’re costly, both in terms of time and effort and impact to the business.
Unbeknownst to most organizations, just as much (and likely much more) insight can be gained from identifying and analyzing the attacks that fail. Analyzing what happened and what could have happened means defenders can gain a better understanding of how an adversary operates, and then use that knowledge to defend against that adversary and others like them.
So why aren’t more organizations doing this type of valuable analysis?
There are a lot of factors, a common hurdle is that events (e.g. a flagged email, suspicious HTTP request, malicious file) are often treated as independent, isolated things. In reality, they are data points along a much broader string of adversary actions. One of the critical enablers for understanding this fact, and connecting these dots, is an analysis framework.
An analysis framework gives analysts a way to frame the problem beyond just a single event—it puts events into a broader context. And, perhaps more importantly, it enables defenders to better understand the threats they’re facing, which can drive better defensive decision making and an improved defensive posture. While it can’t exist in a vacuum and requires a strong supporting cast, an analysis framework is critical for moving from a mindset of “malicious events” to “adversary activity” – a shift that plays a critical role in creating an adaptive, active defensive strategy.
Analysis Framework Provides Needed Structure
A challenge analysts constantly face is a lack of structure in analyzing adversary activity. How do I know when I’m done? Have I learned everything I can? Are their gaps in what we know? What are the gaps? Are we missing something? Left without a framework, these questions can spiral on indefinitely. With no structure, answering the question “what happened” is substantially more difficult than if there’s a means of defining what information is needed to answer that question.
The key is to have a structured approach for examining and interpreting information. Even on the face of it, an “analysis framework” is exactly what it sounds like. A framework (“a basic structure underlying a system”) for analysis (“detailed examination of the elements of something, process of separating something into its constituent parts”). An analysis framework provides the needed structure by defining the “constituent parts” that make up whatever it is we’re analyzing.
When you think about an incident, there are a lot of elements involved, i.e. people, data, systems, etc. If you look at it as a whole, it’s very complicated. So you break it down into smaller parts. But even then, that’s a pretty onerous task if you don’t have a structure to make sense of the data and know when you’ve come to a conclusion. An analysis framework provides the means of breaking the big, complicated incident into its constituent parts; a task critical for really understanding what happened and learning from it.
Analysis Framework Drives Consistency
Along with structure, an analysis framework promotes consistency, since the framework itself is consistent across analysts and over time. You can put a lot of smart people into a room and tell them to analyze some data, but without a consistent analysis framework for them to use, the end result will be a variety of ideas and outcomes, which won’t necessarily give you what you want or need, which is the understanding needed to drive defensive evolution.
Adopting a consistent analysis framework for your security organization ensures your team tracks, reviews, and measures incidents in the same manner. Every incident can be very different, particularly when you’re dealing with advanced persistent threats. However, when you break incidents down into consistent parts, based on the analysis framework you’re using, you begin to see similarities and trends. For example, a set of threats may use different infrastructures, but your framework uncovers that the underlying TTPs are the same or that the same employees or programs are being targeted.
Use of a consistent analysis framework at a community level also enables analysts to compare notes with other analysts from other companies and industries, helping them validate their hypotheses and giving them added insight on new threats.
Better Understanding Results in Better Outcomes
Finally, analysis frameworks drive better understanding. Having consistent analysis and resulting data helps reshape how your defenders view problems, respond to threats, and make decisions. For organizations using a true defense in depth approach (defending against every facet of an attack, not just building more walls) to protect their networks, this level of intelligence helps guide changes and improvements to security countermeasures.
Selecting the Right Analysis Framework
There are many different types of analysis frameworks available. Two of the most well-known are the Lockheed Martin Cyber Kill Chain® and Diamond Model of Intrusion Analysis. How all of these frameworks differ is in two main areas.
First, is perspective. This is the approach taken to look at the data. For example, the Cyber Kill Chain looks at the actions the adversary has taken, while the Diamond Model’s perspective is focused on the adversary themselves (what are their objectives, capabilities, infrastructure, victims). Both perspectives can provide value to an organization and, in fact, are very complementary. While analyzing from the perspective of the threat’s actions can yield a tactical understanding by answering the “how” question, approaching analysis from the perspective of the adversary’s definition can quickly lead to a more complete understanding of the who/what/why/when/where questions defenders are often asked.
The second area is dimensions of the problem. These are the aspects or the features of the problem you’re looking at. For the Cyber Kill Chain, there are seven dimensions, while the Diamond Model has four. You might think that more dimensions will give you more insight, but an increase in dimensions is also an increase in analysis work. It’s a balancing act. You don’t want to stay too high level and fail to define appropriate “constituent parts” that allow defenders to gather enough detail to drive decisions, but you also don’t want to break things down too granular, whereby you have too many parts that aren’t valuable defensively.
Regardless of the framework you choose, it’s important to understand that initiating its use requires careful planning and that supporting functions be in place. You can’t just walk into your organization and mandate that your security team start using a framework. What does it take?