Solution blueprint
Cloud security assessment and remediation
In the cloud, identity is the perimeter. An assessment that only lists misconfigurations misses the question that matters: from an ordinary identity, what could someone reach?
The situation
A company has grown from one AWS account to a dozen. Each was created for a reason, none were created from a template, and nobody is sure which of them hold production data. An enterprise customer has asked for evidence of cloud security review, which has made an existing worry into a funded project.
The assessment answers three questions: what do we have, who can reach it, and what would we fix first.
Constraints that shape the plan
- Read-only access only. This is an assessment, not a penetration test, unless separately authorized.
- No change to production during the assessment.
- Some accounts owned by teams who were not consulted about the review.
- Logging retention too short in some accounts to answer historical questions.
- A customer deadline, so the output must be usable rather than exhaustive.
What gets reviewed
Identity
- IAM users, roles, groups and policies
- Access keys and their age and use
- Trust policies and external access
- Federation and Identity Center configuration
- Privilege escalation paths
This is where the serious findings usually are.
Exposure
- Internet-facing services and load balancers
- Security groups and network access control lists
- Public object storage and snapshots
- Exposed management interfaces and databases
- Certificates and DNS records
What an outsider can reach without credentials.
Workloads
- EC2 instance metadata configuration and patch state
- Container and Kubernetes RBAC and image sources
- Serverless function permissions and environment secrets
- Secrets management and encryption keys
Where a compromised application becomes a compromised account.
Governance and detection
- Organizations structure and service control policies
- CloudTrail coverage, destination and protection
- Configuration recording and drift
- Threat detection services and who reads them
- Backup and recovery configuration
Whether you would see an incident, and whether you could answer questions about it.
How the assessment runs
- Scope Accounts, access, exclusions
- Discover Inventory and configuration
- Analyze Identity paths and exposure
- Validate Confirm what is real
- Prioritize Impact and effort
- Report Executive and technical
- Remediate With your teams
- Retest Confirm closure
The approach, phase by phase
Phase 1: Scope and access
One week.
-
1
Agree accounts and exclusions
In writing, with the account owners identified.
-
2
Provision read-only access
A dedicated role per account, time-limited, logged, removed at the end.
-
3
Agree the rules
No changes, no active exploitation, named contacts, and what happens if we find something urgent.
Phase 2: Discover and analyze
Two to three weeks.
-
4
Inventory
Accounts, regions, resources, owners and data classification where known.
-
5
Identity analysis
Permissions, trust relationships, key age and use, and the paths from low privilege to high.
-
6
Exposure analysis
What is reachable from the internet, and what it is connected to.
-
7
Workload review
Instance metadata configuration, container permissions, function roles, secrets handling.
-
8
Detection review
Log coverage, destination, protection and who acts on alerts.
Phase 3: Validate and prioritize
One week.
-
9
Confirm findings
Remove the false positives that automated analysis produces, and mark what was inferred rather than proven.
-
10
Build attack paths
Chain findings into the two or three routes that actually matter, with each hop evidenced.
-
11
Rate by impact and effort
So the first week of remediation removes the most risk, not the most findings.
-
12
Review with your team
Before the report is final, so the fixes are ones your engineers agree are feasible.
Phase 4: Remediate and validate
Four to eight weeks, with your teams.
-
13
Fix the urgent items
Root keys, public data, broad trust policies, missing logging.
-
14
Add guardrails
Service control policies, account baselines and a template for new accounts.
-
15
Centralize logging
One log archive account, write-protected, with retention that answers investigation questions.
-
16
Assign detection ownership
Findings routed to a team with a response expectation.
-
17
Retest
Confirm the fixes work, and report what remains open with an owner and a date.
Phase names and order change with the engagement. This is a typical shape, not a fixed method you would be held to.
The kind of team this needs
Roles can be ours, yours or shared. Where you only need people rather than a project owner, the same roles are available through staffing.
Typical deliverables
- Account and resource inventory with owners
- Findings with evidence, affected resources and severity
- Two or three validated attack paths, hop by hop
- Prioritized remediation plan by impact and effort
- Guardrail and account baseline recommendations
- Logging and detection gap list
- Executive summary suitable for sharing with a customer
- Retest report after remediation
What usually goes wrong, and what we do about it
-
A findings list nobody acts on
We prioritize by what removes risk, review the plan with your engineers, and retest. A report that is not actionable is a failed engagement.
-
False positives eroding trust
Every finding is validated by a person before it reaches the report, and anything inferred is labeled as inferred.
-
Account owners surprised by the review
Owners are identified and informed in the scoping week.
-
Fixes that break production
Remediation is planned with the teams who run the workloads, and permission changes are made with a rollback.
-
Short log retention
If logs cannot answer historical questions we say so plainly, and fixing retention becomes a finding.
-
Treating assessment as a penetration test
This blueprint is read-only analysis. Active exploitation needs separate written authorization: see cloud penetration testing.
Questions people ask
Will this satisfy a customer asking for a security review?
It gives you an executive summary, a findings list with evidence and a remediation plan with dates, which is what most customer questionnaires are asking for. It is not a certification and we will not present it as one.
Do you need write access?
No. The assessment is read-only. If you want us to implement the fixes, that is a separate scope with its own access and change control.
Does this cover Azure or Google Cloud?
Yes, with the equivalent services. The structure of the work is the same; the controls differ.
How often should this be repeated?
An annual review plus continuous posture monitoring is a common pattern. The guardrails and account baseline we recommend are what keep the next review from finding the same things.
Related
-
AWS security
Review of IAM, organizations, networking, storage, logging and workloads in AWS, with a fix plan ordered by what attackers use first.
-
Cloud penetration testing
Starting from a defined foothold, test whether identity, permission and trust paths in AWS, Azure or Google Cloud lead to sensitive data or control.
-
Azure cloud migration
Moving a data center of mixed workloads to Azure, in waves, on a governed landing zone.
-
Security assessment planner
Answer questions that fit the service you want and get a structured, preliminary scope we can discuss.
Need to understand your security exposure?
Speak with a security expert
Talk through your environment and goals. We reply to scope the work before anything is tested.
Speak with a security expertPlan an assessment
Answer a few questions and get a structured preliminary scope you can send us.
Use the plannerUnder attack right now?
Call the US office and tell us what you are seeing. Do not wait for a form reply.
Incident response