ITDR-strategi för ISO 27001, NIS2, DORA och GDPR

Klockan 03.00 en tisdag vaknade Sarah, informationssäkerhetschef på FinScale, av den typ av larm som moderna säkerhetsledare allt oftare fruktar. En senior utvecklares aktiva session, autentiserad med MFA bara några timmar tidigare, användes från en ovanlig källa för att enumerera scheman i produktionsdatabaser.

Det fanns ingen C2-beacon från skadlig kod. Inget utpressningsmeddelande från ransomware. Inget utnyttjande av brandvägg. Bara identitet.

SOC upptäckte aktiviteten, men responsen blev rörig. Var detta ett kringgående av MFA, en stulen sessionstoken eller en kompromettering av själva identitetsleverantören? Vem hade befogenhet att avbryta den aktiva sessionen? Räckte det att återkalla lösenordet, eller behövde teamet ogiltigförklara refresh tokens, rotera API-autentiseringsuppgifter och granska OAuth-behörigheter? När aktiviteten väl hade begränsats hade angriparen varit aktiv i 47 minuter.

Nästa morgon hade säkerhetsincidenten blivit en styrningsfråga. Styrelsen ville ha en tydlig förklaring av om FinScales cyberhygien hade brustit enligt NIS2. Regelefterlevnadsteamet ville veta om händelsen kunde klassificeras som en allvarlig IKT-relaterad incident enligt DORA. Juridik behövde ett försvarbart svar på om personuppgifter hade åtkommits enligt GDPR Article 32 och om en bedömning av personuppgiftsincident krävdes. Den externa revisorn frågade om kontrollerna enligt ISO/IEC 27001:2022 fungerade effektivt, inte bara om de var dokumenterade i policyer.

Sarahs problem var inte brist på verktyg. FinScale hade en identitetsleverantör, MFA, ett SIEM, endpointskydd, molnloggar och en process för incidentrespons. Problemet var att identitetshantering, loggning, övervakning, incidentrespons, integritetsbedömning och bevismaterialhantering fungerade i silor.

Det är 2026 års problem med Identity Threat Detection and Response. ITDR är inte längre bara en förmåga inom säkerhetsdrift. Det är en tvärgående bevismotor för efterlevnad av ISO/IEC 27001:2022, NIS2, DORA och GDPR Article 32.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, policysvit och Zenith Controls: The Cross-Compliance Guide Zenith Controls hjälper organisationer att omvandla identitetsattacker från kaotiska utredningar till repeterbara och granskningsbara kontrollprocesser.

Varför Identity Threat Detection and Response nu är en styrelsefråga

Identitetsattacker fungerar eftersom de missbrukar legitima åtkomstvägar. En angripare som stjäl en sessionstoken, registrerar en skadlig OAuth-applikation, komprometterar ett tjänstekonto eller lurar en användare genom upprepade MFA-pushnotiser kan se ut som en giltig användare för system som bara kontrollerar om autentiseringen lyckades.

Det gör ITDR annorlunda än traditionellt perimeterskydd. Ett moget program måste kunna besvara:

• Vilka mänskliga identiteter, tjänsteidentiteter, leverantörsidentiteter och applikationsidentiteter finns?
• Vilka identiteter är privilegierade, inaktiva, delade eller externt federerade?
• Vilka autentiseringshändelser är normala, riskfyllda eller omöjliga?
• Vilka OAuth-behörigheter, SaaS-token och API-autentiseringsuppgifter kan ge åtkomst till känsliga data?
• Vilka larm utlöser incidentklassificering, bevarande av bevismaterial och regulatoriska beslut?
• Vilka kontroller visar att åtkomst till personuppgifter skyddas med lämpliga tekniska och organisatoriska åtgärder?

NIS2 gör detta till en styrningsfråga. Article 20 kräver att ledningsorgan i väsentliga och viktiga entiteter godkänner åtgärder för cybersäkerhetsriskhantering, övervakar deras genomförande och får utbildning. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, bedömning av kontrolleffektivitet, cyberhygien, utbildning, åtkomstkontroll, tillgångshantering och flerfaktorsautentisering eller kontinuerlig autentisering där det är lämpligt.

DORA sätter liknande press på finansiella entiteter. Regelverket kräver ett dokumenterat ramverk för IKT-riskhantering, ansvar hos ledningsorganet, detekteringsmekanismer, incidenthantering, klassificering, rapportering, resiliensprovning och IKT-tredjepartsriskhantering. DORA gäller från den 17 januari 2025. För finansiella entiteter som även identifieras enligt NIS2 fungerar DORA som den sektorsspecifika regelboken för överlappande skyldigheter avseende IKT-risker och incidenter.

GDPR lägger till lagret för ansvarsskyldighet inom dataskydd. Article 5 kräver korrekthet, konfidentialitet och ansvarsskyldighet. Article 4 definierar personuppgiftsincident brett, inklusive obehörig åtkomst till personuppgifter. Article 32 kräver lämpliga tekniska och organisatoriska åtgärder för att säkerställa en säkerhetsnivå som är lämplig i förhållande till risken. Vid identitetsincidenter blir loggar, åtkomstkontroller, autentiseringsposter och incidentunderlag centrala för att visa om personuppgifter var skyddade.

ISO/IEC 27001:2022 är ledningssystemet som kan hålla ihop dessa skyldigheter. Clause 4 kräver att organisationen förstår sitt sammanhang, sina intressenter och rättsliga, regulatoriska och avtalsmässiga krav. Clause 6 kräver riskbedömning, riskbehandling, godkännande av riskägare och bevarat underlag. Annex A innehåller kontroller för identitetshantering, säker autentisering, loggning, övervakning, incidenthantering, bevisinsamling, leverantörsrelationer, molntjänster och integritetsskydd.

ITDR hör hemma i ISMS eftersom identitetsrisk blir granskningsbar först när den omfattas, ägs, bedöms, behandlas, övervakas och förbättras.

Identitetsattackscenariot som tillsynsmyndigheter bryr sig om

Betrakta en molnbaserad leverantör av finansiella arbetsflöden som betjänar EU-kunder. Leverantören använder Microsoft 365, en SaaS-plattform för kundsupport, molninfrastruktur, en betalningsförmedlare och flera API-baserade integrationer. En senior supportingenjör får en övertygande uppmaning att återansluta en produktivitetsapplikation. OAuth-samtyckesvyn begär läsåtkomst till postlåda och offlineåtkomst. Ingenjören godkänner.

Inom några minuter använder angriparen token för att söka efter kundidentifierare och supportbilagor. Angriparen enumererar gruppmedlemskap och försöker få åtkomst till en administrationsportal. MFA var aktiverat, men angriparen behöver inte lösenordet igen eftersom token ger bestående åtkomst. SOC ser ovanlig postlådeåtkomst, en ny OAuth-applikation, misslyckade försök mot administrationsportalen och aktivitet från en ovanlig geografi.

Detta enda scenario korsar flera kontrollområden:

• Identitetslivscykeln, eftersom användarens roll och behörigheter avgör spridningseffekten.
• Säker autentisering, eftersom MFA ensamt inte förhindrade tokenmissbruk.
• Loggning och övervakning, eftersom detektering beror på loggar från identitetsleverantör, SaaS och applikationer.
• Incidentrespons, eftersom autentiseringsuppgifter, sessioner, token och OAuth-behörigheter snabbt måste återkallas.
• Bevisinsamling, eftersom exponering av personuppgifter och regulatorisk rapportering kan följa.
• Leverantörs- och molnstyrning, eftersom SaaS-loggar och revisions-API:er ingår i beviskedjan.
• Integritetsskydd, eftersom åtkomst till personuppgifter måste bedömas enligt GDPR.

Den bättre frågan är inte ”Vilket verktyg brast?” Den bättre frågan är om organisationen hade en utformad, testad och granskningsbar ITDR-kontrollkedja.

Kontrollkedjan i ISO 27001:2022 bakom effektiv ITDR

De mest effektiva ITDR-programmen kopplar samman förebyggande, upptäckande, korrigerande och bevisbaserade kontroller.

I Zenith Controls behandlas ISO/IEC 27001:2022 kontroll 5.16 Identity management som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Den kopplas direkt till 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 och 8.2 Privileged access rights.

Detta är viktigt eftersom identitetsdetektering fallerar när identitetsstyrningen är svag. Om ett tjänstekonto är odokumenterat, en leverantörsidentitet är ohanterad eller en privilegierad roll saknar ägare kan övervakningen upptäcka en händelse, men incidenthanterare kan inte tolka den snabbt.

Kontroll 8.5 Secure authentication är ytterligare ett ankare för ITDR. I Zenith Controls kopplas den till identitetshantering, autentiseringsinformation, privilegierade åtkomsträttigheter, begränsning av informationsåtkomst, övervakningsaktiviteter, incidenthantering och integritetsskydd för PII. Autentisering är inte avslutad vid inloggning. Sessionshantering, tokenhantering, skydd av autentiseringsuppgifter och spårbarhet är delar av samma bevisberättelse.

Kontroll 8.16 Monitoring activities är bryggan mellan att samla in loggar och att fatta beslut. Den beror på 8.15 Logging och stödjer 5.25 Assessment and decision on information security events, 5.26 Response to information security incidents och bredare incidenthantering. För ITDR är 8.16 den punkt där misstänkt identitetsbeteende blir en triagerad händelse, en deklarerad incident eller ett dokumenterat falskt positivt utfall.

Tabellen är inte en teoretisk mappning. Den är den praktiska beviskedja som en revisor, styrelseledamot eller tillsynsmyndighet förväntar sig efter en identitetsincident.

Vad Clarysec-policyer tillför: ägarskap, utlösare och regler för bevismaterial

Identitetsverktyg skapar inte automatiskt ansvarsskyldighet. Under en kris behöver incidenthanterare befogenhet att återkalla sessioner, inaktivera konton, exportera loggar, bevara bevismaterial och fatta eskaleringsbeslut. Revisorer behöver se att dessa åtgärder inte improviserades.

Clarysecs policysvit tillhandahåller den operativa modellen.

Från organisationens User Account and Privilege Management Policy User Account and Privilege Management Policy anger klausul 5.9 i styrningskraven:

Organisationen ska upprätthålla en detaljerad förteckning över alla aktiva och inaktiva autentiseringsuppgifter, privilegierade konton och tjänstekonton på systemnivå. Denna förteckning ska uppdateras löpande och granskas kvartalsvis.

Detta gör identitetsförteckningen till en uttrycklig kontrollförpliktelse. Det är särskilt viktigt eftersom tjänstekonton, API-nycklar och inaktiva autentiseringsuppgifter är vanliga blindfläckar i ITDR.

Samma policy anger i klausul 5.8 i styrningskraven:

Alla administrativa aktiviteter och åtgärder i privilegierade konton ska loggas på ett sätt som möjliggör upptäckt av manipulation och övervakas för avvikelser eller policyöverträdelser.

Den klausulen kopplar privilegierad åtkomsthantering till detektering. En privilegierad åtgärd är inte bara tillåten eller nekad. Den måste övervakas med avseende på beteende som inte stämmer med användaren, rollen, källan, tiden eller verksamhetsprocessen.

För mindre organisationer ger User Account and Privilege Management Policy - SME User Account and Privilege Management Policy - SME en koncis förväntan i klausul 8.1.1 om efterlevnad och verkställighet:

IT-ansvarig ska regelbundet granska systemloggar avseende försök till obehörig åtkomst, inloggningsavvikelser eller ej godkända ändringar av privilegier.

Det är här många ITDR-program för små och medelstora företag börjar. Det kräver inte ett stort SOC. Det kräver utpekat ägarskap och regelbunden granskning av rätt identitetssignaler.

Loggningspolicyn ger grunden för bevismaterial. Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME anger i klausul 5.4.2 i styrningskraven:

Autentiseringsloggar: lyckade och misslyckade inloggningsförsök, sessionslängd, MFA-användning

Dessa fält är inte valfria. De hjälper till att visa om den misstänkta händelsen omfattade lyckad autentisering, upprepade misslyckanden, MFA-användning, bestående session eller onormal varaktighet.

Organisationens Logging and Monitoring Policy Logging and Monitoring Policy utökar det loggomfång som krävs i klausul 6.1.1 om krav för policyimplementering:

Alla omfattade system ska generera loggar som fångar: 6.1.1.1 Användarautentisering och åtkomstförsök 6.1.1.2 Aktiviteter av privilegierade användare 6.1.1.3 Konfigurationsändringar 6.1.1.4 Misslyckade åtkomstförsök eller systemhändelser 6.1.1.5 Detekteringar av skadlig kod och säkerhetslarm 6.1.1.6 Extern kommunikation och utlösare för brandväggsregler

Konfigurationsändringar är särskilt viktiga vid identitetsattacker. Angripare lägger ofta till OAuth-behörigheter, skapar vidarebefordringsregler, registrerar enheter, ändrar MFA-metoder eller skapar nödåtkomstvägar.

Incidentresponspolicyn ger därefter incidenthanterare befogenhet. Organisationens Incident Response Policy Incident Response Policy anger i klausul 6.2.1 om krav för policyimplementering:

SOC ska omedelbart isolera berörda system, återkalla komprometterade autentiseringsuppgifter eller blockera skadlig trafik med hjälp av brandväggs- eller endpointskyddsverktyg.

SME-versionen Incident Response Policy - SME Incident Response Policy - SME anger i klausul 4.2.2 om roller och ansvar:

Genomför begränsnings- och återställningsåtgärder, till exempel genom att inaktivera åtkomst eller återställa säkerhetskopior.

För ITDR räcker det inte att återkalla ett lösenord. Runbooks måste omfatta inaktivering av konton, återkallelse av sessioner, ogiltigförklaring av OAuth-behörigheter, rotation av hemligheter, återställning av MFA-metoder och granskning av delegerade behörigheter.

Bevismaterialhantering är skillnaden mellan att agera och att kunna visa vad som gjordes. Organisationens Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy anger i klausul 5.5 i styrningskraven:

Allt insamlat bevismaterial ska identifieras unikt, märkas och lagras i ett säkert dokumentarkiv med: 5.5.1 Integritetsverifiering, till exempel SHA-256-hashvärden 5.5.2 Tidsstämplade åtkomstloggar 5.5.3 Poster i beviskedjan signerade av varje ansvarig bevisförvaltare

SME-versionen Evidence Collection and Forensics Policy - SME Evidence Collection and Forensics Policy - SME anger i klausul 6.1.1 om krav för policyimplementering:

En forensisk kopia eller export ska alltid skapas; originalbevismaterialet får aldrig redigeras direkt.

I FinScale-scenariot innebär det att SOC exporterar loggar från identitetsleverantören, SaaS-revisionsloggar, poster över postlådeåtkomst, OAuth-samtyckesposter, poster över återkallelse av sessioner och SIEM-larm till ett bevisarkiv med integritetsskydd och beviskedja.

Bygg ITDR-färdplanen med Zenith Blueprint

Zenith Blueprint översätter kontrollkedjan till genomförandesteg.

I fasen Controls in Action, Step 19, Technological Controls I, är Blueprint tydlig om autentisering:

Där det är möjligt bör autentisering enbart med lösenord undvikas, särskilt för administrativa konton, molnkonsoler, verktyg för fjärråtkomst och system som är exponerade mot internet. MFA, med en andra faktor som hårdvarunyckel, mobilapp eller biometri, är nu en baslinje, inte en lyx. Det minskar riskerna för stöld av autentiseringsuppgifter, phishing och brute force- attacker.

Samma steg går längre än lösenord. Det kräver säker lagring och överföring av autentiseringsdata, säker hantering av API-token, sessions-ID:n och OAuth-autentiseringsuppgifter, hemlighetshantering för maskin-till-maskin-autentisering, tokenrotation, styrning av sessionslivslängd, säkra cookie-flaggor och granskning av autentiseringsloggar.

Step 22, Organizational Controls, formaliserar åtkomstlivscykeln. Den vägleder team att integrera åtkomsttilldelning och behörighetsavveckling med HR, genomföra dokumenterade kvartalsvisa åtkomstgranskningar, definiera identitetstyper såsom individuella konton, delade konton och tjänstekonton, kräva MFA för privilegierade konton, eliminera inaktiva konton och rotera autentiseringsuppgifter för tjänstekonton.

Step 19 tillhandahåller även förbättringsvägen för loggning: vidarebefordra kritiska loggar till ett SIEM eller en loggaggregator, validera bevarande, spåra en nylig händelse med loggar, dokumentera funktioner för loggintegritet och bekräfta larmning för misslyckade inloggningar eller privilegiehöjningar. Tidssynkronisering är viktig eftersom incidentrekonstruktion fallerar när identitetsleverantörens, SaaS-plattformens, endpointens och molnets loggar inte är överens om tidsstämplar.

Step 23, Organizational Controls for 5.19 to 5.37, validerar förmågor för incidenthantering. Den kräver en uppdaterad incidenthanteringsplan, definierade rapporteringspliktiga händelser, skrivbordsövningar, dokumenterade beslut, kommunikationsposter, erfarenhetsåterföring och bevarande av forensisk bevisning såsom loggögonblicksbilder, säkerhetskopior och säker isolering.

En pragmatisk ITDR-sekvens med Clarysec ser ut så här:

1. Definiera identitetstyper och ägare.
2. Säkra autentisering, token och sessioner.
3. Samla in autentiseringsloggar, privilegieloggar och SaaS-loggar.
4. Övervaka riskfyllt beteende.
5. Definiera beslutsregler från händelse till incident.
6. Bevara bevismaterial.
7. Rapportera, återställ och förbättra.

Ett ITDR-bevispaket på en vecka

Ett fokuserat ”bevispaket för identitetsincidenter” är ett av de snabbaste sätten att synliggöra luckor. Välj ett högriskscenario, till exempel: ”En privilegierad SaaS-användare ger samtycke till en obehörig OAuth-applikation och token används för att komma åt kunddata.”

Bygg sedan bevispaketet på en vecka.

Inkludera minst ett faktiskt spår. Ta en godartad nylig inloggningsavvikelse och visa hur teamet rör sig från larm till användaridentitet, enhet, käll-IP, MFA-metod, sessionslängd, åtkomna SaaS-resurser, berörda data och beslut om begränsning. Om organisationen inte kan rekonstruera den kedjan i en skrivbordsövning kommer den att få svårt under en verklig incident.

Resultatet blir återanvändbart underlag för internrevisioner enligt ISO/IEC 27001:2022, testning av DORA-processer för IKT-incidenter, NIS2-tillsyn över cyberhygien och ansvarsskyldighet enligt GDPR.

Mappning av ITDR till NIS2, DORA och GDPR Article 32

Styrkan i en enhetlig ITDR-modell är att samma underlag uppfyller flera skyldigheter, samtidigt som varje ramverks språkbruk respekteras.

NIS2 Article 21 förväntar riskbaserade, proportionerliga tekniska, operativa och organisatoriska åtgärder. För ITDR innebär det åtkomstkontroll, tillgångshantering, cyberhygien, utbildning, incidenthantering, bedömning av kontrolleffektivitet och MFA eller kontinuerlig autentisering där det är lämpligt. Article 23 skapar stegvis rapportering för betydande incidenter, inklusive tidig varning inom 24 timmar, incidentanmälan inom 72 timmar och slutrapport inom en månad.

DORA Articles 8 to 14 kräver identifiering av IKT-tillgångar och beroenden, skydd och förebyggande åtgärder, detekteringsmekanismer, kontinuitet och återställning, lärande och kommunikation. Articles 17 to 19 kräver incidenthantering, identifiering av rotorsak, indikatorer för tidig varning, klassificering efter allvarlighetsgrad och tjänstekritikalitet, eskalering, underrättelse till ledningsorgan, rapportering till behörig myndighet och kundunderrättelse när finansiella intressen påverkas.

GDPR kräver lämpliga tekniska och organisatoriska åtgärder samt påvisbar ansvarsskyldighet. Vid identitetsattacker omfattar GDPR-frågorna om obehörig åtkomst inträffade, vilka personuppgifter som berördes, om skyddsåtgärder fungerade och om trösklar för incidentanmälan utlöses.

För fintechföretag är relationen mellan NIS2 och DORA viktig. DORA behandlas som det sektorsspecifika ramverket för finansiella entiteter inom tillämpningsområdet där överlappande skyldigheter avseende IKT-risk och incidentrapportering finns. I praktiken bör organisationer bygga en ITDR-bevismodell och mappa rapporteringsbeslut till den tillämpliga rättsliga vägen.

För SaaS-, moln-, hanterade tjänste-, hanterade säkerhets- och digitala plattformsorganisationer måste NIS2-omfattningen kontrolleras noggrant. NIS2 omfattar många sektorer i Annex I och Annex II, inklusive digital infrastruktur, molntjänstleverantörer, datacenter, betrodda tjänster, DNS, TLD-register, hanterade tjänsteleverantörer, leverantörer av hanterade säkerhetstjänster, onlinemarknadsplatser, sökmotorer och sociala nätverksplattformar. Omfattningsbestämning enligt ISO/IEC 27001:2022 Clause 4 och intressentanalys är därför inte pappersarbete. De definierar vilka skyldigheter ISMS måste hantera.

Leverantörs- och SaaS-identitetsrisk

Identitetsincidenter beror ofta på leverantörsunderlag. Kan SaaS-leverantören exportera revisionsloggar? Visar den OAuth-samtyckeshändelser? Stödjer den säkra åtkomstkontroller, loggning och dataskydd? Är incidentstöd, datalagringsplats, underleverantörer, åtkomsträttigheter och exitbestämmelser reglerade i avtal?

Clarysecs Cloud Usage Policy - SME Cloud Usage Policy - SME innehåller ett direkt krav från klausul 5.2.4 i styrningskraven:

Tjänsten tillhandahåller säkra åtkomstkontroller, loggning och dataskyddsförmågor

Den enkla meningen är en upphandlingskontroll. Om en SaaS-plattform inte kan producera de identitetsloggar som behövs för incidentrespons skapar den efterlevnadsrisk.

DORA gör detta uttryckligt genom skyldigheter avseende IKT-tredjepartsrisk. Finansiella entiteter förblir ansvariga för efterlevnad, måste upprätthålla register över IKT-tjänsteavtal, skilja ut kritiska eller viktiga funktioner, genomföra leverantörsgranskning, bedöma koncentrationsrisk, inkludera revisionsrätt och åtkomsträttigheter, definiera incidentstöd och säkerställa exitstrategier.

I Zenith Controls kopplas ISO/IEC 27001:2022 kontroll 8.16 Monitoring activities till 5.22 Monitoring, review and change management of supplier services. Det speglar den operativa verkligheten. Larm från identitetsleverantörer, SaaS-revisionsloggar, aktivitet från molnadministratörer och konton hos hanterade tjänsteleverantörer utgör alla delar av ITDR-ytan.

Hur revisorer bedömer ITDR

Ett starkt ITDR-program ska tåla flera revisionsperspektiv. Varje målgrupp ställer olika frågor, men underlaget ska komma från samma kontrollsystem.

En revisor för ISO/IEC 27001:2022 kommer att fråga om identitetshot ingår i riskbedömningen, om riskägare har godkänt behandlingen, om tillämpbarhetsförklaringen omfattar relevanta Annex A-kontroller, om policyer är införda och om underlag visar att kontrollerna fungerar. Revisorn kan ta stickprov på ett privilegierat konto och spåra godkännande, MFA-inställning, loggaktivitet, åtkomstgranskning och behörighetsavveckling.

En bedömare enligt NIST CSF 2.0 kommer att granska resultaten GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER. ITDR passar naturligt in i en profil avgränsad till identitetskompromettering, SaaS-tokenmissbruk eller missbruk av privilegierad åtkomst.

En DORA-granskare kommer att leta efter ansvar hos ledningsorganet, IKT-stödda verksamhetsfunktioner, detekteringsmekanismer, kriterier för incidentklassificering, eskalering, regler för kundkommunikation, rotorsaksanalys och IKT-tredjepartsberoenden.

En GDPR-granskare kommer att fråga om organisationen kan visa lämplig säkerhet för personuppgifter. Granskaren kommer att undersöka åtkomstbegränsning, detektering av obehörig åtkomst, loggar som visar vilka data som kan ha åtkommits, bedömning av personuppgiftsincident och underlag för ansvarsskyldighet.

En revisor enligt COBIT 2019 eller ISACA-modell kommer att granska styrning, kontrollmål, ägarskap, prestandaövervakning och kontrollsäkring.

Zenith Controls är användbar här eftersom den fungerar som en guide för tvärgående efterlevnad. Den skapar inte separata ”Zenith-kontroller”. Den mappar kontrollområden i ISO/IEC 27001:2022 till relaterade ISO-kontroller, andra standarder, revisionsförväntningar och genomföranderelationer.

Mätetal som visar att ITDR fungerar

Styrelser och revisorer behöver inte rått SIEM-brus. De behöver underlag som visar att identitetskontroller fungerar och förbättras. Användbara ITDR-mätetal omfattar:

• Andel privilegierade konton med phishingresistent MFA.
• Antal inaktiva konton som är äldre än policytröskeln.
• Antal tjänstekonton utan ägare eller rotationsdatum.
• Andel kritiska SaaS-plattformar som skickar autentiseringsloggar till SIEM.
• Genomsnittlig tid till detektering av misstänkt identitetsaktivitet.
• Genomsnittlig tid till återkallelse av komprometterade sessioner och token.
• Antal OAuth-applikationer som godkänts, avslagits eller tagits bort.
• Andel identitetsincidenter med kompletta bevispaket.
• Antal försenade iakttagelser från åtkomstgranskning.
• Antal leverantörsplattformar som saknar obligatoriska identitetsloggar.

Dessa mätetal bör mata ledningens genomgång enligt ISO/IEC 27001:2022, NIS2-styrningstillsyn, DORA-rapportering av IKT-risk och diskussioner om ansvarsskyldighet enligt GDPR.

Vanliga ITDR-revisionsiakttagelser och åtgärder

Clarysec ser ofta fem återkommande iakttagelser.

För det första aktiverar organisationer MFA men övervakar inte MFA-beteende. Åtgärda detta genom att logga ändringar av MFA-metod, misslyckade utmaningar, omöjliga resor, registrering av nya enheter och upprepade pushförsök.

För det andra undantas tjänstekonton från identitetsstyrning. Åtgärda detta genom att inventera konton på systemnivå, tilldela ägare, rotera hemligheter, ta bort inbäddade autentiseringsuppgifter och övervaka avvikande API-beteende.

För det tredje är SaaS-samtycke ohanterat. Åtgärda detta genom att begränsa användarsamtycke, granska OAuth-applikationer, övervaka nya behörigheter, dokumentera godkända integrationer och ta bort oanvända appar.

För det fjärde ändras bevismaterial under utredning. Åtgärda detta genom att följa regeln i Evidence Collection and Forensics Policy: skapa forensiska kopior eller exporter, redigera aldrig original direkt och lagra bevismaterial med hashar och poster i beviskedjan.

För det femte är incidentklassificeringen för långsam. Åtgärda detta genom att på förhand definiera trösklar för identitetshändelser, inklusive kompromettering av privilegierade konton, åtkomst till personuppgifter, SaaS-tokenmissbruk med kundpåverkan, avbrott i kritisk tjänst och kompromettering av leverantörsidentitet.

Varje iakttagelse har ett kontroll-, policy- och bevismaterialssvar. Det är det praktiska värdet av ett enhetligt ITDR-program: det definierar vad som ska ägas, övervakas, testas, beläggas och förbättras.

Omvandla identitetsrisk till revisionsklart underlag

Om nästa identitetsincident inträffade i morgon, skulle ni kunna visa vem som kom åt vad, hur personen autentiserades, vilken token eller session som användes, vilka data som berördes, vem som beslutade om regulatorisk klassificering och vilka korrigerande åtgärder som slutfördes?

Om svaret är osäkert, börja med en fokuserad ITDR-beredskapssprint.

Använd Zenith Blueprint för att strukturera införandevägen över autentisering, åtkomstlivscykel, loggning, övervakning, incidentrespons och bevismaterialhantering. Använd Clarysecs policyer för åtkomstkontroll, loggning, moln, incidentrespons och forensik för att tilldela ägarskap och befogenhet att agera. Använd Zenith Controls för att mappa identitetshantering, säker autentisering och övervakningsaktiviteter till ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 och revisionsförväntningar.

Målet är enkelt: gör identitetsattacker möjliga att detektera, begränsa, rapportera och försvara.

Clarysec kan hjälpa er att bygga ett ITDR-bevispaket, testa det genom en skrivbordsövning och omvandla iakttagelserna till en riskbehandlingsplan som styrelsen, tillsynsmyndigheten och revisorn kan förstå. Börja med att granska Logging and Monitoring Policy, User Account and Privilege Management Policy - SME, Zenith Blueprint och Zenith Controls, och boka därefter en ITDR-beredskapsbedömning för att omvandla identitetsrisk till revisionsklart underlag.