Risky Events from Privileged Users

Risky Events from Privileged Users

Description

When something generally risky occurs to your most privileged users, you likely should respond more quickly. Fortunately, this is easy to do.

Content Mapping

This content is not mapped to any local saved search. Add mapping


Use Case

Insider Threat, Security Monitoring

Category

IAM Analytics, Insider Threat, Zero Trust

Security Impact

There are many searches that you would not normally want to analyze... except when they occur to your most privileged users. A high entropy process starting in a weird location is probably software installation that only really matters when combined with other events, but it's best to double check when it's occurring on the laptop belonging to the CEO's Executive Assistant. By combining a list of risky events (generated through the Enterprise Security risk framework, or your own version thereof) with a list of privileged users, you can easily prioritize those events.

Alert Volume

Low

SPL Difficulty

Basic

Data Availability

Bad

Journey

Stage 4

MITRE ATT&CK Tactics

Persistence
Privilege Escalation

MITRE ATT&CK Techniques

Valid Accounts

MITRE Threat Groups

Chimera
APT39
FIN4
FIN5
FIN10
Soft Cell
Night Dragon
TEMP.Veles
Leviathan
Dragonfly 2.0
Wizard Spider
OilRig
APT41
Suckfly
Silence
FIN6
Threat Group-3390
APT18
menuPass
APT28
Sandworm Team
PittyTiger
FIN8
Carbanak
APT33

Data Sources

Ticket Management

   How to Implement

Implementation of this search depends on two key components -- a list of risky events, and a list of privileged users.

You can use almost anything to generate a list of risky events -- in fact that's the desired intent for most medium-or-higher alert volume searches in Splunk Security Essentials! Most customers who go down this path will use the Enterprise Security Risk Framework to aggregate these events, though you can also 'roll your own' risk framework with Summary Indexing.

Generating a list of risky users is complicated -- that's why one of the most detailed examples in Splunk Security Essentials takes this on! Check it out! (link).

Once you have these components, implementation of this detection is straightforward.

   Known False Positives

This search can inherently generate false positives because it opens the door to alerting users to low confidence events that occur to privileged users. You will need to tune the underlying search, or potentially filter for a certain risk score to manage these false positives.

   How To Respond

See the response guidance for the underlying searches that generate the original events.

   Help

Risky Events from Privileged Users Help

This example leverages the Simple Search search assistant. Our example dataset is a collection of events from the risk index of a demo environment for Splunk Enterprise Security. The risk index provides a way to track "risky" events that aren't necessarily significant enough to send to a SOC analyst (along with aggregating the overall volume of events for a given user). Our live search looks for the same behavior using the standard sourcetypes. See How to Implement if you do not use Enterprise Security.

SPL for Risky Events from Privileged Users

Demo Data

First we bring in our basic demo dataset. In this case, a list of events from the risk index of a demo Splunk Enterprise Security environment. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
Next we use a lookup with the risk scores of user accounts.
Finally we can filter for just the events occurring to privileged employees.

Live Data

First we bring in our dataset of events from the risk index of Splunk Enterprise Security.
Next we use a lookup with the risk scores of user accounts.
Finally we can filter for just the events occurring to privileged employees.

Screenshot of Demo Data