Meten voordat je ingrijpt

De aanval waar dit mee begon. Bij ClickFix laat een nagemaakte pagina de gebruiker zelf een commando plakken en uitvoeren, meestal via Win+R of PowerShell. Geen exploit, geen bijlage: de gebruiker doet het werk. Wat daarna komt is een infostealer of remote access tool, en uiteindelijk exfiltratie.

De verleiding is dan om meteen te blokkeren: Win+R uit, PowerShell dicht. Dat is precies waar dit stuk tegen waarschuwt. Bij een gemeentelijke organisatie bleek van miljoenen PowerShell-starts in een maand bijna 99 procent machine-automatisering, waaronder de sensor van de eigen endpointbescherming. Een botte blokkade had de eigen beveiliging gebroken.

Vandaar de aanpak: meet eerst wat er feitelijk draait, bepaal dan wat je afdwingt. ClickFix is het vertrekpunt, maar de werkwijze is breder toepasbaar: van de werkplek tot het netwerk, en van detectie tot de vraag wat er in je omgeving feitelijk gebeurt.

Dit stuk bevat de methode: waarom je eerst meet, en in welke volgorde. De uitwerking per laag staat in eigen stukken die hierboven staan opgesomd, en het bestuurlijke deel (regie, strategie, besluitvorming) in Sturen op weerbaarheid.

Gegeneraliseerd uit een concrete casus. Pas de voorbeelden aan op je eigen organisatie, leveranciers en tenant. Let bij maatregelen die verkeer of gebruik inzichtelijk maken (zoals TLS-decryptie of script-logging) op privacy, BIO2 en eventuele medezeggenschapstrajecten.

Wat je hier vindt

Dit stuk bevat de methode. De uitwerking per laag staat in eigen stukken, zodat je kunt lezen wat voor jou geldt zonder de rest door te hoeven.

Drie uitgangspunten

1. Meet voordat je ingrijpt. Stel het feitelijke gebruik vast voordat je iets beperkt. Dat voorkomt uitval en laat zien hoe groot de impact werkelijk is, meestal kleiner dan gedacht.
2. Vertrouw op data, niet op tekeningen. Een netwerktekening of een "we hebben het aanstaan" is een aanname. Toets de werkelijkheid: rule-hits, configuratie-export, telemetrie.
3. Aangezet is niet hetzelfde als beheerd. Een tool met standaardconfiguratie die niemand bijhoudt, beschermt niet aantoonbaar. Leg bestaan, opzet, werking en eigenaarschap vast.

Volgorde van aanpak

1. Meet de werkplek: wat draait er echt, wie gebruikt wat. Werkplekanalyse.
2. Toets identiteit en e-mail: aan staan is niet hetzelfde als gekoppeld en actief. Identiteit en e-mail meten.
3. Analyseer netwerk en firewall uit data: brede regels, beheertoegang, zicht, segmentatie. Netwerk en firewall analyseren uit data.
4. Leg de killchain naast je controls: waar knijp je, waar zit een gat. De killchain naast je controls.
5. Beleg regie en resultaatverplichting, en kies een strategie. Sturen op weerbaarheid.

De methode: evidence-based posture verhogen

Deze aanpak is opzettelijk nuchter. Geen catchy oneliners, wel toetsbare stappen.

Drie principes

1. Meet voordat je ingrijpt

Voordat je een maatregel afdwingt (Win+R uit, PowerShell beperken, een firewallregel versmallen), stel je het feitelijke gebruik vast. Dat doet twee dingen: het laat de werkelijke impact zien (meestal kleiner dan gevreesd) en het voorkomt dat je legitiem werk of beheer breekt. Een voorbeeld uit de praktijk: van miljoenen PowerShell-starts in een maand bleek bij een gemeente bijna 99% machine-automatisering - waaronder de eigen sensor van de endpointbescherming. Een botte blokkade had de eigen beveiliging gebroken.

2. Vertrouw op data, niet op tekeningen

Een netwerktekening toont de bedoeling, niet de werkelijkheid. "We hebben ASR aanstaan" is een aanname totdat je de koppeling aan een gebruikersgroep hebt geverifieerd. Toets met:

• telemetrie (Advanced Hunting, logs);
• configuratie-export (firewallregels, hit-counts, routeringstabellen);
• de daadwerkelijke koppeling/scope van een beleidsregel.

3. Aangezet is niet hetzelfde als beheerd

Toets elke maatregel op vier niveaus van oplopende zekerheid:

Managed dienstverlening is meer dan de aanknop indrukken

Een "managed" dienst omvat gedurende de hele levenscyclus: bijhouden (updates, dreigingsinfo), beheren (configuratie, afwijkingen, prestaties), optimaliseren, functionaliteit aanpassen, en verantwoorden (rapportage, eigenaarschap). Een tool installeren met standaardinstellingen is daarvan alleen de eerste stap. Als de dienstverlening managed is gecontracteerd dan is de optielijst klein, een fireall waar de regelset niet periodiek wordt gevalideerd en voorzien wordt van een risicoletter aan de klant waar nodig is geen managed dienst.

IST → SOLL als werkvorm

Beschrijf per component de huidige stand (IST) en de gewenste stand (SOLL), met een statuskleur en een actiehouder. Houd de SOLL-ambitie expliciet: een verdedigbare ondergrens (richting BIO2 en audit) is iets anders dan "best-practice". Maak die keuze bewust, anders overvraag je de organisatie.

Sjabloon:

Statuskleuren: groen = ingericht · oranje = deels/aandacht · rood = nog niet ingericht · grijs = te bevestigen.

Volgorde

1. Meet de werkplek. Daar is de meeste telemetrie en de meeste laaghangende winst.
2. Toets de configuratie op de werkplek en bij identiteit en e-mail. Onderscheid "aan" van "gekoppeld en actief".
3. Analyseer netwerk en firewall uit data. Brede regels, beheertoegang, zicht op verkeer, segmentatie.
4. Leg de killchain naast je controls. Waar knijp je de aanval, waar zit nog een gat.
5. Beleg regie en kies een strategie.

Aantoonbaarheid en herijking

Leg vast wat je hebt gemeten en wanneer. Een maatregel die ooit aanstond kan weer afvallen (drift). Plan periodieke herijking en, waar mogelijk, een gecontroleerde aanvalssimulatie om detectie en preventie te toetsen - niet aannemen dat het werkt, maar het laten zien.

Herbruikbare query's

De zes KQL-query's voor Advanced Hunting staan bij de handleiding waar ze bij horen: Werkplekanalyse op het Microsoft-platform. Daar staat per query waarvoor hij dient (ClickFix-detectie, Win+R-gebruik, PowerShell-categorisatie, mshta) en hoe je de parent-processen en uitsluitingen op je eigen omgeving aanpast.

Werken met een LLM

Dit stuk is geschreven om mee te werken in een taalmodel. Neem de tekst en de query's mee als context, en laat het model je helpen bij het categoriseren van je eigen meetresultaten en het invullen van de IST/SOLL- en RACI-sjablonen.

Weeg wel af wat je waar doet. Kun je het zelf, prima. Heb je een lokaal model op geschikte hardware, doe het daarin. Anders is het een risicoafweging: wat is het risico van het niet gebruiken van een model tegen het risico dat je meetgegevens bij een aanbieder terechtkomen? Zet je meetresultaten liever geanonimiseerd in, en houd de uitkomsten onder versiebeheer zodat de verbetering aantoonbaar en herhaalbaar blijft.

Hoe dit samenhangt met de andere stukken

Herkomst

Gegeneraliseerd uit een concrete casus bij een gemeentelijke organisatie, ingebracht in de commons. De voorbeelden en aantallen komen uit die casus; de aanpak is bedoeld om over te nemen, niet om na te doen.

Licentie

EUPL-1.2, zie de licentie van de kennisbank.