SPLK-3001 Security Intelligence

Security Intelligence Detailed Explanation

1. What is Security Intelligence in Splunk ES?

Security Intelligence in Splunk ES means understanding threats more intelligently by looking at:

• Context (Who is affected? How important is that asset?)

• Risk (How dangerous is the event or behavior?)

This is different from traditional SIEMs that alert for every small event, often overwhelming analysts. Instead, Splunk ES helps you focus on what really matters by using Risk-Based Alerting (RBA) and contextual data enrichment.

2. Core Concept 1: Risk-Based Alerting (RBA)

What is it?

RBA is a method where:

• Splunk doesn’t generate alerts every time something unusual happens.

• Instead, it assigns risk scores to users or systems over time.

• When the accumulated risk score reaches a threshold, then a notable event is triggered.

Why is this better?

Traditional alerting might say:

“Generate an alert every time someone fails to log in 3 times.”

But what if those failed logins are from a test server with no sensitive data? Or what if 10 alerts flood the dashboard for one small issue?

RBA solves this by:

• Looking at the importance of the asset involved.

• Measuring the severity of behavior.

• Adding it all together into a smart risk score.

Only when the total risk becomes meaningful, Splunk will alert you.

Example:

Let’s say:

• A low-priority device sees failed logins → Risk score +2

• A high-value server sees port scans → Risk score +10

• A C-level executive’s account is involved in both → Total risk = high → Trigger alert

This allows the SOC team to focus on high-impact threats, not every small event.

3. Core Concept 2: Risk Rules

What are Risk Rules?

Risk Rules are a special kind of correlation search. But instead of triggering a notable event directly, they:

• Assign a numeric risk score to a user, host, or system

• Tag the entity (e.g., “High Login Failure Rate”)

• Store the score in a risk index that can be analyzed later

How do they work?

Each rule might define:

• What behavior to watch for (e.g., data exfiltration, privilege escalation)

• How much risk to assign if that behavior is detected

• Whether the rule applies differently to high-value vs. low-value assets

Practical Example:

A Risk Rule might say:

“If a user logs into more than 3 systems in under 5 minutes, assign a risk score of 15.”

This behavior alone might not trigger a notable event. But if other Risk Rules also apply to that user, the total risk score grows, eventually crossing a threshold that generates a single, well-prioritized alert.

4. Core Concept 3: Assets and Identities Framework

This is the foundation that makes Risk-Based Alerting intelligent.

What does it do?

It enriches raw data with organizational context. Splunk ES can match:

• IP addresses to known devices (like finance servers, firewalls, or guest laptops)

• Usernames to real people (including department, role, location)

How is it used?

• In correlation rules: you can write rules that treat executives differently from regular users

• In dashboards: to show you risk scores by department or region

• In alerts: to explain not just what happened, but why it matters

Example:

If the same event (e.g., failed login) happens on:

• A guest Wi-Fi printer → Low risk

• The company CFO's laptop → High risk

That’s context — and it’s critical.

The Assets and Identities Framework makes that possible by using lookup tables (such as assets.csv and identities.csv) to relate IPs and usernames to real-world information.

5. Key Benefits of Security Intelligence in Splunk ES

a. Threat Prioritization

• You don’t waste time on minor alerts.

• You know which alerts affect key assets or users.

• You can create escalation rules for high-risk systems.

b. Reduced Alert Fatigue

• Less noise in the SOC.

• Alerts are smarter, fewer, and more meaningful.

• Analysts can focus on real incidents, improving response times.

c. Better Incident Context

• Alerts include who, where, and how important.

• You make faster decisions with more confidence.

• You can explain findings to non-technical stakeholders more easily.

Summary of Security Intelligence

In Splunk ES, Security Intelligence is about thinking smart, not just fast. By combining:

• Risk-Based Alerting

• Risk Rules

• Context from the Assets and Identities Framework

You end up with a SIEM system that gives you clearer, smarter, and more focused alerts, helping your security team act quickly and effectively.

Security Intelligence (Additional Content)

In addition to understanding the concepts of risk scoring and contextual enrichment, it’s helpful to know how these are implemented and queried in practice within Splunk ES. This makes the Risk-Based Alerting (RBA) model not only conceptually clear but also technically actionable.

1. How Risk Rules Are Configured in Splunk ES

Risk Rules are the backbone of the RBA model. Unlike standard correlation searches, they don’t trigger a Notable Event directly. Instead, they assign numeric risk scores to entities such as users, hosts, or IP addresses, which accumulate over time.

a. Creation via Content Management

• Risk Rules are created and managed through the Content Management Dashboard in Splunk ES.

• You can access this interface via:

  Configure > Content Management > Type: Risk Rule
  

• This UI allows you to:

  • Define SPL logic for risk conditions.

  • Assign static or dynamic risk scores.

  • Specify target entities (e.g., All_Risk.user, All_Risk.src).

  • Set tags, descriptions, and metadata for governance.

b. Storage Location: The risk Index

• All generated risk events are stored in the internal risk index.

• Each entry contains fields like:

  • risk_object_type (user, host, IP)

  • risk_object

  • risk_score

  • rule_name

  • threat_object_type

  • timestamp

This allows security teams to search and analyze cumulative risk over time using SPL.

2. SPL Example: Identify High-Risk Users

Once Risk Rules are active and data is flowing into the risk index, analysts can use SPL to find and prioritize threats. One powerful way is by using data models to search across risk activity in an accelerated, normalized manner.

Here is a basic example using the Risk.All_Risk data model:

| tstats summariesonly=true count from datamodel=Risk.All_Risk 
  where All_Risk.risk_score > 50 
  by All_Risk.user

What this SPL does:

• Uses tstats for high performance (leveraging accelerated data).

• Pulls from the Risk.All_Risk CIM data model.

• Filters for risk scores greater than 50 (considered elevated risk).

• Groups the results by user (All_Risk.user) to see which accounts are involved.

This SPL can be adapted into dashboards, custom alerts, or executive reports to track users accumulating excessive risk and requiring further review.

Summary of Technical Enhancements

Feature	Purpose
Content Management UI	Visual interface to create and manage Risk Rules
risk index	Central storage for all scored risk events
SPL with tstats	Efficient way to query risk data across users or assets using CIM
Practical Query Example	Shows how to identify high-risk users based on stored risk scores