The Detection of Baseline Deviation control is all about keeping a watchful eye on your cloud environment. It's like having a trusty guard dog that barks whenever something looks out of place. The goal is to catch any changes that stray from your carefully crafted baseline and sound the alarm before things get hairy.
Where did this come from?
CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full matrix from https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4 to learn more. This control fits nicely with the AWS Config service which continuously monitors and records your AWS resource configurations (https://aws.amazon.com/config/).
Who should care?
- Cloud security engineers responsible for maintaining a secure baseline environment
- DevOps teams who need to be aware of unauthorized changes that could break things
- Compliance officers checking that actual configs match approved standards
What is the risk?
Undetected configuration drift is like a stealthy villain that can open up security holes you never even knew about. Maybe someone accidentally opened up network access or spun up an unpatched server. Catching deviations quickly reduces the time bad guys have to find and exploit vulnerabilities. It also prevents "configuration sprawl" that becomes a tangled mess over time.
What's the care factor?
For most orgs, detecting baseline deviations should be a top priority. It's one of those fundamental security practices that everything else relies on. Letting configurations drift is like leaving your house unlocked - it's an open invitation for trouble. The more frequently you check for drift, the less you'll have to worry about.
When is it relevant?
This control makes sense for any system or environment where you've gone through the work of establishing a secure baseline. That could be hardening operating systems, defining network rules, validating AMIs, etc. It's less relevant for dev/test environments with looser change control. But in production, drift detection is a must-have.
What are the trade offs?
The biggest cost is defining your baseline in the first place. It takes time to translate security standards into technical configurations. You'll also spend time investigating alerts and remediating drift. More frequent checks mean more overhead. But it's cheaper than cleaning up after a breach. Some alerting noise is worth the peace of mind.
How to make it happen?
- Define your baseline config standards (CIS benchmarks are a good start)
- Codify configs as AWS Config rules, CloudFormation templates, Terraform, etc.
- Enable AWS Config in all regions, set it to record all resource types
- Use Config managed rules or custom Config rules to check for compliant configs
- Send Config notifications to an SNS topic anytime a violation is detected
- Pipe SNS messages to a response system like Lambda or OpenSearch
- Trigger auto-remediation functions and/or manual review processes
What are some gotchas?
AWS Config needs write access to an S3 bucket and publish access to SNS topics. The IAM role will need config:* permissions (https://docs.aws.amazon.com/config/latest/developerguide/iamrole-permissions.html). Also, rules only evaluate changes after Config is enabled, so take a snapshot of existing resources too. Some changes like security group edits can be chatty, so be smart about alert filtering.
What are the alternatives?
Open source tools like Cloud Custodian can check cloud environments against policy rules. It's more hands-on but also more flexible than native guard rails. Commercial CSPM platforms often include robust drift detection too. But for quick no-cost wins, taking advantage of built-in AWS Config rules is the way to go.
Explore further
- CIS Benchmark for CIS AWS Foundations v1.5.0 - Config rules for fundamental security
- AWS Config Managed Rules - The built-in policy checks offered by AWS Config
- AWS blog on managing configuration deviation - In-depth guidance from the AWS team
