Scope and read
We agree the accounts in scope and the questions worth answering, then read the configuration as it actually is rather than as the diagram says.
Practice 01 — Cloud Security
Your cloud was configured once. Mostly by someone who left.
Most cloud incidents are a configuration decision made months earlier by someone solving a different problem. We make those decisions with you, write them down, and then try to get past them.
What sets the estimate
- Providers
- Accounts and environments
- Services in use
- Identity model
- IaC coverage
Scoped on the call, quoted in days, in writing.
Scope a cloud security review
A short call to understand what you run and what you need to be sure of, and to explain how we would approach it.
Times in
Loading available times…
Why teams call
You already suspect at least one of these.
- Nobody can say what a single compromised CI role could reach.
- Permissions were granted to unblock a deploy and never revoked.
- Logging is on, but nobody has tried to answer a real question with it.
- A second product line is sharing an account with the first.
- Long-lived access keys exist in your pipeline because OIDC looked like a project.
What you get
The deliverables.
Configure
- Account structure and multi-tenant isolation, built to the Well-Architected security pillar
- IAM roles, permission boundaries and least privilege that survives contact with engineers
- S3, EC2 and data-layer hardening — encryption, exposure, lifecycle
- Logging, detection and retention you can hand to a customer or an auditor
- OIDC federation for deployment pipelines, so no long-lived cloud keys exist to steal
Attack
- Pacu-driven sweep for exploitable misconfiguration, not a scanner report
- IAM privilege-escalation path mapping — from read-only to administrator, step by step
- Data and service exploitation, demonstrated rather than asserted
- Blast radius: what one compromised role, runner or laptop actually reaches
How it runs
Test and prove
Findings come with the reproduction steps that produced them. An escalation path is shown as a sequence of calls, not a severity rating.
Sequence the fixes
A findings register with named owners and a 90-day order of work, arranged so the changes that shrink blast radius land first.
QuestionsBefore you
Before you
book the call.
Do you need production access?
Read-only access to the accounts in scope, through a role you create and can revoke. Offensive testing runs against what you authorise in writing, and we do not hold credentials after an engagement closes.
Is this a scanner report?
No. Scanners are a starting point and we use them, but the deliverable is the paths we could actually walk — which role reached which data, and the calls that got us there.
We are not on AWS. Does this still apply?
The method does; the benchmarks differ. CIS publishes equivalents for Azure and GCP, and most of the work — identity, isolation, logging, blast radius — is the same shape. Tell us what you run and we will say honestly how much carries over.
Will you make the changes for us?
No. Your engineers make the changes; we design them, document them and verify them afterwards. We do not operate client production systems.
Next step
Scope a cloud security review.
Thirty minutes, no obligation. We will tell you what is worth doing, including when the answer is less than you expected.