v0.2.0-draft AI Drafted
Home / Guides / Splunk

Splunk Cloud Hardening Guide

Security Last updated: 2026-08-08

SIEM platform hardening for Splunk Cloud including SAML SSO, role-based access control, and data security

Product Docs API Docs Hardening Guide
Code Packs: Terraform
View:

Overview

Splunk is a leading SIEM and observability platform used by thousands of organizations for security monitoring, log analysis, and operational intelligence. As a platform that aggregates sensitive security and operational data, Splunk security configurations directly impact data protection.

Intended Audience

  • Security engineers managing SIEM platforms
  • IT administrators configuring Splunk Cloud
  • SOC analysts securing log infrastructure
  • GRC professionals assessing SIEM security

How to Use This Guide

  • L1 (Crawl): Essential controls for all organizations
  • L2 (Walk): Enhanced controls for security-sensitive environments
  • L3 (Run): Strictest controls for regulated industries

Scope

This guide covers Splunk Cloud Platform security including SAML SSO, role-based access control, data security, and search security.

Table of Contents

  1. Authentication & SSO
  2. Access Controls
  3. Data Security
  4. Monitoring & Compliance
  5. Compliance Quick Reference

1. Authentication & SSO

1.1 Configure SAML Single Sign-On

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 6.3, 12.5
NIST 800-53 IA-2, IA-8

Description

Configure SAML SSO to centralize authentication for Splunk Cloud users.

Rationale

Why This Matters:

  • Centralizes Splunk authentication in your corporate IdP, enforcing MFA and conditional access on every login
  • Local Splunk password logins bypass IdP controls and are prime targets for credential stuffing and phishing
  • SAML attribute mapping ties Splunk roles to IdP groups, so disabling a user in the IdP immediately revokes their Splunk access
  • Splunk aggregates sensitive security logs, authentication events, and SIEM data — a single compromised login can expose the entire monitoring estate

Attack Prevented: Credential theft, phishing, password reuse, MFA bypass, orphaned-account access

Prerequisites

  • Administrator access with the change_authentication capability
  • SAML 2.0 compliant IdP with SHA-256 signatures

Correction (2026-08): Earlier revisions of this guide listed “Contact Splunk Cloud Support to enable SAML” as a hard prerequisite. Current Splunk Cloud Platform documentation describes SAML configuration as self-service from Splunk Web — the capability and a SAML 2.0 IdP are the only stated prerequisites. Open a Splunk Support case only if the SAML option is absent from your stack. Source: Configure single sign-on with SAML.

ClickOps Implementation

Step 1: Access SAML Configuration

  1. Navigate to: Settings → Authentication Methods
  2. Under External, click SAML
  3. Click Configure Splunk to use SAML
  4. Your SP metadata is available at: [yourSiteUrl]/saml/spmetadata

Step 2: Configure SAML Settings

  1. Enter IdP settings:
    • Single Sign-on URL
    • IdP Certificate Chain (in order: root → intermediate → leaf)
    • Issuer ID
    • Entity ID
  2. Supported IdPs: PingIdentity, Okta, Microsoft Azure, ADFS, OneLogin

Step 3: Configure IdP

  1. IdP must provide: role, realName, mail attributes

Time to Complete: ~2 hours

Code Pack: Terraform
hth-splunk-1.1-configure-saml-sso.tf View source on GitHub ↗ 
# Configure SAML SSO authentication for centralized identity management.
# Requires SAML to be enabled by Splunk Cloud Support first.
# The splunk_configs_conf resource writes to authentication.conf.

# Enable SAML authentication method
resource "splunk_configs_conf" "auth_saml_settings" {
  count = var.saml_idp_url != "" ? 1 : 0

  name = "authentication/authentication"

  variables = {
    "authType"    = "SAML"
    "authSettings" = "hth_saml"
  }
}

# Configure the SAML stanza with IdP settings
resource "splunk_configs_conf" "auth_saml_idp" {
  count = var.saml_idp_url != "" ? 1 : 0

  name = "authentication/hth_saml"

  variables = {
    "fqdn"                        = replace(replace(var.splunk_url, "https://", ""), ":8089", "")
    "idpSSOUrl"                   = var.saml_idp_url
    "idpCertPath"                 = var.saml_idp_cert_path
    "entityId"                    = var.saml_entity_id
    "signAuthnRequest"            = "true"
    "signedAssertion"             = "true"
    "attributeQuerySoapPassword"  = ""
    "attributeQueryRequestSigned" = "true"
    "redirectAfterLogoutToUrl"    = var.saml_idp_url
    "nameIdFormat"                = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
    "ssoBinding"                  = "HTTPPost"
    "sloBinding"                  = "HTTPPost"
    "role"                        = "role"
    "realName"                    = "realName"
    "mail"                        = "mail"
  }

  depends_on = [splunk_configs_conf.auth_saml_settings]
}

1.2 Configure Local Admin Fallback

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.4
NIST 800-53 AC-6

Description

Maintain local admin access for emergency recovery.

Rationale

Why This Matters:

  • A locally defined admin account preserves administrative access if the IdP or SAML integration fails, preventing total lockout
  • Without a break-glass account, an IdP outage or SAML misconfiguration can leave the SIEM unmanageable during an active incident
  • The fallback account bypasses SSO and MFA, so it must be tightly controlled with a long password, vault storage, and monitoring
  • Splunk is often the primary detection platform — losing admin access blinds the SOC exactly when visibility matters most

Attack Prevented: Loss of access from IdP outage, lockout during incident response, break-glass credential abuse

ClickOps Implementation

Step 1: Create Local Admin

  1. Create locally defined account with admin role
  2. This provides recovery option if SAML fails

Step 2: Document Local Login URL

  1. Local login: [yourSiteUrl]/en-US/account/login?loginType=splunk
  2. Document for emergency procedures

Step 3: Protect Local Credentials

  1. Use strong password (20+ characters)
  2. Store in password vault
Code Pack: Terraform
hth-splunk-1.2-configure-local-admin-fallback.tf View source on GitHub ↗ 
# Maintain a local admin account for emergency recovery when SAML is down.
# This account should use a strong password (20+ chars) stored in a vault.
# Local login URL: https://<instance>/en-US/account/login?loginType=splunk

resource "splunk_authentication_users" "emergency_admin" {
  count = var.local_admin_password != "" ? 1 : 0

  name              = var.local_admin_username
  password          = var.local_admin_password
  force_change_pass = false
  roles             = ["admin"]
  email             = "security-team@example.com"
  realname          = "HTH Emergency Admin"
}

1.3 Govern Authentication Tokens

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.4, 6.3
NIST 800-53 IA-5, AC-2

Description

Splunk platform authentication tokens (JWTs) let users and automation call the REST API and run searches without an interactive login. Restrict who can create them, prefer short-lived token types, and never allow static tokens with no expiry.

Rationale

Why This Matters:

  • Static tokens can be configured to never expire. A non-expiring static token is a permanent API key in JWT clothing: it survives password resets, is not covered by your IdP’s session policy, and completely bypasses the SAML SSO enforced in 1.1
  • Splunk offers three token flavors with very different lifetimes — static tokens created in Splunk Web (admin-set expiry, including no expiry), ephemeral tokens capped at 6 hours, and interactive tokens at 1 hour (Splunk Cloud Platform only). Choosing the shortest viable lifetime is the whole control
  • Token creation and visibility are governed by discrete capabilities, so token issuance can be restricted to a small set of roles instead of every user who can log in
  • A leaked token carries the issuing user’s roles, which on a SIEM means access to indexed authentication and audit data across the estate

Attack Prevented: SSO and MFA bypass via long-lived API credentials, standing-credential abuse, undetected data exfiltration through the REST API, token sprawl

ClickOps Implementation

Step 1: Choose the Right Token Type

Token type Lifetime Use it for
Static Admin-defined expiry — can be set to never expire Long-running integrations only, and always with a bounded expiry
Ephemeral 6 hours maximum Scripted and automation use where a short-lived credential can be re-minted
Interactive 1 hour (Splunk Cloud Platform only) Ad hoc human API access from a session

Step 2: Restrict Who Can Issue Tokens

  1. Navigate to: Settings → Access Controls → Roles
  2. Grant token capabilities deliberately:
Capability Grants
edit_tokens_settings Enable or disable token authentication platform-wide
edit_tokens_all Create, edit, and delete tokens for any user
edit_tokens_own Create, edit, and delete the user’s own tokens
list_tokens_all View tokens belonging to any user
list_tokens_own View the user’s own tokens
  1. Hold edit_tokens_settings and edit_tokens_all to administrators only; grant edit_tokens_own narrowly to roles that genuinely need programmatic access
  2. Retain list_tokens_all for the security team so token inventory is auditable

Step 3: Set and Enforce Expiry

  1. When creating a static token, always set an explicit expiration — never leave it non-expiring
  2. Prefer ephemeral or interactive tokens wherever the consumer can re-authenticate
  3. Delete tokens belonging to departed users and retired integrations

Validation & Testing

  1. With list_tokens_all, enumerate all issued tokens and confirm none has an unbounded expiry
  2. Confirm the roles holding edit_tokens_all and edit_tokens_settings match your intended administrator list
  3. Attempt an API call with an expired token and confirm it is rejected

Source: Set up authentication with tokens

2. Access Controls

2.1 Configure Role-Based Access Control

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.4
NIST 800-53 AC-6

Description

Implement least privilege using Splunk’s role model.

Rationale

Why This Matters:

  • Splunk roles scope capabilities and index access so users can only see and do what their job requires
  • Over-privileged accounts let a single compromise expose all indexed data and administrative functions
  • Limiting the admin role to 2-3 users shrinks the attack surface for the most powerful capabilities
  • Custom roles enforce separation of duties between analysts, power users, and administrators

Attack Prevented: Privilege escalation, lateral movement, insider data access, blast-radius expansion

ClickOps Implementation

Step 1: Review Default Roles

  1. Navigate to: Settings → Access Controls → Roles
  2. Review built-in roles:
    • admin: Full administrative access
    • power: Advanced search and alerting
    • user: Standard search access

Step 2: Create Custom Roles

  1. Click New Role
  2. Configure capabilities and index access
  3. Apply minimum necessary permissions

Step 3: Assign Roles

  1. Assign through SAML mapping (preferred)
  2. Limit admin role to 2-3 users
Code Pack: Terraform
hth-splunk-2.1-configure-rbac.tf View source on GitHub ↗ 
# Implement least-privilege RBAC using custom roles.
# Avoid assigning the built-in admin role directly to users.
# Map roles through SAML for centralized governance.

# Custom security analyst role with restricted capabilities
resource "splunk_authorization_roles" "security_analyst" {
  name = var.custom_analyst_role_name

  # Minimal capabilities for security analysts
  capabilities = [
    "search",
    "schedule_search",
    "list_inputs",
    "get_metadata",
    "get_typeahead",
    "rest_properties_get",
  ]

  # Index access restrictions
  imported_roles    = ["user"]
  default_app       = "search"
  search_indexes_allowed = var.analyst_allowed_indexes
  search_indexes_default = [var.analyst_default_index]
}

# Restricted power user role (L2+) with tighter capabilities
resource "splunk_authorization_roles" "restricted_power" {
  count = var.profile_level >= 2 ? 1 : 0

  name = "hth_restricted_power"

  capabilities = [
    "search",
    "schedule_search",
    "list_inputs",
    "get_metadata",
    "get_typeahead",
    "rest_properties_get",
    "rtsearch",
    "edit_search_schedule_priority",
  ]

  imported_roles    = ["user"]
  default_app       = "search"
  search_indexes_allowed = var.analyst_allowed_indexes
  search_indexes_default = [var.analyst_default_index]
}

# Read-only auditor role (L2+) for compliance reviewers
resource "splunk_authorization_roles" "auditor" {
  count = var.profile_level >= 2 ? 1 : 0

  name = "hth_auditor"

  capabilities = [
    "search",
    "get_metadata",
    "get_typeahead",
    "rest_properties_get",
    "list_settings",
  ]

  imported_roles    = ["user"]
  default_app       = "search"
  search_indexes_allowed = ["_audit", "_internal", var.audit_index_name]
  search_indexes_default = ["_audit"]
}

2.2 Configure Index Access

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 3.3
NIST 800-53 AC-3

Description

Restrict access to indexes based on role.

Rationale

Why This Matters:

  • Index-level access controls confine sensitive data such as security logs and PII to the roles that genuinely need it
  • Without index restrictions, any authenticated user could search across every dataset ingested into the platform
  • Restricting sensitive indexes to the security team enforces need-to-know and data segregation
  • SIEM indexes hold authentication and audit logs that attackers mine for reconnaissance and pivoting

Attack Prevented: Unauthorized data access, reconnaissance via log mining, cross-team data exposure

ClickOps Implementation

Step 1: Review Index Permissions

  1. Edit each role
  2. Configure Indexes searched by default

Step 2: Restrict Sensitive Indexes

  1. Security logs in restricted index
  2. Grant access only to security team
Code Pack: Terraform
hth-splunk-2.2-configure-index-access.tf View source on GitHub ↗ 
# Create dedicated indexes for security data with appropriate access controls.
# Restrict sensitive indexes to the security team through role-based access.

# Dedicated security log index
resource "splunk_indexes" "security" {
  name               = var.security_index_name
  datatype           = "event"
  max_hot_buckets    = 10
  max_data_size      = var.security_index_max_data_size
  frozen_time_period_in_secs = var.security_index_frozen_time_period
}

# Audit trail index with extended retention (L1)
resource "splunk_indexes" "audit_trail" {
  name               = var.audit_index_name
  datatype           = "event"
  max_hot_buckets    = 6
  max_data_size      = var.security_index_max_data_size
  frozen_time_period_in_secs = var.audit_index_frozen_time_period
}

# Threat intelligence index (L2+)
resource "splunk_indexes" "threat_intel" {
  count = var.profile_level >= 2 ? 1 : 0

  name               = "threat_intel"
  datatype           = "event"
  max_hot_buckets    = 3
  max_data_size      = "auto"
  frozen_time_period_in_secs = 31536000  # 1 year
}

3. Data Security

3.1 Configure Search Security

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 3.3
NIST 800-53 AC-3

Description

Control what data users can search.

Rationale

Why This Matters:

  • Role-based search restrictions and sourcetype allowlists limit the data each user can query
  • Search job quotas prevent a single user or compromised account from exhausting cluster resources
  • Unbounded or runaway searches degrade SIEM performance, delaying detection and alerting
  • Constraining searchable data reduces the chance of accidental or malicious bulk data extraction

Attack Prevented: Resource exhaustion and denial of service, bulk data exfiltration, unauthorized data discovery

ClickOps Implementation

Step 1: Configure Search Restrictions

  1. Use role-based index restrictions
  2. Configure allowed sourcetypes

Step 2: Configure Search Quotas

  1. Configure search job quotas per role
  2. Prevent resource abuse
Code Pack: Terraform
hth-splunk-3.1-configure-search-security.tf View source on GitHub ↗ 
# Control what data users can search and enforce search quotas.
# Prevents resource abuse and limits data exposure.

# Search quota limits for standard users via limits.conf
resource "splunk_configs_conf" "search_limits_standard" {
  name = "limits/restapi"

  variables = {
    "maxresultrows" = "50000"
  }
}

# Configure search concurrency limits
resource "splunk_configs_conf" "search_scheduler_limits" {
  name = "limits/scheduler"

  variables = {
    "max_searches_perc"         = "50"
    "auto_summary_perc"         = "50"
    "max_action_results"        = "50000"
  }
}

# L2: Tighter search time window restrictions
resource "splunk_configs_conf" "search_limits_hardened" {
  count = var.profile_level >= 2 ? 1 : 0

  name = "limits/search"

  variables = {
    "max_searches_per_cpu"        = "1"
    "search_process_mode"         = "auto"
    "max_rt_search_multiplier"    = "1"
    "dispatch_dir_warning_size"   = "500"
  }
}

# L3: Maximum search restrictions
resource "splunk_configs_conf" "search_limits_maximum" {
  count = var.profile_level >= 3 ? 1 : 0

  name = "limits/searchresults"

  variables = {
    "maxresultrows"               = "10000"
    "max_count"                   = "10000"
    "compress_rawdata"            = "true"
  }
}

3.2 Configure Encryption

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 3.11
NIST 800-53 SC-8, SC-28

Description

Ensure data encryption in transit and at rest.

Rationale

Why This Matters:

  • TLS in transit protects log data and credentials from interception as they move across the network
  • Encryption at rest protects stored indexes if the underlying storage layer is compromised
  • Customer-managed keys give the organization direct control over key rotation and revocation
  • SIEM data is highly sensitive, so encryption limits exposure from network sniffing and storage theft

Attack Prevented: Man-in-the-middle interception, network eavesdropping, data theft from storage compromise

ClickOps Implementation

Step 1: Verify Transit Encryption

  1. Splunk Cloud uses TLS by default

Step 2: Verify Storage Encryption

  1. Splunk Cloud encrypts data at rest
  2. Customer-managed keys available
Code Pack: Terraform
hth-splunk-3.2-configure-encryption.tf View source on GitHub ↗ 
# Ensure data encryption in transit and at rest.
# Splunk Cloud uses TLS by default; these settings harden the configuration.

# Enforce TLS on HTTP Event Collector
resource "splunk_global_http_event_collector" "hec_ssl" {
  disabled   = false
  enable_ssl = var.hec_enable_ssl
  port       = var.hec_port
}

# Enforce TLS settings in server.conf (L2+)
resource "splunk_configs_conf" "ssl_hardening" {
  count = var.profile_level >= 2 ? 1 : 0

  name = "server/sslConfig"

  variables = {
    "sslVersions"                 = "tls1.2"
    "sslVersionsForClient"        = "tls1.2"
    "cipherSuite"                 = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256"
    "ecdhCurves"                  = "prime256v1, secp384r1, secp521r1"
    "allowSslRenegotiation"       = "false"
    "requireClientCert"           = "false"
    "sslVerifyServerCert"         = "true"
    "sendStrictTransportSecurity" = "true"
  }
}

# Enforce TLS on web.conf for UI access (L2+)
resource "splunk_configs_conf" "web_ssl_hardening" {
  count = var.profile_level >= 2 ? 1 : 0

  name = "web/settings"

  variables = {
    "enableSplunkWebSSL"       = "true"
    "cipherSuite"              = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256"
    "ecdhCurves"               = "prime256v1, secp384r1, secp521r1"
    "sendStrictTransportSecurityHeader" = "true"
  }
}

# L3: Force TLS 1.3 only where supported
resource "splunk_configs_conf" "tls13_enforcement" {
  count = var.profile_level >= 3 ? 1 : 0

  name = "server/sslConfig"

  variables = {
    "sslVersions"          = "tls1.3"
    "sslVersionsForClient" = "tls1.3"
  }
}

3.3 Apply Field Filters to Sensitive Data

Profile Level: L2 (Walk)

Framework Control
CIS Controls 3.3, 3.11
NIST 800-53 AC-3, SC-28

Description

Field filters redact PII, PHI, and other sensitive field values at search time — nulling, replacing, or hashing them in search results without altering the indexed data. Configure them from Splunk Web → Administration → Users and Security → Manage field filters.

Preview feature. Splunk labels field filters a preview capability, provided “as is” without warranties, support, or service-level agreement. Do not build a compliance control that depends solely on field filters, and treat L3 (Run) reliance as unsupported until the feature reaches general availability. Source: Protect PII, PHI, and other sensitive data with field filters.

Rationale

Why This Matters:

  • Index-level restrictions (2.2) are all-or-nothing: an analyst who needs an index gets every field in it. Field filters let the same analyst search the data while sensitive values stay hidden
  • Redaction happens at search time and does not alter indexed data, so the raw values remain available for authorized investigation and are not destroyed by the control
  • Hashing (SHA-256 or SHA-512) preserves correlation — the same value hashes consistently, so analysts can still pivot and join on an identifier without ever seeing it
  • Filters are bypassed by role. Roles you explicitly authorize to see raw values are exempt, so the exemption list is the real control surface and must be reviewed like any other privileged grant

Attack Prevented: Insider harvesting of PII/PHI from log data, over-broad analyst access to regulated fields, accidental disclosure of sensitive values in shared searches and dashboards

Prerequisites

  • Administrator access to Splunk Web
  • Acceptance of the feature’s preview status (see callout above)

ClickOps Implementation

Step 1: Identify Sensitive Fields

  1. Inventory the fields carrying PII, PHI, or regulated data across your indexes and sourcetypes
  2. Record for each field whether analysts need the value, a consistent pseudonym, or nothing at all

Step 2: Create Field Filters

  1. In Splunk Web, navigate to: Administration → Users and Security → Manage field filters
  2. Create a filter for each sensitive field and choose the redaction action:
Action Result Use when
Null Field value removed from results Analysts never need the value
Replace Value substituted with a fixed string The field’s presence matters but the value does not
Hash (SHA-256 / SHA-512) Value replaced with a consistent digest Analysts must correlate on the value without reading it

Step 3: Govern the Bypass List

  1. Grant raw-value access only to roles with a documented need
  2. Review the exempted roles on the same cadence as your privileged-access review
  3. Confirm the exemption list does not silently include broad roles such as power or user

Validation & Testing

  1. Run a search that returns the filtered field as a non-exempt user and confirm the value is nulled, replaced, or hashed as configured
  2. Repeat as an exempt role and confirm the raw value is returned — proving the bypass works as intended and only where intended
  3. Confirm the indexed data is unchanged by searching as an exempt role against historical events

3.4 Configure Private Connectivity

Profile Level: L2 (Walk)

Framework Control
CIS Controls 12.6, 13.4
NIST 800-53 SC-7, SC-8

Description

Splunk Cloud Platform supports private connectivity — AWS PrivateLink, Azure Private Link, and GCP Private Service Connect — so data reaches your Splunk Cloud stack over the cloud provider’s private network instead of the public internet. Private connectivity is requested and managed through the Admin Config Service (ACS) API.

Rationale

Why This Matters:

  • Data ingested into and searched from a SIEM is among the most sensitive traffic an organization moves; keeping it off the public internet removes an entire class of interception and exposure risk
  • Private endpoints complement the transport encryption in 3.2 — encryption protects the payload, private connectivity removes the public path altogether
  • Private connectivity narrows the network reachability of your Splunk Cloud stack, so an attacker holding valid credentials still needs a foothold inside your own cloud network to use them
  • Documented limitation: cross-cloud private connectivity is not supported. A Splunk Cloud stack in one cloud provider cannot be reached privately from a different provider, which is a hard architectural constraint to design around, not a configuration issue to troubleshoot

Attack Prevented: Network eavesdropping on ingest and search traffic, internet-exposed stack reachability, credential reuse from outside your network perimeter

Prerequisites

  • Splunk Cloud Platform stack that meets Splunk’s private-connectivity eligibility requirements
  • ACS API access and the ability to raise a provisioning request with Splunk
  • Your workloads and the Splunk Cloud stack in the same cloud provider

ClickOps Implementation

Step 1: Confirm Eligibility

  1. Verify your stack qualifies for private connectivity using the ACS API eligibility check
  2. Confirm your ingest and search sources reside in the same cloud provider as the stack — cross-cloud is not supported

Step 2: Request Activation

  1. Submit the private-connectivity activation request through the Admin Config Service (ACS) API
  2. Splunk provisions the private endpoints for your stack

Step 3: Point Traffic at the Private Endpoints

  1. Update forwarders, HEC clients, and administrative access to use the private endpoint DNS names
  2. Restrict or remove any remaining public-path access once private connectivity is verified

Validation & Testing

  1. Resolve the stack’s endpoint from inside your VPC/VNet and confirm it returns the private address
  2. Confirm ingest and search succeed over the private path
  3. Confirm that traffic from outside the private network no longer reaches the stack on the paths you restricted

Source: Private connectivity

4. Monitoring & Compliance

4.1 Configure Audit Logging

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 8.2
NIST 800-53 AU-2

Description

Monitor administrative and security events.

Rationale

Why This Matters:

  • The _audit index records authentication, configuration, and search activity, providing accountability for every action
  • Alerting on admin role changes and failed authentications surfaces compromise and privilege abuse early
  • Without audit monitoring, malicious admin changes and reconnaissance activity go undetected
  • Audit trails are required evidence for incident investigation and compliance frameworks like SOC 2 and NIST

Attack Prevented: Undetected privilege abuse, configuration tampering, account compromise, audit evasion

ClickOps Implementation

Step 1: Access Audit Logs

  1. Search index=_audit
  2. Review authentication, configuration, and search events

Step 2: Create Audit Dashboards

  1. Build dashboard for audit events
  2. Monitor admin activities

Step 3: Configure Audit Alerts

  1. Alert on admin role changes
  2. Alert on failed authentications
Code Pack: Terraform
hth-splunk-4.1-configure-audit-logging.tf View source on GitHub ↗ 
# Monitor administrative and security events through the _audit index.
# Configure saved searches for audit alerting on critical actions.

# Enable audit trail forwarding to dedicated index
resource "splunk_configs_conf" "audit_trail_inputs" {
  name = "inputs/monitor:///opt/splunk/var/log/splunk/audit.log"

  variables = {
    "disabled"   = "false"
    "index"      = var.audit_index_name
    "sourcetype" = "splunk_audit"
  }
}

# Saved search: Alert on admin role changes (L1)
resource "splunk_saved_searches" "alert_role_changes" {
  name    = "HTH - Admin Role Changes"
  search  = "index=_audit action=edit_roles OR action=edit_user | stats count by user, action, info"

  is_scheduled  = true
  is_visible    = true
  cron_schedule = "*/15 * * * *"

  actions               = "email"
  action_email_to       = "security-team@example.com"
  action_email_subject  = "HTH Alert: Splunk Role Change Detected"

  alert_type            = "number of events"
  alert_comparator      = "greater than"
  alert_threshold       = "0"

  dispatch_earliest_time = "-15m"
  dispatch_latest_time   = "now"
}

# Saved search: Alert on failed authentications (L1)
resource "splunk_saved_searches" "alert_failed_auth" {
  name    = "HTH - Failed Authentication Attempts"
  search  = "index=_audit action=login status=failure | stats count by user, src | where count > 5"

  is_scheduled  = true
  is_visible    = true
  cron_schedule = "*/10 * * * *"

  actions               = "email"
  action_email_to       = "security-team@example.com"
  action_email_subject  = "HTH Alert: Multiple Failed Splunk Logins"

  alert_type            = "number of events"
  alert_comparator      = "greater than"
  alert_threshold       = "0"

  dispatch_earliest_time = "-10m"
  dispatch_latest_time   = "now"
}

# Saved search: Alert on configuration changes (L2+)
resource "splunk_saved_searches" "alert_config_changes" {
  count = var.profile_level >= 2 ? 1 : 0

  name    = "HTH - Configuration Changes"
  search  = "index=_internal sourcetype=splunkd component=ModifyConfig | stats count by user, action, object"

  is_scheduled  = true
  is_visible    = true
  cron_schedule = "*/30 * * * *"

  actions               = "email"
  action_email_to       = "security-team@example.com"
  action_email_subject  = "HTH Alert: Splunk Configuration Modified"

  alert_type            = "number of events"
  alert_comparator      = "greater than"
  alert_threshold       = "0"

  dispatch_earliest_time = "-30m"
  dispatch_latest_time   = "now"
}

# Saved search: Alert on search of sensitive indexes (L2+)
resource "splunk_saved_searches" "alert_sensitive_search" {
  count = var.profile_level >= 2 ? 1 : 0

  name    = "HTH - Sensitive Index Access"
  search  = "index=_audit action=search info=granted search=*${var.security_index_name}* NOT user=splunk-system-user | stats count by user, search"

  is_scheduled  = true
  is_visible    = true
  cron_schedule = "*/60 * * * *"

  actions               = "email"
  action_email_to       = "security-team@example.com"
  action_email_subject  = "HTH Alert: Sensitive Index Searched"

  alert_type            = "number of events"
  alert_comparator      = "greater than"
  alert_threshold       = "0"

  dispatch_earliest_time = "-60m"
  dispatch_latest_time   = "now"
}

5. Compliance Quick Reference

SOC 2 Trust Services Criteria Mapping

Control ID Splunk Control Guide Section
CC6.1 SSO/SAML 1.1
CC6.2 RBAC 2.1
CC6.7 Encryption 3.2
CC7.2 Audit logging 4.1

NIST 800-53 Rev 5 Mapping

Control Splunk Control Guide Section
IA-2 SSO 1.1
AC-3 Index access 2.2
AC-6 Least privilege 2.1
AU-2 Audit logging 4.1

Appendix A: References

Official Splunk Documentation:

API & Developer Tools:

Compliance Frameworks:

Security Incidents:

  • No major Splunk platform data breach publicly reported. In 2025, multiple Splunk Enterprise vulnerabilities were disclosed (CVE-2025-20371 SSRF, CVE-2025-20366 improper access control) requiring patches to versions 10.0.1+. These were product vulnerabilities, not breaches of Splunk’s hosted service.

Changelog

Date Version Maturity Changes Author
2026-08-08 0.2.0 draft Currency pass (Tier 1 only): added 1.3 authentication-token governance (static/ephemeral/interactive lifetimes, token capabilities), 3.3 field filters for PII/PHI search-time redaction (flagged as a Splunk preview feature), and 3.4 private connectivity via the ACS API; corrected 1.1 to reflect self-service SAML configuration rather than a Splunk Support prerequisite; migrated rotted docs.splunk.com citations to the current help.splunk.com manuals. Tier 3/4 research sweep out of scope this pass. Claude Code (Opus 4.8)
2025-02-05 0.1.0 draft Initial guide with SSO, RBAC, and data security Claude Code (Opus 4.5)

Contributing

Found an issue or want to improve this guide?