A media company runs CloudFront with AWS WAF and uses a third-party SIEM that only parses OCSF. The security team must centralize WAF findings for the SIEM without custom parsing, retain raw logs for 90 days, and keep query costs low. Which integration should the engineer configure to meet the OCSF ingestion requirement?
Select an answer to reveal the explanation.
Short Explanation
You’ve got WAF findings and a SIEM that speaks only OCSF, so let Security Lake handle the conversion for you. Its OCSF normalization turns native logs into a ready-to-consume format, like a universal power adapter.
Full Explanation
Amazon Security Lake is the right fit because it centrally stores security data and converts supported sources, including WAF, into OCSF. Your OCSF-only SIEM can therefore consume WAF findings without custom parsing, while S3 lifecycle policies can retain raw logs for 90 days and subscriber access can help keep query costs low. Sending WAF logs through Firehose to S3 with OCSF partitioning fails conceptually: partitioning organizes data for queries but does not perform managed OCSF normalization, so the SIEM would still need custom parsing. Security Lake with 30-day expiration fails the retention requirement because lifecycle expiration would remove data before the required 90 days, even though it provides OCSF ingestion. Security Lake configured only for CloudTrail and Route 53 fails the coverage requirement: without WAF enabled as a source, WAF findings are not normalized or centralized. Exam caveat: distinguish Security Lake’s managed OCSF conversion from Firehose delivery, which can centralize logs but does not itself normalize WAF data to OCSF. As a practical check, confirm WAF is enabled as a Security Lake source in the relevant Regions, verify the S3 lifecycle retains raw data for 90 days, and validate that the SIEM subscriber receives OCSF records before retiring any interim pipeline.