Exams / SCS-C03 / Study guide / Security data lakes and third-party tools (Security Lake, OCSF)
Security data lakes and third-party tools (Security Lake, OCSF): SCS-C03 study notes and practice questions
What to know about Security data lakes and third-party tools (Security Lake, OCSF) for the SCS-C03 exam, from the Detection domain (16% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a security team that needs one normalized store of security data from many accounts, Regions and tools, so that analysts and third-party products can query it the same way. You decide whether a data lake fits, and how to set it up so every account is covered without custom parsers.
What Security Lake does
Security Lake collects logs and findings from AWS sources, such as CloudTrail management events, VPC Flow Logs, Route 53 Resolver query logs, Security Hub findings and EKS audit logs.
It normalizes that data to the Open Cybersecurity Schema Framework (OCSF), so a login event from one source has the same fields as one from another. It stores the data as Parquet files in S3 buckets that you own.
A delegated administrator enables Security Lake for the organization and chooses the Regions and sources. Member accounts are covered without per-account setup.
Data is stored per Region. A rollup Region lets you bring data from several Regions together for queries.
Subscribers read the data. A query access subscriber, such as Athena in another account or a third-party analytics product, queries the tables in place through Lake Formation. A data access subscriber is notified of new objects and reads them directly from S3, which suits a SIEM that ingests data.
You can add custom sources that write OCSF-formatted events.
How to choose
Scenario wording
Pick
One normalized, long-term store of security data from many accounts and tools
Security Lake
An ad hoc search of CloudTrail files already in S3
Athena on the existing trail bucket
A third-party tool must query the data where it sits
Security Lake query access subscriber
A SIEM must ingest new security data as it arrives
Security Lake data access subscriber
React to one event within seconds
EventBridge rule, not a data lake
Interactive search and dashboards for analysts
OpenSearch Service, with Security Lake as a source if needed
Find out which threats exist
GuardDuty or Security Hub. Security Lake stores data; it doesn’t detect threats
Common traps
Enabling Security Lake in each account instead of through the delegated administrator, which leaves gaps and extra cost.
Treating OCSF as a log format you must produce yourself. It is a shared schema, and the managed sources already write to it.
Building custom export jobs for a SIEM when a subscriber can get query or data access directly.
Expecting Security Lake to alert. It holds data for analysis; findings come from GuardDuty, Security Hub and your own rules.
Forgetting Regions. Data sits in the Regions where you enable it, so a question about all Regions needs rollup or enablement in each.
A property insurer runs workloads in four AWS Regions across 60 accounts. Its security analysts want to query VPC flow logs, CloudTrail management events, Amazon Route 53 Resolver query logs and Security Hub findings from one place, without building data pipelines.
The security tooling account must administer the service for the whole organization, and new accounts must be included automatically. The team also wants the data from the four Regions consolidated into one rollup Region, to keep queries simple.
Which solution meets these requirements with the LEAST operational overhead?
Choose one answer.
AA. Enable Amazon Security Lake in each member account separately, with each owner choosing its own sources and its own Regional S3 bucket. Analysts then query each bucket in turn.
BB. Create S3 buckets in each Region, deliver every log type to them with custom Lambda functions, and catalog the data with AWS Glue crawlers for Amazon Athena.
CC. Make the security tooling account the Security Lake delegated administrator. Set one rollup Region for the four Regions, and select the four log and finding sources.
DD. Turn on Security Lake only in the Region where most workloads run, and leave out the other three Regions because their traffic is smaller.
Show the answer and explanation
Answer: C
A. Wrong: Each account keeps its own data, so analysts must query many buckets and no single administrator sees the whole organization. New accounts also need manual setup, which breaks the automatic inclusion requirement.
B. Wrong: This can work, but writing and maintaining the delivery functions and crawlers is the overhead the team wants to avoid. It also does not give the normalized OCSF schema that Security Lake provides for these sources.
C. Right: Correct. The delegated administrator enrolls member accounts automatically, and the rollup Region keeps the data in one place for analysts. Security Lake normalizes the sources to the OCSF schema, so the managed setup needs no pipeline code. Learn more: What is Amazon Security Lake? (opens in a new tab)
D. Wrong: Leaving out three Regions means their logs are never collected, so the coverage requirement fails. Attacks in smaller Regions would also be invisible to the analysts.
Explanation
Security Lake works best with a delegated administrator, which enrolls accounts and Regions in one setup, and with a rollup Region for consolidated queries. The managed service normalizes the sources, so no custom pipeline is needed. Per-account setup, custom pipelines and partial Region coverage each fail a stated requirement.
Want more on Security data lakes and third-party tools (Security Lake, OCSF)? The 5 full-length practice sets have 8 more Security data lakes and third-party tools (Security Lake, OCSF) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Security data lakes and third-party tools (Security Lake, OCSF)