Cloud Security Validation
You are moving to AWS or Azure, or you are already there and nobody has ever tested it. Identity, data, network and pipeline layers assessed for what an attacker can actually chain together, not for deviation from a baseline.
Findings are cheap, paths are not
Cloud misconfiguration is not a discovery problem. Any posture tool will hand you several thousand deviations from a baseline within an hour of being pointed at the estate. The problem is that almost none of them matter, a handful of them matter enormously, and nothing in the output distinguishes between the two.
What matters is composition. An over-permissive role is uninteresting until a workload that can assume it is reachable from the internet, and its credentials are recoverable through a metadata service that was never restricted. Three findings that a tool ranks as medium form one path that ends in your customer data. Establishing which chains exist requires walking them.
Engagement types this combines
A solution is not a separate capability. It is the engagement types from Services sequenced against a specific situation: here, a move to AWS or Azure.
Penetration Testing
Hands-on testing of the deployed environment: identity escalation paths, reachable secrets, exposed services, and whether a foothold in one account reaches another.
View engagementSecurity Consulting
Cloud security architecture review. Assesses the design, and produces the target state the remediation plan aims at.
View engagementWhat gets assessed
AWS and Azure. Each item below is assessed for reachability, not presence.
Identity and access
- Role and policy escalation paths, including chained escalations
- Service and machine identities with excessive permission
- Cross-account and cross-subscription trust relationships
- Wildcard principals and unconstrained resource policies
- MFA and conditional access enforcement on privileged identities
- Unused roles retaining dangerous permissions
Data exposure
- Publicly reachable object storage and blob containers
- Unencrypted volumes, databases, and snapshots
- Backups and snapshots shared beyond the account boundary
- Credentials and keys in plaintext configuration
- Egress paths that permit bulk extraction
- Sensitive values written into logs
Network boundaries
- Security groups and NSGs permitting unrestricted ingress
- Management ports reachable from the internet
- Absent segmentation between environments
- Flow logging disabled or unretained
- Peering and transit configurations that collapse boundaries
- Exposed orchestration and cluster API endpoints
Compute and workloads
- Containers running privileged or as root
- Instance metadata service reachable from application code
- Serverless functions holding permissions beyond their function
- Images built from outdated or unpatched bases
- Keys and secrets baked into images
- Absent isolation between workloads of differing trust
Delivery pipeline
- Pipelines holding production credentials
- Secrets in registries, repositories, and build logs
- Unauthenticated or weakly authenticated admin interfaces
- Deployment paths that bypass review
- Artefact integrity and provenance
- Third-party actions and plugins with repository access
Logging and detection
- Audit logging disabled, partial, or unretained
- Log retention shorter than the investigation window requires
- No alerting on privileged or policy-changing actions
- Logs writable by the identities they record
- Failed authentication not captured
- Coverage gaps across accounts and regions
How the engagement runs
Step 04 applies only where a migration is in progress. Everything else runs regardless of migration state.
01
Architecture review
3-5 days
The estate assessed as a design: identity model, trust boundaries, data flows, and where the blast radius of a single compromised workload actually ends. Done from documentation, infrastructure-as-code, and read-only access.
Output: Annotated architecture with trust boundaries, identity model analysis, and the target-state design.
02
Configuration analysis
2-4 days
Systematic review of identity policy, storage, network, encryption, and logging configuration across accounts and regions. Deviations are recorded, but the output is the subset that composes into something reachable.
Output: Configuration findings filtered to what is exploitable in your specific topology.
03
Exploitation
5-10 days
The paths identified are walked. Escalation from a low-privilege identity, movement between accounts, secrets recovered from compute, and reachability of data stores. This is what separates a real finding from a posture-tool alert.
Output: Demonstrated attack paths with the commands and API calls that produce them.
04
Migration validation
Per phase, if migrating
Where a migration is in progress, each phase is validated as workloads land: whether the intended controls came with them, whether the interim state opened anything, and whether the old environment is fully decommissioned.
Output: Per-phase validation with go or no-go against defined security acceptance criteria.
05
Reporting and remediation plan
2-3 days
Findings ordered by the paths they enable, not by individual severity, with remediation given as infrastructure-as-code where it can be. Delivered live to the engineers who will apply it.
Output: Engagement report, ordered remediation plan with effort estimates, IaC remediation, debrief.
06
Remediation retest
Within 30 days of fix
Critical and High findings retested once changes are deployed, including whether the fix can be bypassed and whether it introduced a new path.
Output: Retest report with per-finding status and residual risk.
What you receive
Organised around the paths found, so remediation can be ordered by which path it closes.
Architecture assessment
- Annotated architecture with trust boundaries marked
- Identity model and escalation path analysis
- Segmentation and blast radius per environment
- Data flow and encryption coverage
- Target-state design the remediation plan aims at
Attack path report
- Each demonstrated path, from entry to impact
- The API calls and commands that walk it
- Which single change breaks each path
- Configuration findings that are noise, marked as such
Remediation plan
- Ordered by path closed, not by individual severity
- Infrastructure-as-code changes where expressible
- Effort estimate alongside each item
- Changes that are safe now versus those needing a window
Migration security criteria
- Pre-migration prerequisites
- Per-phase validation steps
- Security acceptance criteria for sign-off
- Decommissioning checklist for the source environment
What we need to quote
Account structure is the input that most changes scope. An estate of forty accounts is a different engagement from one of two.
- →Provider and account structure: how many accounts or subscriptions, and how they are organised.
- →Rough scale: workload count, regions in use, and which accounts hold production data.
- →Whether infrastructure is managed as code, and if so in what.
- →Migration state: planning, in progress, or complete and never reviewed.
- →Read-only access you can grant, and through what mechanism.
- →Existing posture tooling and what it currently reports.
- →Compliance scope, if a framework applies to the environment.
- →Change freezes and any workload that must not be touched.
Common questions
Which cloud platforms do you assess?+
AWS and Azure. GCP is assessed case by case. Multi-cloud environments are assessed as one estate, because the interesting paths are usually the ones that cross between providers.
Can you test during an active migration?+
Yes, and it is the better time. Assessment is structured around your migration phases: architecture review before workloads move, configuration validation as they land, and penetration testing against the migrated state.
How do you handle production environments?+
Read-only access wherever it is sufficient, which for configuration and identity analysis is most of the work. Anything active is coordinated to a window, has a defined stop condition, and is never destructive.
How is this different from a cloud security posture management tool?+
A posture tool tells you a configuration deviates from a baseline. This tells you which deviations compose into a path an attacker can walk, and which are noise in your context. The output is a small number of chains, not a large number of tickets.
What do we get that our DevOps team can act on directly?+
Remediation is given as infrastructure-as-code where the fix is expressible that way: the policy document, the module change, the parameter. Not a reference to a provider best-practice page.
What happens after the assessment?+
An ordered remediation plan with effort estimates. Critical and High findings are retested within 30 days of the fix being deployed, including attempts to bypass the fix.
How to start
Send the provider, the account structure, and where you are in the migration. If your estate is small enough that a standard penetration test covers it, the first call will say so.
Direct: hello@principlebreach.com