A guide to cloud security and compliance

Security knowledge has become a must-have skill for cloud engineers. One of the hurdles to acquiring knowledge is the use of lots of acronyms that security engineers may understand but leaves cloud engineers wondering what they’re looking at.

In this post, I’ll provide a basic explanation of cloud security and compliance, the concepts behind them, and two acronyms you’ll often hear in that context—“GRC” (governance, risk and compliance) and “CSPM” (cloud security posture management).

What’s cloud security, what’s compliance? ​

Let’s start with definitions of compliance and security:

• Cloud security consists of processes, strategies, and tools used to protect the confidentiality, integrity, and availability of your cloud infrastructure.

• Cloud compliance implements processes, policies, and practices to ensure that operations and infrastructure comply with regulatory requirements and industry standards.

Good cloud security reduces the risk of unauthorized access, breaches, and threats. Compliance frameworks serve to meet specific legal, contractual, and business obligations.

Examples of standardized compliance frameworks are CIS, SOC 2, ISO 27001, NIST, HIPAA, FedRAMP, or GDPR. These frameworks provide the guidelines, standards and best practices to protect the security of cloud environments and pass audits. Some companies also have custom, internal frameworks, which could be as simple as a tagging policy.

The shared responsibility model ​

To manage security risks and compliance, the cloud service providers (CSP) follow a “shared responsibility model”:

• Customers are responsible for the secure configuration of the cloud services, workloads and applications running in their cloud accounts.

• The CSPs are responsible for protecting the underlying infrastructure cloud services run on: hardware, software, networking, and facilities.

Below is an illustration of the AWS Shared Responsibility Model that depicts this separation of responsibilities.

The challenge for the customer’s responsibility in this model lies in the size and frequent change of their cloud environment due to developer activity, and the expertise to understand each resource kind in use and its configuration options.

The risks in your cloud asset inventory ​

Even for a small start-up with 20 or so developers, the number of cloud resources can run in the tens or hundreds of thousands. For enterprises, it’s in the millions. Together, these Individual resources form a company’s “cloud asset inventory.”

Each resource type in the inventory has its own set of configurations—and there are enough knobs and turns available to get it wrong. A classic example of a misconfigured resource is a “public S3 bucket.” If an S3 bucket is unintentionally made public, whatever sensitive data the bucket contains is now publicly accessible.

Most cloud security breaches are the direct result of a misconfiguration (#3 in the Cloud Security Alliance’s Pandemic 11 Report).

A single misconfigured resource is one problem, and many misconfigurations may not be that critical. But in cloud-native resources are connected, often many levels deep. Access to one misconfigured resource can allow an attacker to traverse the inventory (a.k.a., “lateral movement”), access other resources and get their hands on the sensitive data that way, or even change permissions and execute malicious code. That’s why identifying and understanding misconfigurations is a critical capability to protect your data and workloads in the cloud.

Ensuring compliance and security of your inventory ​

Misconfigurations are a fact of life in the cloud. They happen all the time due to frequent change, human error, or manual intervention—which is fine as long as security is aware.

But for an individual security engineer, it’s impossible to know all good security configurations, let alone track and enforce them across a large and changing inventory. That’s why most compliance and security tools for cloud infrastructure have become two things:

1. An asset inventory that provides visibility into the cloud environment and creates a baseline of what resources are running and how they are configured.

2. A rule engine that runs compliance checks against the inventory, evaluates its configurations and creates alerts when things go past a certain baseline.

With those two components, security engineers can understand if their infrastructure follows a baseline of security. Security engineers are usually okay to take some risks but also don’t want things to deviate too much within a paved road that they’ve established in conjunction with DevOps.

The difference between security and compliance tools ​

To separate the use cases and benefits for compliance and security tools, analyst firms like Gartner and Forrester have created different categories with (somewhat convoluted) acronyms:

• Governance, Risk and Compliance (GRC). Tools in this category monitor and collect evidence of a company’s broader security controls, not just cloud infrastructure. They also automate and document the processes to ensure audit readiness. Completed audits help shorten sales cycles, as they’re often milestones in software procurement. For example, a FinTech company selling to banks will always have to document SOC 2 compliance.

• Cloud Security Posture Management (CSPM). CSPM tools automate security and compliance in the cloud by providing visibility into cloud inventory, identifying misconfigurations, and enforcing policies. CSPM tools also integrate with the security engineering toolchain, such as ticketing and workflow tools, to automate the remediation of misconfigurations and ensure your infrastructure stays compliant.

GRC and CSPM address different aspects of cloud security, but they are also complementary and work together to create a comprehensive security strategy. If GRC sets the processes and policies for security, then CSPM provides the tools and automation needed to implement and enforce those policies.

Another difference is the user. CSPM tools are mostly used by security engineers, whereas the audience for GRC tools also includes legal or finance—pretty much anyone involved in compliance. That’s why CSPM tools tend to have wider coverage of cloud resources and integrations with other security tools to ingest data from.

Cloud provider tools for compliance and security ​

All cloud providers offer a native portfolio of compliance and security products. The services cover both their part of the shared responsibility model, with portals to download their latest compliance reports, as well as tools that help customers check their own security and compliance posture.

The slide below lists the corresponding services for each cloud provider and their job-to-be-done features. The comparison and JTBD descriptions may not always be apples-to-apples for every category, but are directionally correct.

What to look for in a security product ​

Native CSP tools are the natural place to start with compliance and security. However, the slide also shows two shortcomings:

1. Within a single provider, security tooling is not always integrated. Security data is distributed across the stack and often requires engineering work to stitch together data from different tools into a single dashboard.

2. Across different providers, there are repetitive and overlapping implementations of the same frameworks, with data again stuck in the respective tools within each platform—a relevant factor for multi-cloud infrastructure.

This is where third-party compliance and security tools offer a viable alternative.

These tools specialize in providing one consistent security experience, across all assets and clouds, and also support more complex deployments such as containerized workloads. We think a tool like that should have four characteristics:

1. A cloud asset inventory with a single of all your resources in a consistent data format, for both single- and multi-cloud infrastructure.

2. Support for common compliance frameworks across all cloud providers, and the flexibility to implement and monitor custom policies against the inventory.

3. Custom reporting for internal and external audiences, with different levels of detail depending on the audience and use case.

4. Integration with ticketing and workflow tools to automate remediation, so that life for DevOps is easier and security is not perceived as “the bad guy” anymore.

That way, every company can have enterprise-grade security and compliance, without lots of engineering investment to make a security tool stack work. Finally, we believe security should be open source so that it’s transparent and extensible.

It’s the type of tool we’re building with Fix. We started with support for AWS and the CIS benchmark, and are now constantly expanding. If you are interested in learning more, check out our GitHub repo or request early access and a demo here. To stay updated on our progress – check out our LinkedIn page!