Het primaire doel van een beleid voor kwetsbaarhedenbeheer is het beschermen van de organisatie tegen de exploitatie van kwetsbaarheden, die kunnen leiden tot ongeautoriseerde toegang, datadiefstal, netwerkinbreuken en diverse andere cyberaanvallen.

Dit beleid stelt een systematisch en gestructureerd kader vast voor het identificeren, evalueren, prioriteren en aanpakken van kwetsbaarheden binnen alle onderdelen van de organisatie, waaronder gebruikersapparatuur, infrastructuurcomponenten en softwaretoepassingen. Het richt zich op het proactief verminderen van risico's en het waarborgen van de integriteit, vertrouwelijkheid en beschikbaarheid van de informatiesystemen. Door het vaststellen van duidelijke procedures en verantwoordelijkheden helpt dit beleid bij het continu monitoren en verbeteren van de beveiligingsmaatregelen van de organisatie.

Wat zijn kwetsbaarheden?

Kwetsbaarheden (vulnerabilities) verwijzen naar zwakke punten, gebreken of tekortkomingen in een softwaresysteem, hardware, netwerk of toepassing die kunnen worden geëxploiteerd door cyberaanvallers om ongeautoriseerde toegang te verkrijgen of schade aan te richten. Deze kwetsbaarheden kunnen ontstaan door een verscheidenheid aan factoren:

• Softwarefouten: Programmeringsfouten of bugs in software kunnen leiden tot kwetsbaarheden. Voorbeelden hiervan zijn onjuiste invoervalidatie, inadequate foutafhandeling, en kwetsbaarheden in de beveiliging van applicaties.

• Configuratiefouten: Onjuiste of suboptimale configuraties van systemen en netwerken kunnen zwakke punten creëren. Dit kan variëren van slecht geconfigureerde firewalls tot onbeveiligde databasetoegang.

• Ontwerpfouten: Zwakke punten kunnen ook inherent zijn aan het ontwerp van de software of het systeem, waarbij de architectuur van de applicatie of het netwerk beveiligingslacunes vertoont.

• Verouderde hardware of software: Het gebruik van verouderde hardware of software die niet langer wordt ondersteund of geactualiseerd, kan kwetsbaarheden in de hardware chips of software code bevatten die niet kunnen worden aangepakt.

Kwetsbaarheden kunnen worden geclassificeerd op basis van hun ernst. De ernst van een kwetsbaarheid wordt bepaald aan de hand van de volgende factoren:

• De beschikbaarheid van een exploit: Is er al een exploit beschikbaar die de kwetsbaarheid kan uitbuiten?

• De impact van de exploit: Hoe ernstig kunnen de gevolgen van de exploit zijn als deze wordt uitgevoerd?

Toepassingsgebied van kwetsbaarhedenbeheer

Procedures voor het beheer van technische kwetsbaarheden moeten worden toegepast op volgende bedrijfsmiddelen:

• Applicaties, besturingssysteemsoftware, middleware en firmware op:

  • Computerapparatuur (met inbegrip van servers en desktopcomputers)

  • Mobiele apparaten (met inbegrip van tablets en smartphones)

  • Virtuele systemen (met inbegrip van virtuele servers, virtuele desktops en virtuele toepassingen)

  • Netwerkopslagsystemen (met inbegrip van storage area networks (SAN) en network-attached storage (NAS))

  • Netwerkapparatuur (met inbegrip van routers, switches, draadloze toegangspunten (access points) en firewalls)

  • VoIP-telefoniesoftware en vergaderapparatuur

  • Kantoorapparatuur (met inbegrip van netwerkprinters, kopieerapparaten, multifunctionele apparaten, enz.)

  • Gespecialiseerde systemen, waaronder systemen die industriële besturingssystemen ondersteunen (bijv. SCADA-systemen, Distributed Control Systems (DCS), Programmable Logic Controllers (PLC), IoT-apparaten, enz.)

Kortom, kwetsbaarhedenbeheer is van toepassing op alle gebruikersapparatuur, infrastructuurcomponenten, software en toepassingen binnen de organisatie, ongeacht of deze zelf ontwikkeld of aangekocht zijn.

Het identificeren van technische kwetsbaarheden

Het identificeren van kwetsbaarheden is de eerste stap in het kwetsbaarhedenbeheerproces.

Om kwetsbaarheden te identificeren, kan de organisatie gebruik maken van diverse methodes, waaronder:

• Vulnerability scanners: Deze tools scannen systemen, netwerken en applicaties op bekende kwetsbaarheden.

• Penetration tests: Onderzoek en simulatie van cyberaanvallen om kwetsbaarheden in systemen, applicaties en netwerken te identificeren.

• Code reviews: Handmatige of geautomatiseerde beoordeling van de broncode van een applicatie om kwetsbaarheden te vinden.

• Responsible disclosure: Het proces voor het melden van kwetsbaarheden door gebruikers of professionals (bijvoorbeeld ethische hackers).

Het wordt aanbevolen om een combinatie van de bovengenoemde methodes te gebruiken om de effectiviteit van het identificeren van technische kwetsbaarheden te waarborgen. Deze aanpak dient afgestemd te zijn op de informatieklasse (zie het Vo-ICR) van de betreffende bedrijfsmiddelen. Het ontwerpen en ontwikkelen van veilige systemen en software dient ook te voldoen aan Veilig ontwerpen en ontwikkelen.

Vulnerability scan

Vulnerability scans zijn geautomatiseerde processen die applicaties en hun onderliggende infrastructuur doorzoeken op kwetsbaarheden, zoals componenten die niet de juiste beveiligingsupdates of bekende kwetsbare configuraties hebben. Deze scanners gebruiken een database met bekende kwetsbaarheden om te controleren of dergelijke kwetsbaarheden aanwezig zijn in de gescande systemen.

Vulnerability scans kunnen effectief worden ingezet in combinatie met netwerkdiscovery scans. Het doel van een netwerkdiscovery scan is om een volledig overzicht te verkrijgen van alle hardware en software binnen het netwerk, waardoor kwetsbaarheden in onbekende of niet-beheerde bedrijfsmiddelen ook geïdentificeerd kunnen worden.

Bij het plannen van vulnerability scans is het essentieel om de scope, het tijdstip en de frequentie zorgvuldig te bepalen. Dit zorgt ervoor dat geen enkel bedrijfsmiddel over het hoofd wordt gezien, de beschikbaarheid van de productieomgeving niet wordt beïnvloed, en dat bekende kwetsbaarheden binnen een redelijke termijn kunnen worden aangepakt.

Penetratietest

Bij penetratietesten (of pentesten) wordt een gespecialiseerde tester ingeschakeld die kwetsbaarheden in specifieke applicatie onderzoekt. Deze testen hebben een duidelijk gedefinieerde scope, aanvalsvectoren en timing.

Penetratietesten kunnen plaatsvinden in de acceptatieomgeving als deze identiek is aan de productieomgeving. De timing van deze testen moet zo gepland worden dat ze geen piekmomenten in de productieomgeving verstoren. Recurrente testen vinden doorgaans plaats in de productieomgeving.

Er zijn drie soorten penetratietesten:

• White Box: hierbij heeft de tester informatie over de manier waarop de toepassing is geïmplementeerd en over de interne werking van de organisatie (architectuur, organigram, etc.)

• Black Box: hierbij heeft de tester in principe geen, of bijna geen informatie over de toepassing of de organisatie.

• Grey Box: hierbij krijgt de tester een deel van de informatie, maar niet zoveel als bij een white box.

Bovendien kan er gekozen worden om de penetratietest uit te voeren met alle andere mitigerende maatregelen actief (zoals een firewall, API-gateway security, Web Application Firewall (WAF)) of net niet, afhankelijk van het te bekomen doel (end-to-end controle of enkel het aan de penetratietest onderworpen systeem).

De tester moet rekening houden met verschillende aanvalsvectoren en kwetsbaarheden, waaronder:

• De OWASP top 10 kwetsbaarheden

• (D)DoS paraatheid

• Brute force attack paraatheid

• Buffer overflow/memory leak

• Check tegen gekende CVE reports

• Credential hunting (default passwoorden, hardgecodeerde gebruikersnamen of wachtwoorden)

• Downgrade attacks die gebruik maken van verouderde protocollen

• Exploit servers

• Input errors

• Privilege escalation

• Zoeken naar niet-ondersteunde versies van programma’s of systemen

De frequentie en het soort van testen variëren afhankelijk van de informatieklasse van de applicatie. Kwetsbaarheden, vooral in naar het internet ontsloten toepassingen, dienen prioritair te worden aangepakt. Na remediëring van kwetsbaarheden kan een nieuwe test nodig zijn om te bevestigen dat deze in productie zijn opgelost.

Code review

Code review verwijst naar het proces van manuele of geautomatiseerde inspectie van de code van een applicatie om de veiligheid te waarborgen. Afhankelijk van de ontwikkelingsfase van de applicatie, kunnen verschillende soorten reviews nodig zijn, uitgevoerd in de ontwikkel-, test- of acceptatieomgeving.

Er zijn twee hoofdtypen van code reviews:

• Static Application Security Testing (SAST): Deze statische reviews worden uitgevoerd op niet-gecompileerde broncode, dus in een contextloze omgeving.

• Dynamic Application Security Testing (DAST): Deze dynamische reviews vinden plaats op gecompileerde code in een test- of acceptatieomgeving, waar de code in een functionele context wordt beoordeeld.

Naast deze reviews kunnen andere tests tijdens het ontwikkelproces, zoals unit testing of acceptatietesting, ook bijdragen aan het verzekeren van veiligheid.

Code reviews focussen op het identificeren van kwetsbaarheden uit de OWASP Top 10 en specifieke dreigingen uit bronnen zoals CVE-databases. Het doel is om zoveel mogelijk kwetsbaarheden in een vroeg stadium van de ontwikkelfase te verhelpen. Niet-behandelde kwetsbaarheden kunnen in latere fasen nog worden geïdentificeerd en aangepakt (bijvoorbeeld door middel van penetratietest), maar dit kan de doorlooptijd van een project beïnvloeden.

Voor ingekochte of open source toepassingen is het belangrijk dat leveranciers of de onderhoudende communities deze praktijken ook toepassen. Deze controles dienen te gebeuren vóór de aankoop of installatie van de code of applicatie.

Responsible disclosure

Responsible disclosure is een principe waarbij iemand die een kwetsbaarheid in software of een systeem ontdekt, deze op een verantwoordelijke manier rapporteert aan de organisatie die de software of het systeem beheert, in plaats van deze informatie openbaar te maken of te misbruiken. Het doel van responsible disclosure is om de organisatie de gelegenheid te geven de kwetsbaarheid te verhelpen voordat deze bekend wordt bij het grote publiek of bij kwaadwillenden. Het proces omvat typisch de volgende stappen:

• Ontdekking van de kwetsbaarheid: Een onderzoeker of gebruiker identificeert een kwetsbaarheid in een systeem of applicatie.

• Vertrouwelijke rapportage: De ontdekker rapporteert de kwetsbaarheid vertrouwelijk aan de organisatie die verantwoordelijk is voor het systeem of de applicatie. Dit wordt vaak gedaan via een speciaal daarvoor bestemd kanaal of contactpunt.

• Reactie van de organisatie: De betreffende organisatie erkent de melding, onderzoekt de kwetsbaarheid en ontwikkelt een oplossing of patch.

• Communicatie en timing: De melder en de organisatie communiceren over een redelijke tijdlijn voor het openbaar maken van de kwetsbaarheid, meestal nadat de oplossing is geïmplementeerd (Deze situatie komt veelvuldig voor bij grote software leveranciers die een kwetsbaarheid en patch openbaar maken).

• Openbaarmaking: Na het verhelpen van de kwetsbaarheid, wordt deze openbaar gemaakt, vaak inclusief erkenning van de persoon die de kwetsbaarheid heeft ontdekt.

Als onderdeel van het responsible disclosure beleid kan de organisatie overwegen een bug bounty programma te lanceren. Dit programma nodigt ethische hackers of white hat hackers uit om actief naar kwetsbaarheden te zoeken, eventueel in ruil voor een beloning. Door het aanbieden van een bug bounty programma stimuleert de organisatie de melding van kwetsbaarheden, waardoor de algehele beveiliging verbeterd kan worden. Deze benadering helpt niet alleen bij het identificeren en oplossen van beveiligingsproblemen, maar bevordert ook een positieve samenwerking met de cybersecuritygemeenschap. Het is echter belangrijk om duidelijke richtlijnen en regels voor het programma vast te stellen, inclusief de scope van het programma, de criteria voor beloningen en de procedure voor het indienen van bevindingen.

Het beoordelen en evalueren van technische kwetsbaarheden

Om het potentiële impactniveau van kwetsbaarheden op de systemen van de organisatie te bepalen, gebruiken we de CVE-evaluatie van de MITRE-organisatie. Door deze methodologie toe te passen, zorgen we voor een uniforme en consistente risicobeoordeling van kwetsbaarheden over alle systemen heen.

Hieronder vindt u een tabel met een overzicht van de basisschalen die bij deze risicobeoordeling worden gebruikt, evenals de standaard risicobeheersingsmaatregelen die we daar tegenoverstellen. Afwijkingen of uitzonderingen zullen, zoals altijd, onderworpen worden aan een risicoanalyse, inclusief eventuele aanvullende maatregelen, voordat deze mogelijk geaccepteerd kunnen worden.

Wanneer is een systeem correct gepatcht?

Op basis van bovenstaande tabel is een systeem correct gepatcht indien er op het systeem geen kwetsbaarheden voorkomen met een CVSS waarde vanaf 4 en hoger, waar de identificatie, ontvangen of update van een CVSS score van de individueel geïdentificeerde unieke kwetsbaarheden ouder is dan de aangegeven tolerantiewaarde (in kalenderdagen). 

Voor individuele kwetsbaarheden lager dan CCVS score 4 heeft de verantwoordelijke ‘uitvoerder van de verwerking’ de mogelijkheid om over te gaan tot het aanvaarden van de risico’s die voortkomen uit de afwezigheid van deze patches. 

Merk op

Tijdens de levenscyclus van kwetsbaarheden bestaat de kans dat de CVSS waarde van de betrokken kwetsbaarheid word bijgesteld naar een hogere kriticiteit. Het moment waarop deze tolerantiewaarde wordt overschreden is gebaseerd op het moment van herevaluatie van de CVVS score, niet van de originele CVSS score bij de identificatie van de kwetsbaarheid binnen het MITRE framework. 

Kriticiteit kan ook dalen door andere mitigerende maatregelen. Voorbeeld: Stel dat een admin interface een kritieke kwetsbaarheid bevat waar nog geen patch voor beschikbaar is. Een tijdelijke compenserende maatregel is dan bijvoorbeeld door netwerk toegang naar deze interface te beperken middels een firewall. Hiermee blijft de CCVS nog steeds wel hoog, maar de mogelijkheid om de service te compromitteren wordt lager. Iedere situatie is anders, dus compenserende maatregelen zijn niet altijd mogelijk. Het advies blijft om altijd te streven naar patching.

Regelgeving en standaarden (L1)

ISO 27001:2022 (Annex A)

Informatieveiligheidsstrategie van de Vlaamse overheid (L2)

Zie 5.6. Minimale maatregelen - Veiligheidtesten voor meer informatie.