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. Non-Privileged Users Taking Privileged Actions.First Time Access to Jump Server for Peer Group.Successful Login of Account for Former Employee.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: 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. 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. This will also drive higher risk scores if you have a version of Splunk Enterprise Security that has Risk-Based Alerting built-in.
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. 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. 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. Privileged User CompromiseĪnother use case I hear often is Privileged User Compromise. 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.
Using splunk enterprise security password#
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.
Luckily Splunk Enterprise Security (ES) has several built-in correlation rules for this purpose, like these: 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. The root cause here typically happens due to phishing, shared passwords across accounts or inadvertent password exposure. 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. 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. 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. And, like you probably know, sometimes it’s hard to know where to start for specific security use cases. I’ve been working with Splunk customers around the world for years to help them answer security questions with their data.
0 kommentar(er)
