Methodiek

Deze pagina beschrijft hoe CyberRadar Gemeenten 3.0 tot stand komt: van het verzamelen van openbare signalen tot de gemeentelijke duiding, privacy-impactinschatting en workflowstand. De radar werkt regelgebaseerd en navolgbaar — er wordt geen gebruik gemaakt van ondoorzichtige, zelflerende modellen. Bij elke score, escalatie of duiding is daardoor te herleiden waarom die zo is uitgevallen.

De radar is casusgericht: alle signalen — dreigingen, kwetsbaarheden, dataleksignalen, leveranciersmeldingen — worden samengebracht in één centraal object, de cybercasus. Elke rol leest dezelfde casus op zijn eigen detailniveau.

1. Signalen verzamelen

De radar haalt met vaste tussenpozen openbare signalen op uit een aantal geselecteerde bronnen. Per bron is vastgelegd hoe vaak die wordt geraadpleegd. De opgehaalde items worden genormaliseerd naar één gezamenlijk formaat, zodat ze onderling vergelijkbaar zijn.

Er worden vier soorten signalen verzameld:

• dreigingen (advisories, kwetsbaarheidsmeldingen, securitynieuws);
• kwetsbaarheden (CVE-records, EPSS, KEV);
• publieke dataleksignalen (openbare meldingen via nieuwsmedia, AP- publicaties en bevestigde organisatie-uitingen);
• leverancierssignalen (incidenten en kwetsbaarheden in producten en diensten van bekende leveranciers).

2. Bronnen classificeren — bronbetrouwbaarheid

Niet elke bron weegt even zwaar. Elke bron krijgt een betrouwbaarheidsindicatie op basis van het type organisatie en het karakter van de publicatie:

De betrouwbaarheid van de bron werkt door in de zekerheids­inschatting van een casus (confidence — laag/middel/hoog/bevestigd) en in de uiteindelijke prioritering. Het actuele bronnen­overzicht staat op de bronnenpagina.

3. Cybercasussen aanmaken

Signalen die over hetzelfde onderwerp gaan, worden samengevoegd tot één cybercasus. De casusgenerator dedupliceert regelgebaseerd op CVE, titel en koppelingen, zodat dezelfde kwetsbaarheid uit drie bronnen één casus oplevert in plaats van drie.

Elke casus heeft een vast casustype: vulnerability, data_breach, supplier_incident, phishing, identity_attack, ransomware, ddos, cloud_saas, ai_threat of other. Het casustype bepaalt welke workflow van toepassing is.

4. Gemeentelijke relevantie bepalen

Een regelgebaseerde relevantie-engine vertaalt elke casus naar het gemeentelijke perspectief. Daarbij wordt gekeken naar herkende leveranciers en producten, de aard van de dreiging en de raakvlakken met gemeentelijke processen. Het resultaat is een gemeentelijke relevantiescore met een beknopte duiding van de processen en rollen die geraakt kunnen worden.

De casus krijgt drie wegingen:

• strategische relevantie (laag / middel / hoog / kritiek) — de zwaarte voor de gemeentelijke portefeuille;
• operationele urgentie (laag / verhoogd / hoog / kritiek) — hoe snel een reactie nodig is;
• escalatieniveau (operationeel / tactisch / strategisch / bestuurlijk) — wie geïnformeerd of betrokken moet worden.

5. Rolacties genereren

De radar genereert per casus regelgebaseerd case-actions voor de betrokken rollen. Voor een kwetsbaarheid kan dat een patchactie zijn voor de ISO, een detectie-opdracht voor het SOC en — bij externe leveranciers — een leveranciersuitvraag. Voor een datalek zijn dat een privacy-impactbeoordeling, een FG-actie en een SOC-monitoringsactie.

Elke actie heeft:

• een rol (CISO, ISO/patchmanagement, SOC, privacy officer, FG, leveranciersmanager, ICT-beheer, functioneel beheer, proceseigenaar, directie);
• een actietype (beoordelen, patchen, mitigeren, detecteren, leverancier uitvragen, privacy beoordelen, meldplicht beoordelen, communiceren, escaleren, risico accepteren, registreren, monitoren, rapporteren);
• een urgentie (vandaag / binnen 72 uur / deze week / monitoren / reguliere cyclus);
• een status (open, in behandeling, wacht op derde, afgerond, niet van toepassing, geëscaleerd, geaccepteerd restrisico).

6. Datalek- en privacy-impact inschatten

Wanneer een casus van type data_breach is — of wanneer een dataleksignaal aan een casus wordt gekoppeld — genereert de radar een privacy-impactduiding. Die bevat:

• of er persoonsgegevens betrokken lijken te zijn (ja / nee / onbekend);
• of er bijzondere categorieën mogelijk geraakt zijn;
• een inschatting van de mogelijke betrokkenen (een grootte-orde, geen exact aantal);
• het mogelijke risico voor rechten en vrijheden van betrokkenen (laag / middel / hoog / onbekend);
• een meldplichtindicatie (indicatie van mogelijke meldplicht — geen juridisch besluit);
• of FG-aandacht nodig is;
• aanbevolen privacy-acties.

De toon van de privacyduiding is bewust voorzichtig:

• het is een indicatie, geen vaststelling;
• het is geen juridisch advies;
• de meldplicht moet altijd door de eigen organisatie worden beoordeeld in samenspraak met de Functionaris Gegevensbescherming;
• het kader is de AP-guidance voor datalekken — de radar maakt geen zelfstandige juridische beoordeling.

Zie ook de disclaimer en uitgangspunten.

7. Workflowstand

Elke casus krijgt automatisch een workflow die hoort bij het casustype: een geordende reeks fasen, met per fase de default-acties, de condities waaronder ze van toepassing zijn, de escalatieregels en de betrokken rollen. Daardoor wordt zichtbaar:

• in welke huidige fase de casus zit;
• welke fasen al afgerond zijn;
• welke acties open staan;
• welke escalaties door de huidige condities worden getriggerd;
• welke rollen nog geen bijdrage hebben geleverd.

Workflows zijn regelgebaseerd: een fase is afgerond zodra alle van toepassing zijnde default-acties in een terminale status staan, of zodra geen van de condities meer van toepassing is. Zie het achtergronddocument case-workflows.md.

8. Scoring en onzekerheden

Op basis van de verrijkte kenmerken berekent een regelgebaseerde scoring-engine een prioriteitsscore (0–100) en een bijbehorend niveau. Zwaar wegende factoren zijn onder meer bekend actief misbruik, beschikbare exploitcode, een hoge technische ernst en een hoge gemeentelijke relevantie.

Elke score gaat vergezeld van een zekerheidsinschatting (confidence) die de bronbetrouwbaarheid en de mate van overeenstemming tussen bronnen weerspiegelt. Bij lage zekerheid hoort terughoudendheid — de radar geeft de onzekerheid expliciet weer in plaats van een schijn van precisie te wekken.

De scoring is opgebouwd in twee lagen:

• scoring 1.0 — een numerieke prioriteitsscore per dreiging;
• scoring 2.0 — een uitlegbare scoring met per regel zichtbaar welke factoren tot welke bijdrage hebben geleid.

9. Menselijke review

De radar is grotendeels geautomatiseerd. Daarnaast is er een beheeromgeving waarmee een beheerder casussen, acties, privacy­duidingen, risicoacceptaties en bewijsstukken kan beoordelen, corrigeren, (her)classificeren of archiveren. Niet elk item wordt handmatig gecontroleerd; menselijke review wordt vooral ingezet om de kwaliteit te bewaken en duidelijke onjuistheden te herstellen. Handmatige correcties worden navolgbaar vastgelegd in de actie- en evidence-historie.

Beperkingen

De methodiek is bewust eenvoudig en navolgbaar gehouden. Dat betekent ook dat de inschattingen algemeen van aard zijn: ze houden geen rekening met de specifieke infrastructuur, leveranciers­contracten en reeds genomen maatregelen van een individuele gemeente. Voor datalekken geldt nadrukkelijk dat de radar alleen publieke signalen toont — meldingen die uitsluitend bij de Autoriteit Persoonsgegevens of de betrokken organisatie bekend zijn, ontbreken hier per definitie.

Zie ook de disclaimer en uitgangspunten.