Cloud Security Baseline with CIS | Cloud DevOps Solutions

A Cloud Security Baseline: CIS Benchmarks, WAF and Threat Detection

A cloud security baseline is the minimum set of controls every account must have: CIS benchmark settings, encryption, central logging, threat detection with GuardDuty or Defender, a web application firewall for public apps, and alerting. We deploy it as code and check it continuously.

Key takeaways

A baseline is a minimum applied everywhere, not a one-off audit of a single account.

CIS benchmarks give a recognised starting list, which we tune to your context rather than apply blindly.

Prevention, detection and response are all covered: policy, GuardDuty or Defender, and alerts someone sees.

Findings need owners and a process, otherwise the dashboard only collects red items.

Compliance frameworks are supported by the baseline, but the baseline alone does not certify you.

Security that arrives after the migration arrives late

The usual order of events in a rushed migration is: move the workloads, get the business running, then ask security to review. By then public storage has been created for convenience, a security group has been opened wide for troubleshooting, and logging covers only some regions. Reviewers produce a long list, and every item requires changing something live.

A baseline reverses the order. The controls exist in the landing zone before workloads arrive, so each migrated system inherits them. This is a core part of our cloud migration service, and it connects to the ongoing posture work in Managed DevOps.

What good looks like

Every account and subscription has the same minimum controls, applied by code.
Audit logs cover all regions, are tamper resistant and are kept in a separate protected location.
Storage, databases and volumes are encrypted, and public exposure is blocked by default.
Threat detection is on, and someone is paged for high severity findings.
Internet-facing applications sit behind a WAF and a current TLS policy.
The gap between the baseline and the actual state is measured continuously.

The layers

Preventive controls

Prevention is the cheapest control. Organisation-level policies deny actions outright: disabling audit logging, creating public buckets, launching in unapproved regions, removing detection services. On Azure, Azure Policy with deny effects does the same. Preventive rules need testing, since a wrong deny can break a pipeline.

Detective controls

Detection answers what happened and what looks wrong. On AWS this includes CloudTrail for API activity, AWS Config for configuration state and change history, GuardDuty for threat detection and Security Hub to aggregate findings and run benchmark checks. On Azure, Defender for Cloud gives posture assessment and threat protection, with Activity Logs and diagnostic settings feeding a central workspace.

Enabling everything everywhere has a cost, so we scope sensibly: all accounts and regions for audit logging and GuardDuty, and more selective use of paid features based on risk.

Edge protection

Public applications get a web application firewall. On AWS, AWS WAF attaches to CloudFront, an Application Load Balancer or API Gateway, with managed rule groups as a starting point and rate-based rules for abuse. On Azure, WAF sits on Application Gateway or Front Door. Managed rules need a period in count mode to find false positives before blocking. A WAF is a layer, not a cure for vulnerable code.

Putting CIS to work

A scan against the benchmark is an assessment, but the value comes from fixing causes in code. A small example enabling account-level protections in Terraform:

resource "aws_s3_account_public_access_block" "this" {
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_ebs_encryption_by_default" "this" {
  enabled = true
}

resource "aws_guardduty_detector" "this" {
  enable = true
}

resource "aws_iam_account_password_policy" "strict" {
  minimum_password_length = 14
  require_symbols         = true
  require_numbers         = true
  max_password_age        = 0
}

These resources belong in the shared baseline module applied to every account. Scanners such as Prowler or Checkov, and Security Hub’s benchmark standards, then verify the result. When a control does not suit you, record the exception, the reason and a review date in code or in the findings tool. An undocumented skipped control looks like an oversight to an auditor.

A worked example: triaging the first scan

The first benchmark scan of a new account usually returns a long list, and the instinct is to fix everything at once. We sort it instead into three groups. The first is controls that a baseline module can enforce for every account, such as encryption defaults and public access blocks, which are fixed once in code. The second is findings that need a decision from a person, such as a bucket that is deliberately public for a website, which receive a recorded exception with an owner and a review date. The third is genuine defects in a workload, which go to the team that owns it with a severity. Working this way turns a frightening report into a short, finite backlog and stops the same findings returning with every new account.

Decisions and trade-offs

Native tools or third party. Native services integrate easily and avoid extra agents. Third-party posture platforms can span multiple clouds and offer better dashboards, at extra cost. Single-cloud teams usually do well with native tools.

Block or alert. Blocking is safer, alerting is gentler on existing workflows. Block the clearly dangerous, alert on the debatable, and move items from alert to block as confidence grows.

Depth versus size. A ten-person startup does not need a security operations centre, but it does need logging, detection and an on-call recipient. Scale the process to the team, and consider our SRE and incident response support for response capability.

When the baseline is not enough. Regulated workloads, such as payments or health data, require additional controls and formal assessment beyond a baseline. We help scope them, and we do not claim certification on your behalf.

Common failure modes

Findings with no owner, so the backlog grows.
Admin access too broad, undermining everything else. See identity integration.
Logging disabled in rarely used regions, where attackers like to work.
WAF left in count mode forever.
Secrets in code or images, which no benchmark fully catches. We use a secrets manager and scanning in CI.
One-off hardening that drifts. Continuous checks catch drift.

Delivery and handover

Baseline modules, policies and rules are in your repository. You receive the control list with status, accepted exceptions, a findings triage process, and a short guide for adding a new account into the baseline. Response steps are captured in the operations runbook.

How to tell it is working

New accounts are compliant on creation. Benchmark scores are stable and the exceptions are documented. High severity findings are acknowledged quickly and closed with a reason. Auditors and customers get evidence from the tools instead of from screenshots. To review your baseline, contact us.

References

How we deliver it

Define the baseline

We select the controls from CIS benchmarks and your compliance needs, and record which are enforced, monitored or accepted as exceptions.

Enforce preventive controls

Organisation policies and guardrails stop risky settings, such as public storage or unencrypted volumes, before they exist.

Turn on detection

Audit logging, configuration tracking, threat detection and posture management are enabled across all accounts and regions in scope.

Protect public entry points

A web application firewall, TLS policy and rate limiting are applied to internet facing applications.

Route findings to people

Alerts go to a defined channel with severity, owner and expected response, and noisy findings are tuned.

Verify and report

We run benchmark scans, fix or document gaps, and give you evidence your auditors and customers can use.

Frequently asked questions

What are CIS benchmarks?

CIS benchmarks are consensus security configuration guidelines published by the Center for Internet Security for platforms including AWS, Azure, operating systems and Kubernetes. They list specific settings, such as requiring MFA for privileged users and enabling audit logging. They are a strong baseline, though not every item suits every organisation.

Do we need GuardDuty or Defender if we have a firewall?

Yes, they do different jobs. Firewalls and WAFs block traffic at the edge. GuardDuty and Defender analyse logs and behaviour to spot compromised credentials, unusual API calls and malicious activity inside your accounts. Detection catches what prevention missed, provided someone is watching the alerts.

Does following CIS make us SOC 2 or ISO 27001 compliant?

No. CIS controls support many requirements in those frameworks, and automated evidence helps an audit. Certification also covers policies, people, processes and vendor management that no cloud setting can provide. We make the technical controls solid and map them to your framework.

How do you stop security findings becoming noise?

We start with a defined baseline, suppress findings that are accepted with a recorded reason, and route the rest by severity to an owner. We also fix recurring causes at source, in the Terraform modules, so the same finding does not return with every new account.

Should security be built before or after migration?

Before the first workload, and then refined. Retrofitting encryption, logging and access controls onto running production is slower and riskier. The baseline sits in the landing zone, so each migrated workload lands inside it from the beginning.