Cloud Security

Cloud Security

Cloud breaches are rarely clever. They are a public bucket, an over-permissive role, a database on an open security group, and no audit log to reconstruct what happened. This skill covers cloud posture specifically: the configuration of identity, network exposure, encryption, detection coverage, and multi-account guardrails across AWS, Azure, and GCP.

Scope boundary. This skill is deliberately narrow so it does not overlap its neighbours in engineering/. It does not cover application-code vulnerabilities, dependency CVEs, or compliance-framework mapping — that is senior-secops. It does not cover log analysis and intrusion signals — that is threat-detection. It does not cover offensive engagement planning or rules of engagement — that is red-team. It does not cover prompt injection, model extraction, or ML-pipeline threats — that is ai-security. What lives here is the posture of the cloud control plane itself: who can do what, what is reachable, what is encrypted, and what is logged.

When to use this skill

• A cloud account or subscription is about to hold production customer data for the first time
• An IAM sprawl problem has accumulated and nobody knows which roles are actually admin
• A posture scanner produced hundreds of findings and the team needs a defensible priority order
• A new landing zone or multi-account structure is being designed
• A security questionnaire, SOC 2 audit, or customer due-diligence review asks for cloud evidence
• An incident occurred and the review needs to establish what the exposure was and whether logs exist to prove it

Inputs the skill expects

• An exported resource inventory per account, covering every region (see assets/inventory_export_guide.md)
• An IAM principal export with policy statements, trust policies, and last-used data
• Account/subscription/project settings: audit logging, managed detection, org guardrails, log-archive isolation
• Data classification per store — which resources hold confidential, PCI, PHI, or restricted data
• The organization's account topology and which accounts are production
• The decision the review feeds: launch approval, audit evidence, or remediation backlog

Clarify First

Before running the review, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Which accounts hold production or classified data — decides review scope and which findings are launch-blocking rather than backlog
• Data classification of the stores in scope — promotes unencrypted and un-logged findings from high to critical; without it every severity is a guess
• Whether the exports cover all regions — a region-scoped export reliably misses the forgotten test database that becomes the incident
• What the output feeds — a launch gate, an audit evidence pack, or a backlog; changes severity strictness and report format

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Workflows

Workflow 1 — Audit posture across an account

1. Export the resource inventory for every region, normalizing to the schema in assets/inventory_export_guide.md. Include account-level settings.
2. Populate tags.data_classification on data stores before scanning — severity depends on it, and an unclassified store defaults to the lower band.
3. Run the auditor, reading critical findings before the score.
4. For each critical, answer explicitly: is it reachable from the internet right now, and what data sits behind it.
5. Group findings into classes and name the preventive guardrail for each class rather than ticketing every instance.

python3 engineering/cloud-security/scripts/posture_auditor.py \
  --input engineering/cloud-security/assets/sample_inventory.json \
  --min-severity high --fail-on critical

Workflow 2 — Review IAM for least privilege and escalation paths

1. Export principals with their policy statements, trust policies, MFA state, and last-used data. Populate trust.approved with your own account IDs.
2. Run the review and read the escalation paths first — they convert a mid-privilege identity into an admin and outrank raw wildcard counts.
3. Work the principal risk ranking top-down; for each high-tier principal, derive the replacement policy from 90 days of actual usage, never from what the owning team believes it needs.
4. Disable stale principals for one cycle before deleting, so breakage surfaces as a report rather than an outage.

python3 engineering/cloud-security/scripts/iam_least_privilege.py \
  --input engineering/cloud-security/assets/sample_iam_export.json \
  --stale-days 90 --min-severity high --fail-on critical

Workflow 3 — Convert findings into landing-zone guardrails

1. Run both tools with --format json and count findings by class, not by instance.
2. For any class appearing three or more times, stop remediating instances and write the preventive control from references/landing-zone-and-guardrails.md §3.
3. Apply each guardrail to the Dev OU for two weeks before production, with a documented exception path and an owner.
4. Re-scan at 30 days and report the delta, not the absolute count — absolute counts move with inventory growth and demoralize the team.

python3 engineering/cloud-security/scripts/posture_auditor.py \
  --input engineering/cloud-security/assets/sample_inventory.json \
  --format json > /tmp/posture.json

python3 engineering/cloud-security/scripts/iam_least_privilege.py \
  --input engineering/cloud-security/assets/sample_iam_export.json \
  --format json > /tmp/iam.json

Decision frameworks

Severity calibration

Gate on critical count, never on the aggregate score. Ten lows can drag a score below a threshold while one public database sits unremarked.

Where to spend the next two weeks

Preventive beats detective

Anti-Patterns

Ranking findings by wildcard count

Mistake: The IAM review sorts by how many * characters appear in each policy, and the team spends a quarter tightening s3:* grants on single buckets. Why it happens: Wildcards are trivially greppable, so they become the metric, and tightening them produces a satisfying downward chart. Instead: Hunt privilege-escalation paths first. A tidy-looking policy with 40 scoped actions that happens to include iam:PassRole plus ec2:RunInstances is full account takeover; a sloppy s3:* on one non-sensitive bucket is not. iam_least_privilege.py reports escalation paths as critical for exactly this reason.

Treating the posture score as the gate

Mistake: The release check is "posture score above 80," so the team closes twenty low-severity tag findings to clear the bar. Why it happens: A single number is easy to put on a dashboard and easy to trend, and the low findings are genuinely the cheapest to close. Instead: Gate on critical count and on the specific finding classes that map to data exposure. Use the score only to trend across reviews of the same scope. The sample inventory here scores 0/100, and the number that matters is that five criticals include a publicly readable bucket of customer exports.

Remediating instances instead of writing the guardrail

Mistake: Each scan finds new public buckets; each one gets a ticket, gets fixed, and reappears next quarter from a different team. Why it happens: Ticketing an instance takes ten minutes and closing it feels like progress; writing an org policy requires a conversation with every team that might be blocked by it. Instead: The third time a finding class appears, stop remediating and write the preventive control. Public buckets found three times means account-level public access prevention is missing. Apply it to Dev for two weeks with a named exception path, then production.

Leaving the log archive inside the workload account

Mistake: CloudTrail or the diagnostic settings write to a bucket in the same account they monitor. Why it happens: It is the default when you enable logging from the console, and the separation looks like bureaucratic account sprawl. Instead: Put the log archive in a dedicated account with no workload administrators and write-only access from everywhere else. The entire value of audit logging is that it survives the compromise of the thing it audits — an attacker with account admin deletes in-account logs as step two, and your incident timeline starts and ends with "we do not know."

Scanning one region

Mistake: The export script runs against the default region and reports a clean account. Why it happens: Every provider CLI defaults to a single region, and the code that loops over regions is one more thing to write. Instead: Enumerate regions and export all of them, then apply a region-restriction guardrail so the surface stops growing. The forgotten test database in an unused region — unencrypted, unlogged, open to 0.0.0.0/0 because it was "just for a demo" — is the single most common origin of cloud incidents in organizations that otherwise scan diligently.

Files