Checklist - Klant

CHECKLIST: Voorbereiding op een Azure Cloud Pentest

Gebruik deze lijst om stap voor stap af te vinken welke informatie je als klant kunt aanleveren vóór de pentest.

---

Inleiding

Deze checklist helpt je om alle relevante details omtrent jouw Azure-omgeving te verzamelen vóórdat de pentest begint. Door deze stappen te doorlopen:

1. Bepaal je precies wat er getest wordt (scope en resources).

2. Zorg je voor de juridische kaders (Rules of Engagement, autorisaties).

3. Maak je inzichtelijk hoe Azure AD, netwerken, VM’s/containers en data zijn geconfigureerd.

4. Definieer je logging en incidentrespons (SIEM, Sentinel, Security Center).

5. Regel je governance en DevOps-aspecten (zoals RBAC, IaC, pipelines).

6. Leg je vast hoe escalatie, rapportage en nazorg verlopen.

Zo ontstaat een volledig en helder beeld, waarmee de pentester jou de meest waardevolle inzichten kan geven.

---

1. Scope en Omvang

1.1 Subscripties, Resource Groups en Regio’s

1. Azure-subscripties in scope

   • Waarom: Dit bepaalt welke omgevingen (production, test, dev) onderzocht mogen worden.

   • Check:

     • Laat een actueel overzicht genereren (bijv. Get-AzSubscription).

     • Zijn er extra/trial-subscripties die je wilt meenemen of uitsluiten?

     • Wil je dev/test als ‘speelveld’ gebruiken voor intensievere tests?

2. Resource groups met (kritieke) data

   • Waarom: Sommige RG’s bevatten gevoelige workloads (bijv. financiële data, HR).

   • Check:

     • Maak een mapping van resource groups naar bijbehorende VM’s, databases, etc.

     • Bepaal prioriteitsniveaus (High/Medium/Low).

     • Overleg of alle RG’s even diep getest mogen worden.

3. Regio’s en geo-redundantie

   • Waarom: Azure-regio’s hebben verschillende data residency-eisen (AVG/GDPR). Ook kan er sprake zijn van geo-redundantielatentie.

   • Check:

     • In welke regio(’s) draaien de resources? (EU, buiten de EU?)

     • Zijn er compliance-regels voor die regio’s?

     • Heeft failover/latentie impact op de test?

4. Management Groups en Policies

   • Waarom: Op root-level kunnen strikte policies of resource locks actief zijn, die de pentest kunnen inperken.

   • Check:

     • Kennis van Azure Policies op management group-niveau?

     • Zijn Resource Locks ingeschakeld (geen deletes mogelijk)?

5. Cross-tenant / B2B-relaties

   • Waarom: Azure AD B2B en gedelegeerde resources kunnen de scope sterk beïnvloeden

   • Check:

     • Heb je “Guest Access” in management groups?

     • Delen andere tenants resources die je wilt laten meepentesten?

1.2 Uitsluitingen en Bijzondere Verzoeken

1. Kritieke systemen uitgesloten?

   • Waarom: Zeer gevoelige of bedrijfskritieke systemen kunnen soms alleen oppervlakkig worden gescand.

   • Check:

     • Is bijvoorbeeld een Production-DB met live data alleen passief te scannen?

     • Noteer eventuele restricties (geen DDoS, geen heavy scanning).

     • Stel een fallback-route in voor noodgevallen.

2. Externe (SaaS-)applicaties

   • Waarom: Integraties met Slack, Salesforce, etc. kunnen je Azure-tenant raken.

   • Check:

     • Maak een lijst van alle third-party koppelingen.

     • Markeer welke apps je wel/niet in scope wilt hebben.

3. Compliance-beperkingen

   • Waarom: In PCI-DSS- of HIPAA-omgevingen kunnen destructieve tests verboden zijn.

   • Check:

     • Wie is de compliance-officer?

     • Documenteer methodes die niet mogen (packet injection, protocol fuzzing).

4. Social engineering-tests

   • Waarom: Phishing en pretext-calls kunnen Azure AD-accounts blootleggen.

   • Check:

     • Wil je dat phishingcampagnes onderdeel zijn van de pentest?

     • Regel escalatielijnen voor user confusion.

5. Data-eigenaars of partners

   • Waarom: Is data mogelijk eigendom van derden, en is hun toestemming vereist?

   • Check:

     • Contractuele verplichtingen in kaart.

     • Organiseer zo nodig extra LoA (Letter of Authorization).

---

2. Juridische Dekking en Engagementregels

2.1 Rules of Engagement (RoE)

1. Rapportagefrequentie

   • Waarom: Sommigen willen dagelijkse updates, anderen alleen een eindrapport.

   • Check:

     • Bepaal wie tussentijds updates ontvangt.

     • Meld kritieke bevindingen meteen?

2. Omvang exploit attempts

   • Waarom: Is diepgaande exploit op OS-level toegestaan of alleen passieve scans?

   • Check:

     • Impact/urgentie bespreken.

     • Testen koppelen aan specifieke tijdvensters (buiten werkuren?).

3. Destructieve tests (DDoS/resource exhaustion)

   • Waarom: Een mini-DDoS-simulatie kan de service verstoren.

   • Check:

     • Is het toegestaan? Welke maximum bandbreedte?

     • Hoe escaleren we bij storing?

4. Communicatie bij escalaties

   • Waarom: Bij kritieke incidenten moet je direct weten wie te bellen of mailen.

   • Check:

     • Telefoonnummers/e-mails van IT-beheer, CISO, directie.

     • Escalatieladder bij ernstige incidenten.

5. Letter of Authorization (LoA/MoU)

   • Waarom: Juridische basis om te testen zonder dat het als ongeautoriseerde aanval wordt gezien.

   • Check:

     • Getekend door CIO/Security Officer.

     • Digitaal of fysiek opslaan als juridische dekking.

---

3. Azure AD – Identiteit en Toegang

3.1 Basisvragen over Azure AD-configuratie

1. Authenticatiemethode (Hash Sync, Pass-through, ADFS)

   • Waarom: Dit bepaalt hoe inloggegevens en tokens naar on-prem of cloud gefedereerd worden.

   • Check:

     • Zijn er AD FS-endpoints? SAML-config correct?

     • Eventuele migratie van legacy-auth naar modern?

2. Gastaccounts (B2B/B2C)

   • Waarom: Inactieve gastaccounts kunnen een risico zijn.

   • Check:

     • Ruimen jullie deze periodiek op?

     • Koppelen aan Access Reviews in Azure AD?

3. MFA voor admins en high-priv users

   • Waarom: Beveiliging van Global Admins, etc.

   • Check:

     • Conditional Access (Require MFA for Global Admins) ingeschakeld?

     • Uitzonderingen (break glass)? Welke MFA-methode?

4. Blokkering van legacy protocollen

   • Waarom: POP/IMAP/SMTP Basic Auth omzeilt MFA.

   • Check:

     • Zijn legacy protocollen geblokkeerd?

     • In Azure Portal of via PowerShell bevestigd?

5. Privileged Identity Management (PIM)

   • Waarom: JIT-toegang kan permanente admin-rechten beperken.

   • Check:

     • PIM-config en logging van escalatie.

     • Permante admin vs. tijdelijke elevatie?

---

4. Netwerk en Hybride Koppelingen

4.1 Virtual Networks en NSG’s

1. Subnetten en NSG’s

   • Waarom: Kan er onbedoeld veel openstaan in NSG’s?

   • Check:

     • Overzicht via az network nsg list.

     • Zijn er Any/Any/Allow-regels?

2. Azure Firewall / WAF / App Gateway

   • Waarom: Controleren of webapplicaties een WAF hebben met correcte rule sets.

   • Check:

     • OWASP rule sets actief?

     • Custom rules, whitelist, exclusions doornemen.

3. VPN- of ExpressRoute-koppeling

   • Waarom: Een gecompromitteerde Azure-VM kan zo naar on-prem pivotten.

   • Check:

     • IP-ranges, route tables, en of inbreker on-prem resources kan bereiken.

4. DDoS Protection Standard

   • Waarom: Biedt extra bescherming voor public IP’s.

   • Check:

     • Wil je mini-DDoS-tests doen?

     • Escalatie bij verstoring regelen.

5. Private Link/Private Endpoint

   • Waarom: Beschermt services (storage, DB) tegen publiek internet.

   • Check:

     • Zijn er public endpoints onbedoeld actief?

     • DNS/FQDN-check?

---

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

5.1 Virtual Machines

1. OS-versies en patchniveau

   • Waarom: Achterstallige patches zijn populaire aanvalsvector.

   • Check:

     • Versieherkenning via Nmap/Nessus/OpenVAS.

     • Patchmanagementcyclus uitleggen.

2. OS-hardening

   • Waarom: Een baseline (CIS, STIG) kan misconfiguraties voorkomen.

   • Check:

     • Guestconfig in Azure Policy?

     • Mogelijke afwijkingen (RDP open op 0.0.0.0/0?).

3. Azure Arc / config management

   • Waarom: Scripts kunnen plaintext credentials bevatten.

   • Check:

     • TLS/SSL-communicatie agent correct?

     • Repositories geen harde-coded secrets?

4. Remote beheer (RDP/SSH, Bastion, JIT)

   • Waarom: Onbeveiligde RDP/SSH-poorten zijn een groot risico.

   • Check:

     • Is poort 3389/22 altijd open?

     • Eventueel Bastion en logging controleren?

5. Bijzondere workloads (GPU, HPC)

   • Waarom: HPC-omgevingen vereisen extra veiligheidsupdates.

   • Check:

     • HPC-schedulers, RDMA-communicatie?

     • Worden HPC-nodes goed gepatcht?

5.2 Containers (AKS, Container Instances)

1. AKS

   • Waarom: Kubernetes-clusters kunnen misbruikt worden via clusterrole=cluster-admin.

   • Check:

     • RBAC, network policies, Pod Security Policies.

     • Container escape-gevaren.

2. Container Registry (ACR)

   • Waarom: Publieke ACR of ongescande images kunnen risico’s inhouden.

   • Check:

     • Is ACR publiek?

     • Scan images (Trivy, Clair) op CVE’s.

3. Azure Container Instances (ACI)

   • Waarom: Containers met ‘anonymous’ endpoints kunnen openstaan.

   • Check:

     • Environment variables met plaintext secrets?

     • Wie mag ACI starten/stoppen?

4. Azure Functions

   • Waarom: HTTP-trigger anoniem maakt de functie publiek.

   • Check:

     • Auth-level=anonymous of hoger?

     • Secrets in code?

5. App Services

   • Waarom: HTTPS-only en correct domain-binding is essentieel.

   • Check:

     • TLS-instellingen (HTTPS only)?

     • Managed Identity?

     • web.config met plaintext credentials?

---

6. Data en Opslag

6.1 Azure Storage (Blob, File, Disk)

1. Publieke Blob-containers

   • Waarom: Containers met public access kunnen datalekken veroorzaken.

   • Check:

     • Is “Public access” property ingeschakeld?

     • Eventueel fuzzy naam-scans?

2. SAS-tokens

   • Waarom: Te ruim ingestelde SAS-tokens (lange geldigheid, brede rechten) vormen een risico.

   • Check:

     • Hoeveel lees-/schrijfrechten hebben SAS?

     • Geldigheid max 1 dag? Expired SAS toch bruikbaar?

3. Disk Encryption

   • Waarom: Door BitLocker/dm-crypt of SSE+BYOK te gebruiken, wordt data-at-rest beter beschermd.

   • Check:

     • Azure Disk Encryption aan?

     • SSE, BYOK actief?

4. Cosmos DB

   • Waarom: Publiek toegankelijke DB’s of slechte firewall configuraties zijn gevaarlijk.

   • Check:

     • “Allow access from Azure services” te breed?

     • Any secrets/keys in DevOps pipelines?

5. SQL Databases

   • Waarom: Force TDE beveiligt data, Azure AD-auth kan veiliger zijn dan SQL logins.

   • Check:

     • TDE ingeschakeld?

     • Firewall “Allow all azure services” te ruim?

---

7. Logging, Monitoring en Incidentrespons

7.1 Logging en SIEM-integratie

1. Resource logs (Activity, Diagnostic, NSG Flow)

   • Waarom: Zonder goede logs is forensisch onderzoek moeilijk.

   • Check:

     • Volledige dekking (az monitor diagnostic-settings list)?

     • Retentie (30, 90, 180+ dagen)?

2. Azure Sentinel of andere SIEM

   • Waarom: Detectie van brute force, exfil, enz. kan alerts genereren.

   • Check:

     • Detectieregels actief?

     • Kleine testaanval uitvoeren om alarm te valideren?

3. Microsoft Defender for Cloud

   • Waarom: Security Score en aanbevelingen geven directe adviezen.

   • Check:

     • Wordt Autoprotect ingeschakeld bij VM’s?

     • Kritieke adviezen opgevolgd?

4. Azure AD Identity Protection

   • Waarom: Herkent gelekte credentials en ongebruikelijke inlogs.

   • Check:

     • Testscenario “aanmelden vanaf 2 continenten in korte tijd”.

     • Komt er direct een alert?

5. Incidentrespons-plan

   • Waarom: Zonder plan is reageren op een werkelijk incident lastig.

   • Check:

     • Playbooks of runbooks (SOAR)?

     • Escalatiestappen (IT-manager, CISO)?

     • Alerts bij high-severity?

---

8. Organisatorische en Governance Aspecten

8.1 DevOps en CI/CD

1. DevOps-pipelines (Azure DevOps, GitHub, Jenkins)

   • Waarom: Secrets in pipeline-variabelen kunnen uitlekken.

   • Check:

     • YAML-config bekijken

     • Logfiles bevatten tokens?

2. IaC (Terraform, Bicep, ARM)

   • Waarom: Embedded credentials in .tf of .json kunnen direct tot compromise leiden.

   • Check:

     • Doet men drift detection?

     • Best practices (geen plaintext secrets)?

3. Change Management-procedures

   • Waarom: Formeel goedgekeurde wijzigingen voorkomen wildgroei.

   • Check:

     • RFC/ticketing-proces?

     • Rollback-scenario’s?

4. Koppeling code-repos

   • Waarom: Secrets of connection strings kunnen in Git-commit-historie staan.

   • Check:

     • Git secrets scanning actief?

     • Onveilige commithistorie doorzoeken?

5. Test- en stagingomgevingen

   • Waarom: Staging kan prod-data bevatten, maar is minder goed beveiligd.

   • Check:

     • Is staging openbaar bereikbaar?

     • Gebruikt men standaardwachtwoorden?

8.2 Governance en Security Policies

1. Azure Policy en Blueprints

   • Waarom: Blokkeren ongewenste configuraties (bijv. open RDP).

   • Check:

     • az policy assignment list om compliance te checken.

     • Eventuele blueprint-sjablonen voor dev/test/prod?

2. RBAC – Roltoewijzingen

   • Waarom: Contributor/Owner te vaak geven leidt tot privilege escalatie.

   • Check:

     • az role assignment list → kijk naar wildcard roles.

     • Custom roles met *-permissions?

3. Managed Identities

   • Waarom: VM’s/App Services/Functions kunnen via MI ongewenste rechten hebben.

   • Check:

     • Welke rechten hebben de MI’s?

     • Logging gebruik MI?

4. Security-overzichten, auditing

   • Waarom: Periodieke interne audits en “security board meetings” verbeteren security posture.

   • Check:

     • Hoe worden bevindingen uit Security Center opgevolgd?

     • Bestaat er een register van open issues?

5. Training en awareness

   • Waarom: Als beheerders en devs niet getraind zijn, kunnen misconfiguraties blijven ontstaan.

   • Check:

     • Krijgen zij Azure-security training?

     • Is er een Security Champions-programma?

---

9. Escalatie, Rapportage en Nazorg

9.1 Escalaties bij Kritieke Bevindingen

1. Directe melding

   • Waarom: Een “critical exploit” (bijv. Key Vault compromise) wil je meteen weten.

   • Check:

     • Afspraak over melding (mail, telefoon, Teams).

     • Reactietijd (max 1 uur?) vastleggen.

2. Stoppen test bij storing

   • Waarom: Voorkom extra schade als de test ernstige verstoring veroorzaakt.

   • Check:

     • Codewoord “HALT test” of soortgelijk.

     • Incident documenteren (logs opslaan).

3. Realtime vs. eindrapport

   • Waarom: Sommige klanten willen wekelijks updates, anderen alleen slotpresentatie.

   • Check:

     • Wil je tussentijds updates?

     • NDA-scope voor delen van bevindingen?

9.2 Eindrapport en Actieplan

1. Structuur van rapport

   • Waarom: Combinatie van executive summary (voor directie) en gedetailleerd technisch deel (voor IT).

   • Check:

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

     • Gebruik CVSS-scores per bevinding.

2. Prioritering (High/Med/Low)

   • Waarom: Duidelijke prioriteit is cruciaal om snel te patchen.

   • Check:

     • Geef quick wins en lange-termijnoplossingen.

     • Benoem tijds- en resource-inschatting.

     • Stel KPI’s (bv. binnen 30 dagen High risk oplossen).

9.3 Validatie en Retesting

1. Plan voor hertest

   • Waarom: Na het oplossen van bevindingen is een hertest nodig voor confirmatie.

   • Check:

     • Direct na patching opnieuw testen?

     • Reserveer budget/tijd in contract.

2. Nazorg en forensische readiness

   • Waarom: Logging-retentie en forensische tools zijn onmisbaar bij echte incidenten.

   • Check:

     • Findings koppelen aan incidentrespons-plan.

     • Overweeg forensische experts bij ernstige incidenten.

3. Continue verbetering

   • Waarom: Security is een ongoing proces; periodieke scans en audits voorkomen terugval.

   • Check:

     • Cloud Security Posture Management (CSPM) integreren?

     • Azure Security Score en DevSecOps-pipelines monitoren?