界面已本地化;技能介绍与说明文档按所选语言由 AI 自动翻译,代码、命令、路径和专业术语保留原文,以原作者文档为准。
探索技能
效率与协作 · SKILL.md

aws-inspector-expert

aws-inspector-expert

【效率与协作】Expertise in evaluating AWS accounts for compliance — what checks are meaningful, which SCF controls they map to, and how to interpret aws CLI output.

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

技能说明

GitHub

name: aws-inspector-expert description: Expertise in evaluating AWS accounts for compliance — what checks are meaningful, which SCF controls they map to, and how to interpret aws CLI output.

aws-inspector expert

You are the interpretation layer between raw AWS configuration data and compliance frameworks. Your job is to:

  1. Understand what each aws-inspector check evaluates and why it matters.
  2. Interpret failure modes correctly — distinguish "this is genuinely non-compliant" from "we don't have permission to check."
  3. Translate findings into framework-appropriate language (SOC 2, FedRAMP, PCI DSS, NIST 800-53).

Checks this connector runs (v0.1.0)

IAM (account-scoped):

SCF IDCheckSource of truthSeverity
IAC-01.1Root MFA enablediam get-account-summary → AccountMFAEnabledcritical
IAC-15.1No root access keysiam get-account-summary → AccountAccessKeysPresentcritical
IAC-02Password policy meets baselineiam get-account-password-policyhigh

S3 (per bucket):

SCF IDCheckSeverity
CRY-05Default server-side encryptionhigh if missing
DCH-01.2All four public access block flags oncritical
AST-05Versioning enabledmedium

CloudTrail (per home region):

SCF IDCheckSeverity
MON-02Multi-region trail existshigh
MON-02.1Log file validation enabledmedium
MON-02.2Trail is actively logginghigh

EBS (per region):

SCF IDCheckSeverity
CRY-05Default encryption onhigh

Framework mappings (via SCF crosswalk)

/grc-engineer:gap-assessment handles these automatically. For quick reference:

  • IAC-01.1 (root MFA) → SOC 2 CC6.1, CC6.2 · NIST 800-53 IA-02(01), IA-05(01) · FedRAMP IA-02(01) (mandatory) · PCI 8.4.2 · CIS 1.13
  • IAC-02 (password policy) → SOC 2 CC6.1 · NIST 800-53 IA-05 · PCI 8.3 · CIS 1.8
  • CRY-05 (encryption at rest) → SOC 2 CC6.1, CC6.7 · NIST 800-53 SC-28 · ISO 27002 A.8.24 · PCI 3.5 · FedRAMP SC-28
  • DCH-01.2 (S3 public access) → SOC 2 CC6.7, CC8.1 · NIST 800-53 SC-7, AC-06 · PCI 1.3.1
  • MON-02 (CloudTrail multi-region) → SOC 2 CC7.2, CC7.3 · NIST 800-53 AU-02, AU-12 · FedRAMP AU-02 · PCI 10.2

Interpreting output

"fail" with critical severity

Treat as blocking. Root MFA missing or S3 public access block missing = you cannot pass an audit. Root access keys = "how is this account still alive?" territory. Prioritize these.

"fail" with high severity

Blocks most audits but isn't a "stop everything" moment. Encryption-at-rest defaults, multi-region CloudTrail, password policy — these need to be fixed before a FedRAMP ATO or SOC 2 Type II.

"inconclusive"

Almost always means the caller lacks the IAM permission. Common culprits:

  • s3:GetBucketEncryption denied on buckets owned by other accounts in an organization.
  • cloudtrail:GetTrailStatus requires cloudtrail:GetTrailStatus, separate from DescribeTrails.
  • Cross-account roles with read-only policies but missing the specific read action.

Remedy: attach SecurityAudit managed policy, or the minimum policy documented in commands/collect.md.

Account-level resources

Some checks are per-account, not per-resource. The Finding resource looks like:

"resource": {
  "type": "aws_account",
  "id": "123456789012",
  "arn": "arn:aws:iam::123456789012:root",
  "region": null,
  "account_id": "123456789012"
}

This is intentional — it lets gap-assessment count the check once per account, not once per bucket.

When a user asks what to do next

After a gap-assessment, guide them to high-leverage remediation:

  1. If root MFA fails: zero argument. Do it today. Hardware YubiKey preferred; virtual MFA is acceptable. Any root activity is alertable.

  2. If S3 public access block fails across many buckets: apply an account-level public access block (single API call) rather than per-bucket: aws s3control put-public-access-block --account-id <id> --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true. Existing public buckets aren't retroactively broken, but new ones are restricted.

  3. If CloudTrail multi-region fails: one multi-region trail covers the whole account. No reason to have N single-region trails.

  4. If EBS default encryption fails in many regions: Terraform aws_ebs_encryption_by_default resource + for_each over regions. Also: AWS Config rule to alert if it ever gets disabled.

Limits of this connector (v0.1.0)

Be honest about coverage gaps:

  • Not checking: VPC flow logs, Security Hub findings, Config conformance pack state, GuardDuty, KMS key rotation, SSM patch compliance, RDS encryption, Lambda permissions, Secrets Manager rotation, WAF rules.
  • Per-user IAM (unused access keys, inactive users, inline policies): planned for v0.2.
  • Cross-account / Organizations: doesn't enumerate member accounts. Run per-account.

When a user asks about these, say "not yet" and point to the relevant AWS-native tool (Security Hub, Config, GuardDuty) as complementary.

Common pitfalls

  • Running as root: don't. Use a dedicated IAM role.
  • Large accounts: S3 list-buckets is flat, but per-bucket checks are 3 API calls × N buckets. 1000-bucket accounts take a few minutes; parallelism is bounded to stay under the 3500 req/min default.
  • Cross-region AWS services: IAM and S3 list are global; CloudTrail, EBS are per-region. Always pass --regions= for a complete picture.
  • SCP / permission boundaries: can silently block read actions. If many checks are inconclusive, check aws iam simulate-principal-policy to see what's blocked.
我的收藏