cloud security baseline — the foundation that needs to be right from day one — Malay Tech JournalSkip to content

cloud security baseline — the foundation that needs to be right from day one

Cloud Security Baseline (CSB) is the minimum set of controls that must exist before the first workload deploys. Here's the practical breakdown — from CIS Benchmarks, drift detection, to automatically enforcing baseline.

Field notes in English. For Cloud Security Engineers who want to understand the relationship between Cloud Security Baseline, CSPM, and how to enforce posture automatically.

There’s a pattern that shows up almost every time an organization gets breached through cloud:

It’s not a zero-day exploit. It’s not a nation-state attacker with sophisticated tools. Default configuration that was never changed.

Root account without MFA. S3 bucket public by default. CloudTrail disabled. Security group allowing 0.0.0.0/0. All exist because cloud providers set defaults for convenience during onboarding — not for security.

Cloud Security Baseline (CSB) is the answer to this: a set of minimum controls that must exist from day one, before any workload deploys.


Cloud Security Baseline = set of security controls that must be enforced on every account/subscription/project, without exception, before any workload is allowed to run.

How it differs from regular security hardening:

Security Hardening: Cloud Security Baseline:
- Per-workload - Per-account/subscription
- After deploy - Before first workload
- Specific to service - Universal for all resources
- Optional (best practice) - Mandatory (non-negotiable floor)

CSPM vs CSB:

flowchart LR
subgraph csb [Cloud Security Baseline · CSB]
direction TB
S1["STATIC<br/>definition"]:::csb
S2["What MUST<br/>exist"]:::csb
S3["Setup once<br/>enforce always"]:::csb
S4["Foundation<br/>floor"]:::csb
S5["Checklist<br/>policy-as-code"]:::csb
end
subgraph cspm [Cloud Security Posture Management · CSPM]
direction TB
M1["CONTINUOUS<br/>monitoring"]:::cspm
M2["Is it still<br/>there?"]:::cspm
M3["Scan repeatedly<br/>alert on drift"]:::cspm
M4["Ongoing<br/>visibility"]:::cspm
M5["Tools<br/>Wiz · Defender · Orca"]:::cspm
end
classDef csb fill:#1e1b4b,stroke:#818cf8,color:#e0e7ff
classDef cspm fill:#0f2a1c,stroke:#4ade80,color:#bbf7d0

CSB is what you define. CSPM is the tool that ensures CSB stays that way.


You don’t need to invent CSB from scratch. There are established benchmarks to start with:

BenchmarkLatest versionPlatform
CIS AWS Foundationsv7.0.0 (Apr 2026)AWS
CIS Azure Foundationsv6.0.0 (Apr 2026)Azure
CIS GCP Foundationsv3.0.0GCP
CIS Kubernetesv1.9.0K8s

AWS Security Hub now supports CIS AWS Foundations Benchmark v5.0 (announced Oct 2025) — you can enable it directly from the console, auto-scans every resource.

Microsoft publishes MCSB covering multi-cloud (AWS + Azure in one framework). The “Posture and Vulnerability Management” section explicitly defines:

“Define the security configuration baselines for different resource types in the cloud. Use configuration management tools to establish the configuration baseline automatically before or during resource provisioning.”

For regulated industries (government, healthcare, finance) — NIST controls are mandatory. You can map CIS controls to NIST for dual compliance.


This is the floor that cannot be compromised — based on CIS AWS v7.0 + MCSB + field experience:

✅ Root account MFA enabled
✅ Root account access keys DELETED (not disabled, deleted)
✅ MFA required for all human users
✅ Password policy: min 14 chars, complexity, no reuse for 24 passwords
✅ No inline policies (all managed policies)
✅ Principle of least privilege enforced
✅ No wildcard (*) in Action or Resource for production roles
✅ Access keys rotated every 90 days
✅ Inactive users/roles disabled after 90 days

✅ CloudTrail enabled — ALL regions, ALL management events
✅ CloudTrail log file validation enabled
✅ CloudTrail logs sent to S3 + CloudWatch Logs
✅ S3 bucket for CloudTrail: private, versioning on, MFA delete
✅ VPC Flow Logs enabled for all VPCs
✅ Config Rules enabled (AWS Config)
✅ GuardDuty enabled in all regions
✅ Security Hub enabled + CIS benchmark enabled

✅ No Security Group with inbound 0.0.0.0/0 to port 22 (SSH)
✅ No Security Group with inbound 0.0.0.0/0 to port 3389 (RDP)
✅ Default VPC not used for production workloads
✅ VPC endpoints for S3 and DynamoDB (prevent traffic to internet)
✅ Network ACLs reviewed, no allow-all rules

✅ S3 Block Public Access enabled — account level
✅ S3 bucket versioning enabled for critical data
✅ EBS encryption by default enabled
✅ RDS encryption at rest enabled
✅ S3 Server-Side Encryption (SSE-S3 minimum, SSE-KMS for sensitive)
✅ Secrets in Secrets Manager / Parameter Store, not plaintext

✅ Billing alerts configured (threshold not a big number)
✅ Budget alerts configured
✅ Cost anomaly detection enabled
✅ Resource tagging policy enforced (Owner, Environment, CostCenter)
✅ AWS Organizations SCPs (Service Control Policies) to restrict regions

Manual checklists aren’t sustainable. Here’s how to make CSB enforce itself:

# Terraform — deploy CIS-aligned Config Rules
resource "aws_config_config_rule" "mfa_enabled_for_iam_console" {
name = "mfa-enabled-for-iam-console-access"
source {
owner = "AWS"
source_identifier = "MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS"
}
}
resource "aws_config_config_rule" "root_mfa_enabled" {
name = "root-account-mfa-enabled"
source {
owner = "AWS"
source_identifier = "ROOT_ACCOUNT_MFA_ENABLED"
}
}
resource "aws_config_config_rule" "s3_block_public" {
name = "s3-account-level-public-access-blocks"
source {
owner = "AWS"
source_identifier = "S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS"
}
}

# csb_baseline.rego — enforce CSB in CI/CD pipeline
package csb.baseline
# DENY: S3 bucket with public access
deny[msg] {
resource := input.resource.aws_s3_bucket[name]
resource.acl == "public-read"
msg := sprintf("CSB VIOLATION: S3 bucket '%v' must be private", [name])
}
# DENY: Security group allowing SSH from anywhere
deny[msg] {
resource := input.resource.aws_security_group[name]
rule := resource.ingress[_]
rule.from_port <= 22
rule.to_port >= 22
rule.cidr_blocks[_] == "0.0.0.0/0"
msg := sprintf("CSB VIOLATION: Security group '%v' allows SSH from 0.0.0.0/0", [name])
}
# DENY: IAM user without MFA
deny[msg] {
resource := input.resource.aws_iam_user[name]
not resource.force_destroy
not input.resource.aws_iam_user_login_profile[name]
msg := sprintf("CSB VIOLATION: IAM user '%v' has no MFA configured", [name])
}

.pre-commit-config.yaml
repos:
- repo: https://github.com/bridgecrewio/checkov
rev: 3.2.0
hooks:
- id: checkov
args:
- --framework
- terraform
- --check
- CKV_AWS_1 # S3 bucket access logging
- CKV_AWS_8 # EC2 no public IP
- CKV_AWS_18 # S3 no public access
- CKV_AWS_41 # CloudTrail enabled
- --soft-fail # warn first, switch to hard-fail when ready

CSB defines the baseline. Drift happens when someone or something changes configuration from that baseline. CSPM tools monitor for this drift in real-time.

flowchart LR
T0["Time 0<br/>S3 bucket private<br/>CSB compliant"]:::ok
T1["Time 1<br/>Dev sets ACL public-read<br/>DRIFT EVENT"]:::drift
T2["Time 2<br/>CSPM detects 5 min<br/>alert fired"]:::alert
T3["Time 3<br/>Auto-remediation<br/>or manual fix"]:::fix
T4["Time 4<br/>S3 bucket private<br/>compliant again"]:::ok
T0 --> T1 --> T2 --> T3 --> T4
classDef ok fill:#0f2a1c,stroke:#4ade80,color:#bbf7d0
classDef drift fill:#2d1518,stroke:#f87171,color:#fecaca
classDef alert fill:#2e2410,stroke:#fbbf24,color:#fde68a
classDef fix fill:#0f2436,stroke:#38bdf8,color:#bae6fd

Without CSPM, drift might go undetected for days or weeks.

ToolStrengthFree tier?
AWS ConfigNative AWS, CIS benchmark built-inYes (limited rules)
AWS Security HubAggregate findings, CIS v5.0 supportYes (30 day trial)
Checkov + CI/CDPre-deploy scan, policy-as-code✅ Open source
tfdrift-falcoReal-time Terraform drift detection via Falco + CloudTrail✅ Open source (2026)
WizDeep posture + graph-based riskEnterprise (paid)
Orca SecurityAgentless, full stack visibilityEnterprise (paid)
Defender for CloudAzure-native + multi-cloudPartially free

For small teams / startups: AWS Config + Checkov in CI/CD is enough for CSB enforcement. Free, automated, covers 80% of common misconfigs.

For enterprise: Wiz or Orca for broad visibility, Defender for Azure-native, tfdrift-falco for real-time IaC drift.


Traditional CSB (CIS, NIST) doesn’t cover AI/agent workloads. This gap is getting critical:

Traditional controlGap for AI workload
IAM least privilegeAgent has identity — needs scoped, time-bound capability
S3 access controlAgent can read/write S3 — needs audit trail per-task, not per-user
CloudTrail loggingLog “service_account_X accessed S3” — but why? for what task?
Network restrictionAgent can call external APIs — needs per-intent network policy

CSB extension for AI workloads (current best practice):

ai-workload-baseline.yaml
ai_baseline:
agent_identity:
- each agent has dedicated IAM role (not shared)
- role cannot assume human user roles
- session duration maximum 1 hour
audit:
- every agent action has task_id in logs
- CloudTrail + Langfuse/OTel for full trace
network:
- agent roles in SCP — restrict to allowed API endpoints
- egress filter via VPC endpoint policy
data_access:
- agent cannot access production data without explicit tag approval
- S3 bucket policy: deny if "ai-approved" tag absent

The shift-left controls above catch most of the agent identity and audit gaps. But they don’t address what happens when a misconfig slips through CI and lands in production — that’s where auto-remediation and agentic remediation come in. See the full 2026 vendor landscape and the Palo Alto Cortex Cloud deep dive in the next post: Shift-Left → Auto-Remediation → Agentic Remediation.


For a new account or auditing existing accounts:

flowchart TB
W1["Week 1 · Assess<br/>Checkov scan on Terraform<br/>AWS Security Hub + CIS benchmark<br/>Baseline gap report"]:::w1
W2["Week 2 · Fix critical<br/>Root MFA · no public S3<br/>CloudTrail all regions<br/>Close open SSH/RDP"]:::w2
W3["Week 3 · Automate<br/>Terraform Config Rules<br/>OPA / Rego in CI/CD<br/>Pre-commit Checkov hooks"]:::w3
W4["Week 4+ · Continuous<br/>AWS Config + Security Hub<br/>Alert to Slack / PagerDuty<br/>Monthly CSB review"]:::w4
W1 --> W2 --> W3 --> W4
classDef w1 fill:#1e1b4b,stroke:#818cf8,color:#e0e7ff
classDef w2 fill:#2d1518,stroke:#f87171,color:#fecaca
classDef w3 fill:#2e2410,stroke:#fbbf24,color:#fde68a
classDef w4 fill:#0f2a1c,stroke:#4ade80,color:#bbf7d0

CSB is security floor, not ceiling.

You can have perfect CSB and still get breached — if an attacker exploits the application layer, insecure code, or zero-day. But CSB ensures you don’t get breached for preventable reasons: root without MFA, S3 accidentally public, CloudTrail off.

In the large and fast-moving world of cloud, automated CSB and continuous CSPM are the minimum viable security posture. Not optional. Not “we’ll do it later”. From day one an account exists.


References:

  • CIS AWS Foundations Benchmark v7.0.0 — Tenable Audits (Apr 2026)
  • CIS Azure Foundations Benchmark v6.0.0 — NIST NCP (Apr 2026)
  • AWS Security Hub — CIS AWS Foundations Benchmark v5.0 support (Oct 2025)
  • Microsoft Cloud Security Benchmark — Posture and Vulnerability Management
  • ISACA — Cloud Security Posture Management: Control Plane for Modern Cloud Risk (2026)
  • CloudToolStack — Cloud Security Baseline 2026: What Every Account Should Have
  • higakikeita/tfdrift-falco — Real-time Terraform Drift Detection via Falco (2026)
  • OpenMalo — CSPM Practical Guide 2026