Datascape for Cyber-Security NSA Cyber Defence Exercise Worked Example

Transcription

1 Datascape for Cyber-Security NSA Cyber Defence Exercise Worked Example In 2009 the National Security Agency/Central Security Service (NSA/CSS - ran the annual Cyber Defense Exercise (CDX This annual event, sponsored by NSA/CSS, is a computer security competition designed to foster education and awareness among future military leaders about the role of information assurance (IA). During the CDX, NSA/CSS network specialists challenged teams in their abilities to defend the closed computer networks that the students had designed, built and configured at their respective schools. Teams from the U.S. Air Force Academy, U.S. Coast Guard Academy, U.S. Merchant Marine Academy, U.S. Naval Academy, and West Point participated at their respective schools. Also participating was the Air Force Institute of Technology, the Naval Postgraduate School and, for the first time, an allied partner school the Royal Military College of Canada. The 2009 competition was won by the United States Military Academy at West Point (their equivalent of Sandhurst in the UK, my alma-mater), and conveniently the datasets from their entry have been released into the public domain and are available, with supporting information, at and There are three main datasets: The ITOC NSA (Attacker) Firewall Log taken from a machine located outside of the protected network and recording the events from the attacker s point of view. USMA outside Firewall Log taken from a firewall at the boundary of the protected network and recording the events from the victim s point of view. USMA Snort log taken from a machine located within the USMA network and recording suspicious behaviour in that network based on the Snort rules. In order to see how Datascape might be able to visualise this sort of cyber data we brought extracts of all three datasets into Datascape. Initially we imported 1000 log entries from each system, corresponding to 2-3 minutes of ITOC data, 6 minutes of outside data and 3.5 hours of Snort data (note that the time periods did not necessarily overlap). Please bear in mind that we are not cyber-security, or even network data, experts, so we don't have the expertise to look at the data or these visualisations and tell you what is happening, or where the threats may be, but hopefully even so they serve to show how Datascape can take a cyber-security dataset and render a visualisations that might both a) make sense and be useful to an expert in understanding what is going on and identifying a potential threat and b) be used by that expert to explain the activity to a non-expert in a very clear, understandable and memorable way. As ever some data cleansing (particularly removing nulls and invalid IP addresses), and enrichment (splitting the IP address into 4 fields, splitting the single log files into seperate node and edge files) was required, and all achieved within Excel/OpenOffice. And please bear in mind we know nothing about cyber-security we are effectively lay users 1

2 looking to see if we can find what might be interesting patterns and anomalies. If some cyberexperts would like to use Datascape to properly analyse this dataset then please get in touch. ITOC (External) Data To the laymen the ITOC data was by far the most interesting, so lets start there. This is an extract of the node data after cleansing/enrichment. Note that we've used Excel functions to split the IP address into its four component byte and to add the Source/destination End flag. The Node list was derived from the link list provided. And here is the link data. Again we've used Excel functions to generate the NodeBId by just offsetting the NodeAId by 1000 (the number of links). Note that in this data each node is an IP address at a moment in time, so one PC will have a separate node for each link its a part of. These were then imported into Datascape and mappings created as follows: 2

3 For the nodes: Note that: We have used the event ID as a proxy for time (since we only have 1s resolution in the data, but often many events per second), and placed time/id on the Z axis Have used the Y axis for the MSB of the IP address, as a proxy for network Have used the X axis for the LSB of the IP address, as the identity for a particular device Mapped Shape to whether the node originated (sphere) or received (cube) the exchange Mapped Colour to some of the more interesting Ports (92 ports were present in total, we have mapped about 10) The factors for X, Y and Z are just to get a usable layout. For the edges: 3

4 Note that: We have mapped Colour to the network protocols (EIGRP=Red, TCP=Green, UDP=Orange) The resulting plot is shown below: In this visualisation: We are looking down a time-tunnel, oldest data closest to us Each horizontal layer is a different network (defined by MSB of IP address) Each point on a line/layer across the screen is a different device/ip LSB Each line of points down the time tunnel is a different devices's transactions Just from this view (which is only a few minutes data) we can see: Frequent activity on the bottom layer (actually the 10.n.n.n network) between low numbered devices across TCP and UDP Consistent activity between low numbered devices on the 10.n.n.n network and low numbered devices on a high numbered network (actually ) using the EIGRP protocol A regular but infrequent between a low and high numbered device on the 10.n.n.n network Bursts of UDP activity between high numbered devices on the 10.n.n.n and a high numbered network (actually ). 4

5 Regular activity from a low numbered device on a high numbered network (192) and a high numbered device on the 10. network A couple of unique transactions from a low numbered device on a low numbered network (actually ) to a high numbered device on a high numbered network (actually ) If we zoom in on a segment of the plot (from the activity at lower left in the above visualisation) we can also see some of the fine detail. For instance in the section above we can see: 5 groups of TCP (green) exchanges with a pattern of two long (ie broad) transmissions from bottom (actually ) to top ( ), followed by a reverse and smaller transmission (an acknowledgement?), all on a high numbered (red) port 2 groups of UDP (yellow) exchanges, a small one from top to bottom ( to ), and a slightly larger one in the reverse direction (both on a low numbered (grey) port. So whilst we ourselves don't know a lot about network systems and cyber-security Datascape is already beginning to reveal things that look like common patterns, and transmissions that look unique within the dataset and so may be worthy of further study. 5

6 OUTSIDE Data Although called outside data this is actually the view form inside of the firewall as far as we can work out. The data formats are similar to the ITOC data. For nodes: And for links: Note that we are removing from the link list any data specific to the nodes, (eg port), and removing from the node list any data specific to the link (eg protocol, length). The mappings used were essentially the same as for the ITOC data, but the visualisation is quite different: 6

7 As would be expected we are now primarily seeing traffic on the internal 10. network the horizontal layer across the bottom. There are no links from 10. to any other network, and we are just seeing a few links not on the 10. network. And here is the colour translation table which we based on the protocol in use: 7

8 Orientating to a look-down/2d view (and changing our background) we can nicely see the burst of DNS activity (the yellow & white transactions at left), and a repeating pattern of Jabber/XML activity (red and cyan). The original view also showed a couple of transactions well above the 10. plane. And looking at them we see that they are all on the 169 network and going to and appear to consist of management broadcasts involving ITOC (the organisers) and USMA (the network who's data we have). 8

9 SNORT The final set of data comes from SNORT, a lightweight network intrusion detection system running within the USMA network. The data for this is more rules based, flagging issues rather than showing raw transactions. The node data looks much like the others: and the edges data: We used a similar visualisation to the other two, and this time coloured the links by the rule being triggered, grouping similar rules/alerts into similar or the same colours. 9

10 Giving us this visualisation: 10

11 And from the side: Most of the activity is within 10. but there are quite a number of cross-network links. That one reaching to the sky is from to and has a rule of data sent on a stream not accepting data. An oblique view is also useful. 11

12 And then we can start clicking on the links of interest and put them into their own group and get Datascape to display the relevant labels. BRINGING IT ALL TOGETHER Although these samples are not synchronised in time, we could with a synchronised dataset display all sets simultaneously in order to track activities across the three sensor points, showing: ITOC (external) at the bottom SNORT in the middle Outside (internal) at the top. 12

13 SUMMARY As mentioned at the beginning we are not cyber-security experts, but hopefully these visualisations may show those who are experts some original ways of looking at IT network and cyber-security data, and show others the versatility of Datascape and give you some ideas as to how you might visualise your own data. Note: The datasets we have used here are only extracts of 1000 links, but we have run Datascape on reasonable (not even pro-gamer standard) PCs and plotted up to around 250,000 points (about 80,000 links, so we do have the capability to show quite significant portions of these sort of datasets. For more information on Datascape please or visit our web site at 13

14 14