Sep 01, 2020
It can be next to impossible to separate fact from fiction when searching for cloud security solutions. IT security teams have grown weary of unsupported claims, buzzword bingo, and death-by-PowerPoint. Let’s face it, there’s no substitute for getting your hands on a product and trying it out.
So what do you do when you’ve got a revolutionary approach to public cloud security and want to tell the world about it? You let the results speak for themselves. Welcome to the Cloud Security Punch-Out! series.
These are short-form comparison videos putting Orca Security head-to-head against some of the world’s largest IT security brands. Each match starts with a quick scenario review, followed by a comparison of each cloud security solution in relation to its ease and completeness of deployment, alert findings, and results in summary.
Our series lab is representative of a real-world cloud computing environment but smaller. It’s a single AWS deployment with EC2 instances, containers, load balancers, and S3 buckets.
The single VPC has both public and private subnets and an internet gateway provisioned to permit inbound traffic.
Due to their functionality, some cloud security solutions required significant changes to our lab environment just to get them deployed and operational.
We then planted common risks and misconfigurations.
Transparency is essential; we aimed to be as objective as possible. It’s why we were meticulous about documenting versions and dates of comparison. Our goal was to be clear, direct, and not to obfuscate any of the findings. In fact, in some cases, we found that competitors had features that are better than ours.
Did we miss something significant in terms of capability? Do you have ideas for comparisons, feature deep(er) dives, or anything else related to the series? We’d love to get your perspective! Email us at email@example.com.
After watching these videos you might be asking yourself ‘how it’s possible for a startup like Orca to wipe the floor with such large cloud security solution vendors?!’
The short answer is that cloud workloads are vastly different than ’90s-style physical servers running on bare metal. Unfortunately, many organizations ended up having the same agents and scanners from their on-prem days for their cloud environments. The tools weren’t reimagined for the cloud. For the longer answer, read on…
Before the cloud, we secured physical hosts. That meant spending time installing multiple security agents—one for each server. But at least we were living in a fairly static world. IP addresses were assigned to physical assets and they seldom changed. Even then, as every security veteran knows, agent integration was tedious and coverage rarely reached 100% of assets. Then the cloud started making virtual what used to be physical. So we used what we had. We took security agents that ran on physical hosts and ran them on virtual machines.
In a cloud environment, you’re scaling utilization up and down frequently—possibly thousands of times per hour across multiple clouds—and all within a CI/CD pipeline that builds your infrastructure. You have containers and VMs to deal with, and agents carry huge operational costs.
Orca Security takes a radical new approach. With no legacy on-prem environments to protect, Orca was free to create a cloud-native security platform without the constraints of security agents and network scanners.
Orca delivers instant-on, work-load level visibility for 100% of AWS, Azure, and GCP assets without running a single opcode in the customer environment, helping organizations to:
The engine that makes all this possible is called SideScanning™.
Relying on agents for security visibility in the cloud is fundamentally flawed. Visibility is critically limited to only those assets that are already known and accessible. What’s more, the assets must be capable of having an agent installed and maintained, and the assets must have ongoing network connectivity to the backend. Yet in the fast-paced world of DevOps, developers don’t want to be bothered with deploying agents on VMs, in containers, and in serverless configurations—let alone dealing with their never-ending maintenance. Some agent-based cloud security solutions are packaged as Cloud Workload Protection Platforms.
An authenticated scan allows for direct host access using remote protocols such as SSH or RDP. The scanner uses a privileged account to log in and determine how secure each host is from an inside vantage point. While authenticated scans can successfully discover potential vulnerabilities, they’re limited as they require a privileged account on each scanned host. Furthermore, scans use significant system resources during the test procedures and require opening ports that by themselves pose a security risk.
An unauthenticated scan can only examine publicly visible information and isn’t able to provide detailed information about assets. It’s essentially acting as a friendly attacker. An unauthenticated scan can easily miss identifying some assets and vulnerabilities, making it much less effective. For example, say you have a website called mydomain.com/email_campaign that isn’t linked from your main website. The site won’t be scanned unless the scanner is manually configured, but no organization can ensure it’s set up that way. This leaves many organizations exposed to vulnerabilities in areas where the scanner cannot reach.
While unauthenticated scanners act like an attacker, they often get stuck where a real attacker would not. For example, a CAPTCHA can easily prevent any automatic mechanism (including scanners) from registering. However, these techniques won’t have any effect on a human who tries to attack the same system. Orca found a critical vulnerability in a section of a customer’s website that’s only accessible to registered users. A network scanner would get blocked here, but a real attacker could register as a user and trigger a vulnerability leading to a breach.
Orca’s earliest customer engagements revealed that the average organization lacks security visibility into at least 50% of its cloud infrastructure footprint. This is mostly due to an organization’s inability to keep up with the incredibly high TCO for agent deployment and maintenance.
Cloud security posture managers (CSPMs) are scanning tools developed specifically for the cloud. Rather than going inside the machine, a CSPM analyzes the cloud configuration itself for weaknesses. CSPMs are used to discover, assess, and solve cloud misconfigurations but provide shallow coverage where cloud security is concerned because CSPMs will never detect critical risks such as vulnerabilities, malware, and misconfigurations within the workloads themselves.
Organizations choosing to combine agent-based solutions with a CSPM end up getting flooded with separate alerts that lack context which results in alert fatigue on behalf of security analysts.
Cloud security deserves better.