At 02:14, a privileged account authenticates from an unfamiliar network. Two minutes later, a file server records an unusually large export. A security information and event management (SIEM) system shows both events, but the records do not automatically prove that an attacker used the account or that confidential information left the company. The analyst must identify the affected identity, normalize timestamps, verify the host and service context, and decide whether independent evidence supports escalation.<\/p>\n
Useful SIEM engineering begins with a question the organization needs to answer. \u201cDid this identity access sensitive reports from a new endpoint shortly after an unusual sign-in?\u201d is a testable hypothesis. \u201cCollect every log because more data are better\u201d is not. Collection, correlation, alerting and retention should be designed to support specific defensive decisions without creating an unmanageable surveillance stream.<\/p>\n
For the illustrative account event, a useful investigation may need identity-provider sign-in records, privileged-role changes, endpoint process telemetry, file access audit records, network proxy activity and firewall flows. Each source answers a different question. Identity logs may show the authentication context but not the content of a file export. A firewall flow may show a large outbound session while revealing nothing about which employee action caused it.<\/p>\n
Record which assets generate the needed events and whether their collectors are healthy. A cloud audit event sent to a disconnected workspace can be invisible even though the activity occurred. An endpoint agent that is not installed on a contractor laptop will not supply process evidence for that device. Distinguish \u201cthe query found no match\u201d from \u201cthe log source did not report.\u201d These are materially different conclusions.<\/p>\n
Use the smallest data set that can answer the question while preserving required investigation and retention evidence. Security logs may contain user names, network addresses and business metadata, so restrict access, protect collection credentials and apply the organization’s retention policy. Broad permission to every raw log is not necessary for every investigator or alert recipient.<\/p>\n
Different products represent a single event with inconsistent field names, status codes and time formats. One may record account principal name, another a stable user ID, and a third a session or resource ID. Normalize these into a shared investigative model while retaining the original values, event type and source product. A parser should not convert \u201cauthentication challenged\u201d and \u201cauthentication succeeded\u201d into the same generic \u201cuser logged in\u201d field.<\/p>\n
Time alignment is especially important. Check collection timestamp, event timestamp, timezone and known clock offsets before creating a two-minute sequence. A proxy’s ingestion time may differ from the original request time by several minutes during a backlog. Join records through stable identifiers where supported, but treat a reused IP address or shared service account as an ambiguous relationship until better evidence exists.<\/p>\n
In the 02:14 case, the identity record and file audit event should match an actual user or service context, not merely a similar display name. If a NAT gateway obscures the initiating client, the network flow alone may be insufficient to connect an export to a specific laptop. Preserve that uncertainty and request the missing host or identity evidence.<\/p>\n
A single failed sign-in is common. A privileged sign-in from a newly observed device followed by access to an unusual sensitive share may be less common and more actionable. Express the rule’s purpose, required data sources, time window, grouping key, expected normal exceptions and response urgency before implementing it in a SIEM query language. The exact syntax will vary by platform; a copied vendor query is not evidence that the necessary fields are collected correctly.<\/p>\n
For example, compare the last known authorized privileged session to the new one, then look for sensitive-file access by the same stable principal or host in the defined interval. Avoid treating a shared IP address as a reliable identity join by default. Require an analyst to review conflicting indicators rather than automatically block every legitimate employee with an unusual travel or remote-work pattern.<\/p>\n
The detection should also define its exclusions. An approved payroll batch service may export large files at a predictable time, and a scheduled migration can create unusual login patterns. A suppression should be limited by asset, service account, change window and owner. \u201cIgnore file access from this network forever\u201d may suppress the same activity an attacker would try to imitate.<\/p>\n
Once correlation fires, enrichment can supply device owner, asset criticality, managed-device state, privilege level, previous sign-in context and an associated approved change. The alert should show why it fired and which facts remain unknown. An analyst should not need to infer from a color-coded severity number whether there was a successful logon, a failed attempt or a separate authorized job.<\/p>\n
Use a simple evidence matrix:<\/p>\n