AWS Security

aws <service> <command>

references/services-overview.md

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

guardduty-configuration

references/guardduty-configuration.md

guardduty-findings

references/guardduty-findings.md

inspector-configuration

references/inspector-configuration.md

inspector-findings

references/inspector-findings.md

security-hub-configuration

references/security-hub-configuration.md

security-hub-findings

references/security-hub-findings.md

security-hub-cspm-configuration

references/security-hub-cspm-configuration.md

security-hub-cspm-findings

references/security-hub-cspm-findings.md

macie-configuration

references/macie-configuration.md

macie-findings

references/macie-findings.md

detective-configuration

references/detective-configuration.md

detective-investigations

references/detective-investigations.md

security-lake-configuration

references/security-lake-configuration.md

security-lake-sources

references/security-lake-sources.md

organization-policies

references/organization-policies.md

Disambiguation

list-automation-rules-v2

Service reference

references/services-overview.md

references/guardduty.md

references/inspector.md

references/security-hub.md

references/security-hub-cspm.md

references/macie.md

references/detective.md

references/security-lake.md

references/organization-policies.md

Security considerations

• Logging and monitoring: Verify CloudTrail is enabled for security service and Organizations API calls, CloudTrail log file validation is active, and CloudWatch metric filters or alarms exist for anomalous privileged read patterns such as unexpected volume, unusual principals, or unexpected regions.
• Encryption and destinations: Verify publishing or export destinations such as S3 buckets, SNS topics, and CloudWatch Logs use KMS encryption at rest and TLS in transit. For downstream S3 or SNS destinations, verify resource policies use

  aws:SourceArn

  and

  aws:SourceAccount

  condition keys where applicable.
• Notification recipients: Verify SNS topic subscriptions and other security alarm recipients are restricted to authorized security personnel, and periodically audit subscription endpoints.
• Credential management: Confirm CLI execution is using temporary credentials such as IAM roles or AWS SSO. Verify third-party integration credentials, API tokens, or connector secrets are stored in AWS Secrets Manager or AWS Systems Manager Parameter Store rather than plaintext configuration files or environment variables.
• Security references: Consult AWS Security Hub best practices, AWS CloudTrail security best practices, IAM security best practices, and the AWS Well-Architected Security Pillar for current service guidance.
• Sensitive data: Security service outputs may contain sensitive information such as IP addresses, resource identifiers, account IDs, vulnerability details, exposure paths, and threat intelligence. Classification and handling requirements are customer-specific; do not store or share outputs in unprotected channels without verifying organizational data handling policies.