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.

 

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.

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

Visualising virtual infrastructure

The cloud use case in TREsPASS can serve as an example exhibiting many challenges: the cloud is situated in multiple spheres of interest: a physical setting with rooms, doors and windows where e.g., physical infrastructure pieces of a cloud environment are situated and where the different actors have access and can move,software-defined virtual parts, like virtual machines (VMs), virtual network and storage,situated in an abstract and completely separate space, or the social space where a distance between actors defines weak or strong relation-ships. At the same time, the physical elements (e.g., servers, network) can range in the tens of thousands, the virtual, software-defined components (e.g., virtual machines) can range in hundreds of thousands. In addition, there is typically a very large number of users of the cloud infrastructure and rather few, but very powerful, administrators. All these elements will interact (cooperating or interacting maliciously) leading to a complex behaviour over time, which leads in effect to a Complex Adaptive System. 

Here under are some visualisation examples showing how changes on servers, including VMs can be visualised so that a general vulnerability-score can be read from it.

connections-01
Example of a hierarchical structure, where each virtual asset (file, program, VM) is assigned a temporal vulnerability-score.
connections-02
Nested hierarchical structure of virtual assets, dotted lines are (temporarily) not used assets.
connections-04
Virtual assets ordered on vulnerability, in most cases the most logical manner to display the information.

connections_

Two simultaneous views on files on a Virtual Machine (VM). Brighter green blocks are more vulnerable.
Two simultaneous views on files on a Virtual Machine (VM). Brighter green blocks are more vulnerable.
screen-shot-2015-04-08-at-17-15-46
Expanded view of one of the VMs folders.

Attacker profiles

Attacker profiles are a good example of the need for stacking because the number of parameters change depending on the situation. Intel provides a set of baseline attacker profiles in this PDF on Threat Agent Risk Assesment ( Download PDF:wp_it_security_riskassessment). But there are cases where perhaps some parameters may not matter. It is necessary to create a visual system that allows for this. By using a unified legend, as described above, where thickness and colour can represent threat level, it becomes possible to represent an attacker profile as a set of stacked circles, in which each parameter is one of the circles. This technique allows extensibility if say, later on, a situation calls for an additional parameter by providing the ability to stack an additional circle. Again, it is important to pay attention to visual hierarchy as parameters that are closer to the outside of a circle are weighted as visually more important. This can be adjusted by arranging the parameters in order of importance, or preference, from inside to outside.

Interface to change parameters of attacker profiles (budget and time) and legend to the profiles.
Interface to change parameters of attacker profiles (budget and time) and legend to the profiles.

A live demo can be found  here

Workshop results: ATM case study

September 2016, a TREsPASS  Data Visualisation workshop was organised in liaison with WTHX, a one-day mini-festival around the topics Peace, Justice, Security + Code. The data visualisation workshop focused on how to make visualisations around security that create impact, lead by Paolo Ciuccarelli, Michele Mauri from DensityDesign, and LUST. The 35 participants were security practitioners, data visualisation specialists, students interaction and graphic design, journalists, etc..

The participants (in groups of 5-6) worked with data from the ATM case study, the geographical data set on ATMs in Lisbon, their attacks and all kinds of social data around this. In the introduction to the workshop, the goals were made clear and many tools for quickly getting visual insight in data sets were introduced. During the day, the participants presented updates and ideas on the narrative that they found in the data set.

Conclusions from the advanced visualisation workshop

The different groups all had very different perspectives on the data set, and many interesting narratives were created. One interesting example was the extraction of the number of victims per ATM that was attacked, in one case more than 145 victims that got skimmed. Their narrative tried to make the abstract data personal again by relating it to humans again. Also the difference between visualisations that were geographically-based and others that were more graph-based made very clear that data that has geographical qualities does not always need to be visualised geographically to get most impact.

It was very clear that from the participants, the security practitioners had the most difficulty in visualising the data. As they were not used to thinking in visual strategies they stayed closer to the data and could not easily create a narrative out of it that could lead to truly new insights. The cooperation with other professional fields helped getting them out of their comfort zone.

This group came up with a narrative that tried to make the attack personal again. From the data, they could calculate the number of victims per attacked ATM. They visualised each victim as a person, and showed how many were victimised by organised crime or just common thieves, as well as how many victims were made per ATM. See animation on top of this post.
This group came up with a narrative that tried to make the attack personal again. From the data, they could calculate the number of victims per attacked ATM. They visualised each victim as a person, and showed how many were victimised by organised crime or just common thieves, as well as how many victims were made per ATM. See animation on top of this post.

where
This group focused on where attacks were taking place and if there was a relation with external factor, as income in the neighbourhood, population density, and so on.
where2
This group presents an alternative view on vulnerability information, by putting it back on the streets. The bottom image represents a game-like first person visualisation of various ATM types.

 

This group investigated the gross loss versus the indirect loss and first plotted this on a map.
This group investigated the gross loss versus the indirect loss and first plotted this on a map.
A further exploration as result from the research what was found in the previous figure, it became clear that the geographical aspect was not the most important aspect to visualise. In this figure, the loss is visualised per bank, with differentiation between manual and logical attacks.
A further exploration as result from the research what was found in the previous figure, it became clear that the geographical aspect was not the most important aspect to visualise. In this figure, the loss is visualised per bank, with differentiation between manual and logical attacks.

Case study: Vulnerability of ATMs in the city of Lisbon

The set of visualisations has the aim to explore a range of possible correlations between geographic locations and detailed data about the identification of the attack. Each point plotted on the map represents an ATM machine. Zooming in each point reveals information about that ATM as the name of the bank, the address and the neighbourhood.

Each map is composed by layered information:

  • Geographic locations of ATMs machines
  • Area of vulnerability
  • Frequency of attacks

A second layer alternates different data:

  • Geographic locations of Police stations
  • Geographic locations of Highways and Main routes
  • Number of Successful Attacks
  • Distinction between Manual Attacks and Logical Attacks
  • Attack Duration
  • Distinction between Gross Loss and Indirect Loss

Along this mapping the Attack Timeline provides a temporal overview of the events. The layout of the visualisation gives a central importance to the geographic location of each ATM machine. The side column is composed of a corresponding legend and mini maps. The mini maps contain different views and context on the main map.

Distance in meters from ATM to highway entry and main roads
Distance in meters from ATM to highway entry and main roads

 

06_attackdurationvulnerabilitygrey
Visualisation of manual and logical attacks on ATMs in Lisbon plus attack Duration

 

Comparison between gross loss and indirect loss
Comparison between gross loss and indirect loss of attack on ATMs in Lisbon.

Download the full research as PDF

Visualising password cracking

Password cracking is the process of recovering passwords from data that have been stored in or transmitted by a computer system. As a topic, password cracking remains a major focus of security researchers in the area of usability and security. The time to crack a password is related to bit strength, which is a measure of the information entropy of the password. Most methods of password cracking require the computer to produce many candidate passwords, each of which is individually checked. The range of tools available for cracking password are complex because the selection of the tool is intricately connected to the social context and the focus of use for each password. One example of password cracking is ‘brute-force’ cracking, in which a computer tries every possible key or password until it succeeds. More common methods of password cracking, such as ‘dictionary attacks’, ‘pattern checking’, ‘word list substitution’, and others, attempt to reduce the number of trials required and will usually be attempted before brute force is decided upon. Higher password bit strength increases exponentially according to the number of candidate passwords that must be checked, on average, to recover the password and re- duces the likelihood that the password will be found in any cracking dictionary. Using a ‘leaked’ list of fourteen million passwords from the RockYou website, we explored a number of approaches, in order to gain better understanding of such bigger data sets and how they may be interpreted. These tests focussed on visualising processes through which it might be possible to crack passwords and demonstrated the complexity of tools involved in one single attack goal. In this context the focus is on the potential of such visualisations to inform about social practices in connection with password usage, not only the user of the TREsPASS tools but also a broader audience, and thus to create a critical awareness of how to improve password-related practices. By default, a contextually thin dataset can still feed into the research of wider social patterns, even social trends.

Flows that show the amount of generated guesses on leaked hashes (shown as a grey gradient). This allows for visual approximation of the efficiency of each rule. The elements in this figure consist of the word list (on the left), a rule set (in the middle) and the passwords that can be cracked by applying the various rule sets (right).
Flows that show the amount of generated guesses on leaked hashes (shown as a grey gradient). This allows for visual approximation of the efficiency of each rule. The elements in this figure consist of the word list (on the left), a rule set (in the middle) and the passwords that can be cracked by applying the various rule sets (right).

Visualisations can be used to abstract the different cracking method types into technique groups and to align and compare the technique groups. Such visualisation techniques therefore combine abstraction with the use of different views to reduce the complexity and improve the cognitive load for the viewer. As an example, the figure above shows different ‘rules’ modifying dictionary words to reach observed passwords. The colour of the flows highlight nicely which rules are most successful in identifying passwords, thereby informing users about the most common rules that therefore rather should be avoided when creating new passwords. Although passwords are a contextually thin material to work with, it is still possible to distill a context from them. It is possible to derive abstractions from them and to then use a large amount of this data to determine contextual patterns. In this particular case, the fourteen million password list was mapped against the categories inside of Wikipedia. Each found word, fits in a certain category, and that category is often again to be found in another category. In this way, it is possible to visualise which types of passwords people choose over certain times.

Visualisation of a first ontology of 14 million passwords. Each password in the list was mapped against all categories of Wikipedia, recursively, to build this ontology.
Visualisation of a first ontology of 14 million passwords. Each password in the list was mapped against all categories of Wikipedia, recursively, to build this ontology.

 

Detail of the previous figure.
Detail of the previous figure.

It will also possible to use similar techniques in order to build ontologies, that can for instance be used to automatically detect actions, locations, or assets in the Attack Navigator, and thus to figure out its own context. This is one way in which visualisations can use the information that they convey to structure a general framing of analysis.

Download PDF for all visualisation experiments on cracking passwords.