Cloud Security Posture

Cross-cloud security posture assessment covering IAM analysis, encryption audit, and public exposure detection across AWS, Azure, and GCP using [AWS]/[Azure]...

Security Scan

The skill's behavior (running broad, sensitive cloud-read CLI commands across AWS/Azure/GCP) matches its stated purpose, but manifest inconsistencies and broad required account permissions warrant caution before installing or running it against production accounts.

Purpose & Capability

The name/description (cross-cloud security posture assessment) matches the commands and controls in SKILL.md — enumerating IAM, encryption, and exposure checks across AWS/Azure/GCP is coherent with the stated purpose. However the registry-level requirements (none) do not match the SKILL.md metadata which lists required binaries (aws, az, gcloud) and egress endpoints; that mismatch is unexpected and should be clarified by the publisher.

Instruction Scope

SKILL.md contains a clear, read-only assessment procedure and provider-specific CLI commands. The instructions focus on inventory and audit commands (IAM, KMS, S3, firewall rules, etc.) and do not instruct modification of resources or exfiltration to external endpoints. They do, however, assume authenticated CLI sessions with access to many sensitive resources.

Install Mechanism

This is an instruction-only skill with no install spec or code files, so nothing will be written to disk by an installer. That reduces supply-chain risk, but does not remove runtime risk from the CLI commands the agent will execute (or suggest executing).

Credentials

The skill declares no required environment variables or primary credential in the registry summary, yet the prerequisites explicitly require configured AWS/Azure/GCP CLI credentials with broad read permissions. Requesting organization-level or project-level read roles (e.g., organization policies, IAM listings, roles/storage.admin, roles/iam.securityReviewer) is proportionate to an audit but is highly sensitive. The manifest-level omission of required binaries/credentials is an incoherence that could hide assumptions about how credentials are provided. Also metadata lists egress endpoints and an mcpDependency ('aws-network-mcp') that are not otherwise explained in the registry-level fields.

Persistence & Privilege

The skill is not always-enabled and does not request persistent system-level privileges. It appears to be an on-demand assessment workflow; autonomous invocation is permitted (platform default) but not elevated by any 'always' flag or installer behavior.

What to consider before installing

This skill performs sensitive read-only audits across multiple cloud providers. Before using it: (1) Verify the publisher/source and ensure you trust them — there is no homepage and registry metadata mismatches the SKILL.md. (2) Run the assessment from a dedicated, least-privilege audit account or service principal (grant only the minimal read permissions needed). Avoid granting owner/editor or write privileges. (3) Test against non-production scope first. (4) Confirm where results will be reported or stored (the instructions don't specify an external endpoint, but the metadata lists cloud egress hosts). (5) Ask the publisher to fix manifest inconsistencies (declare required CLIs and any dependencies explicitly) and provide provenance (homepage, contact, or source repo). If the publisher cannot clarify these items, treat the skill with extra caution and consider running the commands manually under your controlled audit account instead of installing the skill.

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=<sa-email>. 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 <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 <key> --keyring=<keyring> --location=<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 <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://<bucket> 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

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.