Skip to content

Commit 4bfaeb9

Browse files
xxyjoelclaude
xxyjoel
and
claude
committed
Promote 10 ingest pipeline recommendations (313 → 323)
Add 10 new recommendations across 8 services: dynamodb, account, rds (x3), acm, organizations, network-firewall, systems-manager, and vpc. All validated against schema and confirmed unique via TF-IDF dedup (scores 0.174–0.351, well below 0.70 threshold). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1 parent 2f00526 commit 4bfaeb9

19 files changed

+392
-437
lines changed

‎data/by-service/account.json‎

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
{
2+
"service": "account",
3+
"count": 1,
4+
"misconfigurations": [
5+
{
6+
"id": "3e4cd300-6cff-4fd6-9504-38c0f38ab2ac",
7+
"service_name": "account",
8+
"scenario": "AWS account does not have alternate security contact information configured",
9+
"alert_criteria": "AWS account has no security contact defined in the alternate contacts settings. Security Hub control Account.1 fails.",
10+
"recommendation_action": "Configure an alternate security contact for the AWS account by navigating to Account Settings and providing a security contact email, phone number, and name. This ensures AWS can reach the appropriate team for security-related notifications.",
11+
"risk_detail": "security, operations",
12+
"build_priority": 1,
13+
"action_value": 2,
14+
"effort_level": 1,
15+
"risk_value": 2,
16+
"recommendation_description_detailed": "AWS uses the alternate security contact to notify your organization about security-related issues. Without a designated security contact, critical notifications such as abuse reports, vulnerability disclosures, and compliance alerts may go to the root account email, which might not be monitored by the security team. This is a CIS AWS Foundations Benchmark v5.0.0 requirement (control 1.2) and maps to NIST 800-53 CM-2. Configuring this contact takes minimal effort and ensures that security-relevant communications reach the right personnel promptly, reducing mean time to response for security incidents.",
17+
"category": "security",
18+
"references": [
19+
"https://docs.aws.amazon.com/securityhub/latest/userguide/account-controls.html#account-1"
20+
],
21+
"metadata": {
22+
"created_at": "2026-02-09T05:38:18Z",
23+
"updated_at": "2026-02-09T05:38:18Z",
24+
"contributors": [
25+
"ingest-pipeline"
26+
],
27+
"source": "AWS Security Hub Controls"
28+
},
29+
"tags": [
30+
"security-hub",
31+
"account",
32+
"cis-benchmark",
33+
"incident-response",
34+
"contact-information"
35+
]
36+
}
37+
]
38+
}

‎data/by-service/acm.json‎

Lines changed: 36 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"service": "acm",
3-
"count": 2,
3+
"count": 3,
44
"misconfigurations": [
55
{
66
"id": "9be76839-271a-4733-b947-c4c3705da1f5",
@@ -55,6 +55,40 @@
5555
"source": "Initial CSV Import"
5656
},
5757
"tags": []
58+
},
59+
{
60+
"id": "75a780d7-e8f9-4175-bc93-8c5c5039fd4e",
61+
"service_name": "acm",
62+
"scenario": "RSA certificates managed by ACM use a key length smaller than 2048 bits",
63+
"alert_criteria": "An ACM-managed RSA certificate has a key length below 2048 bits. Security Hub control ACM.2 fails.",
64+
"recommendation_action": "Delete RSA certificates with key lengths smaller than 2048 bits and replace them with certificates using at least 2048-bit keys. For ACM-issued certificates, request new certificates which default to 2048 bits. For imported certificates, regenerate them with the proper key length before re-importing.",
65+
"risk_detail": "security",
66+
"build_priority": 0,
67+
"action_value": 3,
68+
"effort_level": 1,
69+
"risk_value": 3,
70+
"recommendation_description_detailed": "The strength of RSA encryption directly correlates with key size. Certificates with key lengths below 2048 bits are considered cryptographically weak and may be vulnerable to brute-force attacks as computing power increases. Major browser vendors and certificate authorities have mandated 2048-bit minimums since 2014. PCI DSS v4.0.1 (control 4.2.1) requires strong cryptography for data in transit. ACM automatically issues certificates with 2048-bit keys, but imported certificates may have shorter keys if generated externally with weak parameters. Since key length cannot be changed after import, affected certificates must be replaced entirely.",
71+
"category": "security",
72+
"references": [
73+
"https://docs.aws.amazon.com/securityhub/latest/userguide/acm-controls.html#acm-2"
74+
],
75+
"metadata": {
76+
"created_at": "2026-02-09T05:38:18Z",
77+
"updated_at": "2026-02-09T05:38:18Z",
78+
"contributors": [
79+
"ingest-pipeline"
80+
],
81+
"source": "AWS Security Hub Controls"
82+
},
83+
"tags": [
84+
"security-hub",
85+
"acm",
86+
"certificates",
87+
"encryption",
88+
"pci-dss",
89+
"tls",
90+
"key-management"
91+
]
5892
}
5993
]
60-
}
94+
}

‎data/by-service/dynamodb.json‎

Lines changed: 35 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"service": "dynamodb",
3-
"count": 11,
3+
"count": 12,
44
"misconfigurations": [
55
{
66
"id": "b4839001-ddb1-4001-c001-001000000001",
@@ -357,6 +357,39 @@
357357
"source": "Initial CSV Import"
358358
},
359359
"tags": []
360+
},
361+
{
362+
"id": "21e8990b-f442-4975-8927-70399f242f0f",
363+
"service_name": "dynamodb",
364+
"scenario": "DynamoDB tables with critical data lack cross-account global table replication for disaster recovery isolation",
365+
"alert_criteria": "DynamoDB tables classified as critical or high-availability are not configured with multi-account global tables replication. Single-account tables lack the account-level isolation needed to protect against account-level incidents, misconfigurations, or security compromises.",
366+
"recommendation_action": "Evaluate critical DynamoDB tables for multi-account global table configuration using the new cross-account replication feature. Create replica tables in separate AWS accounts and regions to provide account-level isolation for disaster recovery. Monitor replication latency using the ReplicationLatency CloudWatch metric. Implement resource-based policies to control which accounts can join the replication group.",
367+
"risk_detail": "reliability, security",
368+
"build_priority": 2,
369+
"action_value": 2,
370+
"effort_level": 2,
371+
"risk_value": 2,
372+
"recommendation_description_detailed": "DynamoDB global tables support multi-Region replication for high availability, but same-account replicas are still vulnerable to account-level incidents such as credential compromise, SCPs that restrict operations, or accidental account suspension. The new multi-account global tables feature enables replication across separate AWS accounts, providing additional isolation layers that limit the blast radius of misconfigurations, security incidents, or account-level issues. This is particularly important for organizations that operate with strict disaster recovery requirements or need compliance with data isolation mandates. Multi-account replicas also enable proper cost attribution across business units and alignment with organizational account structures. Each replica must reside in a separate account and Region, and the feature uses resource-based policies for cross-account authorization.",
373+
"category": "database",
374+
"references": [
375+
"https://aws.amazon.com/blogs/database/amazon-dynamodb-global-tables-now-support-replication-across-aws-accounts/"
376+
],
377+
"metadata": {
378+
"created_at": "2026-02-09T05:38:18Z",
379+
"updated_at": "2026-02-09T05:38:18Z",
380+
"contributors": [
381+
"ingest-pipeline"
382+
],
383+
"source": "AWS Database Blog"
384+
},
385+
"tags": [
386+
"dynamodb",
387+
"global-tables",
388+
"disaster-recovery",
389+
"multi-account",
390+
"replication",
391+
"high-availability"
392+
]
360393
}
361394
]
362-
}
395+
}

‎data/by-service/network-firewall.json‎

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
{
2+
"service": "network-firewall",
3+
"count": 1,
4+
"misconfigurations": [
5+
{
6+
"id": "b86ef141-f21b-4818-9062-fee738816c22",
7+
"service_name": "network-firewall",
8+
"scenario": "AWS Network Firewall does not have active threat defense enabled for real-time malware protection",
9+
"alert_criteria": "AWS Network Firewall rule groups do not include managed threat intelligence rule groups for active threat defense. No active threat defense subscription is configured.",
10+
"recommendation_action": "Enable AWS Network Firewall active threat defense by subscribing to managed threat intelligence rule groups. Configure the firewall to use MadPot-sourced threat intelligence for DNS, HTTP, and TLS SNI inspection layers. Review and enable all available threat defense rule categories including malware, command-and-control, and reconnaissance blocking.",
11+
"risk_detail": "security",
12+
"build_priority": 1,
13+
"action_value": 3,
14+
"effort_level": 2,
15+
"risk_value": 3,
16+
"recommendation_description_detailed": "AWS Network Firewall active threat defense provides real-time protection by leveraging threat intelligence from MadPot, Amazon's network of honeypot sensors that actively monitor global attack patterns. Without active threat defense, your VPC workloads lack automated protection against emerging threats such as new malware distribution domains, command-and-control servers, and reconnaissance scanning. Active threat defense automatically translates new threat intelligence into protective firewall rules within 30 minutes of discovery, using a multi-layered Swiss cheese defense model that blocks threats across DNS, HTTP, and TLS inspection points. This is critical for defending against cryptomining campaigns and other automated attacks that can compromise instances within minutes of discovery.",
17+
"category": "networking",
18+
"references": [
19+
"https://aws.amazon.com/blogs/security/real-time-malware-defense-leveraging-aws-network-firewall-active-threat-defense/"
20+
],
21+
"metadata": {
22+
"created_at": "2026-02-09T05:38:18Z",
23+
"updated_at": "2026-02-09T05:38:18Z",
24+
"contributors": [
25+
"ingest-pipeline"
26+
],
27+
"source": "AWS Security Blog"
28+
},
29+
"tags": [
30+
"network-firewall",
31+
"threat-intelligence",
32+
"malware",
33+
"ids-ips",
34+
"madpot",
35+
"real-time-protection"
36+
]
37+
}
38+
]
39+
}

‎data/by-service/organizations.json‎

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
{
2+
"service": "organizations",
3+
"count": 1,
4+
"misconfigurations": [
5+
{
6+
"id": "77ef079b-c64e-403b-973f-6782b3f8087d",
7+
"service_name": "organizations",
8+
"scenario": "AWS account is not part of an AWS Organizations organization for centralized governance",
9+
"alert_criteria": "AWS account is standalone and not a member of any AWS Organizations organization. Security Hub control Account.2 fails.",
10+
"recommendation_action": "Create or join an AWS Organizations organization to enable centralized management, consolidated billing, service control policies (SCPs), and cross-account security governance. Use AWS Organizations to implement guardrails and manage permissions across all accounts.",
11+
"risk_detail": "security, operations, cost",
12+
"build_priority": 1,
13+
"action_value": 3,
14+
"effort_level": 2,
15+
"risk_value": 2,
16+
"recommendation_description_detailed": "Operating AWS accounts outside of AWS Organizations prevents centralized governance, making it difficult to enforce security policies consistently, manage budgets, and maintain compliance. Without Organizations, you cannot leverage Service Control Policies (SCPs) to set permission guardrails, use AWS CloudFormation StackSets for cross-account deployments, or enable delegated administration for services like Security Hub, GuardDuty, and AWS Config. This control maps to NIST 800-53 CA-9(1) and CM-2. Organizations also enables consolidated billing for cost optimization and simplified account management at scale.",
17+
"category": "security",
18+
"references": [
19+
"https://docs.aws.amazon.com/securityhub/latest/userguide/account-controls.html#account-2"
20+
],
21+
"metadata": {
22+
"created_at": "2026-02-09T05:38:18Z",
23+
"updated_at": "2026-02-09T05:38:18Z",
24+
"contributors": [
25+
"ingest-pipeline"
26+
],
27+
"source": "AWS Security Hub Controls"
28+
},
29+
"tags": [
30+
"security-hub",
31+
"organizations",
32+
"governance",
33+
"multi-account",
34+
"scp",
35+
"centralized-management"
36+
]
37+
}
38+
]
39+
}

‎data/by-service/rds.json‎

Lines changed: 103 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"service": "rds",
3-
"count": 19,
3+
"count": 22,
44
"misconfigurations": [
55
{
66
"id": "08c3c3cd-25d9-4cb6-8c30-926c823276a8",
@@ -556,6 +556,107 @@
556556
"source": "Initial CSV Import"
557557
},
558558
"tags": []
559+
},
560+
{
561+
"id": "4dd1933d-e014-4a2f-b044-497c050c5983",
562+
"service_name": "rds",
563+
"scenario": "RDS Proxy subnets have insufficient available IP addresses causing connection failures and blocking security patches",
564+
"alert_criteria": "Amazon RDS event ID RDS-EVENT-0243 is generated indicating insufficient available IP addresses in subnets configured for RDS Proxy. Available IP addresses in RDS Proxy subnets fall below the minimum reservation threshold for the database instance class size.",
565+
"recommendation_action": "Monitor RDS Proxy subnet IP utilization using CloudWatch and RDS events. When IP address exhaustion is detected, expand VPC CIDR ranges, create new subnets with adequate address space, and migrate the RDS Proxy to the new subnet configuration using a parallel deployment approach. For long-term resolution, consider migrating to IPv6 if workloads support it. Plan subnet sizing based on the IP reservation requirements documented for each RDS instance class.",
566+
"risk_detail": "security, reliability, performance",
567+
"build_priority": 1,
568+
"action_value": 2,
569+
"effort_level": 2,
570+
"risk_value": 2,
571+
"recommendation_description_detailed": "Amazon RDS Proxy dynamically adjusts its capacity based on database instance size, number of registered instances, and scaling operations. When subnets lack sufficient available IP addresses, RDS Proxy performance degrades through increased query latency and connection failures. More critically, IP address exhaustion prevents the Amazon RDS team from applying essential OS security patches to Proxy servers, exposing infrastructure to security vulnerabilities. It also blocks new feature availability for the proxy. Organizations should proactively monitor subnet IP utilization and plan capacity based on the minimum IP reservation requirements documented for each database instance class. The RDS-EVENT-0243 event provides an early warning signal before critical impact occurs.",
572+
"category": "database",
573+
"references": [
574+
"https://aws.amazon.com/blogs/database/managing-ip-address-exhaustion-for-amazon-rds-proxy/"
575+
],
576+
"metadata": {
577+
"created_at": "2026-02-09T05:38:18Z",
578+
"updated_at": "2026-02-09T05:38:18Z",
579+
"contributors": [
580+
"ingest-pipeline"
581+
],
582+
"source": "AWS Database Blog"
583+
},
584+
"tags": [
585+
"rds",
586+
"rds-proxy",
587+
"networking",
588+
"ip-exhaustion",
589+
"vpc",
590+
"subnet-planning",
591+
"capacity"
592+
]
593+
},
594+
{
595+
"id": "5c3d02fe-0ca2-45fe-be46-ef6ac1c678be",
596+
"service_name": "rds",
597+
"scenario": "RDS for SQL Server multi-tenant instances expose all database names to authenticated users by default",
598+
"alert_criteria": "RDS for SQL Server instances hosting multiple tenant databases have not used the rds_manage_view_db_permission stored procedure to restrict database name visibility per login. All authenticated users can view all database names in the instance.",
599+
"recommendation_action": "Use the Amazon RDS for SQL Server custom stored procedure msdb.dbo.rds_manage_view_db_permission to deny database visibility for tenant-specific logins. Apply this procedure to each tenant login so they can only see their own database names while maintaining full access to their authorized databases. Validate the configuration by confirming restricted visibility and document the process for new tenant onboarding.",
600+
"risk_detail": "security",
601+
"build_priority": 2,
602+
"action_value": 2,
603+
"effort_level": 1,
604+
"risk_value": 2,
605+
"recommendation_description_detailed": "By default, SQL Server's PUBLIC role allows all authenticated users to view every database name on the instance. In multi-tenant environments where database names may contain or reveal tenant identifiers, this default behavior creates an information disclosure risk. Tenants can discover the existence of other tenants, potentially revealing business relationships, customer names, or organizational structure. For ISVs and SaaS providers hosting multiple customer databases on shared RDS for SQL Server instances, this is a significant concern that can violate data isolation requirements and tenant confidentiality expectations. The RDS-specific stored procedure rds_manage_view_db_permission provides per-login control over database visibility without requiring server-level permission changes that are not available in the managed RDS environment.",
606+
"category": "database",
607+
"references": [
608+
"https://aws.amazon.com/blogs/database/control-database-name-visibility-in-amazon-rds-for-sql-server-instances/"
609+
],
610+
"metadata": {
611+
"created_at": "2026-02-09T05:38:18Z",
612+
"updated_at": "2026-02-09T05:38:18Z",
613+
"contributors": [
614+
"ingest-pipeline"
615+
],
616+
"source": "AWS Database Blog"
617+
},
618+
"tags": [
619+
"rds",
620+
"sql-server",
621+
"multi-tenant",
622+
"information-disclosure",
623+
"tenant-isolation",
624+
"saas"
625+
]
626+
},
627+
{
628+
"id": "edc58eac-b68f-45ff-9905-28165178d256",
629+
"service_name": "rds",
630+
"scenario": "Amazon RDS for MySQL or Aurora MySQL audit logs are not exported to S3 for long-term retention and compliance analysis",
631+
"alert_criteria": "RDS for MySQL or Aurora MySQL instances have audit logging enabled but no automated export mechanism to Amazon S3 is configured. Audit logs remain only in CloudWatch Logs without long-term archival or structured analysis capability.",
632+
"recommendation_action": "Implement automated export of MySQL audit logs to Amazon S3 using either batch processing (CloudWatch Logs export tasks triggered by EventBridge on a schedule) or real-time processing (Amazon Data Firehose subscribed to CloudWatch Logs). Configure S3 lifecycle policies for cost-effective long-term retention. Set up Athena tables for SQL-based audit log querying and consider QuickSight dashboards for ongoing monitoring.",
633+
"risk_detail": "security, operations",
634+
"build_priority": 2,
635+
"action_value": 2,
636+
"effort_level": 2,
637+
"risk_value": 2,
638+
"recommendation_description_detailed": "Database audit logs are essential for security investigations, compliance reporting, and tracking user activities including queries executed, data changes, and authentication attempts. While RDS for MySQL and Aurora MySQL provide built-in audit logging to CloudWatch Logs, retaining logs solely in CloudWatch is not cost-effective for long-term storage and limits analysis capabilities. Exporting audit logs to S3 enables durable, cost-effective retention with integration into analytics tools like Athena for ad-hoc SQL queries, QuickSight for visual dashboards, and Lambda/SNS for automated alerting on suspicious patterns such as failed login spikes or after-hours access to sensitive tables. This is a requirement for multiple regulatory frameworks including PCI DSS, HIPAA, and SOX, which mandate retention and regular analysis of database audit logs.",
639+
"category": "database",
640+
"references": [
641+
"https://aws.amazon.com/blogs/database/automate-the-export-of-amazon-rds-for-mysql-or-amazon-aurora-mysql-audit-logs-to-amazon-s3-with-batching-or-near-real-time-processing/"
642+
],
643+
"metadata": {
644+
"created_at": "2026-02-09T05:38:18Z",
645+
"updated_at": "2026-02-09T05:38:18Z",
646+
"contributors": [
647+
"ingest-pipeline"
648+
],
649+
"source": "AWS Database Blog"
650+
},
651+
"tags": [
652+
"rds",
653+
"aurora",
654+
"mysql",
655+
"audit-logs",
656+
"compliance",
657+
"s3-export",
658+
"long-term-retention"
659+
]
559660
}
560661
]
561-
}
662+
}

0 commit comments

Comments
 (0)