Correlate cloud and endpoint evidence without guessing identity

TL;DR: Correlate observations through supported identity and time relationships. A shared address or platform-generated incident grouping is a hypothesis to inspect, not proof that every event has the same cause.

Where you are. Your connector now preserves the required fields; this lesson uses them to scope a fictional incident.

Lab packet: one export, two identities and a reused address

Continue the fictional ShopStream investigation. A support login, a temporary cloud role and an export receipt arrive through different collectors. The address 192.0.2.44 is a documentation-only fixture address shared by several sessions. It is not an indicator from a real campaign.

Your first deliverable is an evidence graph with typed edges: authenticated session, accepted job, worker completion and object set. An edge means the sources supplied a relationship, not that two events happened nearby. The target claim is narrow: which accepted request can be linked to a completed export, and which user/session context belongs to it?

Read the incident packet

The fictional packet contains an endpoint alert, a cloud role change and a document-store read. Two employee devices share the same public egress address. The cloud session record links one user to a specific role session, while the endpoint alert belongs to the other device.

Create a hypothesis table with supporting evidence, contradictory evidence and missing evidence. Do not merge the endpoint alert into the cloud incident solely because the addresses match. Shared networks and reused addresses make that join too weak.

Use the strongest available relationships

Stable device IDs, principal IDs, role-session identifiers and request IDs can support more precise joins. Preserve the mapping's time range because devices and roles change ownership. A display name is useful for readers but should not replace the immutable identifier used for a response action.

Compare event time and collection delay from the prior lesson. A late cloud record can appear after containment while describing earlier activity. Without both times, an investigator might incorrectly conclude that containment failed or that a new action occurred.

Join data and authority context

The document store's classification indicates personal information in supported objects. The role's effective permissions explain possible access. The recorded read identifies a specific operation within the logging scope. Keep those facts separate so the impact statement does not turn the role's full permission set into an observed disclosure count.

A successful request can still be unauthorized in business terms if a credential was misused. Compare the action with the approved workflow and owner expectations. Authentication proves a credential was accepted under the service's rules, not that the human or workload intended the resulting operation.

Contain at the relevant boundary

If a credential was stolen, isolating one endpoint may not stop its use from another system. Review the issuer, sessions and downstream grants. Conversely, disabling a cloud identity does not repair a compromised endpoint. Select response actions for the established paths and keep unrelated systems outside the action scope.

The deliverable is a bounded incident hypothesis, not a polished story that fills every gap. State which records belong together, which remain separate and what additional evidence could change that judgment. Retain alternate explanations until the observations distinguish them.

Join on authority and object identity

A business job identifier can bridge the interactive request and a background worker, but only within its documented namespace. Here the job key includes tenant. User u7 in the two tenants is not one identity, and a worker is not the human who requested the job. Preserve both: the initiating subject explains authority, while the executing workload explains the action path and available containment controls.

This offline join requires tenant, session and job agreement. It explicitly checks temporal ordering in event time. It does not use ingest order, because the accepted request arrives after the completion receipt. Production parsers must also preserve service/account namespaces and the authenticity of propagated identifiers; an arbitrary user-supplied request ID alone is not trustworthy evidence of causality.

sessions = [
    {"tenant": "shop", "session": "s9", "user": "u7", "start": 0, "end": 900},
    {"tenant": "market", "session": "s10", "user": "u7", "start": 90, "end": 900},
]
requests = [
    {"tenant": "shop", "session": "s9", "job": "j4", "time": 60, "allowed": True},
    {"tenant": "market", "session": "s10", "job": "j4", "time": 80, "allowed": True},
    {"tenant": "shop", "session": "s9", "job": "j5", "time": 150, "allowed": False},
]
receipts = [{"tenant": "shop", "job": "j4", "time": 120, "objects": "o8"}]
joined = []
for req in requests:
    for session in sessions:
        same_session = (req["tenant"], req["session"]) == (session["tenant"], session["session"])
        if not (same_session and req["allowed"] and session["start"] <= req["time"] < session["end"]):
            continue
        for receipt in receipts:
            same_job = (req["tenant"], req["job"]) == (receipt["tenant"], receipt["job"])
            if same_job and 0 <= receipt["time"] - req["time"] <= 300:
                joined.append((req["tenant"], session["user"], req["session"], receipt["objects"]))
print(joined)  # => [('shop', 'u7', 's9', 'o8')]
assert all(row[0] != "market" for row in joined)
assert len(joined) == 1

The absence of a completion receipt for the denied request is not independently proof that no other path completed the action. The program establishes the records that satisfy this declared contract. The investigation must separately assess whether the worker completion source is complete and whether another transaction path exists. That distinction matters when a migrated worker has stopped producing receipts.

If clocks have bounded uncertainty, do not silently widen every rule until it matches. Record the bound and evaluate whether the event intervals support, contradict or leave ordering unresolved. For two timestamps each uncertain by two seconds, a one-second apparent ordering is not dependable. A service-generated parent/child relationship can be stronger evidence than timestamp proximity, while still needing provenance and namespace checks.

Separate scheduling delay from the detection window

Suppose a rule evaluates every minute and searches the previous five event-time minutes. Record B's 200-second ingest delay can still fit that look-back when the source resumes quickly. A ten-minute delivery outage does not fit. Repeated runs over overlapping windows need a stable finding key so the same incident is not counted as new each minute. A later backfill should create a historical finding with its actual event time, not pretend an analyst was notified during the outage.

A scheduled join also needs a completeness decision. Closing a five-minute interval because the wall clock advanced does not prove every source finished delivering it. You can delay finalization by an agreed lateness allowance, retain provisional findings, and reopen a case when later receipts change the conclusion. A watermark is a processing policy about accepted lateness; it is not proof that an offline endpoint has no more events to contribute.

For a large consumer service, group by the narrowest trustworthy keys required by the hypothesis. A join on a popular address can create a large cross-product and connect unrelated users. Deduplicate before aggregation, apply source/time filters early, and monitor incomplete or timed-out rule executions. Changing performance limits changes the eligible evidence and must be visible in the assessment, not buried as a tuning detail.

Record hypotheses that can be disproved

The supported hypothesis is that session s9 initiated job j4 and worker w2 exported object set o8. It does not yet establish that the human intended the action, that the session was uncompromised, or that the recipient was authorized. Investigate those as separate claims using session issuance, recipient approval and application authorization records. Authentication, authorization and user intent are three different questions.

An alternate explanation might be a scheduled merchant-support export approved earlier. Evidence that could support it includes a signed business approval tied to j4 and an expected destination. A matching address or familiar display name is insufficient. Assign each unresolved hypothesis an evidence request and a deadline. If historical session records are unavailable, retain that uncertainty in the incident narrative rather than filling the gap with actor attribution.

Do this before moving on

Extend the program with a replayed receipt, a completion six minutes after the request, and a receipt with the same job identifier in another tenant. State whether each should be deduplicated, retained outside this rule's five-minute contract, or rejected as a join. Do not erase a late export merely because it is outside one detection rule.

Produce a timeline in event order and a separate arrival-order timeline. Mark the earliest time an online detector could have joined all three records. Then write a hypothesis table with supported, contradicted and unresolved statements, including the distinction between account attribution and human intent.

Worked review. Arrival order places completion before the request, but the event-time sequence remains coherent. An identical replay should not make two exports. The six-minute completion is a separate review case outside this rule window, not evidence of safety. Another tenant's job cannot join. The earliest complete observation is B's 10:04:20 ingestion, so claiming a 10:02:05 detection would be false.

Pass criteria. The case identifies both the initiating subject and executing workload, excludes the other tenant, exposes the ingest delay, records the rule window, and makes no unsupported human-intent or actor-attribution claim. A candidate who produces a large graph without explaining each edge has not completed the exercise.

Go deeper

• EDR and XDR explains cross-domain joins and response boundaries.
• Cloud detection connects control-plane, data-plane and runtime evidence.
• PII access interview tests the impact statement when activity collection is incomplete.

Key takeaways

• Shared infrastructure can create misleading correlations.
• Permission scope and observed reads support different claims.
• Contain each established authority path at its own enforcement point.

Check yourself

Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.

1. 1Why is the earliest supported online correlation 10:04:20?

   Answer it, then reveal

2. 2Does grouping two event types in one time window enforce their order?

   Answer it, then reveal

3. 3What should happen to a valid completion outside this rule’s five-minute window?

   Answer it, then reveal

4. 4Why keep the worker identity after joining the human session?

   Answer it, then reveal