1 Design Chapter

A visualisation approach may help system ad-ministrators deal with information overload,as it offers several enhancements over textualanalysis of security event collections. Whiletextual analysis is a perceptually serial process,interpreting graphics such as a visualisation isperceptually parallel process [2], offering an im-provement in interpretation efficiency. Addi-tionally, a visualisation can provide a systemadministrator with an overview of the collec-tion, allowing them to easily notice areas ofthe network which may where suspicious ac-tivity may have occured. Thus, a visualisationfront-end to these collections will allow systemadministrators to analyse the collections in anintuitive and interpretation efficient manner.

The visualisation model serves as theproject’s front-end to be utilised by the in-tended users, system administrators. The com-ponent thus plays a key role in the project as awhole, receiving input from both the intrusiondetection and the collection components (Fig-ure 1). The collection component provides thetime, network nodes and network connectionsassociated to each event, while the intrusiondetection component provides the threat levelassociated to each event.

Figure 1: High level overview of the system’scomponent integration

The visualisation component can also beutilised both as a standalone system, or withonly the intrusion detection component, whereit will display event data provided by ourproject supervisor. This will provide the vi-

sualisation with the time, network node, net-work connection and threat level associated toeach event. When used with only the intrusiondetection component, the visualisation will in-stead obtain the threat level of each event fromthe intrusion detection component.

1.1 Design Goals

To establish design goals supportive of the enduser requirements, it is important to under-stand how the user will utilise and interact withthe visualisation. From the user requirementspreviously identified [3], we can infer the fol-lowing typical use case. When presented withan initial overview of the network activity, theuser first seeks to identify a particular areashowing suspicious activity at a specific time.Such an area may be an individual networknode or a group of nodes. Once anomalous ac-tivity is identified, the suspicious area is inves-tigated to further diagnose possible intrusions.This involves the user zooming in on the areaor sub-areas of interest. Once an intrusion isidentified, the user responds by reporting theincident.

With this use case in mind, we can derivethe visualisation’s design goals. A visualisa-tion technique well suited to the use case is theVisual Information-Seeking Mantra detailed bySchneiderman et al. in [6]. The technique in-volves displaying an overview first, then allow-ing the user to zoom in on data of interest andfilter out uninteresting data, then provide finerdetails on demand. Noticeably, these stepsmap well to the tasks described in the use case.It thus makes sense to derive the goals in ac-cordance with these steps.

To assist the user in identifying areas ofthe network generating suspicious activity,the visualisation must provide an informativeoverview, as well as enable efficient explorationof the network activity. As can be identified inthe use case, two important domains the usershould be able to explore are the time and net-work topology domains. This allows the userto zoom in on parts of the network and its ac-tivity to obtain more detail. Diagnosis of in-trusions will be assisted by the ability to filterout irrelevant details. Hence, the visualisationshould enable filtering out of network detailsirrelevant to the user’s current interests. Users

1

will select areas of interest to obtain more in-formation about possible intrusions. The visu-alisation therefore needs to provide finer detailsrelating to a selected network area of currentinterest to the user. Finally, the user needssome form of response functionality once in-trusions are identified. In the case of incidentreporting, for example, this will provide otherswith useful feedback on possible intrusions inthe network, as well as allow for later referenceof discovered intrusions or activity of interest.Thus, provisions in the design need to be madefor such response mechanisms.

2 Visual Queries

From the identified design goals, we can formu-late and rank the visual queries to be supportedby the visualisation. In order of importance,these visual queries are:

• Which nodes have a high threat level?

• How many events have been generated bythese nodes?

• Are these nodes in a similar area of thenetwork?

• Which nodes have they recently been con-nected to?

• Are the nodes’ events clustered in time?

• What are the threat levels of the events?

• Which users are responsible for theseevents?

As highlighted in the previous section, userswill first try identify areas (an individual nodeor groups of nodes) yielding suspicious activ-ity. Thus, suspicious nodes should be empha-sised in the overview to enhance identification.The two natural indicators of suspicious activ-ity supported by the data fields provided are:the number of events generated by each nodeand the threat level of each node. Althoughthe threat level of each node is not immedi-ately available, this can be determined using anaggregation method on the set of events gen-erated by a particular node. Identifying suspi-cious activity can be considered the first step inthe process of diagnosing intrusions. Thus, the

threat level and number of events generatedby each node are of similar importance, andtogether, the most important visual queries.

Organising network activity based on thenetwork provides a logical means for explo-ration, and assists the user in identifying ques-tionable activity occuring at a particular areaof the network. Hence, displaying the networktopology is vital to providing the user with ameans to explore the network to identify net-work areas of interest, and should be rankedaccordingly.

Displaying connections between nodes sup-ports two design goals: providing an infor-mative overview of the network and providingfiner details relating to a selected area. Dis-playing an overview of the connections betweenall nodes in the network gives the user an un-derstanding of associations throughout the net-work. As an example, this allows the user toidentify associations between suspicious net-work areas, which may otherwise appear un-related. Based on the discussed use case, theuser will demand finer details on a particularnetwork area under investigation. Displayingthe set of connections associated only to theselected area allows the user to identify suspectand victim nodes associated to the possible in-trusion.

In support of providing a more informativeoverview, displaying the time of each event’soccurrence allows the user to observe how net-work activity has evolved over time. Addition-ally, it allows the user to draw associations be-tween seemingly unrelated areas of suspiciousnetwork activity. For example, if network ac-tivity occurred in different topological areas ofthe network, but both areas exhibited similarpatterns of activity over time, this may indi-cate a recurring intrusion pattern. Displayingthe time of each event occurrence also providesanother dimension for exploration. With a dis-play of the total network activity, irrelevant ofthe time each event occurred, important infor-mation may be lost amongst the noise of unim-portant network activity. Thus, exploring net-work activity by means of the time domain al-lows the user to focus on network activity rel-evant to a specific time range in the network,and better diagnose possible intrusions.

2

The threat level of each event is importantfor diagnosing intrusions at the granularity ofindividual events. However, an aggregated re-sult indicating the threat level of each nodeor network area allows for faster identificationof suspicious activity, with less information totraverse through. Thus, while this query hasimportance, it is certainly less so than a queryof the threat level of each node. Ideally, thethreat level of each event should be providedas finer grain information available upon selec-tion of a node or area of interest.

The username that yielded each event hasimportance in determining actual victims andsuspects. An attacker could spread their ac-tivity across multiple nodes on the network,effectively minimising the perceived suspicionlevels of their activity. While this does showthe importance of this visual query, it is moreintuitive to the user to be presented with anoverview based on the network topology, thenallow the username generating each event tobe provided as more in detail information dis-played when a particular node or network areais selected.

3 Design Approach

An iterative design approach was taken in thedesign of the visualisation. The design con-sisted of three iterations, each involving sev-eral common steps. First, a paper prototypewould be produced, illustrating ideas to im-prove on the previous design iteration. Rettig[5] reasons how high fidelity prototypes takea significant amount of time to both build andchange, then argues how paper prototypes con-trast this, being both fast to develop and easyto learn. Thus, adopting this approach al-lowed rapid prototyping of individual visual-isation concepts with a minimal time invest-ment. Once a suitable idea was obtained, theidea would be produced as a digital mock-upprototype. The production of these digital pro-totypes utilised a combination of Inkscape [7],an Open Source vector based graphics editor,and d3 [1], an Open Source, data-driven visual-isation framework. The flexibility offered by d3allows its use for both rapid, low fidelity proto-types, as well as a production quality visualisa-tion. Using this approach, the design iteration

could be illustrated at a suitable level of fidelityfor evaluation without an unnecessary time in-vestment. Taking a more interactive approachthrough the use of a visualisation frameworkallowed an iteration’s interaction concepts tobe illustrated and communicated more easilythan what is often possible with a paper pro-totype. Finally, feedback would be obtained onthe design iteration using the mock-up proto-type, providing input for future iterations.

Along with the formulated design goals anduser requirements, two additional considera-tions were kept in mind throughout each it-eration: the scalability of the design and itsapplication of information visualisation tech-niques.

The scalability of each design iterationis largely dependant on how many networknodes, as well as how many network connec-tions the iteration can display effectively. Fig-ure 2 illustrates a common problem with tradi-tional node-link graph visualisations. In caseswith a large number of interconnected nodes,readability is lost as edges clutter and overlap.As can be seen, the problem is worsened as thenumber of nodes and connections increase. Anobservation highlighted in the design chapterwas the apparent trade-off between the num-ber of visual queries offered and scalability inprevious work in the area of network securityvisualisation. This is understandable, as it isinevitable for the level of detail that can beused to display each element in the visualisa-tion to become more limited as more elementsneed to be displayed. These issues demonstratehow challenging it can be to provide a scalablenetwork visualisations. To assert the scalabil-ity of the visualisation, each concept containedin an iteration was assessed in terms of it’s ef-fect on the number of nodes and connectionsthat could be displayed effectively by the visu-alisation.

Two visualisation techniques were consid-ered throughout the design phase: the VisualInformation Seeking Mantra [6] and the Focus+ Context technique [2]. In order to effectivelyapply the former technique, each concept con-tained in an iteration was further assessed ac-cording to its effect on the following: providingan overview of the network and network activ-ity, allowing the user to more closely inspect

3

Figure 2: Node-link graph visualisations suf-fering from “edge clutter”

network areas of interest, allowing the user tofilter out network activity irrelevant to theircurrent interests, and allowing the user to ob-tain finer details pertaining to a specific net-work area on demand. As can be recognised,this assessment criteria is closely related to thedesign goals above.

The Focus + Context technique [2] involvessimultaneously providing an overview (con-text) and detailed information (focus). In or-der to effectively apply this technique, eachnew concept for an iteration was assessed ac-cording to its ability to simultaneously provideinformation relating to an overview of the net-work and detailed information about a partic-ular network area. With the technique prop-erly applied, the user will be able to focus onsuspicious activity in a particular area withoutlosing context of the entire network’s activity.

4 Design Evaluation

Norman [4] introduced the concept of user-centered design. Norman explains how usercentered design emphasizes that the purposeof the system is to serve the user, and thatthe needs of the users should dominate the de-sign of the interface. The visualisation’s designapproach required feedback to be obtained atthe end of each design iteration as input forthe next iteration. Additionally, the visualisa-tion’s design goals were derived with consid-eration for the identified user requirements, aswell as the inferred typical use case. Hence, thedesign approach described exhibits propertiesinherent to user-centered design.

This approach was adopted for several rea-sons. Modelling the design goals based on user

requirements was an important starting point.This allowed us to more accurately orientatethe design around the user’s needs, as opposedto basing the design on a trivial one to onemapping from the data provided, or on userneeds formulated by assumption. Obtainingfeedback each iteration ensured that the user’sneeds and how intuitive user’s find the designwas given close attention each iteration. Thismethod of continuous feedback also preventedpersonal biases from affecting the design.

The design phase consisted of three itera-tions. Feedback for the first iteration was ob-tained from our project’s co-supervisor andsecond reader. As the first iteration pre-sented the base concepts for the visualisation,it was important to receive input from multiplesources in order to obtain a good idea on wherethe base idea needed improvement. Since ma-jor changes were introduced in the second iter-ation, it was important to get feedback on theprogress from the first iteration. Consequently,feedback on the second iteration was again ob-tained from the project’s co-supervisor. Fi-nally, to assert that the needs of the intendedend users are met, feedback on the third it-eration iteration of the design was obtainedfrom an expert user, a system administratorat UCT. A discussion on the evaluation resultsof each iteration can be found in its respectivesection below.

5 Iteration 1

The first iteration provided a number of baseconcepts carried through the design phase. Inaccordance with the ranked visual queries, thefirst iteration displays network activity using anetwork-centric approach. As depicted in Fig-ure 3, nodes are grouped and displayed in a hi-erarchical fashion based on the network topol-ogy. Each circle represents a node or group ofnodes, where a “full” circle (circle with a fill)represents a single node and a “hollow” circle(circle with only a border) represents a “col-lapsed” (aggregated) group of nodes. Nodesexternal to the network are represented by theoutside circles clustering around the big “inter-nal network” circle.

A node group can be expanded by doubleclicking on the group’s circle, resulting in a

4

Figure 3: Iteration 1 showing a partially col-lapsed, partially expanded network node hier-archy

group of nodes enclosed inside a “parent” cir-cle. The user can view connections to a singlenode or group of nodes by selecting the corre-sponding circle with a single click. This resultsin unconnected nodes or node groups greyingout, as illustrated in Figure 4. The selectednode is represented by applying a “crosshair”decoration to the corresponding circle.

Figure 4: Iteration 1 showing connections tothe selected node group (marked with a cross-hair symbol)

The iteration first presents an overview,

showing node activity at the highest level ofgranularity. Once a network area yielding sus-picious activity is identified, expand or drill-down functionality allows the user to zoom inon nodes of interest. As the user selects a nodeor node group to view the node or group’sassociated network connections, unconnectednodes are filtered out of the user’s focus as theygrey out. This demonstrates the application ofthe Visual Information-Seeking Mantra tech-nique. Through the application of this tech-nique, the visualisation assists the user in iden-tifying suspicious network activity, thus com-plying with an identified design goal. Further-more, by greying out nodes not connected tothe selected node, application of the techniqueaccomplishes another design goal: filtering outnetwork details irrelevant to the user’s inter-ests.

Another information visualisation techniqueapplied was the Focus + Context technique.By allowing the user to drill-down into a spe-cific network area using the expand functional-ity, the context of the entire network’s activityis maintained, whilst displaying a finer detailfocus on the network area of interest. Addi-tionally, the drill-down ability provided sup-ports two design goals. Firstly, this allows theuser to explore the network activity by meansof the network topology domain. Secondly, thedrill-down functionality, as well as the abilityto display connections to a node or group ondemand, both provide the user with finer de-tails relating to the network area of interest.

Once complete, the iteration was evaluatedby means of feedback from the project’s co-supervisor and second reader, Patrick Marais.A recurring criticism was that the randomarrangement of external nodes does not pro-vide any useful information. The designwould indeed benefit from a more organisedor meaningful arrangement. A noteable crit-icism was the visualisation’s inability to pro-vide an overview of the network connections,instead only providing connections to an indi-vidual node. With reference to the formulateddesign goals and visual queries, providing anoverview of the network connections certainlyis an important query to support. Moreover, itwas pointed out that simply leaving connectednodes in colour and greying out unconnected

5

nodes is not an intuitive association to rep-resent connections. Another important pointgiven was that the visualisation does not intu-itively suggest that node group circles can beexpanded. A suggestion given was switchingthe node type visual cues, such that “hollow”circles are used to represent individual nodes,and “full” circles are used to represent groupsof nodes. The suggested switch is more intu-itive, since a “full” visual glyph hints at anobject with contents, while “hollow” hints atan object that does not contain anything. Fi-nally, it was noted that the visualisation doesnot utilise screen space effectively. This is anapparent drawback in the use of a radial ar-rangement of the network hierarchy. Conse-quently, future iterations should aim to makebetter use of the empty screen space on the leftand right of the design.

6 Iteration 2

The second iteration was designed with the re-sults of the first iteration’s evaluation in mind.Shown in Figure 5, nodes at the top level ofthe hierarchy extend to fill the screen widthavailable instead of limiting this top level toa circular shape, allowing better utilisation ofthe screen space available. Additionally, “full”circles now represent node groups, while “hol-low” circles represent single nodes. As sug-gested during the first iteration’s feedback, thisis more intuitive, since “full” circles are moresuggestive of node aggregations and “hollow”circles of individual nodes.

Figure 5: Iteration 2 showing a partially col-lapsed, partially expanded network node hier-archy

A major change presented in this design it-eration was the display of connections betweennodes or node groups, represented as linesbetween the corresponding circles. Connec-tion lines are “bundled” together and routedthrough the circle centers of the different lev-els of the network hierarchy before meeting attheir destination circles. This prevents linesfrom cluttering the visualisation and obstruct-ing both nodes and each other (the “edge clut-ter” issue depicted in Figure 2). When a nodeor group circle is selected with a single click,connections irrelevant to the node or group aregreyed out as illustrated in Figure 6. This fil-ters out network connections irrelevant to theusers current interests, fulfilling an importantdesign goal. In contrast to the first iteration,nodes not connected to the selected node orgroup remain in colour. This allows the userto maintain context of the entire network’s ac-tivity when inspecting connections to a specificnetwork area.

Figure 6: Iteration 2 showing showing connec-tions to the selected node (marked with a cross-hair symbol)

To evaluate iteration 2, feedback was ob-tained from our project’s co-supervisor. Basedon the feedback given, it was apparent thatthe design was more intuitive. A change wassuggested for the current visual cue used torepresent the current node or group selection.Instead of the design’s current use of a “cross-hair” decoration on the selected circle, the sug-gestion was to use a “halo” effect underneaththe selected circle. Using such an effect is morenoticeable, as well as more intuitive. A de-tail discussed during the evaluation was visualqueries still to be supported. Noticeably, an

6

important visual query not yet supported is thetime of each event’s occurrence. One sugges-tion given was to use a separate view showingtime of event details for the currently selectednode or node group.

7 Iteration 3

Based on the discussion that took place dur-ing the evaluation of the previous iteration, thethird iteration of the design focused on includ-ing support for an important visual query, thetime of each event’s occurrence. Shown in Fig-ure 7, this iteration of the design introduced adynamic representation of the network basedon the time each event occurred. This con-trasts the static representation approach usedin previous iterations of the design, where anoverview of the total accumulated network ac-tivity was displayed. A stacked area chart atthe bottom of the display represents the totalnetwork events over time. The three differentarea colours on the chart shows the ratio ofthreat levels over time, and corresponds to thethreat level colours used for nodes and groupsin the main view. As the user drags the markeron the chart, the visualisation changes accord-ingly to represent the network’s state based onthe marker’s new position in the time domain.To show the change in network dynamics as theuser drags the marker, node circles “grow” or“shrink” according to changes to their fractionof the total network events. A node generatingevents frequently can easily be identified, as itscorresponding circle’s will continuously grow insize on the display. Similar to the node size dy-namics, nodes will also change colour based ontheir threat level as the user browses the timedomain. Additionally, network nodes and net-work connections will transition in as they areestablished along with their corresponding newevents.

This dynamic visualisation approach waschosen for several reasons. First, this allowsthe visualisation to support an important vi-sual query, and without needing to separate thevisual query into an additional display. Thisapproach allows the user to explore networkactivity through the time domain, achievingan identified design goal. With this methodof exploration, the user can diagnose when ex-

Figure 7: Top: Iteration 3’s view of the net-work at a low activity time, Bottom: Iteration3’s view of network at a high activity time

actly suspicious activity took place. Moreover,this method provides the user with insight intothe evolution of suspicious activity. Finally,utilising this approach allows the user to focuson network activity at a particular time us-ing the main view, whilst maintaining contextof the overall network activity over time usingthe area chart view. Hence, this approach canbe considered an application of the Focus +Context visualisation technique.

In accordance with a valuable suggestiongiven as part of the previous iteration’s feed-back, this iteration used a different visual cueto represent the currently selected node orgroup of nodes. Illustrated in Figure 8, thedesign was changed to use a “halo” effect onthe selected circle. Clearly, this visual cue ismore noticeable and intuitive, as well as more

7

aesthetically pleasing.

Figure 8: Iteration 2 showing showing connec-tions to the selected node (marked with a cross-hair symbol)

Feedback on this design iteration was ob-tained from a system administrator at UCT.The iteration’s mock-up prototype was shownalong with an outline of the purpose of the sys-tem and a brief explanation of the design. Theparticipant then asked a few questions on thedesign that were not addressed in the explana-tion. With the questions addressed, the designappeared well understood, and the participantacknowledged the visualisation’s advantage forexploring large volumes of security event in-formation over textual analysis. Although theparticipant appeared content with the design,an important comment given was that moredetailed information needs to be shown whenthe user selects a particular node. This high-lights the importance of the associated designgoal: providing finer details relating to an areaof interest, and in the this case, the networknode of interest. Consequently, attention wasgiven in the implementation phase to providingmore detailed information relating to selectednetwork nodes.

References

[1] Bostock, M., Ogievetsky, V., andHeer, J. D3: Data-driven docu-ments. IEEE Trans. Visualization &Comp. Graphics (Proc. InfoVis) (2011).

[2] Card, S. K., Mackinlay, J. D., andShneiderman, B., Eds. Readings in infor-mation visualization: using vision to think.

Morgan Kaufmann Publishers Inc., SanFrancisco, CA, USA, 1999.

[3] Komlodi, A., Goodall, J. R., andLutters, W. G. An information vi-sualization framework for intrusion detec-tion. In CHI ’04 extended abstracts on Hu-man factors in computing systems (NewYork, NY, USA, 2004), CHI EA ’04, ACM,pp. 1743–.

[4] Norman, D., and Draper, S. User cen-tered system design; new perspectives onhuman-computer interaction. L. ErlbaumAssociates Inc., 1986.

[5] Rettig, M. Prototyping for tiny fingers.Commun. ACM 37, 4 (Apr. 1994), 21–27.

[6] Shneiderman, B. The eyes have it: Atask by data type taxonomy for infor-mation visualizations. In Proceedings ofthe 1996 IEEE Symposium on Visual Lan-guages (Washington, DC, USA, 1996), VL’96, IEEE Computer Society, pp. 336–.

[7] Team, T. I. Inkscape.

8