topic Re: Entreprise Seurity Not Generating Notables in Splunk Enterprise Security

Entreprise Seurity Not Generating Notables

fedayn05 — Thu, 26 Feb 2026 11:00:40 GMT

Hello Team,

I have integrated Linux Hosts with my Splunk. I installed the splunk add-on for Linux , and it gaves me 3 source types (linux_secure, linux_messages_syslog and linux_audit) .

This is my inputs.conf on Splunk Forwarder :

[monitor:///var/log/auth.log]
disabled = false
sourcetype = linux_secure
index = linux_hosts

[monitor:///var/log/syslog]
disabled = false
sourcetype = linux_messages_syslog
index = linux_hosts

[monitor:///var/log/audit/audit.log]
disabled = false
sourcetype = auditd
index = linux_hosts

The First issue i have is that The Endpoint Data Model doesn't accept thoses source types except for linux_secure, so Correlation searches are not bringing any notables.

The second issue is regarding Notables , i changed the source type from linux_audit to auditd. And i took a correlation search as an axample , I run its SPL on search and it brings result , but On the Entreprise security no notable is generated.

Could you please help me fix This.

Thank you for your time.

Re: Entreprise Seurity Not Generating Notables

azadsarker — Sun, 08 Mar 2026 08:08:05 GMT

Hello,

Thank you for sharing the details of your configuration. Based on your description, there are two separate issues related to data model compatibility and notable event generation in Splunk Enterprise Security.

Endpoint Data Model Not Recognizing Sourcetypes

The Endpoint Data Model in Splunk Enterprise Security expects specific sourcetypes defined in the CIM (Common Information Model). While the Splunk Add-on for Unix and Linux provides sourcetypes such as:

linux_secure
linux_messages_syslog
linux_audit

only some of these are mapped to the Endpoint data model by default.

In your configuration:

/var/log/auth.log -> linux_secure
/var/log/syslog -> linux_messages_syslog
/var/log/audit/audit.log -> auditd

The main issue is that linux_messages_syslog and auditd are not automatically mapped to the Endpoint data model unless CIM field mappings and tags are properly applied.

Recommended actions:

Verify CIM compliance using the CIM Data Model Audit dashboard.
Check if the events contain the required CIM fields such as:

user
src
dest
process
action

Ensure proper event tags are applied (for example: authentication, process, change, etc.).
If necessary, create field aliases or eventtype mappings to align the sourcetypes with the Endpoint data model.

For example, verify whether your events appear in the data model:

| datamodel Endpoint Authentication search

If no results appear, the events are not mapped correctly to CIM.

Re: Entreprise Seurity Not Generating Notables

fedayn05 — Sun, 08 Mar 2026 13:51:00 GMT

Hello,

Thank you for your time and reply.

After further verification, it turns out that linux syslog logs don't generate deep logs about the filesystem and processes, so the logs will never trigger those correlation searches as the required data are not sent.

what i found on reddit is some people recommending the installation of Sysmon, as it monitors and logs the required data. i did install Sysmon and i installed Sysmon add-on for linux on Splunk and used the sysmon-linux sourcetype.

This really helped and now the correlation searches are being perfectly triggered.

Re: Entreprise Seurity Not Generating Notables

PickleRick — Sun, 08 Mar 2026 21:38:00 GMT

OK. Of those three locations only the audit.log contains fairly standardized data.

But.

There are several different types of events there.

1. SELinux alerts

2. PAM events

3. auditd logs

Usefulness of SELinux alerts depends on your SELinux policy (and whether SELinux is enabled at all).

Auditd must be explicitly configured with audit rules to produce meaningful output.

So this single file can be tricky to configure.

And the two other files can contain plethora of various event formats from different daemons on your system depending on what you have installed and how your system is configured. I assume it's some debian-based distro because normal RH-based one doesn't even have /var/log/syslog.

So it's a bit more complicated than just installing "something" and having it work.

Sysmon is... well, that's a completely different story. I'd be very cautious about it since it's a very low-level external tool and requires a decent configuration to produce meaningful output but not overstress the system.