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.2User, asset, and entity context
Understand identifying relevant threat intelligence in the enterprise, differentiating event vs entity data log sources (Cloud Audit Logs, Active Directory organizational context), and evaluating event/entity data matches for enrichment using aliasing fields.
Entity context turns detection from isolated dots into contextual lines. Tie actions to whose and which assets to make alerts meaningful.
2.2.1Event data and entity data
Logs are broadly two kinds. Event data records "when what happened"—behavior (Cloud Audit Logs logins/API calls, network traffic). Entity data is context for "who/which asset" (Active Directory organizational context—a user's department/title/groups, an asset's owner/criticality). Differentiate them, and evaluate relevant threat intelligence (GTI IOCs, actor TTPs) against the enterprise. Map "record of behavior = event data" and "context of who/what = entity data."
2.2.2Enrichment and aliasing
Matching events with entities to enrich events raises detection accuracy and investigation speed (e.g., attach a user's title, device criticality, and prior risk score to a login event). But the same user/asset appears under multiple identifiers (username/email/UPN/hostname/IP), so reconcile them via aliasing fields (associate as the same entity) before matching. Map "add context to events = enrich with entities" and "reconcile multiple identifiers = aliasing fields."
Common: requirement → means. E.g., "behavior record of when/what" = event data (Cloud Audit Logs); "context of who/which asset (department/criticality)" = entity data (AD organizational context); "attach a user's title/risk to a login event" = enrich with entity; "reconcile username/email/UPN as the same person" = aliasing fields.
Watch the mix-ups: (1) Do not confuse event data (behavior) vs entity data (context)—detect on events, add context from entities. (2) Without aliasing, the same person/asset is treated as different—causing misses/duplicates. (3) Entity context also improves detection-rule accuracy (entity graph, later chapter).
2.2.3Section summary
- Event data = behavior (Cloud Audit Logs); entity data = context (AD organizational context)
- Enrich events with entities to raise detection accuracy/investigation speed
- Reconcile multiple identifiers via aliasing fields before matching
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Logs recording "when, who, did what" behavior fall into which category?
Q2. Context of "who/which" like a user's department/title/groups or an asset's owner/criticality is which?
Q3. The same user appears under username/email/UPN. To associate them as the same entity before matching, what do you use?
Q4. To attach a user's title, device criticality, and prior risk score to a login event to raise detection accuracy—what is this?
Q5. Which is the best example of "relevant threat intelligence" to apply to the enterprise?