Redlock Palo Alto vs Orca Security

You can find an overview of our Cloud Security Punch-Out! series and growing list of cloud security solution comparisons here.

Redlock Palo Alto Comparison Transcript

Patrick: Hi, I’m Patrick Pushor, technical evangelist at Orca Security. And today, we’re going to be taking a look at a comparison between Palo Alto Network’s Prisma Cloud, and Orca Security. We’re going to focus on the value and the fidelity of the alerts associated with each platform in terms of the real meaningful intelligence focused on the risk to my security posture. To be clear, the comparison was done against Prisma Cloud Enterprise Edition as of June 12th, 2020. Prison Cloud Enterprise Edition also includes the Prisma Cloud Compute product (aka Twistlock Container Security) that will be featured in a separate video. I’m joined by Alaap Pandit, senior security engineer at Orca, who you will hear from very shortly.

So, imagine for our sample scenario today that we are managers of organizational IT and we’ve acquired through really any means, but let’s talk about maybe M&A activity. We’ve acquired the infrastructure of a company that had a cloud-first directive. So, they try to do everything they could on the public cloud before any other means and so they have a large investment. Imagine acquiring that kind of technology, maybe without the people to support it, right, without the people to explain exactly what everything does, and that’s having to figure out the function, but from a security perspective, you know, where we’re covered, where we’re not, and where the largest risks are.

Okay, great. So, let’s get into it. The first thing we’re going to look at is what it takes to point both of these solutions at our cloud environment and gain some actionable intelligence. So, Alaap, why don’t you take us through the Orca installation, what it takes to get up and running?

Alaap: Definitely, Patrick. So, I’ve already gone ahead and used the email link from Orca to register my credentials from my Orca portal. And as you can see, it’s empty. So, now, we’ll go ahead and onboard an account and you’ll see just how easy it is. So, we’re using AWS for our lab environment. And so, I’ll follow these three steps from Orca. The first of which is logging into your AWS account.

As you can see, I’ve already gone ahead and did that ahead of time. The second step is leveraging the CloudFormation template, which creates an Orca security role and the necessary policies for Orca to perform side scanning, namely, the read-only policy and the ability to take snapshots. So, while the stack it’s created, let’s come to Outputs, go ahead and hit refresh. And now, we have the Amazon Resource Number that was created from the CloudFormation. So, we’ll need this Amazon Resource Number to paste back into Orca. And once we hit “Connect Account”, Orca will verify that the permissions are in fact correct, and then it will begin performing its scan. So, you can see we are successfully connected. It still shows no data though, but if we scroll down ever so slightly, you’ll see that Orca is, in fact, scanning. And that’s how easy it is.

Patrick: Thank you, Alaap. Very, very straightforward, done with policies and roles, not credential exchange like the old way. And as much as I’d like to give Orca the sort of checkmark on the installation test, Prisma Cloud is virtually the same thing. So, we’ve gone ahead and sped up the process and strip some clips out. But basically, we choose our cloud type. We choose whether we want read-only or read-write for some enforcement. We then launch again into our CloudFormation template, much like we did with Orca. We grabbed the generated ARN from the output. Bring that back to Prisma Cloud. Choose whether we want to group this account with others for sort of top-level administration. And that’s really it. We have gone ahead and enabled the flow log since we did the install so that we get those kinds of alerts as well. So, with both products installed and really both taking just about the same level of effort, Alaap, let’s get into our findings.

Alaap: Now that I have connected our AWS account to Orca and Patrick has connected it to Prisma Cloud, let’s take a look at the findings. The first thing I want to check is the inventory in each tool. We have two private subnets, one with two machines. The other only has one. We also have a public subnet, two machines, and one container, which is hosted in the EC2. So, I’d expect to see the container as well. The public subnet is connected to a load balancer followed by an internet gateway, and the entire environment is encapsulated in a VPC, and there’s also a bucket exposed to the internet. Now that we’ve reviewed our lab, let’s first check Prisma Cloud. In the Inventory tab, we should expect to see about six machines and a bucket, but we see 1,500. Well, this is definitely not what we were expecting. Let’s check Orca to see what it shows us for inventory.

Now that we’re in Orca on the dashboard, let’s go to the Assets tab and we see 65 assets. So, while it’s still not quite right, a lot better than what Palo Alto Network’s Prisma Cloud was showing us. And if we scroll to the right, we can actually select container drop-down and VM drop-down, because as we just reviewed, we have a couple of EC2’s and a container, and there we go. Orca actually shows us what we expect to see. So, let’s come back into Prisma Cloud, and we’ll dig into the Alerts. The first thing you’ll notice, we’re filtering by severity, from highest to lowest. And there are about eight high-severity alerts from Prisma Cloud. The first AWS security group does not restrict all traffic. And this is a default security group configured by AWS, but we’re only in one region, yet, Prisma Cloud is alerting us across all regions in the AWS account, even though we don’t have any assets in them.

So, coming back to the Alerts page, we noticed that S3 buckets are accessible to the public, it alerts us on that. And S3 buckets of Global GET permissions enabled. So, let’s click into the S3 bucket alert, and we see it does show the bucket name. Fantastic. Now, let’s take a look at some more alerts. AWS Internet exposed instances. Great. So, we just reviewed our environment. We know we have a public subnet with two EC2s and the container as well. So, let’s click into it and see what Prisma Cloud shows us.

So, Prisma Cloud was able to pick up that container host and the external HR web, both of which are in our public subnet. But it is missing the container. So, we’ve covered a few alerts in Prisma Cloud, and the majority of them seem to be related to security groups. As you can see on my screen, the few that aren’t, we’ve already gone into. Now, let’s take a look at an Orca and see what it produced scanning the same cloud account that Prisma Cloud was scanning.

So, we landed on the dashboard page of Orca calling out 15 alerts, but let’s go to the Alerts tab. And it’s still showing 15 alerts, but there is a noticeable difference in the fidelity behind the alerts provided by Orca versus Prisma Cloud. For example, malware in a container and malware on a management machine, something that Prisma Cloud completely missed. But there is some overlap, for example, a public bucket. However, Orca is telling us that it’s readable as well. It highlights the bucket is publicly accessible and found with write permissions, something that Prisma Cloud didn’t alert us on when we were investigating in their Alerts tab. And even more, things like unpatched web services, like Apache, service vulnerabilities like SSH and Orca is even telling us that the service is internet-facing. We see we have unsupported host OS on both our container and the external HR web machine. We also have password and shell history on the container host, sensitive AWS keys on the external HR web machine, and insecure private key on the container. And Orca even tells us this key allows lateral movement to two other assets in my environment. Weak host password on the internal management machine, the Windows machine, the internal HR benefits machine also has an unsupported host OS, and the internal HR benefits also has an unpatched host OS. So, both unsupported and unpatched host OS in the internal HR benefits machine. And the final alert Orca is highlighting is AWS IAM Policy, root account recently used. And it’s great to see that Orca picked this up.

Now, there is one alert I haven’t seen an Orca yet that we saw in Prisma Cloud. A list of directly exposed instances. So, if we come to the top to the Assets tab and scroll to the right, and we can click the Labels drop-down and filter by internet-facing, and this is where Orca gives us a full list of all internet-facing assets. And as you can see, it displays the container host and hrweb just like Prisma Cloud, but it shows the container is internet-facing as well, something that Prisma Cloud completely missed.

So, we’ve compared alerts, and frankly, it’s pretty clear to me that the information coming from Orca is much more practical and effective. For example, most of the security group alerts from Prisma didn’t have any resources assigned to them. And so, ranking them as high-severity would take my attention away from where the real risks in this environment are. Patrick, what’s your take?

Patrick: Thank you, Alaap. And yeah, definitely, agreed around how practical those high-severity alerts are for me. I would expect to find the very biggest, most daunting security risks in that high category. And 17 to the failures were security groups that I haven’t touched, right, that have no resources assigned to them as you mentioned. But even if we look at the medium-severity alerts, you’ll find many of them have to do with IAM access, overly permissive roles, the lack of MFA on specific accounts, some more security group measurements. Although Orca doesn’t support the breadth of compliance standards that Prisma Cloud does, we do have the bulk of these measurements in the product as well. We haven’t focused on that a lot in this video, but I want to make sure that was clear.

So, to sum up, let’s again consider our lab diagram, but now let’s also layer on top of the things that Alaap and I planted in the environment. These are the same things that we would have no idea about if we had truly just inherited this environment and we’re looking at it for the first time. And in fact, it’s the things that we would really depend on the cloud security products that we pointed at our lab to find in the end. So, what did each find?

Out of the box, so to speak, Orca was able to find both the Linux and Windows-based malware, aging unsupported operating systems, passwords and shell history, insecure private keys that lead to lateral movement, and Orca even advised us about the resources in their environment that the SSH keys map to. Unpatched operating systems and software, sensitive cloud keys, and weak host passwords.

Orca is able to determine this information really in two ways, the first, the process of side scanning, where Orca analyzes the storage that powers your workloads. And the second, a healthy dose of context, a mixture of that data-driven intelligence with cloud control plane measurements, including security groups, route tables, IAM permissions, and much, much more. Although Prisma Cloud performed many measurements, most were of low value to me. They aren’t things I want to ignore, but treating them as a priority and addressing them instead of the Orca findings would do little to mitigate the risk of compromise of my newly discovered cloud environment. Although Prisma Cloud did detect my publicly readable S3 bucket, it did not detect it as publicly writable.

We didn’t have time to cover the Orca fundamentals in this competitive comparison, so please reference the description of this video for links to find more about Orca Security. Thank you for watching.