Security Baseline

A Security Baseline is the minimum set of security controls that should be enabled in every AWS account, regardless of workload. It establishes the foundation for defense in depth.

Essential Controls

• CloudTrail: enabled in all regions, multi-account via Organizations trail
• AWS Config: recording all supported resource types
• GuardDuty: threat detection across all accounts
• Security Hub: centralized findings with CIS/NIST benchmarks enabled
• IAM Access Analyzer: detect external access to resources

Account-Level Settings

• Root Account: MFA enabled, no access keys, used only for billing/emergency
• Default EBS Encryption: enabled in every region
• S3 Block Public Access: enabled at the account level
• IMDSv2: enforced as default for all new EC2 instances
• Account-level S3 settings: disable ACLs, enable versioning for critical buckets

Automation

• Deploy via Control Tower guardrails or CloudFormation StackSets
• Use Config Conformance Packs for continuous compliance verification

How It Goes Wrong in Practice

The most common baseline failure is that it exists as a wiki page instead of as code. Someone configures the first three accounts by hand, the checklist gets ticked, and then account number seventeen is created in a hurry for a proof of concept and receives none of it: no GuardDuty, no Config recorder, default settings everywhere. That forgotten account is precisely where an attacker with stolen credentials likes to operate, because nothing is watching. A baseline that is not applied automatically to every new account, on day zero, is a suggestion, not a control. This is exactly what Control Tower guardrails, Account Factory, or your own StackSets pipeline are for.

The second failure is silent drift. Baselines get weakened for good-sounding reasons: S3 Block Public Access is lifted at the account level "temporarily" to publish one static site, a region's default EBS encryption never got enabled because the region came into use later, an engineer pauses the Config recorder during a noisy migration. Each change is small, none is reverted, and a year later the baseline exists mostly in people's memory. The countermeasures are detective and preventive together: Config rules and conformance packs that flag drift continuously, plus SCPs that deny the API calls that disable your security services in the first place.

Third, the regional blind spot. Several baseline settings are per-region (default EBS encryption among them), and detection services must be enabled where you do not run workloads too, because attackers deliberately pick your quiet regions for cryptomining and persistence.

A Practical Check

Two commands verify two of the highest-value account settings. Default EBS encryption, which is evaluated per region:

aws ec2 get-ebs-encryption-by-default

This returns EbsEncryptionByDefault as true or false for the current region, so loop it over every region you use. Then account-level S3 Block Public Access:

aws s3control get-public-access-block --account-id 123456789012

A healthy baseline shows all four flags true: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets. Both commands are read-only, so they are safe to run anywhere, and they pair naturally with aws iam get-account-summary for the root user checks: AccountMFAEnabled should be 1 and AccountAccessKeysPresent should be 0. Script the set across all accounts in the organization and you have the beginnings of a real baseline verification, cheap to run and hard to argue with.

Frequently Asked Questions

Where do I start if I have existing accounts with nothing in place? In order of payoff: protect the root users (MFA, remove access keys), turn on an organization-wide CloudTrail, then enable GuardDuty, Config, and Security Hub across accounts using delegated administration. Only after the detective layer exists do the account settings (Block Public Access, default encryption, IMDSv2 defaults) and preventive SCPs follow. Detection first, because you cannot fix what you cannot see.

Is the baseline account-wide or per region? Both, and the distinction bites. IAM and root protections are global; CloudTrail can be a single all-region trail; but Config recorders, GuardDuty detectors, Security Hub, and default EBS encryption are regional settings that must be present in each region. Baseline automation should therefore iterate regions, not just accounts.

How do I keep the baseline from degrading over time? Make the baseline machine-checkable and the weakening path expensive. Conformance packs and Config rules give continuous verification with findings you can route to owners; SCPs deny the obvious sabotage (stopping the Config recorder, deleting GuardDuty detectors); and every exception gets an expiry date and a ticket, because "temporary" is the most permanent word in cloud security.