What's changed: Created Professional Security Operations Engineer Chapter 2 (Domain 2 "Data management": ingestion approaches/tools, SCC Event Threat Detection, Google SecOps parsers (modifications/extensions), UDM normalization, new labels, ingestion-cost management; threat intelligence info, event vs entity data (Cloud Audit Logs/AD organizational context), enrichment via aliasing fields).
2.1Ingesting logs for security tooling
Understand determining data-ingestion approaches in security tools (SCC, Google SecOps), configuring ingestion tools/features, assessing required logs for detection/response (incl. automated sources, SCC Event Threat Detection), evaluating Google SecOps parsers and configuring parser modifications/extensions, data normalization (UDM) from log sources, evaluating new labels, and managing log/ingestion costs.
The quality of detection and investigation depends on ingested-log quality. Ingest the right logs correctly, normalize them, and control cost.
2.1.1Log ingestion and normalization
Configure data ingestion into Google SecOps/SCC via feeders (ingestion tools) or native features. Assess logs required for detection/response, and enable SCC Event Threat Detection (detects known threats from Admin Activity/Data Access logs, etc.) for cloud threats. Parse diverse log sources with parsers, extracting custom fields via parser modifications/extensions as needed. Google SecOps normalizes ingested logs into UDM (Unified Data Model), enabling source-independent search/detection under a unified schema. Also evaluate new labels useful for detection/enrichment. Map "source-independent unified schema = UDM normalization" and "tune log parsing = parser modifications/extensions."
2.1.2Managing ingestion cost
More logs are not always better. Manage log and ingestion cost, prioritizing logs valuable for detection/investigation (thin out/relocate noisy low-value logs). Balance required coverage—including automated sources (Event Threat Detection, feeds)—against cost. Map "cost from large low-value logs = optimize with prioritization and filtering."
Common: requirement → means. E.g., "search/detect across differing log sources under a unified schema" = UDM normalization (Google SecOps); "extract needed fields from a custom-format log" = parser modifications/extensions; "detect known threats from cloud Admin Activity/Data Access" = SCC Event Threat Detection; "control ingestion cost" = prioritize/filter low-value logs.
Watch the mix-ups: (1) UDM (normalized unified schema) vs parsers (raw log → field extraction) are different stages. (2) Event Threat Detection (SCC built-in) vs Google SecOps detection rules are different layers—use both. (3) Indiscriminate ingestion inflates cost—prioritize by value.
Network telemetry is an important log source too. VPC Flow Logs record network flows within a VPC (source/destination, ports, bytes, allow/deny, etc.). Ingested into Google SecOps and normalized to UDM, they support detecting and hunting lateral movement and suspicious egress.
2.1.3Section summary
- Ingestion = feeders/native features; cloud threats = SCC Event Threat Detection
- Google SecOps normalizes logs to UDM; parse custom logs via parser modifications/extensions
- Optimize ingestion cost by prioritizing/filtering by value
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To search/detect across diverse log sources under a source-independent unified schema, what in Google SecOps?
Q2. To correctly extract detection fields from a custom-format log, what do you configure in Google SecOps?
Q3. To auto-detect known threats (suspicious logins, privilege escalation) from cloud Admin Activity/Data Access logs, which is best?
Q4. Noisy logs that don't aid detection/investigation are inflating ingestion cost. Which is the best response?
Q5. Which correctly relates UDM and parsers?