Assumed Breach Assessment
Testing that starts from the inside: a compromised user or workstation, and the question of how far an attacker can get from there before anyone notices.
Service 15
Cloud security assessment
In the cloud, identity is the perimeter and a misconfigured permission is a vulnerability. We review how your environments are actually configured, then test how an attacker would chain those settings into real access.
Overview
The problem we are solving
Most cloud breaches do not involve a zero-day. They involve an over-permissioned role, a leaked access key, a storage bucket that was public for a weekend, or a trust relationship nobody remembers creating. Those issues are easy to miss in consoles and hard to see across accounts and subscriptions.
Every assessment combines two views. A configuration review benchmarks your environment against established hardening guidance. Attack-path testing then starts from realistic footholds (a leaked developer key, a compromised workload, a phished cloud user) and shows how far each one actually reaches.
Findings are ranked by what they enable, not by how many benchmark checks failed, so your team spends its time on the handful of paths that lead to real compromise.
Coverage
What we assess
Scope is agreed up front; these are the areas an engagement typically covers.
- Identity & access management
- IAM roles, policies, and service principals; privilege escalation paths; cross-account and cross-tenant trust; and stale or over-permissioned identities.
- Microsoft Entra ID & Microsoft 365
- Conditional Access gaps, app registrations and consent grants, hybrid identity sync, privileged role assignment, and paths between on-premises AD and the cloud.
- Exposed services & storage
- Publicly reachable storage, databases, functions, and management interfaces, and the data or credentials they expose.
- Compute & workloads
- Instance metadata abuse, container and Kubernetes configuration, secrets in environment variables and images, and workload identity permissions.
- Network & segmentation
- Security groups, network security groups, and firewall rules, and whether environments that should be isolated actually are.
- Logging & detection
- Whether CloudTrail, Azure activity logs, and equivalent telemetry are enabled, retained, and would show the attack paths we found.
Methodology
How the engagement runs
-
01
Scoping & access
Agree which accounts, subscriptions, or projects are in scope, and provision read-only review access plus any test identities needed for attack-path work.
-
02
Configuration review
Automated and manual review of identity, network, storage, compute, and logging configuration against CIS Benchmarks and provider guidance.
-
03
Attack-path analysis
Mapping how identities, permissions, and trust relationships connect, and identifying the paths from low-privilege footholds to high-value resources.
-
04
Targeted exploitation
Safely confirming the most significant paths from realistic starting points, so findings reflect demonstrated impact rather than theoretical risk.
-
05
Reporting
Ranked findings with evidence and remediation guidance written as concrete policy and configuration changes, not just benchmark references.
-
06
Debrief & validation handoff
A live walkthrough with your cloud and platform teams, with validation steps for every finding so your team can confirm fixes on its own.
Deliverables
What you receive
- Full technical report with ranked findings, evidence, and reproduction steps
- Attack-path narratives from realistic footholds to high-value resources
- Configuration findings mapped to CIS Benchmarks
- Remediation guidance as specific policy and configuration changes
- Validation steps for every finding, so your team can confirm and close out each fix on its own
- Live debrief with engineering and leadership
Aligned to
- CIS Benchmarks (AWS, Azure, GCP, Microsoft 365)
- AWS Well-Architected Security Pillar
- Microsoft Cloud Security Benchmark
- MITRE ATT&CK Cloud Matrix
Questions
Frequently asked
Do you need production access?
Read-only access to production is usually enough for the configuration review. Attack-path testing uses dedicated test identities with permissions agreed in advance, and anything that could change production state is discussed before it happens.
Do we need to notify our cloud provider?
AWS, Azure, and GCP no longer require advance notice for most security testing of your own resources, though each has policies on prohibited activity. We work within those policies and will flag anything that needs extra care.
We run multiple clouds. Can you cover all of them?
Yes. Multi-cloud and hybrid environments are common, and the trust relationships between them are often where the most interesting paths are. Scope is sized during scoping.
How is this different from a cloud security posture tool?
Posture tools report every misconfiguration they can detect. This assessment determines which of them actually chain into compromise, tests paths a tool cannot see, and tells you what to fix first.
Related
Often scoped together
Penetration Testing
Manual, objective-driven testing of web applications, APIs, and networks (internal, external, wireless, and physical), built on hands-on consulting experience since 2018, not a scanner with a report template.
Get started
Ready to scope cloud security?
Scoping conversations are free and usually take twenty minutes. You will speak directly with the consultant who would do the work.
Request an assessment
or reach out directly, (608) 520-0719 sales@infocus-security.com