ITDR-strategi for ISO 27001, NIS2, DORA og GDPR

Kl. 03.00 en tirsdag vågnede Sarah, FinScales CISO, til den type alarm, som moderne sikkerhedsledere i stigende grad frygter. En seniorudviklers aktive session, der var autentificeret med MFA få timer tidligere, blev brugt fra en usædvanlig kilde til at enumerere schemas i produktionsdatabaser.

Der var intet malware-beacon. Ingen ransomware-besked. Ingen firewall-exploit. Kun identitet.

SOC’et opdagede aktiviteten, men responsen var ukoordineret. Var der tale om MFA-omgåelse, et stjålet sessionstoken eller kompromittering af selve identitetsudbyderen? Hvem havde bemyndigelse til at afbryde den aktive session? Var det nok at nulstille adgangskoden, eller skulle teamet også invalidere refresh tokens, rotere API-legitimationsoplysninger og gennemgå OAuth-tilladelser? Da aktiviteten var inddæmmet, havde angriberen været aktiv i 47 minutter.

Næste morgen blev sikkerhedshændelsen et governance-problem. Bestyrelsen ønskede en forklaring i klart sprog på, om FinScales cyberhygiejne havde svigtet under NIS2. Compliance-teamet ville vide, om hændelsen kunne klassificeres som en større IKT-relateret hændelse under DORA. Juridisk afdeling havde brug for et forsvarligt svar på, om der var tilgået personoplysninger under GDPR Article 32, og om en vurdering af brud på persondatasikkerheden var påkrævet. Den eksterne revisor spurgte, om ISO/IEC 27001:2022-kontrollerne fungerede effektivt, ikke blot om de var dokumenteret i politikker.

Sarahs problem var ikke mangel på værktøjer. FinScale havde en identitetsudbyder, MFA, en SIEM, endpoint-kontroller, cloudlogfiler og en proces for hændelseshåndtering. Problemet var, at identitetsstyring, logning, overvågning, hændelseshåndtering, vurdering af databeskyttelse og håndtering af bevismateriale fungerede i siloer.

Det er ITDR-problemet i 2026. ITDR er ikke længere kun en kapabilitet i sikkerhedsdrift. Det er en tværgående motor til efterlevelsesbevismateriale for ISO/IEC 27001:2022, NIS2, DORA og GDPR Article 32.

Clarysecs Zenith Blueprint: revisorens 30-trins køreplan Zenith Blueprint, politikpakke og Zenith Controls: vejledning til efterlevelse på tværs af rammeværker Zenith Controls hjælper organisationer med at omsætte identitetsangreb fra kaotiske undersøgelser til gentagelige, revisionsbare kontrolprocesser.

Hvorfor Identity Threat Detection and Response nu er et bestyrelsesanliggende

Identitetsangreb virker, fordi de misbruger legitime adgangsveje. En angriber, der stjæler et sessionstoken, registrerer en ondsindet OAuth-applikation, kompromitterer en servicekonto eller presser en bruger gennem MFA push fatigue, kan ligne en gyldig bruger for systemer, der kun kontrollerer, om autentifikationen lykkedes.

Det gør ITDR anderledes end traditionelt perimeterforsvar. Et modent program skal kunne besvare:

• Hvilke menneskelige identiteter, serviceidentiteter, leverandøridentiteter og applikationsidentiteter findes der?
• Hvilke identiteter er privilegerede, inaktive, delte eller eksternt fødererede?
• Hvilke autentifikationshændelser er normale, risikofyldte eller umulige?
• Hvilke OAuth-tilladelser, SaaS-tokens og API-legitimationsoplysninger kan tilgå følsomme data?
• Hvilke alarmer udløser hændelsesklassificering, sikring af bevismateriale og regulatorisk beslutningstagning?
• Hvilke kontroller dokumenterer, at adgang til personoplysninger er beskyttet med passende tekniske og organisatoriske foranstaltninger?

NIS2 gør dette til et governance-anliggende. Article 20 kræver, at ledelsesorganer i væsentlige og vigtige enheder godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og modtager uddannelse. Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder risikoanalyse, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, vurdering af kontroleffektivitet, cyberhygiejne, uddannelse, adgangsstyring, aktivstyring samt multifaktorautentifikation eller løbende autentifikation, hvor det er relevant.

DORA lægger tilsvarende pres på finansielle enheder. Det kræver en dokumenteret ramme for styring af IKT-risiko, ansvar hos ledelsesorganet, detektionsmekanismer, hændelsesstyring, klassificering, rapportering, robusthedstest og styring af IKT-tredjepartsrisici. DORA finder anvendelse fra 17. januar 2025. For finansielle enheder, der også er omfattet af NIS2, fungerer DORA som det sektorspecifikke regelsæt for overlappende forpligtelser vedrørende IKT-risiko og hændelser.

GDPR tilføjer laget for dokumenterbar databeskyttelse. Article 5 kræver integritet, fortrolighed og ansvarlighed. Article 4 definerer et brud på persondatasikkerheden bredt, herunder uautoriseret adgang til personoplysninger. Article 32 kræver passende tekniske og organisatoriske foranstaltninger for at sikre et sikkerhedsniveau, der passer til risikoen. Ved identitetshændelser bliver logfiler, adgangskontroller, autentifikationsregistreringer og bevismateriale fra hændelsen centrale for at dokumentere, om personoplysninger var beskyttet.

ISO/IEC 27001:2022 er ledelsessystemet, der kan samle disse forpligtelser. Clause 4 kræver, at organisationen forstår sin kontekst, interessenter samt juridiske, regulatoriske og kontraktlige krav. Clause 6 kræver risikovurdering, risikobehandling, godkendelse fra risikoejer og opbevaret bevismateriale. Annex A omfatter kontroller for identitetsstyring, sikker autentifikation, logning, overvågning, hændelsesstyring, indsamling af bevismateriale, leverandørrelationer, cloudtjenester og beskyttelse af privatliv.

ITDR hører hjemme i ISMS’et, fordi identitetsrisiko først bliver revisionsbar, når den er afgrænset, ejet, vurderet, behandlet, overvåget og forbedret.

Identitetsangrebsscenariet, som tilsynsmyndigheder er optaget af

Forestil dig en cloudbaseret udbyder af finansielle arbejdsgange, der betjener EU-kunder. Den bruger Microsoft 365, en SaaS-platform til kundesupport, cloudinfrastruktur, en betalingsprocessor og flere API-baserede integrationer. En senior supporttekniker modtager en overbevisende anmodning om at tilslutte en produktivitetsapplikation igen. OAuth-samtykkeskærmen anmoder om læseadgang til mailbox og offlineadgang. Teknikeren godkender.

Inden for få minutter bruger angriberen tokenet til at søge efter kundeidentifikatorer og supportvedhæftninger. Angriberen enumererer gruppemedlemskaber og forsøger adgang til en administrativ portal. MFA var aktiveret, men angriberen behøver ikke adgangskoden igen, fordi tokenet giver vedvarende adgang. SOC’et ser usædvanlig mailbox-adgang, en ny OAuth-applikation, mislykkede forsøg på adgang til administratorportalen og aktivitet fra en usædvanlig geografi.

Dette ene scenarie krydser flere kontroldomæner:

• Identitetslivscyklus, fordi brugerens rolle og tilladelser bestemmer konsekvensomfanget.
• Sikker autentifikation, fordi MFA alene ikke forhindrede misbrug af tokenet.
• Logning og overvågning, fordi detektion afhænger af logfiler fra identitetsudbyder, SaaS og applikationer.
• Hændelseshåndtering, fordi legitimationsoplysninger, sessioner, tokens og OAuth-tilladelser hurtigt skal tilbagekaldes.
• Indsamling af bevismateriale, fordi eksponering af personoplysninger og regulatorisk rapportering kan følge.
• Leverandør- og cloudstyring, fordi SaaS-logfiler og revisions-API’er er en del af beviskæden.
• Beskyttelse af privatliv, fordi adgang til personoplysninger skal vurderes under GDPR.

Det rigtige spørgsmål er ikke: “Hvilket værktøj svigtede?” Det rigtige spørgsmål er, om organisationen havde en designet, testet og revisionsbar ITDR-kontrolkæde.

ISO 27001:2022-kontrolkæden bag effektiv ITDR

De mest effektive ITDR-programmer forbinder forebyggende, detekterende, korrigerende og bevisunderstøttende kontroller.

I Zenith Controls behandles ISO/IEC 27001:2022-kontrol 5.16 Identity management som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Den forbindes direkte med 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 og 8.2 Privileged access rights.

Det er vigtigt, fordi identitetsdetektion svigter, når identity governance er svag. Hvis en servicekonto ikke er dokumenteret, en leverandøridentitet ikke administreres, eller en privilegeret rolle ikke har en ejer, kan overvågning måske detektere en hændelse, men respondenterne kan ikke hurtigt fortolke den.

Kontrol 8.5 Secure authentication er et andet ITDR-anker. I Zenith Controls forbindes den med identitetsstyring, autentifikationsoplysninger, privilegerede adgangsrettigheder, begrænsning af informationsadgang, overvågningsaktiviteter, hændelsesstyring og beskyttelse af PII. Autentifikation slutter ikke ved login. Sessionsstyring, håndtering af tokens, beskyttelse af legitimationsoplysninger og sporbarhed er en del af samme bevisfortælling.

Kontrol 8.16 Monitoring activities er hængslet mellem indsamling af logfiler og beslutningstagning. Den afhænger af 8.15 Logging og understøtter 5.25 Assessment and decision on information security events, 5.26 Response to information security incidents og bredere hændelsesstyring. For ITDR er 8.16 det sted, hvor mistænkelig identitetsadfærd bliver til en triageret hændelse, en erklæret sikkerhedshændelse eller en dokumenteret falsk positiv.

Tabellen er ikke en teoretisk kortlægning. Den er den praktiske beviskæde, som en revisor, et bestyrelsesmedlem eller en tilsynsmyndighed vil forvente efter en identitetshændelse.

Hvad Clarysec-politikker tilfører: ejerskab, udløsere og regler for bevismateriale

Identitetsværktøjer skaber ikke automatisk ansvarlighed. Under en krise har respondenter brug for bemyndigelse til at tilbagekalde sessioner, deaktivere konti, eksportere logfiler, sikre bevismateriale og træffe eskaleringsbeslutninger. Revisorer skal kunne se, at disse handlinger ikke blev improviseret.

Clarysecs politikpakke leverer denne driftsmodel.

Af enterprise-versionen af Politik for styring af brugerkonti og privilegier Politik for styring af brugerkonti og privilegier fremgår følgende af punkt 5.9 om governance-krav:

Organisationen skal vedligeholde en detaljeret fortegnelse over alle aktive og inaktive legitimationsoplysninger, privilegerede konti og servicekonti på systemniveau. Fortegnelsen skal opdateres løbende og gennemgås kvartalsvist.

Det gør identitetsfortegnelsen til en eksplicit kontrolforpligtelse. Det er særligt vigtigt, fordi servicekonti, API-nøgler og inaktive legitimationsoplysninger er almindelige blinde vinkler i ITDR.

Den samme politik angiver i punkt 5.8 om governance-krav:

Alle administrative aktiviteter og handlinger på privilegerede konti skal logges på en manipulationsafslørende måde og overvåges for anomalier eller politikovertrædelser.

Denne bestemmelse forbinder styring af privilegeret adgang med detektion. En privilegeret handling er ikke blot tilladt eller afvist. Den skal overvåges for adfærd, der ikke passer til brugeren, rollen, kilden, tidspunktet eller forretningsprocessen.

For mindre organisationer giver Politik for styring af brugerkonti og privilegier - SMV Politik for styring af brugerkonti og privilegier - SMV en kortfattet forventning i punkt 8.1.1 om håndhævelse og efterlevelse:

Den IT-ansvarlige skal regelmæssigt gennemgå systemlogfiler for forsøg på uautoriseret adgang, loginanomalier eller ikke-godkendte ændringer i rettigheder.

Det er her, mange ITDR-programmer i SMV’er begynder. Det kræver ikke et stort SOC. Det kræver navngivet ejerskab og regelmæssig gennemgang af de rigtige identitetssignaler.

Logningspolitikken udgør fundamentet for bevismateriale. Lognings- og overvågningspolitik - SMV Lognings- og overvågningspolitik - SMV specificerer i punkt 5.4.2 om governance-krav:

Autentifikationslogfiler: vellykkede og mislykkede loginforsøg, sessionsvarighed, brug af MFA

Disse felter er ikke valgfrie. De hjælper med at dokumentere, om den mistænkelige hændelse involverede vellykket autentifikation, gentagne fejl, brug af MFA, vedvarende session eller unormal varighed.

Enterprise-versionen af Lognings- og overvågningspolitik Lognings- og overvågningspolitik udvider det krævede logningsomfang i punkt 6.1.1 om krav til implementering af politikken:

Alle omfattede systemer skal generere logfiler, der registrerer: 6.1.1.1 Brugerautentifikation og forsøg på adgang 6.1.1.2 Aktiviteter udført af privilegerede brugere 6.1.1.3 Konfigurationsændringer 6.1.1.4 Mislykkede adgangsforsøg eller systemhændelser 6.1.1.5 Malwaredetektioner og sikkerhedsalarmer 6.1.1.6 Ekstern kommunikation og udløsere for firewallregler

Konfigurationsændringer er særligt vigtige ved identitetsangreb. Angribere tilføjer ofte OAuth-tilladelser, opretter videresendelsesregler, registrerer enheder, ændrer MFA-metoder eller opretter nødadgangsveje.

Politikken for hændelseshåndtering giver derefter respondenterne bemyndigelse. Enterprise-versionen af Politik for hændelseshåndtering Politik for hændelseshåndtering angiver i punkt 6.2.1 om krav til implementering af politikken:

SOC’et skal straks isolere berørte systemer, tilbagekalde kompromitterede legitimationsoplysninger eller blokere ondsindet trafik ved hjælp af firewall- eller endpoint-sikkerhedsværktøjer.

SMV-versionen af Politik for hændelseshåndtering - SMV Politik for hændelseshåndtering - SMV angiver i punkt 4.2.2 om roller og ansvar:

Implementerer inddæmnings- og genopretningshandlinger, f.eks. ved at deaktivere adgang eller gendanne sikkerhedskopier.

For ITDR er tilbagekaldelse af en adgangskode ikke nok. Responsprocedurer skal omfatte deaktivering af konti, tilbagekaldelse af sessioner, invalidering af OAuth-tilladelser, rotation af hemmeligheder, nulstilling af MFA-metoder og gennemgang af delegerede tilladelser.

Håndtering af bevismateriale er forskellen mellem at reagere og at kunne dokumentere. Enterprise-versionen af Politik for indsamling af bevismateriale og digital efterforskning Politik for indsamling af bevismateriale og digital efterforskning angiver i punkt 5.5 om governance-krav:

Alt indsamlet bevismateriale skal være entydigt identificeret, mærket og opbevaret i et sikkert repository med: 5.5.1 Integritetsverifikation, såsom SHA-256-hashværdier 5.5.2 Adgangslogfiler med tidsstempel 5.5.3 Chain of custody-poster underskrevet af hver forvalter

SMV-versionen af Politik for indsamling af bevismateriale og digital efterforskning - SMV Politik for indsamling af bevismateriale og digital efterforskning - SMV angiver i punkt 6.1.1 om krav til implementering af politikken:

Der skal altid oprettes en forensisk kopi eller eksport; det oprindelige bevismateriale må aldrig redigeres direkte.

I FinScale-scenariet betyder det, at SOC’et eksporterer logfiler fra identitetsudbyderen, SaaS-revisionslogfiler, registreringer af mailbox-adgang, OAuth-samtykkeregistreringer, registreringer af sessionstilbagekaldelse og SIEM-alarmer til et bevisrepository med integritetsbeskyttelse og chain of custody.

Opbygning af ITDR-køreplanen med Zenith Blueprint

Zenith Blueprint omsætter kontrolkæden til implementeringstrin.

I fasen Controls in Action, trin 19, Technological Controls I, er Blueprint direkte om autentifikation:

Hvor det er muligt, bør autentifikation kun med adgangskode undgås, især for administratorkonti, cloudkonsoller, fjernadgangsværktøjer og ethvert system, der er eksponeret mod internettet. MFA, der anvender en anden faktor som en hardware-nøgle, mobilapp eller biometri, er nu en grundkontrol, ikke en luksus. Det begrænser risikoen for tyveri af legitimationsoplysninger, phishing og brute-force- angreb.

Det samme trin går videre end adgangskoder. Det kræver sikker opbevaring og transmission af autentifikationsdata, sikker håndtering af API-tokens, sessions-ID’er og OAuth-legitimationsoplysninger, håndtering af hemmeligheder til maskine-til-maskine-autentifikation, tokenrotation, kontroller for sessionslevetid, sikre cookie-flag og gennemgang af autentifikationslogfiler.

Trin 22, organisatoriske kontroller, formaliserer adgangens livscyklus. Det vejleder teams i at integrere tildeling og fjernelse af adgang med HR, udføre dokumenterede kvartalsvise gennemgange af adgangsrettigheder, definere identitetstyper såsom individuelle konti, delte konti og servicekonti, håndhæve MFA for privilegerede konti, fjerne inaktive konti og rotere servicelegitimationsoplysninger.

Trin 19 angiver også forbedringsvejen for logning: videresend kritiske logfiler til en SIEM eller logcollector, validér opbevaring, spor en nylig hændelse ved hjælp af logfiler, dokumentér funktioner til logintegritet og bekræft alarmering for mislykkede login eller eskalering af rettigheder. Tidssynkronisering er afgørende, fordi rekonstruktion af hændelser svigter, når logfiler fra identitetsudbyder, SaaS, endpoint og cloud ikke stemmer overens om tidsstempler.

Trin 23, organisatoriske kontroller for 5.19 til 5.37, validerer kapabiliteter til hændelsesstyring. Det kræver en opdateret hændelseshåndteringsplan, definerede rapporteringspligtige hændelser, tabletop-øvelser, dokumenterede beslutninger, kommunikationsregistreringer, lessons learned og sikring af digitale beviser såsom logsnapshots, sikkerhedskopier og sikker isolering.

En pragmatisk Clarysec ITDR-sekvens ser sådan ud:

1. Definér identitetstyper og ejere.
2. Sikr autentifikation, tokens og sessioner.
3. Indsaml autentifikations-, privilegie- og SaaS-logfiler.
4. Overvåg for risikofyldt adfærd.
5. Definér beslutningsregler fra event til incident.
6. Sikr bevismateriale.
7. Rapportér, genopret og forbedr.

En ITDR-bevispakke på én uge

En fokuseret “bevispakke for identitetshændelser” er en af de hurtigste måder at afdække huller på. Vælg ét højrisikoscenarie, f.eks.: “En privilegeret SaaS-bruger giver samtykke til en uautoriseret OAuth-applikation, og tokenet bruges til at tilgå kundedata.”

Opbyg derefter bevispakken på én uge.

Medtag mindst ét faktisk spor. Tag en ufarlig nylig loginanomali, og dokumentér, hvordan teamet går fra alarm til brugeridentitet, enhed, kilde-IP, MFA-metode, sessionsvarighed, tilgåede SaaS-ressourcer, berørte data og beslutning om inddæmning. Hvis organisationen ikke kan rekonstruere den kæde i en tabletop-øvelse, vil den få vanskeligt ved det under en reel hændelse.

Outputtet bliver genanvendeligt bevismateriale til interne ISO/IEC 27001:2022-revisioner, test af DORA-processer for IKT-hændelser, NIS2-tilsyn med cyberhygiejne og GDPR-ansvarlighed.

Kortlægning af ITDR til NIS2, DORA og GDPR Article 32

Styrken ved en samlet ITDR-model er, at det samme bevismateriale opfylder flere forpligtelser, samtidig med at hvert rammeværks terminologi respekteres.

NIS2 Article 21 forventer risikobaserede, forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger. For ITDR betyder det adgangsstyring, styring af aktiver, cyberhygiejne, uddannelse, hændelseshåndtering, vurdering af kontroleffektivitet og MFA eller løbende autentifikation, hvor det er relevant. Article 23 etablerer trinvis rapportering for væsentlige hændelser, herunder tidlig varsling inden for 24 timer, hændelsesunderretning inden for 72 timer og en endelig rapport inden for én måned.

DORA Articles 8 to 14 kræver identifikation af IKT-aktiver og afhængigheder, beskyttelse og forebyggelse, detektionsmekanismer, kontinuitet og genopretning, læring og kommunikation. Articles 17 to 19 kræver hændelsesstyring, identifikation af rodårsag, tidlige advarselsindikatorer, klassificering efter alvorlighed og servicekritikalitet, eskalering, underretning af ledelsesorganet, rapportering til kompetent myndighed og kundeunderretning, når finansielle interesser påvirkes.

GDPR kræver passende tekniske og organisatoriske foranstaltninger og dokumenterbar ansvarlighed. Ved identitetsangreb omfatter GDPR-spørgsmål, om der opstod uautoriseret adgang, hvilke personoplysninger der var involveret, om sikkerhedsforanstaltningerne fungerede, og om tærskler for underretning ved brud på persondatasikkerheden er udløst.

For fintech-virksomheder er forholdet mellem NIS2 og DORA vigtigt. DORA behandles som det sektorspecifikke rammeværk for finansielle enheder inden for anvendelsesområdet, hvor der findes overlappende forpligtelser vedrørende IKT-risiko og hændelsesrapportering. I praksis bør organisationer opbygge én ITDR-bevismodel og kortlægge rapporteringsbeslutninger til den relevante juridiske vej.

For SaaS-, cloud-, managed service-, managed security- og digitale platformorganisationer skal NIS2-omfanget kontrolleres nøje. NIS2 dækker mange sektorer i Annex I og Annex II, herunder digital infrastruktur, cloud computing-udbydere, datacentre, tillidstjenester, DNS, TLD-registre, managed service providers, managed security service providers, online markedspladser, søgemaskiner og sociale netværksplatforme. ISO/IEC 27001:2022 Clause 4 om afgrænsning og interessentanalyse er derfor ikke papirarbejde. De definerer, hvilke forpligtelser ISMS’et skal håndtere.

Leverandør- og SaaS-identitetsrisiko

Identitetshændelser afhænger ofte af bevismateriale fra leverandører. Kan SaaS-udbyderen eksportere revisionslogfiler? Viser den OAuth-samtykkehændelser? Understøtter den sikre adgangskontroller, logning og databeskyttelse? Er assistance ved hændelser, datalokation, underleverandører, adgangsrettigheder og exitbestemmelser dækket kontraktligt?

Clarysecs Politik for brug af cloudtjenester - SMV Politik for brug af cloudtjenester - SMV indeholder et direkte krav fra punkt 5.2.4 om governance-krav:

Tjenesten leverer sikre adgangskontroller, logning og kapabiliteter til databeskyttelse

Den enkle sætning er en indkøbskontrol. Hvis en SaaS-platform ikke kan producere de identitetslogfiler, der kræves til hændelseshåndtering, skaber den efterlevelsesrisiko.

DORA gør dette eksplicit gennem forpligtelser vedrørende IKT-tredjepartsrisici. Finansielle enheder forbliver ansvarlige for efterlevelse, skal vedligeholde registre over IKT-servicekontrakter, skelne mellem kritiske eller vigtige funktioner, gennemføre due diligence, vurdere koncentrationsrisiko, inkludere revisions- og adgangsrettigheder, definere assistance ved hændelser og sikre exitstrategier.

I Zenith Controls forbindes ISO/IEC 27001:2022-kontrol 8.16 Monitoring activities med 5.22 Monitoring, review and change management of supplier services. Det afspejler den driftsmæssige virkelighed. Alarmer fra identitetsudbydere, SaaS-revisionslogfiler, cloudadministratoraktivitet og konti hos managed service providers udgør alle en del af ITDR-fladen.

Hvordan revisorer vil vurdere ITDR

Et stærkt ITDR-program skal kunne bestå flere revisionsperspektiver. Hver målgruppe stiller forskellige spørgsmål, men bevismaterialet bør komme fra det samme kontrolsystem.

En ISO/IEC 27001:2022-revisor vil spørge, om identitetstrusler indgår i risikovurderingen, om risikoejere har godkendt behandlingen, om anvendelighedserklæringen omfatter relevante Annex A-kontroller, om politikkerne er implementeret, og om bevismaterialet viser, at kontrollerne fungerer. Revisoren kan udtage en privilegeret konto som stikprøve og spore godkendelse, MFA-indstilling, logaktivitet, gennemgang af adgangsrettigheder og deprovisionering.

En NIST CSF 2.0-vurderingspart vil undersøge GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- og RECOVER-resultater. ITDR passer naturligt ind i en profil afgrænset til identitetskompromittering, misbrug af SaaS-tokens eller misbrug af privilegeret adgang.

En DORA-eksaminator vil se efter ansvarlighed hos ledelsesorganet, IKT-understøttede forretningsfunktioner, detektionsmekanismer, kriterier for hændelsesklassificering, eskalering, regler for kundekommunikation, rodårsagsanalyse og IKT-tredjepartsafhængigheder.

En GDPR-gennemgangsansvarlig vil spørge, om organisationen kan dokumentere passende sikkerhed for personoplysninger. Vedkommende vil undersøge begrænsning af adgang, detektion af uautoriseret adgang, logfiler, der viser, hvilke data der kan være tilgået, vurdering af brud på persondatasikkerheden og bevismateriale for ansvarlighed.

En COBIT 2019- eller ISACA-revisor vil undersøge governance, kontrolmål, ejerskab, performanceovervågning og sikkerhed.

Zenith Controls er nyttig her, fordi den fungerer som en vejledning til efterlevelse på tværs af rammeværker. Den skaber ikke separate “Zenith controls”. Den kortlægger ISO/IEC 27001:2022-kontrolområder til relaterede ISO-kontroller, andre standarder, revisionsforventninger og implementeringsrelationer.

Metrikker der dokumenterer, at ITDR fungerer

Bestyrelser og revisorer har ikke brug for rå SIEM-støj. De har brug for bevismateriale for, at identitetskontroller virker og forbedres. Nyttige ITDR-metrikker omfatter:

• Andel af privilegerede konti med phishingresistent MFA.
• Antal inaktive konti, der er ældre end politikkens tærskel.
• Antal servicekonti uden ejer eller rotationsdato.
• Andel af kritiske SaaS-platforme, der sender autentifikationslogfiler til SIEM’en.
• Gennemsnitlig tid til detektion af mistænkelig identitetsaktivitet.
• Gennemsnitlig tid til tilbagekaldelse af kompromitterede sessioner og tokens.
• Antal OAuth-applikationer, der er godkendt, afvist eller fjernet.
• Andel af identitetshændelser med komplette bevispakker.
• Antal forfaldne konstateringer fra gennemgang af adgangsrettigheder.
• Antal leverandørplatforme, der mangler krævede identitetslogfiler.

Disse metrikker bør indgå i ISO/IEC 27001:2022-ledelsens gennemgang, NIS2-governance-tilsyn, DORA-rapportering om IKT-risiko og GDPR-drøftelser om ansvarlighed.

Almindelige ITDR-revisionskonstateringer og afhjælpning

Clarysec ser typisk fem tilbagevendende konstateringer.

For det første aktiverer organisationer MFA, men overvåger ikke MFA-adfærd. Afhjælp dette ved at logge ændringer af MFA-metoder, mislykkede challenges, impossible travel, registrering af nye enheder og gentagne pushforsøg.

For det andet er servicekonti undtaget fra identity governance. Afhjælp dette ved at registrere konti på systemniveau, tildele ejere, rotere hemmeligheder, fjerne indlejrede legitimationsoplysninger og overvåge anomal API-adfærd.

For det tredje er SaaS-samtykke ikke administreret. Afhjælp dette ved at begrænse brugersamtykke, gennemgå OAuth-applikationer, overvåge nye tilladelser, dokumentere godkendte integrationer og fjerne ubrugte apps.

For det fjerde ændres bevismateriale under undersøgelsen. Afhjælp dette ved at følge reglen i Politik for indsamling af bevismateriale og digital efterforskning: Opret forensiske kopier eller eksporter, redigér aldrig originaler direkte, og opbevar bevismateriale med hashes og chain of custody-registreringer.

For det femte går hændelsesklassificeringen for langsomt. Afhjælp dette ved på forhånd at definere tærskler for identitetshændelser, herunder kompromittering af privilegerede konti, adgang til personoplysninger, SaaS-tokenmisbrug med kundepåvirkning, afbrydelse af kritiske tjenester og kompromittering af leverandøridentiteter.

Hver konstatering har en kontrol-, politik- og bevisrespons. Det er den praktiske værdi af et samlet ITDR-program: Det definerer, hvad der skal ejes, overvåges, testes, dokumenteres og forbedres.

Omsæt identitetsrisiko til revisionsklart bevismateriale

Hvis jeres næste identitetshændelse indtraf i morgen, kunne I så dokumentere, hvem der tilgik hvad, hvordan de autentificerede sig, hvilket token eller hvilken session der blev brugt, hvilke data der blev berørt, hvem der traf beslutning om regulatorisk klassificering, og hvilke korrigerende handlinger der blev gennemført?

Hvis svaret er usikkert, så begynd med et fokuseret ITDR-readiness-sprint.

Brug Zenith Blueprint til at strukturere implementeringsvejen på tværs af autentifikation, adgangens livscyklus, logning, overvågning, hændelseshåndtering og håndtering af bevismateriale. Brug Clarysecs politikker for adgangsstyring, logning, cloud, hændelseshåndtering og digital efterforskning til at tildele ejerskab og responsbemyndigelse. Brug Zenith Controls til at kortlægge identitetsstyring, sikker autentifikation og overvågningsaktiviteter til ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 og revisionsforventninger.

Målet er enkelt: Gør identitetsangreb detekterbare, inddæmmelige, rapporterbare og forsvarlige.

Clarysec kan hjælpe jer med at opbygge en ITDR-bevispakke, teste den gennem et tabletop-scenarie og omsætte konstateringerne til en risikobehandlingsplan, som bestyrelsen, tilsynsmyndigheden og revisoren kan forstå. Start med at gennemgå Lognings- og overvågningspolitik, Politik for styring af brugerkonti og privilegier - SMV, Zenith Blueprint og Zenith Controls, og planlæg derefter en ITDR-readiness-vurdering for at omsætte identitetsrisiko til revisionsklart bevismateriale.