Capital One Breach: Is your AWS environment just as susceptible?

The Opportunity for Security Teams

It’s been a little over a week since the coverage of the Capital One data breach. The impact of 100 million plus records that were compromised breathed gasoline onto the fiery debate as to whether the cloud is or even can be secure. Industry experts are divided as to who is to blame. News cycles drum up the age old advice for consumers to monitor or freeze their credit. Many cybersecurity companies are quick to point fingers and lay blame. It’s hyperbolic and fairly unproductive. 

Even after 10 days, organizational concerns around their lack of visibility and the potential sleeping vulnerabilities that may exist in their own digital environments and infrastructure are still sky high. So how can security teams capitalize on this hyper-alertness across the organization to ensure they are minding their own risks and shining a light on their own policies for examination?  

Two Things You Musn't Forget

This happens to the very best of us. People make mistakes and attacks are inevitable. The root cause was a configuration issue. Put another way, are deadbolts any less secure should you suffer a break-in after forgetting to close the door? No. Misconfiguration in any environment, including the most secure, can lead to compromises.
So the cloud isn’t any less secure, but practices can certainly be improved.

So what can we learn and how can we use that information to be better prepared?

There are a couple of good articles (here and here) with technical details of how it happened, but what it boils down to is being able to complete a comprehensive threat analysis of your AWS environments and configurations and to be able to answer these questions: 

  • What active EC2 instances do I have that are Internet facing/publicly accessible? 
  • What IAM roles can these EC2 instances use/assume? 
  • What policies are assigned to these IAM roles? 
  • What permissions are allowed by these policies?  

Unfortunately, the most challenging part of this threat analysis exercise is the sheer scale.  Even when you know what to look for, you may have hundreds or even thousands of instances running across multiple AWS accounts. This analysis can easily take weeks, if not longer. 

Update: check out our simple infographic around tracking down IAM policy vulnerabilities.

How JupiterOne Provides Visibility

With that in mind, the team at JupiterOne pushed out a few updates this week to allow our users to answer all of the above with one single query, across your entire AWS environments – all accounts integrated with JupiterOne: 

find Internet 
  that allows aws_security_group 
  that protects aws_instance with active=true 
  that uses aws_iam_role 
  that assigned AccessPolicy
  return tree 

If needed, users can also perform the same analysis on a per-account basis by adding an additional `tag.AccountName` filter to the query. 

The result is a graph that presents the results to you visually, showing you:

  • The path connecting the Internet to any AWS Security Group that has rules allowing ingress or egress traffic, the EC2 instance using that security group
  • The IAM role that instance can assume (i.e. obtain a temporary credential with its assigned privilege), and finally,  the IAM policy that is assigned to the role. 

From here, users can open up the property inspector panel and switch to the Raw Data tab to further analyze the policy document and the permission statements, to determine if the policy contains permissions too broad that need to be restricted. 

Users can also review the Security Group rules to see if they need to be hardened, or jump directly to that IAM Policy or Security Group resource in the AWS Console using the pre-built web link.

Additionally, if a vulnerability scanner such as AWS Inspector is being used, users can interact with the graph, or run smart queries, to bring in vulnerability findings data for those EC2 instances in question to further determine risk.


We’d be naive to think a breach as significant as Capital One won’t put pause on a number of cloud-driven digital transformations. It is probably raising alarms for a number of cloud-native organizations as well. But raising awareness around the importance of execution is good for everyone; and we believe providing an avenue the makes managing that execution even easier, is better [for everyone].


Posted By Erkang Zheng

I envision a world where decisions are made on facts, not fear; teams are fulfilled, not frustrated; breaches are improbable, not inevitable. Security is a basic right.

I am a cybersecurity practitioner and founder with 20+ years across IAM, pen testing, IR, data, app, and cloud security. An engineer by trade, entrepreneur at heart, I am passionate about technology and solving real-world challenges. Former CISO, security leader at IBM and Fidelity Investments, I hold five patents and multiple industry certifications.

I am building a cloud-native software platform at JupiterOne to deliver knowledge, transparency and confidence to every digital operation in every organization, large or small.

To hear more from Erkang, get our newsletter. No spam, just the good stuff once or twice a month. Sign up below.


cyber-security 1

Ad Title Placeholder

Lorem ipsum dolor sit amet, consectetur adipiscing elit.