Splunk SOAR Reviews

My use case for Splunk SOAR is security automation.

We are running a Splunk SOAR cluster. Three nodes in three different environments in a dev-test and prod environment.

The SOC team has been much less burdened since implementing Splunk SOAR. They're able to completely automate away some events. At the very least, they get so much information gathered from our automated actions that they're able to almost immediately take action if action isn't already taken by the playbooks that are being run.

Splunk SOAR has helped reduce our mean time to resolve. It has reduced, for example, ten-minute investigations into 30-second ones. Sometimes all our analysts need is a little bit of context, and they can immediately make a decision based on that. There are some events that we have where normally investigating them would take about ten minutes. We get a ton of those a day. I did the math and Splunk SOAR saves over 70 hours a week, which is massive. That savings is only for those types of events alone. In that context, it is a huge improvement.

Splunk SOAR has helped improve our business resilience. It's an extremely powerful tool. I do think that the ability it has depends on the people implementing it, though. The implementation needs to be good. If it's not, that's not Splunk SOAR's fault, that's the organization's fault. If they do it right, it is incredible.

Splunk SOAR has saved us time with alert triage. Even on simple events that might take ten minutes, we're taking that down by around 95 percent. Almost all events can at least have some sort of automation that saves minutes and every minute counts and saves us so much time.

Splunk SOAR has saved us time in threat response.

The most valuable features are the Splunk SOAR apps and playbooks. I am a Splunk SOAR developer, and my job is to make sure that integrations with third-party systems are done well. I give guidelines for how to properly make Splunk SOAR apps. These two features are essential in how the apps will work.

One area for improvement in Splunk SOAR is version control for Splunk apps. Currently, for Splunk playbooks, we can hook up a Splunk store to a Git repository with playbooks in it, and it will pull them down periodically, which is amazing. Splunk apps don't have that, and that would be extremely helpful because we do custom coding a lot. There are many vendors out there. And because there isn't source control, we need to emulate that same behavior, which causes us to do other things. For example, we need to create a Git repository somewhere on SOAR and create a clone job that periodically runs a Git pull action. After that, we bring all that SOAR data into that repository. We need to have a Git Hook that automatically tars the app we just created and then uses the API to automatically upload it. Because of that, now we have this app data that's being doubled up because we have SOAR apps in the Apps directory on the back end of Splunk SOAR, and we also have this Git repository, which holds all the same information. That could be highly simplified, and that is a big gap that would make my life and probably other developers' a lot easier. 

There is a specific situation that comes into place when we have a Splunk SOAR cluster we have to work with. If we also don't have it hooked up to an external Splunk Enterprise instance, trying to debug what's going on in the cluster is extremely difficult because there are 45 different log locations. That could be extremely difficult to try and find out what is going on with all the microservices that are being used in a Splunk SOAR cluster. I had to personally develop a tool to be able to monitor all those logs at once and then parse it out and query that log once we're done with whatever operation so that we can get a clear picture of what's going on in the SOAR cluster, which has been immensely helpful, taking hours off of debugging time to do that. It would be nice to have a tool like that natively available in Splunk SOAR to begin with. Even without the cluster, I believe it's over 30 log sources that could go wrong. 

Providing Splunk app developers and playbook developers Python Stub files so that way when they create custom code through their IDE, they can have IntelliCode suggestions. It could be dangerous for someone who is coding to constantly have to look back at the documentation and not see, for example, a Python dictionary where they are expecting it. In reality, it's a list, that could cause errors when a playbook runs or when an app runs, and that could be a potential incident that now goes unresolved or a serious issue. That's dangerous. Providing SOAR app developers with some Python Stub files that they can use for IntelliCode suggestions would also be helpful. Also having slight changes to the way that it's expected to create custom modifications to already existing apps on GitHub or Splunk base by essentially inheriting from the base app when we want to have custom modifications, and developers should have to explicitly override any methods from the base class that's there. That way, we're not modifying any of the underlying layers of the base app that's there. We could also hook it up to a Git Repository to receive those updates into the base app and then the custom app. This way we have these custom app features, we have all these extra things being put into it, still on the custom app end so we can have our features and the base app all in one. I think that'd be a novel solution.

I have been using Splunk SOAR for one year.

As a standalone instance, SOAR is extremely stable. I don't have any issues with it. The only reason there might be an issue is if we lack resources on the hardware itself, and that's more of a problem from an architecting, and engineering perspective, not exactly Splunk SOAR. When it comes to the Splunk SOAR cluster, it is pretty complicated. There are five different microservices, and if we have an issue there, we have 45 different log sources to get that info from, and it can be hard to debug it. If we have a problem, it can be hard to diagnose which microservice we might be having issues with.

Splunk SOAR scales well though when we get to I believe, more than five nodes in a Splunk SOAR cluster, it becomes a little bit unwieldy, and it takes long for things to happen. If we need to update something in the cluster, things can get slow and we have been told by professional services to try and keep it at three nodes because anything more than that is unwieldy as they have said. I believe that is a known issue with Splunk SOAR.

The technical support from Splunk has been good. Whenever we need to engage in professional services, they're always able to give us new information that we did not explicitly know, or they're able to validate what we need. Usually, when we talk to professional services of some kind, which is the main form of customer service I think that we use, it's usually quick and to the point in exactly what we need, which is fantastic. There have been times when we requested professional services, something we needed, and that was developed in-shop just for us, which is fantastic. The tool that was made to remove SOAR cluster nodes was requested by us, and then it became a feature later on. So that was amazing and helpful.

The initial deployment was extremely easy as a stand-alone instance. It's a straightforward process, especially for someone like me who has had to set up other servers containing security tools on them. In terms of setting up a cluster, I unfortunately haven't had experience setting up a cluster explicitly. I have had experience removing nodes from a cluster and with a new tool that was released, I believe, in version 6.0. It was made easier. When it comes to deploying Spunk SOAR, involves downloading the tarball, extracting it, running the pre-install script to ensure proper configuration, and then running the installation script. As long as system resources are sufficient, the installation itself should be quick despite the application's size.

The biggest metric that I've seen as a developer admin and DevOps engineer is the time saved. I don't think that on our end, we have set up the ROI functionality in SOAR yet, but I know that the timing has been massive. We should get it set up in  SOAR that way the customers see the value.

I would rate Splunk SOAR nine out of ten. It's a fantastic product it needs a few more features to make it amazing. The clustering does need to be simplified a bit. Version controlling for apps and making app development just a little bit easier for developers would take it to the next level. There's no other SOAR product that does what Splunk SOAR does as well. All other SOAR are frankly inferior, but it just needs that little bit of extra functionality to make it a truly great product.

We use Splunk SOAR to automate response for ransomware attacks.

We are triaging with SOAR. It helps the analysts with investigations by automating repetitive tasks and presenting them with scripts that include user lookups, and other information. It also includes widgets for notes.

Splunk SOAR has helped us save on repetitive tasks. Before we had SOAR, we used to triage in Splunk Enterprise using our app but we have migrated most of the searches into SOAR. Now with SOAR, we can get it to close the alerts we know about automatically. It is much faster so the analyst doesn't have many alerts to deal with. Now that we have migrated, we are moving more towards automation and using SOAR to work more for us. Splunk SOAR has freed up the time of three full-time analysts to focus on other tasks.

We only use Splunk SOAR on-premises, but end-to-end visibility is key to having a fast response to ransomware attacks even when we are not in the office.

Splunk has saved us time in threat response.  

We are not a 24/7 SOC, so the most valuable feature of Splunk SOAR is the auto-response to threats when we are not in the office and the notifications that it sends to the on-call engineer.

The banks have recently bought Splunk Enterprise Security. We haven't implemented it yet. It is being built. The new version coming out is going to incorporate Mission Control and SOAR. It looks like we will need to move Splunk again and do our triage in Enterprise Security. The reason we took the step to SOAR was for the functionality available for the triage which is now being incorporated into Mission Control. We can easily migrate the data over to Mission Control. For us, the next steps will be to use it as a backend server where we can run playbooks and triage in there.

It would be ideal for us if Splunk SOAR could integrate with Teams. 

I have been using Splunk SOAR for three years.

The version of Splunk SOAR we are on now is stable. We did have issues with the failover in the early days but now with how we have it configured there is hardly any downtime.

We use about one point six terabytes of data per day with Splunk with about 6,000 users. We don't need it to scale at the moment.

We use Splunk technical support a lot. They are good and we have a good relationship with our Account Manager who helps us with the tickets and provides us with articles.

Splunk technical support wasn't always readily available, and in one instance, a support representative didn't have the expertise to resolve our specific problem.

Positive

Before Splunk we had our analyst log in manually to Carbon Black. No tool automated the tasks until we switched to Splunk.

We had to get a small engineering team of about three people to be dedicated to Splunk SOAR so we could have Splunk professional service come in and give us a startup. That worked well. They passed their knowledge to our engineering team and we maintain it in-house now.

The implementation was completed with the help of the Splunk professional services team.

I found the price of Splunk SOAR to be good.

I would rate Splunk SOAR nine out of ten.

Our initial Splunk installation was a successful proof of concept but needed to be made more reliable. Splunk professional services offered assistance, but due to limitations in finding a suitable SOAR solution, we opted for a cold standby implementation. This allows us to switch to the standby instance if the primary SOAR becomes unavailable.

We use it for risk management. And, we're trying to automate our L1 and L2 agents' functionalities. Through automation, we're trying to reduce the effort that is put in by an agent.

The amount of time that our L1 and L2 agents used to take to do a simple task was about 40 hours per week. Using SOAR and automation we have reduced that to 10 to 15 hours per week. That is a big win. Building up the playbooks helps with the daily investigations for our agents and risk management team.

It has also helped to reduce our mean time to detection. Something that used to take, on average, 30 minutes now takes about five minutes. It really depends on the kind of event it is. And it has definitely helped free up our IT staff for other projects.

Splunk SOAR has also reduced our dependency on UBA, although we still use it. And similarly, while we still use Splunk Enterprise Security (ES) for threat detection, SOAR has reduced our dependency on that by using it for investigation. Of course, ES has to be there as it is receiving feeds, but the SOAR/ES collaboration is just a better way to function.

It's pretty easy when it comes to setting up assets. If you want to fetch emails or call a REST API, you can set up an asset and grab that information. Of course, we need to do some improvisation as far as coding is concerned, but you can just set up an asset such as O365. Or, if you are looking for any of the threat feeds, you can just set up an asset and they're readily available. You can then grab that particular information or those logs and bring them into SOAR.

Another good aspect is SOAR's ability to integrate with other systems and applications. We haven't faced any challenges with that. It's pretty simple and easy.

And although I'm more of a developer as opposed to an end-user, the reviews that we get from our end-users are that they picked it up pretty quickly. Based on that feedback I would say using SOAR for an investigation is pretty easy and convenient.

Creating playbooks using the solution’s playbook editor, for me, is very cumbersome. There have been instances where I have said to myself that I just don't want to use this editor. I might just use a code block and write my own code within it. I've tried using the editor for some of our playbooks, but I find it's cumbersome. It's easy to drag things in the GUI, but for the actual coding part and joining those bits in a full code, it's not as good as I would like. They have tried to make it as simple as possible, but its functionality is not up to the mark.

The functionality in the playbook editor is 80 percent there, but that 20 percent is still lacking. They could make it more efficient.

I've been using Splunk SOAR for almost two years.

Initially, there was some lagging, but there are no issues at all now.

I'm pretty impressed with Splunk's customer support. They're pretty responsive and I appreciate that.

Positive

We were using Phantom, which is a Splunk product, but they asked every customer to migrate from Phantom to SOAR. In my opinion, it's still the same thing, but in a more improvised way.

It is a cloud solution for us. The deployment was in between straightforward and complex.

Training our SOC team to use the playbooks happened pretty quickly. After a couple of weeks, we were up and running.

We have somewhere between 30 and 50 users of SOAR, and there is no maintenance on our side.

Splunk employees helped us out.

It took us four to five months to see value from SOAR, it didn't happen right away. But that was because we were still building up the environment, including the playbooks. 

Initially, we were trying to use it as a case management system, but after a lot of development, it wasn't up to the mark for the end requirements that we had from the business for that. SOAR is more of an orchestration and automation tool. Using it for case management was not appropriate on our end.

My advice is that if you are already using other products from Splunk, like Splunk ES or Splunk Core, first try to refine your logs to make them SaaS-compliant. I don't think SOAR accepts a SIEM model, it's more of a SaaS. Start looking at the logs and making them compliant if you want to bring some of your logs into SOAR. Also, spell out the integrations you require, the type of functionality you want to use it for.

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.

Positive

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.

One of our use cases is to automate any kind of process after investigation. When going into an investigation, we want to make sure that we have the right tools to use. Instead of having multiple tools, we can bring them all into one platform, such as Splunk SOAR, to provide us with that information.

Splunk SOAR has not benefited us yet because we are currently in the development process, but I believe that in the future, it will help us streamline our process and our RTR to respond and detect. It is going to help us in the future, but it has not brought us any benefit yet because we are currently building it up.

It is very important that Splunk SOAR has end-to-end visibility into our cloud-native environment. If there is no visibility, then there is no ability for us to detect on time and respond in time. It knocks out a lot of that time discrepancy.

Splunk SOAR has not yet helped reduce our mean time to resolve. It will be helping us in the future due to its playbooks and its compatibility with Mission Control and other Splunk integrations.

It has helped us with our business continuity and our ability to respond to different threats that might be out there.

Splunk SOAR has not saved us time in alert triage. We are still in the early stages of getting Splunk SOAR onboarded and developed, but I believe that it will significantly reduce our time to triage. Similarly, Splunk SOAR has not saved us time in threat response, but it will do so in the future.

Splunk's unified platform has helped consolidate networking, security, and IT observability tools. Splunk's unified platform has been great for every organization. Every analyst has been able to use one unified area.

In Splunk SOAR, I find the playbooks valuable. We get to create multiple playbooks, and within each playbook, there is a different type of investigation attached to it, which helps out an analyst or new analysts coming on board. When they get an incident, they do not need to find out where to start. All they have to do is to go to a particular playbook. It will give them end-to-end specifics on what to do and how to process it.

They can improve what they are currently doing. They can provide more playbooks or at least template playbooks that are in their repository. That is one area.

Another area would probably be related to onboarding different playbooks or different tool sets that new engineers have. Eventually, they will get there to ingest more tools and datasets into their SOAR. 

In terms of additional features, it is hard to say. There can be more integration with other data ingestion platforms out there, not just Splunk.

We have been using it for about one month.

We have not played with it too much yet. Once we are able to play with it more and get more details from it, we can respond to that.

It can be very scalable just because of the number of different apps that the community pushes to it. Right now, it is not there yet, but I believe in the near future, it is going to be the best growing platform out there.

Splunk's customer service is great and impeccable. I believe that they have been a very valuable resource to our organization and our team.

I would rate their support an eight out of ten just because I believe that no one really gets a ten. It is an eight just because the answers that they cannot answer for us, they are able to get from the community. The community really helps out, but they are always there to help, and they are always responsive.

We are using Splunk Cloud, the public cloud, but we also have on-prem. We use AWS.

As the initial start of the Splunk SOAR, we are getting started with developing the playbooks and getting the configurations set up with our users and toolsets. It has been pretty easy so far. I have not had any hiccups, but we will see where that takes us as we finish our development.

We did not use any integrator or reseller.

We have just started getting our metrics developed, ingesting into Splunk, and showing that to the executives.

I would rate Splunk SOAR a nine out of ten just because it does hit all points for the use cases as an analyst, engineer, or developer. It allows us to automate and orchestrate all of our detections and respond to them very quickly.

Splunk SOAR is primarily used for automating security use cases for clients who want to reduce human intervention and personnel involvement. It facilitates end-to-end security workflows and helps to decrease the time spent on manual investigations.

Splunk SOAR can be deployed both in the cloud and on-premises. The cloud deployment comes pre-installed, so if we want to connect to any on-premises applications, we may need an additional server.

Building playbooks using Splunk SOAR is an easy process.

Splunk SOAR's playbook viewer is excellent. The viewer underwent an update a couple of years ago, making it much more streamlined and easier to use.

Splunk SOAR offers end-to-end visibility throughout our environment. The solution provides us with information about the actions being executed, the flow of the playbooks, where failures occur, and everything in between. It also collects logs of the actions in the backend.

Splunk SOAR simplifies the visualization and troubleshooting of our cloud-native environment. We only need to set up an additional server to connect to our cloud-based applications. Once that is done, the process becomes very straightforward.

Splunk SOAR has the ability to integrate with other system applications in our environment. Currently, SOAR is integrated with nearly 300 applications through APIs.

Splunk SOAR, as a whole, has helped numerous clients automate processes, reduce investigation time, and free up personnel to focus on other tasks. It is a highly effective tool for security automation.

Using Splunk SOAR in an investigation is extremely easy.

Splunk SOAR has significantly reduced our mean time to detect in a relatively short period.

Splunk SOAR has helped reduce our mean time to resolve.

Splunk SOAR has helped free up our IT staff's time to work on other projects.

Splunk SOAR has saved our organization a good amount of time overall.

With Splunk SOAR, we have been able to consolidate tools in our environment, such as Radius and CrowdStrike.

The ability to automate Splunk SOAR and customize the playbook use cases is the most valuable feature and is very exciting for me.

The UI can be more customizable for the clients.

I have been using Splunk SOAR for almost five years.

Splunk SOAR is highly stable. The benefits that Resilience offers to SIEM are crucial at the moment, given the vast amount of data and other factors. It aids us in efficiently handling that data, and, with these additional tools, it helps to manage the data with minimal human intervention. As a result, we can reduce the mean time to resolve, the mean time to detect, and save money as well.

Splunk SOAR's scalability is great. I have never had a client complain about the solution's ability to scale.

The technical support team prioritizes all the tickets based on their criticality. They genuinely provide end-to-end support and contact us via email before scheduling calls. If it's a cloud instance, they simply attempt to push changes over the stack, making them extremely helpful.

Positive

The initial deployment is straightforward. It can be completed by a single person, who handles the installation and setup.

I've heard from clients that they are receiving more value from the fit than they initially expected. They are also pleased with how much Splunk SOAR has been assisting them with various tasks. Additionally, a couple of companies have reduced the number of personnel in their security team due to the implementation of SOAR.

For completely new users, it may take some time to perceive the benefits. However, for those who are already familiar with the solution and hold certifications, they can quickly recognize the advantages.

The licensing cost is reasonable.

I give Splunk SOAR a ten out of ten.

I started looking into security automation at that time. Initially, it was Phantom, which was quite popular five years ago. Splunk bought it and changed it to SOAR, so it became pretty easy to use. It's a relatively new concept, which is why we wanted to see how it works.

Once Splunk SOAR is deployed, it takes a couple of weeks to train the SOC team of our clients to use the playbooks.

Splunk SOAR requires maintenance if we plan to scale up the database, increase the number of users involved, and expand our development efforts. Additionally, the amount of data processed and other factors should be considered. For a premium user who actively uses it daily and is heavily involved in development, the solution may need regular maintenance. However, apart from such cases, I believe it doesn't require significant maintenance.

For those considering using Splunk SOAR, there is ample documentation available on the Splunk website. Additionally, they can download a free trial version, which can be installed on their server for experimentation.

We utilize Splunk SOAR to automate our incident response process. I am the sole engineer in my current organization, responsible for working on Splunk to automate the incident response process followed by our team. This involves investigating various incident response procedures established within our security operations center.

The main problem we want to solve is the time it takes to invoice tickets and remediate incidents. Therefore, we aim to reduce that time. If our analysts manually handle and investigate each incident, it will take longer compared to using this solution, which automates most of the processes. Whenever an incident occurs, the playbook and Splunk automatically initiate the necessary actions to gather the required data, enabling the analyst to make informed decisions and address the incident promptly.

Creating a playbook using the Solutions Playbook Editor, is relatively easy if we possess some knowledge of Python code and the ability to write various types of flow diagrams.

The visibility of the solution's playbook viewer is excellent. There is adequate documentation that assists individuals in learning how to utilize the playbook to construct solutions.

Splunk SOAR's ability to integrate with other systems and applications in our environment is straightforward. It has numerous capabilities to integrate with various security tools, as it supports open APIs. If the solution supports the API, we only need to write the corresponding APIs in the pipeline code and utilize those API tools to construct the integration, enabling us to take action accordingly.

The most significant improvement I have observed is time-saving in the Security Operations Center incidents. We receive approximately a thousand to eleven hundred incidents per day, and if we were to manually investigate these incidents, we would require a team of ten to twelve people. However, by utilizing Splunk SOAR, we are able to handle the investigation of these thousand alerts with just six or seven people.

Splunk SOAR is not difficult to use in an investigation; it depends on the use case. I haven't encountered any issues with the implementation of the case solution, and there don't seem to be any limitations in that regard.

Splunk SOAR assists us in reducing the volume of security events. Whenever an incident occurs, the playbook initiates actions simultaneously with its generation in our security operations center. These incidents are automatically handled by the playbook, while incidents requiring manual intervention are assigned to our analysts. All other incidents are handled automatically through Splunk SOAR playbooks. Splunk SOAR has reduced the security event volume by forty-five percent.

Our mean time to detect has been drastically reduced. Before Splunk SOAR our security operation center, analysts worked on a queue. Whenever an alert was received, it was placed in a queue, and the incidents were investigated one by one. However, with the implementation of Splunk SOAR, we now have instant knowledge and analysts can start investigating more effectively. The required data is already gathered by the playbook itself, aiding analysts in making more accurate decisions in less time. This has resulted in a reduction of our mean time to detection by at least eighty percent. Previously, without Splunk SOAR, we experienced significant mean time to detect because analysts had to focus on one incident at a time, leaving other incidents waiting. Now, there is no need for incidents to wait for an analyst to take over. The playbook automatically gathers the data, allowing the analyst to have all the necessary information as soon as they start, enabling them to make prompt decisions.

Splunk SOAR has helped reduce our mean time to resolve. The resolution of incidents sometimes depends on different teams that need to investigate and send notifications for action. However, the notification of those incidents has been significantly reduced, and we can confidently say that we have achieved a fifty percent reduction in our mean time to resolve.

Fifty percent of our IT staff's time is saved through using Splunk SOAR, and we can utilize that time to work on the other project we have.

Splunk SOAR has saved our organization forty-five percent of our time.

The best feature is the integration and the custom Python code that we can write. Splunk SOAR provides us with both of these capabilities, allowing us to integrate different security solutions with Splunk SOAR and take remediation actions directly on those security tools. Additionally, we can write our own Python code, which can be used and embedded in a Splunk SOAR playbook, enabling us to utilize that code directly within the solution itself.

There is a lot of room for improvement with the UI. 

I would like to have more integrations with cloud technologies and functionalities such as AI within Splunk SOAR.

I have been using Splunk SOAR for five years.

Splunk SOAR is stable.

Splunk SOAR is a hundred percent scalable.

The initial setup was straightforward and took approximately three hours. Four individuals from our network team and one individual from the Splunk personal service team were required for the deployment as we needed to configure the server.

We have observed approximately a forty-five percent return on investment with Splunk SOAR.

Splunk SOAR is more expensive compared to other options for SOAR.

We assessed various open-source options prior to choosing Splunk SOAR, such as Securonix SOAR and Shuffle.

I would rate Splunk SOAR a seven out of ten. The solution necessitates expertise in Python coding, which is challenging to find in individuals. Additionally, Splunk SOAR lacks sufficient AI integration.

Before using Splunk SOAR, it took us approximately six hours to block certain IPs on our firewalls. However, after implementing Splunk SOAR, we were able to accomplish the same task within just five minutes.

We deployed Splunk SOAR on a single server.

We have around nine people that use Splunk SOAR in our organization.

Maintenance is sometimes required based on the incident volume we receive. If we experience a higher volume, we need to maintain the RAM and other components in our server. Therefore, it is important for us to exercise caution in this regard.

I highly recommend Splunk SOAR for individuals seeking to automate the incident response process in their security operation centers.

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.