DORA TLPT-bevismateriale med ISO 27001-kontroller

Klokken er 07:40 en mandag morgen, og informationssikkerhedschefen i et mellemstort betalingsinstitut ser på tre versioner af det samme ubehagelige spørgsmål.

Bestyrelsen vil vide, om organisationen kan overleve et ransomware-drevet nedbrud i kundernes betalingsportal. Tilsynsmyndigheden vil have bevis for, at test af digital operationel robusthed ikke blot er en PowerPoint-øvelse. Intern audit ønsker et klart spor fra DORA-forpligtelser til IKT-risiko, ISO 27001-kontroller, testresultater, afhjælpningsplaner, leverandørbevismateriale og ledelsens godkendelse.

Informationssikkerhedschefen har en red team-rapport. SOC har skærmbilleder af alarmer. Infrastrukturteamet har en log over gendannelse fra backup. Juridisk afdeling har en tracker for DORA-parathed. Indkøb har attester fra cloudleverandører.

Intet af det hænger sammen.

Det er her, mange DORA TLPT- og robusthedstestprogrammer fejler. Ikke fordi testen er svag, men fordi bevismaterialet er fragmenteret. Når en revisor spørger: “Vis mig, hvordan denne test dokumenterer robustheden af en kritisk eller vigtig funktion,” kan svaret ikke være en mappe fuld af skærmbilleder. Det skal være en forsvarlig beviskæde.

Det er i den kæde, et ISO/IEC 27001:2022-tilpasset ISMS ISO/IEC 27001:2022 bliver stærkt. ISO 27001 giver struktur til omfang, risikovurdering, kontroludvælgelse, Anvendelseserklæring, operationel styring, intern audit, ledelsens evaluering og løbende forbedring. DORA tilfører det sektorspecifikke pres. Clarysecs metode og værktøjer til krydsoverholdelse forbinder begge dele i én revisionsklar model for bevismateriale.

DORA TLPT er en governance-test, ikke kun en angrebssimulering

Trusselsbaseret penetrationstest, eller TLPT, er let at misforstå. Teknisk kan den ligne en avanceret red team-øvelse: trusselsefterretning, realistiske angrebsveje, stealth, exploitforsøg, scenarier for lateral bevægelse og validering af blue team-respons.

For DORA er det dybere spørgsmål digital operationel robusthed. Kan den finansielle enhed modstå, reagere på og komme sig efter alvorlige IKT-forstyrrelser, der påvirker forretningsprocesser? Kan den dokumentere, at kritiske eller vigtige funktioner forbliver inden for fastsatte påvirkningstolerancer? Kan ledelsen dokumentere, at IKT-risiko styres, finansieres, testes, afhjælpes og forbedres?

DORA Article 1 fastlægger en ensartet EU-ramme for sikkerheden i net- og informationssystemer, der understøtter finansielle enheders forretningsprocesser. Den omfatter styring af IKT-risiko, rapportering af større IKT-relaterede hændelser, test af digital operationel robusthed, styring af IKT-tredjepartsrisiko, obligatoriske kontraktkrav til IKT-leverandører, tilsyn med kritiske IKT-tredjepartsudbydere og tilsynsmæssigt samarbejde. DORA finder anvendelse fra 17. januar 2025.

For organisationer, der også er omfattet af NIS2, fungerer DORA som den sektorspecifikke EU-retsakt for overlappende cybersikkerhedskrav. I praksis bør finansielle enheder prioritere DORA for styring af IKT-risiko, hændelsesrapportering, test og IKT-tredjepartsrisiko, hvor regelsættene overlapper, samtidig med at de fortsat forstår NIS2-forventningerne til koncernstrukturer, leverandører og ikke-finansielle digitale tjenester.

DORA placerer også ansvarligheden øverst. Article 5 kræver, at ledelsesorganet definerer, godkender, fører tilsyn med og implementerer ordninger for IKT-risikostyring. Det omfatter strategien for digital operationel robusthed, politik for IKT-forretningskontinuitet, respons- og genopretningsplaner, auditplaner, budgetter, politikker for IKT-tredjeparter, rapporteringskanaler og tilstrækkelig viden om IKT-risiko gennem regelmæssig træning.

Revisionsspørgsmålet er derfor ikke blot: “Har I gennemført en TLPT?”

Det er:

• Var TLPT’en knyttet til kritiske eller vigtige funktioner?
• Var den godkendt, afgrænset, sikker og risikovurderet?
• Var leverandører, cloudafhængigheder og outsourcede IKT-tjenester medtaget, hvor det var relevant?
• Skabte testen bevismateriale for detektion, respons, genopretning og læring?
• Blev konstateringer omsat til risikobehandling, sporet afhjælpning, gentest og ledelsesrapportering?
• Forklarede Anvendelseserklæringen, hvilke ISO 27001 Annex A-kontroller der var valgt til at håndtere risikoen?

Derfor behandler Clarysec DORA TLPT-bevismateriale som et ISMS-bevisspørgsmål, ikke kun som en leverance fra penetrationstest.

Opbyg ISO 27001-bevissporet, før testen starter

ISO 27001 kræver, at en organisation etablerer, implementerer, vedligeholder og løbende forbedrer et ISMS, der beskytter fortrolighed, integritet og tilgængelighed gennem en risikostyringsproces. Clauses 4.1 to 4.4 kræver, at organisationen forstår interne og eksterne forhold, interessenter, retlige og regulatoriske forpligtelser, grænseflader og afhængigheder og derefter dokumenterer ISMS-omfanget.

For en DORA-reguleret enhed bør denne afgrænsning eksplicit omfatte kritiske eller vigtige funktioner, IKT-aktiver, cloudplatforme, outsourcede driftsaktiviteter, betalingssystemer, kundeportaler, identitetstjenester, logningsplatforme, genopretningsmiljøer og IKT-tredjepartsleverandører. Hvis TLPT-omfanget ikke kan spores tilbage til ISMS-omfanget, er revisionssporet allerede svagt.

ISO 27001 Clauses 6.1.1, 6.1.2 and 6.1.3 kræver sammen med Clauses 8.2 and 8.3 en proces for risikovurdering og risikobehandling. Risici skal identificeres i forhold til fortrolighed, integritet og tilgængelighed. Risikoejere skal udpeges. Sandsynlighed og konsekvens skal vurderes. Kontroller skal udvælges og sammenholdes med Annex A. Restrisiko skal accepteres af risikoejere.

Dette er broen mellem DORA og revisionsklar test.

Clarysecs Zenith Blueprint: En auditors 30-trins køreplan Zenith Blueprint beskriver i risikostyringsfasen, Step 13, denne sporbarhedsrolle klart:

SoA’en er reelt et brodokument: Den forbinder jeres risikovurdering/-behandling med de faktiske kontroller, I har. Når I udfylder den, dobbelttjekker I samtidig, om I har overset kontroller.

For DORA TLPT bør Anvendelseserklæringen ikke være et statisk certificeringsartefakt. Den bør forklare, hvorfor kontroller som leverandørsikkerhed, hændelsesstyring, IKT-parathed til forretningskontinuitet, logning, overvågning, teknisk sårbarhedsstyring, backup, sikker udvikling og sikkerhedstest er relevante for robusthedsscenariet.

Et praktisk risikoscenarie kan formuleres sådan:

“Kompromittering af privilegerede legitimationsoplysninger hos en identitetsudbyder giver en angriber adgang til administrationssystemer for betalingsbehandling, mulighed for at ændre routingkonfigurationer og forstyrre en kritisk betalingsfunktion, hvilket medfører driftsafbrydelse, regulatoriske rapporteringsforpligtelser, kundeskade og omdømmeskade.”

Det ene scenarie kan drive TLPT-omfang, detektions-use cases, leverandørinvolvering, genopretningsøvelse, bestyrelsesrapportering og bevismateriale.

Zenith Blueprint anbefaler også at gøre regulatorisk sporbarhed eksplicit:

Krydshenvis regler: Hvis bestemte kontroller implementeres specifikt for at overholde GDPR, NIS2 eller DORA, kan I notere det enten i risikoregisteret (som en del af begrundelsen for risikopåvirkning) eller i SoA-noterne.

Rådet er enkelt, men det ændrer revisionsdialogen. I stedet for at fortælle en revisor, at DORA er taget i betragtning, kan organisationen vise, hvor DORA optræder i risikoregisteret, SoA, testprogrammet, politikgrundlaget og ledelsens evaluering.

Kortlæg DORA-test til ISO 27001-kontroller, som revisorer genkender

DORA Article 6 forventer en dokumenteret styringsramme for IKT-risiko, som er integreret i den samlede risikostyring. ISO 27001 Annex A leverer det kontrolkatalog, der gør dette operationelt.

For DORA TLPT og robusthedstest er disse ISO/IEC 27001:2022 Annex A-kontroller særligt vigtige:

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls hjælper organisationer med at undgå at behandle disse kontroller som isolerede tjeklistepunkter. Den kortlægger ISO/IEC 27002:2022-kontroller til attributter, domæner, operationelle kapabiliteter, revisionsforventninger og mønstre på tværs af rammeværker.

For eksempel klassificerer Zenith Controls ISO/IEC 27002:2022-kontrol 5.30, IKT-parathed til forretningskontinuitet, som “korrigerende”, tilpasset “tilgængelighed”, forbundet med cybersikkerhedskonceptet “Respond” og placeret i domænet “Resilience”. Den klassifikation er nyttig, når man over for revisorer skal forklare, hvorfor en genopretningsøvelse ikke blot er en IT-driftsaktivitet, men en robusthedskontrol med en defineret rolle i kontrolmiljøet.

Zenith Controls klassificerer også kontrol 8.29, sikkerhedstest i udvikling og accept, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, med operationelle kapabiliteter inden for applikationssikkerhed, informationssikkerhedsassurance samt system- og netværkssikkerhed. For TLPT-konstateringer, der kan spores tilbage til svagheder i applikationsdesign, usikker API-adfærd, svage autentifikationsflows eller utilstrækkelig validering, er dette kontrolvejen ind i styring af sikker udvikling.

Kontrol 5.35, uafhængig gennemgang af informationssikkerhed, er også vigtig. Den understøtter uafhængig udfordring, styringsmæssig assurance og korrigerende forbedring. Interne teams kan koordinere test, men revisionsklart bevismateriale kræver gennemgang, eskalering og tilsyn ud over de personer, der har bygget eller driftet de testede systemer.

Beskyt systemet, mens det testes

En farlig antagelse i robusthedstest er, at test automatisk er godt. I praksis kan indgribende test skabe nedbrud, eksponere følsomme data, forurene logfiler, udløse automatiserede forsvar, afbryde kundesessioner eller få leverandører til at aktivere nødprocedurer.

Clarysecs Politik for sikkerhedstest og red teaming Politik for sikkerhedstest og red teaming giver organisationer et styringsmønster for sikker gennemførelse. Clause 6.1 fastslår:

Typer af test: Sikkerhedstestprogrammet skal som minimum omfatte: (a) sårbarhedsscanning, bestående af automatiserede ugentlige eller månedlige scanninger af netværk og applikationer for at identificere kendte sårbarheder; (b) penetrationstest, bestående af manuel dybdegående test af specifikke systemer eller applikationer udført af kvalificerede testere for at identificere komplekse svagheder; og (c) red team-øvelser, bestående af scenariebaserede simuleringer af reelle angreb, herunder social engineering og andre taktikker, for at teste organisationens samlede detektions- og responskapabiliteter.

For TLPT er red team-elementet åbenlyst, men revisionsværdien kommer fra programdesignet. Sårbarhedsscanning, penetrationstest, red team-øvelser, robusthedsøvelser og gentest bør udgøre en cyklus, ikke en samling af usammenhængende test.

Clause 6.2 i samme politik adresserer sikker gennemførelse:

Omfang og spilleregler: For hver test eller øvelse skal STC definere omfanget, herunder systemer og IP-intervaller i scope, tilladte testmetoder, mål, tidspunkt og varighed. Spilleregler skal dokumenteres. For eksempel kan driftsmæssigt følsomme systemer udpeges som monitor-only for at undgå forstyrrelser, og enhver test i produktion skal omfatte tilbagerulnings- og stopprocedurer. Sikkerhedsforanstaltninger, såsom definerede tidsvinduer og kommunikationskanaler, skal etableres for at forhindre utilsigtede driftsafbrydelser.

Dette kortlægges direkte til Zenith Blueprint, fasen Controls in Action, Step 21, som fokuserer på ISO 27001 Annex A-kontrol 8.34, beskyttelse af informationssystemer under audit- og testaktiviteter. Zenith Blueprint advarer om, at audit, penetrationstest, forensiske gennemgange og operationelle evalueringer kan indebære forhøjet adgang, indgribende værktøjer eller midlertidige ændringer i systemadfærd. Den fremhæver godkendelse, omfang, tidsvinduer, systemejerens godkendelse, tilbagerulning, overvågning og sikker håndtering af testdata.

Den revisionsklare pakke med bevismateriale bør omfatte:

• TLPT-mandat og mål
• Resumé af trusselsefterretning og scenariebegrundelse
• Kritiske eller vigtige funktioner i scope
• Systemer, IP-intervaller, identiteter, leverandører og miljøer i scope
• Undtagelser og monitor-only-systemer
• Spilleregler
• Risikovurdering for test i produktion
• Tilbagerulnings- og stopprocedurer
• SOC-underretningsmodel, herunder hvad der deles, og hvad der tilbageholdes
• Godkendelser fra juridisk afdeling, databeskyttelsesfunktion og leverandører
• Bevismateriale for oprettelse og tilbagekaldelse af testkonti
• Sikker lagringsplacering for testartefakter og logfiler

En DORA TLPT, der ikke kan vise sikker godkendelse og kontrol med testaktiviteten, kan afdække robusthedshuller, men den skaber også governance-huller.

Omsæt TLPT-output til risikobehandling

Den mest almindelige fejl efter test er red team-rapporten, der ender på hylden. En rapport af høj kvalitet leveres, rundsendes, drøftes og mister derefter gradvist momentum. Konstateringer forbliver åbne. Kompenserende kontroller dokumenteres ikke. Accepterede risici er uformelle. Gentest gennemføres aldrig.

Politik for sikkerhedstest og red teaming gør dette uacceptabelt. Clause 6.6 fastslår:

Afhjælpning af konstateringer: Alle identificerede sårbarheder eller svagheder skal dokumenteres i en konstateringsrapport med alvorlighedsvurderinger. Efter modtagelse af rapporten er systemejere ansvarlige for at udarbejde en afhjælpningsplan med forfaldsdatoer; eksempelvis skal kritiske konstateringer afhjælpes inden for 30 dage og konstateringer med høj alvorlighed inden for 60 dage i overensstemmelse med organisationens Politik for sårbarheds- og patchstyring. STC skal følge fremdriften i afhjælpningen. Gentest skal udføres for at bekræfte, at kritiske forhold er løst eller tilstrækkeligt afbødet.

Clause 6.7 tilføjer styringslaget:

Rapportering: En formel rapport skal udstedes ved afslutningen af hver test. For penetrationstest skal rapporten omfatte et ledelsesresumé, metode og detaljerede konstateringer med understøttende bevismateriale og anbefalinger. For red team-øvelser skal rapporten beskrive scenarierne, hvilke angrebsveje der lykkedes, hvad Blue Team detekterede, og læringspunkter vedrørende huller i detektion og respons. CISO skal præsentere sammenfattede resultater og afhjælpningsstatus for øverste ledelse og, hvor det er relevant, medtage dem i den årlige sikkerhedsrapport til bestyrelsen.

Dette er i overensstemmelse med ISO/IEC 27005:2022-vejledning om risikobehandling: vælg behandlingsmuligheder, fastlæg kontroller fra ISO 27001 Annex A og sektorspecifikke krav, udarbejd en risikobehandlingsplan, udpeg ansvarlige personer, definer tidsplaner, følg status, indhent godkendelse fra risikoejer og dokumentér accept af restrisiko.

Enhver væsentlig TLPT-konstatering bør blive til én af fire ting: en afhjælpende foranstaltning, en kontrolforbedring, en formel risikoaccept eller et krav om gentest.

Målet er ikke at producere flere dokumenter. Målet er, at hvert dokument forklarer den næste beslutning.

Robusthedstest skal dokumentere genopretning, ikke kun detektion

En vellykket TLPT kan vise, at SOC detekterede command-and-control-trafik, blokerede lateral bevægelse og eskalerede korrekt. Det er værdifuldt, men DORA-robusthedstest går videre. Den spørger, om organisationen kan fortsætte eller genoprette forretningstjenester.

Zenith Blueprint, fasen Controls in Action, Step 23, forklarer kontrol 5.30, IKT-parathed til forretningskontinuitet, med et sprog, enhver informationssikkerhedschef bør bruge med bestyrelsen:

Fra et revisionsperspektiv testes denne kontrol ofte med én enkelt formulering: Vis mig det. Vis mig det seneste testresultat. Vis mig genopretningsdokumentationen. Vis mig, hvor lang tid det tog at skifte over og tilbage. Vis mig bevismaterialet for, at det, der er lovet, faktisk kan leveres.

Denne “Vis mig det”-standard er forskellen mellem politikmodenhed og operationel robusthed.

Clarysecs Politik for forretningskontinuitet og katastrofeberedskab-SMV Politik for forretningskontinuitet og katastrofeberedskab - SMV, fra afsnittet “Krav til implementering af politikken”, clause 6.4.1, fastslår:

Organisationen skal teste både sine BCP- og DR-kapabiliteter mindst én gang årligt. Test skal omfatte:

Samme politiks afsnit om håndhævelse, clause 8.5.1, gør ansvar for bevismateriale eksplicit:

GM skal sikre, at følgende vedligeholdes og er revisionsklart:

For en DORA-reguleret finansiel enhed kan årlig test være minimumsniveauet, ikke ambitionen. Kritiske eller vigtige funktioner med højere risiko bør testes hyppigere, særligt efter arkitekturændringer, cloudmigrering, større hændelser, nye IKT-leverandører, væsentlige applikationsreleases eller ændringer i trusselseksponeringen.

En stærk bevispakke for robusthedstest bør omfatte:

• Forretningskonsekvensanalyse, der kortlægger den kritiske eller vigtige funktion
• RTO og RPO godkendt af forretningsejere
• Kort over systemafhængigheder, herunder identitet, DNS, netværk, cloud, database, overvågning, backup og tredjepartstjenester
• Resultater fra backup- og gendannelsestest
• Tidsstempler for failover og failback
• Bevismateriale for, at sikkerhedskontroller fungerer under forstyrrelser
• Skabeloner for kommunikation til kunder, tilsynsmyndigheder og interne interessenter
• Deltagerlogfiler for incident commander og kriseteam
• Læringspunkter og forbedringstiltag
• Bevismateriale for gentest af tidligere genopretningshuller

Det er også her, GDPR kommer ind i billedet. GDPR Article 2 og Article 3 bringer det meste SaaS- og fintech-behandling af EU-personoplysninger ind i omfanget. Article 4 definerer personoplysninger, behandling, dataansvarlig, databehandler og brud på persondatasikkerheden. Article 5 kræver integritet, fortrolighed og ansvarlighed, hvilket betyder, at organisationen skal kunne dokumentere overholdelse. Hvis TLPT eller genopretningstest bruger produktionsdata med personoplysninger, kopierer logfiler med identifikatorer eller validerer brudhåndtering, skal databeskyttelsesforanstaltninger dokumenteres.

Leverandørbevismateriale er DORA-blindvinklen, som revisorer ikke ignorerer

Moderne finansielle tjenester sammensættes af cloudplatforme, SaaS-applikationer, managed security providers, betalingsbehandlere, dataplatforme, identitetsudbydere, observability-værktøjer, outsourcede udviklingsteams og backupudbydere.

DORA Article 28 kræver, at finansielle enheder styrer IKT-tredjepartsrisiko som en del af styringsrammen for IKT-risiko og forbliver fuldt ansvarlige, også når IKT-tjenester er outsourcet. Article 30 kræver skriftlige IKT-servicekontrakter med servicebeskrivelser, betingelser for underleverandører, behandlingslokationer, databeskyttelse, adgang og genopretning, serviceniveauer, assistance ved hændelser, samarbejde med myndigheder, opsigelsesrettigheder, stærkere vilkår for kritiske eller vigtige funktioner, revisionsrettigheder, sikkerhedsforanstaltninger, TLPT-deltagelse hvor relevant og exit-ordninger.

Det betyder, at et TLPT-scenarie ikke kan stoppe ved organisationens firewall, hvis den kritiske funktion afhænger af en leverandør.

Clarysecs Politik for tredjeparts- og leverandørsikkerhed-SMV Politik for tredjeparts- og leverandørsikkerhed - SMV, fra afsnittet “Krav til implementering af politikken”, clause 6.3.1, fastslår:

Kritiske leverandører eller højrisikoleverandører skal gennemgås mindst én gang årligt. Gennemgangen skal verificere:

Politik for sikkerhedstest og red teaming tilføjer et testspecifikt leverandørkrav i clause 6.9:

Koordinering af tredjepartstest: Hvor en kritisk leverandør eller tjenesteudbyder falder inden for omfanget af organisationens samlede sikkerhed, skal organisationen, i overensstemmelse med Politik for tredjeparts- og leverandørsikkerhed, hvor det er muligt indhente assurance vedrørende leverandørens praksis for sikkerhedstest eller koordinere fælles test. Hvis der for eksempel anvendes en Cloud Service Provider (CSP), kan organisationen basere sig på dennes rapporter fra penetrationstest eller medtage den i samarbejdsbaserede red team-scenarier, forudsat at kontraktbestemmelserne tillader det.

For revisionsklart DORA-bevismateriale bør leverandørdokumentation knyttes til det samme risikoscenarie som TLPT’en. Hvis identitetsudbyderen er afgørende for genopretning af betalinger, bør bevispakken omfatte leverandør-due diligence, kontraktlige sikkerhedskrav, vilkår for hændelsesunderstøttelse, testkoordinering, assurancerapporter, bevismateriale for serviceniveau, exitstrategi og begrænsninger for test.

NIS2 Article 21 er også relevant for SaaS-, cloud-, managed service-, managed security-, datacenter-, CDN-, tillidstjeneste-, DNS-, TLD-, online markedsplads-, søge- og sociale netværksudbydere. Den kræver en all hazards-tilgang, der omfatter risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, effektivitetsvurdering, træning, kryptografi, adgangsstyring, styring af aktiver, MFA og sikker kommunikation.

Det praktiske resultat er enkelt: Finansielle enheder bør opbygge én bevismodel, der først opfylder DORA, og derefter krydshenviser NIS2-forventninger, hvor leverandører, koncernenheder eller ikke-finansielle digitale tjenester er involveret.

En praktisk Clarysec TLPT-bevislog

Antag, at scenariet er:

“En trusselsaktør kompromitterer en administratorkonto hos en SaaS-supportplatform, pivoterer ind i betalingsdriftsmiljøet, ændrer konfiguration og forstyrrer transaktionsbehandlingen.”

Opret en bevislog med én række pr. bevisobjekt. Vent ikke, til testen er afsluttet. Udfyld den under planlægning, gennemførelse, afhjælpning og lukning.

Brug derefter Zenith Blueprint Step 13 til at tilføje sporbarhed i risikoregisteret og Anvendelseserklæringen. Hvert bevispunkt bør forbindes med et risikoscenarie, en risikoejer, en valgt kontrol, en behandlingsplan og en beslutning om restrisiko.

Hvis en konstatering vedrører en softwaresvaghed, skal kontroller for sikker udvikling og test citeres. Clarysecs Politik for sikker udvikling-SMV Politik for sikker udvikling - SMV, fra afsnittet “Krav til implementering af politikken”, clause 6.5.2, kræver:

Test skal dokumenteres med:

Hvis en konstatering frembringer forensisk materiale, skal chain of custody bevares. Clarysecs Politik for indsamling af bevismateriale og digital efterforskning-SMV Politik for indsamling af bevismateriale og digital efterforskning - SMV, fra afsnittet “Governance-krav”, clause 5.2.1, fastslår:

Hvert element af digitale beviser skal logges med:

Det er det punkt, mange teams overser. Bevismateriale er ikke kun slutrapporter. Det er den kontrollerede registrering af, hvem der godkendte, hvem der gennemførte, hvad der skete, hvad der blev detekteret, hvad der blev genoprettet, hvad der blev ændret, hvad der fortsat er eksponeret, og hvem der accepterede denne eksponering.

Hvordan revisorer vurderer det samme TLPT-bevismateriale

DORA TLPT-bevismateriale læses forskelligt afhængigt af revisors baggrund. Clarysec designer bevispakker, så hvert perspektiv kan finde det, det skal bruge, uden at teams skal duplikere arbejde.

COBIT 2019 indgår i Zenith Blueprint-referencen for krydsoverholdelse ved sikker audit og testgennemførelse, herunder DSS05.03 og MEA03.04. Relevansen er ikke, at COBIT erstatter DORA eller ISO 27001, men at assurance-professionelle med ISACA-baggrund vil se efter kontrolleret gennemførelse, overvågning, evaluering og bevismateriale for efterlevelse.

Bestyrelsesfortællingen: hvad ledelsen skal godkende

Rapportering til bestyrelsen bør undgå teknisk teater. Bestyrelsen har ikke brug for exploit-payloads. Den har brug for beslutningsegnet bevismateriale:

• Hvilken kritisk eller vigtig funktion blev testet?
• Hvilket trusselsscenarie blev simuleret, og hvorfor?
• Fungerede detektionen?
• Fungerede eskaleringen af respons?
• Opfyldte genopretningen RTO og RPO?
• Hvilke leverandører var involveret eller begrænsende?
• Hvilke væsentlige svagheder består?
• Hvad er afhjælpningsomkostningen, ejeren og tidsplanen?
• Hvilke restrisici kræver formel accept?
• Hvad skal gentestes?

Det er her, ISO 27001 Clause 5 bliver vigtig. Øverste ledelse skal sikre, at informationssikkerhedspolitikken og målene er etableret, afstemt med den strategiske retning, integreret i forretningsprocesser, tilført ressourcer, kommunikeret og løbende forbedret. Roller og ansvar skal tildeles. Mål skal, hvor det er praktisk muligt, være målbare og tage højde for gældende krav og resultater af risikobehandling.

Hvis TLPT identificerer, at genopretningstiden er seks timer mod en forretningstolerance på fire timer, er det ikke blot et punkt i infrastrukturteamets backlog. Det er en ledelsesbeslutning, der involverer risikovillighed, budget, kundeforpligtelser, regulatorisk eksponering, kontrakter, arkitektur og operationel kapacitet.

Almindelige bevisfejl i DORA-robusthedstest

Clarysec-gennemgange finder ofte de samme bevishuller hos finansielle enheder og IKT-tjenesteudbydere, der forbereder sig på DORA.

For det første kortlægges TLPT-omfanget ikke til kritiske eller vigtige funktioner. Testen kan være teknisk imponerende, men den dokumenterer ikke robustheden af den forretningsproces, som tilsynsmyndighederne fokuserer på.

For det andet anerkendes leverandørafhængigheder, men de dokumenteres ikke. Teams siger, at cloududbyderen, det managed SOC eller SaaS-platformen er i scope, men kontrakter, revisionsrettigheder, testtilladelser, vilkår for hændelsesunderstøttelse og exitplaner mangler.

For det tredje skaber test bevismateriale, men ikke behandling. Konstateringer forbliver i en red team-rapport i stedet for at blive omsat til opdateringer i risikoregisteret, kontrolændringer, ejere, datoer, gentest og beslutninger om restrisiko.

For det fjerde antages genopretning i stedet for at blive dokumenteret. Backuppolitikker findes, men ingen kan vise failover-tidsstempler, integritetskontroller af gendannelse, adgangsvalidering eller bekræftelse fra forretningsejer.

For det femte er databeskyttelses- og forensisk bevismateriale ukontrolleret. Logfiler og skærmbilleder indeholder personoplysninger, testartefakter lagres på fællesdrev, midlertidige konti forbliver aktive, og chain of custody for bevismateriale er ufuldstændig.

For det sjette er ledelsesrapporteringen for teknisk. Øverste ledelse kan ikke se, om robustheden er forbedret, om risikoen er inden for risikovilligheden, eller hvilke investeringsbeslutninger der kræves.

Hvert af disse huller kan lukkes ved at behandle DORA TLPT som en struktureret ISO 27001-arbejdsgang for bevismateriale.

Clarysecs integrerede tilgang til revisionsklar robusthed

Clarysecs tilgang kombinerer tre lag.

Det første lag er Zenith Blueprint 30-trins implementeringskøreplanen. For dette emne opbygger Step 13 sporbarhed for risikobehandling og SoA, Step 21 beskytter systemer under audit- og testaktiviteter, og Step 23 validerer IKT-parathed til forretningskontinuitet. Disse trin omsætter TLPT fra en teknisk hændelse til en dokumenteret governance-cyklus.

Det andet lag er Clarysecs politikbibliotek. Politik for sikkerhedstest og red teaming definerer testtyper, omfang, spilleregler, afhjælpning, rapportering og leverandørkoordinering. Politik for forretningskontinuitet og katastrofeberedskab-SMV fastsætter forventninger til årlig BCP- og DR-test og revisionsklart kontinuitetsbevismateriale. Politik for tredjeparts- og leverandørsikkerhed-SMV understøtter leverandørdokumentation. Politik for sikker udvikling-SMV sikrer, at sikkerhedstest dokumenteres. Politik for indsamling af bevismateriale og digital efterforskning-SMV understøtter logning af bevismateriale og disciplin omkring chain of custody.

Det tredje lag er Zenith Controls, Clarysecs vejledning til krydsoverholdelse. Den hjælper med at kortlægge ISO/IEC 27002:2022-kontroller til attributter, domæner, operationelle kapabiliteter og forventninger på tværs af rammeværker. For DORA TLPT er det vigtigste mønster ikke én kontrol. Det er relationen mellem test, kontinuitet, hændelsesstyring, leverandørstyring, logning, overvågning, sikker udvikling, uafhængig gennemgang og governance.

Når disse lag fungerer sammen, ændres informationssikkerhedschefens mandagsproblem. I stedet for tre usammenhængende spørgsmål fra bestyrelsen, tilsynsmyndigheden og intern audit har organisationen én bevisfortælling:

“Vi identificerede den kritiske funktion. Vi vurderede IKT-risikoen. Vi valgte og begrundede kontroller. Vi godkendte og gennemførte TLPT sikkert. Vi detekterede, reagerede og genoprettede. Vi involverede leverandører, hvor det var påkrævet. Vi dokumenterede bevismateriale. Vi afhjælpede konstateringer. Vi gentestede. Ledelsen gennemgik og accepterede den resterende risiko.”

Det er revisionsklar robusthed.

Næste skridt

Hvis jeres DORA TLPT-program stadig er organiseret omkring rapporter i stedet for beviskæder, så start med en Clarysec-gennemgang af bevismateriale.

Brug Zenith Blueprint Zenith Blueprint Step 13 til at forbinde TLPT-scenarier med risici, kontroller og Anvendelseserklæringen. Brug Step 21 til at verificere sikker godkendelse, spilleregler, tilbagerulning, overvågning og oprydning. Brug Step 23 til at dokumentere IKT-parathed til forretningskontinuitet med genopretningsbevismateriale.

Tilpas derefter jeres driftsdokumenter til Clarysecs Politik for sikkerhedstest og red teaming Politik for sikkerhedstest og red teaming, Politik for forretningskontinuitet og katastrofeberedskab-SMV Politik for forretningskontinuitet og katastrofeberedskab - SMV, Politik for tredjeparts- og leverandørsikkerhed-SMV Politik for tredjeparts- og leverandørsikkerhed - SMV, Politik for sikker udvikling-SMV Politik for sikker udvikling - SMV og Politik for indsamling af bevismateriale og digital efterforskning-SMV Politik for indsamling af bevismateriale og digital efterforskning - SMV.

Brug til sidst Zenith Controls Zenith Controls til at krydskortlægge jeres DORA TLPT-bevismateriale til ISO 27001-kontroller, NIS2, GDPR, COBIT 2019 og revisorforventninger.

Hvis jeres næste robusthedstest skal producere mere end konstateringer, kan I bruge Clarysec til at omsætte den til en forsvarlig beviskæde. Download værktøjspakkerne, planlæg en vurdering af bevisberedskab, eller anmod om en gennemgang af, hvordan Clarysec kortlægger DORA TLPT til ISO 27001:2022-kontroller fra planlægning til bestyrelsesgodkendelse.