Detection engineering voor een auditklaar SIEM in 2026
Detection engineering voor een auditklaar SIEM in 2026
Op dinsdagochtend om 08:17 ontvangt de CISO van een groeiende fintech-SaaS-aanbieder binnen één minuut twee berichten.
Het eerste komt van de SOC-analist: “We hebben 312 alerts op mislukte aanmeldingen van afgelopen nacht. De meeste lijken ruis, maar één account had na herhaalde mislukte pogingen een succesvolle aanmelding vanuit een nieuwe geografische locatie.”
Het tweede komt van de compliancemanager: “Onze enterprise-klant heeft gevraagd om bewijsmateriaal dat onze SIEM-detecties zijn getest, getuned, aan een eigenaar zijn toegewezen en zijn gekoppeld aan verplichtingen voor incidentmelding onder NIS2, DORA en GDPR. Ze willen dit vóór de verlenging ontvangen.”
Een jaar eerder was de CISO opgelucht toen het bedrijf de ISO 27001:2022-audit had doorstaan. Het certificaat hielp om enterprise-klanten binnen te halen. Maar één opmerking van de auditor bleef terugkomen in bestuursvergaderingen: “Uw dekking voor logverzameling is sterk, maar de koppeling tussen SIEM-alerts en een gedocumenteerde, risicogebaseerde detectiestrategie is onduidelijk. Hoe toont u aan dat de regels doeltreffend zijn? Hoe beheerst u alert-ruis? Hoe zou u dit verdedigen tegenover een DORA- of NIS2-toezichthouder?”
Dat is de realiteit van detection engineering in 2026. Het oude pakket met bewijsmateriaal — SIEM-schermafbeeldingen, lijsten met logbronnen en retentie-instellingen — is niet langer voldoende. Toezichthouders, klanten, auditors en besturen willen bewijs dat monitoring als levenscyclus wordt beheerst. Zij willen zien waarom elke detectie bestaat, welk risico deze beperkt, wie eigenaar is, hoe deze is getest, hoe tuningbesluiten zijn goedgekeurd, hoe alerts incidenten worden en of het bewijsmateriaal tijdige wettelijke melding kan ondersteunen.
Veel organisaties ontdekken dezelfde pijnlijke kloof. Ze verzamelen logs, maar kunnen niet aantonen dat de logging volledig is. Ze genereren alerts, maar kunnen geen tuninghistorie tonen. Ze escaleren incidenten, maar kunnen het besluitvormingstraject dat een gebeurtenis tot een meldingsplichtig incident maakte niet reconstrueren. Ze besteden SOC-activiteiten uit, maar kunnen geen bewijsmateriaal voor leverancierstoezicht overleggen. Ze claimen ISO-afstemming, maar hun Verklaring van Toepasselijkheid legt niet uit hoe logging, monitoring en incidentrespons NIS2, DORA of GDPR ondersteunen.
Detection engineering is niet langer alleen het vak van Sigma-regels, correlatiezoekopdrachten of gedragsanalyses schrijven. Het is de discipline waarmee SIEM-use cases worden omgezet in beheerde beheersmaatregelobjecten binnen het ISMS.
Waarom detection engineering een compliancekwestie werd
NIS2, DORA en GDPR schrijven uw SOC niet voor welke SIEM-query het moet schrijven. Ze scheppen wel duidelijke verwachtingen dat beveiligingsgebeurtenissen tijdig worden gedetecteerd, beoordeeld, geëscaleerd en met bewijsmateriaal worden onderbouwd.
NIS2 is van toepassing op veel essentiële en belangrijke entiteiten, waaronder aanbieders van digitale infrastructuur, aanbieders van beheerde diensten, aanbieders van beheerde beveiligingsdiensten en bepaalde digitale aanbieders. Voor detection engineering ligt het governancesignaal in de artikelen 20 en 21. Bestuursorganen moeten cyberbeveiligingsrisicobeheersmaatregelen goedkeuren, toezicht houden op de implementatie en cyberbeveiligingstraining ontvangen. Maatregelen moeten passend, proportioneel en gebaseerd zijn op een all-hazards-benadering. De minimumgebieden omvatten incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige ontwikkeling, beoordeling van doeltreffendheid, basale cyberhygiëne, toegangscontrole, beheer van bedrijfsmiddelen en, waar passend, MFA en beveiligde communicatie.
Het rapportagesignaal staat in Article 23. Essentiële en belangrijke entiteiten moeten significante incidenten zonder onnodige vertraging melden via een gefaseerd proces: een vroege waarschuwing binnen 24 uur na bewustwording, een incidentmelding binnen 72 uur, updates wanneer daarom wordt gevraagd, en een eindrapport uiterlijk één maand na de incidentmelding. Een SIEM-alert is niet automatisch een meldingsplichtig incident, maar als de organisatie niet kan aantonen wanneer bewustwording plaatsvond, hoe de ernst werd beoordeeld en wie het escalatiebesluit nam, wordt de rapportageklok moeilijk verdedigbaar.
DORA legt de lat hoger voor financiële entiteiten. Het is van toepassing vanaf 17 januari 2025 en stelt uniforme eisen voor ICT-risicobeheer, melding van ICT-incidenten, testen van digitale operationele weerbaarheid, ICT-risico van derden en toezicht. Voor financiële entiteiten die ook onder nationale omzetting van NIS2 zijn geïdentificeerd, fungeert DORA doorgaans als de sectorspecifieke rechtshandeling van de Unie voor overeenkomstige vereisten voor ICT-risicobeheer en rapportage. DORA Article 17 is centraal voor detection engineering omdat het een beheerproces voor ICT-gerelateerde incidenten vereist om incidenten te detecteren, te beheren en te melden, ICT-gerelateerde incidenten en significante cyberdreigingen te registreren, oorzaken te identificeren, vroegtijdige waarschuwingsindicatoren vast te stellen, incidenten te classificeren, escalatie te definiëren, met stakeholders te communiceren en majeure incidenten aan het hoger management en het bestuursorgaan te rapporteren.
GDPR voegt de laag van privacyverantwoording toe. Article 5 vereist passende beveiliging en verantwoordingsplicht. Article 33 vereist melding van een inbreuk in verband met persoonsgegevens aan de toezichthoudende autoriteit zonder onnodige vertraging en, waar haalbaar, uiterlijk 72 uur nadat men kennis heeft gekregen van de inbreuk. Voor SIEM-programma’s betekent dit dat de organisatie moet kunnen aantonen hoe ongeautoriseerde toegang, verdachte authenticatie, misbruik van privileges, afwijkende verwerking en potentiële data-exfiltratie worden gedetecteerd en beoordeeld.
ISO/IEC 27001:2022 vormt de ruggengraat van het managementsysteem. Clausules 4 tot en met 10 vereisen context, eisen van belanghebbenden, reikwijdte, leiderschap, risicobeoordeling, risicobehandeling, operationele planning en beheersing, monitoring en meting, interne audit, directiebeoordeling en voortdurende verbetering. ISO/IEC 27002:2022 biedt praktische richtlijnen voor Annex A-beheersmaatregelen, waaronder 8.15 Logging, 8.16 Monitoringsactiviteiten, 8.17 Kloksynchronisatie, 5.24 Planning en voorbereiding van informatiebeveiligingsincidentbeheer, 5.25 Beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen, 5.26 Respons op informatiebeveiligingsincidenten, 5.27 Leren van informatiebeveiligingsincidenten, 5.28 Verzamelen van bewijsmateriaal, 5.31 Wettelijke, statutaire, regelgevende en contractuele eisen, 5.33 Bescherming van registraties en 5.34 Privacy en bescherming van PII.
De kern is eenvoudig: detection engineering is waar wettelijke termijnen en technische werkelijkheid elkaar raken.
Van “wij verzamelen logs” naar “wij beheren detecties”
Een volwassen detectieprogramma begint met een betere vraag.
Niet: “Hebben we een SIEM?”
Maar: “Kunnen we aantonen dat onze detecties risicogebaseerd, getest, getuned, gemonitord, geëscaleerd en verbeterd zijn?”
Clarysec’s enterprise Informatiebeveiligingsbeleid legt de governancebasis vast:
“Alle geïmplementeerde beheersmaatregelen moeten auditeerbaar zijn, worden ondersteund door gedocumenteerde procedures en beschikken over bewaard bewijsmateriaal van de werking.”
Die zin verandert de manier waarop SIEM-werk wordt beheerd. Een detectie is niet voltooid wanneer de query is uitgerold. Zij is voltooid wanneer de organisatie de procedure, het bewijsmateriaal en de operationele registratie daarachter kan tonen.
Het Beleid voor logging en monitoring maakt dit operationeel. Voor enterprise-omgevingen vereist clausule 5.2.2 dat het SIEM:
“Regelgebaseerde alarmering en correlatie ondersteunt”
Hetzelfde beleid vereist ook:
“Alertdrempels moeten zijn gebaseerd op contextueel gedrag en correlatie (bijv. frequentie van mislukte aanmeldingen, indicatoren voor laterale beweging).”
Voor kleinere organisaties biedt het Beleid voor logging en monitoring voor het mkb proportionele formuleringen die nog steeds auditeerbaarheid ondersteunen:
“Als gecentraliseerde logging (bijv. SIEM of een clouddashboard) wordt gebruikt, moet deze integriteitscontroles en toegangscontrole ondersteunen”
Het vereist ook:
“Alerts moeten tijdig worden beoordeeld en gedocumenteerd, inclusief de uitkomst van de afhandeling”
En voor escalatie:
“Alerts met hoge prioriteit moeten binnen 24 uur worden geëscaleerd naar de algemeen directeur en de privacycoördinator”
Dat is de brug die veel mkb-organisaties nodig hebben. Ze hebben mogelijk geen intern 24x7-SOC, maar ze kunnen nog steeds aantonen dat alerts worden beoordeeld, uitkomsten worden gedocumenteerd, logs worden beschermd en gebeurtenissen met hoge prioriteit verantwoordelijke leidinggevenden bereiken.
De auditklare levenscyclus voor SIEM-use cases
Clarysec adviseert om elke SIEM-detectie te behandelen als een mini-beheersmaatregel met een levenscyclusregistratie. De levenscyclus moet eenvoudig genoeg zijn voor de operatie, maar gestructureerd genoeg voor auditors.
| Levenscyclusfase | Wat het team doet | Te bewaren bewijsmateriaal | Compliancewaarde |
|---|---|---|---|
| 1. Risicotrigger | Koppel de use case aan een risicoscenario, regelgevende verplichting, dreigingsinformatie of recent incident | Vermelding in het risicoregister, dreigingsscenario, mapping van vereisten | Laat zien waarom de detectie bestaat |
| 2. Detectieontwerp | Definieer gedrag, gegevensbronnen, detectielogica, ernst en verwachte respons | Use-case-specificatie, lijst met gegevensbronnen, regellogica, ernstmatrix | Laat doelbewust ontwerp zien |
| 3. Gegevensvalidatie | Bevestig dat logs worden gegenereerd, doorgestuurd, van tijdstempels voorzien, door parsers verwerkt en beschermd | Validatie van logbronnen, parsercontroles, NTP-bewijsmateriaal, bewijsmateriaal voor toegangscontrole | Ondersteunt reconstructie van incidenten |
| 4. Ontwikkelbeoordeling | Laat de regel peer reviewen en bevestig afstemming op risico- en responsvereisten | Beoordelingsnotities, versiehistorie, goedkeuringsregistratie | Laat beheerste wijziging zien |
| 5. Test | Voer een veilige simulatie, tabletopoefening, red-teamscenario of afgespeelde gebeurtenis uit | Testticket, schermafbeeldingen, gebeurtenis-ID, resultaat, defecten | Bewijst dat de detectie werkt |
| 6. Uitrollen en tunen | Rol uit in productie, beoordeel vroege alerts en pas drempels of verrijking aan | Wijzigingsregistratie, onderbouwing van tuning, goedkeuring | Bewijst dat alertmoeheid wordt beheerst |
| 7. Triage | Beoordeel alertkwaliteit, bedrijfscontext, false positives en impact | Triagenotities, analistenbesluit, sluitingsreden | Ondersteunt gebeurtenisbeoordeling |
| 8. Escaleren | Routeer geldige gebeurtenissen naar incidentrespons, privacy, juridische zaken of management | Escalatieticket, tijdstempels, meldingen | Ondersteunt tijdsbewijs voor NIS2, DORA en GDPR |
| 9. Beoordelen of uitfaseren | Meet prestaties, actualiseer de regel of faseer deze uit wanneer zij niet langer relevant is | KPI-rapport, maandelijkse beoordeling, uitfaseringsregistratie | Ondersteunt voortdurende verbetering |
Deze levenscyclus sluit aan op de Zenith Blueprint: 30-stappenroadmap voor auditors. In de fase Beheersmaatregelen in werking, stap 19, Technologische beheersmaatregelen I, adviseert Clarysec:
“Zorg ervoor dat alle kritieke systemen (servers, domeincontrollers, firewalls) logs doorsturen naar uw SIEM of logcollector. Valideer dat logretentie aansluit op uw loggingbeleid (bijv. 90 dagen live, 1 jaar archief). Kies een recent incident of recente gebeurtenis en toon aan hoe u deze met uw logs hebt getraceerd.”
Die laatste zin is waar audits vaak slagen of falen. De auditor wil niet alleen weten dat logs bestaan. Hij wil zien dat een gebeurtenis over systemen heen wordt getraceerd, met tijdstempels, gecorreleerde context en een besluitvormingstrail.
De Zenith Blueprint benadrukt in stap 19 ook tijdsynchronisatie, omdat detection engineering afhankelijk is van betrouwbare tijdlijnen. Een brute-force-alert, VPN-aanmelding, endpointprocesuitvoering en actie in een cloudconsole kunnen los van elkaar lijken als klokken afwijken. Tijdens een incident kan die afwijking oorzaakanalyse en rapportage ondermijnen.
De ISO-relaties tussen beheersmaatregelen achter effectieve detectie
Clarysec’s Zenith Controls: de gids voor kruisnaleving helpt teams begrijpen hoe beheersmaatregelen uit ISO/IEC 27001:2022 en ISO/IEC 27002:2022 op elkaar inwerken binnen complianceraamwerken. De gids creëert geen afzonderlijke “Zenith controls”. Hij koppelt en verklaart relaties tussen erkende beheersmaatregelen, auditbewijsmateriaal en complianceverwachtingen.
Voor beheersmaatregel 8.15, Logging, legt Zenith Controls uit dat logging de fundamentele gegevenslaag voor monitoring is. Voor beheersmaatregel 8.16, Monitoringsactiviteiten, benadrukt de gids dat monitoring afhankelijk is van logs om beveiligingsgebeurtenissen te analyseren, afwijkingen te detecteren en potentiële inbreuken te identificeren. De gids stelt:
“Zonder robuuste logging ontbreekt het monitoring aan gegevens; omgekeerd zouden logs zonder monitoring niet worden onderzocht om informatiebeveiligingsgebeurtenissen en afwijkingen te detecteren.”
Voor beheersmaatregel 5.25, Beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen, positioneert de gids triage als de brug tussen ruwe alerts en formele incidentafhandeling. Deze mapping is belangrijk omdat alerttuning niet alleen een SOC-kwaliteitstaak is. Zij beïnvloedt of gebeurtenissen correct worden geclassificeerd, of bewijsmateriaal wordt bewaard en of het management kan vertrouwen op incidentmetrieken.
| Beheersmaatregelgebied ISO/IEC 27002:2022 | Interpretatie voor detection engineering | Veelvoorkomend falen | Clarysec-bewijsmateriaal |
|---|---|---|---|
| 8.15 Logging | Genereer, bescherm, bewaar en analyseer beveiligingsrelevante logs | Kritieke logs ontbreken, zijn onvolledig of kunnen worden gewijzigd | Register van logbronnen, retentiebewijsmateriaal, integriteitscontroles |
| 8.16 Monitoringsactiviteiten | Analyseer logs en gedrag op afwijkingen en onderneem vervolgens actie | Alerts bestaan, maar worden niet beoordeeld of getuned | Use-casebibliotheek, tickets voor alertbeoordeling, tuninglogboek |
| 8.17 Kloksynchronisatie | Handhaaf consistente tijd over systemen heen | Tijdlijnen kunnen niet worden gereconstrueerd | NTP-configuratie, controles op klokafwijking, auditschermafbeeldingen |
| 5.25 Beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen | Beslis of een gebeurtenis goedaardig, verdacht of een incident is | Geen gedocumenteerde besluitcriteria | Triagematrix, criteria voor incidentdrempels, escalatiebewijsmateriaal |
| 5.26 Respons op informatiebeveiligingsincidenten | Dam in, elimineer, communiceer en herstel | Incidentproces start te laat | IR-ticket, tijdlijn, communicatie, geleerde lessen |
| 5.28 Verzamelen van bewijsmateriaal | Bewaar logs, momentopnamen en forensisch materiaal | Bewijsmateriaal wordt overschreven of is niet geauthenticeerd | Chain-of-custody, beschermde registraties, forensische export |
| 5.33 Bescherming van registraties | Bescherm audit- en incidentregistraties tegen verlies of manipulatie | Bewijsmateriaal is niet betrouwbaar | Toegangscontrole, retentieconfiguratie, bewijsmateriaal voor onveranderbare opslag |
| 5.34 Privacy en bescherming van PII | Monitor risico’s voor persoonsgegevens proportioneel | Overmatige logging of zwakke beoordeling van inbreuken | Monitoring van PII-toegang, privacybeoordeling, werkblad voor inbreuken |
De levenscyclus wordt auditeerbaar wanneer deze relaties zichtbaar zijn in het ISMS. In de Zenith Blueprint, fase Risicobeheer, stap 13, planning van risicobehandeling en Verklaring van Toepasselijkheid, adviseert Clarysec om beheersmaatregelen aan risico’s en clausules te koppelen, Annex A-verwijzingen toe te voegen aan risicobehandelingsplannen en te vermelden waar beheersmaatregelen GDPR, NIS2 of DORA ondersteunen. Voor detection engineering moet de SoA-vermelding voor logging en monitoring niet alleen “Geïmplementeerd” zeggen. Zij moet logbronnen, SIEM-dekking, de levenscyclus voor alert-use cases, incidentkoppeling, bewaring van bewijsmateriaal en leveranciersafhankelijkheden beschrijven.
Twee praktische use cases die alerts omzetten in bewijsmateriaal
Een detection-engineeringprogramma wordt concreet wanneer het wordt toegepast op scenario’s met een hoog risico. Twee veelvoorkomende voorbeelden zijn misbruik van geprivilegieerde toegang en data-exfiltratie door insiders.
Use case 1: impossible travel gevolgd door geprivilegieerde actie
Een fintechplatform gebruikt SSO, MFA en privileged access management (PAM) voor productiebeheer. Het risicoscenario is ongeautoriseerde toegang tot productiek klantgegevens met gecompromitteerde beheerdersreferenties. GDPR-relevantie bestaat omdat persoonsgegevens kunnen worden geraadpleegd. DORA-relevantie bestaat omdat ICT-systemen die financiële diensten ondersteunen kunnen worden geraakt. NIS2-relevantie kan bestaan afhankelijk van de sector en classificatie van de entiteit.
De detectie correleert SSO-logs, VPN-logs, cloud-IAM-logs en PAM-activiteitenlogs. Zij triggert wanneer dezelfde identiteit zich vanuit twee geografisch ver van elkaar verwijderde locaties binnen een onmogelijk tijdsvenster authenticeert en vervolgens een geprivilegieerde actie uitvoert, zoals roltoewijzing, toegang tot een productiedatabase of wijziging van een security group.
Ernst is contextueel. Impossible travel zonder geprivilegieerde actie kan middelmatig zijn. Impossible travel gevolgd door een geprivilegieerde actie is hoog. Impossible travel gevolgd door gegevensexport is kritiek. Het ernstmodel moet meewegen of het account een break-glass-account, productiebeheerder, servicedeskmedewerker of gewone gebruiker is.
Testen moet gebruikmaken van een gecontroleerd testaccount, gesimuleerde aanmeldlocaties of afgespeelde logs in een test-SIEM-index. Bewijsmateriaal moet gebeurtenis-ID’s, schermafbeeldingen, analistennotities en de verwachte respons omvatten. Tuning moet de regel verrijken met bekende VPN-egressbereiken, apparaatvertrouwen, MFA-resultaat en uitsluitingen voor service principals, zonder het risico volledig te onderdrukken.
Use case 2: potentiële data-exfiltratie door een insider
Een risicobeoordeling identificeert een risico met hoge prioriteit: een geautoriseerde medewerker die gevoelige klantgegevens exfiltreert. De detectie begint met een eenvoudige regel: genereer een alert als een gebruiker binnen één uur meer dan 500 MB downloadt uit de productiedatabase met klantgegevens.
In stille modus genereert de regel honderden alerts omdat het data-scienceteam regelmatig grote datasets ophaalt. Dit is waar de eis uit het Beleid voor logging en monitoring voor contextueel gedrag en correlatie cruciaal wordt. Een betere regel genereert een alert met hoge prioriteit wanneer een gebruiker die niet tot de goedgekeurde data-sciencegroep behoort, meer dan 500 MB downloadt uit de productiedatabase met klantgegevens, vanaf een ongebruikelijk apparaat, buiten een goedgekeurd taakvenster of gevolgd door upload naar een niet-goedgekeurde bestemming.
De test is eenvoudig. Een red-team- of purple-team-oefening probeert gecontroleerde exfiltratie met een testaccount. Het SOC bevestigt of de alert afgaat, of het ticket wordt aangemaakt, of escalatie plaatsvindt en of bewijsmateriaal wordt bewaard.
Voor kleinere teams verankert het Incidentresponsbeleid voor het mkb de wettelijke tijdlijn:
“Responstermijnen, inclusief gegevensherstel en meldingsverplichtingen, moeten worden gedocumenteerd en afgestemd op wettelijke vereisten, zoals de GDPR-vereiste om een inbreuk in verband met persoonsgegevens binnen 72 uur te melden.”
Het Beleid inzake bewijsverzameling en forensisch onderzoek voor het mkb voegt een proportionele eis voor bewijsmateriaal toe:
“Voor elk incident moet een eenvoudig chain-of-custody-logboek (bijv. Excel-bestand of sjabloondocument) worden bijgehouden.”
Voor beide use cases moet het pakket met bewijsmateriaal de use-case-specificatie, risico-eigenaar, lijst met logbronnen, testresultaat, tuninghistorie, triageticket, escalatietijdlijn, chain-of-custody-registratie en notitie na beoordeling omvatten. Dit is het verschil tussen zeggen “het SIEM gaf een alert” en bewijzen “de organisatie heeft volgens goedgekeurde criteria gedetecteerd, beoordeeld, geëscaleerd en bewijsmateriaal veiliggesteld.”
Alerttuning is een compliancebeheersmaatregel
Alertmoeheid creëert compliancerisico. Als analisten alerts routinematig negeren, drempels willekeurig zijn of onderdrukkingen niet zijn gedocumenteerd, bestaat monitoring op papier maar faalt zij operationeel.
Een goede tuningregistratie beantwoordt vijf vragen:
- Wat is gewijzigd?
- Waarom is het gewijzigd?
- Welk bewijsmateriaal ondersteunt de wijziging?
- Wie heeft het goedgekeurd?
- Welk risico resteert?
Neem een detectie voor laterale beweging die 400 alerts per week genereert omdat kwetsbaarheidsscanners zich over endpoints heen authentiseren. Een zwakke tuningreactie is: “Scanneraccount onderdrukken.” Een verdedigbare reactie is: “Scanneraccount alleen onderdrukken wanneer de bronhost een goedgekeurde scanner is, de bestemming binnen de goedgekeurde scanscope valt, authenticatie plaatsvindt tijdens een goedgekeurd scanvenster en er geen interactieve aanmelding plaatsvindt. Elke afwijking blijft alertbaar.”
Het enterprise Incidentresponsbeleid versterkt dit via governancemetrieken:
“De CISO moet alle monitoring- en meetcriteria definiëren, goedkeuren en periodiek beoordelen die worden gebruikt om de doeltreffendheid van incidentrespons te evalueren. Deze metrieken moeten worden gedocumenteerd, ten minste jaarlijks worden beoordeeld en worden gebruikt als input voor ISMS-verbeteringen, interne auditplanning en post-incident herstelmaatregelen.”
Voor SIEM-use cases adviseert Clarysec de volgende metrieken.
| Metriek | Waarom dit belangrijk is | Bron van bewijsmateriaal |
|---|---|---|
| Alertvolume per use case | Detecteert ruis, drift en aanvalspatronen | SIEM-rapportages |
| False-positivepercentage | Toont de doeltreffendheid van tuning aan | Sluitingsredenen uit triage |
| Mean time to triage | Toont responsiviteit aan | Tickettijdstempels |
| Mean time to escalate | Ondersteunt gereedheid voor wettelijke rapportage | Alert- en incidenttickets |
| Slagingspercentage van detectietests | Bewijst dat use cases werken | Testregistraties |
| Gezondheid van logbronnen | Toont dekking van monitoring aan | Rapportages over SIEM-ingestie |
| Beoordelingspercentage van kritieke alerts | Toont governancediscipline aan | SOC-beoordelingslogboeken |
| Regelupdates na incidenten | Toont leren en verbetering aan | Wijzigingsregistraties en geleerde lessen |
Deze metrieken moeten input leveren voor ISO-directiebeoordeling en interne audit. ISO 27001:2022 clausules 9.1 tot en met 9.3 vereisen monitoring en meting, interne audit en directiebeoordeling. Clausules 10.1 en 10.2 vereisen voortdurende verbetering en corrigerende maatregelen. Een detectieprogramma dat alleen SIEM-uptime meet, is onvolledig. Het moet meten of beveiligingsgebeurtenissen worden omgezet in tijdige, accurate besluiten.
Detecties testen met tabletop- en red-teambewijsmateriaal
Een SIEM-use case die nooit is getest, is een aanname. In 2026 doorstaan aannames geen audits.
Het enterprise Beleid inzake beveiligingstesten en red teaming vereist een beveiligingstestprogramma dat omvat:
“red-teamoefeningen, bestaande uit scenariogebaseerde simulaties van echte aanvallen, inclusief social engineering en andere tactieken, om de detectie- en responscapaciteiten van de organisatie als geheel te testen.”
Kwetsbaarheidsscans bewijzen blootstelling. Penetratietesten bewijzen exploiteerbaarheid. Red-team- en purple-team-oefeningen bewijzen of detectie en respons onder realistische omstandigheden werken. Voor ransomware, privilege-escalatie in de cloud of data-exfiltratie moet testen telemetrie over endpoint-, identiteits-, netwerk-, cloud- en applicatielagen valideren.
De Zenith Blueprint, fase Beheersmaatregelen in werking, stap 23, draagt teams op om incidentbeheercapaciteiten te valideren door een recente gebeurtenis te selecteren of een tabletopoefening uit te voeren, besluiten, rollen en communicatie vast te leggen en het plan bij te werken met geleerde lessen. De blueprint benadrukt ook het behoud van bewijsmateriaal, inclusief logmomentopnamen, back-ups en veilige isolatie van getroffen systemen.
Een praktische testregistratie voor detecties moet omvatten:
- Scenarionaam en risico
- Datum en omgeving
- Deelnemers
- Verwachte telemetrie
- Waargenomen werkelijke telemetrie
- Alert gegenereerd of niet gegenereerd
- Triagebesluit
- Escalatiebesluit
- Bewijsmateriaal bewaard
- Geregistreerde defecten
- Datum voor hertest
Deze registratie wordt waardevol auditbewijsmateriaal omdat zij technische detectie koppelt aan incidentrespons, training en voortdurende verbetering.
Mapping van kruisnaleving voor één detectielevenscyclus
Een goed ontworpen pakket met bewijsmateriaal kan meerdere raamwerken bedienen als de mapping doelbewust is. Clarysec gebruikt Zenith Controls als gids voor kruisnaleving en legt vervolgens de mapping vast in het risicoregister en de SoA zoals aanbevolen in Zenith Blueprint stap 13.
| Raamwerk of regelgeving | Wat detection engineering moet aantonen | Bewijsmateriaal dat door de levenscyclus wordt gegenereerd |
|---|---|---|
| ISO/IEC 27001:2022 | Risicogebaseerde beheersmaatregelen, operationele beheersing, monitoring, audit, directiebeoordeling en verbetering | SoA, risicobehandelingsplan, bewijsmateriaal van werking van beheersmaatregelen, auditregistraties |
| ISO/IEC 27002:2022 | Logging, monitoring, gebeurtenisbeoordeling, respons, bewijsverzameling en leren van incidenten | Register van logbronnen, use-casebibliotheek, triagetickets, post-incident evaluaties |
| NIS2 | Toezicht door het bestuur, proportionele maatregelen, incidentafhandeling, beoordeling van doeltreffendheid en gereedheid voor gefaseerde rapportage | Managementrapportage, tijdstempels van alertescalaties, besluiten over incidenternst |
| DORA | Detectie, classificatie, escalatie, oorzaakanalyse, managementrapportage en toezicht op afhankelijkheden van derden voor ICT-incidenten | Incidentlevenscyclusregistraties, vroegtijdige waarschuwingsindicatoren, classificatiematrix, SOC-bewijsmateriaal van leveranciers |
| GDPR | Verantwoordingsplicht voor beveiliging, beoordeling van inbreuken in verband met persoonsgegevens en bewijsmateriaal van passende technische en organisatorische maatregelen | Monitoring van PII-toegang, werkblad voor beoordeling van inbreuken, chain-of-custody-logboek |
| NIST CSF 2.0 | Beheerde, risicogebaseerde cyberbeveiligingsuitkomsten over Govern, Identify, Protect, Detect, Respond en Recover | CSF-profielmapping, huidige-doel-hiaten, POA&M, bewijsmateriaal voor detectie en respons |
NIST CSF 2.0 is vooral nuttig als communicatielaag. De Govern-functie vereist organisatorische context, verwachtingen van stakeholders, wettelijke en regelgevende verplichtingen, inzicht in afhankelijkheden, risicobereidheid en risicoprioritering. Uitkomsten voor Detect, Respond en Recover helpen SIEM-engineering te vertalen naar assurance-termen voor bestuur en klanten.
DORA en NIS2 voegen ook leveranciersscrutiny toe. Financiële entiteiten blijven verantwoordelijk voor naleving wanneer ICT-diensten worden uitbesteed, moeten een register van ICT-regelingen met derden bijhouden en moeten serviceniveaus, incidentondersteuning, samenwerking, auditrechten, noodmaatregelen en exitbepalingen in contracten opnemen. NIS2 vereist beveiliging van de toeleveringsketen en inachtneming van directe leveranciers en dienstverleners.
Zenith Controls koppelt ISO/IEC 27002:2022 beheersmaatregel 8.16 Monitoringsactiviteiten aan 5.22 Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten. In de praktijk moet de SIEM-use-casebibliotheek identificeren welke detecties afhankelijk zijn van telemetrie van derden, welke leveranciersdashboards worden gemonitord en welke contractuele bepalingen toegang tot logs tijdens incidenten garanderen.
Hoe auditors hetzelfde SIEM-programma onderzoeken
Een volwassen detection-engineeringprogramma moet meerdere auditperspectieven kunnen doorstaan.
| Auditorperspectief | Kernvraag | Sterk bewijsmateriaal |
|---|---|---|
| ISO 27001-auditor | Zijn logging, monitoring en respons risicogebaseerd, beheerst en verbeterd? | Risicomapping, SoA, levenscyclusregistraties, interne audit, directiebeoordeling |
| NIS2-beoordelaar | Kan het management proportionele maatregelen en gereedheid voor gefaseerde rapportage aantonen? | Alerttijdlijnen, ernstbesluiten, managementmeldingen, incidentrapporten |
| DORA-beoordelaar | Kan de entiteit ICT-incidenten detecteren, classificeren, beheren en rapporteren? | Classificatiematrix, vroegtijdige waarschuwingsindicatoren, oorzaakanalyseregistraties, leveranciersbewijsmateriaal |
| GDPR-privacyauditor | Kan de organisatie besluiten over inbreuken in verband met persoonsgegevens beoordelen en met bewijsmateriaal onderbouwen? | PII-toegangslogs, werkblad voor inbreuken, chain-of-custody, meldingsbesluit |
| NIST CSF-assessor | Zijn governance-, detectie-, respons- en hersteluitkomsten geïntegreerd? | CSF-profiel, hiatenplan, detectiemetrieken, responsbewijsmateriaal |
| COBIT- of ISACA-achtige auditor | Wie is eigenaar van het proces en hoe wordt prestatie geborgd? | Proceseigenaarschap, KPI’s, goedkeuringen van uitzonderingen, leveranciersbeoordelingen |
Een dashboard alleen is zwak bewijsmateriaal. Een risicogekoppelde use-case-registratie met testresultaten, tuninghistorie, triagebesluiten en managementmetrieken is sterk bewijsmateriaal.
Het verdedigbare SIEM-bewijsmateriaalpakket voor 2026
Als een bestuur, klant of auditor vraagt of detecties doeltreffend zijn, bereid dan een pakket met bewijsmateriaal voor dat een coherent verhaal vertelt.
Neem minimaal op:
- Detection-engineeringstandaard of -procedure
- SIEM-use-case-inventaris met eigenaar, risico en status
- Inventaris van logbronnen met criticaliteit en gezondheidsstatus
- Retentie- en integriteitsbewijsmateriaal
- Bewijsmateriaal voor tijdsynchronisatie
- Ontwerpregistraties van use cases
- Testregistraties en resultaten van red-team- of tabletopoefeningen
- Alerttriagetickets met gedocumenteerde uitkomsten
- Tuningwijzigingslogboek met onderbouwing en goedkeuringen
- Escalatiematrix en incidentkoppeling
- Chain-of-custody-registraties voor steekproefsgewijze incidenten
- Metriekendashboard dat door het management is beoordeeld
- Bewijsmateriaal van beoordeling van leveranciers-SOC of SIEM-dienst
- SoA-mapping aan ISO-beheersmaatregelen en regelgevende verplichtingen
- Registraties van corrigerende maatregelen en geleerde lessen
De Zenith Blueprint geeft het implementatiepad. Stap 19 behandelt verbeteringen in logging en monitoring. Stap 23 valideert incidentbeheer en bewijsbehandeling. Stap 13 koppelt beheersmaatregelen aan risico’s en externe regelgeving in de SoA. Samen voorkomen deze stappen de veelvoorkomende ontkoppeling tussen het SOC, het complianceteam en de directiebeoordeling.
Maak elke SIEM-alert auditklaar
Detection engineering in 2026 is een bestuurs-, compliance- en weerbaarheidskwestie. De vraag is niet langer of uw organisatie logs heeft. De vraag is of u kunt aantonen dat uw detecties risicogebaseerd, getest, getuned, aan een eigenaar toegewezen, geëscaleerd en verbeterd zijn.
Begin deze week met één scenario met een hoog risico. Kies een detectie die ertoe doet, zoals misbruik van geprivilegieerde toegang, impossible travel, verdachte gegevensexport of ransomwaregedrag. Bouw de use-case-registratie, valideer de logbronnen, test de detectie, tune de drempel, koppel escalatie aan incidentrespons en map de beheersmaatregel in de SoA.
Herhaal dit vervolgens.
Clarysec helpt organisaties dat bewijs op te bouwen zonder teams te laten verdrinken in papierwerk. Gebruik Zenith Blueprint: 30-stappenroadmap voor auditors, het Beleid voor logging en monitoring, het Incidentresponsbeleid, Zenith Controls: de gids voor kruisnaleving en de mkb-varianten waar proportionele beheersmaatregelen nodig zijn.
Het resultaat is niet alleen een schoner SIEM. Het is een verdedigbaar detection-engineeringprogramma dat standhoudt bij klanten, auditors, toezichthouders en het bestuur.
Neem contact op met Clarysec om een auditklare SIEM-detectielevenscyclus op te bouwen, of download de Clarysec-beleids- en toolkitset om vandaag nog te beginnen met het omzetten van uw alerts met het hoogste risico in betrouwbaar compliancebewijsmateriaal.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
