Debunking the 5 Biggest Cloud Security Myths

Enterprise cloud adoption is in full swing, and cloud security and compliance have become top priorities. Security in the cloud requires different approaches than in the data center—and also requires a different mindset. Movements including DevOps, DevSecOps and Shift Left are transforming how organizations approach cloud security posture management (CSPM). However, this transformation fosters some dangerous assumptions that can lead to complacency and a false sense of security.

Myth #1: Every change to production goes through the automated pipeline

If your team has adopted an automated CI/CD pipeline that integrates policy checks for security and compliance, you’re ahead of the pack when it comes to embracing the Shift Left model.

But you still need to focus on the security of the “right side” of the software development life cycle (SDLC), specifically production environments. Engineers are going to make changes to production manually, perhaps by creating a new security group rule to perform some maintenance, for example. They may forget to close the door once they’re finished, giving bad actors access to your environment.

Follow these three steps to take a holistic approach to security and compliance throughout the entire SDLC (realizing that some change will always occur outside of your automated pipeline):  

  1. Understand the complete state of your production environments by baselining your infrastructure.
  2. Continuously survey the configuration state of your infrastructure and compare it to the baseline you established.
  3. Implement automated remediation for critical cloud resources.

Myth #2: Validating infrastructure as code files against policy is sufficient

One of the first things IT teams realize when adopting cloud-based platforms is that doing everything in the cloud console doesn’t scale. Thanks to infrastructure as code (IaC) tools, we can express the cloud resources we need in config files and build and update infrastructure in an efficient and scalable way.

 It’s tempting to validate our IaC files against policy to know if the cloud infrastructure we’re going to build will be secure and compliant. While doing so is recognition that Shift Left must include infrastructure security and application security, there are some flaws with this approach that can lead to misconfiguration vulnerabilities.

Give your developers tools that enable them to validate their environments against policy so they can get actionable feedback to fix problems early in the SDLC. Validate staging environments against policy and prohibit any deployment to production if it fails. It’s not a bad thing if developers validate their IaC files as they go—they’ll likely catch some things earlier and that can help them move faster. But before deploying to production, it’s imperative to validate your staging environment against policy.

Myth #3: We can keep our cloud secure without automated remediation

Enterprise cloud environments are too complex to manage misconfiguration with manual processes. Relying on humans to review alerts and fix misconfiguration issues places your organization at risk.

You need to identify the security-critical cloud resources in your environment, validate that they adhere to policy and put automated remediation in place for them. Cloud resource misconfiguration isn’t itself a security incident, but it can lead to one.

Implement automated remediation tools to correct misconfiguration back to the known-good baseline they originally provisioned. The configurations for security-critical cloud resources don’t need to change that often, so it should be easy to get everyone on the same page.

Myth #4: Our cloud provider is responsible for our infrastructure security

When moving to the cloud, it’s important to understand the Shared Responsibility Model. The cloud service provider is responsible for the security of the cloud, including the physical plant and hardware it owns and operates. The customer is responsible for how it configures and uses the cloud environment.

This means the responsibilities of cloud customers include the application and OS layers as well as the configuration of cloud infrastructure resources. Applying a policy framework such as the CIS AWS Foundations Benchmark to your cloud infrastructure will enable you to continuously monitor for drift and misconfiguration

Additionally, it’s important to recognize that, even if you’re making extensive use of serverless resources, you likely still have security-critical resources such as networks, IAM roles, databases, messaging services and storage. Innovative new cloud services require new security responsibilities, but rarely do they relieve you of old ones.

Myth #5: Getting cloud security right slows down developers

Developers need to move fast, but security and compliance teams need to slow things down. These competing incentives have long created friction between the two teams, and in cloud, this friction is amplified. Developers have direct access to on-demand cloud resources, and they’ll take advantage of that. Implementing policy checklists, manual approvals and audits, provisioning guardrails and restricting cloud console access can provide some sense of control and security, but these measures strip away many advantages the cloud offers.

The cloud gives you the means to end the long-standing tension between application teams and security/compliance teams. Leverage cloud APIs to gain continuous visibility into your environments and compliance posture. Help developers shift left on security and compliance with policy as code automation tools to identify and fix issues quickly and early in the software development cycle. Empower developers with the automation tools to check their own work against policy before they deploy to production.

Next Steps

Now that we’ve examined what isn’t true about cloud security, the reassuring truth is that the nature of cloud itself allows it to be more secure than the data center, if you use it properly. Follow these basic steps to strengthen your organization’s cloud security posture:

  1. Validate your cloud environments against a number of compliance policy frameworks including HIPAA, PCI, SOC 2, NIST 800-53, ISO 27001 and GDPR.
  2. Baseline your cloud environments to get complete and accurate visibility into your cloud infrastructure and configurations.
  3. Monitor for baseline drift to protect against misconfiguration, security incidents and compliance violations.
  4. Shift left on cloud infrastructure security and compliance with CI/CD integration to ensure your developers can move quickly without increasing the risk of a data breach or compliance violations.
Featured eBook
SANS 2019 Threat Hunting Survey: The Differing Needs of New and Experienced Hunters

SANS 2019 Threat Hunting Survey: The Differing Needs of New and Experienced Hunters

SANS threat hunting experts Mathias Fuchs and Joshua Lemon capture the different needs within organizations that are just starting their threat hunting journey, versus those who are honing their skills and programs. Read the report to help grow your program and improve threat hunting with: Definitions of threat hunting Methodologies of performing threat hunting Spending ... Read More
Authentic8
Josh Stella

Josh Stella

Josh Stella is Co-founder and CTO of Fugue, the cloud infrastructure automation and security company. Fugue identifies security and compliance violations in cloud infrastructure and ensures they are never repeated. Previously, Josh was a Principal Solutions Architect at Amazon Web Services, where he supported customers in the area of national security. He has served as CTO for a technology startup and in numerous other IT leadership and technical roles over the past 25 years.

josh-stella has 2 posts and counting.See all posts by josh-stella