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):
- Understand the complete state of your production environments by baselining your infrastructure.
- Continuously survey the configuration state of your infrastructure and compare it to the baseline you established.
- 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. – Read more