Solving User Monitoring Use Cases With Splunk Enterprise Security

I’ve been working with Splunk customers around the world for years to help them answer security questions with their data. And, like you probably know, sometimes it’s hard to know where to start for specific security use cases. We all know Splunk’s data platform is capable of delivering incredible analytics and insights at scale, but how do we tie that power with all of the content and premium solutions for security that Splunk provides? I thought it would be a good idea to jot some thoughts down about some common high-level security use cases because I get asked this question so much. In this post, we’ll explore some best practices for content and ideas that will help you get underway as you deploy or refine your Splunk Enterprise Security deployments. Are you ready? Let’s dive in.

To start, what used to be one of the most difficult things to detect is now one of the simplest things to key in on: compromised user credentials. The root cause here typically happens due to phishing, shared passwords across accounts or inadvertent password exposure. No matter what the cause, the name of the game here is to employ several ways to know when a compromised credential is being used against your assets. Luckily Splunk Enterprise Security (ES) has several built-in correlation rules for this purpose, like these:

• Geographically Improbable Access Detected
• Concurrent Login Attempts Detected
• Increase in Hosts a User Logged Into
• New Interactive Login From a Service Account

Those rules employ some “common sense” monitoring to see if a password is being used in a way that is suspicious, even if the authentication is in fact successful. There are also several more sophisticated rules in our content updates “Lateral Movement” analytic story, like “Detect Activity Related to Pass the Hash Attacks,” that dig deeper and provide you the visibility you need to see suspicious use of credentials.

Privileged User Compromise

Another use case I hear often is Privileged User Compromise. These are high-priority users who typically have administrative access to sensitive assets or executive level authority capable of the same, so it’s important to make sure you know right away when one of these accounts is being used by an unauthorized user. The beauty of how our data platform works is we have several frameworks already built into Splunk ES to prioritize detections for these kinds of accounts. You can mark these accounts with a higher priority in the Assets and Identity Framework, and you can also set an increased Risk Factor in the Risk Framework to make sure anything Splunk sees, you hear about with the highest urgency Notable Event. This will also drive higher risk scores if you have a version of Splunk Enterprise Security that has Risk-Based Alerting built-in.

Next, let’s talk about Insider Threat. Are you seeing a pattern here yet? Compromised user credentials, privileged user compromise, and insider threat are all related to the same general behavior that a valid credential is in use in a way that isn’t authorized. And, conversely, the same types of analytics can help detect this situation and you can use them all with Splunk Enterprise Security, right now, today. So, while we have dozens and dozens of analytics available to track and detect suspicious user activity, here are a few examples of interesting ones that work really well for Insider Threat:

• New User Taking Privileged Actions
• User With Many DLP Events
• Excessive Data Printed
• Many USB File Copies for User
• New Cloud Provider for User
• New Data Exfil DLP Alerts for User
• Successful Login of Account for Former Employee
• First Time Access to Jump Server for Peer Group
• Non-Privileged Users Taking Privileged Actions

Moving on, one of the things I really focused on when I managed a security operations center (SOC) was good old fashioned security hygiene by keeping a close eye on what accounts existed, what their purpose was, where I expected them to be used, and how I expected them to be used. To do this, I had to be on top of when an account was created, if an account went dormant, and if it was supposed to be shared or used as a service account, or not. One of the things I really enjoyed about Splunk Enterprise Security as a user back then, was that it did all of this and more out of the box. Let’s explore:

The Account Management dashboard automatically tracks account creation, update, and deletes across all data sources in Splunk. There are also panels built in to see who is creating and updating your accounts, and there is also a panel that shows accounts that have been recently locked out. Additionally, the Splunk Enterprise Security Assets and Identities framework allows you to specify categories on your accounts, and whether or not they are privileged accounts or not. This allows Splunk to treat accounts differently depending on how you say they should be used in your environment. These rules are also built in to give you visibility into interesting account activity, or the lack thereof:

• Account Deleted
• Completely Inactive Account
• Inactive Account Activity Detected
• New User Account Created on Multiple Hosts
• Short Lived Windows Accounts

We also ship a couple of other dashboards that are useful in account monitoring, including the Default Account Activity dashboard which checks your data for the usage of 50+ common default accounts from various vendors and software products, and the Access Anomalies dashboard that reviews your data for evidence of Geographically Improbable Access or Concurrent Application Access.

One more thing: Occasionally you may have the need to take a look at an account from a historic or forensic perspective, and you may not know what you are looking for upfront. There are many reasons for this: You could receive an indication from a third party that a user needs some scrutiny, for example. Or your HR or internal fraud department may flag a user for review, and request a complete timeline of that account’s network activity and access patterns. Luckily, the User Activity and Identity Investigator dashboards in Splunk Enterprise Security help you do just that — all you need is the data in Splunk and the username you want to investigate.

If you don’t have Splunk Enterprise Security today, you can start kicking the tires via our Splunk Autobahn program. Autobahn is our SaaS-based proof of value program, where you can use your own data for selected security use cases; it’s at no cost to you and allows you to quickly convert it to production.

Happy Splunking!