ITDR-strategie voor ISO 27001, NIS2, DORA en GDPR

Om 3.00 uur op een dinsdag werd Sarah, de CISO van FinScale, wakker door het soort waarschuwing waar moderne securityleiders steeds vaker voor vrezen. De actieve sessie van een senior ontwikkelaar, slechts enkele uren eerder met MFA geauthenticeerd, werd vanaf een ongebruikelijke bron gebruikt om schema’s van productiedatabases te inventariseren.

Er was geen malware-beacon. Geen ransomwaremelding. Geen firewall-exploit. Alleen identiteit.

Het SOC detecteerde de activiteit, maar de respons verliep rommelig. Was dit een MFA-bypass, een gestolen sessietoken of een compromittering van de identiteitsprovider zelf? Wie had de bevoegdheid om de actieve sessie te beëindigen? Was het intrekken van het wachtwoord voldoende, of moest het team refreshtokens ongeldig maken, API-referenties roteren en OAuth-toestemmingen beoordelen? Tegen de tijd dat de activiteit was ingedamd, was de aanvaller 47 minuten actief geweest.

De volgende ochtend werd het beveiligingsincident een governancevraagstuk. De raad van bestuur wilde in begrijpelijke taal weten of de cyberbeveiligingshygiëne van FinScale onder NIS2 had gefaald. Het complianceteam wilde weten of de gebeurtenis onder DORA als een majeur ICT-gerelateerd incident kon worden geclassificeerd. Juridische Zaken had een verdedigbaar antwoord nodig op de vraag of persoonsgegevens waren benaderd onder GDPR Article 32 en of een beoordeling van een inbreuk in verband met persoonsgegevens vereist was. De externe auditor vroeg of de beheersmaatregelen van ISO/IEC 27001:2022 effectief werkten, en niet alleen in beleid waren vastgelegd.

Sarahs probleem was niet een gebrek aan tooling. FinScale had een identiteitsprovider, MFA, een SIEM, endpointbeheersmaatregelen, cloudlogboeken en een incidentresponsproces. Het probleem was dat identiteitsbeheer, logging, monitoring, incidentrespons, privacybeoordeling en bewijsbehandeling in silo’s opereerden.

Dat is het probleem van Identity Threat Detection and Response in 2026. ITDR is niet langer alleen een capability van security operations. Het is een overkoepelende compliance-bewijsfunctie voor ISO/IEC 27001:2022, NIS2, DORA en GDPR Article 32.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, beleidssuite en Zenith Controls: The Cross-Compliance Guide Zenith Controls helpen organisaties identiteitsaanvallen om te zetten van chaotische onderzoeken naar herhaalbare, auditeerbare processen voor beheersmaatregelen.

Waarom Identity Threat Detection and Response nu een bestuurskwestie is

Identiteitsaanvallen werken omdat zij misbruik maken van legitieme toegangspaden. Een aanvaller die een sessietoken steelt, een malafide OAuth-applicatie registreert, een serviceaccount compromitteert of een gebruiker via MFA-pushmoeheid overhaalt, kan voor systemen die alleen controleren of authenticatie is geslaagd op een geldige gebruiker lijken.

Daardoor verschilt ITDR van traditionele perimeterbeveiliging. Een volwassen programma moet antwoord kunnen geven op:

• Welke menselijke, service-, leveranciers- en applicatie-identiteiten bestaan er?
• Welke identiteiten zijn geprivilegieerd, inactief, gedeeld of extern gefedereerd?
• Welke authenticatiegebeurtenissen zijn normaal, risicovol of onmogelijk?
• Welke OAuth-toestemmingen, SaaS-tokens en API-referenties kunnen toegang geven tot gevoelige gegevens?
• Welke waarschuwingen leiden tot incidentclassificatie, bewaring van bewijsmateriaal en besluitvorming voor toezicht en melding?
• Welke beheersmaatregelen tonen aan dat toegang tot persoonsgegevens wordt beschermd met passende technische en organisatorische maatregelen?

NIS2 maakt dit een governancekwestie. Article 20 vereist dat bestuursorganen van essentiële en belangrijke entiteiten maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren, toezicht houden op de implementatie ervan en training ontvangen. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, beoordeling van de doeltreffendheid van beheersmaatregelen, cyberbeveiligingshygiëne, training, toegangscontrole, beheer van bedrijfsmiddelen en multifactorauthenticatie of continue authenticatie waar passend.

DORA legt vergelijkbare druk op financiële entiteiten. Het vereist een gedocumenteerd kader voor ICT-risicobeheer, verantwoordelijkheid van het bestuursorgaan, detectiemechanismen, incidentbeheer, classificatie, rapportage, weerbaarheidstesten en ICT-risicobeheer van derde partijen. DORA is van toepassing vanaf 17 januari 2025. Voor financiële entiteiten die ook onder NIS2 zijn aangemerkt, fungeert DORA als het sectorspecifieke regelboek voor overlappende verplichtingen op het gebied van ICT-risico en incidenten.

GDPR voegt de laag van privacyverantwoording toe. Article 5 vereist integriteit, vertrouwelijkheid en verantwoordingsplicht. Article 4 definieert een inbreuk in verband met persoonsgegevens breed, waaronder ongeautoriseerde toegang tot persoonsgegevens. Article 32 vereist passende technische en organisatorische maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen. Bij identiteitsincidenten worden logboeken, toegangscontrole, authenticatieregistraties en incidentbewijsmateriaal centraal om aan te tonen of persoonsgegevens waren beschermd.

ISO/IEC 27001:2022 is het managementsysteem dat deze verplichtingen kan samenbrengen. Clause 4 vereist dat de organisatie haar context, belanghebbenden en wettelijke, regelgevende en contractuele eisen begrijpt. Clause 6 vereist risicobeoordeling, risicobehandeling, goedkeuring door risico-eigenaren en bewaard bewijsmateriaal. Annex A omvat beheersmaatregelen voor identiteitsbeheer, veilige authenticatie, logging, monitoring, incidentbeheer, bewijsverzameling, leveranciersrelaties, clouddiensten en privacybescherming.

ITDR hoort thuis binnen het ISMS omdat identiteitsrisico pas auditeerbaar wordt wanneer het is afgebakend, toegewezen, beoordeeld, behandeld, gemonitord en verbeterd.

Het scenario van een identiteitsaanval waar toezichthouders naar kijken

Neem een cloudgebaseerde aanbieder van financiële workflows die EU-klanten bedient. De organisatie gebruikt Microsoft 365, een SaaS-platform voor klantenondersteuning, cloudinfrastructuur, een betalingsverwerker en meerdere API-gebaseerde integraties. Een senior supportengineer ontvangt een overtuigende prompt om een productiviteitsapplicatie opnieuw te verbinden. Het OAuth-toestemmingsscherm vraagt leestoegang tot de mailbox en offline toegang. De engineer keurt dit goed.

Binnen enkele minuten gebruikt de aanvaller het token om te zoeken naar klantidentificatoren en supportbijlagen. Hij inventariseert groepslidmaatschappen en probeert toegang te krijgen tot een beheerportaal. MFA was ingeschakeld, maar de aanvaller heeft het wachtwoord niet opnieuw nodig omdat het token persistente toegang verleent. Het SOC ziet ongebruikelijke mailbox-toegang, een nieuwe OAuth-applicatie, mislukte pogingen tot toegang tot het beheerportaal en activiteit vanuit een ongebruikelijke geografie.

Dit ene scenario doorkruist meerdere beheersingsdomeinen:

• Identiteitslevenscyclus, omdat de rol en machtigingen van de gebruiker de blast radius bepalen.
• Veilige authenticatie, omdat MFA tokenmisbruik op zichzelf niet heeft voorkomen.
• Logging en monitoring, omdat detectie afhankelijk is van logboeken van de identiteitsprovider, SaaS en applicaties.
• Incidentrespons, omdat inloggegevens, sessies, tokens en OAuth-toestemmingen snel moeten worden ingetrokken.
• Bewijsverzameling, omdat blootstelling van persoonsgegevens en regelgevende rapportage kunnen volgen.
• Leveranciers- en cloudgovernance, omdat SaaS-logboeken en audit-API’s deel uitmaken van de bewijsketen.
• Privacybescherming, omdat toegang tot persoonsgegevens onder GDPR moet worden beoordeeld.

De betere vraag is niet: “Welke tool faalde?” De betere vraag is of de organisatie beschikte over een ontworpen, geteste en auditeerbare ITDR-keten van beheersmaatregelen.

De ISO 27001:2022-keten van beheersmaatregelen achter effectieve ITDR

De meest effectieve ITDR-programma’s verbinden preventieve, detectieve, corrigerende en bewijsgerichte beheersmaatregelen.

In Zenith Controls wordt ISO/IEC 27001:2022 control 5.16 Identity management behandeld als een preventieve beheersmaatregel ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid. Deze is direct verbonden met 5.15 Access control, 5.17 Authentication information, 5.18 Access rights, 5.19 Information security in supplier relationships, 5.36 Compliance with policies, rules and standards for information security en 8.2 Privileged access rights.

Dat is belangrijk omdat identiteitsdetectie faalt wanneer identiteitsgovernance zwak is. Als een serviceaccount niet is gedocumenteerd, een leveranciersidentiteit onbeheerd is of een geprivilegieerde rol geen eigenaar heeft, kan monitoring een gebeurtenis detecteren, maar kunnen responders deze niet snel interpreteren.

Control 8.5 Secure authentication is een ander ITDR-anker. In Zenith Controls is deze verbonden met identiteitsbeheer, authenticatie-informatie, geprivilegieerde toegangsrechten, beperking van informatietoegang, monitoringactiviteiten, incidentbeheer en privacybescherming van persoonlijk identificeerbare informatie (PII). Authenticatie is niet afgerond bij het inloggen. Sessiebeheer, tokenbehandeling, bescherming van inloggegevens en traceerbaarheid maken deel uit van hetzelfde bewijsverhaal.

Control 8.16 Monitoring activities vormt het scharnier tussen het verzamelen van logboeken en het nemen van beslissingen. Deze is afhankelijk van 8.15 Logging en ondersteunt 5.25 Assessment and decision on information security events, 5.26 Response to information security incidents en breder incidentbeheer. Voor ITDR is 8.16 het punt waarop verdacht identiteitsgedrag een getriageerde gebeurtenis, een formeel incident of een gedocumenteerde vals-positieve melding wordt.

De tabel is geen theoretische mapping. Dit is de praktische bewijsketen die een auditor, bestuurslid of toezichthouder na een identiteitsincident zal verwachten.

Wat Clarysec-beleid toevoegt: eigenaarschap, triggers en bewijsregels

Identiteitstools creëren niet automatisch verantwoordingsplicht. Tijdens een crisis hebben responders bevoegdheid nodig om sessies in te trekken, accounts uit te schakelen, logboeken te exporteren, bewijsmateriaal te bewaren en escalatiebesluiten te nemen. Auditors moeten kunnen zien dat deze acties niet zijn geïmproviseerd.

De beleidssuite van Clarysec biedt dat operationele model.

Uit het enterprise Beleid inzake beheer van gebruikersaccounts en privileges Beleid inzake beheer van gebruikersaccounts en privileges, Governance Requirements clause 5.9:

De organisatie moet een gedetailleerde inventaris bijhouden van alle actieve en inactieve inloggegevens, geprivilegieerde accounts en serviceaccounts op systeemniveau. Deze inventaris moet continu worden bijgewerkt en elk kwartaal worden beoordeeld.

Dit maakt de identiteitsinventaris tot een expliciete beheersverplichting. Dit is vooral belangrijk omdat serviceaccounts, API-sleutels en inactieve inloggegevens veelvoorkomende blinde vlekken in ITDR zijn.

Hetzelfde beleid stelt in Governance Requirements clause 5.8:

Alle administratieve activiteiten en acties met geprivilegieerde accounts moeten op een manipulatie-indicerende wijze worden gelogd en worden gemonitord op afwijkingen of beleidsovertredingen.

Die clausule verbindt beheer van geprivilegieerde toegang met detectie. Een geprivilegieerde handeling wordt niet alleen toegestaan of geweigerd. Zij moet worden gemonitord op gedrag dat niet past bij de gebruiker, rol, bron, tijd of het bedrijfsproces.

Voor kleinere organisaties geeft Beleid inzake beheer van gebruikersaccounts en privileges - SME Beleid inzake beheer van gebruikersaccounts en privileges - SME een beknopte verwachting in Enforcement and Compliance clause 8.1.1:

De IT-verantwoordelijke moet systeemlogboeken regelmatig beoordelen op pogingen tot ongeautoriseerde toegang, afwijkingen bij aanmeldingen of niet-goedgekeurde privilegewijzigingen.

Hier beginnen veel ITDR-programma’s voor het mkb. Er is geen groot SOC voor nodig. Wel vereist het benoemd eigenaarschap en regelmatige beoordeling van de juiste identiteitssignalen.

Loggingbeleid vormt de basis voor bewijsmateriaal. Beleid voor logging en monitoring - SME Beleid voor logging en monitoring - SME specificeert in Governance Requirements clause 5.4.2:

Authenticatielogboeken: geslaagde en mislukte aanmeldpogingen, sessieduur, MFA-gebruik

Die velden zijn niet optioneel. Zij helpen aantonen of de verdachte gebeurtenis betrekking had op geslaagde authenticatie, herhaalde fouten, MFA-gebruik, sessiepersistentie of een abnormale duur.

Het enterprise Beleid voor logging en monitoring Beleid voor logging en monitoring breidt de vereiste logscope uit in Policy Implementation Requirements clause 6.1.1:

Alle betrokken systemen moeten logboeken genereren waarin wordt vastgelegd: 6.1.1.1 Gebruikersauthenticatie en toegangspogingen 6.1.1.2 Activiteiten van geprivilegieerde gebruikers 6.1.1.3 Configuratiewijzigingen 6.1.1.4 Mislukte toegangspogingen of systeemgebeurtenissen 6.1.1.5 Malwaredetecties en beveiligingswaarschuwingen 6.1.1.6 Externe communicatie en triggers van firewallregels

Configuratiewijzigingen zijn bijzonder belangrijk bij identiteitsaanvallen. Aanvallers voegen vaak OAuth-toestemmingen toe, maken doorstuurregels aan, registreren apparaten, wijzigen MFA-methoden of creëren noodtoegangspaden.

Incidentresponsbeleid geeft responders vervolgens bevoegdheid. Het enterprise Incidentresponsbeleid Incidentresponsbeleid stelt in Policy Implementation Requirements clause 6.2.1:

Het SOC moet getroffen systemen onmiddellijk isoleren, gecompromitteerde inloggegevens intrekken of malafide verkeer blokkeren met firewall- of endpointbeveiligingstools.

Het mkb-Incidentresponsbeleid - SME Incidentresponsbeleid - SME stelt in Roles and Responsibilities clause 4.2.2:

Voert indammings- en herstelacties uit, bijvoorbeeld door toegang uit te schakelen of back-ups te herstellen.

Voor ITDR is het intrekken van een wachtwoord niet genoeg. Draaiboeken moeten het uitschakelen van accounts, intrekken van sessies, ongeldig maken van OAuth-toestemmingen, roteren van secrets, resetten van MFA-methoden en beoordelen van gedelegeerde machtigingen omvatten.

Bewijsbehandeling maakt het verschil tussen reageren en aantonen. Het enterprise Beleid inzake bewijsverzameling en forensisch onderzoek Beleid inzake bewijsverzameling en forensisch onderzoek stelt in Governance Requirements clause 5.5:

Alle verzamelde bewijsmaterialen moeten uniek worden geïdentificeerd, gelabeld en opgeslagen in een beveiligde repository met: 5.5.1 Integriteitsverificatie, zoals SHA-256-hashwaarden 5.5.2 Van tijdstempels voorziene toegangslogboeken 5.5.3 Chain-of-custody-registraties ondertekend door elke beheerder

Het mkb-Beleid inzake bewijsverzameling en forensisch onderzoek - SME Beleid inzake bewijsverzameling en forensisch onderzoek - SME stelt in Policy Implementation Requirements clause 6.1.1:

Er moet altijd een forensische kopie of export worden gemaakt; het originele bewijsmateriaal mag nooit rechtstreeks worden bewerkt.

In het FinScale-scenario betekent dit dat het SOC logboeken van de identiteitsprovider, SaaS-auditlogboeken, mailbox-toegangsregistraties, OAuth-toestemmingsregistraties, registraties van sessie-intrekking en SIEM-waarschuwingen exporteert naar een bewijsrepository met integriteitsbescherming en chain-of-custody.

De ITDR-roadmap bouwen met Zenith Blueprint

Zenith Blueprint vertaalt de keten van beheersmaatregelen naar implementatiestappen.

In de fase Beheersmaatregelen in de praktijk, Step 19, Technologische beheersmaatregelen I, is de Blueprint duidelijk over authenticatie:

Waar mogelijk moet authenticatie met alleen een wachtwoord worden vermeden, vooral voor beheerdersaccounts, cloudconsoles, tools voor toegang op afstand en elk systeem dat aan het internet is blootgesteld. MFA, met een tweede factor zoals een hardwaresleutel, mobiele app of biometrie, is nu een basisvereiste, geen luxe. Het beperkt de risico’s van diefstal van inloggegevens, phishing en brute-force-aanvallen.

Dezelfde stap gaat verder dan wachtwoorden. Zij vereist veilige opslag en overdracht van authenticatiegegevens, veilige behandeling van API-tokens, sessie-ID’s en OAuth-referenties, secretsmanagement voor machine-to-machine-authenticatie, tokenrotatie, beheersing van sessieduur, veilige cookieflags en beoordeling van authenticatielogboeken.

Step 22, Organisatorische beheersmaatregelen, formaliseert de toegangslevenscyclus. De stap helpt teams om toegangsverlening en intrekking van toegangsrechten te integreren met HR, gedocumenteerde kwartaalgewijze toegangsrechtenbeoordelingen uit te voeren, identiteitstypen te definiëren zoals individuele, gedeelde en serviceaccounts, MFA voor geprivilegieerde accounts af te dwingen, inactieve accounts te verwijderen en servicereferenties te roteren.

Step 19 biedt ook het verbeterpad voor logging: stuur kritieke logboeken door naar een SIEM of logcollector, valideer retentie, traceer een recente gebeurtenis met behulp van logboeken, documenteer logboekintegriteitsfuncties en bevestig alarmering voor mislukte aanmeldingen of privilege-escalaties. Tijdsynchronisatie is belangrijk omdat incidentreconstructie faalt wanneer logboeken van de identiteitsprovider, SaaS, endpoints en cloud verschillende tijdstempels hanteren.

Step 23, Organisatorische beheersmaatregelen voor 5.19 tot en met 5.37, valideert incidentbeheercapaciteiten. De stap vereist een actueel incidentresponsplan, gedefinieerde meldingsplichtige gebeurtenissen, tabletop-oefeningen, gedocumenteerde besluiten, communicatieregistraties, geleerde lessen en bewaring van forensisch bewijsmateriaal, zoals logboekmomentopnamen, back-ups en veilige isolatie.

Een pragmatische Clarysec ITDR-volgorde ziet er als volgt uit:

1. Definieer identiteitstypen en eigenaren.
2. Beveilig authenticatie, tokens en sessies.
3. Verzamel authenticatie-, privilege- en SaaS-logboeken.
4. Monitor op risicovol gedrag.
5. Definieer beslisregels van gebeurtenis naar incident.
6. Bewaar bewijsmateriaal.
7. Rapporteer, herstel en verbeter.

Een ITDR-bewijspakket in één week

Een gericht “bewijspakket voor identiteitsincidenten” is een van de snelste manieren om hiaten bloot te leggen. Kies één hoogrisicoscenario, bijvoorbeeld: “Een geprivilegieerde SaaS-gebruiker geeft toestemming aan een ongeautoriseerde OAuth-applicatie en het token wordt gebruikt om toegang te krijgen tot klantgegevens.”

Bouw vervolgens het bewijspakket in één week.

Neem ten minste één werkelijke trace op. Gebruik een recente onschuldige aanmeldafwijking en laat zien hoe het team van waarschuwing naar gebruikersidentiteit, apparaat, bron-IP, MFA-methode, sessieduur, benaderde SaaS-resources, geraakte gegevens en indammingsbesluit gaat. Als de organisatie die keten niet kan reconstrueren in een tabletop-oefening, zal zij tijdens een echt incident moeite hebben.

De output wordt herbruikbaar bewijsmateriaal voor interne audits onder ISO/IEC 27001:2022, testen van het DORA ICT-incidentproces, NIS2-toezicht op cyberbeveiligingshygiëne en GDPR-verantwoordingsplicht.

ITDR mappen naar NIS2, DORA en GDPR Article 32

De kracht van een uniform ITDR-model is dat hetzelfde bewijsmateriaal meerdere verplichtingen ondersteunt, terwijl de taal van elk raamwerk wordt gerespecteerd.

NIS2 Article 21 verwacht risicogebaseerde, evenredige technische, operationele en organisatorische maatregelen. Voor ITDR betekent dit toegangscontrole, beheer van bedrijfsmiddelen, cyberbeveiligingshygiëne, training, incidentafhandeling, beoordeling van de doeltreffendheid van beheersmaatregelen en MFA of continue authenticatie waar passend. Article 23 creëert gefaseerde rapportage voor significante incidenten, waaronder een vroegtijdige waarschuwing binnen 24 uur, incidentmelding binnen 72 uur en een eindrapport binnen één maand.

DORA Articles 8 to 14 vereisen identificatie van ICT-activa en afhankelijkheden, bescherming en preventie, detectiemechanismen, continuïteit en herstel, leren en communicatie. Articles 17 to 19 vereisen incidentbeheer, identificatie van de oorzaak, indicatoren voor vroegtijdige waarschuwing, classificatie naar ernst en criticaliteit van diensten, escalatie, kennisgeving aan het bestuursorgaan, rapportage aan de bevoegde autoriteit en kennisgeving aan klanten wanneer financiële belangen worden geraakt.

GDPR vereist passende technische en organisatorische maatregelen en aantoonbare verantwoordingsplicht. Bij identiteitsaanvallen omvatten GDPR-vragen of ongeautoriseerde toegang heeft plaatsgevonden, welke persoonsgegevens betrokken waren, of waarborgen werkten en of meldingsdrempels voor inbreuken worden geactiveerd.

Voor fintechbedrijven is de verhouding tussen NIS2 en DORA van belang. DORA wordt behandeld als het sectorspecifieke raamwerk voor financiële entiteiten binnen de reikwijdte waar overlappende verplichtingen voor ICT-risico en incidentrapportage bestaan. In de praktijk moeten organisaties één ITDR-bewijsmodel bouwen en rapportagebesluiten mappen naar de toepasselijke juridische route.

Voor SaaS-, cloud-, managed service-, managed security- en digitale platformorganisaties moet de reikwijdte van NIS2 zorgvuldig worden gecontroleerd. NIS2 omvat veel sectoren uit Annex I en Annex II, waaronder digitale infrastructuur, cloudcomputingproviders, datacenters, vertrouwensdiensten, DNS, TLD-registers, managed service providers, managed security service providers, online marktplaatsen, zoekmachines en socialenetwerkplatforms. ISO/IEC 27001:2022 clause 4-scoping en analyse van belanghebbenden zijn daarom geen papierwerk. Zij bepalen welke verplichtingen het ISMS moet adresseren.

Leveranciers- en SaaS-identiteitsrisico

Identiteitsincidenten zijn vaak afhankelijk van leveranciersbewijsmateriaal. Kan de SaaS-provider auditlogboeken exporteren? Toont het OAuth-toestemmingsgebeurtenissen? Ondersteunt het veilige toegangscontrole, logging en gegevensbescherming? Zijn incidentondersteuning, gegevenslocatie, onderaanneming, toegangsrechten en exitbepalingen contractueel afgedekt?

Clarysec’s Beleid inzake gebruik van cloudservices - SME Beleid inzake gebruik van cloudservices - SME bevat een directe vereiste uit Governance Requirements clause 5.2.4:

De dienst biedt veilige toegangscontrole, logging en mogelijkheden voor gegevensbescherming

Die eenvoudige zin is een inkoopbeheersmaatregel. Als een SaaS-platform de identiteitslogboeken die nodig zijn voor incidentrespons niet kan leveren, ontstaat er compliancerisico.

DORA maakt dit expliciet via verplichtingen voor ICT-risico’s van derde partijen. Financiële entiteiten blijven verantwoordelijk voor naleving, moeten registers van ICT-dienstcontracten bijhouden, kritieke of belangrijke functies onderscheiden, due diligence uitvoeren, concentratierisico beoordelen, audit- en toegangsrechten opnemen, incidentondersteuning definiëren en exitstrategieën waarborgen.

In Zenith Controls is ISO/IEC 27001:2022 control 8.16 Monitoring activities verbonden met 5.22 Monitoring, review and change management of supplier services. Dit weerspiegelt de operationele werkelijkheid. Waarschuwingen van identiteitsproviders, SaaS-auditlogboeken, activiteit van cloudbeheerders en accounts van managed service providers vormen allemaal onderdeel van het ITDR-aanvalsoppervlak.

Hoe auditors ITDR zullen beoordelen

Een sterk ITDR-programma moet meerdere auditperspectieven kunnen doorstaan. Elk publiek stelt andere vragen, maar het bewijsmateriaal moet uit hetzelfde beheersingssysteem komen.

Een ISO/IEC 27001:2022-auditor zal vragen of identiteitsdreigingen zijn opgenomen in de risicobeoordeling, of risico-eigenaren de behandeling hebben goedgekeurd, of de Verklaring van Toepasselijkheid relevante Annex A-beheersmaatregelen bevat, of beleid is geïmplementeerd en of bewijsmateriaal laat zien dat beheersmaatregelen werken. De auditor kan een geprivilegieerd account selecteren en de goedkeuring, MFA-instelling, logactiviteit, toegangsrechtenbeoordeling en intrekking van toegangsrechten traceren.

Een NIST CSF 2.0-beoordelaar zal GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- en RECOVER-uitkomsten onderzoeken. ITDR past van nature in een profiel dat is afgebakend op identiteitscompromittering, misbruik van SaaS-tokens of misbruik van geprivilegieerde toegang.

Een DORA-examinator zal kijken naar verantwoordingsplicht van het bestuursorgaan, door ICT ondersteunde bedrijfsfuncties, detectiemechanismen, criteria voor incidentclassificatie, escalatie, regels voor klantcommunicatie, oorzaakanalyse en ICT-afhankelijkheden van derde partijen.

Een GDPR-beoordelaar zal vragen of de organisatie passende beveiliging van persoonsgegevens kan aantonen. De beoordeling omvat toegangsbeperking, detectie van ongeautoriseerde toegang, logboeken die laten zien welke gegevens mogelijk zijn benaderd, beoordeling van inbreuken en bewijsmateriaal voor verantwoordingsplicht.

Een COBIT 2019- of ISACA-stijl auditor zal governance, beheersdoelstellingen, eigenaarschap, prestatiemonitoring en assurance onderzoeken.

Zenith Controls is hier nuttig omdat het fungeert als cross-compliance-gids. Het creëert geen afzonderlijke “Zenith controls”. Het mapt ISO/IEC 27001:2022-beheersgebieden naar gerelateerde ISO-beheersmaatregelen, andere normen, auditverwachtingen en implementatierelaties.

Metrieken die aantonen dat ITDR werkt

Besturen en auditors hebben geen ruwe SIEM-ruis nodig. Zij hebben bewijsmateriaal nodig dat identiteitsbeheersmaatregelen werken en verbeteren. Nuttige ITDR-metrieken zijn onder meer:

• Percentage geprivilegieerde accounts met phishingresistente MFA.
• Aantal inactieve accounts ouder dan de beleidsdrempel.
• Aantal serviceaccounts zonder eigenaar of rotatiedatum.
• Percentage kritieke SaaS-platformen dat authenticatielogboeken naar het SIEM verzendt.
• Gemiddelde detectietijd voor verdachte identiteitsactiviteit.
• Gemiddelde tijd tot intrekking van gecompromitteerde sessies en tokens.
• Aantal OAuth-applicaties dat is goedgekeurd, afgewezen of verwijderd.
• Percentage identiteitsincidenten met volledige bewijspakketten.
• Aantal achterstallige bevindingen uit toegangsrechtenbeoordelingen.
• Aantal leveranciersplatformen zonder vereiste identiteitslogboeken.

Deze metrieken moeten input leveren voor de ISO/IEC 27001:2022-directiebeoordeling, NIS2-governancetoezicht, DORA ICT-risicorapportage en GDPR-verantwoordingsgesprekken.

Veelvoorkomende ITDR-auditbevindingen en oplossingen

Clarysec ziet vaak vijf terugkerende bevindingen.

Ten eerste schakelen organisaties MFA in, maar monitoren zij MFA-gedrag niet. Los dit op door wijzigingen in MFA-methoden, mislukte challenges, impossible travel, nieuwe apparaatregistraties en herhaalde pushpogingen te loggen.

Ten tweede worden serviceaccounts uitgesloten van identiteitsgovernance. Los dit op door accounts op systeemniveau te inventariseren, eigenaren toe te wijzen, secrets te roteren, ingebedde inloggegevens te verwijderen en afwijkend API-gedrag te monitoren.

Ten derde is SaaS-toestemming onbeheerd. Los dit op door gebruikerstoestemming te beperken, OAuth-applicaties te beoordelen, nieuwe toestemmingen te monitoren, goedgekeurde integraties te documenteren en ongebruikte apps te verwijderen.

Ten vierde wordt bewijsmateriaal tijdens het onderzoek gewijzigd. Los dit op door de regel uit het Beleid inzake bewijsverzameling en forensisch onderzoek te volgen: maak forensische kopieën of exporten, bewerk originelen nooit rechtstreeks en sla bewijsmateriaal op met hashes en chain-of-custody-registraties.

Ten vijfde is incidentclassificatie te traag. Los dit op door drempels voor identiteitsgebeurtenissen vooraf te definiëren, waaronder compromittering van geprivilegieerde accounts, toegang tot persoonsgegevens, misbruik van SaaS-tokens met klantimpact, verstoring van kritieke diensten en compromittering van leveranciersidentiteiten.

Elke bevinding heeft een antwoord in de vorm van een beheersmaatregel, beleid en bewijsmateriaal. Dat is de praktische waarde van een uniform ITDR-programma: het definieert wat eigenaarschap moet hebben, gemonitord, getest, onderbouwd en verbeterd moet worden.

Zet identiteitsrisico om in auditgereed bewijsmateriaal

Als uw volgende identiteitsincident morgen plaatsvond, kunt u dan aantonen wie waartoe toegang had, hoe die persoon was geauthenticeerd, welk token of welke sessie werd gebruikt, welke gegevens zijn geraakt, wie de regelgevende classificatie heeft bepaald en welke corrigerende maatregelen zijn afgerond?

Als het antwoord onzeker is, start dan met een gerichte ITDR-readiness-sprint.

Gebruik Zenith Blueprint om het implementatiepad te structureren over authenticatie, toegangslevenscyclus, logging, monitoring, incidentrespons en bewijsbehandeling. Gebruik Clarysec’s beleid voor toegangscontrole, logging, cloud, incidentrespons en forensisch onderzoek om eigenaarschap en responsbevoegdheid toe te wijzen. Gebruik Zenith Controls om identiteitsbeheer, veilige authenticatie en monitoringactiviteiten te mappen naar ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 en auditverwachtingen.

Het doel is eenvoudig: maak identiteitsaanvallen detecteerbaar, indambaar, rapporteerbaar en verdedigbaar.

Clarysec kan u helpen een ITDR-bewijspakket op te bouwen, dit via een tabletop-scenario te testen en de bevindingen om te zetten in een risicobehandelingsplan dat uw bestuur, toezichthouder en auditor kunnen begrijpen. Begin met het beoordelen van het Beleid voor logging en monitoring, het Beleid inzake beheer van gebruikersaccounts en privileges - SME, Zenith Blueprint en Zenith Controls, en plan vervolgens een ITDR-readiness-assessment om identiteitsrisico om te zetten in auditgereed bewijsmateriaal.