A Windows server is connected. Its forwarder is online. Events arrive every minute. Yet a rule designed to detect suspicious process execution never matches. The dashboard looks healthy because the collection pipeline works; the detection fails because the pipeline does not carry the evidence that rule needs.
Connecting a source establishes transport. Detection coverage requires more: the right activity must be recorded, selected for forwarding, delivered, parsed, and available to the rule. A break anywhere along that path can turn a genuine attack into an empty search result.
Start with a question the SOC must answer
Begin collection design with a small set of investigations. Can we explain an after-hours sign-in? Can we see a newly launched process and its command line? Can we identify an attempt to clear the Security log? For each question, name the evidence and the systems that can provide it.
| Investigation question | Starting evidence | What to verify |
|---|---|---|
| Who signed in, and how? | Security events 4624 and 4625 | Account, host, timestamp, logon type, and source address where populated |
| What process started? | Security event 4688 | Process identity and the command-line field when that policy is enabled |
| Was the Security log cleared? | Security event 1102 | The affected computer, event time, and account context |
| What followed a suspicious connection? | Endpoint, DNS, proxy, or firewall telemetry | A usable link between the device, process where available, destination, and time |
These are starting points rather than a complete Windows logging policy. Microsoft documents 4624 as successful logon, 4625 as failed logon, and 1102 as Security-log clearing. The useful fields depend on the event, its version, and the activity that produced it. Avoid designing a rule around a field you have never seen in a real sample.
Recording an event and forwarding it are separate controls
A forwarder cannot collect an event the operating system never generated. For process execution, Microsoft distinguishes enabling process-creation auditing from including command-line information in those events. Selecting event 4688 in a collection policy does not, by itself, enable either Windows setting. See Microsoft’s process-auditing documentation.
The reverse failure also matters. Windows may record an event locally while an agent excludes it, reads another channel, lacks access, or cannot reach the receiver. An investigation should therefore compare a local event with its received counterpart. Searching only the SIEM cannot reveal which earlier stage lost the evidence.
Use collection profiles that reflect the host’s role
A domain controller, a finance workstation, and an application server serve different purposes. Their collection requirements should follow those roles. Apply a reviewed baseline, then add the channels and event types required by the relevant detections. Keep an owner for each exception so a temporary troubleshooting change does not become permanent policy.
Collecting every event can be useful during a bounded investigation, but it is a poor substitute for choosing evidence deliberately. Measure event volume, agent resource use, and delivery delay after a change. Also consider access to the resulting records: command lines can contain sensitive arguments, a concern Microsoft explicitly calls out in its auditing guidance.
A worked example: an after-hours sign-in
Consider an illustrative customer with an office-hours policy. A successful sign-in occurs at 23:40. To evaluate it, the SOC needs the event timestamp, a consistent timezone, the user and device identities, and that customer’s working-hours context. Logon type helps distinguish an interactive session from routine service activity. An approved maintenance window may change the response.
If the event arrives without a usable user identity, lowering a rule threshold will not fix the problem. If all times are interpreted in the wrong timezone, collecting more events may increase false positives. First establish that the data supports the question; then tune the detection.
Validate coverage with evidence you can repeat
- Choose a controlled activity. Use an agreed test host and account. Define what should appear and where before running the test.
- Confirm local generation. Record the channel, provider, event ID, timestamp, and relevant fields.
- Find the received record. Compare the host, account, event time, and contents; check delay as well as arrival.
- Inspect normalization. Verify that the fields referenced by the rule exist and hold the expected values.
- Check the result. Confirm both a positive test that should match and ordinary activity that should not. Keep the test with the rule.
In mysoc.ai, this work matters whether SiemCore is your primary SIEM or you connect an existing SIEM. The next article explains how remote event management helps operators maintain the Windows collection side. A rule inventory tells you what you intend to detect. A repeatable collection test tells you whether the required evidence actually reaches it.
See mysoc.ai in action
One AI-run platform for your entire SOC—triage, investigation, customer communication, and reporting.