Time and Identity Give Events Their Relationships

Time and Identity Give Events Their Relationships

Learn to relate events without inventing order or merging different subjects.

Why correlation fails when clocks and entities are vague

Two records can be individually correct and still tell a false story when you connect them. Imagine that a host clock is five minutes fast while a cloud audit event arrives twenty minutes late. A process appears to start before the login that authorized it. At the same time, the IP address in both records has been reassigned from one short-lived workload to another. Sorting by one timestamp and joining on the address produces a neat timeline that never happened.

Security records contain several kinds of time. Event time represents when the source says the activity occurred. Observation time may record when a sensor saw it. Ingest time records arrival in the pipeline. Processing time records when transformation or analytics occurred. Alert time records delivery to a consumer. These values are not interchangeable because they answer different questions.

Behavior order usually depends on event or observation time. Pipeline reliability depends on the difference between event and ingest time. Operational responsiveness depends on alert time. If you replace event time with ingest time, a delayed record looks recent and may appear after an action that actually followed it. If you trust source time without measuring clock drift, strict ordering may be equally misleading.

The Event Time, Ingest Time, Clock Drift, and Late Data reference describes the engineering choices, but you can understand the tradeoff without implementation detail. Waiting longer for late records improves completeness but delays the decision and consumes more state. Closing a window quickly supports a fast response but can miss slow sources. The right choice comes from the behavior and consumer, not a universal five-minute default.

Identity creates a similar problem. A username is an identifier, not a person. An IP address is a network location, not a stable device. A process ID is meaningful only on one host during a period. A cloud display name can be reused across tenants. Entity resolution is the work of relating those identifiers to typed subjects—such as a human, account, session, device, workload, application, or resource—while preserving the source and confidence of the relationship.

Consider a human who signs in to an account, receives a session, authorizes an application, and uses a workload identity to change a resource. Calling every participant “user” erases the authority chain. You need to keep the initiator, authenticated actor, delegated subject, service identity, target, and owner distinct. Entity Resolution for Users, Hosts, Sessions, Workloads, and Resources explores that model.

Relationships also expire. An address belongs to one workload at 10:00 and another at 10:05. A contractor owns an account only during an engagement. Historical correlation should use the identity relationship that was true at event time, not the enrichment that happens to be current when you query. Once you see time and identity as evidence with provenance, correlation becomes a reasoned claim rather than a convenient database join.

Resources

• NIST SP 800-92 Rev. 1 Initial Public Draft — Primary reference for the standards and concepts discussed in this lesson.