Identity and access
Where almost every path in an AWS account runs.
- Users, roles, policies and key age
- Privilege escalation paths through PassRole and policy edits
- Cross-account trust relationships
- Root account use, MFA and access keys
Almost nothing that goes wrong in an AWS account is exotic. It is an access key three years old, a role somebody widened to unblock a deployment, a bucket opened for a demo, or an instance profile a compromised container can read. We go across the whole account against the CIS Amazon Web Services Foundations Benchmark, and then we try to use what we found.
A benchmark tool will tell you that a policy is over-permissive. It will not tell you that this particular role can be assumed by a build job, that the build job reads a secret, and that the secret opens the production account. The finding is the path, not the setting.
So the review runs in two passes. First the whole estate measured against the CIS benchmark, which gives you a score, a list and something to show an auditor. Then the paths: what can actually be reached from each identity that exists, which is the part that changes what you fix first.
Structured on the CIS AWS Foundations Benchmark, with the identity work taken considerably further than the benchmark asks.
Where almost every path in an AWS account runs.
What can be read by somebody who should not.
Whether the account is as separated as the diagram says.
What an attacker lands in, and what it can reach.
Whether you would know afterwards.
The part that stops the next mistake rather than this one.
An audit role is all we need to start, and it is the only access most of the work requires.
Everything that exists and everyone who can touch it.
Against the benchmark, so there is a number.
The part that is not in any benchmark.
Fixes ordered by how many paths they close, and a free retest.
Two documents and a conversation. Written so the person who signs the invoice and the person who writes the fix can both use them.
The work follows CIS AWS Foundations Benchmark, AWS Well-Architected Security Pillar, MITRE ATT&CK for Cloud and NIST SP 800-115, so the coverage can be checked rather than taken on trust, and the report maps to what your auditor or your enterprise customer already recognises.
This page is one part of our cloud security service. Where a finding needs a different kind of engagement to answer properly, we say so in the report rather than selling you the test we happen to be running.
A read-only audit role to begin with - SecurityAudit or equivalent. For the attack-path work we also ask for a deliberately low-privileged identity to start from, because that is what an attacker would have.
For ordinary assessment and penetration testing of your own resources, AWS permits it under its published customer support policy for penetration testing without prior approval, with specific exclusions - denial of service being the main one. We check the current policy during scoping and keep the work inside it.
No. This is a review of the whole account against a benchmark, which is where most organizations should start. Cloud penetration testing starts from one foothold and shows what can be reached with it. If you have never had either, have this one first.
It gives you most of what they will ask for on the infrastructure side: a measured benchmark result, evidence of remediation, and a dated independent review. It is not a penetration test, and SOC 2 auditors generally expect one of those too - see our SOC 2 page.
As one estate. Cross-account trust is where the most serious findings usually are, so reviewing a single account in isolation tends to miss the thing that matters most.
Tell us what you need tested. Our team will reply with a clear scope and quote.
An assistant, not a person, so check anything important with us. Please do not type passwords or card numbers here. Messages are kept so we can answer you better.