5.6.8 Responsible Disclosure (Proces Kwetsbaarhedenbeheer) 3.0

Wat is het?  

Bij Responsible Disclosure nodig je white hat hackers uit om kwetsbaarheden te melden op je toepassingen. De voorwaarde is hier wel dat de white hat hacker eventueel gevonden kwetsbaarheden niet actief uitbuit.  

Je bepaalt hierbij enkel de scope (bijvoorbeeld: de website www.vlaanderen.be en alle sub-sites hiervan) die ze mogen onderzoeken. Zij proberen op eigen initiatief welke aanvalsvectoren mogelijk zijn. Bij het vinden van een kwetsbaarheid, melden ze dit aan ons (via een externe partij) en verbindt de overheid zich ertoe deze kwetsbaarheid op te lossen. 

White hat hackers dienen bij het melden van een kwetsbaarheid de volgende informatie te verstrekken om een snelle en accurate oplossing mogelijk te maken: 

  • Details van de kwetsbaarheid, inclusief het type kwetsbaarheid (bijvoorbeeld SQL-injectie, XSS, CSRF, etc.). 

  • Technische beschrijving van hoe de kwetsbaarheid werkt, met specifieke aanduidingen van welke onderdelen of subdomeinen zijn beïnvloed. 

  • Impactanalyse, die beschrijft hoe de kwetsbaarheid potentieel kan worden misbruikt en wat de gevolgen kunnen zijn voor de veiligheid van het systeem. 

  • Proof of Concept (PoC) zonder daarbij systemen te beschadigen of data te manipuleren. 

  • Stappen voor reproductie, zodat de kwetsbaarheid door het interne team kan worden nagebootst. 

Een compensatie voor de gevonden kwetsbaarheden is mogelijk. In tegenstelling tot een penetratietest, is de scope van Responsible Disclosure veel breder: er zijn minder beperkingen in de scope van wat de white hat hacker kan testen en ze kunnen ook meer aanvalsvectoren gebruiken. Sowieso gebeurt dit op de productieomgeving. 

Een white hat hacker mag binnen de context van Responsible Disclosure een gevonden kwetsbaarheid niet publiek maken, tenzij de Vlaamse overheid haar verplichtingen voor een tijdige oplossing niet naleeft. Dit moet de Vo expliciet opnemen in het contract met de white hat hacker, en/of het platform dat we hiervoor gebruiken. 

In diezelfde context zorg je er ook voor dat er een duidelijke code of conduct bestaat en bevestigd is door alle betrokken partijen. Dit moet op juridisch sluitende manier gebeuren. 

 In welke omgeving doe je aan responsible disclosure? 

Omdat dit soort oefening open staat voor mensen buiten onze organisatie, zonder hen extra rechten op onze toepassingen te geven, kan dit enkel in de productieomgeving. 

 Wat te doen? 

Dit soort oefening is een aanvulling op een penetratietest, geen vervanging ervoor. Het biedt namelijk een ander perspectief om te testen: de testscenario’s liggen niet vast en bieden dus meer ruimte om aanvalsvectoren te ontdekken Dit proces verloopt via een derde partij met wie wij in contact staan via een afzonderlijk beschreven proces. 

Een melding van een kwetsbaarheid handel je af als een veiligheidsincident, waarbij de urgentie afhangt van het risico gekoppeld aan de gemelde kwetsbaarheid. Hiervoor kun je dezelfde termijnen hanteren als voor penetratietesten. 

De premies die we uitbetalen aan de white hat hacker bij een als uitbuitbaar bewezen kwetsbaarheid: 

  • € 100 voor een kwetsbaarheid die voorkomt in de OWASP Top 10 

  • Voor andere kwetsbaarheden, een ad hoc te bepalen vergoeding 

 Welke tools? 

Dit proces verloopt via een derde partij met wie wij in contact staan via een afzonderlijk beschreven proces. 

Hier is een high level beschrijving: 

 

Screenshot from 2024-12-12 08-18-30.png

 

 Scope? 

  • Alle online toepassingen, die in scope van de oefening zijn geplaatst door de deelnemende partijen. Deze lijst deelt de Vo mee aan het platform. 

  • Alle websites, die in scope van de oefening zijn geplaatst door de deelnemende partijen. Deze lijst deelt de Vo mee aan het platform. 

Dit kan gaan om toepassingen of websites in eigen beheer, die van de centrale dienstverlening, of die bij een leverancier. 

Elke entiteit kan voor zichzelf bepalen welke delen van hun online dienstverlening ze in of out of scope willen hebben. Daarbij is het dus belangrijk te begrijpen dat deelname niet verplicht is voor alle entiteiten. Hoe meer entiteiten deelnemen, hoe groter de kostenefficiëntie.  

Een aparte aanpak om kwetsbaarheden op te lossen (scope, timing) per entiteit is ook mogelijk. Dit verhoogt uiteraard de complexiteit en de kostprijs.