Visualization has proven its value many times over in many fields, and in security specifically. But while visualization is useful, how do we move past Threatbutt-like, cool-yet-meaningless maps, to a useful visual interface?
There have also been many attempts at security visualization, the most notorious being Norse Attack Map, which the industry loved for being pretty. On the other end of the spectrum we have the illustrious Threatbutt Attack Attribution Map, which ridicules all that came before it. In fact, visualization has become a requirement from customers, mainly for slice-and-dice statistics (usually with Kibana), but also for internal PR with cool maps that would impress the higher-ups. A way to add the ‘cool factor’ to products.
Threatbutt Attack Attribution Map
When faced with the challenge of creating visualization that matters, we waited. Our competition added various Kibana-like statistics, and used various mapping libraries to create Visio-like network maps.
We did have some visualization, although it was basic. It displayed a Sankey approach to deception, where we looked at the deception stories through the lens of IT. Which endpoint group (deployment group) initiated which attack, through which service, by connecting to which asset?
While descriptive for planning and viewing deception stories, it was lacking. Having it, however, allowed us to wait on developing the next generation of our visualization.
MazeRunner Campaign screen
We waited because we wanted to understand three things, which later turned into the goals for our developers:
- Should we visualize the network, security events, and alerts, or should we find a way to visualize the deception campaigns? Perhaps a combination?
- What kind of data should be displayed?
- Would a network map help our customers make better use of our technology?
- What level of detail would be useful? Too much and it will be confusing; too little and it will be useless.
- How would the visualization tie into our product workflow?
- How would the developers tie the visualization into their workflow?
- What kind of interface would users actually use with our product (rather than just stick on a wall in their SOC)?
- Would the visualization still be cool enough to stick on a wall in the SOC, and to impress the higher-ups?
One of the first things we understood was that network mapping is a difficult problem, and even if we were to solve it, it is not our focus. Deception and how it relates to the environment is our focus.
The second point that became clear is that while control via the visualization is the goal, we need to first see how users interact with the map before we can take that route. Thus, we started with visibility.
Lastly, we concluded that we must develop our own visualization to be able to achieve our goals. We wanted to create a battle map to underline the power of deception for active and dynamic defense, as opposed to static observation. We decided to use the D3 visualization engine.
When we started building the battle map, three challenges emerged:
- It was hard for me personally to disconnect from the idea of a network map. In my mind, if we couldn’t create a realm of reference that made sense, the visualization could be stunning, but it wouldn’t be useful. The challenge of network mapping combined with the value to our customers decided it for us, and we anchored our visualization around the deception elements.
As an example of a good “universe” or realm of reference to make sense of data visually, check out any Geo-IP map (such as Norse’s, above). While it displays mostly useless information based on IP addresses, users can easily understand it and the visual meaning of the data they see. The graphical universe in this case is the line denoting the map of the Earth.
- If we display deception, what kind of element makes sense? Without anchoring the deception around the network or endpoints, deception seemed scattered. Luckily, due to our scalability work, MazeRunner collects endpoints in what we call deployment groups, so that these can be manipulated, updated, and refreshed at will, depending on which deception story they cover. Since alerts would be initiated on decoys based on the breadcrumbs deployed to the various groups, this decided the two main elements in our visualization: alerts will be initiated from the deployment groups, and proceed to the decoy under attack.
- Without endpoints, we couldn’t denote activity. How does one visually distinguish how many alerts, or of what type, exist at any given time? Our solution was to display events and alerts in orbit around our deployment groups, and they replaced the need for endpoints in the visualization.
There are some challenges yet to be resolved. For example, without endpoints it is difficult for us to display a drill-down of an attack timeline or story. Further, without relating to some form of network map, it’s difficult to ascertain the importance, scale, or severity of attacks.
With these challenges in our future, as well as the next step of adding control functionality to the visualization, we feel we have embarked on an exciting journey. We thank you for being our customers and coming along on this adventure with us.
With special thanks to Dekel Braunstein and Imri Goldberg.