Turn on the audit trail everywhere, detect risky changes and threats, and set organization-wide guardrails that make whole classes of mistake impossible. The last line: know what happened and prevent the worst by policy.
The cloud audit log (CloudTrail, Azure Activity Log, GCP Audit Logs) records every API call: who did what, when, from where. Without it, you cannot investigate an incident or even prove one happened. Enable it in all regions, protect the logs from deletion or modification (log file validation, a locked archive account), so an attacker cannot cover their tracks.
# an org-wide, all-region, tamper-evident trail
aws cloudtrail create-trail --name org-trail \
--s3-bucket-name org-audit-logs \
--is-organization-trail --is-multi-region-trail \
--enable-log-file-validation # detect tampering
# harden the log destination:
# - separate, locked-down "log archive" account nobody logs into
# - S3 Object Lock / retention so logs can't be deleted, even by admins
# - the log bucket is NOT public (audit this specifically!)
# an attacker's first move is often to disable logging — alert on that (next).Logs are only useful if something watches them. Alert on high-signal events — root account usage, IAM policy changes, disabling of logging or encryption, security-group opens — and layer on a managed threat-detection service (GuardDuty, Defender) that spots credential misuse and known-bad behavior. This is detection engineering (Threat Detection course) applied to the cloud control plane.
# alert the instant someone weakens the account (EventBridge rule)
{
"source": ["aws.cloudtrail"],
"detail": {
"eventName": [
"StopLogging", "DeleteTrail", // hiding tracks
"PutBucketPublicAccessBlock", // exposing data
"AuthorizeSecurityGroupIngress", // opening the network
"CreateAccessKey", "AttachUserPolicy" // privilege changes
]
}
}
// route -> SNS/Slack + your SIEM. Plus enable managed detection:
// aws guardduty create-detector --enable (finds cred misuse, crypto-mining,
// recon, exfiltration patterns from the logs automatically)Detection tells you after the fact; guardrails prevent whole categories of mistake up front. Organization policies (AWS Service Control Policies, Azure Policy, GCP Org Policy) apply account-wide limits that even an account admin cannot override — deny public buckets, restrict regions, require encryption. This is the strongest control because it removes the ability to be insecure rather than relying on everyone getting it right.
// Service Control Policy: no one in the org can disable CloudTrail
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyDisablingAuditLog",
"Effect": "Deny",
"Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail"],
"Resource": "*"
}]
}
// even a full account admin gets AccessDenied. Common guardrails:
// deny making S3 buckets public, deny unencrypted volume creation,
// restrict to approved regions, deny root access-key creation.
// This is prevention by policy — the highest-leverage cloud control.When detection fires, you need a rehearsed cloud response. The moves are cloud-specific: isolate the resource (restrict its security group), revoke the compromised identity's sessions, snapshot for forensics, then rotate and remediate. Pre-write these runbooks — the DFIR course covers the full incident process; here it is the cloud-native containment playbook.
Runbook: "an access key is being used maliciously"
1. CONTAIN deactivate the key + attach a Deny-all policy to the
principal; revoke active sessions (aws iam ... / STS).
2. PRESERVE snapshot affected volumes; export the relevant CloudTrail
events BEFORE anything is cleaned up (chain of custody).
3. ERADICATE rotate the credential, find how it leaked (git? logs?),
fix that source.
4. RECOVER restore from known-good, re-enable access with least priv.
5. LEARN blameless review -> add a guardrail so it can't recur.
Rehearse it (game day) before you need it. See the DFIR course for depth.