Chat with your cloud in Turbot Pipes →
What We Prevent: The Four Layers

What We Prevent: The Four Layers

What We Prevent: The Four Layers

Prevention-first cloud security uses four layers of preventive controls to stop misconfigurations before they create risk. Each layer operates differently, prevents different categories of issues, and has distinct strengths. Understanding what each layer prevents and how they complement each other is essential for building comprehensive prevention coverage.

Most organizations already have some preventive controls deployed. IaC scanning in a few repositories. Organization policies blocking the most critical risks. Account-level encryption defaults. Runtime auto-remediation for specific issues. These scattered controls provide value, but they leave gaps. Comprehensive prevention requires intentional coverage across all four layers.

These are the four layers of preventive controls: Build controls catch issues in code, Access controls block risky actions, Config controls make resources secure by default, and Runtime controls auto-fix drift. Together, they create overlapping prevention coverage where issues that bypass one layer get caught by others.

  • 1. Build Controls: Prevention in Code

    Build controls catch misconfigurations in Infrastructure-as-Code templates before deployment. This is prevention at the earliest possible stage. Issues found during code review never reach cloud environments, never create risk, and never require coordination across teams to fix.

    Infrastructure-as-Code scanning analyzes templates for security issues. Terraform, CloudFormation, Azure Resource Manager templates, Google Cloud Deployment Manager, Pulumi, and Kubernetes manifests all get scanned. Scanning tools like Checkov, tfsec, Trivy, Terrascan, and cloud-native offerings identify misconfigurations in templates: unencrypted storage, overly permissive s

    1. Build Controls: Prevention in Code365 words

  • 2. Access Controls: Organization-Wide Policy Enforcement

    Access controls prevent issues through organization-level policies that block risky actions at the API level. These policies enforce across all cloud accounts, regions, and users. They create boundaries on what's possible regardless of how resources get created-whether through IaC, console, CLI, SDK, or third-party tools.

    AWS Service Control Policies, Azure Policy, and GCP Organization Policies are the primary access control mechanisms. These policies attach to organizational units, subscriptions, or folders and enforce on all child accounts. A policy preventing public S3 bucket creation applies to every account in the organizatio

    2. Access Controls: Organization-Wide Policy Enforcement455 words

  • 3. Config Controls: Secure Defaults

    Config controls prevent issues by making resources secure by default through account and service settings. When properly configured, security becomes automatic. Developers don't need to remember to enable encryption or block public access. The account or service configuration does it automatically for all new resources.

    AWS account-level settings like S3 Public Access Block and EBS encryption by default are archetypal config controls. Enable S3 Public Access Block at the account level and all new buckets in that account are private by default. Enable EBS encryption by default and all new volumes get encrypted automatically. Developers create resources

    3. Config Controls: Secure Defaults449 words

  • 4. Runtime Controls: Continuous Monitoring and Auto-Remediation

    Runtime controls prevent issues from persisting by continuously monitoring for drift and automatically remediating misconfigurations. Even if issues bypass build controls, access controls, and config defaults, runtime controls detect and correct them within minutes. Resources stay compliant continuously rather than drifting until the next manual scan.

    Runtime monitoring evaluates resources against security policies continuously. Tools like Turbot Guardrails, AWS Config with auto-remediation, Azure Policy with remediation tasks, Cloud Custodian, or custom automation monitor resource configurations. When a resource drifts fro

    4. Runtime Controls: Continuous Monitoring and Auto-Remediation479 words

  • Defense in Depth: How the Four Layers Work Together

    The four layers of preventive controls create overlapping defense. Issues that bypass one layer get caught by others. This defense in depth means no single control failure creates exposure. Multiple layers must all fail simultaneously for a misconfiguration to reach production and persist.

    Consider how the four layers prevent a public S3 bucket:

    Build controls scan the IaC template during pull request. If the template specifies public access, scanning tools flag the issue. Developer fixes the template before merging. Issue prevented at the earliest stage.

    Access controls block the bucket creation API call if it specifies

    Defense in Depth: How the Four Layers Work Together324 words

  • Coverage Patterns and Strategic Deployment

    Organizations typically deploy the four layers in different orders based on their starting point and constraints:

    Access-first pattern: Organizations with mature cloud architecture teams often start with access controls. Organization policies can be deployed centrally without requiring changes to development workflows. They enforce universally across all accounts immediately. Quick wins demonstrate prevention value before expanding to other layers.

    Build-first pattern: Organizations with strong DevOps practices and high IaC coverage often start with build controls. They already use CI/CD pipelines where scanning integrates naturally

    Coverage Patterns and Strategic Deployment236 words

  • Key Takeaways

    • The four layers of preventive controls define what we prevent: Build controls catch issues in code, Access controls block risky actions, Config controls make resources secure by default, and Runtime controls auto-fix drift.
    • Each layer has distinct strengths and limitations. Comprehensive prevention requires coverage across all four layers rather than perfect coverage in one layer.
    • Defense in depth emerges from overlapping controls. Issues that bypass one layer get caught by others. Multiple control failures must align simultaneously for misconfigurations to reach production and persist.
    • Organizations deploy the four layers in different orders ba
    Key Takeaways114 words

  • What's Next

    These four layers of preventive controls form the what behind prevention-first security: the specific mechanisms that stop misconfigurations before they create risk.

    For a complete overview of the prevention-first framework, see Prevention 101.

    To understand the other components:

    What's Next115 words