Skip to main content

The Cloud Attack Chain

In an earlier posting on Public Cloud Security Detection Use Cases, we attempted to map
detections to the traditional Lockheed Martin Kill Chain. After further reflection,
we decided that cloud infrastructure threats are sufficiently different enough to warrant a
modified attack chain framework. We are releasing the Cloud Attack Chain framework today.
The Cloud Attack Chain is a simplified attack chain model that describes typical attacks on public cloud
infrastructure.  The attack chain describes how an attacker gains access to a victim’s cloud environment, how
they move laterally through the target cloud infrastructure, and what malicious actions they perform.   Our
new Whitepaper describes the four stages of the attack chain and provides detailed examples of some real-world

As a preview, the stages of the Cloud Attack Chain are:

1. Exposure: Exposure of cloud resources is at the beginning of any cloud attack. Exposure can be deliberate,
based on business trade-offs, or accidental, resulting from misconfigured resources or unpatched vulnerabilities.  
Exposures are where attackers start looking for a way in.

2. Access:  Access occurs when an attacker has figured out how to exploit an exposure and gains access to your
cloud infrastructure.

3. Lateral Movement: With access to your infrastructure, the attacker identifies targets for the attack, gaining
access to additional resources or escalating their privileges.

4. Actions: Now having access to the resources they need, the attacker performs some malicious action to fulfill
their objectives.

We invite you to learn more by downloading the paper at

Popular posts from this blog

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…

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…