Waarom wij continu scannen op kwetsbaarheden

1. Waarom een jaarlijkse test niet meer volstaat

Kwetsbaarhedenbeheer werd lang behandeld als een jaarlijkse gebeurtenis: één keer per jaar een penetratietest, een rapport, een lijst punten, en dan weer twaalf maanden verder. Dat model past niet meer bij hoe software vandaag wordt gebouwd en aangevallen, en het past al helemaal niet bij een AI-platform.

Wij scannen daarom continu op kwetsbaarheden in de omgeving waarin de kantoren werken, in plaats van periodiek. Deze pagina legt uit waarom dat een wezenlijk verschil is, wat er in zo'n programma hoort, en — even belangrijk — wat het níet oplost.

2. Het rekensommetje achter "continu"

Waarom periodiek scannen structureel te laat is, is eenvoudiger uit te leggen dan het klinkt.

Stel dat je één keer per jaar test. Dan is de gemiddelde tijd tussen het moment dat een kwetsbaarheid in jouw omgeving ontstaat en het moment dat je het weet, ongeveer een half jaar. Test je per kwartaal, dan is dat zes weken. Scan je dagelijks, dan is het minder dan een dag. En de tijd die een aanvaller nodig heeft om een publiek bekend gemaakte kwetsbaarheid uit te buiten, wordt korter, niet langer: bij ernstige meldingen in veelgebruikte software zijn dat inmiddels vaak dagen.

Er is een tweede reden, en die is minder bekend. Bij een periodieke test zoek je naar kwetsbaarheden die op dat moment bekend zijn, in de versie die op dat moment draait. Maar het meest voorkomende scenario is anders: de software verandert niet, maar de kennis over de software wel. Er wordt een kwetsbaarheid gepubliceerd in een bibliotheek die jij al twee jaar gebruikt. Je code is niet gewijzigd, je configuratie niet, en toch ben je vanaf dat moment kwetsbaar. Alleen een programma dat continu tegen actuele meldingen aan houdt, ziet dat.

3. Wat wij scannen

Een volwaardig programma dekt vijf lagen. Dit is de structuur waarop je elke leverancier kunt uitvragen, inclusief ons.

4. De lagen die AI erbij heeft gebracht

Dit is het deel dat een klassiek kwetsbaarhedenprogramma niet dekt, en het is precies waarom een AI-platform meer nodig heeft dan een standaardscanner. Een scanner zoekt naar bekende fouten in code en configuratie. Bij AI zitten drie van de belangrijkste risico's daar helemaal buiten.

1. Instructies die in inhoud zijn verstopt. Een taalmodel kent geen verschil tussen "instructies van mijn opdrachtgever" en "tekst die ik moet verwerken". Iemand kan in een pdf-factuur, in een e-mail of zelfs in het omschrijvingsveld van een bankmutatie een instructie verstoppen. Dat is geen bug in code — geen enkele scanner vindt dit. Wat je ertegen doet is testen: een vaste set gevallen met verborgen instructies in verschillende vormen, die het systeem elke keer moet weerstaan. Zie prompt injection.
2. Gedragsverandering zonder dat er iets is gewijzigd. Een modelaanbieder vervangt het onderliggende model of past zijn systeeminstructies aan. Aan onze kant is niets gewijzigd, en toch gedraagt het systeem zich anders. Er is geen changelog die jouw specifieke uitkomsten dekt. Wat je ertegen doet is een set vragen waarvan het juiste antwoord bekend is, die automatisch en periodiek meedraait. Zie stille modelwijzigingen.
3. Rechten en grenzen van de agent. Kan hij alleen lezen wat de vragende gebruiker mag lezen? Zijn stamgegevens onaantastbaar? Zijn er harde limieten op stappen, tijd en besteding? Dat zijn geen kwetsbaarheden maar ontwerpeigenschappen — en ze moeten net zo periodiek worden getoetst als een patchniveau. Zie te veel rechten.

5. Vinden is de helft: het herstelproces

Een scanner die dagelijks een lijst produceert die niemand oppakt, is een kostenpost met een schijnzekerheid. Het proces eromheen bepaalt of continu scannen iets waard is. Vier onderdelen:

• Prioriteren op werkelijk risico, niet op de score. Een ernstige kwetsbaarheid in een component die bij ons niet bereikbaar is, is minder urgent dan een middelmatige in een component die rechtstreeks aan het internet hangt. Blind op scores werken leidt tot veel werk met weinig effect.
• Vaste hersteltermijnen per ernstniveau, vooraf vastgesteld — anders wordt elke termijn achteraf goedgepraat.
• Verifiëren dat het echt weg is. Een gesloten melding zonder hertest is een aanname.
• Registreren wat je bewust niet oplost, en waarom. Dat is geen zwakte maar volwassenheid: elke organisatie accepteert risico's, en het verschil zit erin of dat een besluit is of een vergissing.

6. Wat scannen níet vindt

Eerlijk over de grenzen, want anders is het marketing.

Met andere woorden: continu scannen is een noodzakelijke maatregel, geen voldoende maatregel. In de rangorde van beheersmaatregelen uit deze reeks staat "onmogelijk maken" bovenaan en "instructie geven" onderaan; scannen zit ertussenin, aan de kant van het opsporen in plaats van het voorkomen. Zie de rangorde van beheersmaatregelen.

7. Wat jij ervan terugziet

In het gunstigste geval: niets. Een goed werkend kwetsbaarhedenprogramma is onzichtbaar — updates gaan door zonder dat je erover nadenkt, en de melding die vanmorgen wereldwijd is gepubliceerd, is al beoordeeld voordat jij ervan hoort.

Wat je wel merkt, en zou moeten willen merken:

• Bij een relevant incident of een ernstige melding die jou raakt: bericht, met wat er aan de hand is en wat het voor jou betekent. Ook als er verder niets van je gevraagd wordt.
• Bij een datalek: melding binnen een afgesproken termijn, met de informatie die je nodig hebt om je eigen beoordeling te doen. Jij hebt zelf 72 uur, gerekend vanaf redelijke zekerheid, dus onze snelheid bepaalt jouw ruimte. Zie wanneer een AI-fout een datalek is.
• Op verzoek: onderbouwing die je in je eigen leveranciersdossier kunt leggen. Want de beoordeling van je leveranciers is jouw verplichting, niet de onze — zie wat de Europese toezichthouders daarover hebben vastgesteld.

8. En aan jouw kant van de lijn

Onze scans stoppen bij de rand van onze omgeving. Wat daarbuiten gebeurt bepaalt in de praktijk minstens zoveel — en het is precies de reden waarom de zorgplichtlijst uit de Cyberbeveiligingswet ook voor kantoren die er niet onder vallen een goede checklist is.

• Tweefactorauthenticatie of passkeys op alles wat bij klantdata kan.
• Centrale aanmelding, zodat je toegang kunt inzien en intrekken — en zodat er geen accounts op privé-e-mailadressen bestaan.
• Toegang intrekken op de dag van uitdiensttreding, ook voor tools die buiten de IT-inkoop zijn aangeschaft.
• Consumenten-AI geblokkeerd op beheerde apparaten en het kantoornetwerk.
• Documentrechten opgeruimd vóórdat je een zoekende assistent uitrolt.
• Back-ups die je ook echt een keer hebt teruggezet.
• Een periodieke controle of iemand nog rechten heeft die hij niet gebruikt.

De volledige lijst staat in technisch dichtzetten.

9. Vijf vragen die je elke leverancier kunt stellen

Ook aan ons. Als een AI-leverancier deze vijf niet schriftelijk kan beantwoorden, weet je genoeg — en het antwoord hoort in je leveranciersdossier, want die beoordeling is jouw verplichting.

1. Scan je continu of periodiek, en welke lagen dek je: afhankelijkheden, eigen code, configuratie, de draaiende applicatie, en toegangsrechten?
2. Wat zijn je hersteltermijnen per ernstniveau, en haal je die aantoonbaar?
3. Is er een externe test uitgevoerd, wanneer, en kan ik een samenvatting krijgen?
4. Hoe test je specifiek op AI-risico's — instructies verstopt in inhoud, en gedragsverandering na een modelwissel?
5. Binnen hoeveel uur meld je een incident aan mij, via welk kanaal, en wie is mijn escalatiecontact?

10. Bronnen