The findings that matter in a cloud environment are rarely the ones a scanner ranks highest. A pipeline that was granted a role so a deployment could complete, a storage account that was only ever reachable from a subnet that has since been peered, and a service principal with a standing assignment that nobody has reviewed since it was created, are all low severity when they are looked at individually. Combined, they are often the shortest path an attacker has into your data.
This is the main limitation of assessing a cloud environment one control at a time, so most of the assessment goes on how things relate to each other.
The assessment covers the accounts, subscriptions and projects within an agreed boundary, including the ones that are not in anybody's inventory. Finding those is part of the work. Within that boundary we look at:
- Identity and access, which is where most of the risk sits. Federation and identity provider configuration, standing privileges, break-glass accounts, guest and external identities, service principals, workload identities, CI/CD identities, and trust relationships between accounts
- Network exposure and the trust boundaries between environments, including what is reachable from the internet and what is reachable from a test environment
- Where data is stored, how it is encrypted, who holds the keys, and the paths by which it can legitimately leave the environment
- Logging and detection coverage, meaning whether an attack against this environment would produce a trace that anyone would act on
- The landing zone and control plane, e.g. guardrails, policy assignments and organizational structure, and whether the boundaries that were intended are the boundaries that exist
- Infrastructure as code and the pipelines that have access into the platform
- Third party and SaaS integrations that hold roles in the environment
How we work
We ask for time limited read-only access, typically Reader and Security Reader in Azure, a read-only audit role in AWS, and Viewer and Security Reviewer in Google Cloud, together with read access to the infrastructure as code and pipeline configuration. Nothing is deployed into the environment and nothing is written to it.
Our own tooling enumerates the resource graph and the identity graph through the provider APIs and exports it once. The analysis then happens in our own environment, under a retention and deletion schedule that we agree with you before we start.
We then run two or three working sessions with the people who operate the platform, covering how the landing zone is intended to work, where the trust boundaries are supposed to be, which systems actually matter to the business, and what the team already knows is broken. This context is what lets us cut the finding list down to the ones worth acting on.
What you get
- A findings report, where each finding has detailed evidence and the path it belongs to, with a diagram where the path is complex enough to need one
- A remediation plan in three bands: what can be changed this week, what belongs in this quarter, and what is architectural and needs a decision
- Guardrail recommendations written as policy that your team can apply directly
- The findings in a machine readable format, so that they can go straight into your backlog
- A technical walkthrough and a separate session for the business
- Optionally a re-check after 60 to 90 days using the same method, so that the change can be measured
We work across Microsoft Azure, Amazon Web Services, Google Cloud Platform, OCI and Kubernetes.
To read more about our methodology and a customer testimonial: Uncovering Cloud Risks