The biggest attack surface today is your cloud.
A review of configuration, identity and segmentation across AWS, Azure and GCP. Most cloud incidents do not start with a provider failure: they start with a permission that is too broad, a resource exposed unintentionally, or a forgotten secret.
In the cloud, the mistake is rarely the provider's
The shared responsibility model splits the work: the provider secures the infrastructure, and the configuration is yours. Incidents happen on your half — a bucket opened for the convenience of a test, a role granted administrative permission in a hurry, a network left unsegmented because a deadline was slipping. None of it shows up as a vulnerability in a scan; it shows up as a configuration decision nobody revisited.
- Permission granted as a temporary measure is almost never revoked afterwards.
- A resource created outside the standard process does not inherit the protections that process applies.
- Secrets in environment variables and repositories remain the shortest path in.
- Without segmentation, a single foothold reaches accounts and environments that should be separated.
What's included
The scope below is the default for a typical engagement. Everything is adjustable during scoping, at no cost.
- Broad policies and wildcards in actions and resources
- Assumable roles and privilege escalation chains
- Long-lived access keys and rotation
- Federation, identity provider and sessions
- Service accounts and workload permissions
- Separation between administration and operation
- Public exposure of objects and containers
- Encryption at rest and key management
- Access policy and cross-account sharing
- Versioning, retention and deletion protection
- Backups and restore testing
- Sensitive data outside its intended store
- Ingress rules open to the whole internet
- Segmentation between environments and accounts
- Load balancers, gateways and traffic termination
- Management services reachable from outside
- Private connectivity and network peering
- Container and orchestration surface
- Audit trail enabled across every region
- Retention and protection of the logs themselves
- Control-plane event coverage
- Alerting on sensitive permission changes
- Centralisation into a separate account
- Integration with existing monitoring
- IAM, roles, policies and identity federation
- VPC, security groups, NACLs, peering and public exposure
- S3, RDS, DynamoDB, Blob Storage and Cloud Storage
- EC2, Lambda, ECS, EKS, AKS and GKE
- CloudTrail, AWS Config, Microsoft Sentinel and Security Command Center
- Identity providers and federated SSO
Modalities
adjustable to scopeConfiguration review
A systematic read of the environment from an audit role: identity, network, storage, logging and data protection, compared against the provider's own documentation and public benchmarks.
Path testing
Instead of listing configuration, we start from a plausible position — an application credential, a compromised container, an ordinary user — and establish how far it reaches inside the environment.
Continuous and infrastructure-as-code review
Analysis of the templates and modules that build the environment, plus a recurring verification cycle. Fixing at the source stops the same deviation from returning with every new account, project or deployment.
When to review a cloud environment
Cloud configuration changes daily, through many hands. Some moments concentrate risk more than others.
An environment moved in a hurry usually carries broad permissions granted to unblock the cutover, with a promise to tighten them later — and later rarely arrives.
Every team created one, every project opened another. Without a central standard the protections diverge and nobody has a view of the whole.
Anomalous cost is sometimes waste and sometimes a resource created by someone who should not have had permission to create it. It is worth knowing which.
Evidence of cloud controls is now a standard item in most questionnaires. Better to find the gap before the assessor does.
How we conduct it
[pipeline]Environment discovery
We start with what exists: accounts, subscriptions, projects, active regions and resources in use. A cloud estate is almost always larger than the documentation suggests, and the resource missing from the inventory is usually the unprotected one.
Identity and permission analysis
We map who can do what, including what is possible through inheritance and role assumption. The written policy is not the point — effective permission is, and it tends to be far broader than whoever granted it imagines.
Configuration review
Storage, network, encryption, logging, backup and managed services are compared against provider documentation and public secure-configuration benchmarks, noting each deviation and why it matters in this particular environment.
Reach verification
We simulate realistic starting positions and measure the reach of each: what an application credential can read, what a compromised container touches, whether it is possible to cross from one environment into another. That is what separates a list of deviations from demonstrated risk.
Logging and alerting assessment
We check whether the actions we executed left a trail, whether that trail is protected against deletion, and whether sensitive permission changes raise an alert. An environment without a reliable trail cannot be investigated after an incident.
Report and remediation plan
Deviations are grouped by cause rather than by resource: ten items stemming from one policy are one fix, not ten. Each group gets applicable guidance and a suggestion for preventing recurrence at the source.
Public references behind the work
The review rests on the providers' own documentation and on open configuration benchmarks, which makes every point independently verifiable.
- CIS Benchmarks
- The configuration baselines for AWS, Azure and GCP give an objective, item-by-item reference to compare the state of the environment against.
- Well-Architected (security pillar)
- Each provider's architecture guidance states their own recommended practice, which removes any argument about where a recommendation came from.
- Shared responsibility model
- It defines precisely where the provider's responsibility ends and yours begins — the exact boundary where most incidents occur.
- MITRE ATT&CK for Cloud
- The cloud-specific matrix names techniques for identity abuse, persistence and collection, and serves to assess detection coverage.
- NIST SP 800-53
- The control catalogue is the bridge between a technical finding and the language governance and audit already speak.
- Least privilege
- Not a standard but the criterion guiding permission analysis: every identity should reach only what it needs, and each departure requires an explicit justification.
- Azure Security Benchmark
- Microsoft's own baseline for Azure, used when the estate is predominantly Azure and the audit expects that reference.
- CSA Cloud Controls Matrix
- The Cloud Security Alliance matrix maps cloud security domains and cross-references other standards, which helps when a customer questionnaire runs long.
- ISO/IEC 27017 and 27018
- The standards specific to cloud security and to personal data in the cloud, frequently cited in enterprise contracts.
- Mapping to GDPR and PCI-DSS
- Where the environment handles personal or cardholder data, each finding is also referenced to the corresponding requirement, so it serves directly as evidence.
Deliverables
dual view · NDAInventory of what exists
The real list of accounts, projects, regions and active resources. For many teams this is the first useful deliverable, because it surfaces environments nobody remembered owning.
Effective permission map
Who reaches what in practice, including indirect paths through inheritance and role assumption. This is usually more surprising than the configuration list.
Deviations grouped by cause
Findings organised by common origin, each with its public reference. Fixing the cause closes several items at once and prevents recurrence.
Demonstrated paths
For the most relevant risks, the concrete route: where it starts, what it reaches and why that matters. It turns a configuration deviation into risk a non-specialist can weigh.
Trail and detection assessment
What was recorded of the actions we executed, what was switched off, and which sensitive changes would go unnoticed today.
Prioritised remediation plan
A work order weighing risk and effort, separating what can be fixed in configuration from what must change in infrastructure as code so it does not return.
Frequently asked
No. The review runs from a read-only audit role, which all three providers offer natively. For reach verification we agree specific, limited credentials separately, with scope and duration defined in writing.
It complements them rather than replacing them. Posture tooling covers volume and tracks drift continuously, which is valuable. What it does not do is chain permissions to show that an application credential reaches data that should be isolated — and that demonstration is what changes priorities.
Yes. Mixed estates are the common case, and comparing providers usually exposes uneven protection: the same type of resource locked down in one and exposed in another, because different teams built them.
Orchestration is in scope: roles and bindings, container security contexts, network policy between services, control-plane exposure, secret management, and the link between cluster identity and cloud identity — a frequent escalation path.
The environment serving production, at minimum. Development and staging accounts are worth including when they have a network or identity path into production, which is more common than assumed — and precisely where protection tends to be loosest.
By fixing them at the source. Where the environment is built from infrastructure as code, the fix goes into the module and applies to every future deployment. For each group of deviations the report states whether it should be treated on the resource or in the template that creates it.
Yes. Each point carries its public reference and the evidence of the configuration observed, in a form an auditor can verify independently without redoing the analysis.
Ready to uncover your flaws?
First scoping call is free and covered by NDA. Within 48 hours you receive technical proposal, scope and timeline. No bureaucratic forms.