A Security Baseline for a New AWS Account

Detection must be switched on before an incident, because the services below cannot show you what happened before they were enabled. This is a practical baseline for every new account, small enough to do in an afternoon and strong enough to catch the common problems.

Versions in use on this date. AWS CLI 2.9 and current services. Security Hub supports the AWS Foundational Security Best Practices standard and CIS AWS Foundations benchmark. GuardDuty includes optional S3 and EKS protection plans.

How the pieces fit

flowchart TB
  subgraph ACC[Each AWS account and region]
    CT[CloudTrail<br/>who called which API]
    VPCF[VPC Flow Logs and DNS logs]
    CFG[AWS Config<br/>resource inventory and rules]
    GD[GuardDuty<br/>threat detection]
    AA[IAM Access Analyzer<br/>external access findings]
  end
  CT --> LOGS[(Central log archive account<br/>S3 with object lock, KMS, versioning)]
  GD --> SH[Security Hub<br/>aggregates findings and benchmark checks]
  CFG --> SH
  AA --> SH
  SH --> EB[EventBridge rule on high severity]
  EB --> SNS[SNS topic] --> CHAT[Chat channel and on-call pager]
  EB --> LAM[Lambda auto remediation optional]
  ORG[AWS Organizations<br/>delegated administrator] -.->|enables for all accounts| ACC

What each service gives you

Service	What it gives you	First setting to check
CloudTrail	Record of management API calls; the audit trail	Multi-region trail, log file validation, logs to a separate account
GuardDuty	Threat detection from CloudTrail, VPC flow logs and DNS logs, no agents	Enabled in every region you use, with S3 protection
AWS Config	Inventory of resources and their changes; rules like “S3 buckets must not be public”	Recorder on, with a delivery bucket
IAM Access Analyzer	Finds buckets, roles and keys shared outside your account or organization	Analyzer with organization zone of trust
Security Hub	One dashboard for findings plus benchmark checks	Foundational Best Practices standard enabled

Turn them on

# CloudTrail: multi-region trail with validation, to a bucket in the log archive account
aws cloudtrail create-trail --name org-trail --s3-bucket-name acme-trail-logs \
  --is-multi-region-trail --include-global-service-events --enable-log-file-validation
aws cloudtrail start-logging --name org-trail

# GuardDuty
aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES --region ap-south-1

# IAM Access Analyzer
aws accessanalyzer create-analyzer --analyzer-name account-analyzer --type ACCOUNT --region ap-south-1

# Security Hub with default standards
aws securityhub enable-security-hub --enable-default-standards --region ap-south-1

With AWS Organizations, do this once from a delegated administrator account so new accounts are enrolled automatically (aws organizations enable-aws-service-access --service-principal guardduty.amazonaws.com, then aws guardduty enable-organization-admin-account). The log bucket should live in a dedicated log archive account with a bucket policy that allows only CloudTrail to write and nobody to delete, plus S3 versioning and, for strict needs, Object Lock.

Preventive settings alongside detection

aws s3control put-public-access-block --account-id 111122223333 --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
aws ec2 enable-ebs-encryption-by-default --region ap-south-1
aws iam update-account-password-policy --minimum-password-length 14 --require-symbols --require-numbers \
  --max-password-age 0 --password-reuse-prevention 10

• Root user: strong unique password, hardware or virtual MFA, no access keys, used only for the few tasks that need it; an alias mailbox that several people can read.
• Humans use IAM Identity Center with MFA (previous post), not IAM users with keys.
• Service control policies to deny disabling CloudTrail/GuardDuty/Config, leaving the organization, creating root keys and using unapproved regions.
• Default VPC and its permissive security group: delete them in unused regions or ensure nothing runs there.
• Instance metadata: require IMDSv2 (HttpTokens=required) on new instances.
• Budget alerts with AWS Budgets catch crypto-mining and runaway costs early, and billing alarms are a cheap detector of compromise.

Make findings actionable

A baseline nobody reads is theatre. Route findings with intent:

1. High and critical GuardDuty and Security Hub findings go to the pager through EventBridge and SNS.
2. Medium findings go to a ticket queue with an owner and a weekly review.
3. Suppress known benign findings with documented suppression rules rather than ignoring the dashboard.

Example EventBridge pattern:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [{ "numeric": [">=", 7] }] }
}

Practise one scenario per quarter: “an access key leaked on GitHub.” Walk through finding the key’s activity in CloudTrail, disabling it, checking what it touched, rotating secrets, and writing the timeline. The first rehearsal always shows gaps in logging and ownership.

Costs and limits

CloudTrail’s first management-event trail per region is free; additional trails, data events, Config items, GuardDuty and Security Hub are billed by volume. Start with management events and the services above, then add S3 and Lambda data events or VPC flow logs where the data is sensitive. Use the 30-day free trials on GuardDuty and Security Hub to see the cost on your own usage.