We are an MSSP, and some of our customers have Splunk Enterprise Security, and we run it for them.
Splunk Enterprise Security is very good for helping us find any security event across multi-cloud environments.
Splunk's unified platform works very nicely to help consolidate networking, security, and IT observability tools.
It helps speed up security investigations. There is a 25% to 30% improvement. There is also a 25% reduction in the mean time to resolve, but we are also using a SOAR tool, which reduces that by 70% to 80%.
They have approximately 50,000 predefined correlation rules, which is quite a lot, and I find that good.
It is very complicated to write your own correlation rules without the help of Splunk support.
What Splunk could do better is to create an API to the standard SIEM tools, such as Microsoft Sentinel. The idea would be to make it less painful. In ELK Stack, Kibana is the query language with which you can search log files. I believe Splunk has also a query language in which they search their log files, but once you have identified the log file that you want to use for further security correlation, you want to very quickly transport that into your SIEM tool, such as Microsoft Sentinel. That is something that Splunk could make a little bit less painful because it is a lot of effort to find that log file and forward it. An API with Microsoft Sentinel or a similar SIEM tool would be a good idea.
I have used the solution for about five years.
It is very stable. Sometimes it can be sluggish, especially in completely virtualized environments, but overall, it is good.
I would rate it a nine out of ten for scalability. They struggle a bit with pure virtual environments, but in terms of how much they can handle, it is pretty good.
Based on what customers tell me, it has been good. If you want to write your own correlation rules, it is very difficult to do, and you need Splunk's support to write new correlation rules for the SIEM tool.
In our organization, we use our own tools such as Kyndryl Bridge and Elastic. We use Kyndryl Bridge which essentially has a similar function. It is based on Elastic. It indexes log files and flags log files. It helps you to very quickly search log files similar to the Splunk algorithm.
Our clients use Splunk Enterprise Security. If somebody already has Splunk as a business intelligence tool, then very often, it makes sense to expand the Splunk subscription they have to include Enterprise Security as well. We base our decisions on customer requirements, not on anything else. If a customer comes to us looking for a SIEM solution, we advise them based on their infrastructure and objectives. If we deliver the service for them and they want us to do that, we mostly go with Microsoft Sentinel when they already do not have Splunk. Otherwise, we go with Splunk Enterprise Security. We have about 30 customers in Germany who have Splunk, and we run it for them.
Monitoring multiple clouds with Splunk Enterprise Security is no more difficult than it is with Sentinel. I find Sentinel a bit easier. Splunk, of course, is very useful if you have AWS. Generically, because Splunk is not a cloud provider itself, it fits with anything. However, integration can be challenging at times, especially in virtualized environments. Splunk struggles a bit with speed in virtualized environments. Most importantly, Splunk can be outrageously expensive. That is the problem with both Splunk and Sentinel. Their pricing literally explodes based on the amount of data you feed in.
I like Elastic SIEM. It is a tool that allows you to determine the price. It is based on the computing power you require and not on the amount of data you put in, so it is a lot more flexible than Splunk or Sentinel. If there is a cost concern, Elastic SIEM is a good idea. Elastic is also pretty good at creating on-premises data lakes to control the amount of information you put into the same tool. That is something that neither Splunk nor Sentinel offers.
In our operations, we use a separate threat intelligence vendor. To the SIEM tool, we added a SOAR tool for security orchestration, automation, and response, which is very critical these days. We get threat intelligence from a third-party provider because neither Splunk nor Microsoft gives the coverage that our customers need. Splunk does not have a SOAR capability, so we add that on top. We could add that on top of any tool, so it is not specific to Splunk, but Splunk helps because going through the log files is very fast. It does help when you do the incident analysis. Elastic also provides that, and Sentinel has that to some degree, but Splunk is still the Google for log files.
MITRE ATT&CK framework is integrated pretty much into any SIEM tool. It is not unique to Splunk. It is there in QRadar and other solutions. MITRE ATT&CK framework is helpful when designing incident response plans or playbooks. It is nice that they have it, but that is nothing unique to Splunk.
It is mostly a cloud solution.
The pricing is based on the volume of data fed into it, which can lead to substantial costs. This pricing model is complex and unpredictable, making cost management difficult.
Many parts of the IT world price based on IP addresses, nodes, or the number of devices. Splunk, of course, prices its services based on the volume of data submitted into the Splunk system. From a security perspective, it is very hard for clients to figure out how many security events per second their SIEM tool needs to work with. With Splunk, it is not just the events per second. They also need to know how much data per event per second the Splunk SIEM tool needs to work with. That is almost impossible to indicate.
Microsoft Sentinel is just as weird as Splunk. They also base the price on the amount of data you feed, whereas Elastic has a very interesting approach. It is not the amount of data you feed in; it is the amount of processing power you want to use. If you have a very large amount of data and want to correlate that very quickly, you need a lot more processing power. They base the pricing on processing power rather than on the amount of data. That is not a bad approach because that is scalable up and down depending on the needs of the organization, so the pricing from Splunk is a bit weird. That is what most people that I speak to are unhappy about because the cost can literally explode. I saw clients spend two million dollars a year just feeding data into the Splunk solution. You might have spent two million in feeding data into the SIEM tool a year, but the next year, it could be half of that. You find yourself frequently in an unpredictable situation of how much cost you are going to generate with your SIEM tool, so Splunk or Cisco needs to come up with a better and more scalable way of pricing their SIEM tool.
Overall, Splunk is among the top three SIEM tools due to its capabilities and agility in bridging business analytics with security needs. They very much deserve where they stand on the Gartner Magic Quadrant. I like it a lot better than ArcSight, which was owned by HP at one point or another. In comparison to that, Splunk is much more agile and quick. It comes from a business analytics perspective. It is a lot easier to build the bridge between the business and security based on that platform. As far as stability and scalability are concerned, it is a brilliant solution.
I would rate Splunk Enterprise Security a nine out of ten.