Cloud Security Posture

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

Prerequisites

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  --format=json
gcloud resource-manager org-policies list --project=

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 
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=
gcloud kms keys list --keyring= --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 
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.

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):

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

| Domain | Severity | Condition | Example | |--------|----------|-----------|---------| | IAM | Critical | Wildcard admin policy without SCP boundary | "Action": "*", "Resource": "*" | | IAM | High | Service account/user with no MFA and console access | AWS IAM user, Azure member without CA | | IAM | Medium | Service account key age >90 days | [GCP] key rotation overdue | | IAM | Low | Unused IAM role with permissions attached | Role with 0 last-used date | | Encryption | Critical | Unencrypted database with sensitive data | RDS, Azure SQL, Cloud SQL | | Encryption | High | Unencrypted storage bucket/volume | S3, Blob Storage, Cloud Storage | | Encryption | Medium | Customer-managed key rotation >365 days | KMS, Key Vault, Cloud KMS | | Encryption | Low | Platform-managed keys where CMEK policy exists | Org policy violation | | Exposure | Critical | Public access on 0.0.0.0/0 non-web ports | SSH/RDP open to internet | | Exposure | High | Storage bucket publicly accessible | S3, Blob, GCS with allUsers | | Exposure | Medium | Load balancer without access logging | ALB, App Gateway, Cloud LB | | Exposure | Low | WAF in detection mode (not prevention) | [Azure] App Gateway WAF |

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.

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.