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