Splunk Enterprise Security has been used by my company for the past four to five years. I have been with the company for about a year, so I have approximately one year of experience with Splunk Enterprise Security.
Splunk Enterprise Security has various complex use cases. In our environment, the most common use case is SIEM, which stands for security information and event management. This involves security monitoring, including various attacks monitoring and logs coming from firewalls and other devices. We monitor all the devices and networks as well, which is a very effective use case for Splunk Enterprise Security. Another important use case is threat hunting. Since SIEM has all the logs from all the devices, it makes threat hunting very easy and helps us find the source of all attacks or potential attack attempts.
The best part is the user interface, which I would say is very easy to understand compared to other tools. The log ingestion is another feature that I particularly like. It supports almost every device, whether Windows, Linux, firewalls, cloud platforms, media tools, or APIs. Splunk Enterprise Security has a good amount of log ingestion sources. Detection engineering is another valuable feature. It has very good correlation searches and excellent measurement of MITRE ATT&CK mapping. It maps attacks to MITRE techniques in a very good manner.
Splunk Enterprise Security has helped us with faster threat detection compared to other tools since it has centralized logs from all devices and sources. This helps us catch alerts and incidents faster. There is a term for this called Mean Time to Detect. The Mean Time to Detect is very much faster with Splunk Enterprise Security. Since we can detect incidents earlier, the Mean Time to Response also becomes less, which helps us confine and consolidate incidents faster.
In my experience, Splunk Enterprise Security detects incidents approximately 20% much faster than other tools. Since detection is fast, we can analyze and respond to incidents much faster than other SIEM tools.
I really appreciate Splunk Enterprise Security, but I do have some complaints. One complaint is that it is very expensive for organizations. This is a common complaint, but it does perform very well, so that expense becomes an investment. For small teams, it is very hard to manage. There has to be a dedicated team of analysts or engineers hired to manage Splunk Enterprise Security overall. The tuning takes up some time, particularly detection tuning and response mechanisms. I have also heard from my clients that it is resource intensive on their devices, taking a lot of resources which sometimes hampers their work.
The search and query functionality in Splunk Enterprise Security needs to be much faster in the future because it still needs some work. It can be improved significantly. Additionally, one thing that I observed was the time range functionality was not very helpful for me. I wanted it to be very specific and precise, but it included logs from other time zones as well, which was a hassle. Splunk Enterprise Security needs regular updates and upgrades. Instead of doing this quarterly or half-yearly, I would prefer patches to be released as soon as there are any new incidents. Alert fatigue was a complaint recently, but it has been resolved. The AI detections were detecting very false positives, which caused our analysts to experience alert fatigue, and this was not helpful for real incidents.
Splunk Enterprise Security has various types of scalability features and options. Since my company and our clients have demands where they are adding more devices and new servers, with other SIEM tools, we would need some time duration for deployment. With Splunk Enterprise Security, I would say within two to three days, it is easily deployable and easily connected to the client's console and can start monitoring. Splunk Enterprise Security has good scaling possibilities.
We raised some questions to Splunk Enterprise Security support team because there were some incidents which required certain help and it was very urgent. Splunk Enterprise Security community has helped us a lot, but the support team has medium-paced responses. They are not fast enough and not slow enough, but they have medium-paced response times. However, the responses are very detailed and very correct. We did not have to follow up on anything because we got all the answers in one response only.
I did hear that there were pricing options in the support team as well. There was some premium support available at a much higher price. I would say that is a disadvantage because support should be equally accessible to all. There were a few cases which took some time, but overall it was a timely response. If I were to rate the support team, I would give them an eight out of ten.
When I started deploying Splunk Enterprise Security onto my client's environment, it was the first time for me, so I was a complete beginner. From a beginner's perspective, it was very difficult for me. However, once you get hands-on experience and spend some time with it, it can be moderately easy. The deployment of TI feeds was very easy and had no problems. I think if one has enough experience in deploying it, it can be very easy. However, if someone is a beginner, it will be a bit hard for them.
As an analyst, I look at ROI in a different way. I consider how it is actually helping me and whether it would also help if I used some other SIEM tool integrated into my environment. Splunk Enterprise Security has faster detection and response rates. It is approximately 20 to 25% faster than other SIEM tools, which in turn helps in detecting and responding to alerts faster. Overall, if the query search and performance improve even more, I would say it will be a total good investment and we will get our full return on investment.
AI-driven detection is a hit or miss at best because we get hundreds of alerts daily. There are a few incidents where AI-driven detections do give us false positives, but 90% of the time it has helped us in detecting attacks faster and taking action on it.
AI-driven detection basically analyzes patterns and identifies suspicious patterns. Many traditional rules or traditional alerting mechanisms may miss these patterns. This has helped us in making decisions based on incidents which even human analysts cannot determine clearly. This could have happened because AI has all the log sources and all the patterns, making it very easy for AI to correlate these logs and identify a pattern. AI indicates to the analyst that this could be an attack and to please look into it. If a human had to do it, it might take them a lot of time compared to AI.
In my experience, risk-based alerting has been very helpful. In my company, we have set it in a certain way that when we have set certain parameters, if there is some amount of risk, we trigger an investigation or incident or escalate this incident to L2 or L3 accordingly. We have a mechanism where if it is above 50, we alert L1. If it is above 75, we alert L2s. If it is above 90, we alert both L2s and L3s. Risk-based alerting has helped us in segregating these alerts, and because of that, the time of analysts is divided and they can focus on other areas of their expertise.
MITRE ATT&CK mapping, as I have mentioned before, with any incident we get, it easily maps it to MITRE ATT&CK and gives us the whole log or storyline that shows which MITRE attack it is mapped to. Threat topology is based on certain incidents. For example, if it is an unusual user login, it gives us a detailed topology of who the user is, which host the user has logged into, how many login attempts they made, and whether the source IP is known or unknown. Threat topology helps us in these aspects, and MITRE ATT&CK mapping helps us in auditing as well later on.
The credit mainly goes to AI-based detection because of how fast it correlates and works on the logs. The speed at which AI identifies patterns and gives us an alert based on that, indicating this could be a potential attack, is one major reason. Real-time log ingestion from different sources of devices like firewalls, endpoints, EDRs, and network devices is another factor. Since this is happening in real-time with no delay in between, we can catch AI-based attacks which will happen in the future, helping us get an advantage over them. Risk-based alerting also helps in a certain way. Since we know it is of a particular risk level, if it is about 85 or 90 risk, we have to take certain action on it depending on the risk level.
Essentials has helped accelerate detection because it has avoided pre-built correlation rules and MITRE mappings, providing MITRE mappings with dashboards and use cases that can also be built. We do not have to build everything from scratch. It is built on its own, which is a good thing. This helps us with faster deployment and reduced time in creating dashboards and other things.
In percentage terms, Essentials has improved the time taken to detect or respond to an alert by approximately 25%. It is a rough estimate between 25 to 50%. We do depend moderately on Essentials helping us detect alerts faster.
We have built custom threat intelligence feeds in my company which help for certain clients. We built these custom threat intelligence feeds in-house first, and when we insert them into our environment, they specifically look out for malicious IPs or hashes which we provide in the threat intelligence feed. Based on that, if we get any incident or any malicious IP which traditional Splunk Enterprise Security or Essentials cannot detect, the TI feed works well in that case and helps us block the IP and gives the analyst an alert that a malicious IP was found and to please look into it.
It has helped me in prioritizing things. We can prioritize easily. If there is a hit from the TI feed, we can look at it first because it was custom built by us and we know how malicious or bad the reputation is. The best thing is that it reduces the load of checking every time the reputation of an IP or a hash. For example, if we get a normal incident, we have to check the IP and hash to see if it is malicious, check certain platforms or Splunk Enterprise Security or other tools. The effort and navigation fatigue gets reduced, and the TI feed gives the analyst the information directly that this is malicious with references or that this hash is malicious and has been found malicious by these websites. We have also built correlation rules based on the TI feeds. If we get a hit from a TI feed plus AI-driven detection also gives it a suspicious rating that the patterns are suspicious, then it is automatically escalated to our L2s and L3s and they look into it carefully.
Operational visibility is another important aspect. It detects service failures, app crashes, or if any firewall is down or if any devices are down. We will get an alert as soon as possible after a certain time if a device stops responding. The operational visibility is pretty good so far. Compliance support is another benefit. We have many audits quarterly, and it helps in generating reports based on compliance protocols and procedures, whether HIPAA, NIST, or PCI DSS. We get reports very easily.
It gives me more context since it combines all the logs from various sources. One major thing is log validation. One log can be verified across various sources against another source. If we get only failed logins or if we get a failed login incident, we can also see which endpoint it is from or which firewall is connected to it or who is connecting to it and what the user privileges are. This builds stronger confidence overall.
SOAR has helped us a lot in our environment. Consolidating SIEM, SOAR, and UEBA has improved visibility, detection, response speed, and efficiency. SIEM's main use cases detect the alert, UEBA adds some context to it, and SOAR does the rest by automating the alert generation and the required processes that need to be done.
UEBA gives us very deep insight into the behavior of certain users or certain devices. It helps to make a baseline for behavior. UEBA learns the normal user and host behavior. It knows when it is a normal time for a user to log in and when it is unusual. It detects deviations and anomalies such as unusual login time, impossible travel, VPN usage, unusual process execution, or requesting higher privileges.
This happened last week. UEBA helped us detect an impossible travel for a user who was present in the office working with us. UEBA detected that another login was observed from the Philippines, which was very unusual because the user was with us at that moment. We asked the user if they had logged in from a VPN. The user said they did not log in from a VPN. We had to look into it very carefully, and L3s and L2s were brought on to investigate it very carefully. It was then later realized that the user was indeed using company VPN but was not aware of it.
I would say it is a very good tool that everyone should get experience with Splunk Enterprise Security. However, I have heard that it is not accessible to everyone because of its cost, but it is a very good tool and every analyst should have some hands-on experience with it. My overall rating for Splunk Enterprise Security is nine out of ten.