SOC 2 (AICPA TSC 2017) Pre-Audit Gap Report

Generated: 2026-06-24T23:07:45.312Z

Cover: Scope Attestation

Report ID: aws_20260624_160745
Generated at: 2026-06-24T23:07:45.312Z
Assessment type: Point-in-time (Type-I-friendly). NOT a Type-II operating-effectiveness assertion.
Scanner: NSAuditor AI EE v0.31.3 (CE v0.2.15)
Scan window: (not provided) → (not provided)
Targets in scope: aws
Targets explicitly excluded: None
Framework: SOC 2 (AICPA TSC 2017) (version 2017)
Report integrity: SHA-256 in companion .sha256 sidecar — verify: shasum -a 256 -c <file>.sha256
Trusted timestamp (RFC 3161): Not configured. SHA-256 provides integrity only. For non-repudiation, configure complianceTsaUrl.
TSA policy OID: N/A — TSA itself is not configured.
TSA cert chain bundling: N/A — TSA itself is not configured.
Clock advisory: ℹ️ local_clock (Active NTP-drift probing deferred to EE-SOC2.8 (v0.3.1). Local-clock advisory only.)

This attestation page is required by SOC 2 auditors as proof-of-scope. Without it, reports are routinely rejected for ambiguous coverage.

Executive Summary

Controls assessed (in scope): 14
Controls out of scope (documented gaps): 33
Findings analyzed: 242
Status breakdown: 10 fail · 3 pass · 1 partial · 0 accepted-risk · 0 false-positive · 33 out-of-scope

Failing Controls

CC6.1 — Logical access security software, infrastructure, and architectures FAIL

Category: Common Criteria · Logical & Physical Access · Violations: 17

SHADOW ADMIN: User has full wildcard (*) permissions

Source: aws-iam-deep-auditor

CC6.1 requires least-privilege boundaries; shadow admins bypass intended access restrictions.

Privilege escalation paths detected: iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion, iam:AttachUserPolicy, iam:AttachGroupPolicy, iam:AttachRolePolicy, iam:PutUserPolicy, iam:PutGroupPolicy, iam:PutRolePolicy, iam:CreateUser, iam:CreateRole, iam:CreateLoginProfile, iam:UpdateLoginProfile, iam:CreateAccessKey, iam:AddUserToGroup, iam:UpdateAssumeRolePolicy, iam:PutRolePermissionsBoundary, iam:DeleteRolePermissionsBoundary, iam:PutUserPermissionsBoundary, iam:DeleteUserPermissionsBoundary, iam:PassRole, sts:AssumeRole, sts:AssumeRoleWithSAML, sts:AssumeRoleWithWebIdentity, sts:GetFederationToken, lambda:CreateFunction, lambda:InvokeFunction, lambda:UpdateFunctionCode, ec2:RunInstances, cloudformation:CreateStack, datapipeline:CreatePipeline, glue:CreateDevEndpoint, glue:UpdateDevEndpoint, kms:CreateGrant, kms:PutKeyPolicy, kms:ScheduleKeyDeletion

Source: aws-iam-deep-auditor

CC6.1 requires least-privilege; privesc paths violate access boundaries by allowing self-elevation. EE-RT.1.3 extends the legacy per-policy detector to honor NotAction Allow encodings — a `Allow + NotAction:[s3:Get*] + Resource:*` statement now correctly fires this finding (with a ` (via NotAction)` suffix) since it grants every action except s3:Get*, including iam:PassRole / sts:AssumeRole / lambda:CreateFunction. The titlePattern substring matches both classic and `(via NotAction)` variants.

No MFA configured on active IAM user

Source: aws-iam-deep-auditor

CC6.1 requires multi-factor authentication for privileged access (point of focus on user identification).

Shadow admin path: northwind-deploy → northwind-ci-role (role) [inline: northwind-ci-policy]

Source: aws-iam-deep-auditor

CC6.1 requires least-privilege boundaries; shadow admins bypass intended access restrictions.

SHADOW ADMIN: User has full wildcard (*) permissions

Source: aws-iam-deep-auditor

CC6.1 requires least-privilege boundaries; shadow admins bypass intended access restrictions.

Source: aws-iam-deep-auditor

No MFA configured on active IAM user

Source: aws-iam-deep-auditor

CC6.1 requires multi-factor authentication for privileged access (point of focus on user identification).

Shadow admin path: northwind-root → northwind-ci-role (role) [via policy: arn:aws:iam::aws:policy/AdministratorAccess, arn:aws:iam::aws:policy/AdministratorAccess-Amplify]

Source: aws-iam-deep-auditor

CC6.1 requires least-privilege boundaries; shadow admins bypass intended access restrictions.

Lambda function 'nw-checkout-fn' has a public Function URL with AuthType: NONE — exposes the function to public internet without authentication. CC6.1 violation; SOC 2 institutional CRITICAL (parallel to API Gateway NONE-authorizer class). Set AuthType to AWS_IAM (uses SigV4) or front with API Gateway authorizer.

Source: aws-lambda-auditor

CC6.1 requires authenticated logical access on every entry point. AWS Lambda Function URLs configured with `AuthType: NONE` expose the underlying function directly to unauthenticated callers from the public internet — parallel to the API Gateway NONE-authorizer CC6.1 violation class. Plugin 1080 emits CRITICAL per function with a NONE-auth URL. Set AuthType to AWS_IAM (uses SigV4) or front the function with an authenticated API Gateway. Anchored regex (R2-CRITICAL-2 EE-RT.2 lesson) defeats cross-mapping pollution. EE-RT.5 (v0.4.0).

Secrets Manager secret 'nw-db-credentials' has rotation DISABLED. Long-lived credentials accumulate compromise risk over time; AWS-recommended baseline is enabled rotation with a Lambda rotation function. CC6.1 access-control boundary risk on the credential layer (the credential is the access boundary; without rotation it becomes a single-point-of-failure if leaked). Enable rotation via secretsmanager:RotateSecret + AWSCURRENT/AWSPENDING staging labels.

Source: aws-secrets-auditor

CC6.1 requires authentication credential boundaries on logical access. Long-lived AWS Secrets Manager secrets without rotation are an access-control boundary risk on the credential layer — the credential itself IS the access boundary; without scheduled rotation, a leaked credential remains valid indefinitely and the boundary is structurally compromised once leak occurs. AWS-recommended baseline is enabled rotation via secretsmanager:RotateSecret + AWSCURRENT/AWSPENDING staging labels. Plugin 1090 emits MEDIUM per Secrets Manager secret without rotation. Anchored regex defeats cross-mapping pollution. EE-RT.8 (v0.4.0).

IAM principal 'northwind-deploy' (user) has effective kms:Decrypt on Resource:* via policy inline-user:northwind-ci-policy (statement 0). Action(s): [*]; Resource(s): [*]. CC6.1 / C1.1 / CC6.3 risk: principal can decrypt EVERY KMS key whose key policy permits the principal — confidentiality blast-radius is account-wide for any wildcard-permissive key policy. Replace Resource:* with specific key ARN(s) bound to least-privilege. Evidence layer note (EE 0.9.1 B-CRIT-1/2 closure): this finding reflects the identity-policy GRANT — one of the layers required for effective decrypt; the others (KMS key policy + KMS grants) are now cross-referenced per the run-level kms-grant-decrypt-no-identity-grant emission and the HIGH→INFO downgrade contract when no key in the account trusts this principal. SCP / Permissions Boundary / Deny statements remain plugin 1030's domain and the scope-deferred block.

Source: aws-iam-effective-decrypt-auditor

CC6.1 + C1.1 least-privilege boundary on cryptographic-access. IAM principals with effective kms:Decrypt on Resource:* can decrypt every KMS key whose key policy admits them — the confidentiality blast-radius is account-wide for any wildcard-permissive key policy. Institutional auditors expect bounded, key-specific grants on production-sensitive workloads (payroll, customer data, financial records). Plugin 1110 emits HIGH per principal-per-policy-statement; recommended remediation is to narrow Resource to specific key ARN(s). Anchored regex defeats cross-mapping pollution. EE-RT.10 v1 (v0.4.0); principal-graph dimensions (privilege escalation, cross-role assumption) remain plugin 1030's domain.

IAM principal 'northwind-root' (user) has effective kms:Decrypt on Resource:* via policy attached-managed:AdministratorAccess (arn:aws:iam::aws:policy/AdministratorAccess) (statement 0). Action(s): [*]; Resource(s): [*]. CC6.1 / C1.1 / CC6.3 risk: principal can decrypt EVERY KMS key whose key policy permits the principal — confidentiality blast-radius is account-wide for any wildcard-permissive key policy. Replace Resource:* with specific key ARN(s) bound to least-privilege. Evidence layer note (EE 0.9.1 B-CRIT-1/2 closure): this finding reflects the identity-policy GRANT — one of the layers required for effective decrypt; the others (KMS key policy + KMS grants) are now cross-referenced per the run-level kms-grant-decrypt-no-identity-grant emission and the HIGH→INFO downgrade contract when no key in the account trusts this principal. SCP / Permissions Boundary / Deny statements remain plugin 1030's domain and the scope-deferred block.

Source: aws-iam-effective-decrypt-auditor

IAM principal 'northwind-ci-role' (role) has effective kms:Decrypt on Resource:* via policy inline-role:northwind-ci-policy (statement 0). Action(s): [*]; Resource(s): [*]. CC6.1 / C1.1 / CC6.3 risk: principal can decrypt EVERY KMS key whose key policy permits the principal — confidentiality blast-radius is account-wide for any wildcard-permissive key policy. Replace Resource:* with specific key ARN(s) bound to least-privilege. Evidence layer note (EE 0.9.1 B-CRIT-1/2 closure): this finding reflects the identity-policy GRANT — one of the layers required for effective decrypt; the others (KMS key policy + KMS grants) are now cross-referenced per the run-level kms-grant-decrypt-no-identity-grant emission and the HIGH→INFO downgrade contract when no key in the account trusts this principal. SCP / Permissions Boundary / Deny statements remain plugin 1030's domain and the scope-deferred block.

Source: aws-iam-effective-decrypt-auditor

EC2 instance 'i-0a1b2c3d4e5f60718' has IMDSv1 enabled (HttpTokens=optional). CC6.1 access-control gap: instance metadata is reachable without a session token — no IAM instance profile is attached, so no role credentials are currently exposed — but attaching a profile later silently reintroduces the SSRF credential-theft path. Remediate by setting HttpTokens=required (IMDSv2-only) via ec2:ModifyInstanceMetadataOptions.

Source: aws-ec2-instance-auditor

CC6.1 access-control gap — added in EE 0.13.1 (Move B-1.3, plugin 1210). An EC2 instance with IMDSv1 enabled (MetadataOptions.HttpTokens != required while HttpEndpoint is enabled) exposes the instance metadata service without a session token; a server-side request forgery (SSRF) can read the attached IAM role's temporary credentials — the canonical cloud privilege-escalation pivot. Severity scales with credential exposure: MEDIUM when an IAM instance profile is attached (real role-credential exposure; the profile ARN is surfaced in details for 1030/1110 effective-permission pivot), LOW when none is attached (latent). Remediate by enforcing IMDSv2-only (HttpTokens=required) via ec2:ModifyInstanceMetadataOptions. CONFIG-STATE evidence only — this is point-in-time design evidence, NOT period operating-effectiveness (Type II additionally needs CloudTrail evidence of zero IMDSv1 credential-issuance over the period); 1210 does not compute the role's effective permissions. Anchored regex per [[soc2_titlepattern_anchor_drift]].

EC2 instance 'i-0b2c3d4e5f6071829' has IMDSv2 enforced but metadata hop limit 2 exceeds 1 (HttpPutResponseHopLimit=2). CC6.1 access-control gap: a containerized workload on the instance can still reach IMDS across the extra network hop — no IAM instance profile is attached, so no role credentials are currently exposed — but attaching a profile later silently reintroduces the SSRF credential-theft path. Set HttpPutResponseHopLimit=1 unless containers legitimately require IMDS.

Source: aws-ec2-instance-auditor

CC6.1 access-control gap — added in EE 0.13.1 (plugin 1210, IAM-lens reviewer fold). IMDSv2 is enforced (HttpTokens=required) but HttpPutResponseHopLimit > 1 re-opens container-tier credential theft: a pod/container on the instance can still reach IMDS across the extra network hop and pull the attached role's credentials. Set HttpPutResponseHopLimit=1 unless containers legitimately require IMDS. Severity scales with attached-profile presence (MEDIUM/LOW). Config-state evidence only. Anchored regex per [[soc2_titlepattern_anchor_drift]].

ElastiCache Redis replication-group 'nw-product-cache' has NO authentication configured (AuthTokenEnabled=false AND no IAM-auth user groups). CC6.1 / CC6.2 authentication gap: the cluster relies SOLELY on network-perimeter security (Security Groups) for access control. Any principal reachable on TCP 6379 can issue arbitrary Redis commands — cross-plugin sister of plugin 1170 SG-perimeter audit. Enable Redis AUTH (minimum) OR Redis ACL user groups with IAM auth (institutional-grade).

Source: aws-elasticache-redis-auditor

CC6.1 + CC6.2 authentication gap MEDIUM — added in EE-RT.17 v1 (EE 0.4.6). ElastiCache cluster with neither AuthTokenEnabled nor IAM-auth user groups relies SOLELY on Security Group perimeter for access control. Any principal reachable on TCP 6379 can issue arbitrary Redis commands. Cross-plugin sister of plugin 1170 SG perimeter audit. Plugin 1180 emits MEDIUM.

ElastiCache Redis cache-cluster 'nw-session-cache' has NO authentication configured (AuthTokenEnabled=false AND no IAM-auth user groups). CC6.1 / CC6.2 authentication gap: the cluster relies SOLELY on network-perimeter security (Security Groups) for access control. Any principal reachable on TCP 6379 can issue arbitrary Redis commands — cross-plugin sister of plugin 1170 SG-perimeter audit. Enable Redis AUTH (minimum) OR Redis ACL user groups with IAM auth (institutional-grade).

Source: aws-elasticache-redis-auditor

CC6.3 — System access removal and modification FAIL

Category: Common Criteria · Logical & Physical Access · Violations: 1

⚠️ Coverage caveat: Single-scan visibility shows current state but cannot evidence access-removal cadence; pair with CTEM history (EE-SOC2.9) for full coverage.

Customer-managed KMS key '0a1b2c3d-4e5f-4a1b-8c2d-000000000003' has automatic key rotation DISABLED. CC6.3 expects cryptographic credential rotation cadence; AWS recommends enabling annual automatic rotation for customer-managed symmetric encryption keys. Enable via kms:EnableKeyRotation, or document the manual rotation procedure for auditor walkthrough.

Source: aws-kms-auditor

CC6.3 expects cryptographic-credential rotation cadence. AWS-recommended baseline for customer-managed symmetric KMS keys is annual automatic rotation (enabled via kms:EnableKeyRotation). Disabled rotation is a CC6.3 cryptographic-substrate gap (complements the IAM-credential evidence from plugin 1030 stale-access-key findings). Plugin 1070 emits MEDIUM. CC6.3 remains PARTIAL (not promoted to covered) — single-scan visibility evidences current rotation state but the multi-scan removal-cadence dimension belongs to EE-SOC2.9 recurring attestation. Anchored regex (R2-CRITICAL-2 EE-RT.2 lesson) defeats cross-mapping pollution. EE-RT.3 (v0.4.0).

CC6.6 — Logical access boundaries and network segmentation FAIL

Category: Common Criteria · Logical & Physical Access · Violations: 14

DynamoDB table 'northwind-inventory' has no resource policy attached (access control via IAM identity policies only). For audit-store tables, an explicit resource-policy boundary is the institutional defense-in-depth pattern: a resource policy can encode 'only the audit-writer role can PutItem' independently of IAM-policy drift. Consider attaching a resource policy with explicit Deny on DeleteTable/DeleteItem/UpdateItem for non-audit-writer principals (CC6.6).

Source: aws-dynamodb-auditor

CC6.6 requires fine-grained access boundaries on sensitive data stores. AWS DynamoDB resource policies are the defense-in-depth boundary that operates INDEPENDENTLY of IAM-policy drift — an explicit Deny on DeleteTable / DeleteItem / UpdateItem for non-audit-writer principals encoded on the resource policy stays in effect even if a downstream IAM-policy review accidentally grants broader access to a previously-restricted identity. For audit-store tables (where the institutional-grade auditor question is 'can the audit record itself be tampered with?'), missing the resource-policy boundary is a real CC6.6 gap. Plugin 060 emits INFO so the auditor sees the architectural choice was evaluated; the PASS counterpart (`table-resource-policy-present`) is positive evidence on hardened tables. EE-RT.2 (v0.4.0).

DynamoDB table 'northwind-sessions' has no resource policy attached (access control via IAM identity policies only). For audit-store tables, an explicit resource-policy boundary is the institutional defense-in-depth pattern: a resource policy can encode 'only the audit-writer role can PutItem' independently of IAM-policy drift. Consider attaching a resource policy with explicit Deny on DeleteTable/DeleteItem/UpdateItem for non-audit-writer principals (CC6.6).

Source: aws-dynamodb-auditor

SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/nw-order-events' has no resource Policy configured. CC6.6 segmentation gap (policy-layer): no explicit Deny on aws:SecureTransport=false. The AWS SQS API endpoint is HTTPS-only at the transport layer (so cleartext is structurally blocked), but auditor-canonical posture pins this defense at the resource-policy layer for evidence-pack completeness.

Source: aws-sqs-sns-auditor

CC6.6 policy-layer gap MEDIUM — added in EE-RT.15 v1 (EE 0.4.4). No resource Policy at all means no explicit Deny on cleartext access — auditor-canonical defense-in-depth missing. Anchored regex pins to the policy-missing emission (distinct from the configured-but-incomplete sibling). Plugin 1150 emits MEDIUM.

SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/sqs-encrypted-queue' has no resource Policy configured. CC6.6 segmentation gap (policy-layer): no explicit Deny on aws:SecureTransport=false. The AWS SQS API endpoint is HTTPS-only at the transport layer (so cleartext is structurally blocked), but auditor-canonical posture pins this defense at the resource-policy layer for evidence-pack completeness.

Source: aws-sqs-sns-auditor

SNS topic 'arn:aws:sns:us-east-1:123456789012:nw-notifications' policy contains 1 Allow statement(s) granting Principal:"*" on sensitive actions sns:settopicattributes, sns:addpermission, sns:removepermission, sns:deletetopic, sns:subscribe, sns:publish WITH Condition narrowing. CC6.6 auditor-walkthrough required: verify the Condition scope (aws:SourceArn / aws:SourceAccount / aws:PrincipalOrgID) is sufficient. Wildcard-Principal-with-Condition is the institutional boundary-of-trust the auditor walkthrough confirms.

Source: aws-sqs-sns-auditor

CC6.6 segmentation HIGH (auditor-walkthrough required) — added in EE-RT.15 v1 (EE 0.4.4). SNS topic policy has wildcard-Principal Allow on sensitive actions WITH Condition. Auditor walkthrough required to verify the Condition scope (aws:SourceArn / aws:SourceAccount / aws:PrincipalOrgID) is sufficient. Wildcard-Principal-with-Condition is the institutional boundary-of-trust the auditor walkthrough confirms. Plugin 1150 emits HIGH per topic with `walkthroughRequired: true`.

SNS topic 'arn:aws:sns:us-east-1:123456789012:sns-encrypted-topic' policy contains 1 Allow statement(s) granting Principal:"*" on sensitive actions sns:settopicattributes, sns:addpermission, sns:removepermission, sns:deletetopic, sns:subscribe, sns:publish WITH Condition narrowing. CC6.6 auditor-walkthrough required: verify the Condition scope (aws:SourceArn / aws:SourceAccount / aws:PrincipalOrgID) is sufficient. Wildcard-Principal-with-Condition is the institutional boundary-of-trust the auditor walkthrough confirms.

Source: aws-sqs-sns-auditor

Security Group 'sg-0b2c3d4e5f6071829' (name='nsauditor-secure-sg', vpc='vpc-0abcdef0100000010') has egress rule allowing 0.0.0.0/0 (or ::/0). CC6.6 substrate evidence — this is the AWS-default egress posture on newly-created SGs. Outbound data-exfil concerns at the SG layer are out-of-scope (DLP / VPC-endpoint policy / NACL are the substrates that address egress restriction). Recorded for evidence-pack completeness.

Source: aws-ec2-sg-perimeter-auditor

CC6.6 substrate evidence INFO — added in EE-RT.16 v1 (EE 0.4.5). AWS-default egress posture on newly-created SGs. Outbound data-exfil concerns at the SG layer are out-of-scope (DLP / VPC-endpoint policy / NACL are the substrates that address egress restriction). Plugin 1170 emits INFO per affected SG; recorded for evidence-pack completeness.

Security Group 'sg-0abcdef0100000013' (name='default', vpc='vpc-0abcdef0100000015') has egress rule allowing 0.0.0.0/0 (or ::/0). CC6.6 substrate evidence — this is the AWS-default egress posture on newly-created SGs. Outbound data-exfil concerns at the SG layer are out-of-scope (DLP / VPC-endpoint policy / NACL are the substrates that address egress restriction). Recorded for evidence-pack completeness.

Source: aws-ec2-sg-perimeter-auditor

Security Group 'sg-0abcdef0100000012' (name='nw-web-sg', vpc='vpc-0abcdef0100000010') permits tcp ingress from 0.0.0.0/0 to restricted port(s) [5432 PostgreSQL]. CC6.6 perimeter CRITICAL: management/data-tier ports MUST NOT be reachable from the public internet. Remediate by restricting the CIDR source to the operator's bastion / VPN / VPC CIDR.

Source: aws-ec2-sg-perimeter-auditor

CC6.6 perimeter CRITICAL — added in EE-RT.16 v1 (EE 0.4.5). AWS EC2 Security Group rule with IPv4 wildcard (0.0.0.0/0) source on a RESTRICTED_PORT (SSH/RDP/MSSQL/MySQL/Postgres/Redis/Memcached/MongoDB/Elasticsearch/CouchDB/Docker/Kubelet). Management/data-tier ports MUST NOT be reachable from the public internet. Plugin 1170 emits one CRITICAL per (SG, protocol, restricted-port-set) tuple. Orthogonal-evidence sibling to plugin 1023 zero-trust-checker (which reads OBSERVED open ports — plugin 1170 reads DECLARED SG policy). Remediate by restricting CIDR source to operator's bastion / VPN / VPC CIDR.

Security Group 'sg-0abcdef0100000012' (name='nw-web-sg', vpc='vpc-0abcdef0100000010') permits tcp ingress from 0.0.0.0/0 to restricted port(s) [22 SSH]. CC6.6 perimeter CRITICAL: management/data-tier ports MUST NOT be reachable from the public internet. Remediate by restricting the CIDR source to the operator's bastion / VPN / VPC CIDR.

Source: aws-ec2-sg-perimeter-auditor

Security Group 'sg-0abcdef0100000012' (name='nw-web-sg', vpc='vpc-0abcdef0100000010') permits tcp ingress from 0.0.0.0/0 to restricted port(s) [6379 Redis]. CC6.6 perimeter CRITICAL: management/data-tier ports MUST NOT be reachable from the public internet. Remediate by restricting the CIDR source to the operator's bastion / VPN / VPC CIDR.

Source: aws-ec2-sg-perimeter-auditor

Security Group 'sg-0abcdef0100000012' (name='nw-web-sg', vpc='vpc-0abcdef0100000010') has egress rule allowing 0.0.0.0/0 (or ::/0). CC6.6 substrate evidence — this is the AWS-default egress posture on newly-created SGs. Outbound data-exfil concerns at the SG layer are out-of-scope (DLP / VPC-endpoint policy / NACL are the substrates that address egress restriction). Recorded for evidence-pack completeness.

Source: aws-ec2-sg-perimeter-auditor

Security Group 'sg-0a1b2c3d4e5f60718' (name='default', vpc='vpc-0abcdef0100000010') has egress rule allowing 0.0.0.0/0 (or ::/0). CC6.6 substrate evidence — this is the AWS-default egress posture on newly-created SGs. Outbound data-exfil concerns at the SG layer are out-of-scope (DLP / VPC-endpoint policy / NACL are the substrates that address egress restriction). Recorded for evidence-pack completeness.

Source: aws-ec2-sg-perimeter-auditor

EC2 instance 'i-0a1b2c3d4e5f60718' has public IP exposed (3.239.218.43). CC6.6 perimeter substrate evidence: the instance is directly reachable from the public internet (top-level + secondary-ENI / Elastic-IP associations checked) — auditor walkthrough verifies the Security Group ingress is intentional (pair with plugin 1170 SG perimeter findings).

Source: aws-ec2-instance-auditor

CC6.6 perimeter substrate evidence — added in EE 0.13.1 (Move B-1.3, plugin 1210). An EC2 instance with a public IP is directly reachable from the public internet; checked across the top-level field + secondary-ENI / Elastic-IP associations. CONTEXT-ONLY substrate, NOT a segmentation verdict: a public IP alone evidences nothing about CC6.6 (an instance can carry a public IP behind a deny-all Security Group) — the segmentation control verdict comes from SG-ingress analysis (plugin 1170), not from public-IP presence. Emitted at INFO with walkthroughRequired so it reads as context, never a CC6.6 pass/fail signal. Anchored regex per [[soc2_titlepattern_anchor_drift]].

CC7.1 — Detection of changes to system configurations / vulnerabilities FAIL

Category: Common Criteria · System Operations · Violations: 48

Access logging not enabled – audit trail gap

Source: aws-s3-auditor

CC7.1 requires ongoing detection of unauthorized changes; S3 server-access logs are the canonical AWS evidence stream for object-level access detection. Without them, post-incident forensics has no log to walk and CC7.1 detection-procedure expectations are not met.

Access logging not enabled – audit trail gap

Source: aws-s3-auditor

Access logging not enabled – audit trail gap

Source: aws-s3-auditor

Access logging not enabled – audit trail gap

Source: aws-s3-auditor

Access logging not enabled – audit trail gap

Source: aws-s3-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: cloudtrail:DescribeTrails errored in 2 region(s) (me-south-1: TimeoutError, me-central-1: TimeoutError). Single-region trails homed in those regions are UNAUDITED — CloudTrail-derived evidence is PARTIAL. Re-run for full multi-region evidence; persistent errors warrant a network/endpoint/region-enablement check. This is an evidence gap, NOT a control pass.

Source: aws-cloudtrail-auditor

CC7.1 -- CloudTrail/CloudWatch evidence is INCOMPLETE: plugin 1040 aborted at its soft budget (scan-time-budget-exceeded) before finishing the audit, so this control's CloudTrail-derived evidence was not collected. Fails-closed (no silent PASS over an un-audited control surface) per the conservative-classifier principle and consistent with the 1020/1021/1025 evidence-gap convention. Resolve by raising CLOUD_PLUGIN_TIMEOUT_MS / NSA_CT_SOFT_BUDGET_MS or scoping to a single region (NSA_CT_MAX_REGIONS / multiRegionScan=false), then re-run. EE 0.16.5 false-clean fix.

Trail northwind-orgtrail log files not encrypted with a KMS-CMK (KmsKeyId not set)

Source: aws-cloudtrail-auditor

CC7.1 expects detection-stream integrity. CloudTrail logs unencrypted at the storage layer (no KMS-CMK) lack the customer-controlled key custody required for institutional audit-trail confidentiality. EE-RT.1.

Trail northwind-trail has log file validation disabled (LogFileValidationEnabled=false)

Source: aws-cloudtrail-auditor

CC7.1 detection-evidence integrity. Without LogFileValidationEnabled, CloudTrail cannot detect post-hoc log file tampering — the auditor's primary forensic record can be silently modified. EE-RT.1.

Trail northwind-trail log files not encrypted with a KMS-CMK (KmsKeyId not set)

Source: aws-cloudtrail-auditor

Lambda function 'nw-webhook-fn' has no dead-letter queue (DLQ) configured. CC7.1 detection-procedure gap: failed invocations are silently dropped after retries instead of routed to an inspection surface. Configure DeadLetterConfig.TargetArn to an SNS topic or SQS queue.

Source: aws-lambda-auditor

CC7.1 detection procedures require failure-event-capture substrate. AWS Lambda dead-letter queues (DeadLetterConfig.TargetArn pointing to SNS or SQS) are the AWS-native capture surface for invocation failures that exceed Lambda's automatic retry budget. Without a DLQ, failed asynchronous invocations are silently dropped — the failure event leaves no inspection surface for post-incident forensics or anomaly detection. Plugin 1080 emits LOW per function without DLQ. Anchored regex defeats cross-mapping pollution. EE-RT.5 (v0.4.0).

Lambda function 'nw-checkout-fn' does not have X-Ray active tracing enabled (TracingConfig.Mode=PassThrough). CC7.1 detection-procedure gap: distributed-trace evidence missing for this function's invocation graph. Enable via TracingConfig.Mode=Active.

Source: aws-lambda-auditor

CC7.1 detection procedures require distributed-trace substrate on every workload tier. AWS X-Ray active tracing for Lambda (TracingConfig.Mode=Active) is the AWS-native detection-procedure surface for invocation-graph visibility (which caller invoked which function, traversal patterns, anomalous request signatures). Functions without active tracing are detection-procedure dark spots — anomalous invocation patterns leave no trace beyond CloudWatch metrics aggregates. Plugin 1080 emits LOW per untraced function. Anchored regex defeats cross-mapping pollution. EE-RT.5 (v0.4.0).

Lambda function 'nw-checkout-fn' has no dead-letter queue (DLQ) configured. CC7.1 detection-procedure gap: failed invocations are silently dropped after retries instead of routed to an inspection surface. Configure DeadLetterConfig.TargetArn to an SNS topic or SQS queue.

Source: aws-lambda-auditor

SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/nw-order-events' has NO RedrivePolicy configured (no dead-letter queue). A1.2 availability + CC7.1 anomaly-detection gap: messages that fail processing repeatedly are silently dropped after maxReceiveCount retries with no DLQ to capture them — silent message loss with no anomaly signal. Configure a DLQ via SetQueueAttributes RedrivePolicy={"deadLetterTargetArn":"<arn>","maxReceiveCount":<N>}.

Source: aws-sqs-sns-auditor

CC7.1 anomaly-detection gap MEDIUM — added in EE-RT.15 v1 (EE 0.4.4); dual-mapped with A1.2. SQS queues without a RedrivePolicy/DLQ have no anomaly signal when message processing fails repeatedly — failed messages are silently dropped after maxReceiveCount with no detection-procedure surface. The DLQ IS the AWS-canonical anomaly-detection substrate for async message-processing failures. Plugin 1150 emits MEDIUM per queue. EE-RT.15 v1.

SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/sqs-encrypted-queue' has NO RedrivePolicy configured (no dead-letter queue). A1.2 availability + CC7.1 anomaly-detection gap: messages that fail processing repeatedly are silently dropped after maxReceiveCount retries with no DLQ to capture them — silent message loss with no anomaly signal. Configure a DLQ via SetQueueAttributes RedrivePolicy={"deadLetterTargetArn":"<arn>","maxReceiveCount":<N>}.

Source: aws-sqs-sns-auditor

AWS GuardDuty is NOT ENABLED in region 'ap-south-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

CC7.1 detection-procedure absence HIGH — added in EE-RT.20 v1 (EE 0.6.1). AWS GuardDuty is the AWS-native managed threat-detection substrate (continuous monitoring of VPC Flow Logs, CloudTrail management + S3 data events, DNS logs) and the canonical institutional detection-procedure surface for compromised credentials, instance-level malicious activity, S3 reconnaissance, and Kubernetes audit-log anomalies. A region without a GuardDuty Detector has ZERO managed-detection coverage — equivalent to running production workloads with no IDS at all. Plugin 1200 emits HIGH per region without an enabled Detector. EE-RT.20 v1. **EE-RT.20 R1-CRITICAL-1 fold**: titlePattern anchored to actual plugin emission string (was `^GuardDuty NOT enabled`, never matched).

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-south-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

CC7.1 evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.

AWS GuardDuty is NOT ENABLED in region 'eu-north-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'eu-north-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'eu-west-3' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'eu-west-3') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'eu-west-2' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'eu-west-2') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'eu-west-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'eu-west-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'ap-northeast-3' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-northeast-3') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'ap-northeast-2' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-northeast-2') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'ap-northeast-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-northeast-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'ca-central-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ca-central-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'sa-east-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'sa-east-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'ap-southeast-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-southeast-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'ap-southeast-2' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-southeast-2') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'eu-central-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'eu-central-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'us-east-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'us-east-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'us-east-2' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'us-east-2') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'us-west-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'us-west-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

AWS GuardDuty is NOT ENABLED in region 'us-west-2' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.

Source: aws-inspector-guardduty-auditor

EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'us-west-2') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.

Source: aws-inspector-guardduty-auditor

CC7.2 — Monitoring of system components and operation for anomalies FAIL

Category: Common Criteria · System Operations · Violations: 43

Source: aws-cloudtrail-auditor

CC7.2 -- CloudTrail/CloudWatch evidence is INCOMPLETE: plugin 1040 aborted at its soft budget (scan-time-budget-exceeded) before finishing the audit, so this control's CloudTrail-derived evidence was not collected. Fails-closed (no silent PASS over an un-audited control surface) per the conservative-classifier principle and consistent with the 1020/1021/1025 evidence-gap convention. Resolve by raising CLOUD_PLUGIN_TIMEOUT_MS / NSA_CT_SOFT_BUDGET_MS or scoping to a single region (NSA_CT_MAX_REGIONS / multiRegionScan=false), then re-run. EE 0.16.5 false-clean fix.

Trail destination bucket northwind-orgtrail-logs has Object Lock enabled but NO DefaultRetention rule — the bucket is "Object-Lock-able" but no retention is auto-applied. Auditors expect a default retention rule on trail buckets.

Source: aws-cloudtrail-auditor

CC7.2 monitoring-substrate INTEGRITY — the trail's destination bucket is the storage layer for the monitoring substrate. A trail with log-file-validation enabled but a bucket WITHOUT Object Lock is still tamper-able because the BUCKET itself is mutable (delete-marker → permanent-delete bypass). Plugin 040 (EE-RT.1.4) audits the trail bucket distinctly because monitoring substrate integrity requires both cryptographic integrity (log-file-validation) AND storage immutability (Object Lock COMPLIANCE + MFADelete). EE-RT.1.4.

Trail destination bucket northwind-orgtrail-logs has MFA Delete NOT enabled. Without MFA Delete, any IAM principal with s3:DeleteBucket / s3:DeleteObject can permanently delete trail logs via delete-marker → permanent-delete bypass. For trail buckets (institutional-grade evidence storage), MFA Delete is mandatory.

Source: aws-cloudtrail-auditor

Trail destination bucket northwind-trail-logs has NO Object Lock configuration. SEC Rule 17a-4 / FINRA 4511 require WORM storage for audit logs. Enable Object Lock + COMPLIANCE mode + retention.

Source: aws-cloudtrail-auditor

Trail destination bucket northwind-trail-logs has Versioning Disabled — Object Lock REQUIRES Versioning. Without it, retention rules cannot be enforced.

Source: aws-cloudtrail-auditor

Trail northwind-trail is not multi-region (IsMultiRegionTrail=false)

Source: aws-cloudtrail-auditor

CC7.2 expects monitoring of ALL system components. A single-region trail blinds the auditor to out-of-region API activity — attacker-pivoted regions go unmonitored. AWS CIS Foundations Benchmark 3.0 and SOC 2 institutional guidance both require IsMultiRegionTrail=true. EE-RT.1.

Trail northwind-trail does not log data events (S3 object-level / Lambda invocation)

Source: aws-cloudtrail-auditor

CC7.2 expects monitoring at the resource-access layer. Without S3 data events / Lambda invocation events, the auditor sees no object-level access evidence — exfiltration via GetObject is invisible. EE-RT.1.

CloudWatch alarm missing: Unauthorized API calls (CIS AWS Foundations Benchmark cis-3.1). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CC7.2 expects monitoring of anomalies via active alerting. CIS AWS Foundations Benchmark 1.5 §3.1–3.14 enumerates the canonical 14 alarm classes (Unauthorized API, Root account usage, IAM policy changes, CloudTrail config changes, S3 bucket policy changes, security group changes, etc.). One finding per missing CIS class; auditor matches alarm coverage to the institutional baseline. **Evidence method disclosure (EE-RT.1 v1)**: alarm coverage is currently inferred from a synthetic filter built from alarm name + metric name + alarm description (substring match against CIS hint keywords). The auditor-canonical evidence is the CloudWatch Logs MetricFilter pattern (logs:DescribeMetricFilters); v2 of this rule (EE-RT.1.1) will use that directly. For Type-II audits, cross-check missing-alarm findings with `aws logs describe-metric-filters` per CloudTrail LogGroup. **Coverage mode**: cis-3.3 / 3.6 use any-hint matching (synonymous phrasings); cis-3.4 / 3.5 / 3.7 / 3.8 / 3.9 / 3.10 – 3.14 use majority matching (≥ ⌈N/2⌉ distinct hints required) to prevent single-action alarms from falsely marking the entire class covered. EE-RT.1.

CloudWatch alarm missing: Management Console sign-in without MFA (CIS AWS Foundations Benchmark cis-3.2). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: Root account usage (CIS AWS Foundations Benchmark cis-3.3). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: IAM policy changes (CIS AWS Foundations Benchmark cis-3.4). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: Management Console authentication failures (CIS AWS Foundations Benchmark cis-3.6). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: Disabling or scheduled deletion of customer-created CMKs (CIS AWS Foundations Benchmark cis-3.7). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: S3 bucket policy changes (CIS AWS Foundations Benchmark cis-3.8). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: AWS Config configuration changes (CIS AWS Foundations Benchmark cis-3.9). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: Security group changes (CIS AWS Foundations Benchmark cis-3.10). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: Network ACL changes (CIS AWS Foundations Benchmark cis-3.11). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: Network gateway changes (CIS AWS Foundations Benchmark cis-3.12). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: Route table changes (CIS AWS Foundations Benchmark cis-3.13). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

CloudWatch alarm missing: VPC changes (CIS AWS Foundations Benchmark cis-3.14). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).

Source: aws-cloudtrail-auditor

RDS DB instance 'northwind-orders-db' (postgres) has pgAudit DISABLED (pgaudit.log parameter is '<empty>'). CC7.2 + CC7.3 monitoring gap: no database-level activity log is captured — DDL changes, privileged role changes, and DML on sensitive tables go unaudited. Configure via DescribeDBParameterGroup + ModifyDBParameterGroup: set pgaudit.log to a comma-separated subset of 'ddl,role,write' (read can be added selectively for compliance tables) and add 'pgaudit' to shared_preload_libraries.

Source: aws-rds-auditor

CC7.2 + CC7.3 database-activity monitoring gap HIGH — added in EE-RT.14 v3 (EE 0.4.8). AWS RDS Postgres instance has pgAudit disabled (pgaudit.log parameter is unset, empty, or 'none'). No database-level activity audit trail: DDL changes, role / privilege grants, and DML on sensitive tables go unaudited at the database layer. Plugin 1140 v3 emits HIGH per postgres instance with pgaudit disabled. Remediate via ModifyDBParameterGroup: set pgaudit.log to a comma-separated subset of 'ddl,role,write' + add 'pgaudit' to shared_preload_libraries.

RDS DB instance 'northwind-orders-db' (postgres) has NO CloudWatch Logs exports configured (EnabledCloudwatchLogsExports=[]). CC7.2 monitoring gap: no database activity logs reach CloudWatch for centralized anomaly detection / alerting / long-term retention. Expected for this engine: essential=[postgresql] + optional=[upgrade]. Configure via ModifyDBInstance --cloudwatch-logs-export-configuration.

Source: aws-rds-auditor

CC7.2 monitoring gap HIGH — added in EE-RT.14 v3 (EE 0.4.8). AWS RDS instance has no CloudWatch Logs exports — database activity logs do not reach CloudWatch for centralized anomaly detection / alerting / long-term retention. Plugin 1140 v3 emits HIGH per instance with EnabledCloudwatchLogsExports=[]. Engine-dispatched: essential log types vary (postgres: postgresql; mysql/mariadb: error; oracle: audit+trace; sqlserver: error). Remediate via ModifyDBInstance --cloudwatch-logs-export-configuration.

SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/nw-order-events' (queueName='nw-order-events') has NO CloudWatch MetricAlarm on AWS/SQS:ApproximateAgeOfOldestMessage with QueueName='nw-order-events'. CC7.2 system-monitoring + A1.2 availability gap: consumer backlog growth (failed processing, slow consumers, downstream outages) produces no operator paging — silent service-degradation class. Configure a MetricAlarm with Namespace=AWS/SQS, MetricName=ApproximateAgeOfOldestMessage, Dimensions=[{Name:QueueName,Value:'nw-order-events'}], a Threshold matching your SLO, ActionsEnabled=true, and an AlarmActions ARN routing to SNS / PagerDuty / etc.

Source: aws-sqs-sns-auditor

CC7.2 system-monitoring + A1.2 availability gap MEDIUM — added in EE-RT.15 v2 (EE 0.5.1); dual-mapped with A1.2. SQS queue with no CloudWatch MetricAlarm on AWS/SQS:ApproximateAgeOfOldestMessage with the queue's QueueName dimension. Consumer backlog growth (failed processing, slow consumers, downstream outages) produces NO operator paging — silent service-degradation class. Per the operator monitoring runbook 'Messaging Monitoring' (SOC 2 institutional baseline). Plugin 1150 v2 emits MEDIUM per queue. Remediate via cloudwatch:PutMetricAlarm Namespace=AWS/SQS, MetricName=ApproximateAgeOfOldestMessage, Dimensions=[{Name:QueueName,Value:<name>}], ActionsEnabled=true, populated AlarmActions ARN list.

SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/sqs-encrypted-queue' (queueName='sqs-encrypted-queue') has NO CloudWatch MetricAlarm on AWS/SQS:ApproximateAgeOfOldestMessage with QueueName='sqs-encrypted-queue'. CC7.2 system-monitoring + A1.2 availability gap: consumer backlog growth (failed processing, slow consumers, downstream outages) produces no operator paging — silent service-degradation class. Configure a MetricAlarm with Namespace=AWS/SQS, MetricName=ApproximateAgeOfOldestMessage, Dimensions=[{Name:QueueName,Value:'sqs-encrypted-queue'}], a Threshold matching your SLO, ActionsEnabled=true, and an AlarmActions ARN routing to SNS / PagerDuty / etc.

Source: aws-sqs-sns-auditor

SNS topic 'arn:aws:sns:us-east-1:123456789012:nw-notifications' (topicName='nw-notifications') has NO CloudWatch MetricAlarm on AWS/SNS:NumberOfNotificationsFailed with TopicName='nw-notifications'. CC7.2 + A1.2 gap: subscription delivery failures (HTTPS endpoint timeouts, Lambda invocation errors, SQS DLQ exhaustion on SNS→SQS fan-out, mobile push errors) produce NO operator paging — silent message-loss class for downstream subscribers. Configure a MetricAlarm with Namespace=AWS/SNS, MetricName=NumberOfNotificationsFailed, Dimensions=[{Name:TopicName,Value:'nw-notifications'}], a Threshold matching your error-rate SLO, ActionsEnabled=true, and routed AlarmActions.

Source: aws-sqs-sns-auditor

CC7.2 system-monitoring + A1.2 availability gap MEDIUM — added in EE-RT.15 v2 (EE 0.5.1); dual-mapped with A1.2. SNS topic with no CloudWatch MetricAlarm on AWS/SNS:NumberOfNotificationsFailed with the topic's TopicName dimension. Subscription delivery failures (HTTPS endpoint timeouts, Lambda invocation errors, SQS DLQ exhaustion on SNS→SQS fan-out, mobile push errors) produce NO operator paging — silent message-loss class for downstream subscribers. Per the operator monitoring runbook 'Messaging Monitoring'. Plugin 1150 v2 emits MEDIUM per topic. Remediate via cloudwatch:PutMetricAlarm Namespace=AWS/SNS, MetricName=NumberOfNotificationsFailed, Dimensions=[{Name:TopicName,Value:<name>}], ActionsEnabled=true.

SNS topic 'arn:aws:sns:us-east-1:123456789012:sns-encrypted-topic' (topicName='sns-encrypted-topic') has NO CloudWatch MetricAlarm on AWS/SNS:NumberOfNotificationsFailed with TopicName='sns-encrypted-topic'. CC7.2 + A1.2 gap: subscription delivery failures (HTTPS endpoint timeouts, Lambda invocation errors, SQS DLQ exhaustion on SNS→SQS fan-out, mobile push errors) produce NO operator paging — silent message-loss class for downstream subscribers. Configure a MetricAlarm with Namespace=AWS/SNS, MetricName=NumberOfNotificationsFailed, Dimensions=[{Name:TopicName,Value:'sns-encrypted-topic'}], a Threshold matching your error-rate SLO, ActionsEnabled=true, and routed AlarmActions.

Source: aws-sqs-sns-auditor

Source: aws-inspector-guardduty-auditor

CC7.2 evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.

Source: aws-inspector-guardduty-auditor

CC7.3 — Evaluation of security events to determine response FAIL

Category: Common Criteria · System Operations · Violations: 15

Source: aws-cloudtrail-auditor

CC7.3 -- CloudTrail/CloudWatch evidence is INCOMPLETE: plugin 1040 aborted at its soft budget (scan-time-budget-exceeded) before finishing the audit, so this control's CloudTrail-derived evidence was not collected. Fails-closed (no silent PASS over an un-audited control surface) per the conservative-classifier principle and consistent with the 1020/1021/1025 evidence-gap convention. Resolve by raising CLOUD_PLUGIN_TIMEOUT_MS / NSA_CT_SOFT_BUDGET_MS or scoping to a single region (NSA_CT_MAX_REGIONS / multiRegionScan=false), then re-run. EE 0.16.5 false-clean fix.

Trail northwind-trail has log file validation disabled (LogFileValidationEnabled=false)

Source: aws-cloudtrail-auditor

CC7.3 evaluation requires trustworthy evidence. Without log file validation, the auditor cannot verify post-incident that the events used in the evaluation were unmodified — the evaluation rests on potentially-tampered evidence. EE-RT.1.

Source: aws-cloudtrail-auditor

CC7.3 requires evaluation of security events to determine incident response. CloudWatch alarms are the AWS-canonical evaluation-and-routing primitive: they convert raw CloudTrail events into actionable signals routed to SNS topics, PagerDuty, etc. Missing alarms means no automated evaluation path — security events accumulate in CloudTrail without triggering response procedures. CIS §3.1–3.14 enumerates the canonical alarm classes. EE-RT.1.

Source: aws-cloudtrail-auditor

C1.1 — Identification and disposition of confidential information FAIL

Category: Confidentiality · Violations: 45

Server-side encryption uses AES256 (not KMS-CMK)

Source: aws-s3-auditor

C1.1 requires confidentiality controls over confidential data. AES256 (AWS-managed key) encrypts at rest but the customer cannot rotate, audit, or revoke the key. Customer-managed KMS (KMS-CMK) is the institutional default for confidential workloads — gives the customer control over key access policy, rotation cadence, and crypto-shredding capability. Severity escalates from LOW to MEDIUM when bucket name matches AWS_S3_AUDIT_CONFIDENTIAL_BUCKETS (EE-0.3.2.4).

Server-side encryption uses AES256 (not KMS-CMK)

Source: aws-s3-auditor

Server-side encryption uses AES256 (not KMS-CMK)

Source: aws-s3-auditor

Partial public access block – missing: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets

Source: aws-s3-auditor

C1.1 requires a complete confidentiality boundary at the storage layer; a partial Public Access Block leaves at least one bypass route (BlockPublicAcls / IgnorePublicAcls / BlockPublicPolicy / RestrictPublicBuckets) — auditors expect all four enabled for confidential workloads.

Bucket policy grants public access

Source: aws-s3-auditor

C1.1 requires confidentiality boundary at the storage layer; permissive bucket policy violates this.

Object ACL grants public access (AllUsers) on 2 of 7 sampled objects – objects publicly accessible

Source: aws-s3-auditor

C1.1 requires confidential data not be exposed; public-readable S3 buckets violate confidentiality boundary.

Object ACL grants public access (AllUsers) on 1 of 1 sampled non-current versions – objects publicly accessible

Source: aws-s3-auditor

C1.1 requires confidential data not be exposed; public-readable S3 buckets violate confidentiality boundary.

Server-side encryption uses AES256 (not KMS-CMK)

Source: aws-s3-auditor

DynamoDB table 'northwind-inventory' uses KMS encryption but the returned KMSMasterKeyArn is a :key/UUID form, not an alias — cannot determine AWS-managed vs customer-managed from the SSE response alone. Verify via 'aws kms describe-key --key-id arn:aws:kms:us-east-1:123456789012:key/0a1b2c3d-4e5f-4a1b-8c2d-000000000007' and check KeyManager (AWS = AWS-managed; CUSTOMER = customer-managed-CMK / PASS). EE-RT.3 v1 added automated kms:DescribeKey cross-reference; if this finding still emits, KMS SDK was unavailable OR caller did not provide kmsClient OR kms:DescribeKey returned AccessDenied / NotFoundException.

Source: aws-dynamodb-auditor

C1.1 class-O evidence-gap (at-rest fleet sweep 2026-06-22) — DynamoDB reports KMS encryption but the KMSMasterKeyArn cannot be classified AWS-managed vs customer-managed from the SSE response alone, so at-rest key-custody is UNVERIFIED. Previously routed to ZERO controls (a live false-clean — an unclassifiable-custody table read CLEAN everywhere); now fails-close == the AWS-owned-default-encryption positive's floor (soc2 C1.1 + hipaa). details.evidenceGap. Plugin 1060. (Cross-framework key-custody scope deferred to the fleet doctrine plan.)

DynamoDB table 'northwind-sessions' has neither Point-in-Time Recovery (PITR) NOR deletion protection enabled — a single DeleteTable API call can vaporize the table AND no continuous backup exists to recover. Worst-case audit-the-auditor failure: the audit record itself is not survivable. Enable both (PI1 + C1.1).

Source: aws-dynamodb-auditor

C1.1 worst case: confidentiality preservation requires BOTH a recoverability mechanism (PITR) and a tamper-resistance mechanism (deletion protection). A table without either is equivalent to a single-write-then-vaporize permission boundary — the canonical audit-the-auditor failure mode. Plugin 060 emits CRITICAL when both are absent. EE-RT.2 (v0.4.0).

DynamoDB table 'northwind-sessions' uses AWS-owned default encryption (no SSEDescription or SSEType=AES256). Customer has no key custody; AWS-owned keys cannot be disabled, audited, or rotated by the customer. Auditors require KMS-CMK (customer-managed key) for audit-store tables (C1.1 key-custody requirement).

Source: aws-dynamodb-auditor

C1.1 requires confidentiality controls over confidential data. AWS DynamoDB tables with default `AES256` server-side encryption use an AWS-owned key — the customer cannot rotate, audit, or revoke. For audit-store tables (payroll-runs, employees, checks, invoices) holding confidential data, auditors require customer-managed KMS-CMK so the customer retains key custody and crypto-shred capability. Plugin 060 emits HIGH on `table-sse-default-key`. EE-RT.2 (v0.4.0).

KMS key '0a1b2c3d-4e5f-4a1b-8c2d-000000000001' policy grants Principal: AWS: "*" on 5 sensitive action(s) [kms:CreateGrant, kms:Decrypt, kms:Encrypt, kms:GenerateDataKey*, kms:ReEncrypt*] WITH Condition (AWS-managed CMK template — service-scoped by AWS; demoted to INFO per EE-RT.1.5.x.5; auditor walkthrough confirms by-design). C1.1 boundary evaluated; AWS-managed template — no operator-actionable gap (INFO surfacing for evidence-pack completeness).

Source: aws-kms-auditor

C1.1 INFO substrate evidence (EE-RT.1.5.x.5, EE 0.4.2) — plugin 1070 emission category `key-policy-wildcard-sensitive-conditional-aws-managed-demoted`. AWS-managed CMK aliases (`alias/aws/*`) have AWS-controlled key policies with intentional service-scoping Conditions (`kms:ViaService`, `kms:CallerAccount`); customers cannot modify them. Pre-fold this emitted MEDIUM, which overclaimed (auditor walkthrough always confirms by-design AWS templates). Demoted to INFO per the noise-demotion fold; substrate IS evaluated and recorded for evidence-pack completeness, but no operator-actionable gap. The 4-tier classifier preserves HIGH on unconditional wildcards (real anomaly) and MEDIUM on CUSTOMER-managed conditional (auditor must verify operator-controlled Condition scope). Conservative-classifier discipline: positive-observation gate — null `keyManager` (DescribeKey failure) retains MEDIUM.

KMS key '0a1b2c3d-4e5f-4a1b-8c2d-000000000002' policy grants Principal: AWS: "*" on 5 sensitive action(s) [kms:CreateGrant, kms:Decrypt, kms:Encrypt, kms:GenerateDataKey*, kms:ReEncrypt*] WITH Condition (AWS-managed CMK template — service-scoped by AWS; demoted to INFO per EE-RT.1.5.x.5; auditor walkthrough confirms by-design). C1.1 boundary evaluated; AWS-managed template — no operator-actionable gap (INFO surfacing for evidence-pack completeness).

Source: aws-kms-auditor

KMS key '0a1b2c3d-4e5f-4a1b-8c2d-000000000003' policy grants Principal: AWS: "*" on 1 sensitive action(s) [kms:Decrypt] WITHOUT Condition (any authenticated AWS principal can perform these confidentiality-boundary-crossing actions). C1.1 confidentiality-boundary risk.

Source: aws-kms-auditor

C1.1 confidentiality boundary on cryptographic actions — HIGH (unconditional) or MEDIUM (with Condition, customer-managed). KMS key policy with `Principal: AWS: "*"` on sensitive actions (kms:Decrypt / kms:Encrypt / kms:GenerateDataKey* / kms:ReEncrypt* / kms:CreateGrant / kms:ScheduleKeyDeletion / kms:PutKeyPolicy / etc.) grants any authenticated AWS principal the ability to perform confidentiality-boundary-crossing operations on the key. Plugin 1070 emits one finding per affected key with the sensitive-action count. EE-RT.3 (v0.4.0). Anchored regex requires the `C1.1 confidentiality-boundary risk` trailer (HIGH/MEDIUM tiers only) so this rule does NOT match the demoted AWS-managed INFO emission below (which uses the `C1.1 boundary evaluated; AWS-managed template` trailer instead).

KMS key '0a1b2c3d-4e5f-4a1b-8c2d-000000000005' policy grants Principal: AWS: "*" on 5 sensitive action(s) [kms:CreateGrant, kms:Decrypt, kms:Encrypt, kms:GenerateDataKey*, kms:ReEncrypt*] WITH Condition (AWS-managed CMK template — service-scoped by AWS; demoted to INFO per EE-RT.1.5.x.5; auditor walkthrough confirms by-design). C1.1 boundary evaluated; AWS-managed template — no operator-actionable gap (INFO surfacing for evidence-pack completeness).

Source: aws-kms-auditor

KMS key '0a1b2c3d-4e5f-4a1b-8c2d-000000000006' policy grants Principal: AWS: "*" on 5 sensitive action(s) [kms:CreateGrant, kms:Decrypt, kms:Encrypt, kms:GenerateDataKey*, kms:ReEncrypt*] WITH Condition (AWS-managed CMK template — service-scoped by AWS; demoted to INFO per EE-RT.1.5.x.5; auditor walkthrough confirms by-design). C1.1 boundary evaluated; AWS-managed template — no operator-actionable gap (INFO surfacing for evidence-pack completeness).

Source: aws-kms-auditor

Lambda function 'nw-checkout-fn' has 3 environment variable(s) with secret-suggestive name(s) [API_KEY, DB_PASSWORD, SECRET_TOKEN]. C1.1 confidentiality risk: hardcoded secrets in environment variables are visible to anyone with lambda:GetFunctionConfiguration permission. Migrate to AWS Secrets Manager or Parameter Store (with KMS-CMK encryption + IAM-restricted access). Scanner inspects only env-var NAMES (ZDE-safe — values never read).

Source: aws-lambda-auditor

C1.1 confidentiality boundary on plaintext secrets. AWS Lambda environment variables are visible to any principal with `lambda:GetFunctionConfiguration` permission — the canonical hardcoded-secret risk surface for serverless workloads. Plugin 1080 detects suspicious KEY NAMES (matching key/secret/token/password/credential patterns); ZDE-safe — the scanner NEVER reads the env-var VALUE. The MEDIUM severity reflects that env-var names are heuristic evidence (some may be benign config flags), but every match warrants auditor verification that the secret was migrated to AWS Secrets Manager / SSM Parameter Store with KMS-CMK encryption. EE-RT.5 (v0.4.0); anchored regex defeats cross-mapping pollution.

SSM Parameter '/northwind/prod/legacy-api-key' is Type: String (plaintext) but the parameter NAME suggests it stores a secret. C1.1 confidentiality-boundary violation: any principal with ssm:GetParameter / ssm:GetParameters / ssm:GetParametersByPath can read the value in cleartext, without KMS decryption authorization. Migrate to Type: SecureString with a customer-managed KMS key. Scanner inspects only parameter NAMES (ZDE-safe — VALUES never read).

Source: aws-secrets-auditor

C1.1 confidentiality boundary on plaintext secrets — the SSM Parameter Store substrate. AWS SSM Parameter Store Type: String / StringList parameters store values in plaintext (no encryption at rest); any principal with ssm:GetParameter / ssm:GetParameters / ssm:GetParametersByPath can read the value without KMS decryption authorization. Plugin 1090 detects parameters with secret-suggestive NAMES on plaintext types; ZDE-safe — the scanner NEVER calls GetParameter / GetParameterValue, only DescribeParameters which returns metadata only. HIGH severity reflects the direct C1.1 violation class (parallel to plugin 1080's Lambda env-var detection, but on a substrate that lacks any encryption-at-rest mechanism). Migrate to Type: SecureString with a customer-managed KMS key. EE-RT.8 (v0.4.0); anchored regex defeats cross-mapping pollution.

RDS DB instance 'northwind-analytics-cluster' uses AWS-managed KMS key (arn:aws:kms:us-east-1:123456789012:key/0a1b2c3d-4e5f-4a1b-8c2d-000000000002) — promoted from UNVERIFIABLE LOW via kms:DescribeKey cross-reference (KeyManager=AWS). C1.1 confidentiality is in effect but key custody lives in the AWS-managed key pool rather than the customer's KMS keyring — not customer-rotatable / not customer-revocable. Prefer customer-managed CMK via snapshot-restore-with-KmsKeyId for production-tier databases.

Source: aws-rds-auditor

C1.1 substrate evidence MEDIUM — added in EE-RT.14 v2 (EE 0.4.5). KMS-DescribeKey cross-reference promoted UNVERIFIABLE :key/UUID ARN form to deterministic AWS-managed classification (KeyManager=AWS field). Storage IS encrypted but key custody lives in the AWS-managed key pool. Plugin 1140 emits MEDIUM with promotedFromUnverifiable:true flag. Anchored regex requires the `promoted from UNVERIFIABLE LOW` clause so this rule does NOT match the v1 alias-form MEDIUM emission.

RDS DB instance 'northwind-orders-db' has storage encryption DISABLED (StorageEncrypted=false). C1.1 confidentiality gap: underlying EBS volume, automated snapshots, and read-replicas all unencrypted; no crypto-shred capability. Storage encryption cannot be enabled in-place — requires snapshot + restore-to-new-instance with KmsKeyId set.

Source: aws-rds-auditor

C1.1 confidentiality gap — added in EE-RT.14 v1 (EE 0.4.3). AWS RDS DB instance with StorageEncrypted=false has the underlying EBS volume, automated snapshots, AND read-replicas all unencrypted; no crypto-shred capability (deleting the KmsKeyId does NOT render data unreadable because there is no KmsKeyId). Storage encryption cannot be enabled in-place — requires snapshot + restore-to-new-instance with KmsKeyId set, which has DR-window implications. Plugin 1140 emits HIGH per unencrypted instance. EE-RT.14 v1.

SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/nw-order-events' has encryption-at-rest DISABLED (SqsManagedSseEnabled=false AND no KmsMasterKeyId set). C1.1 confidentiality gap: queue message bodies are stored on Amazon's SQS service infrastructure in cleartext (subject to Amazon employee operational access per the AWS shared-responsibility model). Enable SqsManagedSseEnabled=true (AWS-managed) OR set KmsMasterKeyId to a customer-managed CMK alias (customer key custody).

Source: aws-sqs-sns-auditor

C1.1 confidentiality gap HIGH — added in EE-RT.15 v1 (EE 0.4.4). AWS SQS queue with neither SqsManagedSseEnabled=true nor a KmsMasterKeyId set stores message bodies on Amazon's SQS service infrastructure in cleartext (subject to Amazon employee operational access per the AWS shared-responsibility model). Enable SqsManagedSseEnabled=true (AWS-managed) OR set KmsMasterKeyId to a customer-managed CMK alias for institutional-grade key custody. Plugin 1150 emits HIGH per unencrypted queue.

SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/sqs-encrypted-queue' uses AWS-managed KMS key (alias/aws/sqs). C1.1 confidentiality is in effect but key custody lives in the AWS-managed key pool — not customer-rotatable / not customer-revocable. For production-tier confidential workloads, prefer customer-managed CMK.

Source: aws-sqs-sns-auditor

C1.1 substrate evidence MEDIUM — added in EE-RT.15 v1 (EE 0.4.4). AWS-managed KMS key (alias/aws/sqs) encrypts at rest but key custody lives in the AWS-managed key pool — not customer-rotatable / not customer-revocable. Prefer customer-managed CMK for production-tier workloads. Plugin 1150 emits MEDIUM.

SNS topic 'arn:aws:sns:us-east-1:123456789012:nw-notifications' has encryption-at-rest DISABLED (no KmsMasterKeyId set). C1.1 confidentiality gap: published messages are stored on Amazon's SNS service infrastructure in cleartext until delivery. SNS has no SQS-managed-SSE equivalent — the ONLY at-rest encryption mechanism is a customer-set KmsMasterKeyId. Enable via SetTopicAttributes KmsMasterKeyId=<alias/aws/sns or CMK alias>.

Source: aws-sqs-sns-auditor

C1.1 confidentiality gap HIGH — added in EE-RT.15 v1 (EE 0.4.4). AWS SNS topic with no KmsMasterKeyId set has NO encryption at rest — published messages are stored on Amazon's SNS service infrastructure in cleartext until delivery. SNS has no SQS-managed-SSE equivalent; KmsMasterKeyId is the ONLY at-rest encryption mechanism. Plugin 1150 emits HIGH per unencrypted topic. Enable via SetTopicAttributes KmsMasterKeyId=<alias/aws/sns or customer CMK alias>.

SNS topic 'arn:aws:sns:us-east-1:123456789012:sns-encrypted-topic' uses AWS-managed KMS key (alias/aws/sns). C1.1 confidentiality is in effect but key custody is AWS-managed — not customer-rotatable / not customer-revocable. For production-tier confidential topics, prefer customer-managed CMK.

Source: aws-sqs-sns-auditor

C1.1 substrate evidence MEDIUM — added in EE-RT.15 v1 (EE 0.4.4). SNS AWS-managed alias (alias/aws/sns) encrypts at rest but key custody is AWS-managed — not customer-rotatable / not customer-revocable. Prefer customer-managed CMK for production-tier confidential topics. Plugin 1150 emits MEDIUM.

EC2 account default EBS encryption is DISABLED in ap-south-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

C1.1 PREVENTIVE confidentiality gap — added in EE 0.13.1 (plugin 1210, false-negative-lens R-MED-3 fold). GetEbsEncryptionByDefault=false (per region) means any volume/instance launched without an explicit Encrypted=true is created UNENCRYPTED — even if every current volume is encrypted. CIS AWS Foundations Benchmark 2.2.1 analog. Detective-vs-preventive: this is the preventive-posture control (future-launch default), distinct from the per-volume detective finding above. Plugin 1210 emits MEDIUM per region with default-encryption disabled. Inherits into CIS Safeguard 3.11 per the inheritance contract.

EC2 account default EBS encryption is DISABLED in eu-north-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in eu-west-3 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in eu-west-2 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in eu-west-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in ap-northeast-3 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in ap-northeast-2 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in ap-northeast-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in ca-central-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in sa-east-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in ap-southeast-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in ap-southeast-2 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in eu-central-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EBS volume 'vol-0abcdef0100000014' attached to instance 'i-0a1b2c3d4e5f60718' has encryption DISABLED (Encrypted=false). C1.1 confidentiality gap: volume data at rest is stored unencrypted; without encryption there is no crypto-shred capability on decommission. Remediate by recreating the volume from an encrypted snapshot (default EBS encryption recommended account-wide).

Source: aws-ec2-instance-auditor

C1.1 confidentiality gap — added in EE 0.13.1 (Move B-1.3, plugin 1210). EC2 instance with an attached EBS volume where Encrypted=false stores block-device data at rest unencrypted; no crypto-shred capability on decommission. Cannot be enabled in-place — requires snapshot + recreate-from-encrypted-snapshot (default EBS encryption recommended account-wide). Anchored on the AWS field name (Encrypted=false) per [[soc2_titlepattern_anchor_drift]]. Plugin 1210 emits HIGH per unencrypted attached volume. Maps identically into CIS Safeguard 3.11 (Encrypt Sensitive Data at Rest) per the inheritance contract. NOTE: single-scan substrate evidence of CURRENT at-rest-encryption state — continuous-period operating-effectiveness requires recurring-attestation cadence (EE-SOC2.9), not one clean scan; and encryption-at-rest is necessary-not-sufficient (an encrypted volume's confidentiality is bounded by who can kms:Decrypt its CMK — cross-reference plugin 1110 effective-decrypt analysis).

EC2 account default EBS encryption is DISABLED in us-east-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in us-east-2 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in us-west-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

EC2 account default EBS encryption is DISABLED in us-west-2 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.

Source: aws-ec2-instance-auditor

ElastiCache Redis replication-group 'nw-product-cache' has at-rest encryption enabled but no operator-supplied KmsKeyId — AWS-owned default key in effect. C1.1 confidentiality is in effect but key custody is fully AWS-owned (not even auditable via CloudTrail kms:Decrypt). Prefer customer-managed CMK alias for institutional-grade evidence.

Source: aws-elasticache-redis-auditor

C1.1 substrate evidence MEDIUM — added in EE-RT.17 v1 (EE 0.4.6). At-rest encryption enabled with AWS-owned default key (not even auditable via CloudTrail kms:Decrypt). Prefer customer-managed CMK alias for institutional-grade evidence. Plugin 1180 emits MEDIUM.

ElastiCache Redis cache-cluster 'nw-session-cache' has transit encryption DISABLED (TransitEncryptionEnabled=false). C1.1 transit-encryption gap: client connections + inter-node replication flow over the network in cleartext. Redis client credentials (AUTH tokens) AND cache contents transit unprotected. Enable via in-place migration (Redis 7+ supports TransitEncryptionMode='preferred' for zero-downtime rollout); older engines require recreate-with-encryption + data migration.

Source: aws-elasticache-redis-auditor

C1.1 transit-encryption gap HIGH — added in EE-RT.17 v1 (EE 0.4.6). ElastiCache Redis client connections + inter-node replication flow over the network in cleartext. Redis client credentials (AUTH tokens) AND cache contents transit unprotected. Plugin 1180 emits HIGH.

ElastiCache Redis cache-cluster 'nw-session-cache' has at-rest encryption DISABLED (AtRestEncryptionEnabled=false). C1.1 confidentiality gap: cache data persisted to EBS snapshots + cross-region replication backups stored unencrypted; no crypto-shred capability. At-rest encryption cannot be enabled in-place — requires snapshot-restore-to-new-cluster with KmsKeyId set + DR window for data migration.

Source: aws-elasticache-redis-auditor

C1.1 confidentiality gap HIGH — added in EE-RT.17 v1 (EE 0.4.6). ElastiCache cache data persisted to EBS snapshots + cross-region replication backups stored unencrypted; no crypto-shred capability. Cannot be enabled in-place — requires snapshot-restore-to-new-cluster with KmsKeyId set.

C1.2 — Disposal of confidential information FAIL

Category: Confidentiality · Violations: 15

Object Lock not configured

Source: aws-s3-auditor

C1.2 requires controlled disposal of confidential information per the entity's retention policy. S3 Object Lock (COMPLIANCE mode) is the institutional WORM control on AWS — without it, retention windows cannot be cryptographically enforced and an insider with bucket-write IAM can delete confidential records before retention expires. Maps to SEC Rule 17a-4 / FINRA 4511 retention guarantees. Severity LOW by default; escalates to MEDIUM when bucket name matches AWS_S3_AUDIT_CONFIDENTIAL_BUCKETS (EE-0.3.2.4).

MFA Delete not enabled

Source: aws-s3-auditor

C1.2 requires controlled disposal — versioning alone is not tamper-resistant because a single insider with bucket-write IAM can delete a version permanently. MFA Delete requires a second factor at delete-version time, closing the bypass. Only meaningful for buckets with versioning enabled; the plugin emits this finding only in that case (EE-0.3.2.4). Severity LOW by default; escalates to MEDIUM when bucket name matches AWS_S3_AUDIT_CONFIDENTIAL_BUCKETS.

Object Lock not configured

Source: aws-s3-auditor

MFA Delete not enabled

Source: aws-s3-auditor

MFA Delete not enabled

Source: aws-s3-auditor

Object Lock not configured

Source: aws-s3-auditor

Source: aws-cloudtrail-auditor

C1.2 -- CloudTrail/CloudWatch evidence is INCOMPLETE: plugin 1040 aborted at its soft budget (scan-time-budget-exceeded) before finishing the audit, so this control's CloudTrail-derived evidence was not collected. Fails-closed (no silent PASS over an un-audited control surface) per the conservative-classifier principle and consistent with the 1020/1021/1025 evidence-gap convention. Resolve by raising CLOUD_PLUGIN_TIMEOUT_MS / NSA_CT_SOFT_BUDGET_MS or scoping to a single region (NSA_CT_MAX_REGIONS / multiRegionScan=false), then re-run. EE 0.16.5 false-clean fix.

Source: aws-cloudtrail-auditor

C1.2 requires controlled disposal of audit records per institutional retention policy. The CloudTrail destination bucket IS the audit-record store — Object Lock COMPLIANCE mode + 7-year retention (SEC 17a-4 baseline) + MFADelete are the canonical institutional WORM controls. Plugin 040 (EE-RT.1.4) audits this bucket distinctly from general data buckets because trail-bucket requirements are STRICTER (CRITICAL on missing Object Lock vs general-bucket LOW/MEDIUM). Covers: no Object Lock configured, GOVERNANCE mode, short retention (< minRetentionDays baseline), missing DefaultRetention rule, Versioning disabled, MFADelete disabled. EE-RT.1.4.

Source: aws-cloudtrail-auditor

Trail destination bucket northwind-trail-logs has NO Object Lock configuration. SEC Rule 17a-4 / FINRA 4511 require WORM storage for audit logs. Enable Object Lock + COMPLIANCE mode + retention.

Source: aws-cloudtrail-auditor

Trail destination bucket northwind-trail-logs has Versioning Disabled — Object Lock REQUIRES Versioning. Without it, retention rules cannot be enforced.

Source: aws-cloudtrail-auditor

S3 bucket 'northwind-config-logs' has NO lifecycle configuration, but the bucket's resource policy grants config.amazonaws.com a framework-attach action (s3:PutObject / s3:GetBucketAcl / s3:GetBucketLogging / s3:* via Principal.Service, incl. regional/partition variants) — structural AWS attestation that the bucket IS attached as an AWS Config delivery channel. Retention for these buckets is governed by the host framework (trail config / delivery channel), not S3 lifecycle — operator-configured S3 lifecycle is NOT the canonical control here. Demoted to INFO per EE-RT.4.x.1; policy-attested (auditor walkthrough still recommended to verify policy attestation matches an actual framework attachment — cross-policy spoofing class). C1.2 boundary evaluated; no operator-actionable gap (INFO surfacing for evidence-pack completeness).

Source: aws-s3-lifecycle-replication-auditor

C1.2 INFO substrate evidence (EE-RT.4.x.1, EE 0.4.2) — plugin 1120 emission category `s3-lifecycle-missing-framework-managed-demoted` with `detectionMethod: 'policy'`. Bucket's resource policy contains a Principal.Service grant to `cloudtrail.amazonaws.com` / `config.amazonaws.com` with a framework-attach action (s3:PutObject / s3:GetBucketAcl / s3:*) — structural AWS attestation that the bucket IS attached as a CloudTrail destination / Config delivery channel. Closes the bypass surface where operators could rename a confidential bucket to match the name-pattern detection — policy-based detection requires actual framework attachment, which operators cannot fake. `walkthroughRequired: false` because policy attestation is institutionally sufficient. C1.2 boundary evaluated — bucket is still surfaced in the evidence pack — but no operator-actionable gap.

S3 bucket 'northwind-orgtrail-logs' has NO lifecycle configuration, but the bucket's resource policy grants cloudtrail.amazonaws.com a framework-attach action (s3:PutObject / s3:GetBucketAcl / s3:GetBucketLogging / s3:* via Principal.Service, incl. regional/partition variants) — structural AWS attestation that the bucket IS attached as a CloudTrail destination. Retention for these buckets is governed by the host framework (trail config / delivery channel), not S3 lifecycle — operator-configured S3 lifecycle is NOT the canonical control here. Demoted to INFO per EE-RT.4.x.1; policy-attested (auditor walkthrough still recommended to verify policy attestation matches an actual framework attachment — cross-policy spoofing class). C1.2 boundary evaluated; no operator-actionable gap (INFO surfacing for evidence-pack completeness).

Source: aws-s3-lifecycle-replication-auditor

S3 bucket 'northwind-trail-logs' has NO lifecycle configuration, but the bucket's resource policy grants cloudtrail.amazonaws.com a framework-attach action (s3:PutObject / s3:GetBucketAcl / s3:GetBucketLogging / s3:* via Principal.Service, incl. regional/partition variants) — structural AWS attestation that the bucket IS attached as a CloudTrail destination. Retention for these buckets is governed by the host framework (trail config / delivery channel), not S3 lifecycle — operator-configured S3 lifecycle is NOT the canonical control here. Demoted to INFO per EE-RT.4.x.1; policy-attested (auditor walkthrough still recommended to verify policy attestation matches an actual framework attachment — cross-policy spoofing class). C1.2 boundary evaluated; no operator-actionable gap (INFO surfacing for evidence-pack completeness).

Source: aws-s3-lifecycle-replication-auditor

S3 bucket 'northwind-customer-pii' has NO lifecycle configuration. C1.2 disposal-cadence gap: confidential data accumulates indefinitely without an AWS-canonical disposal trail. Auditors expect a documented retention policy backed by a lifecycle rule with Expiration days; absence is a control gap unless the bucket is documented as "indefinite retention" (legal hold, audit-log substrate, etc.).

Source: aws-s3-lifecycle-replication-auditor

C1.2 MEDIUM (EE-RT.4 v1, v0.4.0) — plugin 1120 emission category `s3-lifecycle-missing`. AWS S3 buckets without a lifecycle configuration accumulate objects indefinitely — no AWS-canonical disposal-cadence evidence trail. Operators with documented 'indefinite retention' (legal hold, audit-log substrate) accept this; production-tier data buckets are an institutional C1.2 gap. The lifecycle-EXPIRATION rule (not transitions) is the canonical disposal evidence — transitions are storage-class migrations, not disposal. Anchored regex requires the `C1.2 disposal-cadence gap` trailer (MEDIUM tier only) so this rule does NOT match the framework-managed-demoted INFO emission below (which uses the `C1.2 boundary evaluated` trailer instead — EE-RT.4.x noise demotion).

A1.2 — Environmental protections, software, data backup processes, recovery infrastructure FAIL

Category: Availability · Violations: 16

⚠️ Coverage caveat: Network scanning evidences exposed availability targets and DoS-amplification surfaces but cannot evidence backup/recovery posture; pair with infrastructure attestations.

Versioning is disabled – data recovery at risk

Source: aws-s3-auditor

A1.2 requires data recovery capability; disabled or suspended versioning compromises point-in-time recovery. Anchored regex (rather than substring) so the pattern matches ONLY the plugin's two real emissions ('Versioning is disabled' / 'Versioning is Suspended') and rejects (a) the plugin's `Versioning check failed: <ErrName>` SDK-error string (would have promoted SDK hiccups into fake A1.2 violations — EE-0.3.2.2 drift detector fix) and (b) academic substring collisions like 'Versioning isolated' or 'Versioning is best-practice' (EE-0.3.2.3 reviewer M2 fold).

Versioning is disabled – data recovery at risk

Source: aws-s3-auditor

RDS DB instance 'northwind-analytics-cluster' has BackupRetentionPeriod=1 days, below the institutional baseline of 7 days. A1.2 availability partial-gap: a recovery event older than 1 days cannot be restored via PITR. Raise to ≥7 days via rds:ModifyDBInstance --backup-retention-period.

Source: aws-rds-auditor

A1.2 availability partial-gap MEDIUM — added in EE-RT.14 v2 (EE 0.4.5). RDS BackupRetentionPeriod is below the institutional baseline (default 7 days, configurable via opts.backupRetentionPassMinDays). PITR window is shorter than auditor-canonical baseline. Plugin 1140 emits MEDIUM per below-baseline instance.

RDS DB instance 'northwind-orders-db' is configured single-AZ (MultiAZ=false). A1.2 availability gap: an AZ outage, instance failure, or maintenance event would render the database unavailable until manual recovery. Enable Multi-AZ via rds:ModifyDBInstance for production-tier workloads.

Source: aws-rds-auditor

A1.2 availability gap — added in EE-RT.14 v1 (EE 0.4.3). AWS RDS DB instance with MultiAZ=false runs a single primary in a single AZ; an AZ outage, instance failure, or maintenance event renders the database unavailable until manual recovery. Multi-AZ deployment provisions a synchronous-replicated standby in a separate AZ, enabling automated failover within ~60s on the same DB instance endpoint (DNS unchanged). Plugin 1140 emits HIGH per single-AZ instance. Remediate via rds:ModifyDBInstance --multi-az --apply-immediately for production-tier workloads.

RDS DB instance 'northwind-orders-db' has BackupRetentionPeriod=0 — automated backups are DISABLED. A1.2 availability gap: PITR is unavailable (requires automated backups), no recovery from corruption / accidental-DROP / insider-vandalism. Enable via rds:ModifyDBInstance --backup-retention-period <days>; institutional baseline is 7 days.

Source: aws-rds-auditor

A1.2 availability gap HIGH — added in EE-RT.14 v2 (EE 0.4.5). AWS RDS instance with BackupRetentionPeriod=0 has automated backups DISABLED entirely. PITR is unavailable (requires automated backups); recovery from corruption / accidental DROP / insider-vandalism is not possible. Plugin 1140 emits HIGH per instance with retention=0. Remediate via rds:ModifyDBInstance --backup-retention-period <days>; institutional baseline is 7 days.

Source: aws-sqs-sns-auditor

A1.2 availability gap MEDIUM — added in EE-RT.15 v2 (EE 0.5.1); dual-mapped with CC7.2. SQS queue with no ApproximateAgeOfOldestMessage alarm: consumer backlog growth silently degrades downstream availability (failed processing, slow consumers, downstream outages) with no operator paging. Plugin 1150 v2 emits MEDIUM per queue.

Source: aws-sqs-sns-auditor

A1.2 availability + CC7.1 anomaly-detection MEDIUM — added in EE-RT.15 v1 (EE 0.4.4); dual-mapped with CC7.1. SQS queues without a RedrivePolicy silently drop messages after maxReceiveCount processing failures — no anomaly signal, no DLQ to capture failed messages for replay. For event-driven architectures where SQS fans out to downstream Lambda/ECS consumers, a missing DLQ is the canonical silent-message-loss class. Plugin 1150 emits MEDIUM per queue. Configure via SetQueueAttributes RedrivePolicy={deadLetterTargetArn:'<arn>',maxReceiveCount:<N>}.

Source: aws-sqs-sns-auditor

A1.2 availability gap MEDIUM — added in EE-RT.15 v2 (EE 0.5.1); dual-mapped with CC7.2. SNS topic with no NumberOfNotificationsFailed alarm: subscription delivery failures silently degrade downstream subscriber availability. Plugin 1150 v2 emits MEDIUM per topic.

Source: aws-sqs-sns-auditor

ElastiCache Redis replication-group 'nw-product-cache' has Multi-AZ=disabled + AutomaticFailover=disabled. A1.2 availability gap: no Multi-AZ replica protection (AZ outage takes the cluster down). Enable both via ModifyReplicationGroup --multi-az-enabled --automatic-failover-enabled for production-tier workloads.

Source: aws-elasticache-redis-auditor

A1.2 availability gap HIGH — added in EE-RT.17 v1 (EE 0.4.6). Either Multi-AZ disabled (AZ outage takes cluster down) OR AutomaticFailover disabled (manual operator action required on primary failure — extended RTO). Enable both via ModifyReplicationGroup --multi-az-enabled --automatic-failover-enabled. Plugin 1180 emits HIGH per non-compliant replication group.

ElastiCache Redis replication-group 'nw-product-cache' has SnapshotRetentionLimit=0 — automatic snapshots are DISABLED. A1.2 availability gap: data is unrecoverable from cluster failure / accidental FLUSHALL / insider-vandalism. Set via ModifyReplicationGroup --snapshot-retention-limit <days>; institutional baseline is 7 days. AWS ElastiCache Redis max is 35 days.

Source: aws-elasticache-redis-auditor

A1.2 availability gap HIGH — added in EE-RT.17 v1 (EE 0.4.6). SnapshotRetentionLimit=0 disables automatic snapshots; cache data unrecoverable from cluster failure / accidental FLUSHALL / insider-vandalism. Plugin 1180 emits HIGH per non-snapshotted cluster.

ElastiCache Redis cache-cluster 'nw-session-cache' has SnapshotRetentionLimit=0 — automatic snapshots are DISABLED. A1.2 availability gap: data is unrecoverable from cluster failure / accidental FLUSHALL / insider-vandalism. Set via ModifyReplicationGroup --snapshot-retention-limit <days>; institutional baseline is 7 days. AWS ElastiCache Redis max is 35 days.

Source: aws-elasticache-redis-auditor

AWS Backup account audit: ZERO backup plans configured. A1.2 availability gap: no AWS-native backup substrate is operating. Production-tier workloads on EBS / RDS / DynamoDB / EFS / FSx / Storage Gateway / Aurora typically require AWS Backup plans (or vendor-equivalent backup). Auditor walkthrough required if backups are managed externally.

Source: aws-backup-auditor

A1.2 availability evidence — institutional gap. AWS Backup is the AWS-canonical backup substrate for EBS / RDS / DynamoDB / EFS / FSx / Storage Gateway / Aurora / Neptune / DocumentDB. An account with ZERO backup plans operating has no AWS-native backup substrate — auditors evaluating availability posture must verify that backups are managed via an external mechanism (snapshot scripts, vendor backup tools, application-tier exports). Plugin 1130 emits MEDIUM at the account level when no plans exist. EE-RT.12 v1 (v0.4.0).

AWS Backup account audit: ZERO Restore Testing Plans configured. A1.2 disaster-recovery validation gap: NO periodic test-restores are scheduled against the AWS Backup substrate. Per SEC Rule 17a-4 / FINRA 4511 audit-the-restorer doctrine, recovery points without periodic test-restores are unverifiable evidence — backups may exist but operators cannot prove they CAN be restored. Configure at least one Restore Testing Plan covering production-tier recovery points. Auditor walkthrough required if DR is validated via external runbook.

Source: aws-backup-auditor

A1.2 disaster-recovery validation gap — added in EE-RT.12.3. Per SEC Rule 17a-4 / FINRA 4511 audit-the-restorer doctrine, recovery points without periodic test-restores are UNVERIFIABLE evidence — backups may exist but operators cannot prove they CAN be restored. AWS Backup Restore Testing Plans automate periodic test-restores against recovery points and surface failures via CloudWatch. An account with ZERO restore testing plans has no AWS-side DR validation substrate. Plugin 1130 emits MEDIUM at the account level. Acceptable only when DR validation is documented via an external runbook (auditor walkthrough required to verify external attestation). Anchored regex (R2-CRITICAL-2 drift pattern) rejects substring matches. EE-RT.12.3 v1 (v0.4.0).

PI1.5 — Stored items — store inputs, items in processing, and outputs completely, accurately, and timely FAIL

Category: Processing Integrity · Violations: 1

⚠️ Coverage caveat: EE-RT.2 (v0.4.0) opens partial PI1.5 evidence by validating the STORAGE SUBSTRATE of items-in-processing and items-at-rest on AWS DynamoDB: PITR (point-in-time-recovery enables stored-item restoration to a known-good prior state), deletion-protection (stored-item survivability against destructive API calls), KMS-CMK key custody (tamper-evident at-rest encryption), and CloudTrail DynamoDB data-event logging (every write to the stored-item store is recorded externally for retrospective verification). This is the auditor-canonical 'audit-the-auditor' dimension on the storage layer. **Initial mapping correction (R1-C1 fold post-2026-05-12 review)**: pre-fold this evidence was incorrectly mapped to PI1.1 'Information quality' — TSC 2017 PI1.1 is about INPUT data quality (definitions, completeness, accuracy of inputs received from upstream sources), which is application-tier and out-of-scope for static substrate scanning. PI1.5 'Stored items' is the correct sub-criterion for storage-substrate evidence. **PI1.5 cannot reach PASS via static substrate scanning alone — partial is the maximum**; full PASS requires (a) EE-RT.7 Lambda Runtime Assurance application-tier evidence for the items-in-processing dimension, AND (b) application-side data-integrity attestations. Pair with both for full PI1.5 coverage. **Confidence: LOW-PARTIAL** — auditor must explicitly accept the substrate-only scope. The other PI1 sub-criteria (PI1.1 input-quality, PI1.2 input-processing, PI1.3 process-integrity, PI1.4 output-delivery) remain OOS for static scanning.

Source: aws-dynamodb-auditor

PI1.5 worst case: a stored-item table with neither PITR nor deletion-protection has no path back to a known-good state after corruption. For payroll-runs / financial-batch / audit-store tables, this is the canonical stored-item integrity failure mode. Plugin 060 emits CRITICAL. Anchored regex (R2-CRITICAL-2 fold) pins to the literal CRITICAL emission. EE-RT.2 (v0.4.0).

Passing Controls (Within Scope)

PASS CC6.2 — User identification and authentication
PASS CC6.7 — Data in transit protection
PASS CC6.8 — Prevention and detection of unauthorized or malicious software

Partial Coverage

PARTIAL CC8.1 — Change management and authorization
⚠️ Coverage caveat: Single-scan visibility cannot evidence change-management cadence; CC8.1 requires multi-scan delta detection (CTEM watch mode + EE-SOC2.9 recurring-scan attestation). EE-RT.9 v1 enriches the partial coverage with static CI/CD-substrate evidence (manual-approval-gate, source-provider-trust) but does not promote partial → covered.

Out of Scope

Control IDs	Title	Reason
`CC1.1, CC1.2, CC1.3, CC1.4, CC1.5`	Control Environment	Governance / ethics / board oversight — not addressable by network scanning. Evidence: HR systems, signed Code of Conduct, board minutes, org charts.
`CC2.1, CC2.2, CC2.3`	Communication and Information	Internal/external policy communication — not addressable by network scanning. Evidence: corporate communication policies, security awareness training logs.
`CC3.1, CC3.2, CC3.3, CC3.4`	Risk Assessment	Enterprise risk identification (strategic/operational/fraud) — technical vulnerability ≠ enterprise risk. Evidence: formal risk register, vendor risk questionnaires.
`CC4.1, CC4.2`	Monitoring Activities	Governance-layer monitoring of internal controls — not network-layer monitoring. Partial evidence possible via tabletop simulation (EE-SOC2.14).
`CC5.1, CC5.2, CC5.3`	Control Activities	Policy and procedural controls — not addressable by network scanning.
`CC9.1, CC9.2`	Risk Mitigation	Business continuity, vendor management, cyber insurance — not addressable by network scanning. Evidence: BCP, DR tabletop logs, vendor SLA reviews.
`PI1.1, PI1.2, PI1.3, PI1.4`	Processing Integrity (input quality / input processing / process integrity / output delivery)	Application-logic correctness — not network-layer scope. (NOTE: PI1.5 'Stored items' moved to `partial` 2026-05-12 via EE-RT.2 v0.4.0 — substrate-level evidence on the storage-layer dimension via DynamoDB PITR + deletion-protection + CloudTrail DynamoDB data-event coverage. Full PI1.5 coverage requires application-tier validation via EE-RT.7 Lambda Runtime Assurance, planned v0.4.1+. The remaining PI1.1/.2/.3/.4 sub-criteria stay OOS — those evidence input/processing/output integrity which is irreducibly application-tier.)
`P1.0, P2.0, P3.0, P4.0, P5.0, P6.0, P7.0, P8.0`	Privacy	Application-level data handling and disclosure — not network-layer scope.
`CC6.4, CC6.5`	Physical access controls	Physical access (keycards, cameras, data center) — not network-layer scope. Evidence: keycard logs, security cameras, data-center SOC 2 attestations (e.g., AWS, GCP).

Appendix A — Cloud Bucket Exposure Attestation

Buckets with finding(s): 21 violation event(s) across 0 unique bucket(s).

Per-bucket detail in JSON sidecar — report.controls[].violations filtered by source IN ["aws-s3-auditor", "gcp-cloud-storage-auditor", "azure-storage-auditor"].

Appendix B — Accepted Risks & False Positives

No suppressions in this scan.

Report integrity: see companion .sha256 sidecar — verify with shasum -a 256 -c <file>.sha256