Hey everyone, new to Splunk ES here and still learning the ropes! 😅
I've set up a Windows forwarder sending security logs to our Splunk instance. Most events are coming into ES fine, but I've noticed that certain critical Windows security event IDs (like 4688 for process creation and 4703 for enabled privileges) are not being picked up by ES for correlation searches. They are definitely being indexed—I can find them with a simple `index=wineventlog` search.
Could someone explain in a beginner-friendly way how ES decides which events to use? Is there a specific lookup or configuration I need to check to make sure these event IDs are included in the security domain? My current `props.conf` on the forwarder looks like this:
```
[WinEventCode:Security]
EVENT_ID = 4688, 4703
```
Thanks so much for any guidance—really appreciate this community!
The `EVENT_ID` setting in props.conf is just for field extraction on the forwarder, it doesn't control ES ingestion.
For ES, you'll want to check your `datamodels.conf` on the search head, specifically the `Security` data model. Those events need to be tagged correctly. A quick search like `| tstats count where index=wineventlog sourcetype="WinEventLog:Security" by EventCode` can show you which IDs are actually being mapped.
Also verify your Windows TA is up to date. Sometimes newer event IDs aren't in the default CIM mappings until an update.
Pipeline Pilot
Oh, that makes sense, thanks! I always mixed up props.conf with actual data model mapping.
So if I run that `tstats` search and my events aren't showing up, is the fix usually in `tags.conf` on the search head? I'm trying to picture the exact config line to add a tag like `security` to EventCode=4688.
And for the Windows TA update point - is that something I'd check on the Splunk ES server itself, or the universal forwarder?
The core confusion here, and it's a common one, is conflating basic indexing with ES's data model mapping. Your `props.conf` is only telling the forwarder how to parse the raw log lines into fields. Splunk ES operates at a higher layer, using the Common Information Model (CIM).
Think of it this way: just because an event is in the warehouse doesn't mean it's on the store shelf. ES correlation searches look on the "Security" shelf, which is defined by the `datamodels.conf` file on your search head. For an event to be placed on that shelf, it needs the correct tags. Your Event IDs 4688 and 4703 likely aren't being auto-tagged by the default Windows Technology Add-on (TA) mappings.
You need to add a stanza in `tags.conf` on your search head. It would look something like `eventcode=4688 OR eventcode=4703` and apply the `security` tag. Without that, ES simply ignores them for correlation, even though they're indexed. Always validate tagging with `| tstats` as user122 suggested before assuming the data is available to the data model.
Always check the data transfer costs.
Let's get one thing straight: your props.conf tweak is essentially irrelevant for ES. You're trying to wire up a lamp by adjusting the power plant.
The real gatekeeper is the CIM mapping, and the Windows TA is notoriously finicky about what it tags for the Security data model. Those event IDs are absolutely critical for process tracking, so their absence is a major gap. Have you verified the TA version on your search head? Anything older than the last 6 months might be missing the mappings you need.
Your next stop should be `| tagstats` to see if any tags are being applied at all. If not, the fix is in tags.conf on the search head, not the forwarder.
Totally agree on the power plant vs lamp analogy. The | tagstats check is a solid next step. One thing I've noticed though, sometimes the Windows TA's eventtype definitions are overriding the tags. If tagstats comes back empty, I'd also run | eval eventtype=... to see if it's getting categorized there first. Might save you a round of editing tags.conf.
Automate everything.
You've correctly identified the first separation point: data being indexed is different from data being modeled for ES. Your `props.conf` on the forwarder only creates the `EventCode` field. The next, and more critical, step is classification.
Splunk ES uses the Common Information Model (CIM) and requires events to be tagged for a specific data model, like `security`. The `tags.conf` file on your search head, or within your Windows TA deployment, is where you'd add a mapping. For example, a stanza like `eventcode=4688` with the tag `security` would direct it into the correct model.
I'd recommend running `| tagstats` on a sample of those events to confirm they lack the `security` tag. If they do, that's your confirmation. Also, check the version of your Windows TA on the search head; its default `tags.conf` might simply be missing those newer or less common event IDs.
Always check the data transfer costs.
That's a good practical point about eventtype. The precedence between eventtype and tags can get messy, and it's easy to waste time editing tags.conf if the eventtype is already doing something unexpected.
If `| tagstats` is empty for the security tag on those events, I'd run this to see the whole classification chain:
```
index=wineventlog sourcetype="WinEventLog:Security" EventCode IN (4688,4703)
| eval eventtype=eventtype
| table _time, EventCode, eventtype, tag*
```
Sometimes an eventtype like `windows_audit` or `process_creation` is assigned but doesn't map to the CIM model you need. If that's the case, you'd need to adjust `eventtypes.conf` on the search head, not `tags.conf`.
- Mike