Testing cloud environments
AWS, Azure, Google Cloud, Kubernetes and the templates they come from. The most common finding is a role that may do more than anyone thought.
Configuration rather than software
In the cloud the findings rarely sit in a vulnerable version. They sit in a permission drawn too widely, in a storage bucket without access control, in a rule that allows connections from anywhere.
So we test with valid credentials and from several vantage points: from outside, as a logged-in user, and as a compromised service. Only the third shows how far an attacker gets after the first step.
A role that reaches across tenants
Three tenants, cleanly separated, each with its own data. Between them a role created for the automation whose permissions were never narrowed. Whoever takes it over reaches the storage of all three.
Roles like that come about during the build, when something has to work and the restriction is to follow later. They do not stand out in operation, because nothing breaks, and they appear in no vulnerability scanner.
So we test permissions along the question of what would be reachable with a taken identity, and not along the question of what the policy says.
Accounts, services, containers
The emphasis depends on what you run. For an application in containers it sits differently than for a landing zone with many accounts.
Accounts and permissions
IAM in AWS, Entra ID and roles in Azure, service accounts in Google Cloud. Who may do what, who may grant rights, and which identity is valid in more than one place.
Services and data
Storage and its sharing, databases and their encryption, network rules, functions and interfaces, key management. Plus the logging: what would an attack leave behind.
Containers and templates
Kubernetes with its permissions, network rules and node hardening, plus the templates from Terraform or Bicep. A mistake in a template spreads to every environment built from it.
How a cloud test runs
A single application in one account is around five days; a landing zone with several accounts and environments is considerably more.
Scope and credentials
Which accounts, which subscriptions, which projects. We need credentials for the vantage points to be tested: a logged-in user and, where possible, an identity a compromised service would have.
Take inventory
Accounts, roles, policies, storage, network rules, and the templates they came from. Plus the logging: what would an attack leave behind.
Follow the paths
What is reachable with a taken identity, and where that stops. That question decides whether an incident affects one application or the whole environment.
Report and retest
Every finding with the call that shows it, and a route to a fix that suits your environment. On request the check afterwards.
Common questions about cloud testing
Testing your cloud environment for permissions, configuration and data access, with valid credentials and from several vantage points: from outside, as a logged-in user, and as a compromised service.
The third vantage point is the important one. It answers how far someone gets after the first step, and that is exactly where it is decided whether an incident affects one application or the whole environment.
In the cloud the findings rarely sit in a vulnerable version. They sit in a role with permissions drawn too widely, a storage bucket without access control, a network rule that allows connections from anywhere.
So we test permissions along the question of what would be reachable with a taken identity, and not along what the policy says.
AWS, Microsoft Azure and Google Cloud. In AWS the emphasis is on IAM, S3, EC2 with security groups, Lambda and API Gateway, RDS and CloudTrail. In Azure on Entra ID, storage accounts, virtual machines with network security groups, Functions, SQL and Cosmos DB, and Key Vault. In Google Cloud on IAM and service accounts, storage buckets and the associated services.
For the usual tests on your own resources, AWS, Azure and Google no longer require separate approval. Tests that load the platform itself, such as denial of service, remain excluded. We fix that boundary in the engagement.
The effort follows the number of accounts, services and roles. A single application in one account is around five days; a landing zone with many accounts and several environments is considerably more.
Roles with more permissions than they need, often from the build phase. Storage whose sharing reaches further than anyone thought. Network rules opened once for a test. Credentials in templates and environment variables. And logging that runs but does not record what an attack would leave behind.
Yes. Permissions in the cluster, network rules between services, node hardening, the handling of secrets, and the question of what a taken container reaches. Plus the images themselves and where they come from.
Yes, and it is worth it. A pipeline often has more permissions than any person in the company. What gets tested is access to the repository, the secrets it holds, the permissions of the runtime account, and who can trigger a change.
Plus the templates from Terraform or Bicep: a mistake there spreads to every environment built from it.
Every finding comes with a route to a fix that suits your environment, not with a link to a vendor page. We are available for questions, and the retest checks the same findings again.
Certifications and memberships.
Talk to us.
A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.