What is our primary use case?
Splunk SOAR is used for internal company operations. One of the best use cases implemented in the last three months with Splunk SOAR is automated phishing triage. Before using Splunk SOAR, if a user reported any suspicious mail, I had to manually extract IOCs such as URLs, file hashes, or IPs and then jump between a Threat Intel platform to check their reputations. It was a repetitive and time-consuming process. Now, we have a playbook that handles the initial heavy lifting. As soon as a suspicious mail is reported, Splunk SOAR automatically parses the email and extracts all the artifacts and cross-references them against our threat intel source.
What is most valuable?
The biggest valuable feature of Splunk SOAR is the integration ecosystem. Since we have used a mix of tools such as SentinelOne and Splunk, having a SOAR that connects seamlessly with everything is huge. The visual playbook editor is quite user-friendly, allowing us to map out logic visually instead of writing complex code.
Splunk SOAR has helped a lot for my team in prioritizing and responding to security alerts and incidents. Better documentation for troubleshooting has been valuable, while documentation is challenging work for us, and it can be difficult to find clear, step-by-step solutions. I would love to see a larger library of production-ready playbook templates.
The impact of implementing Splunk SOAR's automated playbooks on my security analysts' daily workload and responsibilities has been a game-changer for our SOC visibility. Before, we were dealing with large amounts of data, and I could spend way too much time manually piecing together what happened on the endpoint by jumping between different tools. Since we implemented Splunk SOAR, the correlation pulls all those different data streams into a single comprehensive timeline. I have the context I need right there on the screen. My Mean Time to Respond has dropped significantly because I'm no longer chasing false positives or alert noise.
Splunk SOAR has helped a lot to reduce my Mean Time to Resolve.
What needs improvement?
I have found a challenge in my three months with Splunk SOAR in that it is quite a heavy tool to maintain. It's definitely not a set it and forget it situation. Playbooks require constant maintenance and upkeeping. For example, if the API for one of our integrated tools changes or gets updated, the automation can break and I have to jump in to fix it.
I am satisfied with the customization and management of Splunk SOAR playbooks in my environment. Right now, the learning curve to build complex logic from scratch is a little difficult for beginners. However, the templates for common threats are easier to customize.
The use of Splunk SOAR's automation playbooks has improved how my analysts allocate their time during a typical security investigation. We don't need to see small alerts, and two analysts no longer might handle the same type of alert in slightly different ways. Now every alert goes through the same automation steps such as checking threat reputation or pulling endpoint logs every single time. It eliminates human error because I am not missing a step when I'm rushing or dealing with a high volume of alerts. It's basically given me a force multiplier. The playbook handles the boring and repetitive parts, so I can actually focus on the complex incidents that really need human insight.
There is a need for improvement in terms of using advanced terminology.
For how long have I used the solution?
I have been working with Splunk SOAR since the last three months.
What do I think about the stability of the solution?
In terms of stability, overall the stability in the three months I have been using Splunk SOAR, we handle a constant flow of alerts throughout the day. The platform handles that workload without any major lag or crashing. The playbooks execute reliably every time, which is critical because if an automation tool is unstable, it just creates more work for us to verify if an action actually finished. I haven't run into any stability glitch or unexpected downtime, so I have been really confident in its ability to process our triage requests without needing any constant monitoring.
What do I think about the scalability of the solution?
For now, we didn't encounter any challenges or limitations with Splunk SOAR. The scaling has been impressive. Since we have been using it at our organization, I have seen that the platform is built to handle enterprise-level workloads without breaking. In my three months of using it, even as our alert volume shifts or we add more playbooks to the system, the system has remained stable with lots of playbooks and other operations going in the backgrounds and backends. I really appreciate that it supports scaling. As our SOC grows, our SOC team grows, and we need to process more data or more concurrent automations, the architecture is designed to handle that load.
It has a lot of scaling capability. As I said earlier, it has improved a lot in our organization. Scaling as a junior SOC analyst isn't just about doing alerts faster; it's about shifting from being a consumer of a SOC tool to an architect of its efficiency. It is good in scaling.
How are customer service and support?
We have a support team for Splunk SOAR that communicates any technical faults we encounter to the Splunk technical support.
The technical support experience with Splunk is quite good. If we get into a problem, the technical support experience is a bit good in my experience.
The support is generally a bit complicated for someone who is a beginner or new to this product to understand the scope, initial deployment, or any query regarding it.
Which solution did I use previously and why did I switch?
We did also use Shuffle for a SOAR tool before Splunk SOAR.
We decided to switch from our previous solution to Splunk SOAR because Shuffle has some limitations and it doesn't have many features that Splunk provides. It is a little more complex to learn.
How was the initial setup?
I was a little bit involved in the deployment part of Splunk SOAR. From that point of view, the deployment wasn't exactly plug and play, because we integrated it across our existing stack, such as our SIEM and EDR. That's a fair amount of configuration involved in it, especially getting the API keys and authentication set up correctly for each connector. It's not something you can just spin up immediately. Once the core architecture is in place and the connectors are mapped to our environment, expanding it to new playbooks is much easier.
What other advice do I have?
I am satisfied with the customization and management of Splunk SOAR playbooks in my environment. Right now, the learning curve to build complex logic from scratch is a little difficult for beginners. However, the templates for common threats are easier to customize.
We decided to use Splunk SOAR because it's a powerful, reliable engine that has significantly improved our SOC operations, especially in terms of incident response time and scaling features. It's an essential tool for enterprise environments.
Our team recommended us to use and learn about Splunk SOAR, so that's why I got started with it. I really appreciate this tool because it gives us very practical knowledge about the enterprise Splunk SOAR product. I provided this review a rating of 9.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)