Rapportage en Compliance

Er is een merkwaardige paradox in cloud-security. Organisaties migreren naar de cloud omdat het flexibeler, schaalbaarder en – zo wordt beweerd – veiliger is dan on-premise. Vervolgens besteden ze meer tijd aan het bewijzen dat het veilig is dan aan het maken dat het veilig is. Compliance-frameworks stapelen zich op als geologische lagen: CIS Benchmarks, SOC 2, ISO 27001, NEN 7510, BIO, en wat er volgende maand weer wordt uitgevonden. Elk framework vereist bewijs. Elk bewijs vereist documentatie. Elke documentatie vereist een rapport.

En het rapport – het pentest-rapport – is de plek waar al die draden samenkomen. Of uit elkaar vallen, afhankelijk van hoe goed je het schrijft.

In de voorgaande delen behandelden we rapportage in de context van webapplicaties en interne netwerken. Cloud-rapportage verschilt daarvan op fundamentele manieren. De scope is anders. De evidence is anders. De aanbevelingen zijn anders. En de mensen die het rapport lezen verwachten andere dingen.

Dit hoofdstuk behandelt hoe je een cloud-pentest-rapport schrijft dat zowel technisch rigoureus is als daadwerkelijk gelezen wordt. Het eerste is moeilijk. Het tweede is moeilijker.

12.1 Cloud-specifieke rapportage

Wat is anders

Een traditioneel pentest-rapport beschrijft hoe een aanvaller van punt A (de buitenkant van het netwerk) naar punt B (de kroonjuwelen) komt. Het is een lineair verhaal: initieel toegangspunt, privilege escalation, lateral movement, data-exfiltratie. De lezer kan het pad volgen als een wandelroute op een kaart.

Een cloud-pentest-rapport is fundamenteel anders. In de cloud is er vaak geen lineair pad. Er zijn tientallen onafhankelijke misconfiguraties die elk hun eigen risico dragen. Een publieke S3 bucket heeft niets te maken met een overprivileged Lambda-functie, die weer niets te maken heeft met een ontbrekend MFA-beleid. Het zijn parallelle problemen, niet opeenvolgende stappen.

Dit heeft gevolgen voor de structuur van je rapport. In plaats van een verhaal schrijf je een catalogus – maar dan een catalogus met context. Elke bevinding moet op zichzelf staan, maar het rapport als geheel moet een overkoepelend beeld schetsen van de beveiligingspostuur van de cloud-omgeving.

De drie lagen van cloud-rapportage

Een effectief cloud-pentest-rapport opereert op drie lagen:

Laag 1: Identiteit en toegang – De IAM-configuratie. Wie heeft welke rechten? Zijn er overprivileged identiteiten? Zijn er stale credentials? Is MFA afgedwongen? Dit is het fundament. Als de IAM-configuratie zwak is, zijn alle andere beveiligingsmaatregelen irrelevant – alsof je een alarmsysteem installeert maar de sleutel onder de deurmat legt.

Laag 2: Resource-configuratie – De individuele services. Zijn storage containers beveiligd? Zijn databases versleuteld? Zijn security groups correct geconfigureerd? Zijn logging-services ingeschakeld? Dit is het middenniveau, waar de meeste bevindingen zitten.

Laag 3: Architectuur en governance – De grote lijn. Is er een multi-account-strategie? Zijn er Service Control Policies? Is er een proces voor het reviewen van IAM-wijzigingen? Worden compliance-checks geautomatiseerd? Dit is het strategische niveau, en het is het niveau waar de meeste organisaties het zwakst scoren – niet omdat ze het niet willen, maar omdat ze er niet aan toekomen.

IB Tip: Structureer je findings in IB langs deze drie lagen. Gebruik het type-veld in de finding template om onderscheid te maken tussen Identity, Configuration, en Governance-findings. Dit maakt het eenvoudiger om de findings per laag te presenteren in het rapport.

12.2 Het rapport structureren

Management Samenvatting

De management samenvatting is het enige deel van je rapport dat gegarandeerd wordt gelezen. Door iedereen. Inclusief mensen die het verschil niet weten tussen een IAM policy en een huisdier. Schrijf het alsof je het uitlegt aan iemand die intelligent is maar geen technische achtergrond heeft.

Structuur:

1. Scope (2-3 zinnen): Welke cloud-accounts, subscriptions of projecten zijn getest? Welke services waren in scope? In welke periode?
2. Algeheel risiconiveau (1 zin): Kritiek, Hoog, Gemiddeld, of Laag. Een woord. Geen nuance. De nuance komt later.
3. Kernbevindingen (3-5 bullets): De bevindingen die het meest impact hebben, in taal die een bestuurder begrijpt.
4. Positieve observaties (2-3 bullets): Wat ging er goed? Dit is geen vleierei; dit is eerlijkheid. En het zorgt ervoor dat de ontvanger het rapport niet meteen in de prullenbak gooit uit zelfbescherming.
5. Strategische aanbevelingen (2-3 bullets): De high-level acties die de organisatie moet nemen.

Voorbeeld van een kernbevinding in management-taal:

Slecht: > “De IAM policy arn:aws:iam::123456789012:policy/LegacyAdminPolicy bevat "Action": "*", "Resource": "*" waardoor de gekoppelde role volledige administratortoegang heeft tot alle services in het account.”

Goed: > “Een configuratiefout in het rechtenbeheer geeft een service-account volledige toegang tot alle systemen en data in de cloud-omgeving. Een aanvaller die dit account compromitteert – bijvoorbeeld via een kwetsbare applicatie – heeft direct toegang tot alle bedrijfsdata, inclusief klantgegevens en financiele informatie.”

Beide zijn waar. De eerste is nuttig voor het team dat het moet fixen. De tweede is nuttig voor het bestuur dat moet beslissen of en wanneer het wordt gefixt.

Scope-documentatie

In een on-premise pentest is de scope relatief eenvoudig: een IP-bereik, een lijst met systemen, een tijdvenster. In een cloud-pentest is de scope complexer en verdient een eigen sectie in het rapport.

De scope-sectie documenteert:

## Scope

### Cloud-accounts
| Provider | Account / Subscription / Project | Omschrijving |
|---|---|---|
| AWS | 123456789012 | Productie-account |
| AWS | 987654321098 | Development-account |
| Azure | a1b2c3d4-e5f6-... | Productie-subscription |

### Regio's
| Provider | In scope | Buiten scope |
|---|---|---|
| AWS | eu-west-1, eu-central-1 | us-east-1, ap-southeast-1 |
| Azure | West Europe, North Europe | East US, Southeast Asia |

### Services in scope
IAM, EC2, S3, RDS, Lambda, VPC, CloudTrail, Organizations,
Entra ID, Key Vault, Storage Accounts, App Service, Azure Monitor

### Services buiten scope
AWS GovCloud, Azure Government, productie-databases (read-only)

### Tijdvenster
2026-02-16 tot en met 2026-02-27, dagelijks 08:00-18:00 CET

### Beperkingen
- Geen destructieve tests op productie-workloads
- Geen social engineering
- Geen brute force op Entra ID-accounts (lockout-risico)

Methodologie

Beschrijf kort welke methodologie je hebt gevolgd. Voor cloud-pentests is dit doorgaans een combinatie van:

• Geautomatiseerde scanning: ScoutSuite, Prowler, of vergelijkbare tools voor een breed overzicht van misconfiguraties
• Handmatige IAM-analyse: Review van policies, roles, trust relationships
• Handmatige service-configuratie review: Storage permissions, network configuration, logging
• Exploit-validatie: Daadwerkelijke exploitatie van gevonden misconfiguraties om impact te bevestigen
• Compliance mapping: Bevindingen mappen naar relevante frameworks (CIS, SOC 2, ISO 27001)

Verwijs naar de MITRE ATT&CK Cloud Matrix als referentiekader. Dit geeft de opdrachtgever een universeel referentiepunt en maakt het mogelijk om bevindingen te koppelen aan bekende dreigingsactoren.

Bevindingen per severity

Sorteer bevindingen op severity (Critical, High, Medium, Low, Informational), niet op type of service. De lezer wil weten wat het ergste is, niet wat het meest voorkomt. Binnen elke severity-categorie groepeer je op thema (Identity, Configuration, Governance).

## Bevindingen

### Critical (1)
- **C-01**: Publiek toegankelijke S3 bucket met klantgegevens

### High (4)
- **H-01**: IAM user met onbeperkte administratortoegang
- **H-02**: Ontbrekende MFA op privileged accounts
- **H-03**: EC2 instance role met AdministratorAccess
- **H-04**: CloudTrail logging uitgeschakeld in 3 regio's

### Medium (6)
- **M-01**: Security groups met 0.0.0.0/0 inbound rules
- **M-02**: RDS instance publiek toegankelijk
- ...

### Low (3)
- **L-01**: S3 bucket versioning niet ingeschakeld
- ...

### Informational (2)
- **I-01**: AWS Config niet ingeschakeld
- ...

IB Tip: IB sorteert findings automatisch op CVSS 4.0-score in het gegenereerde rapport. De severity-classificatie (Critical/High/Medium/Low) wordt afgeleid uit de CVSS-score. Zorg dat je CVSS-vectors nauwkeurig zijn – een verschil van 0.1 punt kan het verschil zijn tussen High en Critical, wat bepaalt hoeveel aandacht de finding krijgt.

12.3 Cloud Findings Documenteren

Console Screenshots vs CLI Output

In on-premise pentesting is het standaard om screenshots van terminalsessies als bewijs te gebruiken. In cloud-pentesting heb je een extra bron: de cloud console. En de keuze tussen console-screenshots en CLI-output is niet triviaal.

Console-screenshots zijn visueel en begrijpelijk voor niet-technische lezers. Een screenshot van de AWS S3 Console die laat zien dat “Block Public Access” is uitgeschakeld is onmiddellijk duidelijk. Maar console-screenshots zijn ook vluchtig – de interface verandert regelmatig, en een screenshot van een pagina die er over zes maanden anders uitziet verliest zijn waarde.

CLI-output is reproduceerbaar, doorzoekbaar, en exact. Een commando dat de bucket policy ophaalt geeft precies weer wat de configuratie is, zonder grafische interpretatie. Maar CLI-output is voor de gemiddelde lezer van een rapport even begrijpelijk als oude Sumerische kleitabletten.

De oplossing: gebruik beide. Console-screenshots in de managementsamenvatting en de high-level bevindingsomschrijving. CLI-output in de technische details en de stappen om het te reproduceren.

# AWS: S3 bucket access configuratie (CLI evidence)
aws s3api get-bucket-acl --bucket BUCKET_NAME
aws s3api get-bucket-policy --bucket BUCKET_NAME
aws s3api get-public-access-block --bucket BUCKET_NAME

# Voorbeeld output die in het rapport hoort:
# {
#   "PublicAccessBlockConfiguration": {
#     "BlockPublicAcls": false,
#     "IgnorePublicAcls": false,
#     "BlockPublicPolicy": false,
#     "RestrictPublicBuckets": false
#   }
# }

IAM Policy-analyse als Evidence

IAM policies zijn JSON-documenten. Ze zijn de kern van cloud-beveiliging. En ze horen in je rapport – niet als een muur van onleesbare JSON, maar als geannoteerde, relevante fragmenten.

Een effectieve IAM-finding bevat:

1. De policy (of het relevante fragment) met annotatie
2. Wat er mis is in begrijpelijke taal
3. Wat de impact is – wat kan een aanvaller met deze rechten?
4. Wat het zou moeten zijn – de gecorrigeerde policy

// GEVONDEN: Overprivileged policy op service account
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",            // <-- PROBLEEM: wildcard op alle acties
      "Resource": "*"           // <-- PROBLEEM: wildcard op alle resources
    }
  ]
}

// AANBEVOLEN: Least privilege policy
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::corp-data-bucket",
        "arn:aws:s3:::corp-data-bucket/*"
      ]
    }
  ]
}

Vergelijkbare analyses voor Azure:

// GEVONDEN: Azure Role Assignment met te brede scope
{
  "roleDefinitionId": "/subscriptions/SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
  "scope": "/subscriptions/SUBSCRIPTION_ID",
  "principalId": "PRINCIPAL_ID"
}
// Dit is de Contributor-role op subscription-niveau.
// De service principal heeft schrijfrechten op ALLE resources in de subscription.

IB Tip: Gebruik \begin{lstlisting}[language=json] in het LaTeX-uitwerkingsveld van je finding om JSON-policies met syntax highlighting in het rapport op te nemen. De LaTeX-toolbar in IB biedt directe toegang tot code block-opmaak.

Resource ARN/URI’s als Evidence

Elke cloud-resource heeft een uniek adres. In AWS is dat een ARN (Amazon Resource Name). In Azure is dat een Resource ID. In GCP is dat een Resource URI. Deze adressen zijn de “locatie” van je finding en moeten nauwkeurig worden gedocumenteerd.

# AWS ARN-formaat
arn:aws:s3:::corp-backup-prod
arn:aws:iam::123456789012:role/AdminRole
arn:aws:ec2:eu-west-1:123456789012:instance/i-0abc123def456

# Azure Resource ID-formaat
/subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-prod/providers/Microsoft.Storage/storageAccounts/corpbackup

# GCP Resource URI-formaat
//storage.googleapis.com/corp-backup-prod
//compute.googleapis.com/projects/PROJECT_ID/zones/europe-west1-b/instances/vm-prod-01

Gebruik het locatie-veld in IB voor het ARN/URI. Dit veld wordt opgenomen in het rapport en maakt het voor het IT-team direct duidelijk welke resource moet worden aangepast.

Reproductiestappen

Elke finding moet reproductiestappen bevatten. In de cloud zijn die stappen bijna altijd CLI-commando’s:

# Reproductiestappen voor finding C-01: Publiek toegankelijke S3 bucket

# Stap 1: Ontdekking van de bucket via ScoutSuite
scout aws --services s3

# Stap 2: Verificatie van publieke toegang
aws s3 ls s3://BUCKET_NAME --no-sign-request

# Stap 3: Bevestiging van data-lekkage
aws s3 cp s3://BUCKET_NAME/klantdata.csv /tmp/ --no-sign-request

# Stap 4: Analyse van bucket policy
aws s3api get-bucket-policy --bucket BUCKET_NAME

De --no-sign-request vlag is cruciaal hier. Het bewijst dat de bucket toegankelijk is zonder authenticatie – een belangrijk verschil met een bucket die toegankelijk is voor authenticated users.

12.4 CVSS 4.0 voor Cloud

CVSS 4.0-scoring voor cloud-bevindingen vereist een andere kijk dan voor on-premise bevindingen. De attack vectors, de complexiteit en de impact-modellen zijn fundamenteel anders.

Attack Vector in de cloud

Attack Complexity in de cloud

Cloud-aanvallen scoren vaak Low op Attack Complexity, omdat misconfiguraties deterministisch zijn. Een publieke S3 bucket is altijd publiek. Een overprivileged policy is altijd overprivileged. Er is geen race condition, geen specifieke timing, geen afhankelijkheid van netwerkpositie.

Uitzonderingen:

• High wanneer de aanval afhankelijk is van specifieke condities die niet onder controle van de aanvaller zijn (bijv. een Lambda-functie die alleen op bepaalde tijden draait)
• High wanneer cross-account escalatie meerdere stappen en specifieke trust-configuraties vereist

Privileges Required in de cloud

Dit is waar cloud-scoring subtiel wordt:

Scope Change: Subsequent System Impact

De Subsequent System Impact metrics in CVSS 4.0 zijn bijzonder relevant voor cloud-bevindingen. Een gecompromitteerde IAM-rol heeft impact op het kwetsbare systeem (de rol zelf), maar de werkelijke schade zit in de downstream systemen die via die rol bereikbaar zijn.

Voorbeeld: Een overprivileged Lambda execution role.

Vulnerable System Impact:
  VC: None (de Lambda-functie zelf bevat geen gevoelige data)
  VI: None (de Lambda-code is niet gewijzigd)
  VA: None (de Lambda-beschikbaarheid is niet aangetast)

Subsequent System Impact:
  SC: High (via de role zijn alle S3 buckets leesbaar)
  SI: High (via de role zijn IAM policies wijzigbaar)
  SA: High (via de role kunnen resources worden verwijderd)

De CVSS-score stijgt aanzienlijk door de Subsequent System Impact, en dat is terecht. De Lambda-functie is niet het probleem – de rechten die eraan zijn gekoppeld zijn het probleem.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H

IB Tip: De CVSS 4.0-calculator in IB presenteert Vulnerable System Impact en Subsequent System Impact als aparte secties. Vul ze onafhankelijk in. Het is gebruikelijk voor cloud-findings om lage scores te hebben op het kwetsbare systeem en hoge scores op downstream systemen. De calculator berekent de uiteindelijke score correct op basis van beide.

12.5 Compliance Mapping

Waarom compliance mapping

Een pentest-rapport dat alleen bevindingen bevat is nuttig. Een pentest-rapport dat bevindingen mapt naar compliance-frameworks is bruikbaar. Het verschil is dat het tweede rapport de opdrachtgever in staat stelt om bevindingen direct te koppelen aan hun audit-verplichtingen, risicomanagement-processen en governance-structuren.

Het is ook – laten we eerlijk zijn – het verschil tussen een rapport dat in een la verdwijnt en een rapport dat op de agenda van het eerstvolgende managementoverleg komt. Want niets motiveert een organisatie sneller om iets te fixen dan de mededeling dat het een compliance-schending is.

CIS Benchmarks

Het Center for Internet Security (CIS) publiceert gedetailleerde hardening-benchmarks voor AWS, Azure en GCP. Het zijn de meest concrete, de meest actionable, en de meest gebruikte compliance-standaarden voor cloudbeveiliging.

De CIS Benchmarks zijn georganiseerd in secties die direct mappen op de drie lagen van cloud-rapportage:

CIS AWS Foundations Benchmark v3.0:

CIS Azure Foundations Benchmark v2.1:

CIS Google Cloud Foundations Benchmark v2.0:

SOC 2

SOC 2 is een audit-framework dat zich richt op vijf Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, en Privacy. Het is bijzonder relevant voor cloud-dienstverleners en SaaS-bedrijven.

Cloud pentest-bevindingen mappen als volgt naar SOC 2:

ISO 27001 en NEN 7510

ISO 27001 is de internationale standaard voor informatiebeveiliging. NEN 7510 is de Nederlandse vertaling en uitbreiding, specifiek gericht op de gezondheidszorg. Beide zijn relevant voor Nederlandse organisaties die cloud-diensten gebruiken.

De mapping van cloud-bevindingen naar ISO 27001 Annex A-controls:

Compliance mapping in het rapport

Voeg aan elke finding een compliance-referentie toe. Dit is een klein beetje extra werk dat een enorm verschil maakt voor de bruikbaarheid van je rapport.

In IB kun je compliance-referenties opnemen in het uitwerkingsveld van een finding:

\subsubsection{Compliance impact}
\begin{itemize}
\item CIS AWS Foundations Benchmark v3.0: Control 2.1.1 -- FAIL
\item SOC 2 Trust Service Criteria: CC6.6, CC6.7 -- Non-conformity
\item ISO 27001:2022: A.8.24 -- Non-conformity
\end{itemize}

IB Tip: Maak een standaard compliance-tabel template die je kopieert naar elke finding. Dit bespaart tijd en zorgt voor consistentie. Het standard_findings.json-bestand in IB kan worden uitgebreid met compliance-referenties per finding type.

12.6 Automatische Compliance Scanning

ScoutSuite

ScoutSuite is een multi-cloud security auditing tool die de configuratie van AWS, Azure en GCP scant tegen best practices en CIS Benchmark-controles. Het genereert een HTML-rapport dat je als bijlage aan je pentest-rapport kunt toevoegen.

# AWS scan
scout aws --profile target-account --regions eu-west-1,eu-central-1

# Azure scan
scout azure --cli

# GCP scan
scout gcp --project-id PROJECT_ID

# Met specifieke rule set
scout aws --profile target-account --ruleset cis-2.0

ScoutSuite organiseert bevindingen per service (IAM, EC2, S3, RDS, etc.) en geeft elk een severity-label (danger, warning, info). De HTML-output is interactief – je kunt per service inzoomen op individuele findings.

Hoe ScoutSuite-output te interpreteren voor je rapport:

ScoutSuite-bevindingen zijn observaties, geen bevindingen. Een ScoutSuite “danger” is niet automatisch een pentest-finding. Je moet context toevoegen: is deze misconfiguratie exploitable? Wat is de werkelijke impact? Is er compenserende controle die het risico mitigeert?

Een S3 bucket die door ScoutSuite als “publicly accessible” wordt gemarkeerd, bevat misschien alleen openbare documenten die bewust publiek zijn. Dat is geen finding. Dezelfde bucket met klantgegevens is een kritieke finding. Dat onderscheid maakt ScoutSuite niet – dat maak jij.

# ScoutSuite output analyseren
# De resultaten staan in scoutsuite-report/scoutsuite-results/
cat scoutsuite-report/scoutsuite-results/scoutsuite_results_*.json | \
  python3 -c "
import json, sys
data = json.load(sys.stdin)
for service in data.get('services', {}):
    findings = data['services'][service].get('findings', {})
    for fid, f in findings.items():
        if f.get('flagged_items', 0) > 0:
            print(f'{service}: {fid} ({f[\"flagged_items\"]} items)')
"

Prowler

Prowler is specifiek ontworpen voor AWS en Azure en heeft een sterkere focus op CIS Benchmarks dan ScoutSuite. Het genereert output in meerdere formaten (CSV, JSON, HTML) en ondersteunt directe integratie met AWS Security Hub.

# AWS CIS Benchmark scan
prowler aws --compliance cis_3.0 --region eu-west-1

# Azure CIS Benchmark scan
prowler azure --compliance cis_2.1

# Output in JSON voor verdere verwerking
prowler aws --compliance cis_3.0 -M json -F prowler_results

Prowler-output bevat per controle een PASS/FAIL-status, de betreffende resource-ARN, en een aanbeveling. Dit mapt rechtstreeks naar CIS Benchmark-controles en is daarmee ideaal voor compliance-rapportage.

Output interpreteren

De kunst van compliance scanning is niet het draaien van de tool – dat kan iedereen. De kunst is het interpreteren van de resultaten. Hier zijn de valkuilen:

Valkuil 1: Alles is een finding. ScoutSuite en Prowler genereren samen honderden observaties. Niet elke observatie is een finding, en niet elke finding hoort in je rapport. Filter op werkelijke impact en context.

Valkuil 2: Niets is een finding. Het andere uiterste: de tool rapporteert “PASS” op een controle, dus het is veilig. Maar de tool controleert configuratie, niet exploiteerbaarheid. Een security group die poort 443 openlaat naar het internet is een “PASS” voor sommige tools, maar als de webapplicatie achter die poort een SSRF-kwetsbaarheid heeft, is het alsnog een probleem.

Valkuil 3: Copy-paste rapportage. Het verleidelijkste en tegelijkertijd het meest destructieve: de tool-output direct in je rapport plakken als bevindingen. Dat is geen pentest-rapport; dat is een scan-rapport. En een scan-rapport kan de klant zelf genereren zonder een pentester in te huren. Je toegevoegde waarde zit in de analyse, niet in de output.

IB Tip: Gebruik ScoutSuite en Prowler als reconnaissance-tools, niet als rapportage-tools. Draai ze vroeg in je engagement om een overzicht te krijgen van de cloud-configuratie. Gebruik de resultaten om je handmatige testing te focussen. Documenteer relevante findings als IB-findings met eigen analyse en context.

12.7 Aanbevelingen Schrijven

Cloud-specifieke remediation

Cloud-aanbevelingen zijn fundamenteel anders dan on-premise aanbevelingen. In de on-premise wereld is een aanbeveling vaak “patch dit systeem” of “wijzig deze Group Policy”. In de cloud is een aanbeveling een combinatie van policy-wijzigingen, configuratie-aanpassingen, en architectuurverbeteringen.

IAM-aanbevelingen

Het meest voorkomende type aanbeveling in een cloud-rapport. Structureer ze als volgt:

### Aanbeveling: Implementeer principle of least privilege voor IAM

**Korte termijn (binnen 1 week):**
- Verwijder de `AdministratorAccess` policy van de service account
  `arn:aws:iam::ACCOUNT_ID:user/svc-deploy`
- Vervang door een custom policy die alleen de benodigde acties toestaat:

​```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::deployment-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "lambda:UpdateFunctionCode"
      ],
      "Resource": "arn:aws:lambda:eu-west-1:ACCOUNT_ID:function:app-*"
    }
  ]
}
​```

**Middellang termijn (binnen 1 maand):**
- Implementeer IAM Access Analyzer om unused permissions te identificeren
- Configureer Permission Boundaries voor alle IAM users en roles
- Roteer alle Access Keys ouder dan 90 dagen

**Lang termijn (binnen 3 maanden):**
- Migreer van IAM users met Access Keys naar IAM roles met
  temporary credentials via AWS SSO (Identity Center)
- Implementeer just-in-time access via AWS SSO permission sets

Service Control Policies (AWS) / Conditional Access (Azure) / Organization Policies (GCP)

De krachtigste verdedigingsmechanismen in de cloud zijn de governance-tools op het hoogste niveau:

// AWS: SCP die bepaalde acties blokkeert voor alle accounts in de organization
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCloudTrailDisable",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

// Azure: Conditional Access policy (conceptueel)
{
  "displayName": "Require MFA for all admin roles",
  "conditions": {
    "users": {
      "includeRoles": [
        "Global Administrator",
        "Security Administrator",
        "Exchange Administrator"
      ]
    },
    "applications": {
      "includeApplications": ["All"]
    }
  },
  "grantControls": {
    "builtInControls": ["mfa"]
  }
}

VPC/NSG-aanbevelingen

Netwerkconfiguratie in de cloud is minder complex dan on-premise (geen VLAN-trunking, geen spanning tree), maar de principes zijn hetzelfde: minimale toegang, segmentatie, en monitoring.

# AWS: Security group audit -- vind overly permissive rules
aws ec2 describe-security-groups \
  --query "SecurityGroups[?IpPermissions[?contains(IpRanges[].CidrIp, '0.0.0.0/0')]].[GroupId,GroupName]" \
  --output table

# Azure: NSG audit -- vind regels met Any-source
az network nsg list --query "[].{Name:name, Rules:securityRules[?sourceAddressPrefix=='*']}" -o table

Aanbevelingen voor netwerkconfiguratie:

• Verwijder alle 0.0.0.0/0 inbound rules behalve waar strikt noodzakelijk (publieke load balancers)
• Gebruik security group references in plaats van CIDR-blokken waar mogelijk
• Implementeer VPC Flow Logs (AWS), NSG Flow Logs (Azure), of VPC Flow Logs (GCP)
• Gebruik Private Endpoints / VPC Endpoints voor services die geen publieke toegang nodig hebben

Prioritering van aanbevelingen

Gebruik een tijdsgebonden prioritering die past bij de urgentie van de bevinding:

IB Tip: Gebruik het aanbeveling-veld in IB finding templates voor gestructureerde remediation-stappen. De prioriteit kan worden afgeleid uit de CVSS-score: Critical (P1), High (P2), Medium (P3), Low (P4), Informational (P5).

12.8 Het Rapport Genereren met IB

Findings invoeren

De workflow voor het invoeren van cloud-findings in IB is identiek aan die in de voorgaande delen, met enkele cloud-specifieke aandachtspunten:

1. Selecteer of maak een template

Gebruik de cloud-specifieke finding templates (publieke storage, overprivileged IAM, ontbrekende logging, etc.) of maak een custom template aan voor bevindingen die niet in de standaard set zitten.

2. Vul het finding-formulier in

• Naam: Specifiek en beschrijvend. Niet “S3 misconfiguratie” maar “Publiek toegankelijke S3 bucket corp-backup-prod met klantgegevens.”
• Host/Locatie: Het resource ARN, URI, of een beschrijvende identifier. arn:aws:s3:::corp-backup-prod of subscription/rg-prod/storageaccount/corpbackup.
• CVSS 4.0: Gebruik de interactieve calculator. Let op het verschil tussen Vulnerable System Impact en Subsequent System Impact.
• Uitwerking: De technische details, inclusief CLI-commando’s, policy-fragmenten, en compliance mapping. Gebruik LaTeX-opmaak voor het rapport.

3. Upload evidence

Screenshots van de console, CLI-output als tekstbestanden, JSON-exports van policies, ScoutSuite-fragmenten.

# Evidence uploaden via curl
curl -X POST -F "file=@s3_public_access.png" \
  http://127.0.0.1:5000/api/findings/1/evidence

curl -X POST -F "file=@iam_policy_analysis.json" \
  http://127.0.0.1:5000/api/findings/1/evidence

curl -X POST -F "file=@scoutsuite_s3_danger.png" \
  http://127.0.0.1:5000/api/findings/1/evidence

Cloud-templates

De standaard finding templates in IB’s standard_findings.json bevatten web-georiënteerde templates. Voor cloud-pentests breid je deze uit met cloud-specifieke templates. Een cloud finding template bevat dezelfde velden als een standaard template:

{
  "standard_code": "CLOUD-IAM-001",
  "titel": "Overprivileged IAM Identity",
  "type": "Cloud - Identity & Access Management",
  "cwe": "CWE-250",
  "owasp": "A01:2021 - Broken Access Control",
  "mitre_attack": "T1078.004",
  "cvss_vector": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
  "basescore": "9.3",
  "beschrijving_nl": "Een of meer IAM-identiteiten (users, roles, of service principals) in de cloud-omgeving beschikken over meer rechten dan noodzakelijk voor hun functie. Dit maakt het mogelijk dat een aanvaller die deze identiteit compromitteert directe toegang heeft tot alle resources in het account, inclusief gevoelige data en configuratie-instellingen.",
  "impact_nl": "Een aanvaller die een overprivileged identiteit compromitteert kan direct alle data lezen, wijzigen of verwijderen binnen de scope van die rechten. Bij een wildcard policy (Action: *, Resource: *) omvat dit het volledige cloud-account inclusief IAM-configuratie, waardoor persistentie en verdere escalatie triviaal worden.",
  "aanbeveling_nl": "Implementeer principle of least privilege: beperk IAM policies tot de minimaal benodigde acties en resources. Gebruik AWS IAM Access Analyzer, Azure PIM, of GCP IAM Recommender om ongebruikte rechten te identificeren. Implementeer Permission Boundaries (AWS), Conditional Access (Azure), of Organization Policy Constraints (GCP) als bovengrenzen."
}

LaTeX-generatie

IB’s rapportgenerator verwerkt cloud-findings via dezelfde pipeline als alle andere findings: LaTeX-generatie, HTML-conversie, pandoc naar Markdown. De cloud-specifieke elementen (ARN’s, JSON-policies, compliance-referenties) worden opgenomen via het uitwerkingsveld.

Voorbeeld LaTeX-uitwerking voor een cloud-finding:

De S3 bucket \texttt{corp-backup-prod} (ARN: \texttt{arn:aws:s3:::corp-backup-prod})
is publiek toegankelijk. Block Public Access is volledig uitgeschakeld en de bucket
policy staat leestoegang toe voor alle principals.

\begin{lstlisting}[language=bash]
# Verificatie van publieke toegang
aws s3 ls s3://corp-backup-prod --no-sign-request
# Output: 2026-02-20 14:32:01 klantdata_2026.csv
# Output: 2026-02-20 14:32:15 financieel_rapport_q4.xlsx
\end{lstlisting}

\plaatje{s3_public_access}{S3 bucket met Block Public Access uitgeschakeld}

\subsubsection{Compliance impact}
\begin{itemize}
\item CIS AWS Foundations Benchmark v3.0: Control 2.1.1 -- FAIL
\item SOC 2 CC6.6 -- Non-conformity
\item AVG Artikel 32 -- Onvoldoende technische maatregelen
\end{itemize}

Navigeer naar /dashboard/findings en klik op Generate report. IB genereert drie bestanden:

rapport/
  findings_nl.tex    # Ruwe LaTeX
  tex.html           # HTML-tussenvorm
  tex.md             # Markdown-eindresultaat

Converteer naar PDF:

cd rapport/
pandoc tex.md -o cloud_pentest_rapport.pdf \
  --pdf-engine=xelatex \
  --template=eisvogel \
  -V geometry:margin=2.5cm \
  -V colorlinks=true

IB Tip: Voeg de ScoutSuite HTML-output toe als bijlage aan het rapport. Dit geeft de opdrachtgever een gedetailleerd overzicht van alle gecontroleerde configuratie-items, inclusief de items die correct zijn geconfigureerd. Het geeft completheid aan het rapport zonder het hoofddocument op te blazen.

12.9 Na het rapport

Debriefing

De debrief is crucialer bij cloud-pentests dan bij on-premise pentests, om een simpele reden: cloud-misconfiguraties zijn vaak sneller te fixen, maar de organisatie moet begrijpen waarom iets mis is voordat ze het fixen. Anders fixen ze het symptoom en niet de oorzaak, en staat dezelfde misconfiguratie er volgende week weer – aangemaakt door een deployment pipeline die niet is aangepast.

Structureer de debriefing in twee sessies:

Sessie 1: Management (30 minuten) - De drie tot vijf kernbevindingen in business-taal - De overkoepelende risico-beoordeling - Strategische aanbevelingen - Compliance-implicaties - Budget en tijdsinschatting voor remediation

Sessie 2: Technisch team (60 minuten) - Gedetailleerde doorloop van alle bevindingen - Live demonstratie van exploitatie (in het lab, niet in productie) - Specifieke remediation-stappen met CLI-commando’s en policy-voorbeelden - Q&A over implementatie

De splitsing is bewust. Een management-sessie waar een engineer live een IAM-escalatie demonstreert bereikt precies het tegenovergestelde van wat je wilt: het management voelt zich geintimideerd en incompetent, en het technische team voelt zich tentoongesteld. Gescheiden sessies geven elk publiek wat het nodig heeft.

Retesting

Plan de retest vier tot zes weken na oplevering van het rapport. Cloud-retesting is efficienter dan on-premise retesting, omdat je veel controles kunt automatiseren:

# Retest: Is de S3 bucket nog steeds publiek?
aws s3 ls s3://corp-backup-prod --no-sign-request 2>&1
# Verwachte output na fix: An error occurred (AccessDenied)

# Retest: Is de overprivileged policy aangepast?
aws iam get-policy-version \
  --policy-arn arn:aws:iam::ACCOUNT_ID:policy/LegacyAdminPolicy \
  --version-id $(aws iam get-policy --policy-arn arn:aws:iam::ACCOUNT_ID:policy/LegacyAdminPolicy --query 'Policy.DefaultVersionId' --output text)

# Retest: Is CloudTrail nu ingeschakeld in alle regio's?
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo -n "$region: "
  aws cloudtrail describe-trails --region $region --query 'trailList[].Name' --output text
done

# Retest: Is MFA nu afgedwongen?
aws iam list-users --query 'Users[].UserName' --output text | \
  while read user; do
    mfa=$(aws iam list-mfa-devices --user-name "$user" --query 'MFADevices[].SerialNumber' --output text)
    if [ -z "$mfa" ]; then
      echo "FAIL: $user -- geen MFA"
    else
      echo "PASS: $user -- MFA actief"
    fi
  done

Documenteer de retest-resultaten in een kort rapport met status per bevinding:

IB Tip: Importeer de findings uit het originele project in een nieuw IB-project voor de retest. Gebruik de export/import-functionaliteit (/api/findings/export en /dashboard/findings/import) om de originele findings als referentie te laden.

Continuous Monitoring Advies

Een pentest is een momentopname. De cloud verandert continu – resources worden aangemaakt, configuraties worden gewijzigd, nieuwe gebruikers worden toegevoegd. Het advies dat je geeft over continuous monitoring is vaak waardevoller dan de bevindingen zelf.

Aanbevolen monitoring-stack per provider:

AWS: - AWS Config Rules voor continue configuratie-evaluatie - AWS Security Hub voor geaggregeerde bevindingen van GuardDuty, Inspector, en Config - CloudTrail + CloudWatch Alarms voor verdachte API-calls - AWS IAM Access Analyzer voor ongebruikte rechten en publieke/cross-account toegang

Azure: - Microsoft Defender for Cloud met Secure Score tracking - Azure Policy voor compliance-afdwinging - Azure Activity Log + Log Analytics voor monitoring - Entra ID Identity Protection voor risico-gebaseerde detectie

GCP: - Security Command Center (SCC) voor gecentraliseerde bevindingen - Organization Policies voor preventieve controles - Cloud Audit Logs + Cloud Monitoring voor detectie - IAM Recommender voor least privilege-suggesties

# AWS: Snel overzicht van Security Hub findings
aws securityhub get-findings \
  --filters '{"SeverityLabel": [{"Value": "CRITICAL", "Comparison": "EQUALS"}]}' \
  --query 'Findings[].{Title:Title, Resource:Resources[0].Id}' \
  --output table

# Azure: Defender for Cloud secure score
az security secure-scores list --query "[].{Name:name, Score:properties.score.current}" -o table

# GCP: Security Command Center findings
gcloud scc findings list ORGANIZATION_ID \
  --filter="severity=\"CRITICAL\"" \
  --format="table(finding.category, finding.resourceName)"

Het ultieme doel is dat de organisatie niet meer afhankelijk is van jaarlijkse pentests om hun beveiligingsniveau te kennen. Continuous monitoring maakt het mogelijk om misconfiguraties te detecteren en te corrigeren voordat een aanvaller ze vindt – of voordat de volgende pentester ze in zijn rapport zet.

Maar laten we eerlijk zijn: de meeste organisaties zullen die monitoring-stack opstellen, er drie maanden naar kijken, en hem vervolgens vergeten. De alerts komen nog steeds binnen, maar niemand leest ze meer. Het dashboard staat open in een browsertabblad dat langzaam naar achteren wordt geschoven door productievere tabbladen. En volgend jaar komt dezelfde pentester, vindt dezelfde dingen, schrijft hetzelfde rapport, en de cyclus herhaalt zich.

Het is het equivalent van een rookmelder die al maanden piept omdat de batterij leeg is, maar die niemand vervangt omdat het geluid inmiddels deel uitmaakt van de achtergrondgeluiden van het kantoor.

En toch blijven we rapporten schrijven. Omdat het alternatief – niet testen, niet rapporteren, niet adviseren – erger is. Omdat elke keer dat een rapport wel wordt gelezen, wel wordt geimplementeerd, en wel tot een betere configuratie leidt, het de moeite waard is geweest.

Schrijf het rapport alsof het ertoe doet. Want soms doet het dat.

Referentietabel Hoofdstuk 12