A Formal Symbology for Network and Incident Visual is at Ion

8/8/2019 A Formal Symbology for Network and Incident Visual is at Ion

1/21

A Formal Symbology For Network And

Incident Visualisation

November 26, 2001

Stephen P. Berry

[email protected]

Abstract

1. Introduction

2. Symbols

2.1 Design Requirements

2.2 Standard Symbols

2.2.1 Network Symbols

2.2.2 Host Symbols2.2.3 Modifiers/Features

2.3 Basic Usage Rules

2.3.1 Labelling and Grouping

3. Incident Diagrams


3.2 Standard Diagrams

3.2.1 Line of Contact (LOC)3.2.2 Phase Lines (PL)

3.2.2.1 Recon Line (RL)

3.2.2.2 Exploitation Line (XL)

3.2.2.3 Dormancy/Remediation Line (DL)3.2.3 Protocol Marker

3.2.4 Phase Change Line

3.2.5 Isochrons (IC)

3.3 Basic Usage Rules3.3.1 Stacking

Appendix A. Symbol Examples

Appendix B. Incident Diagram Examples

Appendix C. Acknowledgements

Appendix D. Revision History


2/21

Abstract

This document proposes a set of procedures for representing computer networks and

incidents involving them. It presents a set of symbols for standard network and computer

hardware and rules for modifying these symbols for particular uses. In addition, it

presents a set of guidelines for preparing diagrams of network incidents using thestandard symbols.

This manual is designed to be used by network and systems administrators, and network

security and incident handling personnel.

1. Introduction

This document exists primarily for two reasons:

Existing network symbology(-ies) suck

Analysing NIDS data is hard

A more formal document would probably state the first point more judiciously, but that

would only serve to obscure the fact that this is largely a subjective judgement. The very

real problem with existing symbologies, however, is that they tend to be fairlyinformation-poor and they tend to be limited in scope. In other words, they aren't

adequate to represent the breadth of complexity of current networks, and it is generally

difficult to present large volumes of information using them. A pretty line drawing of a

Cisco 2600 might look good on a slide, but it doesn't convey much of use to a seriousanalyst. In addition, diagrams made using existing symbologies are fairly non-portable---

try reproducing a diagram done in Visio ordia(1x) using xfig(1)...or on a whiteboard.

Being able to create graphical representations of networks and network incidents isnevertheless very important. Network intrusion detection systems are very good at

collecting huge volumes of data in a hurry. Few are capable of summarising all that data

in such a way that an analyst can get an overview of a large-scale incident at a glance,

however.

It is as an attempt to address the two problems mentioned above that this document is

presented. The system outlined in this document is inspired by symbologies used to

represent another class of very complex environments: land-based military operations. It

is not an attempt to merely copy or mimic such symbologies. The flexibility and capacity

to convey great detail using sparse notation is, hopefully, something that was borrowedfrom existing military symbology. The conventions used in constructing diagrams are

radically different, however, and reflect the significant differences between the systemsrepresented.

This document consists of two main parts: A set of symbols and notations for

representing network devices; and a system for diagraming network incidents. In


3/21

addition, appendices containing additional examples can be found at the end of this

document.

This document should be considered a draft. Comments, suggestions, and other forms offeedback are solicited.

2. Symbols


To avoid reproducing the shortcomings of existing network symbologies, a number of

design requirements were enumerated prior to design of the actual symbols. Theserequirements should be considered if the system is revised at a later date. The symbols

should be:

Featural

o Symbols consist of simple, atomic componentso Components can be combined in logical ways

o Symbols are not representational (i.e., a PC doesn't look like a beige box)

Easily Whiteboarded

o Symbols should consist of components which can quickly and

unambiguously rendered by hand.

Easily Distinguished

o Symbols should be easy to distinguish from one another, even when the

symbols are small, low-resolution, or hand-written.

Distinct From Existing NATO (ATP-6) Symbolso The symbols should not be identical, and when possible should not

resemble, existing symbols used to represent land warfare units.Q: What's the 1st Battalion, 3rd Marines doing in my DMZ?A: Whatever the hell they want.

Shapes (squares, rectangles, and so on) should be used distinctively to represent specific

roles. I.e., a router should have a shape which is distinctive compared to the shape of a

client host.

Lines, arrows, and other optional components should be used to represent specific

capabilities or functionalities. I.e., to distinguish a filtering router and an `open' router,

which would otherwise share the same basic shape.


4/21


5/21

Table 2.2.2 Host Symbols

Name Symbol Description

Host A generic host machine

Client A generic Desktop/Workstation/Client Host

Laptop A generic portable host (i.e., a laptop)

Appliance A generic network-attached appliance

Printer A generic network-attached printer

Scanner A generic network-attached scanner

File Server A generic network-attached storage device (i.e., a file server)

Symbols for generic hosts are presented in this section. For examples of symbols for

more specific host types and features, see Appendix A.

2.2.3 Modifiers/Features

The modifiers and features presented in this section are intended to represent specific

functions and capabilities. In the table below, the features are drawn with solid blacklines. The device symbols are drawn with dashed grey lines. This is to help distinguish

between the basic symbol and the modifier or feature. In normal usage, the device

symbols would be drawn with solid black lines as well.


6/21

Table 2.2.3 Modifiers and Features

Name Feature Meaning

Hardened Device has been hardened

Portable Device is portable

Remote Access Device connects to remote network[1]

Wireless Device is capable of wireless communication

NIDS Device does network intrusion detection

HIDS Device has host-based intrusion detection capabilities

External Device is external to local networks[2]

Compromised Device is known to be compromised

Notes

1. I.e., via a modem.

2. The `external' feature is provided for convenience when a black

and white diagram is necessary. For other purposes, representing differentnetwork associations may be accomplished by using multiple colours.


7/21


2.3.1 Labelling and Grouping

Labels may be added to symbols to present additional information or detail aboutparticular devices. In general, information about the composition of the device (physicalcharacteristics, OS, and so forth) should be placed outside the symbol box. Information

about the configuration of the device and other things easily changed should be stored

inside the symbol box. This distinction is somewhat subjective. The guiding principleshould be: information about a machine that is unlikely to change during an incident

should be printed outside the symbol box; information could easily be changed during an

incident should be printed inside the box.

The operating system and hardware platform of a device may be indicated by placing alabel directly above the device's symbol. The labels should be drawn in a boldface font,

preferably a serif font. The operating system should be printed first, followed by a slash,followed by the hardware platform.

Figure 2.3.1a Group Label

Multiple devices may be represented by a single symbol by placing the number ofdevices over the symbol. If the devices are all of the same type, the OS/architecture label

may follow the number. If the devices are of different types, only the number should be

used.

The port number(s) associated with a service offered by a network server may be printedinside the symbol box. The label should be printed in a bold font immediately above the

server symbol. A colon may be placed before the number for disambiguation. Similar

symbols may be used for client machines if such information is relevant to the incidentpresented in the diagram.

A single, undotted decimal number above the device symbol inside the symbol box

should therefore be assumed to be a port number.

Figure 2.3.1b Labelled Web Server


8/21

Routers and other multihomed devices may be labeled with the subnets on which they

have interfaces. A device with two interfaces should be labeled with one subnet above the

device symbol, and one subnet below the device symbol, both inside the symbol box.

Figure 2.3.1c Labelled Border Router

A single-homed device may be labeled with it's subnet if the information is relevant. A

machine labeled this way should have the subnet label printed below the device symbol,inside the symbol box.

3. Incident Diagrams


Diagrams constructed using the proposed methods should be able to:

Convey scope of an incident

Depict multiple stages of an incident in progress

Show relationship(s) between target hosts and attacking/probing hosts

Provide meaningful information about the channel(s) of communication used Conform to the design requirements for the symbols themselves (outlined in

section 2.1 of this document)

No diagram can convey all the information an analyst might be interested in while

dealing with an incident. Any attempt to do so would fail, and the resulting diagramwould be hopelessly ornate. The intent is to provide the same sort of information one

analyst might give to another in a phone conversation, in a presentation, or in a brief

email message. That is, enough information to adequately describe the situation withoutattempting to diagnose or enunciate the actual technical issues causing the incident or

resulting from it.

One of the envisioned uses for such diagrams is in the automatic generation of situation

reports (i.e., by an GUI frontend for an NIDS) for triage during an incident in progress.

3.2 Standard Diagrams

3.2.1 Line of Contact (LOC)

A line of contact represents communication between two or more devices. Lines of

contact are heavy, dashed lines drawn between two symbols.


9/21

Lines of contact may be used to connect symbols representing different numbers of

devices. For example, a line of contact may be used to connect a symbol representing a

single device and a symbol representing a group of machines.

It is important to note that a LOC is not synonymous with a session or conversation. It is

more likely that a LOC will represent traffic matching a particular pattern or attacksignature. This is because an incident diagram cannot (and should not) contain all traffic

involving the machines in it---just the traffic related to the incident. For a more detaileddiscussion of this distinction and examples illustrating it, see Appendix B.

Figure 3.2.1 Line of Contact

3.2.2 Phase Lines (PL)

The basic graphic which distinguishes different stages of an incident is called aphaseline. Phase lines are light, dashed lines which run vertically. Devices to the left of a phaseline have have not reached the stage represented by the phase line. Devices between two

phase lines are in the stage indicated by the left phase line.

Multiple phase lines of a single type may be drawn in a diagram. For example, one phase

line per line of contact may be drawn to offer visual representation of the order ofcontacts between multiple hosts. When multiple instances of a single type of phase line

are used, each phase line should be numbered. Examples may be found in Appendix B.

Figure 3.2.2 Phase Lines

3.2.2.1 Recon Line (RL)

The recon phase line is used to delimit the stage of an incident that corresponds to anattacker gathering information about the target network or hosts.

Examples of traffic passing between an attacking host and a target in this phase mightinclude: ICMP echo requests; traffic associated with vulnerability scanners; or the

establishment portion of traffic associated with a worm or DDOS tool. This traffic will

typically originate outside the local network, and be directed at local hosts.


10/21

3.2.2.2 Exploitation Line (XL)

The exploitation phase line is used to delimit the stage of an incident that corresponds to

actual compromise of hosts and networks.

Examples of traffic passing between an attacking host and a target in this phase mightinclude: the response portion of traffic associated with a worm or DDOS tool; outboundattempts to spread a worm or virus; new outbound connections associated with DDOS

tools. This traffic will typically originate in the local network, and be directed at remote

hosts.

3.2.2.3 Dormancy/Remediation Line (DL)

The dormancy or remediation phase line is used to delimit the stage of an incident in

which previously compromised hosts are no longer compromised or are no longerparticipating in an incident.

The determination that a device is in this phase will typically be accomplished using a

vulnerability scanner or similar technique. Devices in this phase will typically be

machines on the local network.

3.2.3 Protocol Marker

A protocol marker may be used to indicate the layer 3 or 4 protocol of a line of contact.The protocol name (i.e., ICMP) may be used if space is available, otherwise the protocol

number (1 in this example) may be used.

Protocol markers should be placed along lines of contact, at the intersection of thecorresponding phase line if applicable.

Figure 3.2.3 Protocol Marker

3.2.4 Phase Change Line

The phase change line is a light, dotted line which may be used to indicate that symbols

in different phases represent a single device or group of devices.

When phase change lines are used, they should simply connect whichever symbolsrepresent the same devices. Phase change lines should not be used to connect a symbol


11/21

representing an individual device in one phase with a symbol representing a group in

another phase.

Figure 3.2.4a Correct Phase Change Line

Figure 3.2.4b Incorrect Phase Change Line

3.2.5 Isochron (IC)

An isochron (IC) is a medium weight, solid, crossed line. It is used to to delimit the mostcurrent data on a device (or group of devices) from older data. The ends of the isochron

should be turned up or down in the direction of the symbols representing older data, so asto `enclose' them.

When a diagram includes a device which appears in multiple phases, the symbols

representing such devices are connected with phase change lines. The isochron is abounding figure which separates the symbol representing the most recent data for a

device (the current phase of the incident the device is in) from the other instances of the

symbol. For example, an isochron might be drawn below the symbol representing an

attacking host. Symbols derived from the most recent data for a particular device would

be placed above the line (with the attacker's symbol), while other instances would beplaced below the isochron.


12/21

Figure 3.2.5 Isochron

In the example in Figure 3.2.5, the leftmost symbol represents old data concerning the

device represented by the symbol. The symbol to the right and above the isochron (IC1)represents the most recent data on the device.

Isochrons are optional, and should be employed when they add clarity to the diagram.

Examples of the use of iscochrons may be found in Appendix B. Diagrams with and

without isochrons illustrating the same incident are provided.


3.3.1 Stacking

Multiple symbols may be stacked in a diagram. The primary justification for stacking

symbols is to minimize the amount of space the diagram requires. Symbols should onlybe stacked if:

The symbol appears elsewhere unobscured. The visible symbol should be

connected to the obscured one in the stack via a phase change line (see section

3.2.4).

or

The diagram is interactive and the symbols can be `unstacked' or cycled through.

For example, if the diagram is generated automagically by an GUI which allowsmanipulation of the symbols.

All symbols in the stack are connected to another symbol via a single line of

contact,

orNone of the symbols in the stack are connected to any other symbol via any line

of contact


13/21

Appendix A. Symbol Examples

Table Ai contains several examples of composite symbols. They are provided to illustratehow the basic symbols may be used in conjunction with additional modifiers and

features.

Table Ai Additional Symbol Examples

Name Symbol Type

Bastion Host A bastion host/hardened server

Desktop RAS A desktop with remote access capabilities

Filtering Router A filtering router/router with ACLs

Secure Switch A secure' switch

Wireless Switch A wireless Switch

Figure Aii is a simple network diagram of the conventional style. It is provided to

illustrate how the symbols presented in this document may be used to construct

conventional, hierarchical diagrams using the new symbols.


14/21

Figure Aii A Simple Network Diagram

The diagram in Figure Aii contains:

A Cisco 2510 border router (top symbol). The external interface is on the

172.16.0.0/12 subnet. The internal interface is on the 192.168.0.0/16 subnet. The

router is using ACLs to screen incoming traffic.

A Cisco 2600 being used as a LAN router (third column). The external interface

is on the 192.168.0.0/16 subnet, and the internal interface is on the 10.0.0.0/8

subnet.

A Firewall-1 firewall running on SPARC hardware (middle symbol, second

column), located between the two routers.

Two NIDS sensors running OpenBSD/x86 (symbols on either side of the firewall

box). One is on either side of the firewall. An internal LAN containing:

o Eight (8) servers running Solaris on SPARC hardware.

o Fifty (50) desktops running Windows NT on Intel x86 hardware.

o Twenty-four (24) workstations running Linux on x86 hardware.

The diagram as presented contains an interesting ambiguity or irregularity. Discovering it

(and supplying a possible explanation) is left as an exercise for the reader.


15/21

Appendix B. Incident Diagram Examples

Figure Bi is a fairly detailed example of an incident diagram. A brief description of the

information presented is:

Three hundred and seventeen (317) hosts outside the local network are involvedin the incident. These hosts are represented by the uppermost symbol to the left ofthe leftmost phase line (RL1).

The 317 attackers ping twenty-nine internal hostso One (1) host does not respond to the ping. This host is the one directly

below the attacking 317 hosts

Twenty-eight (28) hosts respond to the attacker's pings. They are subsequently

compromised, and exchange TCP traffic with the attackers. These machines arerepresented by two symbols. First, the topmost symbol between the RLs and the

XL; then between the xL and the DL (the second of these symbols is `stacked'

below another symbol, and therefore is not clearly visible). The first symbol is

connected to the attackers via a line of contact (LOC). It is labeled with a protocolmarker (the `1' indicating the traffic is ICMP), and corresponds to RL1.

Ten (10) web servers, all NT servers running on Intel x86 hardware, are contacted

via TCP by the attackers (second symbol from the top, between the RLs and theXL), and subsequently respond with their own TCP traffic (top symbol between

the XL and the DL).

Six (6) web servers, ALL NT servers running on Intel x86 hardware, arecontacted via TCP by the attackers (bottom symbol, between the RLs and the

XL). These machines are subsequently scanned and found to be `clean' (symbol to

the right of the DL).

Note the phase change lines connecting symbols representing machines that figure inmore than one phase of the incident.


16/21

Figure Bi Incident Diagram Example 1

The situation presented in Figure Bi is a fairly typical example of a network beinginfected by a worm. The advantage of presenting the information this way lies primarily

in allowing an incident analyst to see in detail the sequencing of events in such an

infection, the current scope of the infection, the channel by which the worm is

propagating, and the extent to which damage control on the local network has beensuccessful.

Figure Bii depicts the same situation as Figure Bi using isochrons (as described in

Section 3.2.5).


17/21

Figure Bii Incident Diagram Example 1 With Isochrons

In Figure Bii, the center portion of the diagram (between the two ICs) represents the

current situation as depicted in the diagram. Events above IC1 and below IC2 occurredearlier. The primary reason the isochrons are used is disambiguation. Consider the 6

NT/x86 devices which are first seen between the RLs and the XL, then later to the right

of the DL. Placing the first occurance of the symbols below IC2 allows an analyst toquickly identify what is the most current information about the boxen, while still

presenting valuable historical information about the incident.

One alternative would be to construct several diagrams, each of which would represent

only the most recent data as of some specified time (i.e., if Figure Bii covered data from1600 to 1900 on one day, three diagrams might be constructed: a diagram covering data

from 1600 to 1700; then 1700 to 1800; and finally 1800 to 1900). The disadvantage to

this method is that there are seldom discrete and obvious epochs of wall-clock time intowhich an incident can be divided. The scan of a subnet might take days, or may be


18/21

accomplished in seconds. Exploit attempts based on the information the attacker gained

from the reconnaissance scan may follow sequentially and proceed serially, or may occur

concurrently with the scan, and attack hosts in parallel. In short, the analyst can not relyon an incident to follow convienient quanta of time (as measured by a wall clock or

calendar), and so a system for representing incidents should not, either. Using phase

change lines allows a diagram to be constructed which covers as much time as isnecessary to depict the entire incident. During this time, a single device might be

involved in multiple stages of the incident, and its role may well change. The phase

change lines allow that information to be conveyed. Isochrons are intended to allowcurrent and historical data to be easily distinguished.

Figure Biii contains another example of an incident diagram. The information presented

in the diagram is:

A single host outside the local network is involved in the incident

The attacker pings seventeen (17) FreeBSD web servers.

All 17 web servers respond to the ping The attacker attempts a TCP connection to the 17 web servers

None of the web servers responds

All 17 web servers are subsequently discovered to be uncompromised

Figure Biii Incident Diagram Example 3

Note the phase change lines indicating that the three group symbols all represent the same

machines. Also note that the response phase (between the XL and the DL) is empty.

It is worth reiterating at this point that a line of contact (LOC) is not synonymous with aconnection or session. The fact that the TCP LOC does not cross the RL does not

necessarily indicate that the web servers did not send any TCP traffic back to the attacker.

The signature or pattern represented by the LOC may simply indicate that the TCP trafficdid not match a particular attack signature. Traffic not matching the signature would not

cause the LOC to run over the RL.


19/21

The reason this is stressed is that the incident diagrams are intended to convey

information about scan and attack patterns. Traffic not indicative of actual incident

should not `escalate' the LOC across the RL.

In constructing Figure Biii, the logic might go something like this:

ICMP ECHO_REQUEST traffic arrives from some attacking hostfoo. This

creates a LOC between the symbol forfoo and the group symbol for the target

machines. At this point, the LOC would remain to the left of the RL

The target machines respond tofoo with ICMP ECHO_REPLYs. Now the LOC

crosses the RL, and the symbol for the target machines moves to the right of the

RL

foo now sends some cookbook IIS exploit to the target machines. This involvesHTTP traffic. The exploit matches a signature, so it creates a LOC between foo

and the target machines. Normal HTTP traffic (not matching any pattern or

signature) would not create a LOC...the analyst is only interested in diagramming

incidents, not day-to-day operations The target web servers respond with a 404 error or something appropriate. They

do not respond like a newly-compromised IIS instance, so they don't match thesignature for such an event. As a result, the LOC doesn't cross the RL line, and

the symbol stays to the left of the RL.

An independent audit event (i.e., running a vulnerability scanner internally)determines that the web servers are not vulnerable to the exploit attempted, so the

machines can be placed to the right of the DL.

Phase change lines connect the identical groupings in different phases.

The power of this method is that it allows automated tools to apply simple signatures

(and possibly statistical or other tests) to traffic and construct diagrams like Figure Biii.By combining multiple signatures/patterns/tests, this helps minimise the occurrence of

false positives while still keeping the analyst apprised of failed exploit attempts.


20/21

Figure Biv depicts the same situation as Figure Biii, with the inclusion of isochrons.

Figure Biv Incident Diagram Example 3 With Isochrons

The data are the same as in Figure Biii. All of the most recent data for each involved

device are placed above IC1. Symbols derived from older data are placed below and

`inside' IC1. The advantage to this version of the diagram is clarity: The analyst can seeat a glance the current situation, but can also see prior stages of the incident without

consulting additional sources. The phase change lines are also easier to follow, and the

graphic as a whole suggests more of a progression than the prior example.


21/21

Appendix C. Acknowledgements

The NATO symbols used to depict land warfare units were one of the primaryinspirations for the system presented in this document. Primary author unknown.

The symbol used for firewalls in this document was originally used by Marcus Ranum.

Its appearance here is an act of crass thievery.

Appendix D. Revision History

17 October 2001

Initial draft26 November 2001

Revision, including:

Addition of colons before port numbers Addition of `compromised' feature

Change in phase line nomenclature. `Proble Line (PL)' becomes

`Recon Line (RL)' and `Response Line (RL)' becomes `Exploitation Line

(XL)'

Addition of isochrons (ICs)

Documents

A Formal Symbology for Network and Incident Visual is at Ion