I Just Looked at 2 Billion Cloud Events. Here’s What I Found.
July 25, 2018
Photo by Jase Ess – Unsplash
Our relationship with Lacework customers usually starts with a 30-day trial of our solution. Going into it, they typically acknowledge the lack of necessary visibility into their cloud environment. They also, however, tend to massively discount the reality of threats and risks to which they’re exposing their users and data. It’s not until they actually partake in the trial that an accurate picture of the state of their security posture becomes apparent.
The first thing our trial users recognize is the breadth of what is identified, which is essentially, everything. Lacework ingests every cloud event occurring across all an organization’s AWS accounts. Indeed, every configuration change, EC2 spin-up, connections to IP addresses are identified, along with the millions, tens of millions, or even billions of events that occur in an environment every month.
While some vendors look specifically at network traffic, DDoS attacks, or other types of threats, Lacework takes a totally comprehensive approach. For most trial users, this is the first opportunity to accurately see the footprint of their cloud, and for most, it’s an eye-opener. With all that great agility and ease-of-management, their cloud environment is complex and layered. Seeing it through the lens of both threat detection and anomalous activity creates a new perspective and punctuates the need to gain control.
Analyzing billions of events is, in itself, a lot to get your head around, and it’s virtually impossible to manage all those issues that look like major risks. So, the second element the trial uncovers is how the Lacework behavioral analysis approach creates sense from all this event data. The result is far fewer alerts, and the alerts users receive are more specific and actionable.
We recently reviewed data from seven trial users in an effort to understand which events and activities are most commonly detected as critical and high risk issues. While all of our trial data is strictly privileged, we found many commonalities among the more than 2 billion cloud events analyzed within these customers’ environments. It can be instructive to review this information and put it into the context of your own organization; it’s likely to be reflected in your own organization.
While not in any particular order, here’s a breakdown of the most commonly identified issues:
- Dead accounts: Perhaps not surprisingly, most organizations have no off-boarding policies or processes. As a result, they tend to have dozens (in some cases, hundreds) of accounts with broad, but illegitimate, access that appear to be unused. Not only is this a SOC 2 violation, it’s also leaving unprotected doors open all over your cloud infrastructure.
- Open security groups: This is likely the result of new VPCs or changing VPCs where rules to security groups change, thus leaving them open and exposed.
- Open S3 buckets: This shouldn’t be a surprise; open S3 buckets were at the root of many infamous breaches (Dow Jones, Verizon, and the Pentagon are among the organizations who were discovered with open access to PII and other confidential data in open S3 buckets. ) Open and unencrypted S3 buckets apparently continue to be a problem, as evidenced by our research.
- No MFA: It’s like flossing; we all know we’re supposed to enforce MFA policies, but few do. Not surprisingly, we see a huge number of IAM users with no MFA being used.
- Bad IP addresses: A huge number of machines were detected connecting to bad IP addresses and/or addresses that are completely anomalous. These were SSH calls to IP addresses which typically indicates automated, machine-originated attempts in attack mode.
- SSH brute force attempts: Indicators highlight many attack attempts to root and admin. That style of attack is certainly nothing new, but occurrences are high and increasingly undetectable without an automated approach that’s enhanced with behavioral context.
- Privilege escalation: A cloud environment can look like Spring Break at Lake Havasu; people all over the place, and getting into places they shouldn’t. Here again, without the right kind of awareness and detection, those users will be able to continue roaming freely unless discovered.
The “a-ha” moment for trial users is usually more like a one-two punch (but a really welcome punch): first is the realization of how vast their cloud operations are and the complex nature of connections that go into supporting their business goals. Indeed, their cloud infrastructure is key to that, but part of the realization is also that, much like Heraclitus’ river, you’re never really assessing the same environment every time you look into your security posture. The cloud infrastructure is agile, and therefore constantly changing. Using Lacework provides a perspective on this, and correspondingly, on the potential for a constant new stream of threats.
The second punch of awareness is the digestibility of issues. If users have tried other vendors, they’ve seen their lives taken over by alerts. Most vendors use an either/or framework for identifying issues – either an IAM user has access to the resource, of she doesn’t. Lacework users recognize that this will put security teams on investigation paths that lead nowhere. Rules, configurations, users, access…all these things change constantly; some are legitimate, some not, but without some intelligence applied to the analysis of events, security teams are flooded with alerts, many of which lead to non-issues.
Because Lacework applies machine learning-supported behavioral analysis to events, users see far fewer critical alerts, and they ultimately are far more accurate. In addition to just being easier to digest, they’re also far more actionable, which leads to better control over one’s cloud environment.
No one takes joy in discovering they’re sitting on a pile of risks, but once known, corrective measures can put you into a better state to manage your threat potential. We encourage you to try Lacework for 30 days to learn more about your cloud environment, the risks you’re exposing your organization to, and how you can begin to establish a security discipline for your organization.