Category: Audit
Summary
A cloud security audit methodology covering AWS, Azure, and GCP across 13 phases — from pre-engagement scoping to final reporting.- Phase 1 covers pre-engagement setup: confirming scope, access level, and verifying tooling connectivity across AWS, Azure, and GCP
- Phase 2 reviews IAM: wildcard permissions, unused access keys, MFA enforcement, cross-account trust relationships, overly permissive roles on compute, Owner/Contributor assignments (Azure), and primitive roles on GCP service accounts
- Phase 3 checks storage exposure: public S3 buckets, Azure Blob containers with public access, and GCS buckets with
allUsersorallAuthenticatedUsersbindings - Phase 4 audits network security: security groups open to
0.0.0.0/0, VPC flow logs, NACLs, publicly accessible RDS/OpenSearch instances, NSG rules (Azure), and open firewall rules (GCP) - Phase 5 verifies encryption: unencrypted EBS volumes, RDS instances, managed disks, KMS key rotation, CloudFront HTTPS enforcement, and CMEK coverage on GCP
- Phase 6 reviews logging and monitoring: CloudTrail multi-region coverage, GuardDuty, Security Hub, Azure Monitor diagnostic settings, Microsoft Defender for Cloud, and GCP Cloud Audit Logs
- Phase 7 covers secrets management: hardcoded secrets in Lambda/Cloud Functions env vars, EC2 user data, SSM Parameter Store, CloudFormation outputs, and Key Vault expiry
- Phase 8 audits compute and containers: IMDSv1 on EC2, EKS public endpoints, privileged ECS tasks, Kubernetes RBAC cluster-admin bindings, root pods, and missing resource limits
- Phase 9 reviews serverless and PaaS: public Lambda policies, deprecated runtimes, App Service authentication, Cloud Run public access
- Phase 10 maps all findings to CIS Benchmarks, ISO 27001, SOC 2, and PCI-DSS
- Phases 11–13 enforce a validation gate, false positive filter, and structured per-finding reporting with severity guidance
CONTEXT.md
When to Use This Context
Load this context when:- Auditing AWS, Azure, or GCP environments
- Reviewing IAM policies, roles, and permissions for least-privilege violations
- Checking for publicly exposed storage (S3, Azure Blob, GCS)
- Assessing network security groups, firewall rules, and VPC configurations
- Reviewing encryption posture at rest and in transit
- Assessing logging, monitoring, and incident response readiness
- Identifying hardcoded secrets in compute, serverless, and pipeline configs
- Mapping findings to CIS Benchmarks, ISO 27001, SOC 2, or PCI-DSS
web-app-pentest or api-security-review), OS-level exploitation, social engineering.
Phase 1 — Pre-Engagement & Scoping
Before any active enumeration, establish scope and access level:- Confirm which cloud accounts/subscriptions/projects are in scope
- Confirm access level: read-only auditor role, or broader permissions?
- Document the engagement type: configuration review only, or active exploitation allowed?
- Collect cloud account IDs, organization structure, and environment names (prod/staging/dev)
- Verify that audit logging is capturing your own activity (to avoid surprises for the client)
Phase 2 — IAM & Identity Review
This is the highest-priority phase. IAM misconfigurations are the root cause of most cloud breaches.AWS IAM
*):
Azure IAM
GCP IAM
Phase 3 — Storage Exposure
Publicly readable or writable storage is one of the most common and severe cloud misconfigurations.AWS S3
Azure Blob Storage
GCP Cloud Storage
Phase 4 — Network Security
AWS
Azure
GCP
Phase 5 — Encryption & Data Protection
AWS
Azure
GCP
Phase 6 — Logging & Monitoring
Missing or incomplete logging means breaches go undetected.AWS
Azure
GCP
Phase 7 — Secrets Management
Hardcoded or improperly stored secrets are consistently among the top findings in cloud audits.AWS
Azure
GCP
Phase 8 — Compute & Container Security
AWS EC2 & ECS/EKS
Kubernetes (EKS/AKS/GKE)
Phase 9 — Serverless & PaaS Security
AWS Lambda
Azure Functions & App Service
GCP Cloud Functions & Cloud Run
Phase 10 — Compliance & Benchmark Mapping
For each finding, map to the relevant control:
Common finding mappings:
Phase 11 — Validation Gate
Before reporting any finding, confirm all of the following:Phase 12 — False Positive Filter
Do not report without further investigation:- Public S3 bucket that is intentionally public — verify it hosts a static website or CDN assets; check the bucket policy for explicit intent
- Cross-account IAM role with broad permissions — verify the trusted account is not a legitimate vendor or internal account (e.g. AWS Config, Security Hub service roles)
- Open port 443/80 on a security group — web-facing services need these; only report if they expose non-web services (RDP, SSH, DB ports)
- Primitive GCP roles on Compute Engine service agent — Google-managed SAs often use Editor; check it is a Google-managed SA before flagging
- KMS key without auto-rotation — asymmetric keys do not support auto-rotation; check key type before reporting
- Lambda without VPC — only a finding if the Lambda accesses internal VPC resources (RDS, ElastiCache)
- Missing CloudTrail in a region with no resources — confirm the region is genuinely unused before flagging
- Short CloudTrail retention — check if logs are streamed to a SIEM with longer retention first
Phase 13 — Reporting
Every finding must include:
Severity guidance:
- Critical — Direct data exposure (public bucket with PII/credentials), unauthenticated RCE, complete loss of access control (public trust on IAM role)
- High — Wildcard IAM permissions, no MFA on privileged accounts, unencrypted sensitive data at rest, open RDP/SSH to world
- Medium — No logging/monitoring, missing rotation policy, IMDSv1 enabled, no flow logs, overly broad service roles
- Low — Short password policy, missing optional security features when other controls exist
- Informational — Best practice deviations with no direct exploit path
finding-writer skill to convert raw notes into structured findings. Use compliance-gap-analyzer to aggregate findings into a gap report. Use pentest-report to assemble the full engagement deliverable.
Related contexts
web-app-pentest
Full web application pentest methodology: recon, auth, injection, business logic
Rifteo-Community/contextscode-audit
Source code security review: secrets, auth logic, injection sinks, crypto, dependencies
Rifteo-Community/contexts
