Cloud Security Posture Assessment

Cross-cloud security posture assessment for evaluating IAM policies,

encryption configuration, and public exposure across [AWS], [Azure],

and [GCP] environments. This skill provides a unified assessment

methodology — diagnostic reasoning is provider-independent, while

specific commands and console paths use inline provider labels.

This is an assessment skill, not a deep-dive into any single provider's

networking layer. For detailed VPC, VNet, or VPC Network analysis, use

the dedicated provider skills: aws-networking-audit for VPC/Security

Group/Transit Gateway, azure-networking-audit for VNet/NSG/Route Table,

and gcp-networking-audit for VPC Network/Firewall Rule/Cloud Router

analysis. Reference references/cli-reference.md for multi-provider

CLI commands organized by audit step, and references/security-controls.md

for the IAM hierarchy model, encryption matrix, and CIS benchmark

control ID mapping.

When to Use

• Multi-cloud security review — assessing posture across two or more cloud providers in a single engagement
• Pre-compliance audit — evaluating IAM, encryption, and exposure gaps before formal CIS or SOC 2 assessment
• Cloud migration security gate — verifying security controls are in place before production traffic cutover
• Incident response scoping — quickly determining cross-cloud exposure surface during a security event
• Periodic posture check — scheduled assessment of IAM hygiene, encryption coverage, and public attack surface
• Merger or acquisition due diligence — evaluating cloud security maturity across inherited environments

Prerequisites

• [AWS] AWS CLI v2 configured (aws sts get-caller-identity succeeds); IAM permissions for iam:List, iam:Get, kms:List*, kms:DescribeKey, s3:GetBucketEncryption, s3:GetBucketPolicyStatus, ec2:DescribeSecurityGroups, ec2:DescribeInstances, elasticloadbalancing:DescribeLoadBalancers, rds:DescribeDBInstances, acm:ListCertificates
• [Azure] Azure CLI (az account show succeeds); RBAC Reader role on target subscriptions; permissions for Microsoft.Authorization/roleAssignments/read, Microsoft.KeyVault/vaults/read, Microsoft.Compute/disks/read, Microsoft.Network/publicIPAddresses/read, Microsoft.Network/networkSecurityGroups/read, Microsoft.Storage/storageAccounts/read
• [GCP] gcloud CLI configured (gcloud auth list shows active account); roles roles/iam.securityReviewer, roles/cloudkms.viewer, roles/compute.viewer, roles/storage.admin (for bucket IAM inspection) on target project(s)
• Target scope identified — cloud accounts/subscriptions/projects, regions, and environment tier (prod, staging, dev) defined before assessment begins
• Assessment window — coordinate with operations to avoid snapshot timing during deployments or maintenance windows

Procedure

Follow these six steps sequentially. Each step produces findings that

feed the cross-cloud posture summary in Step 6.

Step 1: IAM Posture Assessment

Evaluate identity and access management configuration for privilege

escalation risks, excessive permissions, and policy hygiene across

all in-scope providers. Focus on three areas: overly permissive

policies, missing authentication controls, and privilege escalation

paths through role chaining or impersonation.

[AWS] Enumerate IAM users, roles, and policies. Check for wildcard

actions in customer-managed policies:

aws iam get-account-authorization-details --output json
aws iam list-policies --scope Local --query 'Policies[?AttachmentCount>`0`]'

Flag policies with "Action": "" or "Resource": "" as Critical.

Review Service Control Policies (SCPs) in Organizations for boundary

gaps that allow privilege escalation paths (e.g., iam:CreateRole +

iam:AttachRolePolicy without SCP deny). Check for IAM users with

console access but no MFA: aws iam get-credential-report.

[Azure] Audit RBAC role assignments and Entra ID configuration:

az role assignment list --all --output table
az ad user list --query "[?userType=='Member']" --output table

Identify Owner/Contributor role sprawl — assignments at subscription

scope with no expiration indicate missing Privileged Identity Management

(PIM) activation policies. Review Conditional Access policies for gaps:

no policy covering all users, missing device compliance requirements,

or legacy authentication protocols not blocked.

[GCP] Analyze IAM bindings and Organization Policy constraints:

gcloud projects get-iam-policy <project-id> --format=json
gcloud resource-manager org-policies list --project=<project-id>

Flag bindings with roles/owner or roles/editor on service accounts

as Critical. Check for service account key age exceeding 90 days:

gcloud iam service-accounts keys list --iam-account=.

Verify Organization Policy constraints enforce iam.disableServiceAccountKeyCreation

where applicable.

Step 2: Encryption Audit

Assess encryption at rest and in transit across storage, compute,

and database services. Evaluate key management practices including

rotation schedules, access policies, and customer-managed vs

provider-managed key usage.

[AWS] Verify KMS key policies, storage encryption, and certificate

management:

aws kms list-keys --output table
aws s3api get-bucket-encryption --bucket <bucket-name>
aws rds describe-db-instances --query 'DBInstances[*].[DBInstanceIdentifier,StorageEncrypted,KmsKeyId]'

Check EBS volume encryption: aws ec2 describe-volumes --query 'Volumes[?!Encrypted]'.

Review ACM certificate expiry: aws acm list-certificates --query 'CertificateSummaryList[?Status==ISSUED]'.

Flag any unencrypted S3 buckets, EBS volumes, or RDS instances as

High severity. Verify KMS key rotation is enabled for customer-managed

keys: aws kms get-key-rotation-status --key-id .

[Azure] Audit Key Vault configuration, disk encryption, and TLS:

az keyvault list --output table
az disk list --query "[?encryption.type!='EncryptionAtRestWithPlatformKey']" --output table

Verify Key Vault access policies follow least privilege — no vault

with "Get, List, Set, Delete" for all principals. Check managed disk

encryption type (platform-managed vs customer-managed keys). Review

TLS minimum version on App Services: az webapp list --query "[].{name:name, minTlsVersion:siteConfig.minTlsVersion}".

[GCP] Assess Cloud KMS configuration and default encryption:

gcloud kms keyrings list --location=<location>
gcloud kms keys list --keyring=<keyring> --location=<location>

Determine CMEK vs Google-managed encryption per service. Flag any

Cloud Storage buckets or Compute disks without CMEK if the

organization policy requires it. Check KMS key rotation period:

gcloud kms keys describe --keyring= --location=.

Verify SSL policy compliance on load balancers:

gcloud compute ssl-policies list.

Step 3: Public Exposure Detection

Identify publicly accessible resources and evaluate network-level

exposure across all three providers. Public exposure combined with

weak authentication (Step 1) or missing encryption (Step 2) compounds

severity — cross-reference findings when classifying risk.

[AWS] Check for public S3 buckets, permissive Security Groups,

and load balancer configuration:

aws s3api list-buckets --query 'Buckets[*].Name' --output text
aws s3api get-bucket-policy-status --bucket <bucket-name>
aws ec2 describe-security-groups --filters "Name=ip-permission.cidr,Values=0.0.0.0/0"

Flag Security Groups allowing 0.0.0.0/0 ingress on non-standard

ports as Critical. Check ELB access logging: aws elbv2 describe-load-balancer-attributes --load-balancer-arn --query 'Attributes[?Key==access_logs.s3.enabled]'.

[Azure] Identify public IPs without network security controls:

az network public-ip list --output table
az network nsg list --output table
az storage account list --query "[].{name:name, publicAccess:allowBlobPublicAccess}"

Flag public IPs with no associated NSG as High severity. Check

storage account public access settings — allowBlobPublicAccess: true

requires justification. Verify Application Gateway WAF mode is

"Prevention" not "Detection" for production workloads.

[GCP] Detect public firewall rules and external load balancer

exposure:

gcloud compute firewall-rules list --filter="sourceRanges:0.0.0.0/0" --format=table
gcloud compute forwarding-rules list --filter="loadBalancingScheme=EXTERNAL"

Flag firewall rules with 0.0.0.0/0 source range on non-443/80

ports as Critical. Check Cloud Storage public access:

gsutil iam get gs:// and look for allUsers or

allAuthenticatedUsers bindings. Verify external load balancer

backends are intentionally public.

Step 4: Network Security Cross-Reference

Delegate deep network security analysis to the dedicated provider

networking skills. This step connects posture findings to network

architecture context and ensures that infrastructure-level controls

complement the identity and data protection evaluated in Steps 1–3.

• [AWS] Run aws-networking-audit for VPC CIDR design, Security Group rule-by-rule analysis, Transit Gateway topology, VPC Flow Log forensics, and Route Table validation
• [Azure] Run azure-networking-audit for VNet architecture, NSG effective rules, Route Table/UDR analysis, Network Watcher diagnostics, and Service Endpoint/Private Link coverage
• [GCP] Run gcp-networking-audit for VPC Network design, hierarchical firewall policy analysis, Cloud Router/BGP configuration, VPC Flow Log analysis, and Cloud NAT verification

Correlate findings: IAM misconfigurations (Step 1) combined with

permissive network rules (this step) represent compounded risk.

A service account with roles/editor behind a firewall rule

allowing 0.0.0.0/0 is more urgent than either finding alone.

Document cross-references between posture findings and network

architecture gaps in the final report.

Step 5: Compliance Mapping

Map findings to compliance framework controls. Reference CIS benchmark

control IDs for provider-specific checks and SOC 2 criteria for

organizational controls. This step transforms technical findings into

auditor-consumable evidence.

CIS Cloud Benchmark References (control IDs for audit mapping):

• [AWS] CIS AWS Foundations Benchmark — Section 1 (IAM), Section 2 (Storage/Logging), Section 3 (Monitoring), Section 4 (Networking), Section 5 (Compute)
• [Azure] CIS Azure Foundations Benchmark — Section 1 (IAM), Section 2 (Microsoft Defender), Section 3 (Storage), Section 4 (Database), Section 5 (Logging), Section 6 (Networking), Section 7 (VM), Section 8 (Key Vault)
• [GCP] CIS GCP Foundations Benchmark — Section 1 (IAM), Section 2 (Logging/Monitoring), Section 3 (Networking), Section 4 (VM), Section 5 (Storage), Section 6 (Cloud SQL), Section 7 (BigQuery)

Map each finding to the applicable CIS section and control number.

See references/security-controls.md for the full control ID index.

SOC 2 Control Mapping — Map infrastructure findings to Trust

Services Criteria: CC6 (Logical and Physical Access Controls) for

IAM and network exposure findings, CC7 (System Operations) for

encryption and monitoring gaps.

Severity Classification — Critical: exploitable public exposure

or admin-level privilege escalation. High: unencrypted sensitive

data or overly permissive IAM. Medium: missing logging, stale

credentials, or suboptimal encryption key management. Low:

configuration drift from best practice without direct exploit path.

Step 6: Cross-Cloud Posture Report

Compile findings into a structured cross-cloud posture report with

provider-by-provider comparison and prioritized remediation actions.

Provider Comparison Matrix — Tabulate findings by domain (IAM,

encryption, exposure) and provider. Identify which provider has

the strongest/weakest posture per domain. Flag any provider that

lacks coverage for a domain (e.g., no encryption at rest audit

completed for GCP). Note configuration parity gaps — if AWS

enforces MFA but Azure does not require Conditional Access, the

inconsistency itself is a finding.

Prioritized Remediation — Rank all findings by severity, then

by blast radius (multi-provider issues first). Group remediation

actions by provider to enable parallel workstreams. Estimate

effort for each remediation (quick fix vs project-level change).

Identify quick wins: enabling encryption defaults, rotating stale

keys, and restricting overly permissive firewall rules typically

resolve 30–50% of findings with minimal change risk.

Executive Summary — Overall posture score per provider (Critical/

High/Medium/Low finding counts), cross-cloud consistency assessment,

top 5 priority remediations, and recommended reassessment timeline.

Include trend data if prior assessments exist — improving or

degrading posture per domain.

Threshold Tables

Decision Trees

Cloud Posture Assessment Scoping:
├─ Single provider? → Use dedicated provider skill (aws/azure/gcp-networking-audit)
├─ Multiple providers? → Use this skill for cross-cloud posture assessment
│  ├─ All 3 providers in scope? → Full procedure (Steps 1–6)
│  ├─ 2 providers? → Skip provider-specific checks for absent provider
│  └─ Compliance required? → Include Step 5 mapping
└─ Provider deep-dive needed? → Cross-reference to dedicated skill (Step 4)

Finding Severity Assignment:
├─ Exploitable from internet with no authentication? → Critical
├─ Data exposure or privilege escalation path? → High
├─ Missing logging or stale credentials? → Medium
└─ Configuration drift without exploit path? → Low

IAM Escalation Path Detection:
├─ User/role can create new roles? → Check SCP/org policy boundary
│  ├─ No boundary? → Critical — unbounded privilege escalation
│  └─ Boundary exists? → Verify deny rules cover CreateRole + AttachPolicy
├─ Service account can impersonate other accounts? → High
└─ Cross-account trust allows external principals? → High

Report Template

# Cloud Security Posture Assessment Report

## Executive Summary
- **Assessment scope:** [AWS accounts / Azure subscriptions / GCP projects]
- **Assessment date:** [date]
- **Overall posture:** [Critical/High/Medium/Low finding summary]

## Provider Comparison Matrix
| Domain     | AWS        | Azure      | GCP        |
|------------|------------|------------|------------|
| IAM        | [findings] | [findings] | [findings] |
| Encryption | [findings] | [findings] | [findings] |
| Exposure   | [findings] | [findings] | [findings] |
| Network    | [ref: provider skill] | [ref: provider skill] | [ref: provider skill] |

## Findings by Severity

### Critical
| # | Provider | Domain | Finding | CIS Control | Remediation |
|---|----------|--------|---------|-------------|-------------|

### High
| # | Provider | Domain | Finding | CIS Control | Remediation |
|---|----------|--------|---------|-------------|-------------|

### Medium / Low
[Grouped table for lower-severity findings]

## Remediation Roadmap
1. [Immediate — Critical findings, estimated effort]
2. [Short-term — High findings within 30 days]
3. [Medium-term — Medium findings within 90 days]

## Appendix
- Provider-specific networking audit references
- Full CIS control mapping table
- Evidence collection inventory

Troubleshooting

Insufficient permissions on one provider — If credential checks

fail for a single provider (aws sts get-caller-identity, `az account

show, or gcloud auth list`), proceed with available providers and

document the gap. Partial assessments are valuable — note "Provider X

not assessed" in the comparison matrix.

Cross-account or cross-subscription enumeration failures — Multi-

account AWS environments require assume-role chains; multi-subscription

Azure requires Reader on each subscription. If enumeration returns

empty results, verify role trust policies and subscription RBAC before

assuming clean posture.

Large-scale environments — For environments with 50+ accounts or

subscriptions, sample-based assessment is acceptable. Prioritize

production accounts, internet-facing workloads, and accounts with

external trust relationships. Document sampling methodology and

coverage percentage in the report. Consider using cloud-native

aggregation tools ([AWS] Security Hub, [Azure] Defender for Cloud,

[GCP] Security Command Center) to supplement manual CLI checks.

Conflicting severity across providers — The same logical risk

(e.g., public storage) may present differently per provider. Use the

Threshold Tables severity definitions consistently. A publicly

accessible S3 bucket, Azure Blob container, and GCS bucket all receive

the same severity regardless of provider-specific defaults or naming.

Stale credentials not surfaced by default — [AWS] credential

reports require generation (aws iam generate-credential-report)

before download. [Azure] sign-in logs require Azure AD Premium P1.

[GCP] service account key listing shows creation date but not last

usage without additional audit log queries. Document data freshness

limitations in the report appendix.

CIS benchmark version alignment — Verify which CIS benchmark

version applies to the deployed cloud service versions. Cite the

benchmark version in findings (e.g., "CIS AWS Foundations v2.0.0 —

1.4"). Reference references/security-controls.md for control IDs.