Most enterprises are already using public cloud computing services at scale or are planning to adopt the cloud soon. As an executive, chances are you’re paying attention to the Capital One data breach and wondering how this event should impact your decision-making.

This is understandable and good. Capital One has been a true trailblazer within the financial sector in adopting and innovating in the cloud at a time when most of their peers have been slower in making the transition. They’ve attracted an army of cloud experts, including some incredibly talented cloud security professionals. I know some of them personally and respect them greatly. Yet they still got breached. How? And what can we learn from this?

Before we dive in, the following truth can’t be stressed enough: The cloud itself is far more secure than any data center. However, we have to think differently about security in the cloud versus the way we have thought about security in the data center.

I’ll explain why and provide some guidance on how you can ensure your cloud and security teams are properly prioritizing and managing the risks. But first, let’s look at what happened in this case.

This data breach was the result of cloud misconfiguration

Whether or not this is the first time you have heard the term “cloud misconfiguration,” it won’t be the last. According to Neil MacDonald at Gartner, “nearly all successful attacks on cloud services are the result of customer misconfiguration, mismanagement and mistakes.”

That seems to be the case here, but it’s not as simple as leaving an Amazon Web Services (AWS) S3 bucket (an object storage service) open to public access, which unfortunately does happen with some frequency. The hacker here appears to have exploited a series of cloud misconfigurations to move laterally within the company’s cloud environment in order to extract sensitive data. Here’s an overly-simplified explanation:

1. A misconfigured firewall allowed the hacker to access an Amazon EC2 instance (a virtual server).
2. Once on the EC2 instance, the hacker obtained an IAM (Identity and Access Management) role which gave her access to S3 buckets containing customer data.
3. Overly broad access to S3 from the compromised server enabled the hacker to discover and then duplicate the contents and extract them.

My colleague and Fugue CTO Josh Stella wrote up a detailed technical analysis of the breach based on the information we have, along with some technical advice. You can read it here and/or point your technical folks at it.

We’ll no doubt learn more about this breach, and possibly others by the same hacker, over time. But there are some takeaways we can learn now, and steps we can take.

1. Ask Questions About Your Cloud Security Posture

The risks due to cloud misconfiguration are real, and you need to make sure your cloud and security teams take it seriously. If you don’t already know, find out who’s responsible for the security of your cloud environments and data. It may be a security team, a DevOps team, or perhaps individual application teams. Ask them questions about your cloud security posture.

• What are we doing to prevent cloud misconfigurations from happening in the first place? Do we have automated, policy-based guardrails in place to prevent misconfigurations and policy violations from being introduced into our cloud environments? Are we evaluating the infrastructure environment as a whole for misconfiguration vulnerabilities (and not just individual resource configurations)?
  
• What are we doing to find and fix cloud misconfigurations when they do occur? Getting your cloud configurations secure on day one is good, but a lot can go wrong on day two. Change in the cloud is constant: new applications are being developed, existing applications are being enhanced, and technical staff make changes to cloud configurations to investigate and resolve production problems. We call all these changes “drift” and any one drift event can introduce or reintroduce a cloud misconfiguration. Is your team continuously identifying drift, misconfigurations, and policy violations? Are they using automated remediation for security-critical cloud resources to reduce the risk of human error and lengthy response times?
  
• Do we have continuous visibility into the configuration state of our cloud environments? One big advantage the cloud has over the data center is that in the cloud, every configuration detail is knowable via application programming interfaces (APIs). If your team is manually auditing cloud configurations, that’s a problem that should be addressed with automation.

2. Cloud security is different. So think differently.

The cloud is fundamentally different than the data center, and that means cloud security is fundamentally different than data center security. Many of the security tools and processes that worked in the data center simply aren’t effective or don’t scale well in the cloud.

There are many ways cloud is different than the data center. First and foremost, everything is software defined and programmable via APIs. This means not only can your application deployments be fully automated, so can your cloud security. The bad guys are using automation, and you need to use automated defenses to keep up. Make sure your penetration testers, who should be outside vendors, are looking for cloud misconfigurations as part of their efforts. Our experience is that traditional penetration testers don't always do this.

Traditional approaches to things like network security don’t apply as much in the cloud — for one thing, you aren’t typically monitoring network traffic directly, though new features such as AWS VPC Traffic Mirroring or Azure Virtual Network TAP may help eventually. Instead the paradigm of IAM has become paramount. You can think of identity as the new network or the new firewall. You will want to put a lot of focus on this and make sure your teams aren’t using overly permissive IAM roles. The principle of least permissions to accomplish a desired task is key here.

Because the cloud is programmable, your developers are moving fast and making cloud infrastructure decisions, including those with security ramifications. Empower them to move fast and securely with tools to automate cloud security and compliance.

I wrote recently on the five things executives need to know about cloud security. You can read it here.

3. There will be FUD. Ignore it.

Right now legacy technology vendors are using this event in order to sell fear, uncertainty, and doubt (FUD)—so they can keep selling their products. And many organizations inevitably have people on staff who are resistant to change—who will use events like this to try to slow down or stop cloud adoption.

Make no mistake—the cloud is highly secure, so don’t let anyone convince you otherwise. Cloud providers like AWS and Microsoft Azure have incredibly impressive security track records. There have been no data breaches due to a security failure by any of the major cloud providers like AWS or Azure. None.

The FUD peddlers either don’t understand the cloud or they don’t like change. And sometimes they may not have your best interests at heart.

If you avoid the cloud or slow your adoption, you’re not making your IT infrastructure, applications, and data more secure. You’re simply ensuring that you’ll be slower, less agile, less efficient, and less competitive. And in all likelihood, less secure.

If we can help you think differently about cloud security, please reach out to me at phillip at fugue dot co.