Threat analysts work with lots of data and need powerful tools to navigate and restructure it into specific narratives. They also need dashboards that convey status at a glimpse for a more agile and actionable workflow, no matter how complex the system is.
But more complexity and data doesn’t mean bigger tables and shinier dashboards. More complexity and data require data structures that can easily convey more meaning, in a way that is closer to reality.
Attack trees do just that—find the sweet spot between threat modeling and usability.
Because once data is usable it can become a tool.
Here at CounterCraft, we’ve toyed with this concept in the past. If you’ve used our product, you’ve been able to create attack trees and experiment with them yourself. However, in our latest version, we use attack trees as the base model, the structure for our deception campaigns.
Threat Modeling : Developing an Attack Tree that Works
What deception analysts, threat modelers, and analysts in general need are tools to navigate and understand data. Or, more specifically in our case, adversary activity. Observe, understand, model adversary behavior and persist.
Attack trees are well known in cyber, and there it’s lots of literature on the matter. They often get a bad rap: always static, generic, and destined for complexity. This is part of the reason why other frameworks, such as the kill chain, have been more popular. Therefore, to achieve usability with graphs, we must solve layers upon layers of complexity before data reaches the user. Who would have thought… so the quest begins.
How do you make an attack tree into a tool? And why would you want to do so?
These are both loaded questions, and the answers wouldn’t fit into a single blog post. However, here at CounterCraft we are convinced of the attack tree’s importance, and we have put in countless hours of research with the help of many great people in order to create just that: an attack tree that functions as a threat modeling tool.
What are CounterCraft’s Attack Trees?
Attack trees, on their most basic lever, are hierarchical, graphical diagrams that show how activities and movements interact and combine to achieve an adversary’s objectives. CounterCraft, however, has taken this basic idea and turned it into a powerful, highly usable tool with distinct characteristics.
CounterCraft Attack Trees have several unique characteristics:
- Diagram first
You may already be familiar with Breadcrumbs, Deception Services, Deception Hosts and Rules. If you’ve used our product before, these are the building blocks of our Deception Campaigns and also of our Attack Trees.
You can combine any of these elements to Design your Attack Tree; such as AWS Keys, Documents, Deceptive Mobile Apps, AWS and Azure hosts, SWIFT, Medical or SCADA servers to name a few, and build your deception environment. You can then link these assets using adversary detection rules.
For scalability and fidelity to real life deployments, we allow compounded nodes. You can compound services in your host, or breadcrumbs in your endpoints, and answer the question of where your deception assets/objects are located. What Hosts, Endpoints, Breadcrumbs structure my deception infrastructure?
With structure comes location which in turn enables direction.
By definition, attacks are directed from a source towards one or several targets.
Attack trees enable modeling direction for activity behavior detection, by using special directed edges.
CounterCraft’s graph edges carry three main subjects: source, target and detection rule. Where does activity come from? What is it targeting? What kind of behavior have we detected?
Source is probably the hardest matter to capture but it always exists. It may take many forms and shapes. Most often then not, it falls on the Analyst to solve such difficult matters.
Countercrafts solution allows for modeling adversary behavior by creating links between deception assets (breadcrumbs and services). Behavior is defined as activity that can be filtered by defining specific rules. To deal with possible attack path occurrences the Analyst must be able to define these possible paths.
Nodes and edges scale easily and quickly as we’ve already seen in previous sections.
This generic structure is very flexible so it allows to represent any real life model, very similar to what you would do with a relational database.
Diagrams, on the other hand, bring meaning to and control over the data we are representing. They allow you to bridge raw data and usability and convey a very clear image of what the system is and how it works.
Even though differences between graphs and diagrams may be subtle, they are not. Diagrams allow control over each building block in our attack tree, in a way classical UI has already familiarized users over many decades. You could say that CounterCraft’s Attack Trees come with batteries included.
Merging graphs and diagrams is a big first step. Scalability and user control bonanza?
Modelling the attack structure can only do so much. This static data structure does not exist in a vacuum, and it’s tied to time as anything else— thus, attack trees have a life cycle.
Keeping complexity in check is key. That is the difference between a simple representation of data and a usable tool.
Our Attack Trees have three main states: Design > Operations > Analysis. Each step requires different skills from our users and compartmentalizes complexity as per user profile basis.
/ Design : The Analyst is capable of defining an attack tree with the least friction possible. We only enforce the minimum constraints to ensure your design is deployable.
/ Operations : The Operator can now deploy the design. Provide/request required resources to client IT departments, configure assets and inform the Analyst of any required changes on the initial design. These are some of the tasks the Operator must perform at this stage. Once deployed, the most common task is monitoring the health of the attack tree to ensure analysis data keeps coming in and can be investigated by the Analysts.
/ Analysis : The Analyst now must study their own hypothesis, as the initial design has come to life. At this stage we provide real-time feedback on incoming activity, all overlayed on your deployed attack tree. We also provide metadata such as TTPs, GEO location and other artifacts that enrich the detected activity.
The analyst can rapidly scan the current state of the attack tree, aided by a side panel for drilling up and down activity on each node, and then, if needed, go to the Data Explorer for advanced introspection. More widgets and tools are provided, all integrated into the flow of the attack tree life cycle.
While reading about the cyclical properties of the attack tree, you may have noticed an uncanny resemblance to the scientific process. Well done! You have a keen eye for spotting patterns.
You may be thinking, “So cool, but… what now?”
No User Experience is complete without closing the loop. The show must go on.
Using CounterCraft Attack Trees for Threat Modeling
Once your Attack Tree is designed (based on an hypothesis) and deployed, the Analyst is able to investigate real data and draw conclusions. This may be the most significant point in our journey towards meaningful intel. The conclusions and decisions the Analyst makes leads the story down different paths.
Persistence, communication, research, iteration … these are all possible ramifications. We will focus on the cyclical nature of this journey; iteration, and leave the rest for the future.
The Attack Tree on paper is not intelligence, it’s an infinite set of possibilities, which in practice – a.k.a. real life – translates to an unknown and known finite set of possibilities.
The unknown makes it look infinite and unexpected.
When designing the deception environment the Analyst faces the difficult task to design in such a way that their attack tree caters to a specific adversary objective or known actor behavior. The Analyst itself has their own objective that counters the adversary’s objective. This requires the Analyst to think several steps into the future, which means they have to base assumptions upon assumptions. Predicting the future is no easy deed, especially for human beings, where bias weighs heavy at each step.
More often than not, the initial hypothesis may fail. Easy and rapid iteration is required over the initial model. The hypothesis becomes less of a hypothesis and gets enriched with experience. The Analyst is able to jump back to Design, defining new breadcrumbs, changing existing services, or creating new edges with better behavior detection rules, based on new unexpected intel.
Modeling deceptive environments may seem daunting, especially for newcomers to the industry. But worry not, we provide excellent starting points, such as Campaign Templates, Intelligence Database, a sweet integration with MITRE matrices (thanks to our wonderful Intel team), our state of the art deployment expertise (from our Operations team), and so on.
Alex Craiu is the Product Designer at CounterCraft. Follow him on LinkedIn.