Attack Cloud

Representing the hierarchical nature of a structure in a tree structure or tree diagram is very common, but it also has its disadvantages. Especially in larger structures (500+ nodes) the tree form is not always the most optimal way to present a structure in a graphical form, let alone make this actionable. In an attempt to provide a better overview for very large attack trees (1.000—500.000 nodes) we developed what we refer to as the attack cloud. An attack cloud aims to represent all the steps possible in an attack tree. Because there is often no sense of order in an attack path, linearisation can potentially be misleading. This cloud format allows to see which steps are involved in which attacks while still understanding the full context. Steps that are a higher potential threat are closer to the root node at the center, which creates a logical hierarchy of information. By removing duplicates, this approach could potentially also allow us to view entire attack trees as a threat landscape.

The attack cloud graph is divided in sections on the basis of the main action from a label (for instance In, Make, or Force), giving a user a general idea of the action attached to a node. The placement and colour of a node are based on the combination of all known parameters for a node (for instance cost, time, probability and difficulty). The size of the node represents the number of occurrences of this node. Hovering over a node lets the user inspect all parameters, view the label with actions, actors and types, and lets the user mitigate the threat-level of a node by means of altering the parameters as counter-measures. This can be fed back into the Attack Navigator Map from which another analysis can be run.

label
The top row consists of the various types, like action or actor. The second row shows the type of action or actor. Below the text, a mini-visualisation of all the data that determines the position and colour of the node, is displayed. A circle indicates in colour and number the general threat score of the node in question, and a bar graph with the four parameters this general threat score is composed of.
Legend to the Attack Cloud visualisation
Legend to the Attack Cloud visualisation

a

The XML-output from the TreeMaker tool generates labels that are very long and not very ‘human readable’. By restructuring the text into understandable pieces, those labels can become much more informative.

ac-1
Visualisation based on the Cloud case study that was first modelled in the ANM. The ANM generated an attack tree via the TreeMaker tool, and converted into linear attack paths. In this example there are three main actions on which the nodes are ordered. The scale of the visualisation automatically adapts to the data presented, here the scale is between ,30 and ,25. Also, most values in this example were default values, resulting in only two colours (yellow and red), while all shades between those colours would be possible.
ac_hover1-1
A user hovers over one of the nodes and a large tool tip label appears. This tool tip contains the label describing the action attached to the node, in the form of a circle that indicates in colour and number the general threat score of this node, and a bar graph with the four parameters the general threat score is composed of. Clicking on the node makes the tool tip editable, and the user can edit or apply mitigations to the node. These are applied by changing the parameters in the tool tip or by dragging the node to a different position in the graph, updating the parameters. On the right, the 50 most threatening paths are displayed. On hover over the node in the main graph, those paths are highlighted where this node appears. To highlight the exact position of the node in the attack path, the node in question is given a white circle.
achover2
A user hovers over one of the nodes in the column on the right side of the graph. This “attack path” is highlighted with a grey bar, and the corresponding node appears with a white outline. All nodes that are part of this path draw lines to the `goal’ node in the middle of the graph. The colour of these paths indicate difficulty, the colour indicates time.
Example of an attack cloud based on a large attack tree with as main actions "go to", "out", "make", "execute", "force", "in", and "move"
Example of an attack cloud based on a large attack tree with as main actions “go to”, “out”, “make”, “execute”, “force”, “in”, and “move”

Explore the interactive version here 

Linear attack trees

In visualisations, it is widely agreed that it is better to have more simple elements than fewer, complex elements (Tufte, 1990). A tree works well in situations where the structure is fairly simple and small. However, the attack trees that are used in TREsPASS are already more complex than can comfortably be fit on a screen. Working with and studying attack trees from a visualisation point of view, one can question the role of intermediate nodes. Other than being a labelled container for their child nodes, they are not actually steps along the attack path but nevertheless occupy a large part of the attack tree. We can visually simplify attack trees by turning them into linear sequences of their required children. This will result in more paths, but each path will be easier to follow. The simplification and conversion to straight paths benefit readability from a visualisation standpoint. One path now shows a user the steps that need to be taken in a straight and easy to follow line (although it does not usually imply a temporal or causal sequence).
lmh
Visualising attacker skills. Red indicates how far an low-skilled attacker could come, orange a medium-skilled attacker and yellow a high-skilled attacker.
radial
Two visualisations of the same attack tree visualised as attack steps on attack traces, both ordered clockwise where the top is the most vulnerable attack trace. On the left, only vulnerabilities are highlighted, while on the right a differentiation is made between physical nodes and virtual nodes.
radial_total
Three visualisations of the same attack tree as linear paths for each attack trace, each depicting one parameter (cost, time, difficulty). All values of each attack trace are generalised to one total value. They are ordered clockwise where the top is the most vulnerable attack trace.

 

Stacking Visual Elements

Another legend was also developed in the case that additional parameters to each step may be needed. By mapping different visual elements (thickness and colour to threat level) of a line to a scale of threat, it is possible to modularise this element and stack it to any number of parameters.

Visually, this becomes just as effective as the original legend because a step in which all parameters have a high perceived threat level will stand out much more strongly than a step with a low perceived threat level. When combined to form a path, this legend is very informative on which steps and connections are areas of vulnerability.

 

stacking
The principle of stacking visualisation elements, in this example four parameters. Note that low as well as high can be represented with a thick and red line, depending on the type of parameter.
stacking2
Top: application of stacking elements to an attack trace in an attack tree. Each parameter has its own space and can be inspected individually. Generally this would be used in a zoomed in detail view. Middle: application of stacking elements to an attack trace in an attack tree. Each node is generalised to the average parameter values. Bottom: Most general view of the attack trace, where the values of each parameter are abstracted to one value.
stacking3
Alternative view on the same data as the figure above, where the visual elements are stacked without in-between space, therefor adding total height as a visual clue for each node. Also this view can be abstracted depending on zoom-level.

 

 

Attack Navigator Map: Analysis results dashboard

The Attack Navigator Map tool unites a large part of the TREsPASS tool chain (model creation, attack tree creation, analysis, visualisation) in one user interface. The analysis results visualisation dashboard is the last step in the tool chain, and will appear as a different view on top of the regular ANM user interface. It gathers all the results of the analysis (and other intermediate tools) and makes them available as download, and visualises them as attack trees. Next to this the dashboard also offers alternative visualisations, that are derived from the attack tree. If needed it also displays additional visualisations, that are specific for the output format of individual tools, for instance the Attack Cloud visualisation and the tree map view.

Integrated and stand-alone

The TREsPASS visualisations are developed as single, loosely coupled components – entirely independent of one another. By avoiding interdependence we can ensure complete modularity, which in turn allows us to use the components as building blocks for applications like the ANM analysis results dashboard, with the option to easily replace components with compatible alternatives, if needed).

At the same time it is also entirely possible to take a single visualisation component, and –with only a thin layer of application logic around it– package it and distribute it as a standalone (desktop) application.

How it works

The javascript framework that is used is react, where components take required or optional inputs (very similar to function arguments in programming), called “props” (short for properties). The input data must be provided in a certain format, which can be a common format shared among similar visualisation types (attack trees, for instance), or specific to the output of individual analysis tools (for instance ATEvaluator). Best practices dictate to build components that only contain a minimum amount of logic themselves. The task(s) of parsing and preparing the input data is therefore handed over to the host application, whose responsibility it is to provide the component with the right data.

All of the preparation and pre-processing routines are outsourced into an external library, and available as reusable utility functions. The trespass.js library has sub modules for working with the TREsPASS socio-technical model format, different “flavours” of attack trees, and the output formats of the analysis tools that are part of the TREsPASS family of tools.

Visualisation explorations of analysis tools

Most of the analysis tools provide outcomes comparable to a `top 10′, but all do that in slightly different ways. The visualisation of the outcomes of these tools are presented with small charts on the left and a sub set of the attack tree on which the analysis is applied to on the right, and they are always linked to each other. This makes it easy for a user to look for the most vulnerable attack traces.

analyzer-1
ATAnalyzer presents the attack traces with the highest utility for an attacker. In this example a user hovers over the highest utility (utility=1000, cost=600).
evaluator-1
ATEvaluator calculates pareto efficient solutions for the attack tree. Hovering over the pareto frontier highlights the involved attack traces in the sub set of the attack tree on the right.
atcalc-big-1
ATCalc displays the likelihood of attack over time, as well as which leafs become more probable at a certain point in time. The two small graphs on the left plus the sub set of the attack tree on the right interact with each other so that a user can quickly explore the results of the analysis tool.
atcalc
Detail of the two parts of the visualisation of the ATCalc results. Each time step allows explorations and visualises in the graph under it which leaf nodes are involved.

 

screen-shot-2016-11-01-at-09-17-39
Visualisation of an attack tree generated from a map that was build in the Attack Navigator Map.


Watch the visualisation dashboard in action on Vimeo

screen-shot-2016-11-01-at-09-18-28
Circular visualisation of an attack tree generated from a map that was build in the Attack Navigator Map.
screen-shot-2016-11-01-at-09-18-46
Circular visualisation of an attack tree generated from a map that was build in the Attack Navigator Map. Colours indicate similar actions, grey actions are unique actions.

 

screen-shot-2016-11-01-at-09-19-08
Circular visualisation of an attack tree generated from a map that was build in the Attack Navigator Map. The list on the right is ordered on label frequency, how many times the same label appears in the tree.

 

Attack Tree component visualiser

The TREsPASS visualisations are developed as single, loosely coupled components – entirely independent of one another. By avoiding interdependence we can ensure complete modularity, which in turn allows us to use the components as building blocks for applications like the ANM analysis results dashboard, with the option to easily replace components with compatible alternatives, if needed).

At the same time it is also entirely possible to take a single visualisation component, and –with only a thin layer of application logic around it– package it and distribute it as a standalone (desktop) application.

The Attack Tree component visualiser visualises attack trees from XML files, including countermeasures (green). It automatically detects which flavour of Attack Tree (for instance ADTool outputs a different style of Attack Tree XML as TreeMaker). The user can zoom-in and out, to inspect details and change view, from tree structure to circular. It can also visualise similarity for the nodes.

Try out the Attack Tree component visualiser

Download example XML file to load in visualiser

The Attack Navigator Map

The Attack Navigator Map (ANM) is a tool that predicts and prioritises attack scenarios based on a model of the system or organisation concerned. It can also be used to judge the effect of countermeasures, by re-running the analysis with an adapted model. The model takes the form of a navigator map and a set of attacker profiles.

The Attack Navigator Map represents the system cartographically, displaying connections between the elements as potential steps that an attacker could take. These steps are annotated with relevant variables such as difficulty and cost.

A map created in the ANM. The user hovers over the asset "access card" and is prompted that the item can be dragged onto the map. The colour of assets is based on how potentially dangerous the asset is. For "door" red means very weak, for an actor type red means vulnerable.
A map created in the ANM. The user hovers over the asset “access card” and is prompted that the item can be dragged onto the map. The colour of assets is based on how potentially dangerous the asset is. For “door” red means very weak, for an actor type red means vulnerable.

The attacker profile collects relevant characteristics of an attacker, such as skills, resources, motivations / goals, and initial access. By combining a map and attacker profile, the system will calculate routes for the attacker across the map that provides utility to the attacker.

Typically, this will involve gaining access to certain assets and compromising their confidentiality, integrity or availability, which may cause damage to the organisation. The routes with the highest utility for the attacker constitute the highest risk with respect to the selected attacker profile.

Various tools analyse the various routes, and the results are visualised in a dashboard for inspection. On the basis of the outcomes, a user can implement counter-measures and rerun the analysis, until satisfied.

Interface concept

As the structure of elements in an Attack Navigator Map can become complicated very quickly, a wizard-like structure is applied, that guides users through the various steps that need to be taken. Users can draw or import floor plans (for physical and digital environments), apply those to multiple floors and drag-and-drop items  as assets and actors onto the map. These assets, actors, and many more items come from libraries, where the user can also save its own library items, add items, and adjust the properties.

The basic building blocks for constructing a model come from libraries of single components, or of prefabricated model fragments (groups of components with relations), such as the model pattern library. These libraries will contain commonly used patterns, that can be used as templates to rapidly build the basic structure, which can then be refined and tweaked. The underlying data structure is a directed graph of nodes (components with properties) and edges (relations between those components).

 

screen-shot-2016-10-25-at-09-06-58
Diagram describing a typical work-path for a user of the ANM. The individual steps taken within the ANM are shown in grey boxes, and the preparatory and finalising steps are shown in purple boxes. Each step is part of a different phase of work, beginning with Definition of the problem to be worked on, moving through into several stages of Analysis, and finally into Visualisation and Evaluation, shown in yellow circles.

 

03_drag-drop-mov
Animation showing how one can drag and drop files onto the map

 

02_merge-file-mov
Animation showing how to merge files in the ANM

 

04_left-right-click-mov
Animation showing the various contextual functions available when a user user left and right-clicks. Nodes, edges, groups, etc. all have different contextual menus.

 

06_connections-mov
Adding connections.

 

05_move-pan-zoom-reset-mov
How to move, zoom, pan en reset the map view.

 

07_custom-relationships-mov
Editing custom relationships

 

Missing parameters of an asset, actor or location are indicated in the validate layer. The ANM specifies exactly what is missing, for instance if an asset is located somewhere. Also under Run Analysis these problems are indicated, and the analysis can only be done once these problems are resolved. Other examples of warnings are missing attacker, missing value of asset, etc..
Missing parameters of an asset, actor or location are indicated in the validate layer. The ANM specifies exactly what is missing, for instance if an asset is located somewhere. Also under Run Analysis these problems are indicated, and the analysis can only be done once these problems are resolved. Other examples of warnings are missing attacker, missing value of asset, etc..

See the article on the visualisation dashboard for details

 Read the full manual

 Go to the Attack Navigator Map (log-in required)

ATM case study: Horizontal attack-defence diagram

The ATM (Automated Teller Machine) case study aims to study attacks to these kinds of machines, which can be from:

  • Software attacks consisting of infecting the machines with malware software that allows the attacker to take control of the devices, including the ability to open the machine money vault, and record data from the cardholders;
  • Physical attacks consisting in stealing the machines to open them in order to access the money vault.

 

Securing automated teller machines (ATMs), as critical and complex infrastructure, requires a precise understanding of the associated threats. The ATM case study tries to capture the most dangerous multi-stage attack scenarios applicable to ATM structures. This is done through creating attack-defence trees to model and analyse the security of ATMs. Based on expert knowledge and available historical data, the attack-defence tree have been decorated with estimations for critical parameters, such as likelihood of an attack. Next to this, the ATM case study partners have also collected a large data set on ATMs in Lisbon, including data on attacks over the last five years, locations, loss, victims, type of attacks, data on locations of entrances to highways, locations of police stations, unemployment rates in neighbourhoods, and many more.

Developing a horizontal attack-defence diagram

Most attack trees used in the TREsPASS-project only include attacks, decorated with values for difficulty or probability. The ATM case study –next to parameters for difficulty and probability– also implements countermeasures. As previous attack tree visualisations did not account for this yet, a specific visualisation was devised. The arrangement of the tree is based on a hierarchical grid to simplify the relation between the nodes and avoid repetition. The horizontal layout of the attack-defence tree facilitates the exploration of the complex data set and allows the intersection of multiple parameters. The ‘difficulty’ value of each node is represented with a specific colour palette from yellow to red (high—low). The ‘probability’ value of each edge is represented with the thickness of the line (i.e. a thin line shows a low probability).

Download the full research as PDF: lineardefensediagram

at_0929_cs6-07
Example of how an interactive application would highlight the various branches, including countermeasures.
Visualisation strategy of stacking visual elements to communicate multiple parameters, is applied here to the ATM case study. The visualisation is divided into manual and logical attacks. The nodes are combined in broader attack steps as attacks, events, process, action, and countermeasures.
Visualisation strategy of stacking visual elements to communicate multiple parameters, is applied here to the ATM case study. The visualisation is divided into manual and logical attacks. The nodes are combined in broader attack steps as attacks, events, process, action, and countermeasures.
High-level overview based on attack trees for an ATM retail scenario displaying AS-IS versus TO-BE scenarios. In the TO-BE scenarios, various countermeasures have been applied to get to the desired state of security. \\Top left: global overview. Top right: overview for only manual attacks. \\Bottom left: overview for only fraud attack. Bottom right: overview of countermeasures on physical attacks.
High-level overview based on attack trees for an ATM retail scenario displaying AS-IS versus TO-BE scenarios. In the TO-BE scenarios, various countermeasures have been applied to get to the desired state of security. Top left: global overview. Top right: overview for only manual attacks. Bottom left: overview for only fraud attack. Bottom right: overview of countermeasures on physical attacks.

Stacking parameters

Every type of visualisation or graph will contain graphic elements whose rendering is modified by variables. A circle, for example, has several variables, such as position, radius, fill and opacity, that affect the final visual outcome. One can think of these variables as controls that can be adjusted depending on a certain input. This way of thinking allows the creation of many combinations of visual elements.

For example, directed graphs (in the mathematical, not the visual context. So a graph in this context is defined as a network of vertices or nodes connected by (directed or un-directed) edges) are used heavily in security models because of their ability to represent complex network relationships between entities. These graphs consist of edges and vertices, visually often represented by the two essential elements of a line and a circle. Feedback on early TREsPASS explorations found that it is most visually effective to parameterise a maximum of three variables simultaneously. A line can be defined, for example, by its thickness, colour, and opacity. By applying a mapping from a derived security vocabulary (e.g. difficulty, time, and probability) to the visual vocabulary, it is possible to begin building the framework for visualisation. Thickness can be mapped to indicate difficulty, colour to indicate time, and opacity to indicate probability. Note that certain properties are more suitable for mapping to certain visual parameters. It does not make sense, for example, to map time to opacity because a lower opacity implies a weak link, whereas time only indicates the length to complete. More examples can be found in Bertin. All of these parameters combined lead to a very rich, yet simple visualisation that leaves no visual ‘stone’ un-turned. One can apply a similar approach to visualise information in a node.

There are often cases where the number of parameters that need to be visualised far outnumber the sensible variants to a particular visual element. In other cases, it may not be known what the total number of parameters is (as they may shift depending on user input). An example might be an entity, such as an attacker profile, for which the user has the freedom to pick and choose the parameters to assign. In such cases, it makes sense to develop a language that is extensible. An approach in which visual elements are stacked provides a solution to the problem, as it can be applied to a wide range of parameters.

First, it is important to establish a unified legend, where, for example, line thickness and colour are used to indicate levels of risk. Quite often parameters in security models can be mapped to a scale that ranges from low to high risk. This means that a visual element becomes a generalised module for visualising, allowing for adaptability and re-usability.

The principle of stacking visualisation elements, in this example four parameters. Note that low as well as high can be represented with a thick and red line, depending on the type of parameter.
The principle of stacking visualisation elements, in this example four parameters. Note that low as well as high can be represented with a thick and red line, depending on the type of parameter.

 

stacking2
Top: application of stacking elements to an attack trace in an attack tree. Each parameter has its own space and can be inspected individually. Generally this would be used in a zoomed in detail view. Middle: application of stacking elements to an attack trace in an attack tree. Each node is generalised to the average parameter values. Bottom: Most general view of the attack trace, where the values of each parameter are abstracted to one value.
stacking3
Alternative view on the same data as the figure above, where the visual elements are stacked without in-between space, therefor adding total height as a visual clue for each node. Also this view can be abstracted depending on zoom-level.

 

Hereunder a series of examples how the various parameters can be combined in various constellations.
colorsparameters1

Visualising Attack Trees

Attack trees, as developed and used in the TREsPASS consortium, are a tool to capture all possible attacks to reach a specific goal, as described in the root node. To build such an attack tree, experts typically gather and, starting from the goal node, try to enumerate possible ways of attack to reach this goal. Each sub node can be iteratively refined as far as it seems fit. Individual intermediate nodes can thereby be either conjunctive or disjunctive. A conjunctive node requires that all of its children be fulfilled in order to proceed up the tree, whereas disjunctive nodes only require one child to be satisfied in order to proceed. A complete path of actions consists of any number of leaf and intermediate nodes leading to the root node. Within the project, each leaf node is considered to contain four parameters: difficulty, minimum cost, probability of success, and minimum time required to complete. Depending on the effort put into the creation, these attack trees can be very complex, comprising hundreds or thousands of nodes, especially when they are generated programmatically from an underlying model as is the aim of the project. When attempting to visualise these trees, such visualisations quickly become complex and unreadable.

 

tree_radial
Attack tree visualised in radial form where each node corresponds to an attack step. The root node, i.e., the goal, is placed in the center. The edges are coloured according to three parameters: difficulty is indicated as stroke width, time as stroke colour, and probability as stroke opacity.

legendat
In their traditional form, attack trees present a wide variety of important and relevant information, but are not easily visualised, oftentimes shown as an arrangement of text in a directed graph. From a visualisation perspective, attack trees have several flaws; the tree structure gets very wide rapidly, repeating lots of elements to eventually become effectively unreadable even in a medium allowing arbitrary zooming. Also, because attack trees consist of conjunctive and disjunctive nodes, it needs to become visually clear that in the case of conjunctive nodes, all steps need to be fulfilled in order to proceed. We can counteract this complexity by improving the way the tree is laid out and labelled, as well as by testing alternative layouts that result in more compact trees, while maintaining readability. Next to that, exploring interactivity by allowing the user to zoom and pan, and to collapse sub-trees at any level, makes it easier to concentrate only on certain parts of the tree.

tree_radialwtime
Same attack tree as the attack tree above, using the TREsPASS unified colour scheme, including opacity to indicate probability.

A visual language can be developed based on this. It is important to keep in mind that attack trees can vary greatly in size, as their construction is largely dependent on the scenario and environment that they are trying to model. As a result, the language should be scaleable to any size tree. In initial explorations, user feedback revealed that when representing the graph with directed graphs, edges carry much more weight and information visually. Subsequently, most of the parameters were mapped to the edge leading to parent nodes. This allows focus to be placed on the path rather than on each individual step. The resulting legend was developed by parameterising the visual properties of a line and creating a mapping to the attack tree vocabulary.

tree_radial_notime-copy
Same attack tree as the attack tree above, using the TREsPASS unified colour scheme, showing only cost and time as parameters.

 

legendat-new