Checklist - Tester

---

1. Scope en Omvang

1.1 Subscripties, Resource Groups en Regio’s

• 1.1.1: Welke Azure-subscripties vallen expliciet binnen de scope (productie, test, dev)?

  • Overzicht genereren van alle subscriptions (bijv. via Get-AzSubscription).

  • Bepalen of er extra (trial)subscripties bestaan.

  • Inzicht of dev/test-subscripties dienen als “playground” voor diepgaandere scans.

• 1.1.2: Welke resource groups zijn van kritisch belang of bevatten gevoelige data?

  • Vragen over RG’s met namen als ‘Production’, ‘Finance’, ‘HR’, etc.

  • Mapping van resource groups naar workloads (VM’s, databases, etc.).

  • Prioriteer (High/Medium/Low sensitivity) en bepaal diepgang per RG.

• 1.1.3: In welke regio(‘s) draaien de resources en is er sprake van geo-redundantie?

  • Overzicht van multiregionale deployments (West Europe, North Europe, buiten EU).

  • Nagaan of data residency-eisen (AVG/GDPR) gelden.

  • Bepalen of multiregionale failover extra testcomplexiteit geeft.

• 1.1.4: Is er een overkoepelend Azure Management Group-structuur met beleid (Policies)?

  • Check welke Azure Policies op root-level actief zijn.

  • Inzicht in eventuele Resource Locks en of die de pentest beperken.

• 1.1.5: Welke gedelegeerde (cross-tenant) of B2B-relaties bestaan tussen tenants?

  • Kijken of Azure AD B2B of resource sharing plaatsvindt.

  • Vaststellen of “Guest Access” is toegestaan en of andere tenants meedoen in de pentest.

1.2 Uitsluitingen en Bijzondere Verzoeken

• 1.2.1: Welke (zeer) bedrijfskritieke systemen moeten uitgesloten worden of alleen oppervlakkig getoetst?

  • Vastleggen of Production-DB’s met live data enkel passief gescand worden.

  • Noteren van restricties (geen DDoS-tests, geen heavy scanning).

  • Eventuele fallback-routes in noodgevallen.

• 1.2.2: Zijn er externe (SaaS-)applicaties gekoppeld die expliciet buiten scope liggen?

  • Lijst van integraties (Slack, Salesforce, NetSuite via Azure AD).

  • Markeer welke wel/niet in de test opgenomen zijn.

• 1.2.3: Zijn er compliance-eisen die bepaalde testmethodes verbieden (destructieve exploits)?

  • Check of PCI-DSS, HIPAA of andere eisen destructieve tests uitsluiten.

  • Noteer contactgegevens compliance-officer.

  • Documenteer methodes die uitdrukkelijk niet mogen.

• 1.2.4: Mogen social engineering-tests (phishing, pretext-calls) ook onderdeel zijn?

  • Overwegen of phishing-simulaties in scope vallen.

  • Escalatielijnen bepalen (user confusion, reputatierisico).

• 1.2.5: Zijn er data-eigenaars of externe partners wier toestemming ook vereist is?

  • Controleren of sommige data door derde partijen beheerd wordt.

  • Zo nodig extra LoA (Letter of Authorization) organiseren.

---

2. Juridische Dekking en Engagementregels

2.1 Rules of Engagement (RoE)

• 2.1.1: Welke rapportagefrequentie verlangt men (dagelijks, wekelijks, alleen eindrapport)?

  • Bepaal wie tussentijdse updates ontvangt.

  • Leg vast of kritieke bevindingen meteen gemeld worden.

• 2.1.2: Mag de pentester exploit attempts tot op OS-niveau uitvoeren, of alleen passieve scans?

  • Overleg over mogelijke impact van actieve exploits.

  • Koppel intensievere tests aan specifieke tijdvensters (buiten werkuren).

  • Noteer fallback-scenario (stoppen bij storing).

• 2.1.3: Hoe omgaan met potentieel destructieve tests (DDoS, resource exhaustion, data corruptie)?

  • Bepaal of mini-DDoS-scenario mag en welk maximumverkeer.

  • Bepaal escalatieprotocol bij verstoring.

• 2.1.4: Wat zijn de communicatielijnen voor escalatie: wie is 24/7 bereikbaar?

  • Noteer belangrijke telefoonnummers en mailadressen (IT-beheer, CISO, directie).

  • Definieer escalatieladder bij kritieke incidenten.

• 2.1.5: Is er een juridisch document (LoA/MoU) waarin partijen instemmen met deze RoE?

  • Alle stakeholders ondertekenen (CIO, Security Officer).

  • Bewaar document veilig voor juridische zekerheid.

---

3. Azure AD – Identiteit en Toegang

3.1 Basisvragen over Azure AD-configuratie

• 3.1.1: Welke authenticatiemethode wordt gebruikt (Password Hash Sync, Pass-through, Federatie/ADFS)?

  • Check of AD FS-endpoints bestaan en SAML-config correct is.

  • Inventariseer eventueel claims-based SSO.

• 3.1.2: Worden gastaccounts (B2B/B2C) opgeruimd na inactiviteit?

  • Gast- of B2B-accounts kunnen extra risico vormen.

  • Koppel logs (Last Sign-In Date) en check Access Reviews.

• 3.1.3: Is MFA verplicht voor alle admins en high-priv users?

  • Inspecteer conditional access “Require MFA for Global Admins”.

  • Controleer of er uitzonderingen (‘break glass’ accounts) zijn.

  • Vraag naar gebruikte MFA-methoden (hardware tokens, push).

• 3.1.4: Is er een Default Conditional Access-blokkering voor legacy protocollen (POP, IMAP, SMTP)?

  • Legacy auth is een bekend MFA-bypass-risico.

  • Controleer in Azure Portal Security of dit actief is.

• 3.1.5: Gebruikt men Privileged Identity Management (PIM) voor Just-In-Time?

  • Check of admins permanent privileges hebben of alleen bij nood.

  • Inspecteer PIM-config en logging van escalatie.

---

4. Netwerk en Hybride Koppelingen

4.1 Virtual Networks en NSG’s

• 4.1.1: Welke subnetten zijn er en welke NSG’s zijn actief?

  • Let op Any/Any/Allow-regels.

  • Laat klant az network nsg list of Get-AzNetworkSecurityGroup uitvoeren.

  • Identificeer inbound policy’s die te ruim zijn.

• 4.1.2: Is er een Azure Firewall / WAF / App Gateway en hoe is die geconfigureerd?

  • Check of WAF rule sets (OWASP) actief zijn.

  • Inspecteer custom rules, whitelists, exclusions.

• 4.1.3: Is er een VPN- of ExpressRoute-verbinding naar on-prem?

  • Beoordeel of gecompromitteerde Azure-VM’s on-prem netwerken kunnen bereiken.

  • Inventariseer IP-ranges en route tables.

• 4.1.4: Geldt er DDoS Protection Standard op public IP’s?

  • Plan of mini-DDoS-tests gewenst zijn, hoe intens en wanneer.

  • Overleg testwindow en escalatie bij storing.

• 4.1.5: Maakt men gebruik van Private Link/Private Endpoint?

  • Check of storage accounts, databases en webapps alleen via privénetwerk bereikbaar zijn.

  • Loop endpoints langs (DNS, FQDN) en verifieer onbedoelde public endpoints.

---

5. Compute Services (VM's, Containers, PaaS)

5.1 Virtual Machines

• 5.1.1: Welke OS-versies draaien (Windows, Linux) en zijn ze up-to-date?

  • Nmap, Nessus, OpenVAS voor versiedetectie.

  • Laat klant patchmanagement toelichten.

  • Check LTS-versies of end-of-support OS.

• 5.1.2: OS-hardening: bestaat er een baseline (CIS, STIG), hoe strict is die?

  • Check of men securitycenter/hardening scripts inzet.

  • Evalueer Azure Policy gastconfig.

  • Noteer afwijkingen (RDP open op 0.0.0.0/0, etc.).

• 5.1.3: Wordt er gebruikgemaakt van Azure Arc of config management (Chef, Ansible)?

  • Inspecteer eventuele config-scripts of plaintext credentials.

  • Check TLS/SSL-communicatie tussen agents en servers.

• 5.1.4: Hoe is remote beheer geregeld: RDP/SSH, Bastion, JIT-toegang?

  • Controleer of poorten altijd open zijn of alleen bij JIT-requests.

  • Test scenario: Probeer RDP/SSH vanaf internet.

  • Evalueer Bastion en logging.

• 5.1.5: Zijn er bijzondere workloads (GPU, HPC) met eigen risico’s?

  • Noteer HPC-schedulers, RDMA-communicatie.

  • Controleer patching en security van HPC-nodes.

5.2 Containers (AKS, Container Instances)

• 5.2.1: Azure Kubernetes Service (AKS)

  • Check RBAC in Kubernetes (clusterrole=cluster-admin?).

  • Inspecteer network policies, Pod Security Policies.

  • Let op mogelijke container escapes.

• 5.2.2: Container Registry (ACR)

  • Is ACR publiek? Zijn er onbeveiligde images?

  • Scan images op bekende kwetsbaarheden.

  • Let op credentials in Dockerfiles.

• 5.2.3: Azure Container Instances (ACI)

  • Check of containers ‘anonymous’ endpoints hebben.

  • Inspecteer environment variables op plaintext secrets.

  • Bepaal toegangsrechten voor ACI-mgmt.

• 5.2.4: Azure Functions

  • Is de HTTP-trigger anoniem toegankelijk?

  • Probeer via Postman/cURL te zien of er auth-level=anonymous is.

  • Let op secrets in code.

• 5.2.5: App Services

  • Controleer TLS-instellingen (HTTPS Only), custom domain-binding.

  • Inspecteer Managed Identity, en let op plaintext credentials in web.config.

---

6. Data en Opslag

6.1 Azure Storage (Blob, File, Disk)

• 6.1.1: Zijn Blob-containers publiek toegankelijk (Public Access)?

  • Check “Blob service property” voor public access.

  • Voer fuzzy scans uit om open directories op te sporen.

• 6.1.2: Shared Access Signatures (SAS)

  • Welke rechten (rwld) en looptijd hebben SAS-tokens?

  • Test scenario: Probeer zogenaamd “expired SAS” alsnog te gebruiken.

• 6.1.3: Disk Encryption

  • Controleer Azure Disk Encryption (BitLocker/dm-crypt).

  • Inspecteer of SSE en BYOK actief zijn.

• 6.1.4: Cosmos DB

  • Firewall-enabled of publiek?

  • “Allow access from Azure services” te breed?

  • Let op keys in DevOps pipelines.

• 6.1.5: SQL Databases

  • Force TDE (Transparent Data Encryption) aan?

  • Azure AD auth i.p.v. SQL logins?

  • Firewall rules: “Allow all azure services” kan riskant zijn.

---

7. Logging, Monitoring en Incidentrespons

7.1 Logging en SIEM-integratie

• 7.1.1: Welke resource logs (Activity, Diagnostic, NSG Flow) worden verzameld?

  • az monitor diagnostic-settings list voor dekking.

  • Check logretentie (30, 90, 180 dagen?).

• 7.1.2: Is er integratie met Azure Sentinel of andere SIEM?

  • Overzicht van detectieregels (brute force, unusual sign-in, data exfil).

  • Test of Sentinel alarm genereert bij testaanval.

• 7.1.3: Microsoft Defender for Cloud (Security Center)

  • Security Score en aanbevelingen checken.

  • Autoprotect-enabled VMs?

  • Negeert men kritieke adviezen?

• 7.1.4: Azure AD Identity Protection

  • Herkent men leaked credentials of suspicious sign-in (snelle travel)?

  • Testscenario: “sign in from 2 continenten in 5 min”.

  • Observeer alerts in Security Center.

• 7.1.5: Incidentrespons-plan

  • Bestaan er playbooks (SOAR-stijl)?

  • Overzicht escalatiestappen (IT Manager, CISO).

  • E-mailnotificaties bij high-severity alerts?

---

8. Organisatorische en Governance Aspecten

8.1 DevOps en CI/CD

• 8.1.1: Welke DevOps-pipelines (Azure DevOps, GitHub, Jenkins) worden gebruikt?

  • Check of secrets in pipeline-variabelen plaintext staan.

  • Inspecteer logging: tokens in logs?

• 8.1.2: IaC (Terraform, Bicep, ARM)

  • Controleer drift detection en environment variables.

  • Let op embedded credentials in .tf of .json.

• 8.1.3: Change Management-procedures

  • Zijn wijzigingen formeel gekeurd (RFC, tickets)?

  • Noteer rollback-scenario’s.

• 8.1.4: Koppeling met code-repositories (Azure Repos, GitHub)

  • Zoek in repos (grep) naar connection strings, secrets.

  • Activeert men Git secrets scanning?

  • Let op onveilige commit-historie.

• 8.1.5: Test- en stagingomgevingen

  • Is staging openbaar bereikbaar?

  • Mogelijk simpele credentials (“Passw0rd”?).

  • Check of staging real prod-data bevat.

8.2 Governance en Security Policies

• 8.2.1: Azure Policy en Blueprints

  • Blokkeert men ongewenste configuraties (open RDP)?

  • Bekijk az policy assignment list voor compliance.

• 8.2.2: RBAC – Roltoewijzingen

  • Komt Contributor of Owner te vaak voor?

  • az role assignment list → let op wildcard roles.

  • Observeer custom roles met *-permissions.

• 8.2.3: Gebruik van Managed Identities

  • Hebben VM’s, App Services of Functions een managed identity en welke rechten?

  • Check logs op usage.

• 8.2.4: Security-overzichten, auditing

  • Maandelijkse “security board meetings” en interne audits?

  • Hoe verwerkt men bevindingen van Security Center?

  • Is er een open issues register?

• 8.2.5: Training en awareness

  • Krijgen beheerders en developers Azure-security training?

  • Check of men op de hoogte is van nieuwe features.

  • Stimuleer “Security Champions”.

---

9. Escalatie, Rapportage en Nazorg

9.1 Escalaties bij Kritieke Bevindingen

• 9.1.1: Directe melding

  • Bij een “Critical” exploit (Key Vault compromise) direct melden?

  • Formuleer richtlijnen (mail, telefoon, Teams) en reactietijd (bijv. max 1 uur).

• 9.1.2: Stoppen van de test bij storing

  • Definieer “HALT test”-afspraak bij ernstige outages.

  • Documenteer reden en logs van verstoring.

• 9.1.3: Realtime vs. eindrapport

  • Wekelijkse short summary of alleen eindpresentatie?

  • Bepaal NDA-scope voor tussentijdse bevindingen.

9.2 Eindrapport en Actieplan

• 9.2.1: Structuur van het rapport

  • Executive summary vs. diep technisch deel.

  • Koppeling findings aan ISO 27001 / NIST / best practices.

  • CVSS-scores per bevinding.

• 9.2.2: Prioriteren van bevindingen (High/Med/Low)

  • Quick wins en lange-termijnadviezen.

  • Omschrijf benodigde tijd, middelen en stel KPI’s (bv. 30 dagen fix van High).

9.3 Validatie en Retesting

• 9.3.1: Plan voor hertest

  • Kan de pentester direct na patching hertesten?

  • Reserveer budget, tijd en leg vast in contract.

• 9.3.2: Nazorg en forensische readiness

  • Adviseer logging-retentie, forensische tools.

  • Koppel bevindingen aan incidentrespons-plan.

  • Overweeg forensische experts bij ernstige incidenten.

• 9.3.3: Continue verbetering

  • Moedig periodieke scans en interne audits aan.

  • Integreer Cloud Security Posture Management (CSPM).

  • Monitor Azure Security Score en DevSecOps-pipelines.

---

Conclusie

Met deze checklist kun je als klant en de pentester samen bepalen:

• Welke resources worden getest (subscriptions, resource groups, regio’s),

• Welke methoden zijn toegestaan (passief, actief, destructief),

• Welke compliance-eisen gelden (GDPR, PCI, HIPAA),

• Hoe logging en incidentrespons is ingericht (SIEM, Sentinel, Security Center),

• Hoe DevOps en governance zijn geregeld (IaC, RBAC, Policy’s),

• En hoe de rapportage, escalatie en nazorg worden vormgegeven.

Door deze lijst stap voor stap te doorlopen, ben je verzekerd van een compleet, veilig en juridisch verantwoord pentesttraject in Azure, met als eindresultaat een concreet verbeterplan om de cloudomgeving nog sterker te beveiligen. Veel succes met het voorbereiden van je Azure Cloud Pentest!