4 MIN READ
Windows endpoints produce a stream of security events that almost nobody is listening to properly. A 100,000 endpoint estate will generate somewhere between 50 and 200 events per second per endpoint, which amounts to a real volume problem, and the typical setup is collecting a small slice of the events the endpoints are sending, alerting on a small share of what is collected, and storing the rest in case the auditors ask. The data is there. The pipeline is the gap.
Why this matters. A modern attacker will land on the endpoint, sit quiet for 60 to 100 days, move laterally through the network, find the data they came for, and exfiltrate it. The activity is loud at the endpoint if you are listening for it, because every step leaves a Windows event log entry: the logon (4624), the process creation (Sysmon 1), the network connection (Sysmon 3), the scheduled task creation, the service install. The data is being generated. The question is whether the SOC has the budget, the storage, and the parsing in place to hear it.
Which events actually matter
Authentication events live in the Security log, and they form the highest signal source in the whole Windows event log family. ID 4624 captures the successful logon, with the user, the source IP, the logon type, and the workstation name. ID 4625 records the failed logon, which is the trail a brute force or password spray leaves behind. ID 4672 tracks the privileged logon, the alert that should always page. IDs 4720 and 4726 capture the user account created and deleted, the audit signal that someone is doing identity work, and the one that should page on a service account. Process creation events live in the Sysmon log, with Event ID 1 recording every executable that ran, including the parent process, the command line, the hash, and the user. Network connection events live in the Sysmon log as Event ID 3, recording every TCP connection the endpoint made, with the destination IP, the destination port, and the process that initiated the connection. The three event families cover most of the security value in the whole Windows event log.
What the typical setup gets wrong
Sampling tops the list, and it costs the most. The storage cost of the events used to be the constraint, and the storage cost is no longer the constraint. Object storage runs fractions of a cent per gigabyte per month, and dropping most of the events to save most of the storage means the small share kept will not contain the activity that matters. Short retention is the second failure, and the one that hits hardest during a breach investigation. Modern dwell time runs 60 to 100 days, and a 30 day retention guarantee means the events that would have told the story are gone by the time the investigator is asking. Unparsed ingest is the third failure, and the most common. Events that arrive at the SIEM as raw text are events the analyst cannot query, and events the analyst cannot query are events the alert engine will never fire on.
What to actually do
Collect everything the endpoint is willing to send, and pay the storage cost. Object storage is cheap enough that the argument no longer holds, and the value of having the events when the breach lands is worth more than the line item on the storage bill.
Retain for at least 180 days, and prefer a year if the budget allows. Dwell time runs 60 to 100 days, breach investigations typically run another 90, and the retention window has to cover both or the events that tell the story will be gone.
Parse and enrich at ingest. The raw event does not serve as the unit the analyst queries, and the unit the analyst queries is the unit the alert engine fires on. An event that arrives with the username, the hostname, the parent process, the destination IP, and the destination port already extracted serves as the event the SOC can build a query on. The platform org that collects everything, retains 180 days, and parses at ingest is the one that gets the value from the event log.
The bottom line
Collect everything, retain 180 days, parse at ingest. The data is being generated. The question is whether the SOC has the budget, the storage, and the parsing in place to hear it.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
