AWS security assessments
When everything is a priority, nothing is.
I review your AWS accounts for misconfigurations and vulnerabilities, then rank what I find by whether it leads to the systems and data that matter most, so you know what to fix first.
How it works
Your environment, mapped as a graph.
Every account in scope is loaded into a graph database: each resource and how it connects to the others, from internet gateways and security groups to instances, IAM roles, and the data stores those roles can reach. The analysis runs on that graph.
- Attack paths
- Routes through the graph from the internet to your critical assets, for example an open security group, the instance behind it, and a role that can read your customer data. Misconfigurations alone can form a path; no vulnerability is needed.
- Vulnerability chains
- If you run Amazon Inspector, each instance's vulnerabilities are analyzed together for chains: an entry point plus a privilege escalation. Two mediums that chain into a compromise are ranked by what they add up to. Each CVE is checked against CISA's Known Exploited Vulnerabilities catalog and scored with EPSS.
- Critical assets
- AI flags which data stores look sensitive from their names, tags, and settings, not their contents. We confirm the list on a 30-minute call.
- Checks from real breaches
- I wrote checks Security Hub doesn't have, after studying the root causes of major breaches. In the 2019 Capital One breach, an instance role's stolen credentials were used from outside the company's network; one check flags S3 buckets that accept a role's credentials from anywhere. Others catch containers that can reach their host's role credentials, and roles anyone can assume.
The AI steps run on Amazon Bedrock, which doesn't train models on your data.
How findings are prioritized
The vendor rates severity. I set priority.
Every finding keeps the vendor's severity rating, visible and unchanged. Next to it is my priority, which depends on your environment: which systems and data stores are your critical assets, and whether the finding sits on an attack path to one of them.
A critical finding with no path to anything important ranks below a medium one on the path to your customer data.
One fix can break several paths at once, so the report leads with the fixes that break the most.
What gets reviewed
Area by area, in the accounts and regions we agree on.
The review covers the AWS accounts and regions we agree on at scoping. Within them, I look at:
- Identity and access
- IAM roles and policies, users and access keys, and the root account.
- Network
- VPCs, security groups, and what is reachable from the internet.
- Encryption
- Data at rest and in transit, and how the keys are managed.
- Compute
- EC2, Lambda, and containers.
- Storage
- S3 and EBS.
- Logging and detection
- CloudTrail, AWS Config, and GuardDuty.
- Edge protection
- WAF and Shield.
- Vulnerabilities
- Amazon Inspector findings, if you run Inspector. It is not a prerequisite.
I measure your configuration against the CIS AWS Foundations Benchmark, the Security Pillar of the AWS Well-Architected Framework, and NIST SP 800-53 Rev. 5, and each finding carries its references to them.
How it runs
From scoping to readout.
- 01
Scoping
We agree on which AWS accounts and regions are in scope.
- 02
Access
You deploy a CloudFormation template that creates a cross-account role with AWS's SecurityAudit managed policy. I collect the configuration and build the graph.
- 03
Critical assets
A 30-minute call to confirm which systems and data stores are your critical assets.
- 04
Report and readout
I write the report and walk you through it. If a penetration test makes sense, the readout is where it gets scoped.
- Timeline
- Two weeks
- You get
- An executive summary
- The scope, including anything not assessed
- A fix-first list: the changes that break the most attack paths
- The attack paths to your critical assets, step by step
- Findings with the vendor's severity and my priority side by side
- Benchmark results
- A prioritized remediation roadmap
- A live readout
The business case
Scanners hand engineering teams long lists sorted by vendor severity. Ranking findings by what reaches your critical assets puts engineering time on the fixes that matter first.
The compliance case
Supporting evidence for:
- SOC 2 CC3.2, CC4.1, CC7.1
- HIPAA §164.308(a)(1)(ii)(A), §164.308(a)(8)
- ISO 27001 A.8.8, A.8.9
- NIST CSF ID.RA-01, ID.RA-05
- NIST 800-53 CA-2, RA-3, RA-5
Measured against: the CIS AWS Foundations Benchmark, the Security Pillar of the AWS Well-Architected Framework, and NIST SP 800-53 Rev. 5.
For where you stand against a whole framework, see Internal Compliance Assessment.
References are to the 2017 Trust Services Criteria for SOC 2, the HIPAA Security Rule at 45 CFR Part 164, ISO/IEC 27001:2022 Annex A, NIST CSF 2.0, and NIST SP 800-53 Rev. 5.
Pricing
A fixed fee, quoted after a 30-minute scoping call.
What moves the price:
- How many AWS accounts and regions are in scope
- How large the environment is
You can also buy it through AWS Marketplace and pay on your AWS bill.
Azure and GCP reviews are scoped by hand.
Start with a conversation.
The right engagement depends on what you’re building and where the gaps are. A 30-minute call gets us to whether and how I can help.