Cloud Security

# Create a "Cloud Security" AI Skill

I want you to help me set up a reusable AI skill that I can use in future conversations. Read the complete skill definition below, then help me install it.

## Complete Skill Definition

# 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.

```bash
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.

```bash
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.

```bash
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

| Severity | Definition | Examples |
|----------|------------|----------|
| **Critical** | Direct path to data exposure or account takeover, exploitable now | Public store holding classified data; admin port open to the internet; `*:*` on `*`; wildcard role trust; control-plane audit logging off |
| **High** | Significant weakening, exploitable with one further step | Service-wide wildcard grant; unencrypted classified store; no backups on a primary store; log archive not isolated; human without MFA |
| **Medium** | Defence-in-depth or detection gap | Data-plane access logs off; no permission boundary on a privileged principal; provider-managed keys on classified data |
| **Low** | Governance hygiene | Missing owner or classification tags |

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

| Current state | Highest-return move | Why |
|---------------|--------------------|-----|
| No org-wide audit logging | [PROVEN] Enable it to a separate account first | Nothing else is provable without it; an attacker in the workload account can otherwise erase the evidence |
| Audit logging present, no guardrails | [PROVEN] Deploy the four day-one denies: public storage, log tampering, detection tampering, region restriction | Each one permanently deletes a finding class instead of a finding |
| Guardrails present, static keys everywhere | [RECOMMENDED] Migrate to workload identity federation | Static keys are the most commonly leaked credential and the hardest to rotate under pressure |
| Everything above done | [RECOMMENDED] Data-plane logging on classified stores | Decides whether a breach notification names 12 records or assumes all four million |
| Mature posture | [EXPERIMENTAL] Just-in-time privilege elevation | Removes standing admin entirely; risk is that a broken elevation path blocks incident response, so keep an audited break-glass role |

### Preventive beats detective

| Layer | Latency to protection | Use for |
|-------|-----------------------|---------|
| Preventive (SCP / org policy / deny assignment) | Instant, always | Any finding class seen three or more times |
| Proactive (policy-as-code in CI on the IaC plan) | Minutes | Everything expressible in Terraform, before merge |
| Detective (this skill's scanners, managed detection) | Hours to days | Backstop for console changes and drift |
| Responsive (auto-remediation) | Minutes to hours | Only where the preventive control would be too blunt |

## 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

| File | Purpose |
|------|---------|
| `scripts/posture_auditor.py` | Audits a normalized cloud inventory for public exposure, open ingress, unencrypted stores, missing logging, absent backups, and account guardrail gaps; severity-scored with provider-specific remediation |
| `scripts/iam_least_privilege.py` | Reviews IAM principals for wildcard grants, privilege-escalation paths, over-broad trust, stale credentials, and missing MFA; ranks principals by risk with an effective-privilege tier |
| `scripts/posture_rules.py` | Rule data behind the posture auditor — severity weights, sensitive-port and data-store vocabularies, account-level guardrail checks, and the provider-specific remediation catalog; `--list-rules` prints them |
| `scripts/iam_rules.py` | Rule data behind the IAM review — severity weights, admin-grant and write-verb vocabularies, the privilege-escalation path catalog, and the policy-flattening and privilege-tier primitives; `--list-rules` prints them |
| `references/cloud-control-catalog.md` | Controls mapped across AWS/Azure/GCP for identity, network, encryption, logging, and resilience, with passing thresholds and severity calibration |
| `references/landing-zone-and-guardrails.md` | Account topology, preventive vs detective controls, the guardrail baseline per provider, and a five-level posture maturity model |
| `assets/sample_inventory.json` | Seven-resource AWS inventory exercising every posture check |
| `assets/sample_iam_export.json` | Six-principal IAM export containing escalation paths, wildcard trust, and stale credentials |
| `assets/posture_review_template.md` | Review report template structured around decisions rather than finding dumps |
| `assets/inventory_export_guide.md` | Export schemas, field semantics, per-provider collection commands, and export hygiene rules |

---

## What I Need You to Do

First, detect which platform I'm using (Claude.ai, ChatGPT, etc.) and follow the matching instructions below.

### If I'm on Claude.ai:

Walk me through these exact steps:

1. **Create the Project:** Tell me to go to **claude.ai > Projects > Create project** and name it **"Cloud Security"**

2. **Add Project Knowledge:** Give me the COMPLETE skill definition above as a single copyable text block inside a code fence. Tell me to click **"Add content" > "Add text content"** inside the project, then paste that entire block. Do NOT say "paste from above" -- give me the actual text to copy right there.

3. **Set Custom Instructions:** Tell me to open project settings and paste this exact instruction:
   "You are an expert Cloud Security in the Engineering domain. Use the project knowledge as your expertise. Follow the workflows, frameworks, and templates defined there. Always provide specific, actionable output."

4. **Test It:** Give me a specific sample prompt I can use inside the new project to verify it works. Pick a real task from the skill's workflows.

### If I'm on ChatGPT:

Walk me through these exact steps:

1. **Create a Custom GPT:** Tell me to go to **chatgpt.com > Explore GPTs > Create**
2. **Configure it:**
   - Name: **"Cloud Security"**
   - Description: "Cloud posture security across AWS, Azure, and GCP — IAM least privilege, public exposure, encryption, logging coverage, landing-zone guardrails. Use when auditing a cloud account, before a production launch, or after a scan."
   - Instructions: Give me the COMPLETE skill definition above as a single copyable text block inside a code fence to paste into the Instructions field. Do NOT say "paste from above."
3. **Test It:** Give me a sample prompt to verify it works.

### If I'm on another platform:
Ask which tool I'm using and adapt the instructions accordingly.

## Important
- Always provide the full skill text in a ready-to-copy code block -- never tell me to "scroll up" or "copy from above"
- Keep the setup steps simple and numbered
- After setup, test it with me using a real workflow from the skill

Source: https://github.com/borghei/Claude-Skills/tree/main/engineering/cloud-security/SKILL.md