AWS security assessment
The deepest surface we test. IAM is where AWS environments quietly go wrong, and it is almost never a single bad policy. It is a chain.
The context
What actually breaks on AWS
AWS is where we spend the most assessment time, and not because it is less secure than the alternatives. It has the largest surface, the most granular permission model, and the most ways for a reasonable-looking configuration to chain into something that is not.
The permission model is the whole story. An IAM policy that looks fine on its own becomes a problem when combined with a trust relationship you set up eighteen months ago, a role that CodeBuild assumes, and an S3 bucket policy that grants access to a principal rather than a path. None of those four things is a finding. Together they are.
This is why a posture score misses it. A scanner evaluates each resource against a rule. What matters is whether a path exists from something an attacker can reach to something you cannot afford to lose, and answering that requires walking the graph.
Assessed surfaces
Everything we look at on AWS.
- 01IAM roles, policies, trust relationships & privilege escalation paths
- 02S3 bucket policies, ACLs, Block Public Access & pre-signed URL handling
- 03VPC design, security groups, NACLs & internet-facing exposure
- 04KMS key policies, Secrets Manager, SSM Parameter Store
- 05CloudTrail coverage, GuardDuty, log integrity & retention
- 06EKS RBAC, ECS task roles, Lambda execution permissions
- 07CodeBuild / CodePipeline permissions & OIDC trust from CI
Questions
AWS FAQ
A role we can assume with the AWS-managed SecurityAudit and ViewOnlyAccess policies attached, scoped to the accounts in scope. Read-only. We make no changes. If your policy prohibits third-party roles, we provide the collection scripts and one of your engineers runs them, which works almost as well and takes a little longer.
Yes, and the boundaries between them are usually the interesting part. Cross-account trust relationships, SCPs that do not do what people think, and a management account with more permissions than anyone remembers granting are all common. Assessing a single account in isolation misses most of what matters in a multi-account estate.
Those tell you a control is non-conforming. They do not tell you that a GitHub Actions workflow can assume a role because the OIDC trust policy uses a wildcard in the subject condition, and that the role can read the production data bucket. We do the chaining and the prioritisation, then hand you Terraform changes rather than console click-paths.
Other platforms we assess
An app registration holding a long-lived client secret with directory-wide Graph permissions.
Azure assessmentA downloadable service account key with project Editor, committed to a repo two years ago.
Google Cloud assessmentA read-write API token in a build environment variable, with no expiry and no rotation record.
DigitalOcean assessmentFind out what is reachable in your AWS estate.
Read-only access, one to two weeks, fixed price. You get attack paths with proof, not a posture score.
No sales sequence. A scoping call and a written proposal cost nothing.