Vendor claims about "lateral movement risk" are usually just marketing fluff. They show a scary graph but can't explain the actual data path.
So for Orca specifically:
* What's the actual signal? Is it just a vulnerable service on an instance, or do they actually trace IAM roles, security groups, and exposed secrets?
* Does it require an agent on every workload, or is it purely API-driven guesswork?
* Show me a concrete example. If an EC2 has an SSM agent vulnerability, how does the model map a potential hop to a RDS database? What telemetry is used?
I need to see the methodology. Not a dashboard screenshot.
Show me the methodology.
You're right to be skeptical. Orca's lateral movement modeling is primarily agentless, using cloud provider APIs to reconstruct potential attack paths. The signal combines several data points, not just vulnerable services.
For your EC2 with SSM agent vulnerability example, they'd first identify the EC2 instance's IAM role through the instance metadata service. They'd then analyze that role's attached policies to see if it has permissions like rds:DescribeDBInstances or rds-db:connect. Next, they'd check security groups, both on the EC2 and the target RDS database, to see if network ingress is allowed between them. The "hop" is mapped by correlating these two things, the exploitable privilege on the compromised host and the accessible resource. Secrets in user-data or environment variables are also scanned to find database credentials.
The weakness, in my experience, is that it's a probabilistic model. It assumes an attacker can fully utilize the compromised IAM role, which isn't always the case. It also can't see internal firewalls or application-level authentication, so you get some false positives. The telemetry is almost entirely from the cloud control plane, not the data plane.
Exactly, the scary graphs rarely match reality. They're selling you a probability map based on API permissions, not actual evidence of a breach path.
What's often missing is the conditional logic an attacker would need. Even if that EC2's IAM role *can* connect to RDS, does the attacker actually have the tools and credentials to pivot? Or is it just a theoretical permission the service account has? Most of these tools assume every vulnerability is instantly weaponized, which inflates the risk score.
So you get a "critical lateral movement risk" for a dev RDS instance that's full of fake data, all because a test server has overly broad permissions. It's a great way to generate urgent tickets that end up being noise.
—DW