Splunk SOAR Reviews

We have a couple of different use cases. A lot of it started out in our security space, and we have use cases related to our legal and withhold process. We manage and handle our phishing and spam activity as well as our digital or any copyright act complaints.

We have a multi-cloud implementation, but most of our use cases that are currently implemented tend to not be specific to monitoring our cloud environments.

A lot of it comes down to the time and effort savings. For what we are doing with Splunk SOAR, a human would take a lot more time. Some things are very repetitive, and with Splunk SOAR, it might take a little bit of work to get that human work translated to the programming language or functions inside a playbook, but it allows us to take all that workload off that person and be able to do more with that one person.

For some of our actions, there has been about a 300% increase in productivity. For a lot of the use cases that we have implemented inside of Splunk SOAR, there is not as much to resolve. There are mostly actions where if something happens, it should go and do something, so it is automating that human process. It takes most of the work away from the person.

We have been able to benefit from a decreased workload on our limited staff. That same staff has been able to do more things because they are not having to do the work that this tool is doing.

Splunk SOAR has had no bearing on our resiliency.

The playbooks are valuable. They are the core component. Being able to implement and build a code process to work through and scale out what we want to do is valuable.

I have put a number of ideas on the ideas.splunk.com site for feature requests for the Splunk SOAR product. I posted one of them about three years ago, which finally got implemented in the latest release that just got announced, so the time to implement new features and things like that is a little bit concerning. I tend to post my ideas there so that other people in the community can see the features or ideas. They can then upvote them and make comments on them. I thought that is what the site is for.

We have been using Splunk SOAR for about three years.

Overall, the stability of the product in terms of day-to-day operations is great. It is 100%, but because of the inter-dynamic and connected nature of SOAR, it relies on other services. When those services have changes or issues, it impacts SOAR, but SOAR, unfortunately, does not always handle them very well. It might look like there is a problem in SOAR or in the playbook or process that happened, but it might be a third party that caused it. Unfortunately, it requires someone to go into SOAR and fix something and do rework because, ultimately, that is the interconnection point where it fails.

We have not designed our SOAR to scale. I am just going to grow it as big as it can until finally, I need to split it. We are not that large, so I do not know whether it will scale well or not.

Overall, it has been great. We have not had any major bugs or incidents that have required anything more than requesting copies of the code for apps to make the additional changes that we need. Overall, the organization has been very good with that. I would rate them a nine out of ten.

We had no other automation or orchestration technology prior to Splunk SOAR.

It was complex. Several of our use cases required modifications to existing SOAR apps, meaning new features had to be coded or added to the SOAR app support we wanted to do. Additional custom bits of code had to be created. At the time, we first implemented a lot of the features that are there in the product now, but they were not there. If we had waited two years to do the initial implementation, we probably would have got a much faster time to value because a lot of the work went in early on to build out features, but then they came out with a whole new version of it. The sad part is that for upgrading to the latest version of Splunk SOAR, we had to migrate from Python 2 to Python 3, so the process by which those playbooks and other things get migrated is difficult and requires a lot of work and rework.

We did have a Splunk professional involved in our initial setup. I believe it was a direct Splunk employee. I do not believe it was a third-party person. They were good. 

We have a lot of Splunk knowledge. We have complex use cases. We have a high level of knowledge. We did not want someone who just came out of the training class. They had to send us someone who was going to be valuable to us, and they did.

It is hard to quantify whether we have seen a return on investment. The expectation is that we do, but we are so short on staffing that it is difficult to calculate whether it is giving us a full FTE worth of a person. We think we are getting it, but we do not have good numbers to say that we are.

It is also hard to say whether we have seen time to value because there are some use cases that take so long to implement. Because of the way that SOAR is structured and interconnected with so many systems, to get something going and then make sure it continues to work, the time to value starts to become a little bit back and forth. Some of the use cases are great. The services underneath them have not changed. There has not been a lot of transition, but with the other ones, such as an API update, an update is required on the SOAR side, so it is a little harder.

When we first purchased our Splunk SOAR license, it was based on an event-count model. It was based on the number of events. I had strong opinions at the time that automation should not be stifled by the amount of automation you can accomplish, so the previous structure was not as beneficial for us. Later that year, we got told or saw at a conference that they announced user-based pricing.

We are now in a renewal period, so we migrated to a user-based license model, which is more appropriate for us so that we no longer have to worry about stifling our automation based on the quantity. If I have an event that happens 500 times a day, but it is relatively minor, I can still spend the effort to automate it. The previous model meant that we could only automate high-value items in Splunk SOAR, meaning they had a large cost of the human factor to automate them, whereas now, I can transition. I can do many different things with Splunk SOAR that we were intentionally limited on.

We had evaluated other options twice. We evaluated before the acquisition by Palo Alto and then during our latest renewal period, we went ahead and reevaluated Palo Alto's competing products just to make sure that we are doing our due diligence about technology and whether this was going to be better or worse for us.

Overall, I would rate Splunk SOAR a six out of ten.

We are primarily using it to automate tasks for our incident response team. They use it to block suspicious traffic from our network detection system and for alerts from our endpoint security system. Those are the two major use cases we're using it for right now.

It has definitely saved a decent amount of time for our analysts so they can focus on other tasks. This gives us more value for man hours.

It has definitely improved our business resilience. It's given us greater visibility into the environment we have and the ability to collect all of the threat and log data and put it into one central place.

The ability to connect it to external apps is the most valuable feature. We've also gotten a lot of use from writing custom apps for some of our authentication systems for password scramble.

Splunk's ability to predict, identify, and problem-solve in real time is really good.

Splunk's ability to provide business resilience by empowering staff is fairly high. It detects issues as they come up and responds to them.

We have seen time to value. I did help configure it, but we do have the cloud solution, so it was mostly in place.

It has definitely helped to reduce our meantime to resolve. Having it there to automatically take action as events come in and not needing the analysts to have to go out and have a look is how it saved time.

We've run into a few minor issues. Some of the playbook writing is a bit complicated. We've had a few hiccups with the source control. We'd really like to use GitHub deployment keys for a dedicated account. We haven't been able to do that. I think those are some of the major ones. 

There is a general learning curve as far as playbook writing goes. 

I have been using SOAR for four to five months.

Stability is good. We've had a few hiccups with apps, but never a major outage. I would rate it an eight out of ten.  

I haven't really grown it very wide yet, but I could easily foresee us doing that.

I've opened a few tickets for different issues with apps, and they have always been responded to fairly quickly. I'd give support a ten out of ten. 

Positive

I did help configure it but we have a cloud solution, so it was mostly in place.

The development was fairly straightforward. There were some issues setting up the single sign-on, but we were able to get help from Splunk to get all that straightened out. The roles in user accounts and onboarding were all fairly straightforward. App configuration is also something that's pretty streamlined and intuitive.

We did it all in-house.

We have seen ROI in its ability to streamline and automate mundane tasks that we would run into on a daily basis. It freed up DevOps people from having to maintain custom tools that were previously used to complete similar tasks.

I would rate Splunk SOAR a nine out of ten. 

My primary use case is for SOC automation but it's used for a lot more than that. Some of the use cases are more or less appropriate for it. It's capable of doing a lot of things.

We use the SOAR platform to ingest alerts and escalations that we get. They do the actual enrichment processing and triaging but we don't use it for detection. We potentially could, but it's not what the product is meant for.

The visual playbook editor updates that they released have been absolutely instrumental because the old editor was impossible to look at for most of the time. It made my eyes bleed. I still have to look at it from time to time. 

Splunk does provide substantial value. 

It definitely does reduce our mean time to resolution through the enrichment details that it provides. Inputting your facts and details of the things you do not want to see with the events coming into it and easily filtering down off of that is one of the main value drivers outside of phish removal.

The most valuable feature is the API connector, depending on how it's formatted and who made the actual app offering for it. The REST API is my favorite component. It's very easy to use. The filters are also really valuable. Those are the two primary features but I enjoy using the rest of it. 

SOAR is probably the most unreliable product Splunk has and that's because most of it is content driven from what you put into it. There are certain parts of it that have a little bit of difficulty at volume too. It's always changing. There is new stuff coming out for it that's going to make it a little bit better, but it does have some drawbacks.

It's specifically geared for SOC and not broader automation. The artifact filtering that's forced on everything inside the platform is pretty awful. It's for a subset of active playbooks which, out of the two hundred that we own, I think three or four of them are active, but we have to play with that setting for each one of them. 

Every block should also have that option specifically because if you're not doing the artifact filtering on the front end, it's not good. 

We've had lots of processes that have been victim to filtering not working appropriately at scale. It's hard to actually track down and trace because we can't reproduce the issues that we see in our testing environment or in production. That was two minor versions ago. It might have changed, it might not have, but we don't have a lot of trust in that feature.

UI elements like interacting with our analysts are near impossible. Finding stuff on the actual dashboard is really impossible most of the time. One example is that the timeline takes up three-quarters of the screen, but not a single person uses it because you have to individually set the container, the artifacts, and the actions to a specific attribute field that's really difficult to correlate to the actual events you put into it. The artifacts are really weird too because they're not traditional forensic artifacts. You shouldn't be able to change the value of an actual artifact. It was in that capacity but we also use it for that purpose in the platform. 

My company was one of Splunk's first five customers. I have been using it for the last three years.

I've only crashed SOAR a few times and it was my fault. If you have a production environment that's been running for a month or two and you have a few thousand events in it, if you mess up your query when you're trying to ask it a question and you do page size zero, it will just give you things on it, and it will crash it. That's a fun thing, but you shouldn't do that in general. That was a mistake on my part. Generally, it is very stable and available as most of the issues are usually the fault of the vendors that it's talking to, but that's with any platform.

Scalability is interesting. Some of the assets do choke each other out. There is a cyclical lock thing that we had to fix on our inside. We have a CrowdStrike app, and we give it a file and ask it to do something and it goes great. It tells us that the default wait time is fifteen minutes, and there's only one of me. But there are five processes competing for that, and you get a giant backlog. We had to make our own custom app to get it later. 

We have about fifty users on SOAR and a few hundred playbooks. Our environment is fairly large in terms of standard customers.

I didn't do the initial integration, it was many years ago but we do deployments with the platforms team because we have the experience. 

We have it down to a pretty good science right now because platform science does a really good job of automating the steps that go into setting up the server and whatnot. One good thing about the SOAR connectors that we have in the apps is the ability to save states and for apps just to self-heal. That has been really helpful because things go down from time to time and we don't have to worry about it because there's a second or third process that's going to pick it up.

I have heard they are changing pricing, not possibly for the better. In comparison to the other vendors we looked at, they're all in the same ballpark of what they should be billing on. SOAR makes the most sense out of all of them, in terms of the billing factors.

We are looking at other platforms currently to compare areas. Splunk's editors are exceptionally better to look at. Visually, it's easier to find things and configure them. 

There is more capability out-of-the-box for doing typical data transformation that you don't have to write too much code for, which is really nice. The code blocks have annotations in them. So when you actually open and look at what you worked on, four or five months later, you have your notes right there in the same place where it runs, which is really handy. 

It's also just built for broader automation and it's all more HTTP, actions-based. Instead of having to build a connector, then put that on GitHub and install that in your platform, you can define an endpoint with credentials and you can do the same thing with SOAR. It's encouraged to do it with the actions and assets, which can be beneficial depending on what the product is. 

If we do continue using SOAR, I think we're going to default to using more HTTP actions and stop using too many assets because it's a bit of a burden to create one, especially if out-of-the-box the actual configuration doesn't do what we need it to. 

One example of this that we have is the request tracker app that we use for all of our tickets. When you ask it for the ticket information, it will return the metadata on it, nothing inside the actual ticket. That's a fork we have to create. It didn't actually do the basic product functionality that the vendor should be providing. 

We also find that the vendors don't always keep the SOAR connectors updated. Sometimes they'll update the associated API, and then their connector will stop working because they're on different versions, and then we have to force our own fix on that. They usually make a SOAR connector just to say that they have one, but they won't put too much effort or thought into it.

I'd probably rate the functionality an eight or a nine out of ten. I would give the UI a four out of ten. I would rate general Splunk SOAR a seven out of ten. 

My company has two use cases for Splunk SOAR. We use it to enrich alarms by pulling in outside sources of information. Splunk can also automate actions while ensuring they are structured and reproducible.

With SOAR, you build a workflow, so you think ahead about all the steps that can be automated for a specific type of investigation. You need to do a decent amount of work in advance so that it does exactly what you tell it to. We need to gather a lot of essential details for our incidents. For example, if we're investigating a suspicious email, we need to gather a lot of information about who the user is.

We can enrich alerts by pulling in more information about each user. We can see their locations, roles, etc. Having that knowledge may influence our decisions or analysis. We can also submit files to be reviewed and get the results. It's akin to a doctor ordering diagnostic testing. The doctor can use the results to make decisions. 

Splunk has benefited us from that perspective, but it takes some effort upfront to think about the flow and build it out. It reduces some of our manual research by offering additional context for events. I can pull the files, automatically submit them to a sandbox, have it run, and get the results from the sandbox. I don't have to notify one of my engineers and tell them to get this file I submitted to the sandbox. 

It also improves ticketing because we can notify users when suspicious emails are quarantined and ensure a ticket is associated with it. We constantly track the work. We can close the ticket when the issue is resolved and release the email if it's legitimate. Splunk helps us document the entire process.

Splunk reduced our detection time a little by helping us quickly differentiate between an actual event and a false alarm. I don't view SOAR as a detection mechanism in itself. The events still occur. It helps enrich alerts so we can distinguish between actual events and noise. 

For every event, it saves the responding staffer about 15 to 20 minutes because they need to do less data entry. They need to do the research and follow our procedure for a ticket. It takes time to assign a ticket and make entries. Finally, they need to perform an assessment and close the ticket.  

Splunk SOAR frees up our staff to work on other things to a degree. There is always more than enough work, and somehow the volume still feels like it's always crazy. Still, it allows people to do some other tasks. It will enable my engineers to focus on more thought-provoking problems instead of menial tasks. I want them to spend time learning the underlying mechanism in case SOAR goes down. 

If Splunk is unavailable for whatever reason, I always want to have someone who understands the mechanics of what it does. At the same time, it improves retention if you can eliminate some mind-numbing work and allow them to focus on challenging items. Your employees will be happier in general. They can do some more unusual, engaging work that enables them to learn and grow. 

We couldn't consolidate any tools by using Splunk SOAR because everything was manual before we implemented it. We didn't have an automation tool. 

I like the way Splunk interacts with various systems via the API. The ability to integrate Splunk with our ticketing system has been an immense help because we can maintain our workflow while blending Splunk with our support desk and other ways that we track work.

Sometimes we flag events based on conditions in the app or service that is sending us the feed, and we focused on a couple. We get some normal events, but we also see some security issues occasionally in the same feed. I don't know if they injected this or if this was the first time we saw it. There was another type that was security-related, but we didn't know about it before. 

We have playbooks written to extract these events and put them into the workflow since it wasn't structured as expected. It was a miss for us. We couldn't figure out why it broke or what actually happened there. It was something in this feed with legitimate and security events, so we tried to understand the names and what we would call them.

It was a unique time. That goes back to an inability to detect these kinds of events. API documentation is typically a weak spot. Many vendors focus on the product first and save the API information for the very last. 

Splunk's integration isn't bad. However, it comes down to which APIs are available. For example, I would like to automate file extraction, and a particular vendor seems to have an API that should do that, but I can't. You're at the mercy of the vendors. While APIs probably leverage more than ever, it's still like pulling teeth to get some vendors to support it correctly. Nevertheless, it's highly beneficial when it works.

Depending on the playbook, it can sometimes get a little crazy and overwhelming, but I think it's generally okay.

I have used Splunk SOAR for about a year. 

Splunk is relatively stable. We had an issue early on. It was a bug. Splunk sorted it out. Our uptime has been consistent. 

We haven't had any issues with scalability. 

It took a little time before we realized Splunk SOAR's value. I have one engineer who dedicated himself to building many of our playbooks and a lot of the automation that we have. Another engineer is only starting out. 

You need to have the right mindset so that you don't get scope creep. It's critical to manage what you want to do because you're dealing with a blank slate. There are costs like computation time, but it's relatively straightforward. You need to be thoughtful and take your time to do everything in small chunks. It took us a while to get going with SOAR because we have to integrate our devices. It isn't a turnkey solution. 

I don't remember Splunk SOAR's price off the top of my head. Still, I believe it was a solid value because of the time saved, consistent results that are reproducible, integration with multiple systems, etc. The benefits justify the cost. 

We didn't seriously consider other options. We looked at what was happening in our environment, and our SIEM is a hub for our security operations. Palo Alto is another vendor we use, so we briefly looked at their SOAR solution. However, it wasn't in the right position to work with the Splunk piece. Splunk gathers all the log material. We can act on that and interface with all of our key security devices because they have rich associations with multiple security vendors. It made more sense for us to focus on that.

I rate Splunk SOAR a nine out of ten. If you're thinking about implementing the solution, you should consider which events will save you the most time. Think about the procedures you're following today and where you can benefit the most from automation. 

The second piece is thinking about the other solutions involved and the capabilities they offer. Do you have the API access to automate what you want? Your success depends on those vendors and sorting that stuff out. You must also approach your SOAR playbooks and workflows in a modular way. Don't try to handle everything upfront. 

It's best to automate piece by piece. You don't need to tackle an entire ecosystem right off the bat. Take what you can and constantly improve it as you grow more comfortable. Splunk SOAR's strength comes from its interactions with other systems. Ensure that you're fully leveraging that.

We have around 95 different use cases for Splunk SOAR that help secure our environment. 

The solution has helped us automate and customize some of our servers.

I give an eight out of ten for the ease of creating a playbook. The visibility of the solutions playbook viewer is user-friendly.

We have integrated 15 plus services with Splunk SOAR. Splunk SOAR is easy to use for investigations as long as they have experience with the solution.

Splunk has helped us reduce our security event volume. The solution has also helped us reduce our mean detection time by 80 percent and has helped our security IT staff save time to work on other projects.

Splunk SOAR has as well helped us consolidate tools in our environment. 

Scalability is the best feature of the solution.

The algorithm and machine learning have room for improvement and can be more user-friendly.

The integration with the phone system, price, UI, and performance have room for improvement.

I have been using the solution for one year.

I give the stability a seven out of ten.

I give the scalability an eight out of ten.

I previously used Swimlane which has a better GI than Splunk SOAR.

I give the initial setup an eight out of ten. There is a lot of documentation available online to help with deployment and as long as we know how to configure it, it is straightforward. For basic deployment, we do not require much time.

The implementation was completed in-house.

I give the price a six out of ten. Splunk SOAR is priced higher than most other solutions.

I give the solution a seven out of ten.

I recommend Splunk SOAR for larger organizations.

We wanted to automate the process of creating playbooks, orchestrating events, customizing integrations, and deploying applications such as Thread Connect and Wireless Total for enrichment and threat hunting. We have tailored these applications to meet our specific needs and redeployed them.

As a programmer, I am glad that Splunk did not position itself as a no-code or low-code platform. The solution allows us to customize playbooks and incorporate custom code, allowing us to drag and drop elements while still writing code to build the integrations we need. This makes Splunk a great solution for a solid platform.

Splunk's support for integration is subpar and has room for improvement. 
Splunk should make more effort to keep up with the latest developments in the external world, so that their applications, integrations, and enrichment apps are up to date. Additionally, the documentation and support should be improved, as the experience, their users have had in the past has been unsatisfactory. We were very disappointed that our queries were left unresolved for six months, as it was a time for response rather than solutions. Additionally, several tickets were lodged with Splunk, yet the issue persisted for half a year.

I would request that SOAR add a feature that allows the extraction of documentation from playbooks. This would enable developers to quickly understand the features and use cases associated with a playbook, so they can modify or interact with it. This would eliminate the need for someone to manually explain each playbook in detail. 

I would suggest making the app customizable and deployable in an easy and straightforward manner. This would save time and effort compared to the current process.

I have been using the solution for four years.

Although not the most stable solution, I would say the overall stability of the updates is satisfactory. I give the stability a seven out of ten.

We had difficulty with scalability, but I would not attribute this to Splunk. It could have been due to our lack of knowledge or lack of support from Splunk. I give the scalability a six out of ten.

Our company utilizes a variety of SOAR tools, including Splunk SOAR, Swimlane, and Palo Alto XSOAR, along with ServiceNow for SecOps. Initially, Splunk SOAR was chosen as the SOAR tool due to its compatibility with the majority of our other tools. Unfortunately, it became apparent that SOAR was difficult to install, service, and price, leading some teams to switch to SwimLane and Palo Alto XSOAR.

The initial setup is not necessarily an easy task, nor is it overly complex, so I would say it's of medium difficulty. Splunk could have provided more documentation and support, considering it is not a free product. It would have been much more helpful if Splunk had provided basic understanding and assistance for those installing the solution.

Deployment took several hours each time to install and upgrade, and we often encountered broken pieces of functionality due to miscoordination or non-sequential startup processes. I remember there were five items that came with Splunk SOAR. Deployment was a difficult process, and we ran into issues every time we had an upgrade.

We used Git version control to deploy our playbooks to SOAR, and then we would pull them back to the production SOAR to bring them into use.

I give the solution a six out of ten because of the scope of building playbooks and automation. Unfortunately, this is accompanied by a downside due to a lack of support, bad applications, inadequate documentation, and a general lack of support.

We have thousands of people using the solution.

I would suggest alternatives to Splunk SOAR due to the cost and poor support. However, if cost and support are satisfactory I would recommend the solution.

Basically, we are using it for most of our automation, and not as per the SOAR, although it is a SOAR application. We are not using it just for security purposes. We are using it for various purposes like maintenance. 

We do have our own data center where we have our maintenance on the infrastructure side, and the application has to be brought down. Here it has done exceptionally well. We shut down all our different applications by writing our code in the shell languages, and we upload through GitHub. It means that we can just call that script, and it gets triggered on the particular server, and it shuts down. It's like a workflow.

The workflow has been created in such a way that it helps us. Earlier, when we used to have to manage it manually, when we shut down the application, it used to take a lot of time. Now it is done within 30 minutes. In our environment, we have SAP applications, and SAP has its own commands to shut down the applications, databases, et cetera. So it is just not limited to all those shutdowns and this. We do have various other stuff as well, like upgrades. So we have written the upgrade codes, and now we can upgrade X number of SAP applications and databases as needed.

It has helped us with the SAP kernel upgrade. Recently, due to security fixes, and security bugs, we had to upgrade the various SAP applications. To do it manually, it would have taken around five to six months to complete. However, with this product, we were able to complete it within two months since we just wrote a script, and it got triggered in various systems, and it fixed everything. We were saved from the security perspective as well since it ensured we had less vulnerability for less time. Also, thanks to SOAR, only two people were needed to run all those scripts, and just have to monitor everything. That's less personnel. 

The customizable playbook is the most valuable aspect of the solution. 

With the Splunk vendor itself, the vendor is supporting us in the creation of those playbooks. We have created playbooks in such a way that they are a universal playbook, where we just have to bring in any type of command which needs to be triggered, and it works. If we did things another way, we would have to install our agents to connect the particular application. Here, we don't have to have to do that. It can work in the playbook itself. We just have to give our credentials. The credentials also are in an encrypted format, so we are much more secure.

The solution is stable. 

Technical support is helpful. 

What we have seen is if the workflow gets halted or if we want to halt a workflow, it cannot be resumed. We have to trigger the entire plan from step one. That is a bit annoying. If something is wrong, we can't just resume stuff. We'd like it to be possible to pause things without having to start from square one. 

Reporting could be better. We are getting reports, yet not in the way we want. Whatever fails, for example, we want all those errors, the logs, in an attachment, which can be sent easily over an email just by the click of a button. Right now, we cannot send over an email. We have to pull everything, and we have to download it.

We've been using the solution for the past two years.

The stability is great. I'd rate it eight out of ten. It's not breaking very often, and the playbook makes things easy for us. 

I'd give the level of scalability seven out of ten. There is still room for improvement. We'd like to have more use cases and automation.

Technical support has been good. I work on technical parts of the product and bring in use cases, et cetera. If there are any problems, my colleagues check with the vendor and so far, we have had good support from them. We haven't had many issues. 

We were using IBM BigFix before this, and we used it for various purposes like patching on the Windows server. The same solution was also used for the automation of shutting down the system, upgrades, and many other things. Ultimately, we decommissioned it, and we moved ahead with the Splunk SOAR.

The vendor was the one who deployed the solution. Later on, they just installed it on our site. We gave everything to the vendor, and the vendor supports everything since it is on the cloud. 

We have witnessed an ROI, and it is good. We've gotten good feedback from senior management. 

I don't handle the pricing aspect of the product.

We are both partners and customers of Splunk. 

If you are a company looking into SOAR and if you are a customer of Splunk, then you should definitely use it. And if your product is most probably looking for security or for some alerting purposes, it will help you to automate your many, many use cases. You can build many, many things with Splunk and on the SOAR side and you can automate your end-to-end process. Also, companies should know that a minimal language knowledge of Python is required.

I'd rate the solution eight out of ten overall. Even for people who are not too technical, it's a good product.

Splunk SOAR streamlines the handling of common customer scenarios that arise across diverse situations. Even when specific expertise within our team varies, Splunk SOAR empowers all users with pre-built playbooks, guiding them through the required actions in any circumstance.

Splunk SOAR's UI is user-friendly for managing workflows.

The integration of Splunk SOAR is good.

When we implemented Splunk SOAR we were able to reduce our team of five down to three.

Splunk SOAR's quick response to incidents is the most valuable part.

The cost of Splunk SOAR has room for improvement.

I have been using Splunk SOAR for a couple of years.

Splunk SOAR is stable. We have not heard of any issues from our customers.

Splunk SOAR is scalable.

The cost is high and the licensing is on an annual basis.

I would rate Splunk SOAR an eight out of ten.

We use the solution to automate some of our legacy processes. We review items like phishing and emails.

The product’s integration with other Splunk products is valuable. It's easier to collect and enrich all the data to give our incident response teams better access to the information to make their decisions.

Some of the training materials are on a basic level. They don't feel like they're really in-depth. I would like to have more advanced and in-depth training.

My organization has been using the solution for two months.

There have been no issues whatsoever with stability. I wouldn't expect there to be any downtime.

We have a large environment. We have more than 10,000 devices in our organization. It's a complex environment, depending on which areas we're working with. We have different types of regulations.

The team we're working with right now is extremely helpful, and it's easy to coordinate with them and get them involved. They're very welcoming and open to helping us. They are going out of their way to set up meetings to answer questions and help us with the process.

Positive

There's a lot of overlap of concepts between our current SOAR solution and Splunk SOAR. The dashboard's functionality in Splunk SOAR has great value compared to our current platform. It was not easy to make dashboards or reports at a high level in our current solution. It was a bit tedious and difficult. It’s a lot easier to facilitate with Splunk SOAR. Splunk SOAR integrates nicely with all the other Splunk products. We can enrich the data.

We are still going through the initial deployment of the product. The deployment is easy since it is a SaaS solution. There's not much for us to configure right out of the box.

One of the biggest factors that helped the management to decide to switch to Splunk SOAR was its cost. The solution's cost model, Mission Control, and other features make it cost-effective.

We are fairly new to the solution. We are still adjusting Splunk SOAR. As I use the platform more, it'll become more intuitive. My core focus is on the SOAR platform. We're still beginning to get the tool fully customized for us. We are going through the basics to get all the way to fully leveraging the tool. We are still considering how to go from our current setup and expand it.

Our organization monitors multiple cloud environments with Splunk SOAR. It is important for our organization that the product has end-to-end visibility into our cloud-native environment. It allows us to have better incident response. Having visibility on where the attacks or different issues are coming from allows us to better respond to them.

The workshops are the biggest value I get from attending Splunk conferences. I'm getting a lot of real-world examples from different companies. It helps with networking and meeting other individuals who are going through the same type of process or are already leveraging Splunk SOAR. I can get feedback on how they're leveraging the platform. It gives us a lot of insight into things we should consider as we start to set up and build environments.

Overall, I rate the product a ten out of ten.

We use the solution to search the logs, check the threat indicators, threat tasks, etc. It helps us check any alerts that we get in the alert report. Based on that, we react to that particular alert.

The tool's most valuable feature is its searchability and ease of action on the logs. I can easily search within the logs and take action on them, and I can trace them back to my environment because the way the logs are written is very helpful for us.

Overall, if any incident or anything happens in terms of security, then Splunk SOAR is the tool we look at first.We have a nice dashboarding and alerting system when we see an alert. It gives us direct access to the specific alert, detailing what happened when it occurred and where it originated. It helps us to identify the affected site faster. 

Splunk SOAR helps us to save a lot of time. We have integrated it with some SIEM tools. 

The tool's response is slower because it has to search through a huge dataset, which can be improved for latency.

I have been using the product for three years. 

The only issue I've noticed is the latency when accessing data for longer periods. Sometimes, fetching data from the API can take a lot of time. However, apart from that, everything else seems stable.

The tool is scalable. We have scaled it to about thousands of assets. 

I haven't had much direct interaction with customer service and technical support. Our central Splunk team manages those aspects for us. I have heard that the response time is good. 

The tool's deployment is done in-house. 

I rate the overall solution an eight to nine out of ten. It's helpful from both an operations and product security perspective.