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)

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

Attackers already think in terms of graphs; however defenders tend to think in terms of lists
Gabriel Basset, Verizon

Semantic Zooming

Often security visualisations will either be too simple in their attempts to abstract a model, or too complex and confusing by trying to show all the data. An approach to address this issue is semantic zooming which applies meaning to different zoom levels. As more and more visualisations are digital in format, taking advantage of interactivity allows one to generalise parameters of a security model depending on the level of inspection, providing more abstract representations at a macro view, and only displaying the complex intricacies when in a micro view. This corresponds to the act of zooming into an online map to reveal additional details.

This approach complements the of stacking visual elements, as it allows elements to be seen only when such detail is required. For example, when viewing attacker profiles from a macro view, it is only important to show the total perceived threat that an attacker has. As a result, the attacker can be represented by a single circle whose radius is the sum of the stacked circles. A zoom provides a more detailed view, where a viewer might want to inspect how parameters differ between attackers; only at this point does the visualisation reveal the individual stacked elements. By displaying this detail only when necessary, it is possible to create visualisations that can be relatively simple without any loss of information while still allowing the viewer to take a closer look.

On the left a generalised, zoomed-out state of an object, on the right a detailed view that allows for a specific inspection of each element.
On the left a generalised, zoomed-out state of an object, on the right a detailed view that allows for a specific inspection of each element.

When applying the stackable legend in section stacking parameters to massive attack trees, the overall visual effect of the visualisation becomes confusing and harder to read. Viewers are not as able to follow paths as easily as before. However, semantic zooming can be applied in multiple ways. Because the stacked lines are only necessary at a very detailed level, it is perfectly fine to show the average threat level at a macro view with other paths or the entire tree. Only when zooming in to view specific paths will the individual stacked lines be revealed to the viewer. This eliminates the original complexity at a macro level while still allowing specificity at a micro level.

This can be combined with a rearrangement of the linearised attack trees to present the paths in a more understandable manner. By using a radial view for the linearised attack trees at a macro view and transitioning to a table, in which information about the total path can be displayed alongside each path upon user interaction, it can be possible to sort and analyse paths in a way that might otherwise be unwieldy at the macro level. A viewer can then zoom in even closer to see an individual path and its stacked line components, as well as any intermediate labels that might not have been shown before.

radial_difficulty_step
Example of a linearised attack tree that uses the principle of semantic zooming. In this case, the parameter displayed is difficulty, as general difficulty for one attack trace and per step.

 Try out the very rudimentary demo.

TREsPASS data design process

A data design process of five steps based on Ben Fry’s universal process, combined with the narrative-centered design concepts of Ricardo Mazza:

TREsPASS five steps data design process
TREsPASS five steps data design process

 

In addition, our general visualisation approaches include:

Filtering/highlighting/sorting filtering and/or highlighting and focusing can be used to select a subset of elements to reduce visual clutter; similarly, sorting of elements allows to restrict the focus on a subset, utilising a metric for the purposes of ranking.
Highlight highlight a subset of elements to identify, eg elements forming part of a policy violation.
Exploiting visual form and representations utilise visual form and well-known representations to allow quick and high-level recognition to humans.
Using abstractions use abstractions in the set of elements to allow grouping ‘similar’  elements and combine into fewer elements in order to visualise effectively.
Overview and drill-down give an overview of the total system, possibly starting with higher-level abstractions of subsystems, while allowing drill-down into individual subsystems to show more detail.
Multiple views show multiple views of the system from different viewpoints or ‘gazes’ to highlight different aspects of the system at the same time in a coordinated-visualisation (see also North, Chris and Shneiderman, Ben, Snap-together Visualization: Can Users Construct and Operate Coordinated Visualizations?).

However, we also need to consider the focus of the narrative and the nature of the target user communities. We have therefore further applied Riccardo Mazza’s, principles:

Problem: What is the main purpose of the visualisation? Is it needed for reporting purposes, used for exploring the dataset in order to find new information, or is the purpose to confirm an assumption or prove a hypothesis?
Data type: What type of data needs to be visualised? Is it nominal, ordinal, interval, or ratio data? (Mazza combines interval and ratio types under the label quantitative.)
Number of dimensions: How many dimensions need to be examined using the visualisation? These are defined as the number of independent attributes (the attributes that vary with respect to one or more independent attributes).
Primary structure of data: What is the structure of the data we need to visualise? Are there simple values, or are we primarily interested in temporal aspects of the data? Is it of spatial (physical extents), hierarchical, or network structure? Are we interested in a distribution of values?
Type of interaction: How much interaction is needed for the task? Can we use a static display? Does the user need to be able to transform the data prior to visualisation, or manipulate display attributes like colour or zoom-level?

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 Attack Trees: Multiple views

Visualising an attack tree in a tree structure may do a good job at displaying how the nodes are connected, but it does a poor job at examining frequency. Therefore, it makes sense to split this into two visualisations: an attack tree visualisation structured as a tree, as well as a tree map visualisation that focuses just on the relative frequency of each node (Fig. \ref{fig:treemap}). The frequency of the node determines the size of each box, while the colour depicts the relative difficulty of each node. A hover over each box in the tree map shows its label and highlights the nodes in the attack tree, allowing a user to understand the visualisation. Together, they paint a more complete picture. We consider the tree map as part visualisation and part legend.

Tree map visualisation that shows frequency of an attack step.Bottom: figure shows a user hovering over the treemap, highlighting the "im-personate technician" box. All repeating instances of this node are highlightedin the attack tree visualisation.
Tree map visualisation that shows frequency of an attack step.Bottom: figure shows a user hovering over the treemap, highlighting the “im-personate technician” box. All repeating instances of this node are highlightedin the attack tree visualisation.

 

InterActor

interactor_homepage

From our extensive contact with security practitioners, in a long series of LEGO engagements and evaluations, we sketched out the beginnings of a potential digital prototype. After nearly 300 people have used the LEGO method with great success on a wide range of contrasting cases, it was clear to us that there was also a need for an extension to the method, where data can be captured during and after the co-creation process which had closely involved stakeholders of all types and kinds. The InterActor prototype is designed to extend the physical modelling process, so that stakeholders may continue to work on these problems together, by creating shareable digital models of their tangible LEGO models, ensuring that the resulting insights are not lost.

map2

InterActor has been conceived as a way of extending and facilitating the co-construction process, and is intended to be used during and after workshops, in face-to-face sessions, and work can also be shared remotely via its web-based architecture. Starting points are provided to users so that they may shape things so that they are relevant to their own practice (using a spreadsheet view of their data).

This can include practitioners modelling their own roles within an organisation, managing and accounting for how an issue is being tracked within the workforce. Doing this requires a narrative that can be jointly developed with teams and stakeholders involved in a risk scenario, and InterActor is also designed to suit this purpose.

relationships

The overall aim of the prototype is to assist the security practitioner in finding and mapping the communities of practice that surround controls. It provides a more refined and integrated view of how control strengths in specific areas are supported by (and are also based on) the specific values and perspectives of actors, in groups and as individuals.

acmemap1

The digital tool operates in such a way that the techniques can be applied in depth or with a light touch, depending on the level and amount of data that is encoded with the prototype. In the security domain no comparable tools exist that can be compared to the LEGO analogue tool kit and the InterActor prototype produced by TREsPASS, as they work in combination to visualise socio-technical patterns, and inform our view of risk.

The first version of prototype can be accessed online: InterActor-Creative Securities/RHUL

The second version of the prototype following user feedback can be found here

 

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.

Paper prototyping: Cloud case study

Paper prototyping is a means of creating a paper version of a digital interface and inviting a participant group to engage with the paper prototype simulating the use of the digital interface. This has placed emphasis on taking paper prototypes to user groups to explore how they perceive risk through successive spheres: organisational, physical, digital and social. The importance of the spheres is to steer participants toward awareness of four significantly different views of the same issue, for example the differences between the views that security is about compliance to protocol (organisational), locking the office door (physical), changing passwords frequently (digital) or trusting a colleague with sensitive information (social).

A session run at CSP 2105, Brussels.
One of the several groups taking part in paper prototyping at CSP 2105, Brussels.

A mapping kit was developed for these sessions. This was composed of:

  • A map of a geographical location (in most cases a room).
  • Icons for physical assets and people.
  • Icons representing boundaries.
  • Colouring pens.
  • Tape.

In each session the same process was followed, and the steps were as follows:

  1. Introduce the TREsPASS project and the role of visualisation within the project.
  2. Present participants with a scenario and a mapping kit and explain how to use the mapping kit.
  3. Ask participants to identify the assets, the connections between the assets and the possible attack paths.
  4. Place a likelihood on the success of each attack (represented by an attack path).
  5. Rank the risks based on the likelihoods.

The results were recorded through photography, note-taking and the collection of the completed paper prototyping.

Template that was used for paper prototyping.
Above: The template that was used for paper prototyping.

 

The completed template, a sample result from the paper prototyping session.
The completed template, a sample result from the paper prototyping session.

Insights from the evaluation sessions

The key insights from the evaluation sessions are as follows:

  • Narratives are needed to make the map understandable.
  • Risks need to be visually categorised in order to make the map usable.
  • Those using the map focused on the left-hand side of the map and not on the right.

The insight about narrative has led us to consider how we can include narrative in the Attack Navigator Map. One possible avenue of innovation is to incorporate analogue three- dimensional modelling (such as LEGO) into the more mathematically abstracted Attack Navigator Map, as mentioned in the previous section. This will be further explored in Year 4 of the TRESPASS project.

A paper prototyping session at Edith Cowan University.
From a paper prototyping session at Edith Cowan University, Australia.
img_1854
The toolkit developed for evaluation sessions.

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