Twistlock’s container security solution is the “Compute” side of the Palo Alto Prisma Cloud suite. This video covers deployment, breadth of coverage, and the effectiveness of alerts in mitigating risk.
Patrick: Hi, my name is Patrick Pushor, technical evangelist at Orca Security. And today, we’re doing a competitive comparison against Orca Security and Palo Alto Networks Prisma Cloud Compute. Compute is the second product in the Prisma Cloud Enterprise Edition. And in fact, we’ve reviewed the Prisma Cloud product already in a previous Redlock Palo Alto video. We’ll have combined findings for both Prisma Cloud and Prisma Cloud Compute at the end in our summary. And the testing done against Prisma Cloud Compute was current as of July 1st.
I’m joined by Alaap Pandit, Senior Security Engineer at Orca, who we’ll hear from very shortly. If you’ve seen any of our other competitive videos in this series, you already know our sample lab scenario. But for those who haven’t, we’ve got a very basic lab that we’ve inherited from really any means. Let’s call it, you know, M&A activity, where we know very little about the lab. We’ve been given a lab diagram, but it’s really our intent to sick both of these Cloud security tools at our lab environment and see if we can find what the biggest risks really are.
Great. So let’s do just that. Let’s point both products at our sample lab environment. I’m gonna go ahead and do the Prisma Cloud Compute install. Just before that, Alaap, do you mind taking us through the Orca install? And since we’ve done this once already, let’s go fairly quickly.
Alaap: Definitely, Patrick. So we’re using AWS for our lab environment. And we’re going to follow the steps from Orca. The first, login to your AWS account, and you’ll see I’ve already done that ahead of time. The next, leveraging the CloudFormation template to create the necessary role in policies Orca requires to perform SideScanning and we’re fast-forwarding through save time. So you’ll see, it’s as easy as taking the ARN, pasting, hitting connect account, Orca verifies the permissions and you scroll down a little you’ll see we’ve already begun scanning. It’s as easy as that.
Patrick: Palo Alto Networks Prisma Cloud Compute is deployed using agents or what they call defenders. So we’ll go ahead and deploy on our first machine, which happens to be a machine running containers. So we’ll select that defender and we’ll install. Although sizable, the defender install is a very straightforward process. We’ve gone ahead and sped each of these deployments up for the sake of timing in the video.
As we pivot to our second public-facing machine, a quick cross-reference with the Prisma Cloud Compute online documentation shows us that this flavor of Ubuntu is not supported. So as we reference our lab diagram, that xyz-external-hrweb Ubuntu machine will not be covered. Nor will the xyz-internal-acctproc machine as that’s a marketplace image that we never had credentials too.
As we think beyond deployment, the problem actually gets worse. The Prisma Cloud defenders do have to phone home back to the backend and the console. And if we reference our lab diagram, once again, we have a private subnet where no communication in and out is possible. So by default, with no changes, we have exactly one host with one container that can participate in this exercise.
So we will connect an Elastic IP to each of these two resources in the private subnet to deploy the defender. Obviously, with a private resource that’s intended to stay private, this isn’t an ideal. We will do this for the install and then we will disassociate that Elastic IP from each resource. And we’re gonna show in the video the Linux install, the windows install using Powershell is very, very straightforward as you would expect as well.
Next, of course, we have to create a NAT gateway. Once we disassociate these IPs, we need to wait for traffic to leave our VPC. So, in that way, we bring those two machines on the private subnet back into scope, but at the cost of fundamental network changes that make our network quite a bit less private. Great. Now that we have both products deployed, mostly, let’s have a look at the alert findings. Alaap, do wanna start us off with Prisma Cloud Compute?
Alaap: Upon clicking into Radar, we see the compute sidecar, we see our finance pay web machine, which is a container, notice that we’re filtering color by vulnerabilities and these are showing green while I’d expect to show another color. So clicking into the payweb container, we confirm there are no risks or vulnerabilities that Prisma Cloud Compute alerted us on, but we know there are some. So let’s take a look at the compliance, why there are two high-risk alerts. So upon clicking into it, we see there’s a compliance check against Docker CIS, along with a private key stored in image alert, which is matching to Twistlock. So we’ve covered the deployment we have at the container. Patrick, can you walk us through the host that we have deployed on?
Patrick: Yeah, absolutely, Alaap. Let’s pivot over to hosts. And you’ll notice that no longer are we classifying by container name or container, you think we would be classifying by host, but we are classifying and coloring by vulnerabilities, which is fine, a very different perspective. But I had challenges understanding things like severity, right, if I click into rsyslog, for example, and I drill down to the hosts that have this vulnerability, they’re not classified in a very severe kind of way, medium and this one in the other hosts, it’s actually low. So I’m not sure where those color codings come from. But thankfully, there is a different way to sort of slice and dice this information. If we go to vulnerabilities under Monitor, we’ll get a bit of a dashboard view, not so effective in our small lab. But then across images and hosts, this is effectively the same view that Alaap showed us in the Radar interface. The host is right here. And this is where you have your familiar breakdown kind of per-asset, what that vulnerability landscape looks like, including some risk factors.
If we pivot over to compliance, we can get there similarly in that monitor section. And now we have an additional kind of vector and that’s containers. So we have containers, images, and hosts. Containers are kind of the container as it runs. Again, there are some vulnerabilities in the Twistlock defender. There are some compliance issues there too. But there are rules that you’ll find in the defend section that block them.
So let’s take a look at our container. And definitely, we see some CIS Docker, some internal kind of compliance failures, which makes sense. The only thing I couldn’t really understand was these two compliance failures look very similar to me. In fact, they’re not, they’re contradictory. One says Port 80 is exposed not in use, one says Port 80 is open and not exposed. So that was a bit of a problem. I’d have to dig into that further to see what’s going on there.
And then across images, the Docker image as it stands before it’s executed. Looks like we have some failures here as well. These are the ones that Alaap looked at in the Radar view as well. And then lastly, Hosts. And if we drill into some of these complaints failures, it will tell us kind of where they come from. This looks to be the CIS benchmark for Operating Systems, in this case, Linux. This machine appears to be that plus some Docker benchmarks which is really nice and what we’d expect to find on our machine that runs Docker containers. And then, in this case, it looks like we only have two compliance failures in the case of Windows, and these are both sort of proprietary. And in fact, there is no CIS support for Windows in the product.
Shifting our focus over to Orca, let’s take a look at the findings here. For that, we’re going to use the alerts tab. And right away, we can see the Orca found malware in the container on the host that runs the container on our internal Windows management server. Some observations around non compute resources as well like our S3 bucket, and then some roll-ups of vulnerabilities, which is done a little bit differently than in Prisma Cloud Compute. So this happens to be an alert on an internet-facing service. You can see that Orca has displayed many of the risk factors here including internet-facing service. And notice that doesn’t say server, right, this is a deeper measurement than is my resource facing the internet? This is my service exposed to the internet through all the different networking and security controls of AWS in this case, and it is and so it’s risk appropriately as an imminent compromise but it’s a roll-up of many different vulnerabilities and that’s a little bit different than what we saw at Prisma Cloud Compute.
Also found some unsupported host operating systems and that’s really key. So Prisma Cloud had a hard time with older and specifically Ubuntu 14.04. Orca does not and in fact, it’s a significant risk to your security posture. So they’re called out very specifically. Passwords in shell histories, sensitive AWS keys, and the accounts they map to, as well as insecure private keys. This tells us that Orca found SSH keys that not just they found them, Prisma Cloud Compute told us that as well, but because Orca has this contextual perspective of your whole cloud account, it’s able to tell us what system they map to as well. Some weak host passwords, some unpatched host operating systems, and then some observations around the AWS root account being used. So you know, that’s more of an alert centric view if you’re interested in more of a classic vulnerability perspective, we do have the vulnerabilities tab, or you can drill into sort of per-resource.
Let’s take a look at our container. This is the container that Prisma Cloud Compute found no vulnerabilities in but certainly, we know there are some. Within compliance will be really the test to do both at the cloud level compliance but also the operating system level compliance. And Orca supports a lot of measurements in this way.
So to wrap up, let’s bring back a table we used in the Prisma Cloud comparison, and let’s add our Prisma Cloud Compute column. In doing so, really, the private insecure key was the only thing that Prisma Cloud Compute found. It didn’t contextualize it with a listing of systems that it provided access to but it did find it. So stepping back from specific alert types, both Orca Security and Palo Alto Networks Prisma Cloud deployed quickly and effortlessly while Prisma Cloud Compute did not.
Prisma Cloud Compute is agent-based and as such requires installation on each asset you want protected, whereas Orca requires installation only one time. We also had problems with older operating system support which disqualified Prisma Cloud Compute from some hosts and containers. Orca did a great job finding vulnerabilities and quite a bit more wherever we pointed it. Prisma Cloud Compute found vulnerabilities as well, but was stumped by an older container. We suspected we ran into some sort of bug since this does appear to be a supportive configuration. So we deployed a more modern version of Apache2, one associated with Ubuntu 18.04 instead of 14.04, and vulnerability alerts worked in that scenario. As such, we gave Prisma Cloud Compute the checkmark here, but be aware if you have aging software in your configuration, you may run into some challenges. Only Orca prioritized alerts using the combined context both at the workload and cloud control plane levels to represent actual and effective risk.
Both Orca and Prisma did a good job of testing our cloud configuration. Although Prisma Cloud didn’t detect our S3 bucket as publicly writable. Prisma Cloud does have wider compliance standard support than Orca, but Orca supports the most important tests and that gap is closing quickly. Only Orca was able to detect malware both at the host level and in containers. Despite having rules to do so Prisma Cloud Compute wasn’t able to find any.
Both Orca and Prisma Cloud Compute did a good job of Linux and container compliance. Prisma Cloud Compute was only able to find two compliance issues in our Windows workload and didn’t support the CIS Windows Server Benchmarks at all. Through the process of out-of-band SideScanning Orca provides deep data-driven intelligence without any code running in your environment at all. The Prisma Cloud defender download was larger than 300 megabytes and has a material impact as it runs alongside your important applications.
And finally, our customers tell us that deploying agents and the public cloud simply don’t mix. Even the most successful organizations struggle to get agents quickly and fully deployed on their known cloud assets, and still can’t say with any certainty what percentage of the organization’s actual cloud footprint they are covering. Orca’s approach requires no agents, and in fact, doesn’t even require that the resource is powered on.
With that, thank you very much for joining us, and please tune in for our next competitive comparison.