Embed Size (px)
DESCRIPTION
Symbols for networks
Citation preview
A Formal Symbology For Network And Incident VisualisationNovember 26, 2001
Stephen P. Berry
Abstract
1. Introduction
2. Symbols
2.1 Design Requirements2.2 Standard Symbols
2.2.1 Network Symbols2.2.2 Host Symbols2.2.3 Modifiers/Features
2.3 Basic Usage Rules2.3.1 Labelling and Grouping
3. Incident Diagrams
3.1 Design Requirements3.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 Marker3.2.4 Phase Change Line3.2.5 Isochrons (IC)
3.3 Basic Usage Rules3.3.1 Stacking
Appendix A. Symbol ExamplesAppendix B. Incident Diagram ExamplesAppendix C. AcknowledgementsAppendix 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)
