Enablement Checks

Only with an explicit request for detailed account-level enumeration, reconcile complete member IDs/status with scoped ACTIVE IDs from inventory, following all pages. Broad coverage audits or service recommendations alone do not authorize member enumeration. Prefer available statistics/counts; mark unrequested detail NOT ASSESSED. Apply this gate to every member read below and any Security Lake per-member source checks or account-bearing source listings. Do not run unbounded source listings for org-wide member discovery. Missing permissions/pages in authorized reads leave the remainder UNKNOWN. Membership and central-policy association are separate evidence; listing policies proves neither coverage nor successful application.

Contents

• Amazon GuardDuty
• AWS Security Hub CSPM
• AWS Security Hub (unified)
• AWS Certificate Manager
• AWS Network Firewall
• Route 53 Resolver DNS Firewall
• AWS Firewall Manager
• Account-scoped coverage interpretation
• Amazon Inspector
• Amazon Macie
• Amazon Detective
• Amazon Security Lake
• AWS Security Incident Response
• IAM Access Analyzer
• AWS Config
• Summary table to produce

Amazon GuardDuty

get-detector returns Features[] with a Name and Status per plan.

Features[] also includes the foundational sources CLOUD_TRAIL, DNS_LOGS, and FLOW_LOGS. These are always ENABLED on an active detector and are not protection plans; they cannot be toggled, so do not report them as gaps. VPC flow and DNS analysis are still metered per GB; apply the parent workflow cost rules.

Discover the current optional protection-plan names and covered resource/service set from get-detector Features[] and the current GuardDuty documentation. Report every returned feature name, including new or unrecognized names, and mark supported-but-unreturned completeness UNKNOWN if current documentation cannot be read. The rows below are applicability examples, not a closed feature catalog:

Runtime Monitoring has an AdditionalConfiguration array for agent management: EC2_AGENT_MANAGEMENT, ECS_FARGATE_AGENT_MANAGEMENT, EKS_ADDON_MANAGEMENT. The guide recommends letting GuardDuty manage agents so new resources are covered automatically.

describe-organization-configuration returns AutoEnableOrganizationMembers with values NEW, ALL, or NONE. ALL covers existing and new accounts and is what the guide’s reference Terraform uses; the guide itself presents the three options without ranking them, so this skill’s pass condition of ALL is its own design. NEW leaves existing accounts uncovered; NONE means manual management.

Pass conditions: detector exists; every feature whose triggering resource is present is ENABLED; AutoEnableOrganizationMembers is ALL in an org; finding publishing frequency tightened from the 6-hour default (15 minutes if Detective is in use; AWS states that changing this setting has no effect on the cost of using GuardDuty, a statement scoped to FindingPublishingFrequency alone and not to any consumer’s own charges); S3 Malware Protection plans exist for the buckets identified as taking untrusted uploads.

AWS Security Hub CSPM

Standard names, versions and ARNs change as AWS adds and retires them: read the current set with aws securityhub describe-standards and name only versions that call returns. New adopters should start at the latest version of a benchmark. The PCI SSC’s retirement of PCI DSS v3.2.1 (external context, not guide-sourced) is why in-scope orgs need the current PCI DSS version. NIST SP 800-171 applies to CUI handling. The AI Security Best Practices standard and the AWS Resource Tagging Standard are also offered; confirm availability from describe-standards.

Pass conditions: hub enabled; FSBP enabled at minimum; a finding aggregator exists if more than one region is in use; central configuration policy in place for orgs; a customer-managed AWS Config recorder present only if CSPM runs standalone (see AWS Config below).

AWS Security Hub (unified)

Distinct from CSPM. The older product was rebranded Security Hub CSPM; the unified Security Hub is a platform that correlates GuardDuty, Inspector, Macie, and CSPM signals into exposure findings and attack paths. Both can be enabled at once, and both live in the securityhub API namespace — the unified service uses the *V2 operations.

Cross-cutting finding: if unified Security Hub is enabled and CSPM is still ingesting AWS service or third-party findings that Security Hub already aggregates, you may be paying for the same aggregation twice. The guide’s lever is disabling that finding ingestion in CSPM, not removing the cross-region finding aggregator, which central configuration requires. Before recommending it, the guide is explicit that you must audit EventBridge rules, SIEM feeds, ticketing workflows, and custom Lambda functions and confirm each reads from Security Hub, because disabling ingestion without checking dependencies “breaks alerting quietly”. Keep Macie publishing to CSPM: that is how sensitive-data traits reach Security Hub exposure scoring.

Verify current plans, pricing and inclusion using the parent cost-review rules.

Policies vs deployments: Organizations policies exist for Security Hub and Inspector and auto-apply to new accounts, preventing drift. GuardDuty and CSPM use one-time deployments that cannot be viewed or edited and do not cover newly enabled accounts — so GuardDuty and locally configured CSPM still need auto-enable for new members. Under CSPM central configuration, false/NONE auto-enable fields are expected; verify policy association/application and member coverage separately, or report them UNKNOWN.

Pass conditions: enabled in the delegated admin’s home region; no duplicate finding ingestion in CSPM once consumers are confirmed on Security Hub; Threat Analytics considered for production accounts.

AWS Certificate Manager

ACM is always available rather than something you enable, so the checks here are monitoring and configuration hygiene.

Pass conditions: the chosen monitoring method demonstrates coverage of the relevant certificate estate, successful notification delivery and adequate renewal lead time (see the matrix (opens in a new tab)). Accept adequate CloudWatch expiry alarms or scheduled issuer-side checks; missing EventBridge/SNS routing alone is not a gap. Where an unmet need is demonstrated and ACM event applicability is verified, EventBridge expiry routing is an option: inspect the enabled rule’s aws.acm source and “ACM Certificate Approaching Expiration” detail-type, relevant certificate scope and notification target. If the target is SNS, require KMS encryption at rest and TLS in transit for publication and subscriber access, apply the parent topic-policy and authorized-recipient requirements, and verify successful delivery separately. Rule/target existence proves configuration, not delivery. Missing monitoring, destination-protection or delivery evidence stays UNKNOWN, not absent protection. Prefer DNS validation where applicable.

ACM-requested public and private certificates may qualify for managed renewal: inspect RenewalEligibility, available RenewalSummary status, and the issuance/management path. Type or eligibility alone does not prove successful renewal. Imported certificates and certificates issued directly through Private CA IssueCertificate need separate renewal handling. Do not assume ACM expiry events for direct issuance: verify ACM representation and documented event applicability; otherwise require issuer/deployment-side expiration monitoring and report monitoring UNKNOWN. Missing issuance history needs manual confirmation.

Notes: Inspect actual NotBefore/NotAfter dates, certificate type, and current issuer/service documentation, including ACM certificate characteristics (opens in a new tab). Do not assume public, private, and imported certificates share one validity period; missing dates remain UNKNOWN. CloudFront certificates must be issued in us-east-1 regardless of the distribution’s origin region. Certificate Transparency logging cannot be toggled from the console, cannot change once the renewal period starts (confirm the current window in the ACM managed-renewal documentation), and failures there are silent.

AWS Network Firewall

These reads establish presence, logging and policy settings. list-firewalls, describe-firewall and describe-logging-configuration cover the firewall resource itself; policy-level settings (stateless/stateful rule groups, default actions, rule order) live on the policy, not on the firewall, and are read with describe-firewall-policy. Continue with the selected network suitability guidance (opens in a new tab) for deployment, HOME_NET/rule applicability, TLS/trust suitability using focused evidence. Do not author or execute Suricata rules, mutation recipes, scans or analyses. Configuration alone does not prove symmetric routing, enforcement or client compatibility.

Assessment conditions: first establish the actual deployment mode, intended traffic paths and compatible policy strategy (see the matrix (opens in a new tab)). Assess endpoint/AZ coverage against that topology; do not apply an inspection-VPC rule universally to native TGW or multi-endpoint designs. Record observed rule order, stateless forwarding, default actions and logging destinations separately from evidence of effective blocking and log delivery. Any recommended ALERT/FLOW destination MUST use KMS encryption at rest for its CloudWatch Logs log group or S3 sink and TLS in transit for delivery and consumer access. Verify encryption, transport, retention and delivery separately; destination configuration alone proves none of them. Evaluate strict order, application-aware versus custom defaults and required ALERT/FLOW visibility in that context; do not require every drop default to have a paired alert default. Unresolved topology, intent, compatibility or effectiveness remains UNKNOWN rather than a gap.

Assess StreamExceptionPolicy against application recovery requirements and existing connection/idle-flow evidence. Recommend a change only for a demonstrated incompatibility, with owner-reviewed planned impact and validation; do not assert a universal firewall restart or change requirement.

Route 53 Resolver DNS Firewall

Pass conditions: at least one rule group associated with each VPC; AWS-managed domain lists attached as the first layer; DNS Firewall Advanced enabled for DNS tunneling and domain-generation-algorithm detection; query-log association CREATED for the actual VPC; and its CloudWatch Logs log group or S3 sink uses KMS encryption at rest and TLS in transit for delivery and consumer access, with a deliberate retention policy. A query-log configuration alone does not prove VPC coverage, encryption, transport, retention or delivery; missing evidence for any of those remains UNKNOWN.

DNS Firewall is the earliest filter in the chain — blocking at the DNS layer stops traffic before it reaches Network Firewall, which reduces downstream processing cost.

AWS Firewall Manager

Relevant for distributed deployments: 10 or more accounts with per-account or per-VPC WAF, DNS Firewall, or Network Firewall that need policy rollout and enforcement as accounts and VPCs are added. Requires AWS Organizations and AWS Config; verify current pricing/bundling. It adds limited value to a centralized single-firewall design.

Pass conditions: an FMS administrator account exists if the org has 10 or more accounts with distributed firewall deployments; not required for a centralized design.

Account-scoped coverage interpretation

For both coverage examples, substitute only the account established by caller identity, not an account discovered through admin visibility. For an explicitly approved multi-account set, run bounded per-account predicates and label each scope. Follow CLI auto-pagination; no max-items/no-paginate for completeness claims. Retain successful pages and mark a failed remainder UNKNOWN. Coverage rows are scan/coverage records, not unique workload counts. The projections retain identifiers for scoped reconciliation; mask them in reports. GuardDuty’s resource type is nested under ResourceDetails.ResourceType. Inspector’s account predicate is filterCriteria.accountId with comparison: EQUALS. A client-side projection/filter does not constrain collection. Do not use unfiltered GuardDuty coverage statistics from a delegated administrator as evidence about the caller account; if a verified scoped statistics request is unavailable, use the filtered list or mark UNKNOWN.

Amazon Inspector

batch-get-account-status returns resourceState entries for scan types in the reviewed account and Region. Use the current Amazon Inspector documentation as the source of truth for supported scan types, compare that documented set with the returned states, and report every returned scan type including new or unrecognized names. The API response is account status, not a complete supported-type catalog. If current documentation cannot be read, mark supported-scan-type completeness UNKNOWN rather than comparing against a remembered list.

LAMBDA and LAMBDA_CODE are separate toggles and the guide says both should be on — LAMBDA covers package vulnerabilities, LAMBDA_CODE covers custom application code.

CODE_REPOSITORY is Inspector Code Security (repository SAST, SCA, and IaC scanning). A confirmed repository or CI/CD use case selects the matrix guidance (opens in a new tab), with focused integration/language/gate evidence and an AppSec handoff. Account inventory alone neither triggers this recommendation nor establishes absence of repositories.

Use the current Amazon Inspector API documentation as the source of truth for allowed ECR rescan-duration values. Report the observed rescanDurationState value and compare it with current documented options; if the documentation cannot be read, mark option-set completeness UNKNOWN rather than comparing against a remembered list.

Pass conditions: every scan type with corresponding resources is ENABLED; autoEnable covers new member accounts; EC2 scanning on Enhanced EC2 Scanning (the VM Scanner), with a legacy SSM-plugin setup flagged as a migration finding; Deep Inspection on for supported platforms with Enhanced EC2 Scanning, after confirming the latest platform set in Amazon Inspector documentation, and custom paths reviewed against where software is actually installed; ECR rescan durations match build cadence (a cost lever only for standalone Inspector).

Amazon Macie

Pass conditions: session ENABLED; automated sensitive data discovery ENABLED; classification export configured to an S3 bucket that uses KMS encryption at rest and TLS in transit for delivery and consumer access, with retention and successful delivery verified separately; securityHubConfiguration.publishClassificationFindings is true (the guide calls publishing sensitive data findings its highest-value configuration change, because Security Hub exposure scoring and GuardDuty attack sequences use the sensitive-data trait); autoEnable on for new org accounts.

Coverage limits: Macie monitors general purpose buckets per account up to a documented ceiling, and coverage stops once that ceiling is reached. The limit changes, so confirm the current value from the Macie quotas documentation rather than relying on a fixed number. Buckets whose policy carries an explicit deny need the Macie service-linked role allowed before they can be scanned; the resource coverage page lists them.

Amazon Detective

Eligibility: GuardDuty is not a prerequisite. The current Detective prerequisites (opens in a new tab) are the required IAM permissions and a recent AWS CLI version (confirm the current minimum from the Detective prerequisites documentation); the pinned guide’s prerequisite claim is superseded. GuardDuty’s actual relationship is a recommendation to align the administrator account across GuardDuty, Security Hub CSPM and Detective so the finding pivot and the archive-from-Detective integration work. Do not recommend enabling GuardDuty solely to satisfy a prerequisite gate.

Pass conditions: graph exists; auto-enable on; administrator account aligned with GuardDuty and Security Hub CSPM where those are in use; GuardDuty finding publishing frequency set to 15 minutes (the 6-hour default delays recurring-finding updates in Detective by up to 6 hours; AWS states that changing this setting has no effect on the cost of using GuardDuty, which says nothing about Detective’s own charges); source packages for AWS security findings and EKS audit logs enabled — older deployments must turn these on manually; where Security Lake is also in use, the Detective integration lets investigators pull the underlying logs with a pre-built Athena query. Source: Detective recommendations (opens in a new tab).

Quota: a behavior graph has a maximum number of member accounts; confirm the current value in the Amazon Detective quotas documentation before relying on it.

Amazon Security Lake

Use the current Amazon Security Lake documentation as the source of truth for supported AwsLogSourceName values, default-source behavior and regional availability. Prefer AWS MCP documentation search/read when available; otherwise use the official Security Lake documentation over HTTPS. Do not treat source names shown elsewhere in this Skill as a closed catalog. Compare that current documented set with get-data-lake-sources status and list-log-sources configured inventory. Report every returned source name, including new or unrecognized names. If current documentation cannot be read, mark supported-source and default-source completeness UNKNOWN rather than comparing against a remembered list.

Each AWS source also carries a sourceVersion, which matches latest or an N.N value such as 2.0. Security Lake ingests the latest version by default. Record the observed sourceVersion per source, account and region instead of requiring a particular value: a newer version is not automatically safe for current consumers, and selecting a version requires a matching subscriber update before those consumers can read it. Custom sources carry no sourceVersion, so mark that NOT APPLICABLE, not UNKNOWN. Do not confuse the field value with OCSF table or S3 prefix naming such as vpc_flow_2_0, which cannot appear in this field.

Prerequisite: CLOUD_TRAIL_MGMT collection requires an existing multi-region organization trail capturing read and write management events. Verify log file validation, KMS encryption at rest and TLS in transit for the trail’s S3 destination and any CloudWatch Logs delivery, with retention and successful delivery assessed separately.

Delegated admin placement: the Log Archive account, not the security tooling account used by the other five services.

Pass conditions: data lake exists; every source in the current documented default set is enabled where available and applicable; new-account collection enabled; the observed sourceVersion recorded for each enabled source, with any subscriber update the selected version still needs identified; if rollup regions are configured, contributing-region retention matches verified investigation and recovery needs. If the current default set could not be read, its completeness check is UNKNOWN.

AWS Security Incident Response

Downstream of detection: it ingests and triages threat detection findings that GuardDuty and Security Hub produce. It triages threat detection findings only — security posture and compliance findings (misconfiguration alerts, benchmark violations) are not triaged, because they describe a state in the environment, not an active threat. It is not a detection service, generates no findings of its own, and never substitutes for them. Enabling GuardDuty or Security Hub CSPM first is strongly recommended but is not required to activate it, so absent detection coverage is a separate finding, not a blocked prerequisite.

Pass conditions: membership status Active (Pending means onboarding is incomplete); account scope covers the intended organizational units; at least two incident response team members configured, which the service requires; the registered Region matches where the assessed workloads run. Coverage is selected at organization or OU level, not per account, and every account in a selected OU including child OUs is covered. A membership existing is not account coverage: only accounts enrolled in the membership are monitored, so reconcile the covered OUs against the assessed scope before calling coverage complete. Findings created before onboarding are not ingested retroactively.

Cost note: charges are metered on findings ingested, and AWS documents a monthly free-tier allowance plus inclusion for some support tiers. Free-tier counts and inclusion terms change, so do not state a specific figure here: report cost UNKNOWN pending verified ingestion volume and the account’s support tier, and read the current free-tier allowance, inclusion terms and per-finding rate from AWS pricing. No rate is recorded here.

IAM Access Analyzer

Use the current IAM Access Analyzer documentation as the source of truth for supported analyzer types and their scope. Treat list-analyzers as configured inventory rather than a complete supported-type catalog, and report every returned type, including new or unrecognized values. Compare current documented external-, unused- and internal-access analyzer capabilities with the configured inventory. If current documentation cannot be read, mark supported-type completeness UNKNOWN rather than comparing against a remembered list.

These are distinct analyzers, not one analyzer with modes. An account can have an unused-access analyzer and still have no external-access analyzer — check the type field rather than treating any active analyzer as coverage. Security Hub may create an unused-access analyzer automatically (named _AccessAnalyzerForSecurityHub*), which is why “an analyzer exists” is not sufficient evidence of external-access coverage.

Pass conditions: a current documented external-access analyzer type is configured for each relevant region; a current documented unused-access analyzer type is configured when the organization reviews unused permissions, without duplicating organization-wide coverage per region. Verify internal-access scope separately before judging coverage.

AWS Config

Check this only when Security Hub CSPM runs standalone. When unified Security Hub and CSPM are both enabled, CSPM creates and manages the service-linked recorder AWSConfigurationRecorderForSecurityHubCSPM in each account and region, keeps its scope aligned to the controls, does not use your customer-managed recorder, and Config.1 always passes. In that state a missing customer-managed recorder or delivery channel is not a gap.

Pass conditions (standalone CSPM): recorder exists, recording is true, and lastStatus is SUCCESS; delivery channel configured, with KMS encryption at rest and TLS in transit for its S3 destination and any SNS topic, plus the parent destination-policy and recipient checks; retention and successful delivery verified separately; recording group covers the resource types the enabled standards evaluate; global resources recorded in one region only (the guide’s duplication-avoidance practice). The guide’s standalone cost levers: record global resources in one region, turn off the compliance history timeline if Config serves only CSPM, and be cautious scoping the recorder down, since new controls arrive regularly. Whichever recorder is in play, CSPM emits WARNING findings for controls whose resource type is not being recorded; treat those as the safety net.

Summary table to produce

Summarize relationships/counts with masked identifiers unless detail was explicitly requested. Projections are not disclosure permission; apply parent raw-output and sensitive-field exclusions. Unrequested member detail is NOT ASSESSED.