One of the biggest differentiators at Sift Security is our security event graph: We map security events into a graph database. We then analyze the graph structure to prioritize alerts. Specifically, we look for clusters of interrelated alerts, score the clusters, and surface the clusters to the analyst. The analyst can then investigate each cluster in order, quickly assessing the threat and resolving the alerts in bulk.
Our algorithms do the important work of sifting through isolated alerts and separating the false alarms and low priority alerts from high priority security incidents. We identify the high priority incidents by analyzing how alerts are related to each other. Key to this approach is our security event graph. This graph is stored in a graph database, a relationship-centric database that enables rapid execution of complex queries that would be very expensive to make in a traditional RDBMS. The graph structure enables us to rapidly traverse relationships and find interrelated alerts. We use JanusGraph, an open-source, scalable, and distributed graph database, to store, query, and analyze our security event graph.
The clusters are scored and ranked based on a number of factors, including:
- Number and priority of alerts
- Number of alert sources and types
- Number of different affected entity types
In this post, we share two examples of how our graph algorithms provide effective alert prioritization, one from a traditional SIEM use case and another from our CloudHunter product.
SIEM Alert Prioritization
In this scenario, we have ingested Windows Event, netflow, Cylance, and Cisco IronPort logs. We have alerts from:
- Threat intelligence sources
- Cylance Antivirus
- Sift Security’s Entity Behavioral Analytics module
- Sift Security’s Detection Rules module
In total, there are over 1,000 alerts affecting some 70 host and 10 users.
The graph algorithms identify one cluster of alerts that stands out above the rest. This cluster contains 55 alerts, 44 of which are high risk. We display a summary of the alerts, including a breakdown of the alert priority scores by entity, shown below.
We also surface an interactive visualization of this cluster of alerts to help the analyst quickly assess the threat. The visualization (below) shows the user credential “Robert” at the center of the cluster, and 3 affected hosts: ws02, ws35, and dev. The processes shared between ws35 and ws02 are a malware exploit identified by Cylance, the processes shared between ws02 and dev are reconnaissance processes identified by our Entity Behavioral Analytics, and the IP address 202.116.65.35 is a threat intelligence hit. Together, this cluster represents a successful malware exploit affecting 3 hosts and 2 user credentials.
CloudHunter Alert Prioritization
In the CloudHunter example, we have ingested CloudTrail logs from multiple AWS accounts. The alerts come from two places:
- Sift Security’s Analytics Module
- Sift Security’s Detection Rules Module
Because this is a CloudHunter deployment, the detection rules module is preconfigured to alert on the Center for Internet Security benchmarks, and the analytics are configured for common cloud security use cases, such as identifying privilege escalation, data exfiltration, and other misuse of resources.
From thousands of individual alerts, the graph algorithms again identify a high priority cluster (below). This cluster shows demo-contractor creating an instance from an AMI, and automated-s3-user accessing sensitive documents in s3 from that instance. This is a situation where an insider was able to get access to data that should not have been able to by abusing the privileges they were granted.
Conclusions
The benefit of this graph-based alert prioritization approach is that these clusters of alerts may have otherwise gone unnoticed for a while, buried in a pile of other similar alerts. Our graph based alert prioritization helps reduce the mean time to remediation by enabling analysts to be more effective in their investigations. If you’d like to try out our graph based alert prioritization techniques for yourself, consider trying CloudHunter, which can be deployed in under and hour to start identifying prioritized security incidents in your AWS cloud infrastructure.
For other posts about alert prioritization, see: