Důkazy k DORA TLPT mapované na opatření ISO 27001

Je pondělí 07:40 ráno a CISO středně velké platební instituce sleduje tři podoby téže nepříjemné otázky.

Vedoucí orgán chce vědět, zda organizace přežije výpadek zákaznického platebního portálu způsobený ransomwarem. Orgán dohledu chce důkaz, že testování digitální provozní odolnosti není pouze cvičení v PowerPointu. Interní audit chce čistou stopu od povinností DORA přes rizika v oblasti ICT, opatření ISO 27001, výsledky testů, plány nápravných opatření, důkazy od dodavatelů až po schválení vedením.

CISO má zprávu red teamu. SOC má snímky obrazovek s upozorněními. Infrastrukturní tým má záznam obnovy ze zálohy. Právní oddělení má přehled připravenosti na DORA. Nákup má atestaci poskytovatele cloudových služeb.

Nic z toho není propojeno.

Právě zde selhává mnoho programů DORA TLPT a testování odolnosti. Ne proto, že by testování bylo slabé, ale proto, že důkazy jsou roztříštěné. Když se auditor zeptá: „Ukažte mi, jak tento test prokazuje odolnost kritické nebo důležité funkce,“ odpovědí nemůže být složka plná snímků obrazovky. Musí jít o obhajitelný důkazní řetězec.

Právě v tomto řetězci se ukazuje síla ISMS sladěného s ISO/IEC 27001:2022. ISO 27001 dává strukturu rozsahu, posouzení rizik, výběru opatření, Prohlášení o použitelnosti, provoznímu řízení, internímu auditu, přezkoumání vedením a neustálému zlepšování. DORA dodává odvětvový tlak. Metodika Clarysec a nástroje pro křížové zajištění souladu propojují obojí do jednotného důkazního modelu připraveného k auditu.

DORA TLPT je test správy a řízení, nejen simulace útoku

Penetrační testování řízené hrozbami, tedy TLPT, lze snadno pochopit nesprávně. Technicky může vypadat jako sofistikované cvičení red teamu: informace o hrozbách, realistické cesty útoku, skrytý postup, pokusy o exploitaci, scénáře laterálního pohybu a ověření reakce blue teamu.

U DORA je však hlubším tématem digitální provozní odolnost. Dokáže finanční subjekt odolat závažnému narušení ICT, které ovlivňuje obchodní procesy, reagovat na něj a obnovit se po něm? Dokáže prokázat, že kritické nebo důležité funkce zůstávají v mezích tolerovaného dopadu? Dokáže vedení doložit, že riziko v oblasti ICT je řízeno, financováno, testováno, napravováno a průběžně zlepšováno?

DORA Article 1 zavádí jednotný rámec EU pro bezpečnost sítí a informačních systémů podporujících obchodní procesy finančních subjektů. Pokrývá řízení rizik v oblasti ICT, hlášení významných incidentů souvisejících s ICT, testování digitální provozní odolnosti, řízení rizik třetích stran v oblasti ICT, povinné smluvní požadavky na dodavatele ICT, dohled nad kritickými poskytovateli služeb ICT z řad třetích stran a spolupráci orgánů dohledu. DORA se použije od 17. ledna 2025.

Pro organizace, na které se vztahuje také NIS2, působí DORA jako odvětvový právní akt Unie pro překrývající se požadavky kybernetické bezpečnosti. V praxi by finanční subjekty měly upřednostnit DORA pro řízení rizik v oblasti ICT, hlášení incidentů, testování a rizika třetích stran v oblasti ICT tam, kde se režimy překrývají, a zároveň rozumět očekáváním NIS2 pro skupinové struktury, dodavatele a nefinanční digitální služby.

DORA také klade odpovědnost na nejvyšší úroveň. DORA Article 5 vyžaduje, aby vedoucí orgán definoval a schválil rámec řízení rizik ICT, dohlížel na něj a zajišťoval jeho uplatňování. To zahrnuje strategii digitální provozní odolnosti, politiku kontinuity činností ICT, plány reakce a obnovy, plány auditů, rozpočty, politiky pro třetí strany v oblasti ICT, kanály pro hlášení a dostatečné znalosti rizik ICT prostřednictvím pravidelného školení.

Auditní otázka tedy nezní pouze: „Provedli jste TLPT?“

Zní takto:

• Bylo TLPT navázáno na kritické nebo důležité funkce?
• Bylo autorizováno, vymezeno, bezpečné a posouzené z hlediska rizik?
• Byli zahrnuti dodavatelé, cloudové závislosti a outsourcované služby ICT tam, kde to bylo relevantní?
• Vytvořil test důkazy o detekci, reakci, obnově a získaných poznatcích?
• Byla zjištění převedena do ošetření rizik, sledovaných nápravných opatření, opakovaného testování a reportingu vedení?
• Vysvětlilo Prohlášení o použitelnosti, která opatření přílohy A ISO 27001 byla vybrána pro řízení rizika?

Proto Clarysec považuje důkazy k DORA TLPT za problém důkazů v ISMS, nikoli pouze za výstup penetračního testování.

Vybudujte důkazní páteř ISO 27001 před zahájením testu

ISO 27001 vyžaduje, aby organizace zavedla, implementovala, udržovala a neustále zlepšovala ISMS, který chrání důvěrnost, integritu a dostupnost prostřednictvím procesu řízení rizik. Kapitoly 4.1 až 4.4 vyžadují, aby organizace porozuměla interním a externím aspektům, zainteresovaným stranám, právním a regulačním povinnostem, rozhraním a závislostem a následně dokumentovala rozsah ISMS.

U subjektu regulovaného DORA by tento krok vymezení rozsahu měl výslovně zachytit kritické nebo důležité funkce, aktiva ICT, cloudové platformy, outsourcovaný provoz, platební systémy, zákaznické portály, služby identit, platformy protokolování, prostředí pro obnovu a poskytovatele služeb ICT z řad třetích stran. Pokud se rozsah TLPT nemapuje zpět na rozsah ISMS, auditní stopa je slabá už na začátku.

Kapitoly ISO 27001 6.1.1, 6.1.2 a 6.1.3 spolu s kapitolami 8.2 a 8.3 vyžadují proces posouzení rizik a ošetření rizik. Rizika musí být identifikována vůči důvěrnosti, integritě a dostupnosti. Musí být přiřazeni vlastníci rizik. Musí být posouzena pravděpodobnost a dopad. Opatření musí být vybrána a porovnána s přílohou A. Zbytkové riziko musí být přijato vlastníky rizik.

To je most mezi DORA a testováním připraveným k auditu.

Clarysec Zenith Blueprint: 30kroková mapa auditora Zenith Blueprint ve fázi řízení rizik, kroku 13, popisuje tuto roli dohledatelnosti jasně:

SoA je fakticky přemosťující dokument: propojuje vaše posouzení/ošetření rizik se skutečnými kontrolami, které máte zavedené. Jeho vyplněním zároveň znovu ověříte, zda vám nechybí nějaké kontroly.

Pro DORA TLPT by Prohlášení o použitelnosti nemělo být statickým certifikačním artefaktem. Mělo by vysvětlit, proč jsou pro scénář odolnosti použitelná opatření, jako je bezpečnost dodavatelů, řízení incidentů, připravenost ICT pro kontinuitu činností, protokolování, monitorování, technické řízení zranitelností, zálohování, bezpečný vývoj a bezpečnostní testování.

Praktický rizikový scénář může znít:

„Kompromitace privilegovaných přihlašovacích údajů poskytovatele identit umožní útočníkovi přístup do administrátorských systémů zpracování plateb, změnu směrovacích konfigurací a narušení kritické platební funkce, což způsobí výpadek služby, regulační oznamovací povinnosti, újmu zákazníkům a poškození dobré pověsti.“

Tento jediný scénář může řídit rozsah TLPT, detekční případ užití, zapojení dodavatelů, cvičení obnovy, reporting vedoucímu orgánu i soubor důkazů.

Zenith Blueprint také doporučuje výslovně zachytit regulační dohledatelnost:

Křížově odkazujte právní předpisy: Pokud jsou určité kontroly implementovány konkrétně za účelem splnění GDPR, NIS2 nebo DORA, můžete to uvést buď v Registru rizik (jako součást odůvodnění dopadu rizika), nebo v poznámkách SoA.

Tato rada je jednoduchá, ale mění auditní rozhovor. Namísto tvrzení auditorovi, že DORA byla zohledněna, může organizace ukázat, kde se DORA objevuje v registru rizik, SoA, programu testování, sadě politik a přezkoumání vedením.

Mapujte testování DORA na opatření ISO 27001, která auditoři znají

DORA Article 6 očekává dokumentovaný rámec řízení rizik ICT integrovaný do celkového řízení rizik. Příloha A ISO 27001 poskytuje katalog opatření, který z toho dělá provozně uchopitelný rámec.

Pro DORA TLPT a testování odolnosti jsou zvlášť důležitá tato opatření přílohy A ISO/IEC 27001:2022:

Clarysec Zenith Controls: Průvodce křížovým souladem Zenith Controls pomáhá organizacím vyhnout se tomu, aby s těmito opatřeními zacházely jako s izolovanými položkami kontrolního seznamu. Mapuje opatření ISO/IEC 27002:2022 na atributy, domény, provozní schopnosti, auditní očekávání a vzory napříč rámci.

Například Zenith Controls klasifikuje opatření ISO/IEC 27002:2022 5.30, připravenost ICT pro kontinuitu činností, jako „nápravné“, sladěné s „dostupností“, spojené s konceptem kybernetické bezpečnosti „reagovat“ a zařazené do domény „odolnost“. Tato klasifikace je užitečná při vysvětlování auditorům, proč cvičení obnovy není jen provozní činnost IT, ale opatření odolnosti s definovanou rolí v kontrolním prostředí.

Zenith Controls také klasifikuje opatření 8.29, bezpečnostní testování ve vývoji a akceptaci, jako preventivní opatření podporující důvěrnost, integritu a dostupnost, s provozními schopnostmi v oblasti zabezpečení aplikací, zajištění informační bezpečnosti a zabezpečení systémů a sítí. U zjištění TLPT, která se vztahují ke slabině návrhu aplikace, nezabezpečenému chování API, slabému toku autentizace nebo nedostatečnému ověření vstupů, je toto cesta od zjištění k řízení bezpečného vývoje.

Důležité je také opatření 5.35, nezávislý přezkum bezpečnosti informací. Podporuje nezávislé oponentní posouzení, ujištění v oblasti správy a řízení a nápravné zlepšování. Interní týmy mohou testování koordinovat, ale důkazy připravené k auditu vyžadují přezkum, eskalaci a dohled nad rámec osob, které testované systémy vybudovaly nebo provozovaly.

Chraňte systém během jeho testování

Nebezpečným předpokladem při testování odolnosti je, že testování je automaticky přínosné. Ve skutečnosti může invazivní testování způsobit výpadky, zpřístupnit citlivá data, znečistit logy, spustit automatizované obranné mechanismy, přerušit zákaznické relace nebo přimět dodavatele k aktivaci nouzových postupů.

Clarysec Politika bezpečnostního testování a red teamingu Politika bezpečnostního testování a red teamingu poskytuje organizacím vzor správy a řízení pro bezpečné provedení. Kapitola 6.1 stanoví:

Typy testů: Program bezpečnostního testování musí zahrnovat minimálně: (a) skenování zranitelností, spočívající v automatizovaných týdenních nebo měsíčních skenech sítí a aplikací za účelem identifikace známých zranitelností; (b) penetrační testování, spočívající v manuálním hloubkovém testování konkrétních systémů nebo aplikací kvalifikovanými testery za účelem identifikace komplexních slabin; a (c) cvičení red teamu, spočívající ve scénářových simulacích skutečných útoků, včetně sociálního inženýrství a dalších taktik, za účelem otestování detekčních a reakčních schopností organizace jako celku.

U TLPT je prvek red teamingu zřejmý, ale auditní hodnota vychází z návrhu programu. Skenování zranitelností, penetrační testování, cvičení red teamu, cvičení odolnosti a opakované testování musí tvořit cyklus, nikoli soubor nepropojených testů.

Kapitola 6.2 téže politiky řeší bezpečné provedení:

Rozsah a pravidla zapojení: Pro každý test nebo cvičení musí STC definovat rozsah, včetně systémů a rozsahů IP adres v rozsahu testu, povolených testovacích metod, cílů, načasování a doby trvání. Pravidla zapojení musí být dokumentována. Například provozně citlivé systémy mohou být označeny pouze pro monitorování, aby se předešlo narušení, a jakékoli testování v produkčním prostředí musí zahrnovat postupy návratu do původního stavu a zastavení. Musí být zavedena bezpečnostní opatření, jako jsou definovaná časová okna a komunikační kanály, aby se předešlo neúmyslným výpadkům služeb.

To přímo odpovídá Zenith Blueprint, fázi Controls in Action, kroku 21, který se zaměřuje na opatření přílohy A ISO 27001 8.34, ochranu informačních systémů během auditního testování. Zenith Blueprint upozorňuje, že audity, penetrační testy, forenzní přezkumy a provozní hodnocení mohou zahrnovat zvýšený přístup, invazivní nástroje nebo dočasné změny chování systému. Zdůrazňuje autorizaci, rozsah, časová okna, schválení vlastníkem systému, návrat do původního stavu, monitorování a bezpečné nakládání s testovacími daty.

Balíček důkazů připravený k auditu by měl obsahovat:

• zadání a cíle TLPT,
• shrnutí informací o hrozbách a odůvodnění scénáře,
• kritické nebo důležité funkce v rozsahu,
• systémy, rozsahy IP adres, identity, dodavatele a prostředí v rozsahu,
• výjimky a systémy pouze pro monitorování,
• pravidla zapojení,
• posouzení rizik produkčního testování,
• postupy návratu do původního stavu a zastavení,
• model informování SOC, včetně toho, co je zpřístupněno a co je zadrženo,
• schválení právního oddělení, ochrany soukromí a dodavatelů,
• důkazy o vytvoření a revokaci testovacích účtů,
• bezpečné úložiště testovacích artefaktů a logů.

DORA TLPT, které nedokáže ukázat bezpečnou autorizaci a řízení testovací činnosti, může odhalit mezery v odolnosti, ale zároveň vytváří mezery ve správě a řízení.

Převádějte výstupy TLPT do ošetření rizik

Nejčastějším selháním po testu je problém zprávy red teamu založené do šuplíku. Kvalitní zpráva je dodána, rozeslána, projednána a poté postupně ztrácí hybnost. Zjištění zůstávají otevřená. Kompenzační opatření nejsou dokumentována. Přijatá rizika jsou neformální. Opakované testování se nikdy neuskuteční.

Politika bezpečnostního testování a red teamingu to považuje za nepřijatelné. Kapitola 6.6 stanoví:

Náprava zjištění: Všechny identifikované zranitelnosti nebo slabiny musí být dokumentovány ve zprávě o zjištěních s hodnocením závažnosti. Po obdržení zprávy jsou vlastníci systémů odpovědní za vytvoření plánu nápravných opatření s termíny splnění; například kritická zjištění musí být napravena do 30 dnů a zjištění s vysokou závažností do 60 dnů, v souladu s Politikou řízení zranitelností a záplat organizace. STC musí sledovat postup nápravných opatření. Musí být provedeno opakované testování, aby se potvrdilo, že kritické problémy byly vyřešeny nebo odpovídajícím způsobem zmírněny.

Kapitola 6.7 doplňuje vrstvu správy a řízení:

Reporting: Po ukončení každého testu musí být vydána formální zpráva. U penetračního testování musí zpráva obsahovat shrnutí pro vedení, metodiku a podrobná zjištění s podpůrnými důkazy a doporučeními. U cvičení red teamu musí zpráva podrobně popsat scénáře, které cesty útoku byly úspěšné, co detekoval Blue Team, a získané poznatky týkající se mezer v detekci a reakci. CISO musí předložit shrnuté výsledky a stav nápravných opatření vrcholovému vedení a tam, kde je to relevantní, zahrnout je do každoroční bezpečnostní zprávy pro správní radu.

To je v souladu s pokyny ISO/IEC 27005:2022 pro ošetření rizik: vybrat možnosti ošetření, určit opatření z přílohy A ISO 27001 a odvětvových požadavků, vytvořit plán ošetření rizik, přiřadit odpovědné osoby, definovat termíny, sledovat stav, získat schválení vlastníka rizika a dokumentovat přijetí zbytkového rizika.

Každé významné zjištění TLPT by se mělo stát jednou ze čtyř věcí: nápravným opatřením, zlepšením opatření, formálním přijetím rizika nebo požadavkem na opakované testování.

Cílem není vytvářet více dokumentů. Cílem je, aby každý dokument vysvětloval další rozhodnutí.

Testování odolnosti musí prokázat obnovu, nejen detekci

Úspěšné TLPT může ukázat, že SOC detekoval provoz command-and-control, zablokoval laterální pohyb a správně eskaloval. To je cenné, ale testování odolnosti podle DORA jde dál. Ptá se, zda organizace dokáže pokračovat v poskytování obchodních služeb nebo je obnovit.

Zenith Blueprint, fáze Controls in Action, krok 23, vysvětluje opatření 5.30, připravenost ICT pro kontinuitu činností, jazykem, který by měl každý CISO používat s vedoucím orgánem:

Z auditního hlediska je tato kontrola často testována jedinou větou: Ukažte mi to. Ukažte mi poslední výsledek testu. Ukažte mi dokumentaci obnovy. Ukažte mi, jak dlouho trvalo přepnutí na záložní řešení a zpět. Ukažte mi důkazy, že to, co bylo slíbeno, lze skutečně dodat.

Tento standard „ukažte mi to“ je rozdílem mezi vyspělostí politik a provozní odolností.

Clarysec Politika kontinuity činností a obnovy po havárii - SME Politika kontinuity činností a obnovy po havárii - SME, ze sekce „Požadavky na implementaci politiky“, kapitola 6.4.1, stanoví:

Organizace musí alespoň jednou ročně otestovat své schopnosti BCP i DR. Testy musí zahrnovat:

Sekce uplatňování téže politiky, kapitola 8.5.1, výslovně stanoví odpovědnost za důkazy:

GM musí zajistit, aby byly udržovány a připraveny na audit následující položky:

U finančního subjektu regulovaného DORA může být roční testování spíše minimem než cílem. Kritické nebo důležité funkce s vyšším rizikem by měly být testovány častěji, zejména po změnách architektury, migraci do cloudu, významných incidentech, nových dodavatelích ICT, významných vydáních aplikací nebo změnách expozice vůči hrozbám.

Silný balíček důkazů z testu odolnosti by měl obsahovat:

• analýzu dopadů na obchodní činnost mapující kritickou nebo důležitou funkci,
• RTO a RPO schválené vlastníky podnikových procesů,
• mapu závislostí systému, včetně identity, DNS, sítě, cloudu, databáze, monitorování, zálohování a služeb třetích stran,
• výsledky testů zálohování a obnovy,
• časová razítka přepnutí na záložní řešení a návratu zpět,
• důkazy o fungování bezpečnostních opatření během narušení,
• šablony komunikace se zákazníky, orgánem dohledu a interní komunikace,
• záznamy o účasti velitele incidentu a krizového týmu,
• získané poznatky a zlepšovací opatření,
• důkazy o opakovaném testování předchozích mezer v obnově.

Zde do příběhu vstupuje také GDPR. GDPR Articles 2 a 3 zahrnují do působnosti většinu zpracování osobních údajů EU v prostředích SaaS a fintech. GDPR Article 4 definuje osobní údaje, zpracování, správce, zpracovatele a porušení zabezpečení osobních údajů. GDPR Article 5 vyžaduje integritu, důvěrnost a odpovědnost, což znamená, že organizace musí být schopna doložit soulad. Pokud TLPT nebo testování obnovy používá produkční osobní údaje, kopíruje logy obsahující identifikátory nebo ověřuje reakci na porušení zabezpečení, musí být dokumentována opatření na ochranu soukromí.

Důkazy od dodavatelů jsou slepým místem DORA, které auditoři nepřehlédnou

Moderní finanční služby se skládají z cloudových platforem, SaaS aplikací, poskytovatelů řízených bezpečnostních služeb, zpracovatelů plateb, datových platforem, poskytovatelů identit, nástrojů observability, outsourcovaných vývojových týmů a poskytovatelů zálohování.

DORA Article 28 vyžaduje, aby finanční subjekty řídily rizika třetích stran v oblasti ICT jako součást rámce řízení rizik ICT a zůstaly plně odpovědné i tam, kde jsou služby ICT outsourcovány. DORA Article 30 vyžaduje písemné smlouvy o službách ICT s popisy služeb, podmínkami subdodávek, místy zpracování, ochranou údajů, přístupem a obnovou, úrovněmi služeb, podporou při incidentech, spoluprací s orgány, právy na ukončení, přísnějšími podmínkami pro kritické nebo důležité funkce, právy na audit, bezpečnostními opatřeními, účastí na TLPT tam, kde je relevantní, a ujednáními o ukončení spolupráce.

To znamená, že scénář TLPT se nemůže zastavit na firewallu organizace, pokud kritická funkce závisí na dodavateli.

Clarysec Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME, ze sekce „Požadavky na implementaci politiky“, kapitola 6.3.1, stanoví:

Kritičtí nebo vysoce rizikoví dodavatelé musí být přezkoumáni alespoň jednou ročně. Přezkum musí ověřit:

Politika bezpečnostního testování a red teamingu přidává v kapitole 6.9 požadavek na dodavatele specifický pro testování:

Koordinace testování s třetími stranami: Pokud jakýkoli kritický dodavatel nebo poskytovatel služeb spadá do rozsahu celkové bezpečnosti organizace, v souladu s Bezpečnostní politikou dodavatelů a poskytovatelů služeb třetích stran organizace podle možností získá ujištění o jeho postupech bezpečnostního testování nebo koordinuje společné testování. Například pokud je používán poskytovatel cloudových služeb (CSP), organizace se může spolehnout na jeho zprávy z penetračního testování nebo jej zahrnout do spolupracujících scénářů red teamu, a to podle smluvních ustanovení.

Pro důkazy DORA připravené k auditu by ujištění dodavatelů mělo být navázáno na stejný rizikový scénář jako TLPT. Pokud je poskytovatel identit nezbytný pro obnovu plateb, měl by balíček důkazů obsahovat prověrku dodavatele, smluvní bezpečnostní požadavky, podmínky podpory při incidentech, koordinaci testování, zprávy o ujištění, důkazy o úrovni služeb, výstupní strategii a omezení testování.

NIS2 Article 21 je důležitý také pro poskytovatele SaaS, cloudu, řízených služeb, řízené bezpečnosti, datových center, CDN, služeb vytvářejících důvěru, DNS, TLD, online tržišť, vyhledávání a sociálních sítí. Vyžaduje přístup založený na všech hrozbách zahrnující analýzu rizik, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečný vývoj, posouzení účinnosti, školení, kryptografii, řízení přístupu, správu aktiv, MFA a bezpečnou komunikaci.

Praktický závěr je jednoduchý: finanční subjekty by měly vybudovat jeden důkazní model, který nejprve splní DORA, a následně křížově odkazovat očekávání NIS2 tam, kde jsou zapojeni dodavatelé, skupinové subjekty nebo nefinanční digitální služby.

Praktická evidence důkazů Clarysec pro TLPT

Předpokládejme tento scénář:

„Aktér hrozby kompromituje administrátorský účet na SaaS platformě podpory, přesune se do prostředí platebního provozu, upraví konfiguraci a naruší zpracování transakcí.“

Vytvořte evidenci důkazů s jedním řádkem pro každý důkazní objekt. Nečekejte, až test skončí. Plňte ji během plánování, provádění, nápravy a uzavření.

Poté použijte Zenith Blueprint krok 13 k doplnění dohledatelnosti do registru rizik a Prohlášení o použitelnosti. Každá položka důkazů by se měla propojit s rizikovým scénářem, vlastníkem rizika, vybraným opatřením, plánem ošetření a rozhodnutím o zbytkovém riziku.

Pokud se zjištění týká slabiny softwaru, uveďte opatření bezpečného vývoje a testování. Clarysec Politika bezpečného vývoje - SME Politika bezpečného vývoje - SME, ze sekce „Požadavky na implementaci politiky“, kapitola 6.5.2, vyžaduje:

Testování musí být dokumentováno včetně:

Pokud zjištění vytváří forenzní materiál, zachovejte řetězec předávání a kontroly důkazů. Clarysec Politika sběru důkazů a forenzního šetření - SME Politika sběru důkazů a forenzního šetření - SME, ze sekce „Požadavky na správu a řízení“, kapitola 5.2.1, stanoví:

Každá položka digitálního důkazu musí být zaevidována s:

Právě toto mnoho týmů přehlíží. Důkazy nejsou jen závěrečné zprávy. Jsou řízeným záznamem o tom, kdo schválil, kdo provedl, co se stalo, co bylo detekováno, co bylo obnoveno, co bylo změněno, co zůstává exponováno a kdo tuto expozici přijal.

Jak auditoři kontrolují stejné důkazy TLPT

Důkazy k DORA TLPT budou čteny různě podle odborného zázemí auditora. Clarysec navrhuje balíčky důkazů tak, aby každá perspektiva našla to, co potřebuje, aniž by týmy musely práci duplikovat.

COBIT 2019 se objevuje v křížové referenci souladu v Zenith Blueprint pro bezpečné provádění auditu a testování, včetně DSS05.03 a MEA03.04. Podstatné není, že by COBIT nahrazoval DORA nebo ISO 27001, ale že odborníci na ujištění ve stylu ISACA budou hledat řízené provedení, monitorování, hodnocení a důkazy o souladu.

Příběh pro vedoucí orgán: co musí vedení schválit

Reporting vedoucímu orgánu by se měl vyhnout technickému divadlu. Vedoucí orgán nepotřebuje exploit payloady. Potřebuje důkazy vhodné pro rozhodování:

• Která kritická nebo důležitá funkce byla testována?
• Jaký scénář hrozby byl simulován a proč?
• Fungovala detekce?
• Fungovala eskalace reakce?
• Splnila obnova RTO a RPO?
• Kteří dodavatelé byli zapojeni nebo představovali omezení?
• Jaké významné slabiny přetrvávají?
• Jaké jsou náklady nápravy, vlastník a harmonogram?
• Která zbytková rizika vyžadují formální přijetí?
• Co bude opakovaně testováno?

Zde se stává důležitou kapitola ISO 27001 5. Vrcholové vedení musí zajistit, aby politika bezpečnosti informací a cíle byly stanoveny, sladěny se strategickým směrem, integrovány do obchodních procesů, vybaveny zdroji, komunikovány a neustále zlepšovány. Role a odpovědnosti musí být přiřazeny. Cíle musí být tam, kde je to prakticky proveditelné, měřitelné a musí zohledňovat použitelné požadavky a výsledky ošetření rizik.

Pokud TLPT zjistí, že doba obnovy je šest hodin oproti čtyřhodinové toleranci podnikového procesu, nejde pouze o položku backlogu infrastruktury. Jde o rozhodnutí vedení zahrnující ochotu podstupovat riziko, rozpočet, závazky vůči zákazníkům, regulační expozici, smlouvy, architekturu a provozní kapacitu.

Běžná selhání důkazů při testování odolnosti podle DORA

Přezkumy Clarysec často nacházejí stejné mezery v důkazech u finančních subjektů a poskytovatelů služeb ICT připravujících se na DORA.

Zaprvé, rozsah TLPT se nemapuje na kritické nebo důležité funkce. Test může být technicky působivý, ale neprokazuje odolnost obchodního procesu, který zajímá orgány dohledu.

Zadruhé, závislosti na dodavatelích jsou uznány, ale nejsou doloženy. Týmy tvrdí, že poskytovatel cloudových služeb, řízené SOC nebo SaaS platforma jsou v rozsahu, ale chybí smlouvy, práva na audit, povolení k testování, podmínky podpory při incidentech a výstupní plány.

Zatřetí, testování vytváří důkazy, ale nikoli ošetření. Zjištění zůstávají ve zprávě red teamu namísto toho, aby byla převedena do aktualizací registru rizik, změn opatření, vlastníků, termínů, opakovaného testování a rozhodnutí o zbytkovém riziku.

Začtvrté, obnova se předpokládá, ale neprokazuje. Politiky zálohování existují, ale nikdo neumí ukázat časová razítka přepnutí na záložní řešení, kontroly integrity obnovy, ověření přístupu nebo potvrzení vlastníkem podnikového procesu.

Zapáté, ochrana soukromí a forenzní důkazy nejsou řízeny. Logy a snímky obrazovek obsahují osobní údaje, testovací artefakty jsou uloženy na sdílených discích, dočasné účty zůstávají aktivní a řetězec předávání a kontroly důkazů je neúplný.

Zašesté, reporting vedení je příliš technický. Vrcholové vedení nevidí, zda se odolnost zlepšila, zda je riziko v mezích ochoty podstupovat riziko nebo jaká investiční rozhodnutí jsou potřebná.

Každou z těchto mezer lze vyřešit tím, že se DORA TLPT uchopí jako strukturovaný důkazní pracovní postup ISO 27001.

Integrovaný přístup Clarysec k odolnosti připravené k auditu

Přístup Clarysec kombinuje tři vrstvy.

První vrstvou je 30kroková implementační roadmapa Zenith Blueprint. Pro toto téma krok 13 buduje dohledatelnost ošetření rizik a SoA, krok 21 chrání systémy během auditního testování a krok 23 ověřuje připravenost ICT pro kontinuitu činností. Tyto kroky mění TLPT z technické události na dokumentovaný cyklus správy a řízení.

Druhou vrstvou je knihovna politik Clarysec. Politika bezpečnostního testování a red teamingu definuje typy testování, rozsah, pravidla zapojení, nápravu, reporting a koordinaci s dodavateli. Politika kontinuity činností a obnovy po havárii - SME stanoví očekávání pro každoroční testování BCP a DR a důkazy kontinuity připravené k auditu. Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME podporuje ujištění dodavatelů. Politika bezpečného vývoje - SME zajišťuje dokumentaci bezpečnostního testování. Politika sběru důkazů a forenzního šetření - SME podporuje protokolování důkazů a disciplínu řetězce předávání a kontroly důkazů.

Třetí vrstvou je Zenith Controls, průvodce křížovým souladem Clarysec. Pomáhá mapovat opatření ISO/IEC 27002:2022 na atributy, domény, provozní schopnosti a očekávání napříč rámci. U DORA TLPT není nejdůležitějším vzorem jedno opatření. Je to vztah mezi testováním, kontinuitou, řízením incidentů, řízením dodavatelů, protokolováním, monitorováním, bezpečným vývojem, nezávislým přezkumem a správou a řízením.

Když tyto vrstvy fungují společně, pondělní ranní problém CISO se mění. Namísto tří nepropojených otázek od vedoucího orgánu, orgánu dohledu a interního auditu má organizace jeden důkazní příběh:

„Identifikovali jsme kritickou funkci. Posoudili jsme riziko ICT. Vybrali a odůvodnili jsme opatření. Autorizovali jsme a bezpečně provedli TLPT. Detekovali jsme, reagovali a obnovili jsme provoz. Zapojili jsme dodavatele tam, kde to bylo vyžadováno. Zdokumentovali jsme důkazy. Napravili jsme zjištění. Provedli jsme opakované testování. Vedení přezkoumalo a přijalo zbývající riziko.“

To je odolnost připravená k auditu.

Další kroky

Pokud je váš program DORA TLPT stále organizován kolem zpráv, nikoli důkazních řetězců, začněte kontrolním průchodem důkazy Clarysec.

Použijte Zenith Blueprint Zenith Blueprint krok 13 k propojení scénářů TLPT s riziky, opatřeními a Prohlášením o použitelnosti. Použijte krok 21 k ověření bezpečné autorizace, pravidel zapojení, návratu do původního stavu, monitorování a úklidu. Použijte krok 23 k prokázání připravenosti ICT pro kontinuitu činností pomocí důkazů obnovy.

Poté slaďte své provozní dokumenty s Clarysec Politikou bezpečnostního testování a red teamingu Politika bezpečnostního testování a red teamingu, Politikou kontinuity činností a obnovy po havárii - SME Politika kontinuity činností a obnovy po havárii - SME, Bezpečnostní politikou dodavatelů a poskytovatelů služeb třetích stran - SME Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME, Politikou bezpečného vývoje - SME Politika bezpečného vývoje - SME a Politikou sběru důkazů a forenzního šetření - SME Politika sběru důkazů a forenzního šetření - SME.

Nakonec použijte Zenith Controls Zenith Controls ke křížovému mapování důkazů k DORA TLPT na opatření ISO 27001, NIS2, GDPR, COBIT 2019 a očekávání auditorů.

Pokud chcete, aby váš další test odolnosti přinesl více než jen zjištění, použijte Clarysec k jeho přeměně na obhajitelný důkazní řetězec. Stáhněte si sady nástrojů, naplánujte posouzení připravenosti důkazů nebo si vyžádejte průchod tím, jak Clarysec mapuje DORA TLPT na opatření ISO 27001:2022 od plánování až po schválení vedoucím orgánem.