Cloud Security Assessment Methodology
Release: Version 2.0
Document
| Field | Description |
|---|---|
| Name | Cloud Security Assessment Methodology |
| Subject | Cloud security assessment; configuration review; attack-path analysis; controlled penetration testing; IaaS; PaaS; SaaS; IAM; misconfiguration; vulnerability assessment |
| Purpose | Defines Hacken's approach to assessing the security of cloud environments and, where explicitly authorized, validating identified weaknesses in a controlled manner. |
| Primary platforms | Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) |
| Additional platforms | Alibaba Cloud, Tencent Cloud, Oracle Cloud Infrastructure (OCI), Huawei Cloud, IBM Cloud, DigitalOcean, OpenStack-based environments, and other public, private, hybrid-cloud, or SaaS tenant environments, subject to engagement-specific scoping and technical feasibility |
| Author | Ece Örsel | Leading Offensive Security Engineer, Hacken OU |
| Date | October 30, 2026 |
| Rights | Hacken OU |
1. Introduction
Cloud environments combine identities, networks, workloads, managed services, data stores, automation, and third-party integrations. Security weaknesses may arise from individual vulnerable resources as well as from excessive permissions, insecure configurations, exposed credentials, inherited policies, and trust relationships that create broader attack paths.
This document outlines Hacken's methodology for evaluating cloud security. Assessments are primarily performed as credentialed configuration and architecture reviews using broad read access. Depending on the agreed scope, they may also include controlled validation of attack paths and security testing of customer-controlled cloud workloads.
The term Cloud Security Audit, where used in commercial or contractual documents, refers to the assessment activities described in this methodology. It does not constitute a statutory audit, certification, or formal compliance attestation unless explicitly stated in the applicable agreement.
2. Objectives
The objectives of a cloud security assessment are to:
- Identify vulnerabilities, insecure configurations, excessive permissions, exposed resources, and weaknesses in cloud security controls.
- Map the cloud attack surface and identify privilege-escalation, credential-abuse, lateral-movement, and data-access paths.
- Evaluate the potential technical and business impact of identified weaknesses.
- Validate selected weaknesses in a controlled and non-destructive manner when active testing is authorized.
- Provide practical, prioritized, and provider-relevant remediation recommendations.
- Clearly document the assessment scope, coverage, assumptions, access limitations, and untested areas.
3. Scope
3.1 Supported Platforms and Service Models
The methodology applies primarily to AWS, Microsoft Azure, and GCP. It may also be applied to Alibaba Cloud, Tencent Cloud, OCI, Huawei Cloud, IBM Cloud, DigitalOcean, OpenStack-based environments, and other public, private, hybrid-cloud, or SaaS tenant environments.
Assessment of an additional platform is subject to the services in use, available access methods, provider-specific restrictions, technical feasibility, and written agreement. Listing a provider does not imply that all services offered by that provider are automatically supported or included in scope.
The methodology may cover:
- Infrastructure as a Service (IaaS)
- Platform as a Service (PaaS)
- Explicitly scoped Software as a Service (SaaS) tenant configurations
- Container and Kubernetes environments
- Infrastructure-as-Code and CI/CD configurations
- Customer-controlled cloud workloads, applications, APIs, and network services when separately included in scope
The assessment is limited to customer-owned or customer-authorized configurations, identities, resources, workloads, and integrations. It does not authorize testing of a cloud provider's underlying infrastructure, other customers, or third-party systems not expressly included in scope.
3.2 Engagement-Specific Scope
The exact scope is defined for each engagement and may include:
- Organizations, tenants, accounts, subscriptions, projects, folders, and management groups
- Regions, environments, and business units
- Cloud services, workloads, endpoints, and integrations
- User, service, workload, and federated identities
- Virtual networks, security controls, gateways, and management interfaces
- Data stores, backups, snapshots, secrets, and cryptographic key-management services
- Kubernetes clusters, container registries, and related workloads
- Infrastructure-as-Code repositories, CI/CD pipelines, runners, and deployment identities
- Explicit exclusions, restrictions, testing windows, and prohibited actions
Cloud-hosted application, API, operating-system, and network-service testing is not automatically included in a configuration assessment. Such testing is performed only when explicitly included in the agreed scope.
4. Standards and Reference Guidance
The methodology is informed by recognized technical testing guidance, cloud-security control frameworks, provider recommendations, and industry best practices. Relevant references may include:
- NIST Cybersecurity Framework and NIST SP 800-115
- ISO/IEC 27001, ISO/IEC 27002, and ISO/IEC 27017
- Cloud Security Alliance Cloud Controls Matrix
- Applicable CIS Benchmarks
- MITRE ATT&CK techniques relevant to cloud and identity environments
- Applicable cloud-provider security baselines, architecture guidance, and penetration-testing rules
- Common Vulnerability Scoring System (CVSS)
These references support assessment planning and control coverage. Their use does not by itself constitute certification or confirmation that every control in a referenced framework has been assessed.
5. Tools and Assessment Resources
Hacken selects tools according to the provider, scope, services, and objectives of each engagement. The assessment may use:
- Cloud-provider APIs, command-line interfaces, SDKs, and native security services
- Cloud-specific configuration, identity, policy, and attack-path analysis tools
- Kubernetes, container, Infrastructure-as-Code, and CI/CD security tooling where applicable
- Hacken-maintained internal scripts and automation for configuration collection, permission analysis, attack-path correlation, and evidence processing
- Manual review and controlled validation by qualified security testers
Exact tools are not fixed across all engagements. Automated results and script output are manually reviewed before being reported as confirmed findings.
6. Assessment Approach
The Cloud Security Assessment follows the phases below.
6.1 Pre-Engagement and Authorization
Before testing begins, Hacken and the customer establish the assessment objectives, boundaries, authorization, and safety requirements.
Activities include:
- Scope Definition - Define in-scope and out-of-scope environments, services, identities, workloads, regions, integrations, and third parties.
- Objective Alignment - Agree on business priorities, critical assets, required assessment depth, and expected deliverables.
- Authorization and Compliance Confirmation - Obtain written authorization and any required third-party consent, and confirm applicable legal, regulatory, contractual, and cloud-provider requirements.
- Provider-Rule Review - Identify applicable cloud-provider restrictions and approval requirements.
- Risk and Safety Planning - Agree on prohibited actions, rate limits, production safeguards, stop conditions, emergency contacts, and testing windows.
- Access Planning - Define required identities, permissions, connectivity, MFA, source addresses, and temporary credentials.
- Data Handling - Agree on evidence collection, confidentiality, redaction, storage, retention, transfer, and deletion requirements.
6.2 Environment Setup and Access Validation
A secure testing environment is prepared and access is validated before the technical assessment begins.
Activities include:
- Obtaining the agreed read-only or otherwise restricted assessment credentials.
- Configuring secure access to authorized APIs, consoles, command-line interfaces, clusters, repositories, and supporting systems.
- Confirming that the provided access covers all agreed accounts, subscriptions, projects, regions, services, and environments.
- Recording inaccessible or partially accessible areas as assessment limitations.
- Distinguishing the read-only assessment identity from any separate identity used to represent a realistic attacker scenario.
A read-only audit role is used to inspect configuration state; it is not automatically treated as an attacker foothold. Where active attack-path validation is required, the applicable initial-access assumptions and scenario identity are agreed separately.
6.3 Architecture, Threat Context, and Inventory
The team reviews the environment's architecture and establishes the context required to interpret technical weaknesses.
Activities may include:
- Reviewing resource hierarchy, network design, identity architecture, data flows, deployment processes, and security services.
- Reviewing the applicable customer and cloud-provider shared-responsibility boundaries for in-scope services.
- Identifying critical assets, sensitive data, privileged identities, trust boundaries, and external dependencies.
- Defining plausible attacker profiles and initial-access assumptions relevant to the scope.
- Enumerating in-scope resources, services, identities, endpoints, workloads, data stores, and integrations.
- Identifying public exposure, management interfaces, cross-account or cross-tenant trust, and inherited policies.
- Mapping the cloud attack surface and potential entry points.
6.4 Configuration and Security Control Assessment
Configuration data is assessed using cloud-specific tooling, Hacken-maintained scripts, provider-native capabilities, and manual review.
The review may cover:
- Governance and Resource Hierarchy - Organization structure, account or subscription boundaries, policies, guardrails, ownership, and configuration consistency.
- Identity and Access Management - Users, roles, groups, service accounts, workload identities, federation, MFA, access keys, effective permissions, least privilege, and privilege-escalation paths.
- Network Security - Network architecture, segmentation, firewall and security-group rules, public exposure, private connectivity, ingress, egress, DNS, and management-plane access.
- Data Protection and Cryptography - Storage and database permissions, backups, snapshots, encryption, key-management policies, key rotation, and cross-boundary data access.
- Secrets and Credentials - Secrets-management services, exposed credentials, environment variables, configuration files, CI/CD secrets, and credential-rotation controls.
- Compute and Managed Services - Virtual machines, images, metadata services, serverless functions, managed services, hardening, and service-specific security settings.
- Containers and Kubernetes - Cluster access, RBAC, admission controls, workload identities, secrets, registries, network policies, and workload isolation where included in scope.
- Logging, Monitoring, and Detection - Audit logs, control-plane logs, alerts, retention, centralization, integrity, and monitoring coverage.
- Vulnerability and Configuration Management - Insecure defaults, missing controls, unsupported components, patch posture, configuration drift, and deviations from approved baselines.
- CI/CD and Infrastructure-as-Code - Deployment identities, federation, runners, repositories, pipeline permissions, artifacts, secrets, and infrastructure definitions where included in scope.
- Resilience and Recovery - Backup protection, deletion safeguards, recovery arrangements, and availability-related configuration.
- Third-Party Integrations - External identities, managed-service providers, SaaS integrations, marketplace components, and cross-boundary trust.
Automated output is correlated with manual analysis to reduce false positives and identify weaknesses that may be exploitable only when combined.
6.5 Attack-Path Analysis
The collected configuration, identity, network, and service data is analyzed to determine how individual weaknesses may combine into broader compromise scenarios.
Activities may include:
- Identifying excessive, indirect, inherited, or unintended permissions.
- Enumerating cloud privilege-escalation paths.
- Analyzing cross-account, cross-subscription, cross-project, or cross-tenant trust relationships.
- Correlating exposed credentials, service identities, workload permissions, network reachability, and data access.
- Identifying possible paths from an assumed initial foothold to sensitive data, administrative control, or other high-impact assets.
- Documenting the preconditions and assumptions required for each material attack path.
The report distinguishes between paths confirmed from configuration evidence, paths actively validated, and impact that was inferred but not demonstrated.
6.6 Controlled Validation and Optional Active Testing
Where explicitly authorized, Hacken may perform controlled validation to confirm exploitability, effective access, or practical impact.
Validation may include:
- Assuming or impersonating an authorized test role
- Verifying privilege-escalation or cross-boundary access paths
- Testing the effective permissions of approved test credentials
- Confirming access to a limited, non-sensitive test object
- Validating public exposure or unauthorized resource access
- Confirming whether monitoring or preventive controls detect an agreed test action
Testing follows the least-intrusive approach and uses the minimum evidence necessary. Unless explicitly authorized, Hacken does not perform destructive actions, denial-of-service testing, bulk data extraction, persistent-access deployment, unapproved lateral movement, or modification or deletion of production data.
When customer-controlled workloads, applications, APIs, or network services are separately included in scope, the assessment may also cover:
- Exposed or outdated network services
- Application and API security weaknesses
- TLS, certificate, gateway, load-balancer, and ingress configuration
- Dangling DNS records and cloud-resource dependencies that may enable subdomain takeover
- Operating-system and workload vulnerabilities
These activities are not part of the default cloud configuration review and may also be governed by a separate Hacken testing methodology.
6.7 Risk Evaluation and Severity
Findings are evaluated based on available technical evidence and the context of the affected environment.
CVSS is used where applicable. Additional factors may include:
- Required access and attacker preconditions
- Internet or internal exposure
- Effective privileges and reachable resources
- Exploitability and complexity
- Data sensitivity and business criticality
- Blast radius across accounts, subscriptions, projects, or tenants
- Potential impact on confidentiality, integrity, availability, operations, and compliance
- Compensating controls and detection capabilities
Severity and validation depth are treated separately. A finding may be configuration-confirmed, attack-path validated, impact-demonstrated, partially validated, or not actively validated due to scope, safety, or provider restrictions.
| Severity | CVSS Range |
|---|---|
| Informational | 0.0 |
| Low | 0.1–3.9 |
| Medium | 4.0–6.9 |
| High | 7.0–8.9 |
| Critical | 9.0–10.0 |
Where CVSS is not suitable for a configuration or architectural weakness, the rating is determined using documented contextual risk factors.
6.8 Reporting, Closure, and Retesting
The assessment concludes with reporting, review, and closure activities.
The report includes, as applicable:
- Executive summary and overall security posture
- Assessment scope, objectives, access model, and methodology
- Coverage of accounts, subscriptions, projects, regions, services, and environments
- Relevant attacker assumptions and material attack paths
- Identified vulnerabilities and misconfigurations
- Affected resources, evidence, preconditions, impact, severity, and validation status
- Practical and prioritized remediation recommendations, including remediation or retest status where applicable
- Assessment limitations, exclusions, and untested areas
Reported findings undergo technical review and quality assurance before delivery.
Post-engagement activities may include:
- A debriefing or report walkthrough
- Removal of temporary test artifacts created by Hacken
- Revocation of temporary credentials where applicable
- Evidence handling according to the agreed retention requirements
- Retesting to validate implemented remediation
- Documentation of unresolved findings and residual risk
7. Responsibilities
Customer Responsibilities
The customer is responsible for:
- Providing accurate scope information and written authorization
- Ensuring ownership or authorization for all in-scope resources
- Providing the agreed access, documentation, and technical contacts
- Informing Hacken of sensitive production constraints and planned changes
- Maintaining appropriate backups and recovery procedures
- Reviewing and implementing remediation decisions
Hacken Responsibilities
Hacken is responsible for:
- Operating within the agreed scope and authorization
- Following applicable provider restrictions and safety requirements
- Protecting credentials, evidence, and customer information
- Using controlled and proportionate testing techniques
- Manually validating reported findings
- Clearly documenting evidence, assumptions, limitations, and remediation guidance
- Applying technical review and quality assurance to the deliverable
8. Disclaimer
A Cloud Security Assessment represents a point-in-time evaluation of the environment and access made available during the engagement. Cloud resources and configurations may change continuously; therefore, findings and conclusions are valid for the assessed scope and state observed during the assessment period.
The completeness of the assessment depends on the accuracy of the declared scope, the visibility provided by the supplied access, the availability of relevant evidence, and the testing restrictions agreed with the customer. Inaccessible, excluded, newly created, or modified resources may not be reflected in the results.
Stay in Touch
We’re excited to share our expertise and help you build a safer web3 future. If you have any questions, feel free to contact us.