View!transformation!

The fifth stage includes the generation of the graphical representation and is often an iterative process by itself. It is about the question of design. How is the graphical representation supposed to look like? By considering the information seeking mantra again, it all starts with providing an overview first before going into detail. This is achieved by only providing the IP address, the number of vulnerabilities in text form, and the color-coding scheme for each node.

Figure 28: The information seeking mantra proclaims providing an overview first before going into detail. This graph identifies each host and the number of vulnerabilities assigned to it.

Figure 28 was created using the GraphViz “dot” layout. The DOT file was modified to add another network hierarchy. The numbers in brackets represent the number of vulnerabilities found per severity level (ordered by “critical”, “important”, “moderate”, “low”, and “info”). The number of nodes has been decreased for better readability. The network hierarchy can be easily followed. The “subgraph” option allows to further highlight the nodes of a subnet. I think that this view is a good start to look at the scan results (overview first). From here, given an interactive tool [RM09], the user would now pursue to view a dedicated network or a selection of nodes (zoom and filter), and then click on a node to view the detailed list of vulnerabilities (details on demand).

What is not satisfying yet is the presentation of the results. For a small number of nodes, this layout works very well. However, a real-world scan often includes tens (or hundreds) of systems. Figure 25 (the network graph I started with on page 57), for example, contains 30 nodes. Using the “dot” layout makes the graph hard to read in a non-interactive tool. Therefore, the scan results need to be aggregated or arranged in a different way. The GraphViz tool supports various graph layouts [GVIZ, GN09]:

• dot. Used for directed and hierarchical graphs. Subgraphs are supported but without connections to them. This layout is recommended if edges have directionality.

• neato. Meant for unidirected graphs using so-called “spring” models. Supports subgraphs but no subgraph-connections. Its use is recommended if the graph is not too large (about 100 nodes).

• twopi. Draws graphs using a radial layout. Does not support subgraphs. Nodes are placed on concentric circles depending on their distance from a given root node. This reminds me of the RadialNet/ZenMap network topology view presented in Figure 17 on page 35.

• circo. Creates graphs using a circular layout. Subgraphs are not supported. This is suitable for certain diagrams of multiple cyclic structures such as telecommunications networks.

• fdp. Is for unidirected graphs using a “spring” model. Subgraphs and corresponding connections are supported. Fdp is similar to neato but uses different scaling algorithms.

• osage. Has been designed to draw clustered graphs. Does support subgraphs but no connections to them. Nodes and cluster subgraphs are viewed as rectangles to be packed together.

The three layouts that appear most suitable for this work are “neato”, “fdp” and “osage”. These layouts are presented below. Samples of the other layouts are provided in Appendix A for further reference.

Figure 29: Scan results for thirty-three systems presented in the GraphViz neato layout.

Figure 29 represents the scan results for 33 systems in the GraphViz “neato” layout. The nodes are arranged in a circular way, which saves space. Compared to Figure 28, this graph lacks the clear visibility of the network hierarchy. The comparison of the number of vulnerabilities per node (represented by its size) is more difficult because the eye is constantly moving around the graph. In addition to that, some node information is covered by the edges. And last, but not least, the “neato” layout does not support connections to the subgraph itself (the blue rectangles around each subnet). This connection is shown to a new node called “clusterB” instead, which is the internal reference for the 10.18.12 network. Aggregation by leaving the edges away will break the graph.

Figure 30: The same scan results presented in the GraphViz osage layout.

Figure 30 shows the scan results for the same 33 systems in the GraphViz “osage” layout. The nodes are arranged using a minimum amount of space. Compared to Figure 28, this graph lacks the clear visibility of the network hierarchy. The high number of edges makes the node information hard to read. Connections to the subgraph itself (the blue rectangles around each network) are not supported. Therefore, a connection to a new node called “clusterB” was created instead. The name “clusterB” is the internal reference for the 10.18.12 network. Aggregation by leaving all edges away is not an option because the network hierarchy will not be visible anymore.

Figure 31: Third view of the same results, this time presented in the GraphViz fdp layout.

Figure 31 represents the third view of the same scan results. This time, I was using the GraphViz “fdp” layout. The nodes per subnet are arranged in a condensed way. Although the presentation of the network hierarchy is different to Figure 28, it is still readable. The high number of edges obscuring the node information is disturbing. This can be improved by aggregating the edges of all the hosts in the same subnet into one. It is possible to attach connections to the subnet cluster itself. Therefore, I consider the “fdp” layout as the most suitable one for this work.

Figure 32: Visualization of the scan results for three networks using the GraphViz fdp layout with aggregation.

Figure 32 shows the scan results for three networks using the GraphViz “fdp” layout with aggregation. Superfluous edges have been removed (compare to Figure 31). Connections are now aggregated at the network level if possible. The graph and the network hierarchy are well readable. Thanks to the vulnerability scoring system applied, nodes 10.10.1.243 and 10.18.1.110 are marked as critical (shown in red). By looking at a node’s size, the IP addresses 10.10.1.243, 10.18.1.100, and 10.18.1.101 contain the highest number of issues per host. This can be verified by looking at the numbers in brackets. They represent the numbers of issues ordered by severity level.

1: digraph structs {

2: layout=fdp; // overlap=false; 3: …

4: digraph subgraph cluster10_10_1 { 5: color=blue;

6: labelloc=b;

7: label="10.10.1 network";

8: "10.10.1.200" [ fillcolor=orange, height=0.2, label="10.10.1.200\n (0/1/0/0/0)", width=0.2 ]

9: "10.10.1.243" [ fillcolor=red, height=2.2, label="10.10.1.243\n (9/1/1/2/0)", width=2.2 ]

10: "10.10.1.254" [ fillcolor=lightblue, height=0, label="10.10.1.254\n (0/0/0/2/0)", width=0 ]

12: … 13: "10.15.1.102" -> "10.18.16.3"; 14: "10.18.16.3" -> "10.18.12.1"; 15: "10.18.16.3" -> "cluster10_18_11"; 16: "10.18.16.3" -> "cluster10_10_1"; 17: "10.18.12.1" -> "cluster10_18_12"; 18: }

Source Code 11: Relevant sections of the DOT-file used for Figure 32.

Source Code 11 is an excerpt of the relevant sections of the DOT file used for Figure 32. The parser was modified once more to support aggregation. Lines 1 to 3 contain general graph definitions. The graph layout is “fdp” as set in line 2. Lines 4 to 7 contain definitions that are specific to subgraph “cluster10_10_1”, which represents the 10.10.1.0/24 network. The nodes of that network are defined in lines 8 to 11. Lines 12 to 18 hold the aggregated connections between the nodes and the networks, respectively.

Although the iterations of going back and forth between adjusting graphical properties and re-creating the visual could be repeated many times more, I stop at this point. The visual representation in Figure 32 shows the scan results in condensed form and provides a good starting point to select a single node or an entire network and look at the details. All labels are readable and the network hierarchy is preserved. The scan results are shown in a reasonable amount of space. Due to a limitation in the GraphViz “fdp” layout, the weight of an edge does not show correctly. And, putting labels to the edges would not add additional value (information) to the graph. Further interpretation is left to chapter 5.6.