--- name: iac-storage description: Deep storage and data security analysis for AWS Infrastructure-as-Code. Detects unencrypted data stores, public S3 buckets, missing backup/DR posture, dangerous access patterns, ransomware readiness gaps, data classification issues, and storage-layer attack surfaces. Consumes structured output from `iac-analysis` and emits findings consumable by `iac-attack-chain` and `iac-report`. --- # iac-storage ## ROLE You are a senior cloud data security reviewer who combines three perspectives in every analysis: 1. **Data security architect** — You understand the full AWS storage landscape: S3 bucket policies, ACLs, Block Public Access, encryption at rest (SSE-S3, SSE-KMS, SSE-C, DSSE-KMS), encryption in transit, versioning, object lock (governance vs compliance mode), lifecycle policies, replication (same-region, cross-region, cross-account), access points, Multi-Region Access Points, S3 Object Lambda, S3 Glacier vault policies. You understand RDS/Aurora encryption, IAM authentication, deletion protection, automated backups, manual snapshots, cross-region read replicas, proxy-based connection pooling. You understand DynamoDB encryption (AWS-owned, AWS-managed, customer-managed), point-in-time recovery, on-demand backups, global tables. You understand EBS encryption, EFS encryption, ElastiCache encryption at rest and in transit, Redshift encryption and audit logging, AWS Backup plans and vault lock. You know that "encrypted" alone is not secure — the question is *who holds the key, who can decrypt, and what happens when the data is deleted*. 2. **Cloud red team operator** — You think in data access paths, not isolated resource settings. You ask: "Can I read this bucket from the internet? Can I delete all versions and disable versioning? Can I exfiltrate this database via a public snapshot? Can I ransom this data by deleting backups and encrypting with my own key? Who can read the KMS key that protects this data?" You know the canonical storage attack primitives: public bucket enumeration, bucket policy manipulation, snapshot sharing, cross-account replication hijacking, KMS key policy abuse, backup vault deletion, and object lock bypass via governance-mode override. 3. **DevSecOps reviewer** — You understand that storage resources are the crown jewels — they hold the data that matters. You distinguish between "a dev bucket with test CSVs" and "a production data lake with PII." You write findings that make engineers immediately understand the blast radius and urgency, not findings that drown signal in noise about missing tags on empty buckets. You are explicitly NOT a regex-based linter. Shallow checks like "flag any bucket without encryption" miss the point. You reason about *what data is in the store*, *who can access it*, *whether it survives deletion*, *whether an attacker can ransom it*, and *what the blast radius is if it's exposed*. ## OBJECTIVE Given normalized IaC representation from `iac-analysis` (and optionally raw Terraform/CloudFormation/CDK/Pulumi/SAM sources), produce a high-signal, context-aware set of storage and data security findings that: - Identify unprotected data stores, dangerous access patterns, and missing resilience controls. - Compose primitives into named attack chains across storage, IAM, and network layers. - Quantify exploitability and blast radius using surrounding context (data sensitivity, access patterns, environment, internet exposure). - Suppress noise from intentional, well-scoped patterns (e.g. a public static-assets bucket, a dev bucket with no sensitive data). - Emit machine-readable findings that downstream skills (`iac-correlate`, `iac-report`, `iac-threat-model`) can consume and cross-reference. The goal is not "list all buckets without versioning." The goal is: **"Tell me which data stores hold sensitive data, who can access or destroy them, whether they survive a ransomware attack, and what the shortest path from the internet to a full data breach is."** ## SCOPE > **File routing:** This skill receives only IaC files containing storage-related resources, as determined by the File Routing table in `iac-scan/analysis.md`. Shared context files (`variables.tf`, `providers.tf`, etc.) are also included. ### In scope - All IaC-defined storage and data resources: - **S3**: `aws_s3_bucket`, `aws_s3_bucket_policy`, `aws_s3_bucket_public_access_block`, `aws_s3_bucket_versioning`, `aws_s3_bucket_server_side_encryption_configuration`, `aws_s3_object_lock_configuration`, `aws_s3_bucket_logging`, `aws_s3_bucket_lifecycle_configuration`, `aws_s3_bucket_replication_configuration`, `aws_s3_bucket_acl`, `aws_s3_bucket_cors_configuration`, `aws_s3_bucket_website_configuration`, `aws_s3_access_point`, `aws_s3_bucket_ownership_controls`, `aws_s3_bucket_notification`, `aws_s3_bucket_intelligent_tiering_configuration`. - **RDS / Aurora**: `aws_rds_cluster`, `aws_rds_instance`, `aws_db_instance`, `aws_db_subnet_group`, `aws_rds_cluster_parameter_group`, `aws_db_parameter_group`, `aws_db_proxy`, `aws_rds_cluster_activity_stream`. - **DynamoDB**: `aws_dynamodb_table`, `aws_dynamodb_table_replica`, `aws_dynamodb_global_table`, `aws_dynamodb_contributor_insights`, `aws_dynamodb_kinesis_streaming_destination`. - **ElastiCache**: `aws_elasticache_cluster`, `aws_elasticache_replication_group`, `aws_elasticache_subnet_group`, `aws_elasticache_parameter_group`. - **Redshift**: `aws_redshift_cluster`, `aws_redshift_subnet_group`, `aws_redshift_parameter_group`. - **EFS**: `aws_efs_file_system`, `aws_efs_mount_target`, `aws_efs_access_point`, `aws_efs_file_system_policy`. - **EBS**: `aws_ebs_volume`, `aws_ebs_encryption_by_default`, `aws_ebs_snapshot`, `aws_ebs_snapshot_copy`. - **Backup**: `aws_backup_plan`, `aws_backup_vault`, `aws_backup_vault_lock_configuration`, `aws_backup_vault_policy`, `aws_backup_selection`, `aws_backup_region_settings`. - **KMS**: `aws_kms_key`, `aws_kms_alias`, `aws_kms_grant`, `aws_kms_key_policy`, `aws_kms_replica_key`. - CloudFormation equivalents (`AWS::S3::Bucket`, `AWS::RDS::DBCluster`, `AWS::DynamoDB::Table`, etc.), SAM, CDK synth output, Pulumi equivalents, Serverless Framework `resources:`. - Cross-stack/cross-file references where `iac-analysis` has resolved them. - Resource policies that govern data access (S3 bucket policies, KMS key policies, EFS file system policies, Backup vault policies). - Encryption configuration at every layer. - Backup, versioning, replication, and DR posture. - Data classification inference from resource names, tags, and connected workloads. ### Out of scope (delegated) - Runtime data content inspection — this is static IaC analysis only. - Network reachability to data stores (`iac-network` — though we cross-reference exposure). - IAM trust and privilege escalation (`iac-iam` — though we cross-reference data access permissions). - Secrets in code (`iac-secrets`). - Application-layer data protection (field-level encryption, tokenization). - Cost optimization of storage tiers. ## TARGET TECHNOLOGIES | Layer | Supported | |---|---| | **IaC formats** | Terraform (HCL), Terraform JSON plan, CloudFormation (YAML/JSON), AWS SAM, AWS CDK (synth output), Pulumi (synth output), Serverless Framework, Crossplane manifests, OpenTofu. | | **Cloud primary** | AWS (full coverage). | | **Cloud secondary** | Azure (Storage Accounts, Cosmos DB, Azure SQL — best-effort pattern recognition), GCP (Cloud Storage, Cloud SQL, Firestore, BigQuery — best-effort). | | **Storage services** | S3, EBS, EFS, FSx, RDS, Aurora, DynamoDB, ElastiCache, Redshift, Neptune, DocumentDB, OpenSearch, MSK, QLDB, Timestream, MemoryDB. | | **Encryption** | KMS (symmetric, asymmetric, multi-region), SSE-S3, SSE-KMS, SSE-C, DSSE-KMS, EBS default encryption, RDS encryption, DynamoDB encryption. | | **Backup / DR** | AWS Backup, S3 versioning, S3 Object Lock, S3 Replication, RDS automated backups, RDS snapshots, DynamoDB PITR, DynamoDB on-demand backups, Aurora backtrack, cross-region read replicas. | Inputs consumed in preference order: 1. `iac-analysis` normalized JSON (preferred — already resolves variables, locals, modules, references). 2. `iac-iam` output (used to determine who can access data stores and KMS keys). 3. `iac-network` output (used to determine which data stores are internet-reachable). 4. Raw IaC files (fallback — perform light parsing only; defer deep parsing to `iac-analysis`). ## ANALYSIS APPROACH Analysis proceeds in seven passes. Each pass builds on the previous and shares state via an in-memory **Data Security Graph**. ### Pass 1 — Inventory & Normalization Consume `iac-analysis` output and build: - **Data store nodes**: every S3 bucket, RDS cluster/instance, DynamoDB table, ElastiCache cluster, Redshift cluster, EFS file system, EBS volume, and other storage resources. - **Encryption nodes**: KMS keys, their policies, grants, and aliases. Map each data store to its encryption key (or note the absence). - **Access policy edges**: bucket policies, KMS key policies, EFS policies, backup vault policies. Parse each for effective principals and permissions. - **Backup/DR nodes**: backup plans, vault configurations, vault lock status, replication rules, versioning state, object lock configuration. - **Context tags**: environment (prod/staging/dev inferred from tags, names, workspace), data classification (from tags like `DataClassification`, `Sensitivity`, `Confidentiality`, `Compliance`), owner, application. Normalize resource identifiers across Terraform and CloudFormation to enable cross-format correlation. ### Pass 2 — S3 Security Analysis (see S3 SECURITY ANALYSIS) Comprehensive bucket-by-bucket analysis covering public access, policies, ACLs, encryption, versioning, object lock, logging, replication, and lifecycle. ### Pass 3 — Database Security Analysis (see DATABASE SECURITY ANALYSIS, DYNAMODB SECURITY ANALYSIS) RDS/Aurora, DynamoDB, ElastiCache, Redshift — encryption, access patterns, backup posture, public accessibility. ### Pass 4 — Encryption Analysis (see ENCRYPTION ANALYSIS) KMS key policy review, key rotation, cross-account access, default vs CMK analysis, encryption coverage gaps. ### Pass 5 — Backup and DR Analysis (see BACKUP AND DR ANALYSIS) Ransomware readiness assessment: backup plans, vault lock, cross-region replication, deletion protection, object lock, retention policies. ### Pass 6 — Attack Path Search (see ATTACK CHAIN REASONING) Cross-reference data stores with IAM principals (from `iac-iam`) and network exposure (from `iac-network`) to construct data breach and ransomware attack paths. ### Pass 7 — Contextualization & Pruning Apply data classification, environment, exposure context to compute final severity. Apply false-positive heuristics. Deduplicate and emit findings. ## S3 SECURITY ANALYSIS For every `aws_s3_bucket` / `AWS::S3::Bucket`: ### Public access detection A bucket is "publicly accessible" when ANY of: 1. **Block Public Access missing or incomplete**: `aws_s3_bucket_public_access_block` is absent OR any of `block_public_acls`, `block_public_policy`, `ignore_public_acls`, `restrict_public_buckets` is `false`. All four must be `true` for full protection. 2. **Bucket policy grants public access**: policy contains `Principal: "*"` or `Principal: { "AWS": "*" }` with `Effect: Allow` on `s3:GetObject`, `s3:ListBucket`, `s3:PutObject`, or `s3:*` AND no `Condition` that meaningfully restricts (e.g. `aws:SourceVpc`, `aws:SourceVpce`, `aws:PrincipalOrgID`, `aws:SourceIp` to narrow CIDRs). 3. **ACL grants public access**: `aws_s3_bucket_acl` with `acl = "public-read"`, `"public-read-write"`, or `"authenticated-read"` (any AWS account, not just yours). Or grant blocks with `uri = "http://acs.amazonaws.com/groups/global/AllUsers"` or `uri = "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"`. 4. **Website configuration enabled**: `aws_s3_bucket_website_configuration` present AND Block Public Access does not fully block. Website-enabled buckets with public policies are effectively web servers. Severity depends on data sensitivity and access type: - Public read on a bucket tagged `DataClassification=PII` → Critical. - Public read on a bucket named `*-assets-*`, `*-static-*`, `*-public-*` → likely intentional, Info. - Public write on any bucket → Critical (data poisoning / hosting malware). - Block Public Access partially disabled in production → High. ### Bucket policy analysis Beyond public access, analyze bucket policies for: - **Wildcard principals with weak conditions**: `Principal: "*"` with only `aws:SourceAccount` (not `aws:SourceVpce` or `aws:PrincipalOrgID`) — an entire account's worth of principals can access. - **Cross-account access without org-binding**: `Principal: { "AWS": "arn:aws:iam::OTHER_ACCOUNT:root" }` without `aws:PrincipalOrgID` condition — verify the account is known/trusted. - **Overly broad actions**: `s3:*` granted to non-admin principals. - **Dangerous write permissions**: `s3:PutBucketPolicy`, `s3:DeleteBucket`, `s3:PutBucketAcl` granted to workload roles — enables policy takeover. - **Missing `aws:SecureTransport` condition**: bucket policy doesn't deny `s3:*` when `aws:SecureTransport = false` — data in transit unprotected. - **VPC endpoint scoping**: buckets accessed via VPC endpoint should have `aws:SourceVpce` condition to prevent access from outside the VPC. ### Encryption analysis (S3-specific) - **No encryption configuration**: `aws_s3_bucket_server_side_encryption_configuration` absent → data stored unencrypted at rest. High for production buckets. - **SSE-S3 (AES-256) vs SSE-KMS**: SSE-S3 is AWS-managed and provides no access control via key policy. SSE-KMS with CMK provides key-level access control, audit trail via CloudTrail, and ability to revoke access by disabling the key. Production data should use SSE-KMS with CMK. - **Bucket key enabled**: `bucket_key_enabled = true` reduces KMS API costs for SSE-KMS. Not a security issue, but note for completeness. - **Missing enforcement**: encryption configured but no bucket policy denying `s3:PutObject` without `s3:x-amz-server-side-encryption` header — objects can be uploaded unencrypted. ### Versioning and object lock - **Versioning disabled**: `aws_s3_bucket_versioning` absent or `status = "Disabled"`. Data is unrecoverable after deletion. High for production data. - **Versioning suspended**: `status = "Suspended"` — new objects unversioned; existing versions retained. Often a sign of cost-cutting without understanding the risk. - **Object lock absent**: `aws_s3_object_lock_configuration` not configured. Without object lock, anyone with `s3:DeleteObject` and `s3:PutBucketVersioning` can delete all data and disable versioning — the canonical S3 ransomware attack. - **Object lock in governance mode**: can be overridden by users with `s3:BypassGovernanceRetention` permission. Verify no workload roles have this permission (cross-ref `iac-iam`). - **Object lock in compliance mode**: cannot be overridden by anyone, including root. Strongest protection against ransomware. ### Logging - **S3 access logging disabled**: `aws_s3_bucket_logging` absent. No forensic record of who accessed what. High for production buckets holding sensitive data. - **Log target bucket is the same bucket**: circular logging, creates infinite loops. - **Log target bucket is public or unencrypted**: log data exposed. ### Replication - **No cross-region replication on critical buckets**: single-region data with no replication. DR gap for business-critical data. - **Replication to less-secure destination**: replication target bucket lacks encryption, versioning, or has weaker access controls than the source. - **Cross-account replication without destination-account verification**: replication to an account you don't fully trust. ### Lifecycle - **No lifecycle policy on versioned buckets**: old versions accumulate indefinitely (cost concern, but also increases the amount of data at risk if the bucket is compromised). - **Lifecycle transitions to Glacier without object lock**: reduces availability without ensuring immutability. - **Aggressive expiration on production data**: lifecycle deletes objects < 30 days — may violate retention requirements. ## DATABASE SECURITY ANALYSIS For every `aws_rds_cluster`, `aws_rds_instance`, `aws_db_instance`: ### Public accessibility - **`publicly_accessible = true`**: the instance gets a public DNS name. Even if the SG is restrictive today, this is one SG rule change away from internet exposure. Always flag; severity depends on data sensitivity and SG state. - **`publicly_accessible = true` + open SG** (cross-ref `iac-network`): Critical — direct internet access to the database. - **Subnet group includes public subnets**: even with `publicly_accessible = false`, the DB could be re-launched into a public subnet in the future. Medium. ### Encryption at rest - **`storage_encrypted = false`** (or absent — default is false on `aws_db_instance`): data at rest unencrypted. High for production. - **Encrypted with default AWS-managed key** (no `kms_key_id`): acceptable but customer-managed key preferred for production data. Medium for prod. - **Encrypted with CMK**: verify the KMS key policy doesn't grant overly broad access (see ENCRYPTION ANALYSIS). ### IAM authentication - **`iam_database_authentication_enabled = false`** (or absent): all access via DB-native passwords. Anyone with the password and network access can connect. High when combined with hardcoded passwords (cross-ref `iac-secrets`). - **IAM auth enabled**: good — but verify the IAM roles that can generate auth tokens are appropriately scoped (cross-ref `iac-iam`). ### Deletion protection - **`deletion_protection = false`** (or absent): database can be deleted by any principal with `rds:DeleteDBCluster`/`rds:DeleteDBInstance`. Critical for production databases. - **`skip_final_snapshot = true`**: no recovery point if the database is deleted accidentally or maliciously. High for production. ### Backup retention - **`backup_retention_period = 0`**: automated backups disabled entirely. Critical for production. - **`backup_retention_period < 7`**: too short for forensic investigation of a breach. Medium. - **`backup_retention_period < 35`** (max): acceptable but note for compliance-bound workloads. - **No AWS Backup plan covering this database**: relying solely on RDS automated backups, which don't support cross-account copy or vault lock. Medium. ### Multi-AZ - **`multi_az = false`** on production: availability risk, not directly a security finding. Info unless combined with no backups (then the data has a single point of failure). ### Audit logging - **`enabled_cloudwatch_logs_exports` absent or incomplete**: missing audit/error/general/slowquery logs. Flag for production databases — no forensic trail. Medium. - **Performance Insights disabled (`performance_insights_enabled = false`)**: not a security finding per se, but note as missing telemetry. ### Parameter groups - **`ssl` / `rds.force_ssl` not enabled**: connections can be plaintext. High for production. - **`log_connections` / `log_disconnections` disabled** (PostgreSQL): missing connection audit trail. ## DYNAMODB SECURITY ANALYSIS For every `aws_dynamodb_table`: ### Encryption - **`server_side_encryption` absent or `enabled = false`**: uses AWS-owned key (the default). Data is encrypted but you have no control over the key and no CloudTrail audit of key usage. Medium for production tables. - **`server_side_encryption.enabled = true` with no `kms_key_arn`**: uses AWS-managed key (`aws/dynamodb`). Better than AWS-owned. Acceptable. - **CMK specified**: best. Verify key policy (see ENCRYPTION ANALYSIS). ### Point-in-time recovery - **`point_in_time_recovery` absent or `enabled = false`**: no ability to restore to an arbitrary point in time. Ransomware deletion or corruption is irrecoverable without separate backups. High for production tables. ### Backup - **No AWS Backup plan covering this table**: relying on PITR alone. PITR restores to a new table (not in-place) and is limited to 35 days. For long-term protection, AWS Backup provides vault-locked, cross-account backups. ### Access patterns - **Table policy (via resource-based policy on DynamoDB)**: DynamoDB supports resource-based policies (introduced 2023). If present, analyze for overly broad principals. - **Cross-account access**: table accessed from principals in other accounts without `aws:PrincipalOrgID` condition. ### Global tables - **Replication to regions with weaker controls**: verify all replicas maintain equivalent encryption and access controls. - **Inconsistent encryption across replicas**: if the primary table uses a CMK but a replica region uses AWS-managed key, the security posture is only as strong as the weakest replica. ### Delete protection - **`deletion_protection_enabled = false`** (or absent): DynamoDB tables can be deleted by any principal with `dynamodb:DeleteTable`. High for production tables — single API call destroys all data. ## ELASTICACHE SECURITY ANALYSIS For every `aws_elasticache_cluster` and `aws_elasticache_replication_group`: ### Encryption - **`at_rest_encryption_enabled = false`** (or absent): cache data unencrypted on disk. High for production caches holding session tokens, user data, or sensitive query results. - **`transit_encryption_enabled = false`** (or absent): data in transit between application and cache is plaintext. Interceptable on the VPC network. High for production. - **`transit_encryption_mode`**: when transit encryption is enabled, verify mode is `required` (not `preferred`) for strict enforcement. ### Authentication - **`auth_token` absent on Redis replication groups**: no authentication required to connect. Anyone with network access to the cache port can read/write. High when combined with broad SG ingress (cross-ref `iac-network`). - **`auth_token` hardcoded in Terraform**: finding delegated to `iac-secrets`, but flag the cross-reference. ### Subnet group - **ElastiCache in public subnet**: cache should always be in private subnets. Flag if subnet group includes public subnets. ## REDSHIFT SECURITY ANALYSIS For every `aws_redshift_cluster`: ### Public accessibility - **`publicly_accessible = true`**: Redshift cluster gets a public endpoint. Combined with open SG → direct internet access to data warehouse. Critical with sensitive data. ### Encryption - **`encrypted = false`** (or absent — default is false): data warehouse unencrypted at rest. High for production. - **`kms_key_id` absent when encrypted**: uses AWS-managed key. ### Audit logging - **`logging` block absent**: no query audit trail. Medium for production — no forensic capability for data access investigation. ### Automated snapshots - **`automated_snapshot_retention_period = 0`**: snapshots disabled entirely. High for production. - **`automated_snapshot_retention_period < 7`**: too short. Medium. ## EFS SECURITY ANALYSIS For every `aws_efs_file_system`: ### Encryption - **`encrypted = false`** (or absent — default is false for older API versions): file system data unencrypted. High for production. - **`kms_key_id` absent when encrypted**: uses AWS-managed key. ### File system policy - **`aws_efs_file_system_policy` absent**: no resource-level access control beyond IAM. Medium for production. - **Policy allows anonymous access or overly broad principals**: same analysis as S3 bucket policies. - **Policy does not enforce encryption in transit** (`elasticfilesystem:TlsRequired` condition missing): connections can be plaintext. Medium. ### Mount target security - **Mount targets in public subnets**: EFS accessible from public subnets. Should be private only. High. - **No access points configured** (`aws_efs_access_point` absent): all clients mount with full filesystem access. Medium for multi-tenant or multi-application file systems where isolation is needed. ## EBS SECURITY ANALYSIS For every `aws_ebs_volume`: ### Encryption - **`encrypted = false`** (or absent): volume data unencrypted. Severity depends on what the volume stores and the attached instance's role. - **Account-level EBS default encryption** (`aws_ebs_encryption_by_default`) not enabled: new volumes can be created unencrypted by default. Medium. - **`kms_key_id` absent when encrypted**: uses default `aws/ebs` key. ### Snapshots - **`aws_ebs_snapshot` with no encryption**: snapshot is unencrypted and could be shared cross-account. - **Snapshot sharing**: `aws_ebs_snapshot` shared with other accounts via `create_volume_permissions`. Verify the target account is trusted. ## ENCRYPTION ANALYSIS ### KMS key policy review For every `aws_kms_key`: - **Key policy grants `kms:*` to `Principal: "*"`**: catastrophic — anyone can use, manage, or delete the key. - **Key policy grants `kms:Decrypt` to overly broad principals**: cross-ref with `iac-iam` to determine who effectively has decrypt access. If an internet-facing Lambda role can decrypt production data encryption keys, that's Critical. - **Key policy grants `kms:CreateGrant` broadly**: grants are a back door to key access. A principal with `kms:CreateGrant` can grant itself (or anyone) `kms:Decrypt` without modifying the key policy. - **Key policy uses `kms:ViaService` condition correctly**: restricts key use to specific AWS services (e.g. only S3 can use this key for encryption). Good practice. - **Key admin vs key user separation**: key policy should separate administrative actions (`kms:Create*`, `kms:Delete*`, `kms:Enable*`, `kms:Disable*`, `kms:Put*`, `kms:Update*`, `kms:Revoke*`, `kms:Schedule*`, `kms:Cancel*`) from usage actions (`kms:Encrypt`, `kms:Decrypt`, `kms:GenerateDataKey*`, `kms:ReEncrypt*`, `kms:DescribeKey`). Flag when the same principal has both. ### Key rotation - **`enable_key_rotation = false`** (or absent — default is false): key material is never rotated. Medium for production keys. AWS auto-rotation rotates the backing key material annually while keeping the key ID stable. - **Customer-managed key without rotation for > 365 days**: High. ### Cross-account key access - **KMS key policy grants decrypt to principals in other accounts without conditions**: data encrypted with this key is accessible from the foreign account. Verify intentionality. ### Default encryption vs CMK - **Data store uses SSE-S3 / AWS-managed key instead of CMK**: acceptable for non-sensitive data; flag Medium for production PII/financial data where key-level access control matters. - **Data store uses no encryption at all**: High regardless of data sensitivity — encryption at rest is a baseline control. ### Encryption coverage gaps - **Some data stores encrypted, others not**: inconsistent encryption posture suggests oversight. Flag each unencrypted store individually and note the coverage gap in the summary. ## BACKUP AND DR ANALYSIS This section evaluates ransomware readiness — the ability to survive an attacker who gains write/delete access to production data stores. ### Ransomware readiness scoring For each production data store, compute a ransomware readiness score based on: 1. **Immutability**: Is the data protected against deletion/modification even by privileged principals? - S3 Object Lock (compliance mode): best. - S3 Object Lock (governance mode): good but bypassable. - S3 versioning (without object lock): recoverable if attacker doesn't disable versioning and delete all versions. - No versioning / no object lock: no recovery. 2. **Backup isolation**: Are backups stored in a separate account / region with independent access controls? - AWS Backup with cross-account vault + vault lock: best. - AWS Backup same-account: good but an account-admin attacker can delete. - RDS automated backups only: same-account, same-region, deletable by DB admin. - No backups: no recovery. 3. **Deletion protection**: Can the data store itself be deleted? - `deletion_protection = true` (RDS): requires two-step delete (disable protection, then delete). Good. - No deletion protection: single API call deletes. - S3 bucket with object lock + versioning: objects survive bucket deletion attempts. 4. **Key control**: Can the attacker re-encrypt with their own key? - If data store uses a KMS key the attacker can disable/delete, data is ransomable. - If key policy restricts admin to a separate principal, better. - Multi-region keys with replicas in isolated accounts: best. ### Backup plan analysis For each `aws_backup_plan`: - **Frequency**: less than daily for production → Medium. - **Retention**: less than 30 days → Medium; less than 7 days → High. - **Cross-region copy**: absent for business-critical data → High (single-region failure scenario). - **Cross-account copy**: absent → the backup is only as secure as the account it's in. ### Backup vault analysis For each `aws_backup_vault`: - **Vault lock absent** (`aws_backup_vault_lock_configuration` missing): backups can be deleted by any principal with `backup:DeleteBackupVault` + `backup:DeleteRecoveryPoint`. High for production. - **Vault lock in governance mode** (`changeable_for_days` > 0 and still in cooling-off): can still be modified. Medium. - **Vault lock in compliance mode** (cooling-off expired): immutable. Best. - **Vault policy absent** (`aws_backup_vault_policy` missing): default access — any principal with `backup:*` in the account can manage. Medium. - **Vault policy grants broad access**: `Principal: "*"` without conditions. Critical. - **Vault not encrypted with CMK**: uses default encryption. Medium for production. ### Missing backup coverage Cross-reference all production data stores against backup plans (`aws_backup_selection`): - Production S3 buckets not in any backup plan. - Production RDS instances/clusters not in any backup plan. - Production DynamoDB tables not in any backup plan. - Production EFS file systems not in any backup plan. - Production EBS volumes not in any backup plan. For each gap, flag based on whether the resource has *any* other recovery mechanism (RDS automated backups, S3 versioning, DynamoDB PITR) or none at all. ## DATA CLASSIFICATION Infer data sensitivity from available signals, in order of confidence: 1. **Explicit tags**: `DataClassification=PII`, `DataClassification=Confidential`, `Sensitivity=High`, `Compliance=HIPAA`, `Compliance=PCI`, `Compliance=SOC2`, `DataType=CustomerData`, `DataType=FinancialData`. 2. **Resource names**: names containing `customer`, `user`, `payment`, `billing`, `order`, `transaction`, `health`, `medical`, `patient`, `pii`, `ssn`, `credit`, `financial`, `audit`, `compliance`. 3. **Connected workloads**: a DynamoDB table read by a Lambda named `process-payments` likely holds payment data. An S3 bucket written by a service named `user-data-export` likely holds PII. 4. **Resource type heuristics**: RDS databases and DynamoDB tables are more likely to hold sensitive data than EBS volumes used for ephemeral compute. 5. **Environment**: production resources hold production data; dev/staging may hold synthetic data. When classification is unknown, assume the *more sensitive* option for severity calculations — false-positive on sensitivity is better than false-negative. Data classification feeds into severity for every finding: an unencrypted bucket holding PII is Critical; an unencrypted bucket holding Terraform state is Critical (for different reasons — state contains secrets); an unencrypted bucket holding CloudFront logs is Medium. ## ACCESS PATTERN ANALYSIS For each data store, determine who can read, write, and delete data, combining resource policies (bucket policies, key policies, EFS policies) with identity policies (from `iac-iam`). ### Dangerous access patterns - **Wildcard principal on resource policy**: `Principal: "*"` without meaningful condition → data is accessible to anyone (or any AWS principal, for `"AWS": "*"`). - **Cross-account access without org-binding**: data accessible from foreign accounts without `aws:PrincipalOrgID` or `aws:PrincipalAccount` condition. - **Overly broad delete permissions**: principals with `s3:DeleteObject`, `s3:DeleteBucket`, `rds:DeleteDBCluster`, `dynamodb:DeleteTable`, `backup:DeleteRecoveryPoint` that are internet-reachable or broadly assumable (cross-ref `iac-iam`). - **S3:PutBucketPolicy permission on workload roles**: a compromised workload can rewrite the bucket policy to grant itself (or the attacker) full access. - **KMS key disable/delete permission on workload roles**: a compromised workload can disable the encryption key, rendering data irrecoverable (ransomware-enabler). - **Multiple unrelated services sharing a single KMS key**: blast radius — one key compromise affects all services. - **S3:PutBucketVersioning permission on workload roles**: enables the ransomware primitive of suspending versioning before deleting objects. - **RDS snapshot sharing** (`rds:ModifyDBSnapshotAttribute`): a principal that can share snapshots can exfiltrate entire databases by sharing a snapshot to an attacker-controlled account. - **DynamoDB export to S3**: a principal with `dynamodb:ExportTableToPointInTime` can export full table data to an S3 bucket they control — data exfiltration vector. ### Access audit For production data stores, enumerate the effective access set: - Which IAM principals can `GetObject` / `GetItem` / `DescribeTable`? - Which IAM principals can `PutObject` / `PutItem` / `UpdateItem`? - Which IAM principals can `DeleteObject` / `DeleteItem` / `DeleteTable` / `DeleteDBCluster`? - Which IAM principals can modify the resource policy (`PutBucketPolicy`, `PutKeyPolicy`)? - Which IAM principals can modify encryption (`PutEncryptionConfiguration`, `DisableKey`, `ScheduleKeyDeletion`)? Flag when the set of delete-capable or policy-modifying principals is larger than expected. ## CONTEXTUAL REASONING Every finding's final severity is a function of intrinsic severity AND context. Required dimensions: ### Data sensitivity The most important context for storage findings. A missing encryption finding on a bucket tagged `PII` is Critical; the same finding on a bucket named `temp-build-artifacts-dev` is Low. ### Internet exposure Cross-reference with `iac-network`: - Data stores with direct internet reachability (public RDS, public S3). - Data stores accessed by internet-reachable workloads (ALB → Lambda → S3). - Data stores whose credentials are exposed (cross-ref `iac-secrets`). ### IAM coupling Cross-reference with `iac-iam`: - Who can read/write/delete each data store? - Are data access permissions held by overprivileged or internet-facing roles? - Can any principal modify the resource policy or encryption key? ### Environment / production criticality Inferred from (in order of confidence): - Explicit tags: `Environment=prod`, `Criticality=tier-1`. - Resource names containing `prod`, `prd`, `production`. - Terraform workspace name. - File path (`environments/prod/...`, `live/prod/...`). - Default: `unknown` → use conservative (higher) severity. ### Ransomware readiness Storage findings are uniquely relevant to ransomware. For every data store, assess: - Can an attacker with write access delete all data and backups? - Can an attacker re-encrypt data with a key they control? - How long until the data loss is detected? (Cross-ref `iac-logging-monitoring` for alert coverage.) ### Blast radius If the data store is compromised: - **Organization-wide**: data store holds data for multiple teams/products (shared data lake, central logging bucket). - **Application-wide**: data store serves one application but all of its data. - **Component-level**: single table or bucket for a specific microservice feature. - **Single-resource**: individual EBS volume on one instance. ## ATTACK CHAIN REASONING Compose storage findings with IAM, network, and secrets findings to identify named attack chains. Bounded depth ≤ 5. Starting points: - Internet (anonymous, via public S3 bucket). - Internet (authenticated, via public RDS/Redshift with leaked credentials). - Compromised workload (Lambda, ECS, EC2 with data access). - Compromised CI/CD (with state bucket access or deploy credentials). - Insider threat (developer with broad IAM). Terminal capabilities: - Read all data from a production data store (data breach). - Delete all data and backups (ransomware). - Modify data in a production data store (integrity compromise). - Exfiltrate data via cross-account replication or public bucket. - Escalate from data access to account-wide control (via KMS key policy or bucket policy manipulation). ### Chain templates **Chain: Public S3 bucket → PII exfiltration** ``` 1. S3 bucket policy grants s3:GetObject to Principal: * (no condition). 2. Bucket contains customer PII (inferred from name/tags/connected workloads). 3. Attacker enumerates bucket via DNS brute-force → downloads all objects. ``` **Chain: Compromised workload → bucket policy takeover → data exfiltration** ``` 1. Internet-reachable Lambda has overprivileged role (iac-iam). 2. Role includes s3:PutBucketPolicy on production data bucket. 3. Attacker compromises Lambda → rewrites bucket policy → grants cross-account access. 4. Attacker copies all data to their own account. ``` **Chain: Ransomware via deletion + key destruction** ``` 1. Workload role has s3:DeleteObject, s3:PutBucketVersioning on production bucket. 2. Bucket has versioning enabled but no object lock. 3. Workload role also has kms:ScheduleKeyDeletion on the bucket's KMS key. 4. Attacker suspends versioning → deletes all objects → schedules key deletion. 5. No cross-account backup exists → data irrecoverable. ``` **Chain: Public RDS + hardcoded password → full database compromise** ``` 1. RDS instance publicly_accessible=true + open SG (iac-network). 2. master_password hardcoded in Terraform (iac-secrets). 3. No IAM auth enabled. 4. Attacker connects directly → full read/write/delete. ``` **Chain: State bucket compromise → credential harvesting → multi-environment breach** ``` 1. Terraform state backend S3 bucket has weak IAM / no vault lock. 2. State files contain RDS passwords, Secrets Manager values (iac-secrets). 3. Attacker reads state → extracts credentials for all environments. 4. Credentials unlock databases across prod/staging/dev. ``` For each chain, emit `steps[]`, `prerequisites[]`, `break_at[]`, and cross-skill finding references. ## CONFIDENCE SCORING Every finding carries a `confidence` score from 0.0 to 1.0 indicating how certain the analysis is that the finding represents a real, exploitable issue. | Range | Label | Meaning | |---|---|---| | 0.9–1.0 | **confirmed** | Direct evidence in IaC — missing `aws_s3_bucket_public_access_block`, explicit `acl = "public-read"`, `publicly_accessible = true` on RDS, no encryption configuration present. | | 0.7–0.89 | **high** | Strong signal with minor inference — e.g. bucket policy with `Principal: "*"` parsed, KMS key policy allows broad access, backup retention inferred from resource defaults. | | 0.5–0.69 | **medium** | Requires inference — e.g. data sensitivity inferred from resource name/tags, encryption status depends on provider defaults, cross-account bucket policy with unresolved principal. | | 0.3–0.49 | **low** | Heuristic-based — e.g. data classification inferred solely from bucket name pattern, backup status depends on module internals not visible, Object Lock mode ambiguous. | | 0.0–0.29 | **speculative** | Possible but unverifiable from IaC alone. Emitted only when potential impact is Critical. | ### Confidence signals for storage findings **Boosters (+):** explicit `acl` or `policy` visible in IaC, `aws_s3_bucket_public_access_block` resource absent for the bucket, `publicly_accessible = true` on RDS/Redshift, encryption configuration block entirely missing, no `aws_backup_plan` referencing the resource, versioning explicitly disabled. **Reducers (-):** bucket policy attached via variable, encryption managed by AWS-default (SSE-S3) which is implicit, data sensitivity inferred only from name, backup coverage via AWS Backup plans in separate state, Object Lock status set at account level not visible in IaC. Confidence and severity are independent axes. ## SEVERITY GUIDANCE Severity is *composite and contextual*. Every finding must include a `severity_rationale` explaining the reasoning. | Severity | Criteria | |---|---| | **Critical** | Public S3 bucket with PII/financial data (confirmed or strongly inferred). OR: Public RDS/Redshift with open SG and hardcoded credentials. OR: Production data store with no encryption + no backup + no deletion protection (complete exposure). OR: KMS key policy grants `kms:*` to `Principal: "*"`. OR: S3 bucket with PutBucketPolicy permission on an internet-facing workload role AND no object lock (ransomware + exfiltration). OR: Terraform state bucket publicly accessible. | | **High** | Unencrypted production data store (RDS, DynamoDB, S3, EBS, EFS). OR: Production bucket without versioning or object lock. OR: Production database without deletion protection + skip_final_snapshot=true. OR: KMS key without rotation for production data. OR: Cross-account bucket policy without org-binding to non-trusted account. OR: S3 bucket policy with `Principal: "*"` and only weak conditions. OR: Production RDS with publicly_accessible=true (even if SG is narrow). OR: Backup vault without lock on production data. | | **Medium** | Production data store using AWS-managed key instead of CMK. OR: Bucket without access logging. OR: RDS backup retention < 7 days. OR: DynamoDB without PITR. OR: KMS key admin and user roles not separated. OR: Inconsistent encryption across related data stores. OR: S3 replication to less-secure destination. OR: Missing AWS Backup coverage for production resource with only native backups. | | **Low** | Non-production data store without encryption. OR: Bucket lifecycle with aggressive expiration in non-prod. OR: Versioning suspended on non-prod bucket. OR: RDS without Performance Insights. OR: Single NAT gateway as only concern. | | **Info** | Observations useful for context: "This bucket uses SSE-S3; consider SSE-KMS with CMK for finer access control." OR: "This DynamoDB table uses AWS-owned encryption; this is acceptable for non-sensitive data." | Severity floors and ceilings: - A finding tagged `production=true` or involving PII cannot be lower than Medium. - A finding involving public access to data stores cannot be lower than High. - A finding for which no production/sensitivity signal exists is reported at the level the primitive warrants — do not artificially deflate. - A finding that participates in a ransomware attack chain is reported at least High. ## FALSE POSITIVE REDUCTION Suppress or down-rank likely false positives. Suppression means lower severity or `informational` tag, not silent dropping. 1. **Intentionally public buckets**: buckets named `*-public-*`, `*-static-*`, `*-assets-*`, `*-cdn-*`, `*-website-*`, tagged `Public=true` or `Exposure=internet`, with website configuration or CloudFront origin. Don't flag public access itself; still flag if the bucket contains non-static content, lacks encryption, or has write access enabled. 2. **Log buckets**: S3 buckets used as log targets (referenced by `aws_s3_bucket_logging`, CloudTrail, ELB access logs, CloudFront logs). These are expected to have specific policy shapes (e.g. granting `s3:PutObject` to `logging.s3.amazonaws.com` or `elasticloadbalancing.amazonaws.com`). Don't flag these grants. 3. **Terraform state buckets**: backend buckets often have specific policy shapes. Still flag security issues but don't flag the expected access pattern (Terraform runner needing state read/write). 4. **Replication destination buckets**: buckets that are replication targets often have specific cross-account policies. Verify they match the source bucket's account/org. 5. **AWS-required defaults**: some resources default to AWS-managed encryption, which is acceptable for many use cases. Don't flag AWS-managed key as a finding for non-production, non-sensitive workloads. 6. **Backup retention on non-production**: dev/staging databases with `backup_retention_period = 1` are acceptable. 7. **Read replicas**: RDS read replicas inherit encryption from the primary. Don't flag the replica's encryption as a separate finding. 8. **Test/dev environments**: findings in non-prod environments at one severity level lower, except public access (always at least High) and missing encryption on data that could contain prod-copy data. 9. **CDK/bootstrap resources**: CDK bootstrap creates buckets with specific shapes (staging bucket, asset bucket). Match against known CDK patterns and suppress. 10. **Explicit suppression markers**: honor `# iac-storage:ignore= reason="..."` inline and `IacStorageIgnore` tags. Always require a reason. Record in `suppressions[]`. 11. **Empty buckets**: if `iac-analysis` can determine a bucket has never been written to (new resource, no referencing workload), downgrade findings to Info. 12. **Glacier-only buckets**: buckets that only contain Glacier/Deep Archive objects with lifecycle-only access. Access patterns differ from standard S3. ## CORRELATION OPPORTUNITIES This skill's output is most valuable when correlated with other pipeline skills via shared resource identifiers. Emit `correlation_hints` on every finding. | Correlated skill | What to look for | Why it matters | |---|---|---| | `iac-iam` | Principals with read/write/delete access to data stores we flagged. Principals with `kms:*` on keys we flagged. Principals with `s3:PutBucketPolicy` on buckets we flagged. Principals with `backup:DeleteRecoveryPoint` on vaults we flagged. | Access control is the primary defense for data stores; IAM defines who can breach/ransom them. | | `iac-network` | Data stores with internet reachability (public RDS, public S3). Workloads accessing data stores that are themselves internet-reachable. VPC endpoint configurations for S3/DynamoDB. | Network exposure elevates storage findings from "misconfiguration" to "active attack surface." | | `iac-secrets` | Hardcoded database passwords. Credentials in Terraform state (which lives in a bucket we analyze). API keys that unlock data stores. | Exposed credentials + storage misconfig = immediate breach. | | `iac-logging-monitoring` | CloudTrail data events on S3/DynamoDB. S3 access logging status. RDS audit logging. Backup vault activity monitoring. | Detection coverage determines dwell time after a storage breach. | | `iac-serverless` | Lambda functions accessing data stores we flagged. Lambda execution roles with data permissions. API Gateway → Lambda → data store chains. | Serverless workloads are common data access paths; their security affects data store exposure. | | `iac-report` | All findings + attack paths, grouped, prioritized, deduplicated across skills. | Human-readable output layer. | `correlation_hints` field on each finding: ```json { "shared_resources": ["aws_s3_bucket.data_lake_prod", "aws_kms_key.data_lake_key"], "related_skills": ["iac-iam", "iac-network", "iac-secrets"], "join_keys": { "resource_arn": "arn:aws:s3:::acme-data-lake-prod", "iac_address": "module.data.aws_s3_bucket.data_lake_prod", "kms_key_arn": "arn:aws:kms:us-east-1:123456789012:key/mrk-1234" } } ``` ## OUTPUT FORMAT > See [`examples/output-format.md`](examples/output-format.md) for the full JSON schema, finding fields, and attack path structure. ## EXAMPLE FINDINGS > See [`examples/findings.md`](examples/findings.md) for detailed example findings with severity rationale and evidence. ## EXAMPLE ATTACK PATHS > See [`examples/attack-paths.md`](examples/attack-paths.md) for detailed example attack paths with narratives, step-by-step primitives, and prerequisites. ## EXAMPLE JSON OUTPUT > See [`examples/json-output.md`](examples/json-output.md) for a complete example of the top-level JSON output with summary, findings, attack paths, and suppressions. ## LIMITATIONS The skill is honest about what it does NOT and CANNOT do reliably: 1. **No runtime state**: This is static IaC analysis. A bucket that appears public in IaC may have a manually-applied Block Public Access at the account level. Conversely, a bucket that appears private in IaC may have been made public via console. The skill flags the IaC-visible risk; runtime correlation requires a separate skill. 2. **No data content inspection**: The skill cannot examine what data is actually in a bucket, database, or volume. Data classification is inferred from tags, names, and connected workloads — not from actual content. 3. **S3 Block Public Access at account level invisible**: Account-level S3 Block Public Access settings are typically not in IaC (or are in a separate account-bootstrap IaC). If present, they override bucket-level settings — but this skill cannot see them unless they're in the analyzed IaC. 4. **Module-level abstractions**: When IaC uses heavy module abstraction, the skill depends on `iac-analysis` to flatten before analysis. If `iac-analysis` cannot resolve a reference, the skill emits a warning and proceeds with partial information. 5. **Cross-account graph**: The skill sees only what's in the analyzed IaC. If a replication target bucket is in another account whose IaC is not in scope, the skill flags the replication but cannot verify the destination's security posture. 6. **KMS key policy complexity**: AWS KMS key policies interact with IAM policies in non-obvious ways (the key policy must explicitly grant root-account access before IAM policies can grant key usage). The skill models the common patterns but may not catch every edge case in complex key policy configurations. 7. **Default encryption behavior changes**: AWS has introduced and changed default encryption behavior over time (e.g. S3 now encrypts new objects with SSE-S3 by default as of January 2023). The skill flags explicit misconfigurations but notes when default behavior provides baseline protection. 8. **Backup plan resource selection**: `aws_backup_selection` uses tag-based or resource ARN-based selection. Tag-based selection depends on tags being consistently applied — the skill cannot verify tag consistency at scale. 9. **Naming-based classification inference**: Inference of data sensitivity from names is heuristic. A bucket named `customer-data` might hold test data; a bucket named `temp-files` might hold PII. The skill prefers false positives (over-flag) to false negatives. 10. **Object Lock retroactivity**: Object Lock can only be enabled on a bucket at creation time (the bucket must be created with object lock enabled). The skill flags missing object lock but enabling it requires recreating the bucket, which is operationally complex. 11. **No cost analysis**: Storage optimization (S3 Intelligent-Tiering, Glacier transitions, reserved capacity) is out of scope. The skill focuses on security, not cost. ## FUTURE IMPROVEMENTS Tracked enhancements, roughly ordered by expected impact: 1. **Live-account correlation mode**: Optional mode that, given read-only AWS credentials, cross-references IaC findings against runtime state (e.g. S3 Access Analyzer findings, RDS public snapshot checks, actual KMS key usage via CloudTrail). 2. **Account-level Block Public Access detection**: When account-bootstrap IaC is in scope, incorporate account-level S3 BPA settings to reduce false positives on bucket-level public access findings. 3. **Data classification from connected workloads**: Deeper inference by tracing data flows — if a Lambda writes to bucket A and reads from an API tagged "PII", bucket A likely contains PII. 4. **Differential analysis**: When comparing a PR against main, identify *new* storage misconfigurations introduced by the change. Most useful for PR-time review. 5. **Ransomware simulation scoring**: Formal scoring model (0–100) for ransomware readiness per data store, incorporating immutability, backup isolation, key control, and detection coverage. 6. **Cross-region DR validation**: Verify that cross-region replication targets are in different failure domains and maintain equivalent security controls. 7. **S3 Access Point analysis**: Analyze S3 access points for overly permissive policies and missing VPC restrictions. 8. **Backup restore testing signals**: Flag when backup plans exist but there's no evidence of restore testing (no recent `backup:StartRestoreJob` in CloudTrail — runtime mode only). 9. **Encryption key dependency mapping**: Build a graph of which data stores depend on which KMS keys, to compute blast radius of key compromise/deletion. 10. **Coverage reporting**: Per-run report on which data stores were evaluated, which were skipped (and why), to improve auditor trust. 11. **Suppression governance**: Track suppression aging — flag suppressions in place > N days without re-review. 12. **Compliance-aware findings**: Map findings to specific compliance control IDs (CIS AWS Benchmark, SOC2 CC6.1, PCI DSS 3.4, HIPAA §164.312) for compliance reporting. 13. **Multi-cloud data store coverage**: Deeper support for Azure Storage Accounts, Cosmos DB, GCP Cloud Storage, BigQuery with equivalent detection logic. 14. **Intelligent lifecycle analysis**: Flag when lifecycle rules conflict with compliance retention requirements (e.g. lifecycle deletes at 90 days but compliance requires 7-year retention). 15. **Data residency and sovereignty**: Flag when replication targets are in regions that violate data residency requirements indicated by tags or compliance markers.