cloud-security

---
name: cloud-security
description: Use when assessing cloud infrastructure for security misconfigurations: IAM privilege escalation, S3 exposure, open security groups, or IaC gaps. Covers AWS, Azure, GCP with MITRE ATT&CK mapping.
category: Engineering
version: 1.0.0
tools: []
---

# Cloud Security

Cloud security posture assessment for detecting IAM privilege escalation, public storage exposure, network configuration risks, and infrastructure-as-code misconfigurations. This is not incident response for an active cloud compromise, and not application vulnerability scanning — it is systematic cloud configuration analysis to prevent exploitation before it happens.

## What This Covers

Cloud security posture management (CSPM): systematically checking cloud configurations for misconfigurations that create exploitable attack surface. Covers IAM privilege escalation paths, storage public exposure, network over-permissioning, and infrastructure code security. Preventive — assess before exploitation, as distinct from reactive incident triage, behavioral threat hunting, or offensive penetration testing.

**Prerequisites:** read access to IAM policy documents, S3 bucket configurations, and security group rules (as JSON). For continuous monitoring, integrate with the cloud provider's own posture APIs (AWS Config, Azure Policy, GCP Security Command Center).

## Cloud Posture Checks

Three check types: **iam** (privilege escalation), **s3** (public access), and **sg** (network exposure). Each check can be run individually or together, and severity can be bumped with two modifiers: `internet-facing` (resource is directly internet-accessible — load balancer, API gateway, public EC2) and `regulated-data` (resource handles PCI, HIPAA, or GDPR-regulated data). Both modifiers raise each finding's severity by one level.

Overall result maps to three outcomes: no high/critical findings → no action required; high-severity findings → remediate within 24 hours; critical findings → remediate immediately, and escalate to incident response if the exposure looks actively exploited.

## IAM Policy Analysis

Detects privilege escalation paths, overprivileged grants, public principal exposure, and data-exfiltration risk. The danger is almost always in *combinations* of actions, not single actions in isolation — `iam:PassRole` alone is not critical, but `iam:PassRole + lambda:CreateFunction` is a confirmed privilege escalation path.

### Privilege Escalation Patterns

| Pattern | Severity | Key Action Combination | MITRE |
|---------|----------|------------------------|-------|
| Lambda PassRole escalation | Critical | iam:PassRole + lambda:CreateFunction | T1078.004 |
| EC2 instance profile abuse | Critical | iam:PassRole + ec2:RunInstances | T1078.004 |
| CloudFormation PassRole | Critical | iam:PassRole + cloudformation:CreateStack | T1078.004 |
| Self-attach policy escalation | Critical | iam:AttachUserPolicy + sts:GetCallerIdentity | T1484.001 |
| Inline policy self-escalation | Critical | iam:PutUserPolicy + sts:GetCallerIdentity | T1484.001 |
| Policy version backdoor | Critical | iam:CreatePolicyVersion + iam:ListPolicies | T1484.001 |
| Credential harvesting | High | iam:CreateAccessKey + iam:ListUsers | T1098.001 |
| Group membership escalation | High | iam:AddUserToGroup + iam:ListGroups | T1098 |
| Password reset attack | High | iam:UpdateLoginProfile + iam:ListUsers | T1098 |
| Service-level wildcard | High | iam:* or s3:* or ec2:* | T1078.004 |

### IAM Finding Severity Guide

| Finding Type | Condition | Severity |
|-------------|-----------|----------|
| Full admin wildcard | Action=* Resource=* | Critical |
| Public principal | Principal: '*' | Critical |
| Dangerous action combo | Two-action escalation path | Critical |
| Individual priv-esc actions | On wildcard resource | High |
| Data exfiltration actions | s3:GetObject, secretsmanager:GetSecretValue on * | High |
| Service wildcard | service:* action | High |
| Data actions on named resource | Appropriate scope | Low/Clean |

For every critical or high finding, give a least-privilege remediation: replace `Action: *` with a named list of required actions, replace `Resource: *` with specific ARN patterns, recommend AWS Access Analyzer to find actually-used permissions, and separate dangerous action combinations into different roles with distinct trust policies.

## S3 Exposure Assessment

Checks four dimensions: public access block configuration, bucket ACL, bucket policy principal exposure, and default encryption.

### S3 Configuration Check Matrix

| Check | Finding Condition | Severity |
|-------|------------------|----------|
| Public access block | Any of four flags missing/false | High |
| Bucket ACL | public-read-write | Critical |
| Bucket ACL | public-read or authenticated-read | High |
| Bucket policy Principal | "Principal": "*" with Allow | Critical |
| Default encryption | No ServerSideEncryptionConfiguration | High |
| Default encryption | Non-standard SSEAlgorithm | Medium |
| No PublicAccessBlockConfiguration | Status unknown | Medium |

Baseline: all four public-access-block settings (`BlockPublicAcls`, `BlockPublicPolicy`, `IgnorePublicAcls`, `RestrictPublicBuckets`) set `true`, server-side encryption with a KMS key and `BucketKeyEnabled: true`, and ACL set to `private`. Both account-level and bucket-level public access block settings must be enabled — a bucket-level setting can override an account-level one, so enabling only one layer is a false sense of security.

## Security Group Analysis

Flags inbound rules that expose admin ports, database ports, or all traffic to internet CIDRs (0.0.0.0/0, ::/0).

### Critical Port Exposure Rules

| Port | Service | Severity | Remediation |
|------|---------|----------|--------------|
| 22 | SSH | Critical | Restrict to VPN CIDR or use AWS Systems Manager Session Manager |
| 3389 | RDP | Critical | Restrict to VPN CIDR or use AWS Fleet Manager |
| 0–65535 (all) | All traffic | Critical | Remove rule; add specific required ports only |

### High-Risk Database Port Rules

| Port | Service | Severity | Remediation |
|------|---------|----------|--------------|
| 1433 | MSSQL | High | Allow from application-tier SG only — move to private subnet |
| 3306 | MySQL | High | Allow from application-tier SG only — move to private subnet |
| 5432 | PostgreSQL | High | Allow from application-tier SG only — move to private subnet |
| 27017 | MongoDB | High | Allow from application-tier SG only — move to private subnet |
| 6379 | Redis | High | Allow from application-tier SG only — move to private subnet |
| 9200 | Elasticsearch | High | Allow from application-tier SG only — move to private subnet |

## IaC Security Review

Catches configuration issues at definition time, before deployment.

### IaC Check Matrix

| Tool | Check Types | When to Run |
|------|-------------|-------------|
| Terraform | Resource-level checks (aws_s3_bucket_acl, aws_security_group, aws_iam_policy_document) | Pre-plan, pre-apply, PR gate |
| CloudFormation | Template property validation (PublicAccessBlockConfiguration, SecurityGroupIngress) | Template lint, deploy gate |
| Kubernetes manifests | Container privileges, network policies, secret exposure | PR gate, admission controller |
| Helm charts | Same as Kubernetes | PR gate |

Example — a Terraform IAM policy granting `Action = "*"` / `Resource = "*"` is a critical finding; the least-privilege fix scopes `Action` to a named list (e.g. `["s3:GetObject", "s3:PutObject"]`) and `Resource` to a specific ARN pattern (e.g. `arn:aws:s3:::my-specific-bucket/*"`).

## Cloud Provider Coverage Matrix

| Check Type | AWS | Azure | GCP |
|-----------|-----|-------|-----|
| IAM privilege escalation | Full (IAM policies, trust policies) | Partial (RBAC assignments, service principal risks) | Partial (IAM bindings, workload identity) |
| Storage public access | Full (S3 bucket policies, ACLs, public access block) | Partial (Blob SAS tokens, container access levels) | Partial (GCS bucket IAM, uniform bucket-level access) |
| Network exposure | Full (Security Groups, NACLs, port-level analysis) | Partial (NSG rules, inbound port analysis) | Partial (Firewall rules, VPC firewall) |
| IaC scanning | Full (Terraform, CloudFormation) | Partial (ARM templates, Bicep) | Partial (Deployment Manager) |

## Workflow: Quick Posture Check (20 Minutes)

For a newly provisioned resource or pre-deployment review: pull the IAM policy document and run the IAM check; pull the S3 bucket ACL and public-access-block config and run the S3 check; pull the security group rules and run the SG check. A critical result blocks deployment and requires immediate remediation; a high result gets scheduled within 24 hours.

## Workflow: Full Cloud Security Assessment (Multi-Day)

**Day 1 — IAM and Identity:** export all IAM policies attached to production roles; run the IAM check on each; map every privilege escalation path found; identify overprivileged service accounts and roles; review cross-account trust policies.

**Day 2 — Storage and Network:** enumerate all S3 buckets and export configurations; run the S3 check with the `regulated-data` modifier for data buckets; export security group configurations for all VPCs; run the SG check for internet-facing resources; review NACL rules for network segmentation gaps.

**Day 3 — IaC and Continuous Integration:** review Terraform/CloudFormation templates in version control; check the CI/CD pipeline for IaC security gates; produce a remediation plan prioritized Critical → High → Medium.

## Workflow: CI/CD Security Gate

Validate infrastructure-as-code before it applies, and validate an existing S3 bucket policy before it's modified. A critical result blocks the deployment; anything less proceeds with a logged finding.

## Anti-Patterns

1. **Running IAM analysis without checking escalation combos** — individual high-risk actions look low-risk in isolation; always analyze the full statement, not individual actions.
2. **Enabling only bucket-level public access block** — both account-level and bucket-level settings must be configured; a bucket-level setting can be silently overridden.

Return findings as a severity-ordered table directly in the chat, and @mention the on-call or infrastructure owner for any critical finding rather than only logging it.