This network visualization for the National Collegiate Cyber Defense Competition was developed as an internal tool. The purpose was to illustrate the network activity occurring during the competition to casual non-technical observers. The architecture of this system was as follows: the competing teams had of their traffic routed through a switch, and a dedicated machine processed all network traffic from the SPAN port. The traffic processor would then upload the relevant data to a MySQL database. One of the requirements of the visualization was that it was not allowed to poll the database. Therefore, we chose to maintain a connection to the database through a socket that would receive new data based on a set of database triggers. The visualization would receive this data, parse it, and update the display accordingly. The display itself was a set of 10 cities, one city for each team network. Each building in a city represented a machine on that network. Each building had a small numbered port object. Some of the objects in the visual space had a special meaning. For example, the globe represented all endpoints external to the competition environment (i.e. the internet). Connections were represented by colored lines based on the source IP of the network traffic. Blue lines represented the collegiate blue teams, while the adversarial red team was shown with red lines. Traffic from the team that simulated a customer service was represented with orange.

Challenges

During development, we did not have access to a live competition environment, only packet capture files from a previous competition. Furthermore, the amount of network traffic generated in two competition days was several terabytes in size.

What Went Wrong

We created the visualization in Unity3D. However, at that time, Unity3D did not natively support multithreading. As a result, the software was not as performant over time, as the queue of data to be parsed would grow faster than the software's ability to handle it. Also, due to our limited exposure to the competition infrastructure, we were essentially testing our software in a production environment. As a result, the worst issue we had was single-threaded performance bottlenecks dropping the framerate of the visualization. Behind the scenes, this meant that the visualization would be less accurate over time as it fell out of sync with the latest network data. Restarting the visualization "fixed" this temporarily, which was determined to be sufficient for the two days of the competition that it was deployed.

What Went Right

Due to the storage requirements for this traffic, we decided not to store the data as events, instead just updating the timestamps and statuses of records in the database. This meant that we did not need to parse through millions of rows of data if the simulation needed to be restarted for any reason (as it did.

Lessons Learned

Identify any major performance impacts from the use of a given technology. Don't test in production!

Additional Media