What needs improvement with Splunk Phantom?

The visibility of Splunk SOAR's playbook viewer is rather unclear to me; I wonder what the visibility is for. There are indeed some problems with integrating Splunk SOAR with other Splunk products or other vendors in my system, and it took a while after implementing Splunk SOAR to train my SOC team on how to use the playbooks. Splunk SOAR does not help me reduce my security event volume; in fact, it makes them massive. Splunk SOAR does not help me free up resources to work on other projects; they are not good in this regard. I have not seen time to value with Splunk SOAR; I am curious about what time to value means. I believe Splunk SOAR can be improved by adding more integrations and out-of-the-box integrations, and by increasing the number of admins that can access the solution simultaneously. I see the need to inject more AI in creating the playbooks. I think they can inject more threat intelligence into the solution.

I'm not an expert on Splunk SOAR, but I'm sure our team members know what areas could be improved. I haven't spoken to them specifically about what could be improved or what they would want Splunk SOAR to improve.

I haven't gone too far into it to see anything that needs improvement yet. We can likely include some features related to the integration with on-premises resources, rather than focusing solely on the existing automation. These are the additional features that could be included in the future. Splunk's Unified Platform does help consolidate networking security and IT observability tools. They should integrate Splunk Enterprise Security better into Splunk Cloud.

It would be nice if we could put it on other search heads, not just Enterprise Security. We have an ad hoc search head, and compatibility with that would be beneficial. More training classes from Splunk University would also be good.

There are areas in Splunk SOAR that have room for improvement. To make Splunk SOAR a better solution, there could be better built-in debugging tools, smarter playbook suggestions, and enhanced lifecycle management. Real-time collaboration features, more granular metrics, and improved reporting for dashboards would also be beneficial.

The creation of playbooks is complex in Splunk SOAR ( /categories/security-orchestration-automation-and-response-soar ), and the number of integrations needs enhancement. Although it enhances alert handling, it still has a journey to compete with Palo Alto SOAR and FortiSOAR ( /products/fortinet-fortisoar-reviews ).

The dashboard could be improved and some other features. SOAR should integrate network capabilities, allowing us to also monitor the WLAN network. Splunk is also expensive and difficult for beginners to learn. It's hard for a new user to figure out how to visualize old threat data. It took two to three months to learn with hands-on experience how to use the dashboard, visualize events, and analyze threats.

I haven't had any issues with the solution so far.

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.

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.

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 think some of the case management functionality could be improved. Improving the integration ecosystem can raise the quality of the bottom tier of the integrations so that they can work better out of the box. In general, our company is pretty happy with the tool.

The solution must provide more AIOps to improve predictability.

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

The cost of Splunk SOAR has room for improvement.

The number of playbooks on offer should be increased.

The UI can be more customizable for the clients.

Splunk SOAR should improve its ease of upgrade, which is a pain point for us right now. Each upgrade to the version requires expertise and time commitment. Then, we usually have to troubleshoot it with support.

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.

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.

The visibility of the solution’s playbook viewer depends on the right you assign to the analyst. SOAR has the flexibility to distinguish between the roles of analyst and owner. If the analyst's role is to just work on a ticket, they cannot view the playbook design platform. That is limited to the owner. That can be both a good and bad thing. A major problem I have faced in SOAR's rights distribution is roles and responsibilities. Suppose I am initially granted user rights or analyst rights, but later on, I also get admin rights. SOAR is unable to amend the limitations of my role. I raised a support ticket with Splunk about this. They said it's a bug in their 5.3.5 version. To fix this, I had to reinstall the entire platform from scratch, just to amend the rights and responsibilities of one role. This bug was not fixed. Also, the latest GUI is terrible. The previous one was better. Another point is that while using Splunk SOAR in an investigation is not difficult, there are some complex parameters. We have SOAR case management, but the licensing is going to put a big hole in your pocket. Also, there is an issue with investigation node addition. When you are doing node additions you cannot grant the entire environment to have SOAR visibility into the incident. So when you integrate it with an ITSM tool, like ServiceNow or Jira for ticketing purposes, there is a challenge. When you do nodes for investigation on a regular basis, sometimes it does not update our ServiceNow platform, which is terrible. It is a redundant activity for an analyst to update that in the case management as well as in the ITSM tool. Although SOAR provides integration, the functionality of investigation and nodes is terrible when it comes to integration. An additional area for improvement is custom function creation. It's terrible. A newbie cannot create custom functions right away. They would require a solid understanding first. Also, the reporting is really awful. If I want to do a report for a customized time period, such as the last three days or the last four days, or from the 10th to the 12th of June, that is not available in SOAR at all. That kind of feature is available in Cortex XSOAR. Reporting is a real challenge.

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.

The application does not work properly and does not pass the log-based configuration. I feel that some kind of review should happen in the application. This review should validate things so that we can get the right information. Splunk does not tell us where the IP address is associated with.

The pricing could be a bit more reasonable. It would be great if it were feasible for smaller organizations.

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 Phantom 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.

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.

There are only problems if the customer is not ready with emergency plans or standard procedures if something breaks. There is some homework to be done before you can really properly use Splunk and the Phantom solution. Resolution times could be faster in terms of support. It could be easier to implement.

Splunk Phantom can improve IoT/OT security-related case studies or your use cases. Their integration with identity and access management (IAM) solutions is a bit shaky. They don't have good integration with a lot of IAM solutions. They do have good capability in terms of user access management internally, but even with privileged user access, they have a good module. However, if they have to integrate with solutions, such as CyberArk or IBM IAM solutions they are lacking, the visibility of user access is not that much.

The Splunk Phantom case management feature lacks some of the functionalities like the possibility to fully customize the fields for the tickets/events and create custom statuses.

I haven't used it fully, but based on my usage, I could not find simulation tools and features. It currently lacks simulation features, which are important for me for creating a playbook. It is also very expensive for my region.

In the beginning, we couldn't find any specific documents for every function. It wasn't easy to navigate to what we needed. However, lately, it has improved and we are able to find Splunk documents for all the functionalities of Phantom. It would be helpful, on the other hand, if there were videos regarding each functionality. That would make it even easier to work with Phantom. We are able to find some documentation in written form, and that's fine. If it is in a video format, then it would be better due to the fact that, in some environments, we find some other issues or something and it would be nice to have a visualization of the process. The solution is a bit more expensive than other offerings. I'd recommend that the solution add some new apps, or some average services, like bots or G-Suite. We may already have G Suite in Phantom. Bots, like any common VPN service, would be great, however.

We haven't had too much experience on the solution. The solution is relatively new in the market. It would be ideal if we could automate processes even more. The interface is great, however, they could still keep refining it to make it even more user friendly.

Phantom was only recently acquired by Splunk so it is not fully integrated yet. Our area of concern is that Splunk Phantom works with the other Splunk products. At this point, there are certain things that are not fully operational across the rest of the product line. The extension of the product to allow for better integration with other data sources is something that needs attention. We want to see improvements made to the APIs such that we can connect to many different systems and data sources. The search capability could be improved by way of better indexing and also integration with third-party solutions such as Elasticsearch. I would like to see escalation management and integration with communication tools like Slack. I would like to have more capability around analytics. There needs to be a better facility for documenting and storing issues, as well as being able to find those issues. Splunk does a good job of that, so I think that it will be done.