Please share with the community what you think needs improvement with Prisma Cloud by Palo Alto Networks.
What are its weaknesses? What would you like to see changed in a future version?
One problem was identifying Azure Kubernetes Services. We had many teams creating Kubernetes systems without any security whatsoever. It was hard for us to identify Kubernetes because the Prisma Cloud could not identify them. From what I heard from Palo Alto at the time, they were building a new feature to identify those. It was an issue they were already trying to fix. In addition, when it comes to access for developers, I would like to have more granular settings. For example, in our company we didn't want to display hosts' vulnerabilities to developers, because the infrastructure or containers team was responsible for host vulnerabilities or the containers. The developers were only responsible for the top application layer. We didn't want to provide that data to the developers because A) we thought it was sensitive data and B) because it was data that didn't belong to developers. We didn't want to share it, but I remember having this problem when it came to the granularity of granting permissions. They need to make the settings more flexible to fit our internal policies about data. We didn't want developers to see some data, but we wanted them to have access to the console because it was going to help them. One possibility was to develop our own solution for this, using the API. But that would add complexity. The console was clean and beautiful. It has the radar where you can see all the containers. But we just didn't want to show some data. It was a pain to have to set up the access to some languages and some data. Another thing that was a pain was that in our on-prem environment there was a tool that sometimes generated a temporary container, to be used just for a build, and Prisma would raise some compliance issues for this container that would die shortly. It was hard to suppress these kinds of alerts because it was hard to find a standard or a rule that would fit this scenario. The tool was able manage the whole CI/CD pipeline, including the build as well—even these containers that were temporary for a build—but sometimes it would raise too much unnecessary data. Also, one of the things that it's hard to understand sometimes is how to fix an issue. We managed to do so by testing things ourselves because we are developers. But a little bit of explanation about how to fix something would help. It was more showing what the problem was than it did about how to fix it.
Some of the usability within the Compute functionality needs improvement. I think when Palo Alto added on the Twistlock functionality, they added a Compute tab on the left side of the navigation. Some of the navigation is just a little dense. There is a lot of navigation where there is a tab and dropdowns. So, just improving some of the navigation where there is just a very dense amount of buttons and drop-down menus, that is probably the only thing, which comes from having a lot of features. Because there are a lot of buttons, just navigating around the platform can be a little challenging for new users. They could improve a little bit of the navigation, where I have to kind of look through a lot of the different menus and dropdowns. Part of this just comes from it having so many awesome features. However, the navigation can sometimes be a little bit like, "I can't remember where the tab was," so I have to click and search around. This is not a big negative point, but it is definitely an area for improvement.
The remediation part could be better. It should be able to automatically remediate on the basis of its artificial intelligence. If there are alerts, it should directly act and surround the malicious threat with a container or something. Instead of waiting on approval, it should immediately act. There should be no need for manual input when there is a threat on hand. The ability to scale is limited as it is a SAS product. The licensing is a bit confusing.
IAM role management need to be improved like the day dome9 provides we can provide access to cloud resource on need basis along with time limit
When it comes to protecting the full cloud-native stack, it has the right breadth. They're covering all the topics I would care about, like container, cloud configuration, and serverless. There's one gap. There could be a better set of features around identity management—native AWS—IAM roles, and service account management. The depth in each of those areas varies a little bit. While they may have the breadth, I think there's still work to do in flushing out each of those feature sets. My understanding of Palo Alto's offerings is that they have a solution that is IAM-focused. It's called Prisma Access. We have not looked at it, but I believe it's a separately-licensed offering that handles those IAM cases. I don't know whether they intend to include any IAM-type of functionality in the Prisma Cloud feature set or whether they will just say, "Go purchase this separate solution and then use them next to each other." Also, I don't think their SaaS offering is adoptable by large enterprises like ours, in every case. There are some limitations on having multiple consoles and on our ability to configure that SaaS offering. We would like to go SaaS, but it's not something we can do today. We have some capability to do network functions inside of Prisma Cloud. Being able to integrate that into the non-cloud pieces of the Palo Alto stack would be beneficial. The solution's security automation capabilities are mixed. We've done some API development and it's good that they have APIs, that's beneficial. But there is still a little disconnect between some of the legacy Twistlock APIs versus some of the RedLock APIs. In some cases the API functionality is not fully flushed out. An example of that is that we were looking at integrating Prisma Cloud scans into our GitHub. The goal was to scan GitHub repositories for CloudFormation and Terraform templates and send those to Prisma Cloud to assess for vulnerabilities and configuration. The APIs are a little bit on the beta-quality side. It sounds like newer versions that some of that is handled, but I think there's some room to grow. Also, our team did run into some discrepancies between what's available, API-wise, that you have to use SaaS to get to, versus the on-premise version. There isn't necessarily feature parity there, and that can be confusing.
The alignment of Twistlock Defender agents with image repositories needs improvement. These deployed agents have no way of differentiating between on-premise and cloud-based image repositories. If I deploy a Defender agent to secure an on-premise Kubernetes cluster, that agent also tries to scan my ECR image repositories on AWS. So, we have limited options for aligning those Defenders with the repositories that we want them to scan. It is scanning everything rather than giving us the ability to be real granular in choosing which agents can scan which repositories. This is our biggest pain point. There are little UI complexities that we work around through the API or exporting.
Based on my experience, the customization—especially the interface and some of the product identification components—is not as customizable as it could be. But it makes up for that with the fact that we can access the API and then build our own systems to read the data and then process and parse it and hand it to our teams. At that point, we realized, "Okay, we're not never going to have it fully customizable," because no team can expect a product, off-the-shelf, to fit itself to the needs of any organization. That's just impossible. So customization from our perspective comes through the API, and that's the best we can do because there is no other sensible way of doing it. The customization is exactly evident inside the API, because that's what you end up using. In terms of the product having room for improvement, I don't see any product being perfect, so I'm not worried about that aspect. The RedLock team is very responsive to our requirements when we do point out issues, and when we do point out stuff that we would like to see fixed, but the product direction itself is not a big concern for us.
One scenario, in early days, was in trying to get a view on how you could segregate account access for role-based access controls. As a DevSecOps squad, you might have had five or six guys and girls who had access to the overall solution. If you wanted to hand that off to another team, like a software engineering team, or maybe just another cloud engineering team, there were concerns about sharing the whole dashboard, even if it was just read-only. But over the course of time, they've integrated that role-based access control so that users should only be able to view their own accounts and their own workloads, rather than all of the accounts. Another concern I had was the fact that you couldn't ingest the accounts into Prisma Cloud in an automated sense. You had to manually integrate them or onboard them. They have since driven out new features and capabilities, over the last 12 months, to cater for that. At an organizational level you can now plug that straight into Prisma Cloud, as and when new accounts are provisioned or created. Then, by default, the AWS account or the Azure account will actually be included, so you've got visibility straight away. The lack of those two features was a limitation as to how far I could actually push it out within the organization for it to be consumed. They've addressed those now, which is really useful. I can't think of anything else that's really causing any shortcomings. It's everything and more at the moment.
The challenge that Palo Alto and Prisma have is that, at times, the instructions in an event are a little bit dated and they're not usable. That doesn't apply to all the instructions, but there are times where, for example, the Microsoft or the Amazon side has made some changes and Palo Alto or Prisma was not aware of them. So as we try to remediate an alert in such a case, the instructions absolutely do not work. Then we open up a ticket and they'll reply, "Oh yeah, the API for so-and-so vendor changed and we'll have to work with them on that." That area could be done a little better. One additional feature I'd like to see is more of a focus on API security. API security is an area that is definitely growing, because almost every web application has tons of APIs connecting to other web applications with tons of APIs. That's a huge area and I'd love to see a little bit more growth in that area. For example, when it comes to the monitoring of APIs within the clouded environment, who has access to the APIs? How old are the APIs' keys? How often are those APIs accessed? That would be good to know because they could be APIs that are never really accessed and maybe we should get rid of them. Also, what roles are attached to those APIs? And where are they connected to which resources? An audit and inventory of the use of APIs would be helpful.
The integration of the Compute function into the cloud monitoring function—because those are two different tools that are being combined together—could use some more work. It still feels a little bit disjointed. Also, the permissions modeling around the tool is improving, but is still a little bit rough. The concept of having roles that certain users have to switch between, rather than have a single login that gives them visibility into all of the different pieces, is a little bit confusing for my users. It can take some time out of our day to try to explain to them what they need to do to get to the information they need.
We would like it to have more features from the risk and compliance perspectives. On the governance side of it, we did want it, but the licensing costs for that are so high. As a result, I have to integrate this solution with a couple of additional tools. For example, suppose I wish to assign something to an organization or to another person. To do that I have to integrate it with something like JIRA or Confluence where I can ask them to provide the pieces of information. If the licensing costs were a little lower, I would have been able to assign it then and there. As it is, though, I need to assign it from one platform to another platform, one where the team of engineering people is working. I still need to go to multiple platforms to check if something was assigned, and I have to keep checking between the two platforms to see whether it's not done or not.
The feedback that we have given to the Palo Alto Networks team is that the UI can be improved. When you press the "back" button on your browser from the Investigate tab, the query that you're working on just disappears. It won't keep the query on the "back" button. Also, the way the policies are structured and the alerts are created could be better. It requires a lot of manual work to search through the policies when creating an alert. These are minute nuances. They are not major issues and are more about convenience than they are product bugs.
In terms of improvement, there are some small things like hardening and making sure the Linux resources are deployed well but that's more at an operational level. Day-to-day, we do find a lot of issues but having a tool to help us with them is what we want because manually, it's not feasible for us. Other than that, we not really looking for any other add-ons or plug-ins because that was our core problem.
In our testing, we have found the Check Point product CloudGuard Dome9 to be more user-friendly at this point. Palo Alto Prisma's interface was not as user-friendly. Palo Alto should work on this part of its solution to be more competitive with ease-of-use. I do not feel Palo Alto is short of any features, but if we compare the two side-by-side, I think the user interface for Palo Alto needs to be improved to make it at least as good as Dome9.
I'm not sure about areas for improvement on the solution, however, I do think the compliance and dashboarding could be better. The innovation side of the solution could be more efficient and more detailed.
The pricing for the solution needs improvement.
I would like to see the inclusion of automated counter-attack, although this is probably illegal.
Is one better than the other?