Vulnerability Management & Patchbeleid

Rechten Omlaag, Controle Omhoog

Aanvalspaden worden klein zodra rechten, segmenten en beheerkanalen consequent zijn ingericht.

Voor Vulnerability Management & Patchbeleid blijft de basis hetzelfde: minder impliciet vertrouwen en meer zicht op afwijkend gedrag.

Zo beperk je niet alleen de kans op incidenten, maar vooral ook de omvang en duur als er iets misgaat.

Directe maatregelen (15 minuten)

• Start met MFA, least privilege en tiering voor beheeraccounts.
• Voer segmentatie en expliciete firewallregels door op kritieke paden.
• Borg logging, detectie en hersteltests als structurele operatie.

Waarom dit telt

De kern van Vulnerability Management & Patchbeleid is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Het Vulnerability Management Proces

Vulnerability management is geen scan draaien en een rapport mailen. Het is een cyclisch proces met vijf fasen die zich eindeloos herhalen, als een wasmachine die nooit stopt:

Het proces begint bij iets dat veel organisaties niet hebben: een complete asset inventarisatie. Je kunt geen kwetsbaarheden vinden in systemen waarvan je niet weet dat ze bestaan. Shadow IT – die testserver die een ontwikkelaar heeft opgezet en vergeten, die oude webapplicatie die “tijdelijk” was maar al drie jaar draait – dat zijn de systemen die het langst ongepatcht blijven, want ze staan in geen enkel register.

Regel een: je kunt niet beschermen wat je niet kent.

Scantools

De markt voor vulnerability scanners is volwassen. Er is voor elk budget en elke omvang een optie. De keuze hangt af van drie factoren: wat je scant (netwerk, web, containers), hoeveel je wilt betalen, en hoeveel valse positieven je bereid bent te accepteren.

Voorbeeld: OpenVAS scan configuratie

# OpenVAS installeren (Kali Linux)
sudo apt install gvm -y
sudo gvm-setup

# Na setup: webinterface op https://127.0.0.1:9392
# Login met gegenereerde credentials

# CLI scan starten met gvm-cli
gvm-cli --gmp-username admin --gmp-password <password> \
  socket --socketpath /run/gvmd/gvmd.sock \
  --xml '<create_target>
    <name>Intern Netwerk</name>
    <hosts>10.0.10.0/24</hosts>
  </create_target>'

Voorbeeld: Nuclei CLI

# Installatie
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

# Basis scan met alle templates
nuclei -u https://target.example.com -as

# Scan met specifieke severity
nuclei -u https://target.example.com -severity critical,high

# Scan met specifieke tags
nuclei -u https://target.example.com -tags cve,misconfig

# Netwerk scan met CIDR
echo "10.0.10.0/24" | nuclei -t network/

# Output naar JSON voor verwerking
nuclei -u https://target.example.com -j -o resultaten.json

# Integratie in CI/CD pipeline
nuclei -l targets.txt -severity critical,high \
  -markdown-export rapport/ \
  -silent

Voorbeeld: Trivy container scan

# Container image scannen
trivy image nginx:latest

# Alleen critical en high
trivy image --severity CRITICAL,HIGH nginx:latest

# Filesystem scannen (IaC misconfigs)
trivy fs --scanners vuln,misconfig /pad/naar/project

# SBOM genereren
trivy image --format cyclonedx nginx:latest > sbom.json

De keuze voor een scantool is minder belangrijk dan de discipline om het te gebruiken. Een gratis OpenVAS-scan die wekelijks draait is oneindig waardevoller dan een Qualys-licentie van honderdduizend euro die stof vergaart.

Prioriteren: CVSS vs EPSS vs KEV

Hier wordt het interessant. Want na een scan heb je een lijst. En die lijst is lang. Honderden, soms duizenden kwetsbaarheden. En nu moet je beslissen: wat patch je eerst?

Waarom CVSS alleen niet genoeg is

CVSS – het Common Vulnerability Scoring System – geeft elke kwetsbaarheid een score van 0 tot 10. Een CVSS van 9.8 klinkt alarmerend, en dat is het soms ook. Maar CVSS meet potentiele impact, niet waarschijnlijkheid van exploitatie. Een kwetsbaarheid met CVSS 9.8 in een component die alleen bereikbaar is via een intern netwerk dat achter drie firewalls en een VPN zit, is een ander risico dan een CVSS 7.5 in een internet-facing webserver.

Het resultaat: als je alleen op CVSS prioriteert, patch je alles met een hoge score, ongeacht of er daadwerkelijk een exploit in het wild bestaat. Je bent druk. Je voelt je productief. Maar je patcht misschien de verkeerde dingen.

EPSS – Exploit Prediction Scoring System

EPSS, ontwikkeld door FIRST.org, beantwoordt een andere vraag: hoe waarschijnlijk is het dat deze kwetsbaarheid in de komende 30 dagen actief wordt geexploiteerd? Het model gebruikt machine learning op basis van historische exploitdata, kenmerken van de CVE, en signalen uit het wild (exploit code beschikbaar, vermeldingen op fora, etc.).

EPSS scoort van 0 tot 1 (0% tot 100% kans op exploitatie). Een CVE met CVSS 9.8 maar EPSS 0.02 is waarschijnlijk theoretisch gevaarlijk maar in de praktijk nog niet geexploiteerd. Een CVE met CVSS 7.0 maar EPSS 0.95 wordt nu actief gebruikt door aanvallers.

# EPSS data opvragen via API
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2024-1709" | jq .

# Voorbeeld output:
# {
#   "data": [{
#     "cve": "CVE-2024-1709",
#     "epss": 0.97431,
#     "percentile": 0.99961
#   }]
# }

CISA KEV – Known Exploited Vulnerabilities

De CISA KEV-catalogus is de meest directe indicator: deze kwetsbaarheden worden bewezen actief geexploiteerd in het wild. Geen voorspelling, geen score – feit. Als een CVE op de KEV-lijst staat, is het geen theoretisch risico meer. Iemand gebruikt het. Nu. Tegen organisaties zoals de jouwe.

De KEV-catalogus bevat op het moment van schrijven meer dan 1.100 kwetsbaarheden. CISA verplicht Amerikaanse overheidsinstanties om KEV-items binnen de gestelde deadline te patchen. Dat is een goed beleid om over te nemen, ook als je geen Amerikaanse overheidsinstantie bent.

# CISA KEV catalogus ophalen
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | jq '.vulnerabilities | length'

# Zoek specifieke CVE
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | jq '.vulnerabilities[] | select(.cveID == "CVE-2023-46805")'

Decision matrix

Combineer de drie bronnen voor een rationele prioritering:

De kolom “Internet-facing” is cruciaal. Een CVSS 7.0 op een publiek bereikbare webserver is een groter risico dan een CVSS 9.0 op een interne applicatieserver die alleen via een jump host bereikbaar is. Context is alles.

Patchbeleid

Een patchbeleid zonder handhaving is een wensenlijst. Hier is een template dat werkt – niet omdat het perfect is, maar omdat het afdwingbaar is:

Patchbeleid template

Uitzonderingsproces

Soms kun je niet patchen. De applicatie is end-of-life. De vendor heeft geen patch. De patch breekt functionaliteit. Dat gebeurt. Het punt is niet dat uitzonderingen niet mogen bestaan – het punt is dat ze gedocumenteerd, goedgekeurd en tijdelijk moeten zijn.

Een uitzondering bevat minimaal: - CVE-nummer en beschrijving van de kwetsbaarheid - Reden waarom niet gepatcht kan worden - Compenserende maatregel die het risico mitigeert (zie sectie 18.5) - Eigenaar die verantwoordelijk is voor de uitzondering - Vervaldatum – uitzonderingen zijn niet permanent. Maximaal 90 dagen, daarna hernieuwde beoordeling. - Handtekening van de risico-eigenaar (niet de systeembeheerder, maar de business owner)

Dat laatste punt is belangrijk. Als de business owner persoonlijk moet tekenen voor het risico van een ongepatchte kritieke kwetsbaarheid, word je verbaasd hoe snel die “onmogelijke” patch ineens mogelijk blijkt.

Compenserende Maatregelen

Wanneer patchen niet kan – en soms kan het echt niet – zijn er compenserende maatregelen die het risico verlagen zonder de kwetsbaarheid te verhelpen:

Virtual patching (WAF-regels)

Een Web Application Firewall kan verkeer blokkeren dat bekende exploit-patronen bevat, zonder de onderliggende applicatie te wijzigen:

# ModSecurity regel voor CVE-2021-44228 (Log4Shell)
SecRule REQUEST_LINE|REQUEST_HEADERS|REQUEST_BODY "@rx \$\{(?:j(?:ndi|ava)|lower|upper|env|sys|date|base64)" \
    "id:1000,\
    phase:2,\
    deny,\
    status:403,\
    log,\
    msg:'Potential Log4Shell exploitation attempt',\
    tag:'CVE-2021-44228'"

Virtual patching is een noodverband, geen oplossing. Het beschermt tegen bekende exploit-patronen, maar niet tegen varianten. Gebruik het om tijd te kopen, niet als vervanging voor een echte patch.

Netwerksegmentatie

Isoleer kwetsbare systemen. Als je een server niet kunt patchen, beperk dan wie erbij kan:

• Verplaats naar een geïsoleerd VLAN (zie hoofdstuk 15)
• Sta alleen verkeer toe van specifieke bronnen op specifieke poorten
• Blokkeer outbound verkeer behalve wat strikt noodzakelijk is
• Monitor al het verkeer van en naar het kwetsbare systeem

Monitoring

Wat je niet kunt patchen, moet je bewaken als een havik:

• IDS/IPS-regels specifiek voor de kwetsbaarheid
• Verhoogde logging op het kwetsbare systeem
• Alerting op exploit-indicatoren
• Regelmatige handmatige controle

Automatisering

Handmatig patchen schaalt niet. Bij tien servers kun je het handmatig doen. Bij honderd wordt het onpraktisch. Bij duizend is het onmogelijk. Automatisering is geen luxe – het is een vereiste.

Windows: WSUS / Intune

# WSUS -- Windows Server Update Services
# Configureer via Group Policy:
# Computer Configuration > Administrative Templates > Windows Components > Windows Update
# - Specify intranet Microsoft update service location: http://wsus-server:8530
# - Configure Automatic Updates: Auto download and schedule the install

# Intune -- Modern management
# Endpoint Manager > Devices > Update rings for Windows 10 and later
# - Quality update deferral: 0 dagen (kritiek), 7 dagen (overig)
# - Feature update deferral: 30 dagen
# - Compliance policy: non-compliant na 3 dagen overdue

Linux: unattended-upgrades (Debian/Ubuntu)

# Installatie
sudo apt install unattended-upgrades apt-listchanges -y

# Configuratie: /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Mail "beheer@example.com";

# Activeren
sudo dpkg-reconfigure -plow unattended-upgrades

# Testen
sudo unattended-upgrade --dry-run --debug

Ansible: geautomatiseerde patching

# patch-all.yml -- Ansible playbook voor geautomatiseerde patching
---
- name: Patch Linux servers
  hosts: linux_servers
  become: true
  serial: "25%"              # Patch 25% tegelijk (rolling update)
  max_fail_percentage: 10    # Stop als >10% faalt

  pre_tasks:
    - name: Controleer of systeem bereikbaar is
      ping:

    - name: Maak snapshot (VMware)
      community.vmware.vmware_guest_snapshot:
        hostname: "{{ vcenter_host }}"
        name: "{{ inventory_hostname }}"
        snapshot_name: "pre-patch-{{ ansible_date_time.date }}"
        state: present
      delegate_to: localhost
      when: create_snapshot | default(true)

  tasks:
    - name: Update package cache
      apt:
        update_cache: yes
        cache_valid_time: 3600
      when: ansible_os_family == "Debian"

    - name: Installeer security updates (Debian/Ubuntu)
      apt:
        upgrade: safe
        update_cache: yes
      register: apt_result
      when: ansible_os_family == "Debian"

    - name: Installeer security updates (RHEL/CentOS)
      yum:
        name: '*'
        state: latest
        security: yes
      register: yum_result
      when: ansible_os_family == "RedHat"

    - name: Controleer of reboot nodig is
      stat:
        path: /var/run/reboot-required
      register: reboot_required
      when: ansible_os_family == "Debian"

    - name: Reboot indien nodig
      reboot:
        reboot_timeout: 300
        msg: "Reboot na patching"
      when:
        - reboot_required.stat.exists | default(false)
        - allow_reboot | default(true)

  post_tasks:
    - name: Verifieer services
      service:
        name: "{{ item }}"
        state: started
      loop: "{{ critical_services | default([]) }}"

    - name: Rapporteer resultaat
      debug:
        msg: "Patching {{ 'geslaagd' if not apt_result.changed and not yum_result.changed else 'voltooid met wijzigingen' }}"

# Uitvoeren
ansible-playbook patch-all.yml -i inventory/productie --check  # Dry run
ansible-playbook patch-all.yml -i inventory/productie           # Echt patchen

# Alleen kritieke security updates
ansible-playbook patch-all.yml -i inventory/productie -e "security_only=true"

De serial: "25%" parameter is cruciaal: het voorkomt dat je alle servers tegelijk patcht en je hele omgeving platlegt als er iets misgaat. Patch in golven. Controleer na elke golf. Ga pas door als alles werkt.

Meten en Rapporteren

Wat je niet meet, kun je niet verbeteren. En wat je niet rapporteert, krijgt geen budget. Hier zijn de KPI’s die ertoe doen:

Dashboard voorbeeld

VULNERABILITY MANAGEMENT DASHBOARD -- Q1 2026

Scan Coverage:     ████████████████████░  96% (target: 98%)
Patch Compliance:  ██████████████████░░░  89% (target: 95%)

Open Vulnerabilities:
  Critical:  2   ▼ (was 7)    SLA: 0 overdue
  High:     14   ▼ (was 23)   SLA: 3 overdue
  Medium:   67   ► (was 65)   SLA: 8 overdue
  Low:     234   ► (was 241)  SLA: binnen target

MTTP (Mean Time to Patch):
  Critical:  1.8 dagen  ✓ (target: <2)
  High:     11.2 dagen  ✓ (target: <14)
  Medium:   24.5 dagen  ✓ (target: <30)
  Low:      67.0 dagen  ✓ (target: <90)

Active Exceptions: 4 (was 6)
  - CVE-2023-xxxxx: Legacy ERP, verloopt 15-apr
  - CVE-2024-xxxxx: SCADA systeem, verloopt 01-mei
  - CVE-2024-xxxxx: Vendor patch pending, verloopt 28-mrt
  - CVE-2024-xxxxx: Test-omgeving, verloopt 30-apr

De trend is belangrijker dan het absolute getal. Een organisatie die van 60% naar 85% compliance gaat, doet het beter dan een organisatie die al jaren op 90% zit en niet verbetert. Rapporteer trends, niet snapshots.

En rapporteer in de taal van het management. Niet “we hebben 47 kritieke CVE’s gepatcht.” Maar: “we hebben 47 kwetsbaarheden verholpen die actief worden gebruikt door ransomware-groepen om organisaties zoals de onze binnen te dringen.” Dat is dezelfde informatie. Het ene krijgt een knikje. Het andere krijgt budget.

Samenvatting

Vulnerability management is geen project met een einddatum. Het is een proces dat draait zolang je systemen hebt:

1. Discover – je kunt niet beschermen wat je niet kent. Begin met een complete asset inventarisatie en scan continu
2. Prioriteer met context – CVSS alleen is niet genoeg. Combineer CVSS, EPSS en de CISA KEV-catalogus met business context (internet-facing vs. intern)
3. Patchbeleid met SLA’s – kritiek binnen 48 uur, hoog binnen 14 dagen. Geen uitzonderingen zonder schriftelijke goedkeuring en compenserende maatregel
4. Compenseer wat je niet kunt patchen – virtual patching, segmentatie en monitoring kopen tijd, maar zijn geen vervanging
5. Automatiseer – handmatig patchen schaalt niet. Ansible, WSUS, Intune, unattended-upgrades: kies je wapen
6. Meet en rapporteer – Mean Time to Patch, compliance rate, open vulnerabilities. Rapporteer trends in de taal van het management
7. Verify – een patch die niet is geverifieerd, is geen patch. Scan opnieuw na elke remediatie

De Equifax-breach kostte het bedrijf 1,4 miljard dollar. De patch die het had voorkomen was gratis en kostte vijf minuten om te installeren. Vulnerability management is het goedkoopste beveiligingsprogramma dat bestaat. Het enige dat het kost, is discipline.

Vorige: Hoofdstuk 17 – Backup & Disaster Recovery Volgende: Hoofdstuk 19 – Zero Trust Architectuur