Je browser is verouderd en geeft deze website niet correct weer. Download een moderne browser en ervaar het internet beter, sneller en veiliger!

Kwetsbaarheid melden

Medewerker Z-CERT aan het werk achter computer

Z-CERT hecht veel belang aan de veiligheid van haar (medische) apparatuur, programmatuur en diensten. Ondanks de zorg voor de beveiliging hiervan kan het voorkomen dat er toch sprake is van een kwetsbaarheid. Als u zo’n kwetsbaarheid ontdekt, kunt u dit veilig aan ons melden. Deze aanpak is de zogenaamde Coordinated Vulnerability Disclosure (CVD). Op deze manier kan Z-CERT beschermende maatregelen treffen.

Melding maken van een kwetsbaarheid

Als u een kwetsbaarheid heeft gevonden in een systeem van Z-CERT of een van de deelnemers waarvoor wij het CVD-proces afhandelen, horen wij dit graag. Dan kunnen wij zo snel als mogelijk maatregelen treffen. Z-CERT wil graag met u samenwerken om onze deelnemers en systemen nog beter te kunnen beschermen.

Wanneer u via ons Coordinated Vulnerability Disclosure-beleid kwetsbaarheden aan ons meldt, dan hebben wij geen reden om juridische consequenties te verbinden aan uw melding:

  • Verzeker u ervan dat uw melding ‘in scope’ is. Onderaan deze pagina kunt u controleren wat als niet ‘in scope’ wordt beschouwd.
  • U meldt uw bevindingen veilig via deze link. Of u maakt gebruik van het volgende mail-template en verstuurt dat versleuteld met Z-CERT’s publieke PGP-sleutel.
  • In uw melding geeft u voldoende informatie, zodat het probleem te reproduceren is. Op die manier kunnen wij het zo snel mogelijk oplossen. Meestal is het IP-adres of de URL van het getroffen systeem en een omschrijving van de kwetsbaarheid voldoende, maar bij complexere kwetsbaarheden is soms meer informatie gewenst/noodzakelijk. U kunt een proof of concept meesturen.
  • U misbruikt de geconstateerde kwetsbaarheid niet door bijvoorbeeld meer data te downloaden dan nodig is om het lek aan te tonen of door gegevens van derden in te zien, te verwijderen of aan te passen.
    Als u vermoedt dat u via een kwetsbaarheid medische gegevens kan inzien vragen wij u dit niet zelf te verifiëren maar dit door ons te laten doen.
  • U deelt uw bevindingen niet met anderen, voordat het is opgelost. Daarnaast vragen we u om alle vertrouwelijke gegevens die u heeft verkregen, na het dichten van het lek, direct te wissen.
  • U doet geen aanval(len) op onze (fysieke) beveiliging en maakt geen gebruik van social engineering, (distributed) denial of service, spam, brute-force aanvallen en/of applicaties van derden.

Hoe wij omgaan met uw melding:

  • Z-CERT behandelt uw melding vertrouwelijk en deelt uw persoonlijke gegevens niet met derden zonder uw toestemming, tenzij dit wettelijk verplicht is.
  • U krijgt een ontvangstbevestiging van Z-CERT en binnen 5 werkdagen ontvangt u een reactie op uw melding met een beoordeling van de melding en een verwachte datum voor een oplossing.
  • Als melder van het probleem houdt Z-CERT u op de hoogte van de voortgang van het oplossen van het probleem.
  • In berichtgeving over het gemelde probleem zal Z-CERT, als u dit wenst, uw naam vermelden als de ontdekker.
  • Als uw melding overlap vertoont met een eerdere melding, dan wordt alleen de eerste in behandeling genomen.
  • Als uw CVD-melding in scope is, dan ontvangt u als dank voor uw hulp een beloning, afhankelijk van de ernst van het beveiligingsprobleem en de kwaliteit van de melding.

We streven ernaar om alle problemen zo snel mogelijk op te lossen. Samen overleggen we daarna over de meerwaarde van een eventuele publicatie van het opgeloste probleem.

Met dank aan Floor Terra voor zijn voorbeeldtekst op responsibledisclosure.nl.

Laatst gewijzigd: 3 januari 2024

Niet in scope:

Z-CERT neemt meldingen niet in behandeling als het gaat om triviale kwetsbaarheden of security-issues die niet misbruikt kunnen worden.

Hieronder staan voorbeelden van bekende kwetsbaarheden en security-issues die buiten bovenstaande regeling vallen. Dit houdt niet in dat ze niet opgelost zouden moeten worden, echter bij ons CVD-proces gaat het om het melden van zaken waar direct misbruik van gemaakt kan worden. Bijvoorbeeld een kwetsbaarheid waar een werkende exploit voor bestaat of een misconfiguratie waardoor een bestaande securitycontrol te omzeilen is. Deze lijst is afgeleid van de lijst die het CERT van SURF hanteert.

  1. HTTP 404 codes/pages or other HTTP non-200 codes/pages and content spoofing/text injections in these pages
  2. Fingerprinting/version disclosures op public services
  3. Public files or directories that do not contain confidential information
  4. All disclosures of confidential/sensitive information will be judged by Z-CERT or the healthcare organization involved, and might be labeled “out of scope” if they do not pose a significant risk.
  5. Click jacking, problems that can only be exploited by clickjacking
  6. No secure/HTTP-only flags on unconfidential cookies
  7. OPTIONS HTTP method enabled
  8. Rate-limiting without clear impact
  9. All issues related to HTTP security headers, for example:
    1. X-Frame-Options
    2. X-XSS-Protection
    3. X-Content-Type-Options
    4. Content-Security-Policy
    5. Strict-Transport-Security
  10. SSL security configuration issues, for example:
    1. SSL Forward secrecy disabled
  11. No TXT record for DMARC or a missing CAA-record
  12. Host header injection
  13. Reports of outdated versions of any software without a proof of concept of a working exploit
  14. Absence of security best practices or hardening measures. Though important, they are not within scope of a CVD process. Example:
    1. xmlrpc.php/wp-json of a wordpress website
    2. Absence of rate limiting measures.
  15. Vulnerabilities only affecting users of outdated or unpatched browsers and platforms
  16. Social engineering of healthcare organisation staff or contractors. For example creating phishing pages.
  17. Issues that result in Denial of Service (DoS) to organisations servers at the network or application layer.
  18. Issues that require unlikely user interaction
  19. Cross-site Request Forgery with minimal security impact
  20. Issues related to software or protocols not under the organizations control. For example known issues with ARP or HL7.