In the cloud the perimeter is a policy document. A role that can pass another role, a storage bucket readable by any authenticated user, a metadata service reachable from a web application: each looks harmless alone, and together they are a path from the internet to the data.
We review the configuration with read-only access and then test what it means in practice: starting from the position of an outsider, of a compromised workload and of a developer account, we follow the permissions to see how far each of them gets.
01Scope
What we test
Identity and access management: users, roles, policies, federation, service accounts
Privilege escalation paths and cross-account trust
Network: security groups, public endpoints, peering, private links
Storage and databases: public access, encryption, backups, snapshots
The large providers publish policies that permit testing of your own resources without prior approval, with a list of prohibited actions such as denial of service. We check the current policy of your provider before testing and stay inside it.
Is read-only access enough?
For the configuration review, yes. To validate attack paths we need the low-privilege identities the paths start from; they are created for the test and removed after it.
We use a cloud security posture tool. What is left to find?
Posture tools list misconfigurations one by one. They rarely show which three of them combine into a path to the data, or which of two hundred warnings actually matters. That is the purpose of this assessment.