Building a Continuous Cloud Security Posture Management Program

Annual penetration tests and quarterly security reviews are useful. They are not sufficient. A cloud environment that passes its June security review can have three publicly accessible S3 buckets, an overly permissive security group, and a root credential with MFA disabled by August — and none of these changes will appear in any report until the next scheduled review.

Cloud Security Posture Management (CSPM) solves the fundamental problem of continuous visibility: instead of snapshots, you get a live compliance score that moves as your environment changes — minute by minute, not quarter by quarter.

AWS Security Hub: The CSPM Aggregation Layer

AWS Security Hub is the closest thing AWS has to a native CSPM platform. It aggregates findings from GuardDuty, Inspector, Macie, Config, IAM Access Analyzer, and supported partner tools into a single normalized view. More importantly, it runs continuously against a set of security controls and maintains a real-time compliance score.

That score is your CSPM score. A Security Hub compliance score of 85% means 15% of the enabled controls are currently failing somewhere in your environment. The score updates within minutes of a resource configuration change. When a developer accidentally creates a public S3 bucket, your score drops and a finding appears — not in 90 days at the next review, but in minutes.

Enable the AWS Foundational Security Best Practices (FSBP) standard first. It covers the most critical controls across IAM, S3, EC2, Lambda, and RDS. Then add the CIS AWS Foundations Benchmark v1.4 — this is widely recognized and maps directly to SOC 2 and ISO 27001 controls.

Running both standards simultaneously gives you broad coverage. The key is treating the compliance score as a team-level metric, visible in a dashboard, with clear ownership of findings by service team.

AWS Config Rules: The Assessment Engine

AWS Config rules evaluate whether resource configurations comply with your security policies. There are two types:

Managed rules are pre-built checks against specific resource properties:

• s3-bucket-public-read-prohibited — fires when any S3 bucket has a public ACL or bucket policy
• restricted-ssh — fires when a security group allows inbound SSH from 0.0.0.0/0 or ::/0
• encrypted-volumes — checks that all EBS volumes use encryption
• rds-instance-public-access-check — flags RDS instances with PubliclyAccessible: true
• lambda-function-public-access-prohibited — flags Lambda functions with resource-based policies allowing public invocation

Custom Config rules use Lambda functions for evaluations that managed rules can’t express. A common example: ensuring every EC2 instance has a owner and environment tag. When a resource is created without these tags, the Config rule evaluates it as NON_COMPLIANT and Security Hub surfaces a finding.

def evaluate_compliance(configuration_item, rule_parameters):
    required_tags = {"owner", "environment", "cost-center"}
    resource_tags = set(configuration_item.get("tags", {}).keys())
    
    if required_tags.issubset(resource_tags):
        return "COMPLIANT"
    
    missing = required_tags - resource_tags
    return {
        "compliance_type": "NON_COMPLIANT",
        "annotation": f"Missing required tags: {', '.join(missing)}"
    }

Continuous vs Point-in-Time: The Configuration Change Trigger

The critical difference between CSPM and traditional auditing is the trigger model. Traditional audits run on a schedule. Config rules evaluate on configuration change — the moment a resource is modified, the relevant rules re-evaluate against the new configuration.

This means:

• A security group opened to 0.0.0.0/0 generates a finding within seconds
• A public S3 bucket created at 11pm on a Friday generates a finding before midnight
• A new IAM user created without MFA generates a finding before their first login

Periodic evaluation (the alternative trigger mode) is still valuable for checks that require external data — for example, checking whether an S3 bucket’s contents match its sensitivity classification, or whether an EC2 instance’s AMI is still current. Use change-triggered rules for configuration properties and periodic rules for content or state checks.

Building the Alert-to-Ticket Pipeline

Security findings are only valuable if someone acts on them. The Security Hub + EventBridge + ticket system pipeline automates this:

Security Hub generates findings → EventBridge filters by severity and status → Lambda creates tickets.

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL", "HIGH"] },
      "RecordState": ["ACTIVE"],
      "WorkflowState": ["NEW"]
    }
  }
}

The Lambda handler maps the finding to the correct team using a tag-based ownership model: look up the affected resource’s team tag, then create the Jira ticket in that team’s project. Include the finding title, resource ARN, severity, direct link to the Security Hub finding, and a suggested remediation step from the finding’s Remediation.Recommendation field.

Drift Detection: Knowing What Changed

Config’s drift detection capability is underutilized. When a resource enters a compliant configuration, Config records that state as the baseline. If the resource is subsequently modified, Config generates a non-compliance finding with a precise diff.

This answers the “it was fine last week” question. Instead of discovering during an audit that a security group was modified three months ago and no one can explain why, Config gives you:

• The exact timestamp of the change
• The IAM principal who made it (from the associated CloudTrail event)
• The exact configuration before and after

Pair the Config finding with the corresponding CloudTrail event by correlating the configurationItemCaptureTime timestamp with CloudTrail events from the same resource ARN within a 5-minute window.

The Prioritization Model

A freshly enabled Security Hub account on a mature AWS environment will generate hundreds of findings. Working through them alphabetically is a path to exhaustion. The correct sequence:

1. Severity + exposure — Critical and High findings on resources with public internet access are P1. A public S3 bucket with a CRITICAL severity is a same-day fix.
2. Production first — Filter findings by the environment: production resource tag. Production findings before sandbox.
3. Resource type clusters — Fix IAM findings in bulk (they’re often related — a single policy change can resolve multiple findings). Then S3, then compute, then networking.

Target a maintained posture above 90% on critical and high controls — not 100%. An organization that maintains 92% continuously is more secure than one that hits 100% annually and degrades to 65% in between.

Metrics for Leadership Visibility

Three metrics define a healthy CSPM program:

• Mean time to remediation (MTTR) for critical findings — target under 24 hours
• Weekly compliance score trend — should trend upward; any week-over-week decline triggers investigation
• New critical/high findings introduced per sprint — measures whether engineering practices are improving

A dashboard showing MTTR dropping from 14 days to 36 hours over a quarter is a compelling story for leadership. It also provides the documentation you need when a SOC 2 auditor asks how you ensure security issues are addressed promptly.

---

CloudDefender extends AWS-native CSPM with cross-cloud coverage, custom policy evaluators, and automated remediation workflows — maintaining continuous posture visibility without manual intervention.