Kort gezegd: Kwetsbaarhedenbeheer in het mkb is een slank, terugkerend circuit: uw systemen kennen, meldingen gericht volgen, beoordelen op risico, beslissen, uitvoeren en aantonen. Beslissend zijn niet dure tools, maar duidelijke verantwoordelijkheden en een prioritering die rekening houdt met bereikbaarheid, gegevens en dreigingsbeeld. PHP2Shell is een goed oefenvoorbeeld, omdat alle stappen erin voorkomen.
Honderden meldingen, weinig personeel
Elke week verschijnen nieuwe beveiligingslekken, in besturingssystemen, programmeertalen, toepassingen en plug-ins. Een concern heeft daarvoor een team. Een mkb-bedrijf heeft vaak één IT-manager, een of twee beheerders en meerdere externe dienstverleners. Niemand kan elke melding lezen, en dat hoeft ook niet.
Wat nodig is, is een filter: welke meldingen betreffen onze systemen, welke daarvan zijn dringend en wie pakt ze op? Ontbreekt dat filter, dan gebeurt een van twee dingen. Of alles wordt genegeerd totdat er iets misgaat, of elke melding veroorzaakt onrust en de werkelijk kritieke verdwijnt in de ruis.
Het circuit van kwetsbaarhedenbeheer
Een werkbaar proces voor het mkb laat zich in zes stappen beschrijven:
- Vastleggen wat er draait. Zonder inventaris geen vergelijking. Welke websites, servers, PHP-versies en toepassingen beheert u, en waar? Hoe dat lukt, leest u in Weten wat er draait: inventaris van alle websites en servers.
- Meldingen volgen. Abonneer u op een paar betrouwbare bronnen: waarschuwingen van het BSI, meldingen van de fabrikanten van uw software, de beveiligingspagina's van uw Linux-distributie en bij PHP de startpagina van php.net.
- Beoordelen. Betreft de melding ons? Zo ja, hoe dringend? Daarover hieronder meer.
- Beslissen. Verhelpen, tijdelijk afschermen, het systeem isoleren of het risico bewust dragen. Wie mag wat beslissen?
- Uitvoeren. Update installeren, overbruggende maatregel nemen, dienstverlener inschakelen.
- Aantonen en opvolgen. Is het lek echt gedicht? Wanneer wordt een tussenoplossing vervangen?
Daarna begint het circuit opnieuw. Nieuwe systemen komen erbij, oude vallen weg en nieuwe meldingen verschijnen.
Bij stap 2 helpt een eenvoudige regel: liever een paar bronnen regelmatig lezen dan veel bronnen af en toe. Voor een typische mkb-webomgeving volstaan meestal de waarschuwingen van CERT-Bund (het Duitse overheids-CERT) bij het BSI, de beveiligingsmeldingen van de gebruikte Linux-distributie, de pagina's van de CMS- en shopfabrikanten en de startpagina van php.net. Bepaal wie deze bronnen leest en richt daarvoor een gedeelde mailbox of een kanaal in dat niet aan één persoon hangt.
Daarnaast loont een blik van buitenaf. Een regelmatige kwetsbaarhedenscan van de openbaar bereikbare systemen laat zien of verouderde software of onnodig open diensten zichtbaar zijn. Hij vervangt noch de inventaris noch de updates, maar legt systemen bloot die op geen enkele lijst staan.
Beoordelen: wat het eerst aan de beurt komt
De CVSS-score, een gestandaardiseerde indeling van de ernst, is een goed vertrekpunt. Voor de volgorde in uw eigen organisatie volstaat ze echter niet. Drie aanvullende vragen geven de doorslag:
| Vraag | Verhoogt de urgentie | Verlaagt de urgentie |
|---|---|---|
| Is het systeem vanaf internet bereikbaar? | openbare website, shop, portaal | alleen intern, achter VPN |
| Is aanmelden nodig om het lek te misbruiken? | nee, zonder authenticatie | ja, alleen voor beheerders |
| Welke gegevens verwerkt het systeem? | klantgegevens, betalingen, toegangsgegevens | openbare inhoud zonder accounts |
| Zijn er berichten over aanvallen? | aanvalspogingen gemeld | geen bekende pogingen |
| Is er een overbruggende maatregel? | nee | ja, met aangetoonde werking |
PHP2Shell laat zien hoe dit samenwerkt. Beide lekken hebben een CVSS v4.0-score van 9.2, maken code-uitvoering zonder aanmelding mogelijk en treffen openbaar bereikbare webservers. Cloudflare en Patchstack meldden volgens de media aanvalspogingen, het BSI classificeerde de situatie als waarschuwingsniveau 3. De overbruggende maatregelen van php.net bieden uitdrukkelijk geen volledige bescherming. Alle vragen wijzen in dezelfde richting: direct handelen. Wat het BSI concreet adviseerde, leest u onder Wat het BSI over PHP2Shell adviseert.
Beslissen en documenteren
Niet elk lek is meteen te dichten. Een oud systeem draait op PHP 8.1, waarvoor geen officiële updates meer bestaan (zie PHP 8.1 en ouder: wat nu geldt), een vakapplicatie verdraagt de update nog niet. Dan is een besluit nodig, en dat hoort niet alleen bij de techniek.
Een goede besluitnotitie bevat het getroffen systeem, het lek, de beoordeling, de gekozen optie, overbruggende maatregelen, de verantwoordelijke persoon en een datum voor een nieuwe beoordeling. Wordt een risico bewust gedragen, dan beslist de leiding en niet de beheerder alleen. Ook de OWASP Cheat Sheet over de omgang met kwetsbare afhankelijkheden adviseert risicoacceptatie uitdrukkelijk op leidinggevend niveau te verankeren.
Houd één enkele lijst van openstaande kwetsbaarheden bij met status, verantwoordelijke en datum. Een tabel volstaat. Belangrijk is dat ze regelmatig wordt doorgenomen, bijvoorbeeld in het maandelijkse overleg met de directie.
Wat NIS2 en dienstverleners ermee te maken hebben
Voor bedrijven die onder NIS2 vallen, is de omgang met kwetsbaarheden onderdeel van de verplichtingen voor risicobeheer. De details beschrijft NIS2 en webserverbeveiliging. Maar ook zonder wettelijke plicht is een gedocumenteerd proces een voordeel, bijvoorbeeld tegenover klanten, verzekeraars en de eigen directie.
Veel stappen zijn uit te besteden, zoals het volgen van meldingen of het installeren van updates. De beslissing over risico's en het totaaloverzicht horen echter in huis te blijven. Wie het circuit volledig aan een dienstverlener overdraagt, weet in een noodgeval niet meer welke systemen hij eigenlijk heeft. Hoe u de uitvoering als routine organiseert, beschrijft Patchbeheer als proces in plaats van brandweer.
Hoe helpt PHP SOS concreet?
- Wij stellen samen met u de inventaris van uw websites en servers op als basis voor elke vergelijking.
- Wij volgen voor uw systemen de relevante meldingen en leveren een beoordeling in heldere taal met advies.
- Wij bereiden besluitnotities voor voor gevallen waarin een update niet direct mogelijk is.
- Via security-monitoring controleren wij doorlopend of systemen opvallend worden zolang een lek nog openstaat.
Conclusie: Kwetsbaarhedenbeheer in het mkb hoeft niet groot te zijn, maar wel bindend. Wie zijn systemen kent, een paar goede bronnen leest en besluiten vastlegt, reageert bij de volgende kritieke melding snel en juist.
Veelgestelde vragen
Wat is kwetsbaarhedenbeheer?
Een terugkerend proces waarmee een bedrijf beveiligingslekken in zijn systemen leert kennen, beoordeelt, verhelpt of bewust accepteert en het resultaat vastlegt. Het gaat niet om een softwaretool, maar om verantwoordelijkheden en besluiten.
Is de CVSS-score genoeg om prioriteiten te stellen?
Ze is een goed vertrekpunt, maar niet genoeg. Daarnaast telt of het getroffen systeem vanaf internet bereikbaar is, welke gegevens het verwerkt en of er al aanvallen zijn waargenomen. Een lek met een hoge score op een intern testsysteem kan wachten, een lek op de webshop niet.
Heeft een klein bedrijf hiervoor een eigen tool nodig?
In het begin niet. Een bijgehouden lijst van systemen, geabonneerde beveiligingsmeldingen en een tabel met openstaande punten volstaan. Kwetsbaarhedenscanners lonen zodra het aantal systemen groeit of controles regelmatig moeten worden aangetoond.
Mag je een kwetsbaarheid bewust niet verhelpen?
Ja, als het risico is beoordeeld, het besluit is genomen door de verantwoordelijke leiding en schriftelijk is vastgelegd, bij voorkeur met overbruggende maatregelen en een datum voor een nieuwe beoordeling.