DEV Community: Mario

Responding to a Compromised AWS Access Key

Mario — Sun, 14 Jun 2026 22:21:35 +0000

You wake up to this email from AWS:

Irregular Activity Detected for Your AWS Access Key

As part of our standard monitoring of AWS systems, we observed anomalous activity in your AWS account that indicated your AWS access key(s), along with the corresponding secret key, may have been inappropriately accessed by a third party.

Your stomach drops. The email links to a compromised access key: AKIA1234567890ABCDEF. User: app-integration-user. Event: GetCallerIdentity. Time: yesterday at 12:11:58 UTC. IP: 198.51.100.50.

AWS gives you four steps:

Rotate the key.
Check CloudTrail for unwanted activity.
Review account for unexpected usage.
Respond to the support case.

Four steps. Clean. Linear. Assumes everything goes right.

It won't.

What AWS Documentation Assumes

AWS's steps assume:

CloudTrail is already enabled and logs are queryable.
Someone on your team knows how to read CloudTrail.
You have time to investigate without pressure.
The only damage is the exposed key.
Rotating the key is enough to fix it.

In reality:

CloudTrail might not be enabled. Or enabled but logs are in an S3 bucket nobody checks.
The person who set up the account left months ago.
You have 4 hours before customers start calling about errors.
The attacker might have created backdoor credentials, roles, or policies while they were in.
Rotating the key stops them from using that key. But if they left a trail of IAM users, keys, or assumed roles behind, you're still exposed.

What Actually Happened

You look at the details. The compromised key belongs to app-integration-user. A user who was supposed to only send emails via SES. Instead, someone called GetCallerIdentity from IP 198.51.100.50 at 12:11 UTC.

(If the compromised key is your root account's access key: this is a P1 incident. Root cannot be restricted by IAM policies. Rotate immediately, audit all root activity in the last 30+ days, and contact AWS Security right now.)

That one call tells you:

The key was exfiltrated (not guessed in a bruteforce).
The attacker tested it immediately to confirm it works.
They got basic information about your account and role.
The next calls happened after that test.

Now you need to answer: What did they do next?

This is where the 4-step plan breaks down. AWS doesn't tell you how to find that out if your logs aren't ready.

The Three Things That Actually Save You

1. Access to CloudTrail, Even If It's Basic

If CloudTrail is off or inaccessible, you're blind. You can't answer the question: What happened after that GetCallerIdentity call?

If CloudTrail is on:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA1234567890ABCDEF \
  --start-time 2026-05-21T12:00:00Z \
  --end-time 2026-05-21T14:00:00Z \
  --region us-east-1

You'll see every API call made with that key. Not glamorous. Not a dashboard. But it works. And it shows you the sequence: GetCallerIdentity → what came next.

From a typical reconnaissance scenario, that query might show:

GetCallerIdentity (12:11:58)
ListUsers (12:12:05)
ListAccessKeys (12:12:12)
ListRoles (12:12:19)
ListPolicies (12:12:25)
GetUser (12:12:33, targeting 'admin-user')

The attacker was doing reconnaissance. They're mapping your account structure. That tells you what they might do next: assume the admin role, create a backdoor key, or escalate.

Without CloudTrail, you're guessing. With CloudTrail, even basic, you have facts.

2. A Playbook

The four AWS steps are necessary but insufficient. A playbook is what you execute while following those steps, what you execute before the key is fully rotated, and what you execute after you think it's over.

A minimal playbook for a compromised key looks like this:

Immediate (first 30 minutes):

Do NOT delete the exposed key yet. Mark it as inactive. You need it in CloudTrail for the investigation.
Query CloudTrail for all events from that key in the last 30 days (not just the past hour).
Check if that key was used to assume any roles or create temporary credentials. If yes, those STS tokens are in the wild and valid until expiration. Monitor those roles' activity separately.
In parallel: create a new key for the application using that user, update your code/deployment.

Investigation (first 2 hours):

Look for any new IAM users, roles, or policies created in the same timeframe.
Check for any API calls to sensitive services: RDS, Secrets Manager, KMS, S3 policy changes.
Check CloudTrail for any actions after the GetCallerIdentity test that were anomalous (deletes, policy changes, cross-account AssumeRole).
Verify the alternate contact (Billing, Operations, Security) was not modified. An attacker could reroute support tickets or recovery emails.

Containment (2-4 hours):

Once the new key is confirmed working in production, mark the exposed key as inactive in the console.
If the attacker created backdoor credentials or roles, delete them.
If they touched resources, take snapshots or note the state for forensics.

Post-incident (next business day):

Review all other IAM users in the account. Are there other keys that should be rotated? Other users with overprivileged access?
Check S3 bucket policies, security group rules, and VPC peering for unexpected changes.
Enable MFA on all human IAM users and the root account.

A playbook turns panic into a sequence. It answers the question "what do I do first?" before you need the answer.

3. Rotate the Key Without Breaking Your Application

Here's the trap: the application using app-integration-user is running in production right now. It's sending emails, and it's using that exposed key.

If you delete the key immediately, the application fails. Customers' emails don't send. You get paged. You panic. You revert.

If you rotate the key slowly, the application keeps working while the attacker still has access.

The solution is simple: rotate before you block.

Create a new access key for app-integration-user right now.
Update your application to use the new key (redeploy or restart).
Test that the application works with the new key.
Only then mark the exposed key as inactive in the console.

This takes 10 to 15 minutes if you have automation. If you don't, it takes longer. But it works.

The attacker can't use the old key once it's inactive. Your application never stops. You avoid the panic of choosing between security and uptime.

If the key is embedded in a third-party tool or service, contact the vendor right away. Tell them the key is compromised. Ask them to help you rotate it. In parallel, mark the key as inactive in AWS. Once the vendor confirms the new key is working, you're done.

How to Build This Capacity Before You Need It

You don't build incident response by responding to incidents. You build it by preparing for them.

Start with CloudTrail

aws cloudtrail create-trail \
  --name my-organization-trail \
  --s3-bucket-name my-cloudtrail-logs-bucket \
  --region us-east-1

aws cloudtrail start-logging \
  --name my-organization-trail \
  --region us-east-1

CloudTrail has free tier: 1 trail, 90 days of event history in the console. That's not enough for forensics. Older events are archived to S3, which is where you'll do real investigation.

For long-term retention, query CloudTrail logs in S3 using Athena:

SELECT
  useridentity.arn,
  eventname,
  sourceipaddress,
  eventtime
FROM cloudtrail_logs
WHERE eventtime > '2026-05-21'
ORDER BY eventtime DESC
LIMIT 100;

Run this query in the Athena console after you've configured Athena tables on your CloudTrail S3 bucket (AWS CloudTrail documentation has the setup steps).

If you're in an AWS Organization, one trail in the management account logs all accounts. Do that instead of one trail per account.

Write Your Playbook Now

Don't write it during an incident. Write it next Tuesday.

Use the structure above or a template. Share it with your team. Update it when you learn something new. Version control it (GitHub, not a Google Doc).

Test Key Rotation Without Pressure

Pick a test application (or a test user with a limited policy) and rotate its key. How long does it take? Where do you get stuck? Fix those problems now.

If you have 15 applications using access keys, and rotation takes 30 minutes per app, an incident will take you 7.5 hours under pressure. That's a problem.

If you can rotate a key in 5 minutes because you automated it or have a runbook, an incident is 1.25 hours. Still not fun. But survivable.

The Real Problem Isn't Technical

The email from AWS assumes you're ready. The four steps assume you have the foundation.

Most teams don't.

Not because they're careless. Because incident response looks like overhead until the incident happens.

Then it becomes the only thing that matters.

The three things that save you — CloudTrail access, a playbook, and the ability to rotate a key in 15 minutes — aren't expensive. They don't require a SIEM or a SOC or a fancy tool.

They require 4 hours of work before something breaks.

That's the gap AWS doesn't mention.

Detect, Alert, Search: The SIEM You Already Have on AWS

Mario — Sun, 07 Jun 2026 03:27:07 +0000

The question came up in a security assessment. "Do you have a SIEM?"

The honest answer was no. There was no budget for one either. A commercial SIEM meant a license, an ingestion bill that grew with every log source, and someone to run it. None of that was happening this quarter.

But the question behind the question was fair. Can you see what is happening in your AWS accounts? Would you know if a credential was being used from somewhere it should not be? Could you go back and check?

That is what a SIEM is for. And the account already had most of the parts to answer those questions. They just were not connected.

You do not buy a SIEM to get detection and searchable history on AWS. You connect four services you may already be paying for.

If you read the last article, this is the other half of it. The guardrails there kept an attacker from deleting CloudTrail or switching off GuardDuty. Here we use the logs and findings those guardrails protect.

What a SIEM Actually Does

Strip away the marketing and a SIEM does three things that matter here.

It collects signals from many sources and puts them in one format. It alerts you in real time when something important happens. And it keeps history you can search later, when you need to investigate.

Collect, alert, search. That is the job.

What we are not rebuilding is the rest of the brochure: a correlation engine that stitches twenty events into one story, user behavior analytics, prebuilt compliance dashboards, a case management workflow. Those are real features. Most teams asking "do we have a SIEM?" do not need them yet. They need to know when something fires, and be able to look back.

The Architecture

Four services, each doing one job.

GuardDuty is the sensor. It watches CloudTrail, VPC flow logs, and DNS queries, and raises findings when it sees credential abuse, cryptomining, or traffic to known-bad infrastructure. You do not write rules for it. You turn it on.

Security Hub is the part that makes this a SIEM instead of a pile of consoles. It ingests findings from GuardDuty, Inspector, IAM Access Analyzer, Macie, and its own security checks, and normalizes all of them into one schema, the AWS Security Finding Format (ASFF). That normalization is work a SIEM would otherwise charge you for.

EventBridge is the router. Security Hub emits an event every time it imports a finding. A rule decides which of those events are worth waking someone up for.

Lambda is the processor. It reads the finding, pulls out what a human needs, sends it to Slack, and writes the raw record to S3.

GuardDuty ─┐
Inspector ─┤
Config    ─┼─► Security Hub ──► EventBridge ──► Lambda ─┬─► Slack  (real-time alert)
Access    ─┤   normalize        filter by      format   │
Analyzer  ─┘   (ASFF)           severity                └─► S3 ──► Athena  (searchable history)

S3 plus Athena is the half people skip, and it is the half that earns the word SIEM. Security Hub keeps findings for about 90 days. The S3 archive is your real history, and Athena lets you query it with SQL when you need to answer "has this happened before?"

Setting It Up

The order matters. Sensor first, then aggregator, then the pipe.

If GuardDuty or Security Hub is already on in your account, skip ahead. Most of these steps are idempotent. The point is not turning things on, it is connecting what is already running.

Step 1. Turn on GuardDuty. This is the detection sensor. Without it, Security Hub has thin threat signal.

aws guardduty create-detector --enable --region us-east-1

The command returns a detector ID. Save it. You will use it to send test findings later.

Step 2. Enable Security Hub with its default standards. This turns on the aggregator and a baseline set of checks, and it wires GuardDuty findings in automatically.

aws securityhub enable-security-hub --enable-default-standards --region us-east-1

Give it a few hours. Findings do not appear instantly. Security Hub runs its checks and pulls in GuardDuty on its own schedule.

Step 3. Create the archive bucket, with public access blocked and versioning on. This is where the searchable history lives, so it should outlive any single finding.

BUCKET_NAME="your-account-id-siem-findings"

aws s3api create-bucket --bucket "$BUCKET_NAME" --region us-east-1

aws s3api put-public-access-block --bucket "$BUCKET_NAME" \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

aws s3api put-bucket-versioning --bucket "$BUCKET_NAME" \
  --versioning-configuration Status=Enabled

Step 4. Wire the EventBridge rule. The piece that decides what is worth an alert is the event pattern. This is the one to get right.

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "Workflow": { "Status": ["NEW"] },
      "RecordState": ["ACTIVE"]
    }
  }
}

Read it from the inside out. RecordState ACTIVE ignores findings Security Hub has already archived. Workflow.Status NEW skips anything someone has already triaged or suppressed. Severity.Label HIGH and CRITICAL is the filter that keeps this from becoming noise on day one. Inside an attribute the values are OR, across attributes they are AND. So this matches a new, active, high-or-critical finding, and nothing else.

That last filter is a decision, not a default. Start narrow.

The Lambda

The function does the unglamorous work. Turn a finding into a message a person can act on, and keep a copy.

import json, os, urllib.request
import boto3

s3      = boto3.client("s3")
secrets = boto3.client("secretsmanager")

BUCKET  = os.environ["ARCHIVE_BUCKET"]
WEBHOOK = secrets.get_secret_value(
    SecretId=os.environ["WEBHOOK_SECRET_ARN"])["SecretString"]


def handler(event, _context):
    for finding in event["detail"]["findings"]:
        archive(finding)
        notify(finding)
    return {"statusCode": 200, "body": f"Processed {len(event['detail']['findings'])} findings"}


def archive(finding):
    fid = finding["Id"].rsplit("/", 1)[-1]
    key = f"findings/{finding['CreatedAt'][:10]}/{finding['AwsAccountId']}/{fid}.json"
    s3.put_object(Bucket=BUCKET, Key=key, Body=json.dumps(finding).encode())


def notify(finding):
    text = (f":rotating_light: *{finding['Severity']['Label']}*  "
            f"{finding['Title']}\n"
            f"account `{finding['AwsAccountId']}`  region `{finding['Region']}`")
    req = urllib.request.Request(
        WEBHOOK,
        data=json.dumps({"text": text}).encode(),
        headers={"Content-Type": "application/json"})
    urllib.request.urlopen(req, timeout=5)

A few decisions worth calling out. One EventBridge event can carry several findings, so the handler loops, it does not assume one. The function returns a clean response so failures are explicit. If the Lambda throws, EventBridge retries twice by default (configurable up to 185 retries with exponential backoff on the rule's retry policy). That means a transient Slack outage will not lose findings permanently. The S3 key is built from the finding date, account, and ID, so a redelivery of the same finding overwrites instead of duplicating. The webhook URL is not in the code. It comes from Secrets Manager, because a webhook in source control is a credential leak waiting to happen. And the function uses urllib from the standard library, not requests, so there is nothing to package. It deploys as a single file.

The full version, with the IAM role scoped to one bucket prefix and the EventBridge wiring, is in the repo. Link is at the end.

Querying the Archive with Athena

Once findings land in S3, Athena turns the bucket into a searchable database. Create the table once:

CREATE EXTERNAL TABLE siem_findings (
  Id             STRING,
  AwsAccountId   STRING,
  Region         STRING,
  Title          STRING,
  Description    STRING,
  CreatedAt      STRING,
  Severity       STRUCT<Label:STRING, Normalized:INT>,
  Workflow       STRUCT<Status:STRING>,
  ProductName    STRING,
  Resources      ARRAY<STRUCT<Type:STRING, Id:STRING, Region:STRING>>
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://your-account-id-siem-findings/findings/'
;

Then query as needed. Example — all critical findings in the last 30 days:

SELECT CreatedAt, Title, AwsAccountId, Region
FROM siem_findings
WHERE Severity.Label = 'CRITICAL'
  AND CreatedAt > date_format(current_date - interval '30' day, '%Y-%m-%d')
ORDER BY CreatedAt DESC;

This is the piece that earns the word SIEM. Not a live dashboard, but on-demand investigation when an incident requires context.

The Findings I Route First

Turning on every finding at once is how a SIEM becomes a channel everyone mutes. Start with the ones that usually mean someone is already inside.

From GuardDuty: UnauthorizedAccess on IAM credentials, CryptoCurrency activity, Backdoor and Trojan types, and any use of the root account. From Security Hub's own checks: root account in use, S3 buckets open to the public, console users without MFA, security groups open to 0.0.0.0/0 on admin ports.

That is a short list on purpose. You widen the EventBridge pattern later, by adding MEDIUM to the severity filter, once you trust the signal and have somewhere to put it. Widening is a one-line change. Earning back a team's attention after you have flooded them is not.

What This Is Not

This is honest detection and searchable history. It is not an enterprise SIEM, and pretending otherwise will get someone hurt.

It does not correlate. It routes one finding at a time. It will not connect a failed login, a new access key, and a data transfer into a single story. AWS has a reference pattern for that with EventBridge, Lambda, and DynamoDB, but that is a build, not a checkbox.

Athena is query on demand, not a live dashboard. You write SQL when you investigate. If you want charts, that is QuickSight, and QuickSight costs.

It is single account as written. Multi-account means setting up Security Hub and GuardDuty with a delegated administrator and aggregating findings into one account. Same pattern, more setup.

And "without buying anything" means no third-party license and no new product. It does not mean free. Security Hub bills per finding ingested and per check, GuardDuty bills on the events and volume it analyzes, Athena bills per terabyte scanned. For a small to mid AWS footprint this lands in the tens of dollars a month. A commercial SIEM for the same footprint starts in the thousands. That gap is the whole point.

To put numbers on it: a small account generating 100 findings per day and running 200 security checks hits roughly $4/month for Security Hub ($0.00003/finding + $0.0010/check), $10–15/month for GuardDuty (CloudTrail and VPC flow analysis on modest traffic), and pennies for Athena queries against a few gigabytes in S3. Call it $15–25/month total. A commercial SIEM ingesting the same data starts at $1,000/month before you count the engineer running it.

When This Is Enough, and When It Is Not

It is enough when you have a small to mid AWS footprint, you need to know when something fires, you need to be able to look back, and no auditor is requiring a specific named product.

It is not enough when a compliance framework names a SIEM you have to use, when you need to correlate AWS with on-prem or another cloud, when you need monitored response around the clock, or when your finding volume is high enough to need real tuning and a team to do it.

"We don't have a SIEM" and "we have no visibility" are two different problems. Only one of them needs a budget.

Detection is the easy half. The next article is the hard half: what happens after the alert fires, when the incident response playbook assumes a team, centralized logs, and time you do not have.

Open Security Hub in your account right now. If there are findings sitting there with no one watching, you already have the signal. The only missing piece is the wire.

The deployable template, the Lambda, and a test script that fires a sample finding through the whole pipeline are in a companion repo: https://github.com/Kiruma/aws-lightweight-siem

Tags: AWS, Cloud Security, Security Hub, GuardDuty, SIEM

A Starting Point for AWS Service Control Policies

Mario — Sat, 30 May 2026 21:12:34 +0000

A team opens an AWS account. They deploy everything in us-east-1. Reasonable choice.

Six months later, their AWS bill has EC2 instances running in ap-southeast-1.

Nobody on the team worked in that region. Nobody authorized those instances. They weren't in any Terraform state. They didn't appear in any monitoring dashboard because GuardDuty wasn't enabled there.

A credential had been compromised three weeks earlier. The attacker scanned the account, saw that monitoring was concentrated in us-east-1, and picked a region where nobody was watching. They ran there quietly for weeks.

That's the case that made me take SCPs seriously.

Not a compliance requirement. Not a Well-Architected checklist item. A bill with instances nobody recognized, in a region nobody was watching.

What SCPs Actually Do

AWS Organizations lets you attach Service Control Policies to an organizational unit. An SCP sets a permission ceiling. It defines the maximum permissions any account in that OU can use, regardless of what IAM says.

If your IAM policy allows an action and your SCP denies it, the action is denied. SCP wins.

That's the leverage. One policy, attached at the OU level, governs every account underneath it, including accounts that don't exist yet.

A Practical OU Structure

Before you write a single SCP, you need a structure to attach it to.

The simplest model that works in practice:

Root
├── Security       (audit account, log archive)
├── Infrastructure (shared services, networking)
├── Workloads
│   ├── Production
│   ├── Staging
│   └── Development
└── Sandbox

Each OU gets its own SCPs. Production gets the strictest. Sandbox gets the most relaxed. Development sits in the middle, with enough freedom to build but without the blast radius of production.

In practice, many organizations end up with a different shape. One OU per project, or one per business unit. Both work. The structure matters less than the rule: accounts that share the same security requirements belong in the same OU.

One mistake I see repeatedly is applying everything at Root. Root-level SCPs apply to every member account, including your security account, your audit account, your billing tools. One important exception: SCPs never apply to the management account, regardless of what you attach at Root. Apply at Root only what must be true everywhere without exception. Everything else belongs at the OU level.

SCP Examples Worth Considering

Quick note before the code: these are examples, not a definitive list. Your environment will be different. You may need fewer of these, more of them, or completely different ones. Take what's useful and leave the rest.

One more thing about the format. Each block below is a single SCP statement, not a complete policy. To use one, drop it into the Statement array of a policy document:

{
  "Version": "2012-10-17",
  "Statement": [ /* one or more of the statements below */ ]
}

You can combine several statements into one SCP, as long as the whole policy stays under the 5,120-character limit.

Example: Deny Non-Approved Regions

AWS accounts have multiple regions enabled by default. Most teams use two or three. The rest are attack surface with no monitoring.

When a credential is compromised, attackers look for regions where GuardDuty isn't enabled and where no one is watching CloudTrail. This SCP closes that gap by denying API calls to regions outside your approved list.

{
  "Sid": "DenyNonApprovedRegions",
  "Effect": "Deny",
  "NotAction": [
    "iam:*",
    "sts:*",
    "route53:*",
    "cloudfront:*",
    "budgets:*",
    "ce:*",
    "support:*",
    "organizations:*",
    "account:*",
    "waf:*",
    "globalaccelerator:*",
    "health:*"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": [
        "us-east-1",
        "us-west-2"
      ]
    }
  }
}

Use NotAction, not Action: *. Services like IAM, STS, Route53, and CloudFront are global, not regional. If you use Action: *, you break them. This is the most common mistake when teams write this SCP for the first time.

The NotAction list above is simplified for readability. The official AWS reference list is much longer and includes services like config:*, kms:*, sso:*, and wafv2:*. Before applying this in production, compare against the AWS Control Tower region deny policy to avoid blocking legitimate cross-region operations.

Adjust the approved region list to match where your workloads actually run.

Apply this to a sandbox OU first. As written, it can also block your IaC deployment role and AWS service-linked operations across regions, so watch CloudTrail for AccessDenied before promoting it to production.

Example: Deny Large Instance Types

This looks like a cost control. It's also a security control.

When an attacker compromises credentials, they launch GPU instances for cryptomining. The financial damage from a credential leak drops significantly when the largest instance they can run is an m5.xlarge. This SCP limits the impact of a compromised credential, not just the bill.

{
  "Sid": "DenyLargeInstances",
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "StringNotLike": {
      "ec2:InstanceType": [
        "t3.*",
        "t2.*",
        "m5.large",
        "m5.xlarge",
        "m5.2xlarge",
        "c5.large",
        "c5.xlarge"
      ]
    }
  }
}

Adjust the allowed list to match your actual workload needs. If your production workloads require larger instances, add them explicitly. The goal is to make the approved list specific enough that anything outside it stands out.

Example: Deny Disabling Security Services

This is the one that stops attackers from going dark after they get in.

Standard post-compromise playbook: gain access, disable GuardDuty, delete CloudTrail, operate without detection. This SCP breaks that sequence. Even with AdministratorAccess in IAM, the attacker cannot disable these services. SCP overrides IAM.

{
  "Sid": "DenyDisableSecurityServices",
  "Effect": "Deny",
  "Action": [
    "guardduty:DeleteDetector",
    "guardduty:DisassociateFromAdministratorAccount",
    "guardduty:StopMonitoringMembers",
    "guardduty:UpdateDetector",
    "securityhub:DeleteHub",
    "securityhub:DisableSecurityHub",
    "securityhub:DisassociateFromAdministratorAccount",
    "cloudtrail:DeleteTrail",
    "cloudtrail:StopLogging",
    "cloudtrail:UpdateTrail",
    "config:DeleteConfigurationRecorder",
    "config:StopConfigurationRecorder",
    "config:DeleteConfigRule",
    "access-analyzer:DeleteAnalyzer"
  ],
  "Resource": "*"
}

If you use SNS for security alerting, add cloudwatch:DisableAlarmActions and sns:DeleteTopic. An attacker who can't disable the detector can still silence the alarm.

One caveat on guardduty:UpdateDetector. It blocks every update to the detector, not just the ones that weaken it, so changing finding-publishing frequency or enabling a new feature goes through the same deny. If that friction bothers your team, scope it with a condition instead of denying the action outright.

Example: Deny Disabling Logging

Logs are forensic evidence. An attacker who can't turn off detection services will try to erase the trail instead.

{
  "Sid": "DenyDisableLogging",
  "Effect": "Deny",
  "Action": [
    "cloudtrail:DeleteTrail",
    "cloudtrail:StopLogging",
    "logs:DeleteLogGroup",
    "logs:DeleteLogStream",
    "logs:DeleteRetentionPolicy",
    "ec2:DeleteFlowLogs",
    "wafv2:DeleteLoggingConfiguration"
  ],
  "Resource": "*"
}

You'll notice cloudtrail:DeleteTrail and cloudtrail:StopLogging appear here and in the previous example. That overlap is fine. If you apply both statements, the duplication costs nothing. If you'd rather keep one source of truth, drop them from whichever statement you apply second.

One operational note: logs:DeleteLogGroup will block developers from cleaning up log groups in test environments. Apply this SCP to production and staging OUs only. For development, use a CloudWatch Logs retention policy instead of blocking deletion entirely.

For RDS and ELB logging, SCPs are a poor fit. The actions that control their logging configuration are too broad and block legitimate operations. A more reliable approach is AWS Config rules with automatic remediation: if logging gets disabled, Config detects it and re-enables it. Same result, less friction.

What Control Tower Actually Covers

If you're on AWS Control Tower, it's worth reading the actual SCP content before assuming you're protected.

CloudTrail: Control Tower's mandatory SCP for CloudTrail targets this resource:

"Resource": ["arn:aws:cloudtrail:*:*:trail/aws-controltower-*"]

It only protects trails named aws-controltower-*. Any trail you create yourself is not covered. And if you're on Landing Zone 4.0 or above, this SCP was removed entirely. AWS deprecated it when Control Tower moved away from account-level trails.

AWS Config: This one is different. The mandatory Config SCP uses "Resource": ["*"], so it does protect your Config setup broadly, not just Control Tower's.

GuardDuty and Security Hub: No mandatory preventive guardrail by default. There are elective options, but you have to enable them explicitly per OU.

The practical check: open your Organizations console, read the SCP attached to your OU, and look at the Resource field. If it's scoped to aws-controltower-* resources, it's not protecting yours.

When SCPs Are Not Enough

SCPs are preventive controls. They stop things from happening.

They don't tell you what happened before you put them in place. They don't detect misconfigurations that already exist. They don't replace monitoring.

The full picture: SCPs for prevention, AWS Config for drift detection, GuardDuty and Security Hub for threat detection, CloudTrail with a centralized destination for forensics.

SCPs are the foundation. Not the ceiling.

If you're implementing these for the first time, start with the region restriction and the security services protection. Those two give you the most immediate security return. Instance types and logging have more operational nuance and will need adjustment for your workloads.

Start there. Tune as you go.

Prevention is the first layer. The next one is seeing what's happening inside the accounts you just put a ceiling on. In the next article I'll build a lightweight SIEM on AWS without buying anything, using the logs these guardrails keep an attacker from deleting.

Tags: AWS, Cloud Security, IAM, Cloud Governance, DevSecOps

IAM Misconfiguration: Why It Keeps Happening and How to Start Fixing It

Mario — Sat, 23 May 2026 22:06:56 +0000

The Most Common Pattern I See

Across the AWS environments I've reviewed — financial services, retail, healthcare, telecom — there is one pattern that shows up almost everywhere.

It is not a sophisticated attack vector.
It is not a zero-day vulnerability.
It is IAM.

Specifically, it is IAM configured the way it was configured three years ago, by someone who no longer works there, using a tutorial that was written for a single-account startup.

The most frequent findings:

IAM Users with long-lived access keys attached to production workloads
Admin roles without permission boundaries or conditions
No SCPs enforced at the organization level — because there is no organization level
Root account used regularly, sometimes for daily operations
Access keys that have not been rotated in over 400 days

None of this is surprising.
All of it is fixable.
But first, you need to understand why it happens.

Why This Is Not a Skill Problem

When I point out these findings to the teams responsible, the reaction is almost always the same.

They know.

They are not unaware that long-lived access keys are a risk. They have read the AWS documentation. They have seen the warnings in Security Hub. In some cases, they have even flagged it internally, written a ticket, added it to a backlog.

The problem is not knowledge. The problem is context.

AWS documentation, AWS Well-Architected Framework, AWS Security Best Practices — all of it was written assuming a certain baseline:

A dedicated security team.
A mature cloud governance process.
An organization that started with multi-account in mind.
Budget for tooling beyond what comes free with the account.

For most organizations, the reality looks different.

They entered AWS through a single team that needed to ship something fast. IAM was configured to make that happen. There was no time to design a permission model, no security architect on the team, and no organizational structure to enforce standards later.

That is not negligence. That is how cloud adoption actually happens.

Where to Start Without Rewriting Everything

The worst advice I can give someone in this situation is "start over."

Tearing down IAM and rebuilding it properly sounds good in a blog post. In reality, it means production risk, migration work, and political capital you probably do not have.

Here is what I actually recommend as a starting point — a sequence that reduces risk without requiring a full redesign:

Step 1: Stop the bleeding.
Identify every IAM User with an access key that has not been rotated in 90+ days. Rotate or deactivate them. This takes a few hours and removes a real risk immediately.

aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
  awk -F',' 'NR>1 && $9 != "N/A" { print $1, $9 }'

Step 2: Tag everything you touch.
Before changing any role or policy, add tags. This is how you build the visibility you need to understand what you have before you change it.

Step 3: Enable the basics in Security Hub.
Turn on AWS Foundational Security Best Practices standard. Let it run for a week. Do not try to fix everything — use the findings to build your backlog in priority order.

Step 4: No new IAM Users.
Draw a line. From today, every new workload that needs AWS access gets a role, not a user. Not because roles are perfect, but because the habit of using roles changes how your team thinks about identity.

None of this requires a project. None of it requires approval from three stakeholders.
It requires a decision to start.

What This Problem Is Actually Telling You

IAM misconfiguration is not a technical problem with a technical solution.

It is a signal.

It tells you that cloud adoption happened faster than governance frameworks could follow. It tells you that security was positioned as a blocker rather than an enabler. It tells you that most teams building on AWS have been doing so without the baseline the documentation assumes they already have.

That is the real gap — not skill, not intention. Baseline.

The good news: you do not need a transformation program to close it.
You need a decision, a starting point, and consistency over time.

This article is part of that starting point.

What's Next

In the next article, I will go deeper into the governance layer that prevents these problems from appearing in the first place: AWS Service Control Policies, and how I use them to enforce security guardrails across environments in nine countries.

If you are managing AWS accounts across multiple clients or countries, that one is for you.

[Tags: AWS, IAM, Cloud Security, AWS Security, Cloud Governance, DevSecOps]