2.1.2. Aggregating Security Events

First Principle: Individual security signals are noise; aggregated, correlated signals are intelligence. Without centralized aggregation, a GuardDuty finding in one account and a CloudTrail anomaly in another look like unrelated events — but together they reveal a coordinated attack.

AWS Security Hub is the central aggregation point for security findings across your entire AWS organization:

• Ingests findings from GuardDuty, Inspector, Macie, Config, Firewall Manager, and third-party tools
• Normalizes all findings into AWS Security Finding Format (ASFF)
• Provides security standards benchmarks (CIS, PCI DSS, AWS Foundational)
• Enables cross-account, cross-Region visibility through a delegated administrator

Amazon Security Lake (new in C03) takes aggregation further by creating a centralized security data lake using the Open Cybersecurity Schema Framework (OCSF):

• Automatically collects log and event data from AWS services, third-party sources, and custom sources
• Normalizes everything into OCSF format for consistent querying
• Stores in S3 with Apache Iceberg tables for cost-effective, queryable storage
• Enables third-party SIEM and analytics tool integration through subscriber access

When to use which:

⚠️ Exam Trap: Security Hub aggregates findings (processed alerts). Security Lake aggregates raw logs and events. They serve different but complementary purposes. A question asking about "centralizing raw log data" points to Security Lake, not Security Hub.

Scenario: Your SIEM vendor needs access to CloudTrail logs, VPC Flow Logs, and GuardDuty findings in a normalized format. You configure Security Lake to collect these sources and grant the SIEM subscriber access.

Reflection Question: How does normalizing events into OCSF format solve the problem of correlating data from dozens of different log formats?