How Activity Becomes a Record

How Activity Becomes a Record

See why a log record is a constructed view of activity rather than the activity itself.

Follow one action through the evidence pipeline

Suppose an administrator changes a cloud role. The change happens once in the service, but a detection never sees the action directly. It sees a record created by a component that observed some part of the action. That difference matters because every record reflects a vantage point, a configuration, and a purpose.

The service may know the authenticated session, requested API operation, target role, submitted parameters, and response. It may not know the human intention behind the request. A network sensor might see an encrypted connection to the provider but not the operation. An endpoint sensor might see the command-line client but not whether the provider accepted the change. Each source offers evidence about the same activity while answering a different question.

The place where a source can observe activity is its observation point. Before asking whether you “have the log,” ask whether the observation point can see the behavior variation you care about. A record of successful configuration changes cannot prove that a denied attempt never occurred if the service does not audit failures. A collector with read access to one region cannot support a global claim. Visibility begins with architecture, not ingestion.

After the service creates the record, the evidence travels. A collector retrieves or receives it. Transport may buffer, retry, batch, duplicate, reorder, or drop records. A parser turns bytes into fields. A normalization layer maps provider-specific concepts into a common schema. Enrichment adds identity ownership, asset value, or threat context. Storage applies access and retention. Finally, an analytic evaluates the record and an alerting path delivers a result.

At each boundary, ask what can change. A parser can treat an integer as a string. Normalization can collapse the requesting actor and target identity into one user field. Enrichment can apply today’s asset owner to an event from last month. A queue can delay one source long enough to break a sequence. The Security Telemetry Quality and Blind Spots reference gives you a vocabulary for assessing these failures, but the central idea is that evidence quality is end to end.

This changes how you diagnose a detection. When an expected alert does not appear, the query is only one possibility. The action may not have been observed, auditing may have been disabled, collection may have stopped, parsing may have failed, a required field may have become null, or delivery may have broken after the analytic matched. Thinking in pipelines prevents you from tuning logic to compensate for missing evidence.

The record remains useful because its limits are knowable. If you preserve where it came from, what observed it, how it changed, and whether the path was healthy, an analyst can decide what the evidence supports. Without that context, a polished common field can look more authoritative than the source ever was.

Resources

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