Skip to main content

Sift Security Tools Release for AWS Monitoring - CloudHunter

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:
  1. Investigating events happening in AWS directly from Amazon is painful, unless you know exactly what event you're looking for.
  2. 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, especially for security use cases, becomes exceedingly complex.  With compute instances and load balancers constantly being spun-up and torn down, sometimes changing from one minute to the next, security and operations groups can often find themselves in the dark about what's happening in their own environment.

Today, CloudHunter ingests events from AWS CloudTrail and VPC Flow logs, similar to how CloudTrail helps customers to perform compliance with internal policies or regulatory standards.  We load this data into our graph database and run our anomaly detection algorithms over that data the same as any other data source.  The result is that we will allow you to explore your infrastructure visually, and will alert you about suspicious activity in the cloud.  What kinds of things do we find?  Here are a few:
  1. In our own infrastructure, we already found people who were not using multi-factor authentication when making changes to AWS, and were able to resolve it quickly.
  2. We can see the geographies and IP addresses being used to modify our infrastructure and easily report on the employees who are traveling the most.
  3. We know exactly who has modified security groups, the interfaces involved, and the traffic allowed through.
  4. We know who's making permission changes to our S3 buckets, and when.
  5. We get alerts when somebody does something strange, like deleting security groups or S3 buckets.
The best part is that there is no agent to install, it works right out of the box with the AWS infrastructure you already have in place.  Since we don't have a monitoring agent deployed, there is no impact on the performance of your services. Still, CloudHunter can monitor your AWS security similar to Amazon CloudWatch, that is a monitoring service for AWS cloud infrastructure and the app running on AWS.

You may be asking what's next.  Our next step is to empower users to take actions right from the graph, using the APIs exposed from Amazon.  I, for one, would certainly like to be able to right click and run a "playbook".  It would be great, for example, to be able to get the current permissions for a S3 bucket or run a forensic procedure for an EC2 instance that seems to be compromised.  If you have any ideas, we would love to hear from you!

We have a data sheet about CloudHunter available to learn more.
For any further information, please e-mail us at contact@siftsecurity.com

Popular posts from this blog

Data Exfiltration from AWS S3 Buckets

You will have no doubt heard by now about the recent Booz Allen Hamilton breach that took place on Amazon Web Services – in short, a shocking collection of 60,000 government sensitive files were left on a public S3 bucket (file storage in Amazon Web Services) for all to see. We are all probably too overwhelmed to care, given all the recent breaches we have been hearing about in the news. But with this breach it was different, it involved a trusted and appointed contractor whose job it was to follow security policies, put in place to avoid such incidents. So was this incident accidental or malicious? More, later about the tools we can use to tell the difference between the two. First, lets recap what happened.The IncidentAccording to Gizmodo, the 28GB of data that was leaked not only contained sensitive information on recent government projects, but at least a half dozen unencrypted passwords belonging to government contractors with Top Secret Clearance – meaning anyone who got their h…

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 interr…