Splunk Enterprise Security

SIEM Platform Observability

Synopsis

The Splunk Enterprise Security target sends security telemetry to Splunk ES using the HTTP Event Collector (HEC) with security-optimized index configuration and CIM normalization. This target extends standard Splunk HEC configuration with security-specific data models and correlation search integration.

Schema

- name: <string>
  description: <string>
  type: splunksecurity
  pipelines: <pipeline[]>
  status: <boolean>
  properties:
    endpoints:
      - endpoint: <string>
        auth_type: <string>
        token: <string>
        secret: <string>
    index: <string>
    source_type: <string>
    source: <string>
    batch_size: <integer>
    timeout: <integer>
    tcp_routing: <boolean>
    use_compression: <boolean>
    insecure_skip_verify: <boolean>
    ca_name: <string>
    server_name: <string>
    cert_name: <string>
    key_name: <string>
    passphrase: <string>
    min_tls_version: <string>
    max_tls_version: <string>
    field_format: <string>
    debug:
      status: <boolean>
      dont_send_logs: <boolean>

Configuration

The following fields are used to define the target:

Base Target Fields

Field	Required	Default	Description
name	Y	-	Unique identifier for this target
description	N	-	Human-readable description
type	Y	-	Must be splunksecurity
pipelines	N	-	Pipeline names to apply before sending
status	N	true	Enable/disable the target

Splunk ES Connection

Field	Required	Default	Description
endpoints	Y	-	Array of Splunk HEC endpoint configurations
endpoints[].endpoint	Y	-	Splunk HEC URL (e.g., https://splunk.example.com:8088/services/collector)
endpoints[].auth_type	N	token	Authentication type (token, secret)
endpoints[].token	Y*	-	HEC token for authentication
endpoints[].secret	Y*	-	Bearer token from environment variable
max_bytes	N	4194304 (4 MB)	Maximum size of a single request body or batch, in bytes

note

max_bytes caps the size of a single request body or batch. It behaves differently from max_size on the file-writing targets, and the difference is easy to get wrong:

• An explicit max_bytes: 0 IS honoured and removes the ceiling on targets that have no ceiling of their own. The value is read with Int64, which returns what you wrote — unlike max_size, which is read with MustInt64 and silently substitutes its default for a zero. Where a target has a fixed ceiling of its own, its page says so and a zero is clamped to that ceiling instead.
• A negative value is rejected at configuration time with max_bytes must not be negative.

The ceiling is validated when the target is built and enforced again on every batch, so a value the receiving service will refuse fails early rather than per request.

* = token is required when auth_type is token; secret is required when auth_type is secret.

Event Configuration

Field	Required	Default	Description
index	N	-	Default Splunk index (e.g., main, security, notable)
source_type	N	-	Default sourcetype for events
source	N	-	Default source for events

Batch Configuration

Field	Required	Default	Description
batch_size	N	10000	Number of events to batch before sending
timeout	N	30	Connection timeout in seconds

Connection Settings

Field	Required	Default	Description
tcp_routing	N	false	Enable TCP routing header
use_compression	N	true	Enable GZIP compression

TLS

TLS is engaged by the endpoint URL scheme: an https:// endpoint enables it, an http:// endpoint does not. There is no status field. The fields below are top-level, at the root of properties.

The web interface exposes only insecure_skip_verify for these targets. Every other field below — the CA bundle, the client certificate and key, the SNI override and the version bounds — has to be set in the YAML configuration or through the API; there is no form control for it.

Field	Required	Default	Description
insecure_skip_verify	N	false	Skip server certificate verification. Use only for testing.
ca_name	N	-	CA bundle used to verify the server certificate. When unset, the host trust store is used; when set, it replaces the host trust store rather than adding to it.
server_name	N	-	SNI hostname override for the TLS handshake
cert_name	N*	-	Client certificate for mutual TLS
key_name	N*	-	Client private key for mutual TLS
passphrase	N	-	Passphrase for an encrypted private key
min_tls_version	N	tls1.2	Minimum accepted TLS version (tls1.0, tls1.1, tls1.2, tls1.3)
max_tls_version	N	tls1.3	Maximum accepted TLS version (tls1.0, tls1.1, tls1.2, tls1.3)

* = Mutual TLS requires both cert_name and key_name. Setting only one is a configuration error.

note

A nested tls: block is also accepted, and a non-empty one replaces the flat shape rather than merging with it: the sender reads the block and ignores every flat key, including options the block leaves out. Use one shape or the other, never a mixture.

insecure_skip_verify is the single exception. It is read from the nested block when present and otherwise falls back to the root, so a target carrying a hand-written tls: block keeps the skip-verify its form wrote. Only an absent nested value falls through — a nested false is an explicit statement and overrides a root true.

There is no tls.status: TLS is off when the whole block is absent, and a status key inside the block is not read.

note

TLS material fields (cert_name, key_name, ca_name, client_ca_name) accept any of the following:

• File name — resolved relative to the service root directory. Nested paths such as certs/prod/server.pem are supported.
• Absolute path — honored only if it resolves inside the service root. Any path that escapes the root is refused.
• Inline PEM content — used verbatim when the value contains -----BEGIN.
• Environment variable — ${ENV_VAR}.
• Vault reference — $secret{id=...} or $secret{store=...,ref=...}.

Normalization

Field	Required	Default	Description
field_format	N	-	Data normalization format. See applicable Normalization section

Scheduling

See Scheduling and Pool Behavior for interval and cron fields shared by all targets.

Debug Options

Field	Required	Default	Description
debug.status	N	false	Enable debug logging for this target
debug.dont_send_logs	N	false	Log events without sending to Splunk ES

Details

HEC Modes: JSON and RAW

The target supports both JSON and RAW HEC ingestion modes. The mode is determined by the endpoint URL path, not by a separate configuration field.

An endpoint URL ending in /services/collector/event (or the default /services/collector) uses JSON mode, where each event is sent as a structured JSON object with metadata fields (index, sourcetype, source) embedded in the payload.

An endpoint URL ending in /services/collector/raw uses RAW mode, where events are sent as plain text with metadata passed as query parameters. RAW mode is useful for forwarding pre-formatted log lines that should not be wrapped in JSON structure. When the incoming pipeline data contains a _raw field, the target extracts its value and sends it as the raw event body.

Named Streams

Endpoint URLs can include a query parameter to define a named stream. For example, https://hec.example.com:8088/services/collector/raw?paloalto creates a stream named paloalto using RAW mode, while https://hec.example.com:8088/services/collector/event?winevent creates a stream named winevent using JSON mode.

Named streams allow routing different event types through separate HEC paths within a single target configuration. A pipeline selects the stream for an event by setting index or table.

Events carrying neither are delivered to the endpoint configured without a query parameter, which acts as the catch-all stream. An event naming a stream that no endpoint defines also falls back to the catch-all; if no catch-all exists, the event cannot be delivered and is retried until one is configured.

All endpoints sharing a stream name must use the same mode. Mixing a /raw endpoint and an /event endpoint under one stream is a configuration error and the target fails to initialize.

Security Index Configuration

Recommended Indexes:

• main: Default index for general security events
• security: Dedicated security events index
• notable: Notable events generated by correlation searches
• threat_activity: Threat intelligence indicators
• audit: Audit trail and compliance events

Index Naming Conventions:

• Use descriptive index names matching data categories
• Separate indexes for different security zones
• Configure index retention based on compliance requirements

Index Permissions

Ensure HEC token has write permissions for configured indexes. Configure index permissions in Splunk Settings > Data > HEC tokens.

CIM Normalization

Common Information Model (CIM):

• Splunk's standard for field naming and categorization
• Required for Enterprise Security correlation searches
• Enables the pre-built Splunk Enterprise Security views and reports
• Provides consistent data model across sources

CIM Data Models:

• Authentication: Login events, authentication failures
• Network Traffic: Firewall logs, network sessions
• Endpoint: Process execution, file modifications
• Malware: Anti-virus detections, malware events
• Intrusion Detection: IDS/IPS alerts
• Change Analysis: Configuration changes, account modifications

Field Mapping:

• src / dest: Source and destination systems
• user / dest_user: User accounts
• action: Event action (allowed, blocked, success, failure)
• vendor_product: Vendor and product identification

Examples

Basic Security Events

Sending security events to Splunk Enterprise Security...

targets: - name: splunk-security type: splunksecurity properties: endpoints: - endpoint: https://splunk.example.com:8088/services/collector token: "${SPLUNK_HEC_TOKEN}" index: security source_type: datastream:security

With CIM Normalization

Applying custom normalization for CIM compliance...

targets: - name: splunk-es-normalized type: splunksecurity properties: endpoints: - endpoint: https://splunk.example.com:8088/services/collector token: "${SPLUNK_HEC_TOKEN}" index: security source_type: datastream:security:cim field_format: "cim"

Notable Events

Sending events to notable index for correlation search integration...

targets: - name: splunk-notables type: splunksecurity properties: endpoints: - endpoint: https://splunk.example.com:8088/services/collector token: "${SPLUNK_HEC_TOKEN}" index: notable source_type: datastream:notable source: DataStream

High-Availability Configuration

Multiple Splunk HEC endpoints for high availability...

targets: - name: splunk-es-ha type: splunksecurity properties: endpoints: - endpoint: https://splunk-hec1.example.com:8088/services/collector token: "${SPLUNK_HEC_TOKEN}" - endpoint: https://splunk-hec2.example.com:8088/services/collector token: "${SPLUNK_HEC_TOKEN}" - endpoint: https://splunk-hec3.example.com:8088/services/collector token: "${SPLUNK_HEC_TOKEN}" index: security batch_size: 10000 use_compression: true

Threat Intelligence

Forwarding threat intelligence indicators to Splunk ES...

targets: - name: splunk-threat-intel type: splunksecurity properties: endpoints: - endpoint: https://splunk.example.com:8088/services/collector token: "${SPLUNK_HEC_TOKEN}" index: threat_activity source_type: datastream:threatintel source: threat-feeds

Authentication Events

Sending authentication events with CIM-compliant sourcetype...

targets: - name: splunk-authentication type: splunksecurity properties: endpoints: - endpoint: https://splunk.example.com:8088/services/collector token: "${SPLUNK_HEC_TOKEN}" index: security source_type: datastream:auth batch_size: 5000

Production Configuration

Production-ready Splunk ES configuration with HA, compression, and security settings...

targets: - name: splunk-es-production type: splunksecurity properties: endpoints: - endpoint: https://splunk-hec1.example.com:8088/services/collector token: "${SPLUNK_HEC_TOKEN}" - endpoint: https://splunk-hec2.example.com:8088/services/collector token: "${SPLUNK_HEC_TOKEN}" index: security source_type: datastream:security:production source: datastream-director batch_size: 10000 timeout: 30 use_compression: true insecure_skip_verify: false field_format: "cim"

Troubleshooting

The splunksecurity target delivers over the HTTP Event Collector in the same way as the splunk target, and it reports the same errors for the same causes: refused tokens, rejected indexes, certificate and connection failures, size limits, and stream routing. Use the troubleshooting section of the Splunk target for the full list of errors, causes and fixes. See Target Delivery Errors for how Director logs and retries target failures.

Read that section with your own target name in mind. Log lines and the connection status carry the name you gave this target, so match on the cause text, which is the part after Reason: or after the last colon, rather than on the target names used in the examples there.

What differs for Splunk Enterprise Security

Nothing in how this target connects, batches, retries or reports its failures differs. What differs is what this page adds on top: the index and sourcetype conventions of an Enterprise Security deployment, and the endpoint path its examples use.

What this page adds	What to check when events do not arrive
The indexes security, notable, threat_activity and audit	These are conventions, not indexes Splunk creates for you. Each one has to exist, and the token has to be allowed to write to it. Otherwise the collector answers 400, typically reporting Incorrect index
Sourcetypes such as datastream:security	A sourcetype is a label carried with the event, and nothing checks it on the way out. A typo is typically accepted, so no error is logged. The events are indexed under the name you sent, and the data models and correlation searches that expect the other name stop matching
Endpoints ending in /services/collector	That path is JSON mode. If events arrive with the expected time, index and sourcetype but the body reads as one long run of letters and digits, use /services/collector/raw instead. The Splunk page covers this under the unreadable message entry
Several endpoints, as in the high-availability example	Each endpoint carries its own token and its own certificate trust. A failure names the endpoint URL, so read the URL in the log line to find out which member is at fault

Leaving index empty sends the events to the token's own default index. That is the quickest way to confirm that a rejected index, rather than the token or the network, is what you are looking at.

warning

An index the token may not write to is the one failure here that loses data. The batch is delivered four times and then dropped, and the dropping (giving up) line is your only record of it. A refused token or an unreachable collector, by contrast, is retried until you fix it and loses nothing.

Everything else reads exactly as it does on the Splunk page, including the configuration messages, the certificate failures, and the 408, 429 and 503 replies that mean the collector is busy rather than misconfigured.