A SIEM alert is only as reliable as the records that produced it. A failed sign-in, a successful authentication and a file download may appear to describe one sequence. They may instead refer to different identities, clocks or network paths. Before an analyst treats the pattern as an incident, the logging pipeline has to preserve what each source actually recorded and explain how the events were interpreted.<\/p>\n
This guide follows a small, fictional security-monitoring example from raw records through parsing, normalization, correlation and investigation handoff. Its purpose is practical: make event transformations inspectable, recognize where evidence is missing, and distinguish a useful alert from a claim that an intrusion has already been proved. The example is not an export from a real environment, and its field names are illustrative rather than a prescribed vendor or Open Cybersecurity Schema Framework (OCSF) implementation.<\/p>\n
A raw log is the record received from a particular producer before your<\/em> SIEM’s parsing and enrichment steps. That does not guarantee it is complete or untouched since the event occurred. An application may log only selected actions, an agent may filter messages, a transport may lose events, and the producer’s clock may be wrong. Treat the raw message as evidence of what the source emitted or the collector received, not automatically as a complete history of the user’s activity.<\/p>\n Inventory the relevant producers before designing detection rules: identity provider, application, endpoint, firewall, proxy and cloud activity logs where available. For each, record its owner, event coverage, clock and time zone, collection path, expected delivery delay, data sensitivity and retention policy. A rule for suspicious authentication cannot reason about logins that the identity provider never recorded or the connector stopped forwarding.<\/p>\n The Australian Cyber Security Centre and partner agencies’ event logging and threat detection<\/a> emphasizes consistent event content, trustworthy time sources and centralization. Those are prerequisites for dependable correlation, not a promise that collecting more logs automatically produces accurate detections. Scope collection to justified operational and security purposes, protect access to sensitive log data, and preserve records according to organizational retention requirements.<\/p>\n Prioritize sources by the questions defenders actually need to answer. Authentication records may establish the outcome of an access attempt; endpoint telemetry may help connect that attempt to a device; storage audit records may show what object was accessed. None is a full substitute for the others. Maintain a simple coverage matrix that names each planned detection, its required fields, the source owner, and the expected behavior when one required source is unavailable. \u201cNo alert\u201d must not be reported as \u201cno suspicious activity\u201d when collection was interrupted.<\/p>\n Parsing identifies fields that are present in the source message: event time, producing system, action, outcome, account, source address and any native event identifier. A parser should return an explicit failure or partial record when its expected format changes. Silently guessing a username or event type may make dashboards look complete while contaminating investigations. Consider these invented input records. The addresses are drawn from the documentation-only network 203.0.113.0\/24, not an observed hostile host. Assume the application that produced the first two lines is configured for UTC+02:00 on the example date.<\/p>\n The first step is not correlation. It is extracting known fields with a parser appropriate to each format. Here, the gateway uses space-separated key-value pairs, while the identity and storage services use different names for the actor and event. A production parser must account for escaped separators, quoting, absent fields, source-specific field semantics and schema changes; splitting blindly on spaces is not a general-purpose security-log parser.<\/p>\n Keep the original message or a securely linked immutable record alongside the parsed fields. Record a parser version and ingestion time so an investigator can identify whether a mapping changed after a software update. A stable source-native event ID or request ID can help with deduplication, but a similarly named identifier from two different systems is not automatically a globally unique transaction ID.<\/p>\n In the example, a record missing Normalization places comparable source fields into a documented shared vocabulary. For this exercise, use Parse each record without inventing missing fields<\/h2>\n
2026-10-14T09:41:12+02:00 auth-gw-03 action=login result=denied user=CORP\\mira src=203.0.113.24 request=r-101\n2026-10-14T09:41:15+02:00 auth-gw-03 action=login result=denied user=CORP\\mira src=203.0.113.24 request=r-102\n2026-10-14T07:41:18Z idp-01 event=sign_in result=success user=mira@corp.example src=203.0.113.24 mfa=passed request=r-103\n2026-10-14T07:42:03Z store-02 event=file_download result=success principal=mira@corp.example src=203.0.113.24 object=report-17 request=r-104<\/code><\/pre>\nresult<\/code> should not be given the outcome success<\/code> merely because an event type normally signifies success. Mark the outcome unknown, attach a parse diagnostic, and route the sample to schema-review tests. When the input is partially parsed, record which fields were confidently extracted and which could not be interpreted. This lets a rule require validated inputs without hiding the underlying event from manual examination.<\/p>\nNormalize time and meaning, but retain identity context<\/h2>\n
event_time_utc<\/code>, source_system<\/code>, event_type<\/code>, outcome<\/code>, actor_raw<\/code>, src_ip<\/code> and raw_ref<\/code>. The first two example timestamps translate from UTC+02:00 to 07:41:12Z and 07:41:15Z. The third and fourth were already UTC. The normalized event time is distinct from ingested_at<\/code>; late arrival must not rewrite when the source says the action occurred.<\/p>\n