A Formal Symbology For Network And

Incident Visualisation
November 26, 2001

Stephen P. Berry

spb@meshuggeneh.net

Abstract

1. Introduction

2. Symbols

2.1 Design Requirements

2.2 Standard Symbols
2.2.1 Network Symbols
2.2.2 Host Symbols
2.2.3 Modifiers/Features
2.3 Basic Usage Rules
2.3.1 Labelling and Grouping

3. Incident Diagrams

3.1 Design Requirements

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 Rules
3.3.1 Stacking

Appendix A. Symbol Examples

Appendix B. Incident Diagram Examples
Appendix C. Acknowledgements
Appendix D. Revision History
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 the
standard 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 fairly
information-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 serious
analyst. In addition, diagrams made using existing symbologies are fairly non-portable---
try reproducing a diagram done in Visio or dia(1x) using xfig(1)...or on a whiteboard.

Being able to create graphical representations of networks and network incidents is

nevertheless 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 borrowed
from existing military symbology. The conventions used in constructing diagrams are
radically different, however, and reflect the significant differences between the systems
represented.

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
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 of
feedback are solicited.

2. Symbols

2.1 Design Requirements

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

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

Featural
o Symbols consist of simple, atomic components
o 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) Symbols
o 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.
2.2 Standard Symbols

2.2.1 Network Symbols

The basic network symbol is an horizontal rectangle (a rectangle wider than it is tall).

When possible, lines specific to individual symbols should be heavy, solid lines. Lines
common to all symbols (i.e., the border around the entire symbol) should be solid lines of
normal weight.

Table 2.2.1 Network Symbols

Name Symbol Type

Network Device A generic network device

Server A generic network server

Router A generic router

Gateway A border router or gateway

Firewall A generic firewall

Switch A generic switch or hub

Symbols for generic network hardware are presented in this section. For examples of
symbols for more specific hardware and features, see Appendix A.

2.2.2 Host Symbols

The basic host symbol is a vertical rectangle (a rectangle taller than it is wide).

When possible, lines specific to individual symbols should be heavy, solid lines. Lines
common to all symbols (i.e., the border around the entire symbol) should be solid lines of
normal weight.
 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 black
lines. 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.
 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 different network
associations may be accomplished by using multiple colours.
2.3 Basic Usage Rules

2.3.1 Labelling and Grouping

Labels may be added to symbols to present additional information or detail about

particular devices. In general, information about the composition of the device (physical
characteristics, 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 principle
should 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 a
label 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 of

devices 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 printed
inside 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 incident
presented 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

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

3.1 Design Requirements

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 diagram
would 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 without
attempting 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.
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 attack
signature. 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 detailed
discussion 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 a phase
line. Phase lines are light, dashed lines which run vertically. Devices to the left of a phase
line 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 of
contacts 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 an
attacker gathering information about the target network or hosts.

Examples of traffic passing between an attacking host and a target in this phase might
include: 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.
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 might
include: the response portion of traffic associated with a worm or DDOS tool; outbound
attempts 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 longer
participating 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 the
corresponding 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 symbols
represent the same devices. Phase change lines should not be used to connect a symbol
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 most
current 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 as
to `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 a
bounding 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 be
placed below the isochron.
 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 Basic Usage Rules

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 only
be 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 allows
manipulation of the symbols.
All symbols in the stack are connected to another symbol via a single line of
contact,
or
None of the symbols in the stack are connected to any other symbol via any line
of contact
Appendix A. Symbol Examples

Table Ai contains several examples of composite symbols. They are provided to illustrate
how 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.
 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.
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 involved
in the incident. These hosts are represented by the uppermost symbol to the left of
the leftmost phase line (RL1).
The 317 attackers ping twenty-nine internal hosts
o 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 are
represented 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 protocol
marker (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 the
XL), 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, are
contacted 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 in
more than one phase of the incident.
 Figure Bi Incident Diagram Example 1

The situation presented in Figure Bi is a fairly typical example of a network being

infected 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 been
successful.

Figure Bii depicts the same situation as Figure Bi using isochrons (as described in
Section 3.2.5).
 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 occurred
earlier. 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 to
quickly 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 from
1600 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 into
which an incident can be divided. The scan of a subnet might take days, or may be
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 rely
on 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 is
necessary 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 allow
current 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 a
connection 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 traffic
did not match a particular attack signature. Traffic not matching the signature would not
cause the LOC to run over the RL.
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 host foo. This
creates a LOC between the symbol for foo 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 to foo 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 involves
HTTP 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 the
signature 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.
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 see
at 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.
Appendix C. Acknowledgements

The NATO symbols used to depict land warfare units were one of the primary
inspirations 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 draft
26 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)