Auditing Cloud With Cis BenchmarksSAFE

817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains ·

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: auditing-cloud-with-cis-benchmarks
description: Audit AWS, Azure, and GCP environments against the CIS Foundations Benchmarks by running automated scans with tools like Prowler and ScoutSuite, interpreting failed controls, and tracking remediation for continuous compliance. Use when conducting a cloud security audit, validating CIS benchmark compliance (CIS v5 AWS, v4 Azure, v4 GCP), or setting up continuous cloud compliance monitoring.
domain: cybersecurity
subdomain: cloud-security
tags:
- cis-benchmarks
- cloud-audit
- compliance-assessment
- prowler
- security-hardening
version: 1.0.0
author: mahipal
license: Apache-2.0
nist_ai_rmf:
- GOVERN-1.1
- GOVERN-4.2
- MAP-2.3
nist_csf:
- PR.IR-01
- ID.AM-08
- GV.SC-06
- DE.CM-01
mitre_attack:
- T1078.004
- T1530
- T1098.003
- T1685.002
- T1580
---

# Auditing Cloud with CIS Benchmarks

## When to Use

- When performing initial security audits of cloud environments against industry-standard benchmarks
- When preparing for SOC 2, ISO 27001, or regulatory audits that reference CIS controls
- When establishing a measurable security baseline for new cloud accounts or subscriptions
- When tracking compliance improvement over time with periodic reassessment
- When evaluating the security posture of acquired or inherited cloud environments

**Do not use** for runtime threat detection (see detecting-cloud-threats-with-guardduty), for application-level security testing (see conducting-cloud-penetration-testing), or for compliance frameworks not based on CIS (refer to specific regulatory skill files).

## Prerequisites

- Read-only access to target cloud accounts (AWS SecurityAudit policy, Azure Reader role, GCP Viewer role)
- Prowler, ScoutSuite, or cloud-native CSPM tools installed and configured
- Understanding of CIS benchmark structure: sections, controls, profiles (Level 1 and Level 2)
- Remediation access for implementing fixes (separate from audit credentials)

## Workflow

### Step 1: Select Appropriate CIS Benchmark Version

Choose the correct benchmark version for each cloud provider. Current versions as of 2025 include CIS AWS Foundations Benchmark v5.0, CIS Azure Foundations Benchmark v4.0, and CIS GCP Foundations Benchmark v4.0.

```
CIS Benchmark Coverage Areas:
+-------------------+-------------------------+------------------------+
| Section           | AWS v5.0                | Azure v4.0             |
+-------------------+-------------------------+------------------------+
| Identity & Access | IAM policies, MFA, root | Azure AD, RBAC, PIM    |
| Logging           | CloudTrail, Config      | Activity Log, Diag     |
| Monitoring        | CloudWatch alarms       | Defender, Sentinel     |
| Networking        | VPC, SG, NACLs         | NSG, ASG, Firewall     |
| Storage           | S3 encryption, access   | Storage encryption     |
| Database          | RDS encryption          | SQL TDE, auditing      |
+-------------------+-------------------------+------------------------+

CIS Profile Levels:
  Level 1: Practical security settings that can be implemented without significant
           performance impact or reduced functionality
  Level 2: Defense-in-depth settings that may reduce functionality or require
           additional planning for implementation
```

### Step 2: Run Automated Assessment with Prowler

Execute comprehensive CIS benchmark scans using Prowler for automated control evaluation across AWS, Azure, and GCP.

```bash
# AWS CIS v5.0 assessment
prowler aws \
  --compliance cis_5.0_aws \
  --profile audit-account \
  --output-formats json-ocsf,html,csv \
  --output-directory ./cis-audit-$(date +%Y%m%d)

# Azure CIS v4.0 assessment
prowler azure \
  --compliance cis_4.0_azure \
  --subscription-ids "sub-id-1,sub-id-2" \
  --output-formats json-ocsf,html,csv \
  --output-directory ./cis-audit-azure-$(date +%Y%m%d)

# GCP CIS v4.0 assessment
prowler gcp \
  --compliance cis_4.0_gcp \
  --project-ids "project-1,project-2" \
  --output-formats json-ocsf,html,csv \
  --output-directory ./cis-audit-gcp-$(date +%Y%m%d)

# Multi-account AWS scan using ScoutSuite
scout suite aws \
  --profile audit-account \
  --report-dir ./scout-report \
  --ruleset cis-5.0 \
  --force
```

### Step 3: Interpret Results and Prioritize Remediation

Analyze audit results by section and severity. Prioritize Level 1 controls first as they represent fundamental security hygiene, then address Level 2 controls for defense in depth.

```bash
# Parse Prowler results for failed controls
cat ./cis-audit-*/prowler-output-*.json | \
  jq '[.[] | select(.StatusExtended == "FAIL")] | group_by(.CheckID) |
  map({control: .[0].CheckID, description: .[0].CheckTitle,
  failed_resources: length, severity: .[0].Severity}) |
  sort_by(-.failed_resources)'

# Generate compliance score by section
cat ./cis-audit-*/prowler-output-*.json | \
  jq 'group_by(.Section) | map({
    section: .[0].Section,
    total: length,
    passed: [.[] | select(.StatusExtended == "PASS")] | length,
    failed: [.[] | select(.StatusExtended == "FAIL")] | length,
    score: (([.[] | select(.StatusExtended == "PASS")] | length) / length * 100 | round)
  })'
```

### Step 4: Remediate Critical and High Controls

Address failed controls starting with the highest impact items. Use AWS Config remediation, Azure Policy, or Terraform to apply fixes systematically.

```bash
# CIS 1.4: Ensure no root account access key exists
aws iam list-access-keys --user-name root
# If keys exist, delete them
aws iam delete-access-key --user-name root --access-key-id AKIAEXAMPLE

# CIS 2.1.1: Ensure S3 bucket default encryption is enabled
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
  aws s3api put-bucket-encryption --bucket "$bucket" \
    --server-side-encryption-configuration '{
      "Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]
    }' 2>/dev/null && echo "Encrypted: $bucket" || echo "FAILED: $bucket"
done

# CIS 3.1: Ensure Clo

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.