Skip to main content

Using the Security Event Graph to Drive Alert Prioritization


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.

Screen Shot 2017-08-01 at 11.18.22 AM.png

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.  
Screen Shot 2017-08-01 at 11.24.07 AM.png

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. 

Screen Shot 2017-08-01 at 11.54.11 AM.png

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:

Popular posts from this blog

Sift Joins Netskope, the Cloud Security Leader

Four years ago, we started Sift with the mission of simplifying security operations and incident response for the public cloud. In that time, we have assembled a fantastic team, created an innovative cloud detection and response solution, and have worked with many market-leading customers. I’m delighted to share that we’ve taken yet another step forward — as announced today, Sift is now officially part of Netskope. You can read more about this on Netskope CEO Sanjay Beri’s blog or in the official announcement on the Netskope website.
For our customers, investors, partners, and team, this is an exciting new chapter. Let me tell you why we’re so excited.  Since the beginning, Netskope has had an unmatched vision for the cloud security market. Having started in 2012, they initially focused on SaaS security and quickly followed that with IaaS security capabilities. Six years later, they are now more than 500 employees strong and used by a quarter of the Fortune 100. They are a leader in …

Sift Security Tools Release for AWS Monitoring - CloudHunter

We are excited to release CloudHunter, a web service similar to AWS CloudTrail that allows customers to visually explore and investigate their AWS cloud infrastructure.  At Sift, we felt this integration would be important for 2 main reasons:
Investigating events happening in AWS directly from Amazon is painful, unless you know exactly what event you're looking for.There are not many solutions that allow customers to follow chains of events spanning across the on-premises network and AWS on a single screen. At Netflix, we spent a lot of time creating custom tools to address security concerns in our AWS infrastructure because we needed to supplement the AWS logs, and created visualizations based on that data.  The amazing suite of open source tools from Netflix are the solutions they used to resolve their own pain points.  Hosting microservices in the cloud with continuous integration and continuous deployment can be extremely efficient and robust.  However, tracking events, espec…

Integration with Amazon GuardDuty

What is Amazon GuardDuty?
Amazon GuardDuty is a continuous security monitoring platform that analyzes and processes VPC flow logs, AWS CloudTrail event logs and DNS logs. It uses threat intelligence feeds, such as lists of malicious IPs and domains to identify malicious activity within your AWS environment.
You can enable the GuardDuty Service through your Amazon Console. Once there, you are then presented with the GuardDuty dashboard, as shown in the example below:














Finding are rated as High, Medium or Low on the dashboard and have the following meaning:  

Highfindingsindicates that the resource in question is compromised and is actively being used for unauthorized purposes.

Medium findings indicates suspicious activity, for example, a large amount of traffic being returned to a remote host that is hiding behind the Tor network.

Low findingsindicates suspicious or malicious activity that was blocked before it compromised your resource.

Integrating CloudHunter with GuardDuty

CloudHunter integr…