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)

Cloud Environment & Actor Visualiser (CEAV)

The Cloud Environment & Actor Visualiser (CEAV) visualises a cloud environment, including infrastructure such as physical servers and virtual machines as well as cloud actors. The environment is depicted over time with a focus on the roles the administrators have on parts of the infrastructure. As cloud environments typically have a large number of components, the view abstracts/summarises unchanging parts visually, allowing the user to focus on the changing elements over a given time interval. The time interval of interest can be selected from a timeline that indicates changes in an overview of the available date range.

Representing the overall cloud environment including its actors does not leave room for the explicit representation of time as a spatial dimension. Therefore in this prototype snapshots of the system state, and respectively highlighted changes during a selected time interval, are shown together with a timeline to summarise times of change as well as to select the time interval for which to show changes.

Figure 1 shows the initial view of CEAV for data from a real medium-level private cloud (for protection, the data is anonymised – a cloud administrator would see instead the user and infrastructure names with which he is familiar). This more complicated view shows on the left hand side the various cloud actors (represented by their user ids in the cloud), and on the right hand side a depiction of the parts making up the cloud infrastructure. Both parts are connected by role links that show what level of access control the actors on the left have over which part of the cloud infrastructure on the right. The infrastructure parts form a hierarchy through parent-child relationships (as given by the cloud management backend, here VMware vCenter) essentially used for grouping of similar types of the infrastructure. Additionally there are many other typed relations between the elements, e.g., the containment relationship between virtual machines and physical hosts, as exploited in the TiCoVis prototype.

ceavis
Figure 1: Changes of the cloud environment over time. The upper part shows the cloud actors to the left, the cloud infrastructure parts to the right, while connecting both parts by showing the access roles the actors have on the infrastructure. A timeline below shows where changes occur (red for changes in the infrastructure, blue for access role changes), allowing the selection of a time interval for which the changes are summarised and highlighted above.

These relationships can be highlighted and named when selecting individual elements (see Figure 2).

Figure 2: tooltips and highlighting for more detailed information.

This structural representation of the cloud environment is accompanied by a timeline below that shows the full range of observation available, marking again where changes occurred (where red marks changes in the infrastructure, blue a change in actors and or roles).

As the structure here is more complex to represent and there is typically a large number of cloud infrastructure elements, the representation focuses on changes occurring in the time interval as selected in the timeline. Hereby a red colour signifies vanishing, a green colour newly introduced relationships in the graph. To keep the representation visually readable despite the large number elements, abstraction is employed here to summarise similar elements into nodes marked ’Unchanging’ together with a counter of summarised nodes (on this particular level, each of which potentially represents a much larger number of lower-level elements).

Figure 3 shows the selection of a smaller time interval around the time where the role change occurred. Hovering over the role connection shows details of the role type and the explicit user respectively infrastructure element.

ceav-timeselection
Figure 3: selection of a smaller time interval around the role change shows the correspondingly different set of environment changes in the main graph.

The prototype can be found online at TREsPASS CEAV.

 

Time-Containment Visualiser (TiCoVis)

The Time-Containment Visualiser (TiCoVis) creates an ’alluvial’ view of a selected ’container- content’ relations, e.g., between physical servers and virtual machines, over time. In an alluvial diagram, time is an integral part of the visualisation and the ’flow’ of contained elements between containers over time is directly visible as it is laid out spatially. Zooming and panning functionality allows seeing the big picture over time as well as details for specific time intervals.

In this prototype the focus is just on one specific containment-like relation between two types of instances, here the placement of virtual machines on physical hosts, therefore it is possible to explicitly show time as one dimension of the representation. Still, the large number of elements and change events require steps to visually summarise and focus on changes rather than unchanging elements.

The alluvial flow of virtual machines contained by physical hosts over time.
Figure 1: The alluvial flow of virtual machines contained by physical hosts over time.

Figure 1 shows the entry screen of TiCoVis with the representation of data from a live medium-level private cloud (for protection, the data is suitable anonymised — a cloud administrator would of course see instead the host names with which he is familiar).

The different horizontal bands represent physical host machines over time, the width of the bands indicates the number of virtual machines deployed on that host.
Rectangles represent a host at a specific point in time, when a change occurred for this host. Flows are coloured with a gradient in order to further clarify visually where changes are occurring.

Time is represented in the horizontal axis. The upper part shows the main information for the time interval selected in the timeline at the bottom. The timeline summarises the available data as a fixed full interval by placing red markings for all change events, giving a direct indication where respectively when changes occurred.

Hovering over flows or host rectangles will dim all flows except the ones connected to this flow/host and show information of the involved virtual machines and related changes in a tooltip (see Figure 2).

Figure 2: highlighting selections while hovering and tooltips for detailed data.

Zooming and panning is enabled on both the data area and the timeline for easily selection of arbitrary time intervals, allowing to resolve time interval dense with changes (see Figure 3 for a detail).

Figure 3: zooming and panning is possible for the selection of time intervals.

Still, some time intervals contain so many changes to the system that marking each change by a rectangle would lead to an overload. For these time intervals, the entries have been summarised into special summarisation nodes (double the width of normal nodes with slightly darker color and a pattern indicating how many events are summarised within). This can for example be seen in Figure1 } in the lower right hand side. Zooming into this time regime will gradually unfold the contained nodes (shown in Figure 4).

ticovis-unfolding
Figure 4: unfolding summarisation nodes while zooming.

The prototype can be found online at TREsPASS TiCoVis.