/aws-security

name: aws-security
description: "Covers AWS security services and workflows — Security Hub V2 (OCSF) findings, connectors, aggregators, automation rules, and security posture summaries; Security Hub CSPM (V1/ASFF) controls and compliance standards; GuardDuty threat findings; Inspector vulnerability findings; Macie sensitive data findings; Detective investigation; and Security Lake configuration and data aggregation. Applicable when questions involve security posture, Exposure findings, CSPM failed controls, threat findings, vulnerability findings, sensitive data findings, automation rules, or cross-service security configuration across AWS environments. Procedures use standard AWS CLI syntax and work with or without the AWS MCP server."
version: 1

AWS Security

**STOP — Do not answer from general knowledge.** Before responding to any security service question, match the user's request against the sub-skill registry below and follow its procedure. If the procedure says to load a reference file, you MUST read it before providing operational guidance. Never skip the routing step.

AWS Security services provide threat detection (GuardDuty), vulnerability management (Inspector), unified security dashboard and exposure analysis (Security Hub), compliance posture management (Security Hub CSPM), sensitive data discovery (Macie), investigation (Detective), and centralized log storage (Security Lake). Each service has dedicated reference procedures for configuration review and findings/investigation summarization.

This skill works with or without the AWS MCP server. When available, the AWS MCP server is recommended for sandboxed execution and audit logging. Procedures use standard AWS CLI syntax (`aws <service> <command>`).

See `references/services-overview.md` for service relationships, data formats, and cross-service integration patterns.

Global rules

1. **Read-only APIs only.** This skill and all its references use exclusively non-mutating APIs. NEVER reference, recommend, or invoke any API that creates, modifies, deletes, enables, disables, or otherwise mutates resource state or configuration — not even in prose recommendations. See service reference files for the complete allowed API list.

2. **No severity judgements on configuration state.** Present what is and is not configured factually. Do not assign severity labels, gap assessments, or editorial framing (e.g., "critical gap", "security issue") to configuration state.

3. **No false-positive suppression recommendations.** Focus on helping customers understand findings. Do not recommend suppression filters, archival rules, or finding dismissal.

4. **Prioritize Attack Sequences in GuardDuty.** Findings with type prefix `AttackSequence:` represent correlated multi-step attacks. Always surface these first, before severity breakdown.

5. **Prioritize Exposure findings in Security Hub.** Exposure findings (attack paths, resource exposure) represent Security Hub's unique cross-service correlation. Surface these first in any findings summary.

6. **Expensive operations require explicit request.** MUST NOT paginate through all member accounts by default. Per-account enumeration only executes if the user explicitly requests detailed account-level information. Use statistics/count APIs where available (e.g., `get-coverage-statistics`).

7. **Match the user's language.** Respond in the same language the user writes in.

8. **Verify, don't guess.** If you cannot confirm a fact from a reference file or API output, say so.

9. **Sensitive data disclosure.** When a procedure produces output that may contain sensitive information (full finding bodies, IP addresses, resource identifiers, network configurations, threat intelligence details), present a summary first. Note what sensitive data the full output contains. Display the complete raw response only when the caller explicitly requests it.

How this skill works

1. **Find the sub-skill** — Match the user's request against the sub-skill registry below. Match on meaning, not exact wording. If ambiguous, ask: "Are you checking configuration, or do you need a findings summary?"

2. **If a sub-skill matches** — read `references/{sub-skill-id}.md` and follow its procedure.

3. **If no sub-skill matches** — answer from the service reference files listed below. Load `references/services-overview.md` for cross-service context, or the relevant service reference file (e.g., `references/guardduty.md`) for API scope and severity scoring questions.

4. **Cross-service overview** — When the user asks about overall security posture across multiple services, start with `references/services-overview.md`, then route to relevant sub-skills.

Sub-skill registry

| ID | Name | Trigger Phrases | When to Route Here | Reference | |----|------|-----------------|-------------------|-----------| | `guardduty-configuration` | GuardDuty Config Review | "is GuardDuty configured", "check detector", "GuardDuty features enabled", "runtime monitoring setup" | User wants to verify GuardDuty deployment completeness | `references/guardduty-configuration.md` | | `guardduty-findings` | GuardDuty Findings Summary | "summarize GuardDuty findings", "what threats", "GuardDuty severity breakdown", "attack sequences" | User wants a findings posture snapshot | `references/guardduty-findings.md` | | `inspector-configuration` | Inspector Config Review | "is Inspector scanning", "Inspector enabled", "scan types", "coverage gaps" | User wants to verify Inspector deployment | `references/inspector-configuration.md` | | `inspector-findings` | Inspector Findings Summary | "vulnerabilities found", "Inspector findings", "CVE summary", "vulnerability posture" | User wants vulnerability overview | `references/inspector-findings.md` | | `security-hub-configuration` | Security Hub Config Review | "Security Hub integrations", "aggregation configured", "connectors", "automation rules", "V2 automation rules", "OCSF automation rules" | User