
From wikipedia:
"Treemaps display hierarchical (tree-structured) data as a set of nested rectangles. Each branch of the tree is given a rectangle, which is then tiled with smaller rectangles representing sub-branches. A leaf node's rectangle has an area proportional to a specified dimension on the data. (In the illustration, this is proportional to a waiting time). Often the leaf nodes are colored to show a separate dimension of the data.
When the color and size dimensions are correlated in some way with the tree structure, one can often easily see patterns that would be difficult to spot in other ways. A second advantage of treemaps is that, by construction, they make efficient use of space. As a result, they can legibly display thousands of items on the screen simultaneously."
In this example i use the following data hierarchy:
Let me explain this a bit more; depending of the rule itself, the generated alert will contain some specific relevant information ('parameters'). For example, for the rule "r02 - Port Scan Detected", I considered only the Source IP and the Destination IP as relevant. Let me zoom in on the tree map for this alert:

As you can see there is one much bigger square than the rest, the size is related to the number of ocurrences of the alert. So, in terms of tunning, it makes sense to me to focus on the Port Scan detected case from source IP "92.13.205.21" to destination IP "113.11.221.33".
Let's see another example, this time we use treemap for the rule r12 - Increase in Failed Remote Login Attempts detected (within the User Monitoring category). In this case I considered as relevant information to obtain from the alert the User Name and Workstation.

Similar than before, the first case I'd try to solve is the one with the most occurrences, the failed remote login attempts of the user name "Alonso" in the workstation "home-pc-r40".
For these examples i always used 2 parameters as relevant information, but this could be extended to as many parameter you desire in your hierarchy. It will be normally limited by the SIEM solution you are using and the SEM/alerting capabilities within the product.
But not only the size of the squares is important, the color is also. The color is associated to the severity, so a high severity alert will be displayed in red and the lowest in green. The severity goes from 1 to 5, been 1 the highest; the different values of severity will be displayed as different colors in the transition from red to green. Take a look at the User Monitoring category as the next example:

There are three rules in this category, one with high severity in red, other with medium severity in brown, and other with low severity in green. The red alert has only one parameter, the IP of the machine where the tampering was detected.
Finally, I'd like to comment a small inconvenient I found to this representation: it is when you have a red alert which has been generated only once. It's pretty difficult to find it when the other alerts have been generated dozens of times. Below you can see the treemap for the same data than the first graph of the post changing just the number of occurrences of the r05 alert to 1.

As you can see it's hardly visible on the screen and difficult to spot. Anyway I would expect that a high alert has a specific action when is triggered, as an email or similar.
In case that you want to use this visualization more as a "pseudo-real time" alert monitoring and not only as a tunning tool, I wouldn't use only the number of occurrences of an alert as the size of the square. I'd use some kind of criticality equation relating number of occurrences and severity of the alert. (I'll try to continue with this in a future post).
Personally, I spend many hours tunning SIEM alerts and I really think that using treemaps is a cool way of doing it. It looks good and you save time.
What else can you ask for? ;)
Note: all the treemaps shown have been created with the treemap tool within the DAVIX distribution.
No comments:
Post a Comment