Dôkazná dokumentácia DORA TLPT mapovaná na opatrenia ISO 27001

Je pondelok 07:40 ráno a CISO stredne veľkej platobnej inštitúcie sa pozerá na tri verzie tej istej nepríjemnej otázky.

Predstavenstvo chce vedieť, či organizácia dokáže zvládnuť výpadok zákazníckeho platobného portálu spôsobený ransomvérom. Regulátor chce dôkaz, že testovanie digitálnej prevádzkovej odolnosti nie je len cvičenie v PowerPointe. Interný audit chce čistú stopu od povinností podľa DORA cez riziká IKT, opatrenia ISO 27001, výsledky testov, plány nápravy, dôkazy od dodávateľov až po schválenie manažmentom.

CISO má správu Red Teamu. SOC má snímky obrazovky upozornení. Tím infraštruktúry má log obnovy zo zálohy. Právne oddelenie má tracker pripravenosti na DORA. Obstarávanie má vyhlásenia cloudového poskytovateľa.

Nič z toho nie je prepojené.

Práve tu zlyháva mnoho programov DORA TLPT a testovania odolnosti. Nie preto, že by samotné testovanie bolo slabé, ale preto, že dôkazy sú fragmentované. Keď sa audítor opýta: „Ukážte mi, ako tento test preukazuje odolnosť kritickej alebo dôležitej funkcie,“ odpoveďou nemôže byť priečinok plný snímok obrazovky. Musí ísť o obhájiteľný dôkazový reťazec.

Práve v tomto reťazci sa ukazuje sila ISMS zosúladeného s ISO/IEC 27001:2022 ISO/IEC 27001:2022. ISO 27001 poskytuje štruktúru pre rozsah, posúdenie rizík, výber opatrení, Vyhlásenie o uplatniteľnosti, prevádzkové riadenie, interný audit, preskúmanie manažmentom a neustále zlepšovanie. DORA prináša odvetvovo špecifický tlak. Metodika Clarysec a nástroje na krížový súlad prepájajú oboje do jedného dôkazového modelu pripraveného na audit.

DORA TLPT je test správy a riadenia, nielen simulácia útoku

Penetračné testovanie vedené hrozbami, teda TLPT, sa dá ľahko nesprávne pochopiť. Technicky môže vyzerať ako sofistikované cvičenie Red Teamu: spravodajstvo o hrozbách, realistické cesty útoku, nenápadnosť, pokusy o zneužitie, scenáre laterálneho pohybu a validácia reakcie Blue Teamu.

V prípade DORA je hlbšou otázkou digitálna prevádzková odolnosť. Dokáže finančný subjekt odolať závažnému narušeniu IKT, reagovať naň a obnoviť činnosti ovplyvňujúce obchodné procesy? Vie preukázať, že kritické alebo dôležité funkcie zostávajú v rámci tolerancií dopadu? Vie manažment doložiť, že riziká IKT sú riadené, financované, testované, napravované a priebežne zlepšované?

DORA Article 1 zavádza jednotný rámec EÚ pre bezpečnosť sietí a informačných systémov podporujúcich obchodné procesy finančných subjektov. Zahŕňa riadenie rizík IKT, nahlasovanie významných incidentov súvisiacich s IKT, testovanie digitálnej prevádzkovej odolnosti, riadenie rizík tretích strán v oblasti IKT, povinné zmluvné požiadavky na dodávateľov IKT, dohľad nad kritickými externými poskytovateľmi IKT a spoluprácu orgánov dohľadu. DORA sa uplatňuje od 17. januára 2025.

Pre organizácie, na ktoré sa vzťahuje aj NIS2, DORA pôsobí ako odvetvovo špecifický právny akt Únie pre prekrývajúce sa požiadavky kybernetickej bezpečnosti. V praxi by finančné subjekty mali uprednostniť DORA pri riadení rizík IKT, nahlasovaní incidentov, testovaní a rizikách tretích strán v oblasti IKT tam, kde sa režimy prekrývajú, a zároveň rozumieť očakávaniam NIS2 týkajúcim sa skupinových štruktúr, dodávateľov a nefinančných digitálnych služieb.

DORA zároveň kladie zodpovednosť na najvyššiu úroveň. DORA Article 5 vyžaduje, aby riadiaci orgán definoval, schvaľoval, dohliadal na usporiadanie riadenia rizík IKT a implementoval ho. Patrí sem stratégia digitálnej prevádzkovej odolnosti, politika kontinuity činností v oblasti IKT, plány reakcie a obnovy, plány auditov, rozpočty, politiky pre tretie strany v oblasti IKT, kanály nahlasovania a dostatočná znalosť rizík IKT prostredníctvom pravidelného školenia.

Auditná otázka teda neznie len: „Spustili ste TLPT?“

Znie takto:

• Bolo TLPT prepojené s kritickými alebo dôležitými funkciami?
• Bolo autorizované, správne vymedzené, bezpečné a podrobené posúdeniu rizík?
• Boli podľa relevantnosti zahrnutí dodávatelia, cloudové závislosti a outsourcované služby IKT?
• Vygeneroval test dôkazy o detekcii, reakcii, obnove a získaných poznatkoch?
• Boli zistenia prevedené na ošetrenie rizík, sledovanú nápravu, opätovné testovanie a reportovanie manažmentu?
• Vysvetľovalo Vyhlásenie o uplatniteľnosti, ktoré opatrenia prílohy A ISO 27001 boli vybrané na riadenie rizika?

Preto Clarysec považuje dôkazy DORA TLPT za otázku dôkazov v ISMS, nielen za výstup penetračného testovania.

Vybudujte dôkazovú os ISO 27001 ešte pred začiatkom testu

ISO 27001 vyžaduje, aby organizácia vytvorila, implementovala, udržiavala a neustále zlepšovala ISMS, ktorý chráni dôvernosť, integritu a dostupnosť prostredníctvom procesu riadenia rizík. Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia pochopila interné a externé otázky, zainteresované strany, zákonné a regulačné povinnosti, rozhrania a závislosti a následne zdokumentovala rozsah ISMS.

Pre subjekt regulovaný DORA by tento krok vymedzenia rozsahu mal výslovne zachytiť kritické alebo dôležité funkcie, aktíva IKT, cloudové platformy, outsourcované operácie, platobné systémy, zákaznícke portály, služby identít, platformy logovania, prostredia obnovy a externých poskytovateľov služieb IKT. Ak sa rozsah TLPT nemapuje späť na rozsah ISMS, auditná stopa je oslabená už na začiatku.

Kapitoly ISO 27001 6.1.1, 6.1.2 a 6.1.3 spolu s kapitolami 8.2 a 8.3 vyžadujú proces posúdenia rizík a ošetrenia rizík. Riziká musia byť identifikované vo vzťahu k dôvernosti, integrite a dostupnosti. Musia byť priradení vlastníci rizík. Musí sa posúdiť pravdepodobnosť a následok. Opatrenia musia byť vybrané a porovnané s prílohou A. Zostatkové riziko musia akceptovať vlastníci rizík.

Toto je most medzi DORA a testovaním pripraveným na audit.

Clarysec Zenith Blueprint: 30-kroková cestovná mapa audítora Zenith Blueprint vo fáze riadenia rizík, krok 13, túto úlohu sledovateľnosti opisuje jasne:

SoA je v praxi premostovací dokument: prepája vaše posúdenie/ošetrenie rizík so skutočnými kontrolami, ktoré máte zavedené. Jeho vyplnením zároveň overíte, či vám neunikli nejaké kontroly.

Pri DORA TLPT nemá byť Vyhlásenie o uplatniteľnosti statickým certifikačným artefaktom. Má vysvetliť, prečo sú pre scenár odolnosti uplatniteľné opatrenia ako bezpečnosť dodávateľov, riadenie incidentov, pripravenosť IKT na kontinuitu činností, logovanie, monitorovanie, technické riadenie zraniteľností, zálohy, bezpečný vývoj a bezpečnostné testovanie.

Praktický rizikový scenár môže znieť takto:

„Kompromitácia poverení privilegovaného poskytovateľa identít umožní útočníkovi získať prístup k administračným systémom spracovania platieb, zmeniť smerovacie konfigurácie a narušiť kritickú platobnú funkciu, čo spôsobí prerušenie služby, regulačné oznamovacie povinnosti, ujmu zákazníkom a reputačnú ujmu.“

Tento jediný scenár môže riadiť rozsah TLPT, detekčné prípady použitia, zapojenie dodávateľov, cvičenie obnovy, reportovanie riadiacemu orgánu aj súbor dôkazov.

Zenith Blueprint tiež odporúča výslovne uvádzať regulačnú sledovateľnosť:

Krížovo odkazujte na predpisy: ak sú určité kontroly implementované špecificky na dosiahnutie súladu s GDPR, NIS2 alebo DORA, môžete to uviesť buď v registri rizík ako súčasť odôvodnenia dopadu rizika, alebo v poznámkach SoA.

Táto rada je jednoduchá, ale mení auditný rozhovor. Namiesto tvrdenia audítorovi, že DORA bola zohľadnená, môže organizácia ukázať, kde sa DORA objavuje v registri rizík, SoA, testovacom programe, súbore politík a preskúmaní manažmentom.

Mapujte testovanie podľa DORA na opatrenia ISO 27001, ktoré audítori poznajú

DORA Article 6 očakáva zdokumentovaný rámec riadenia rizík IKT integrovaný do celkového riadenia rizík. Príloha A ISO 27001 poskytuje katalóg opatrení, ktorý z toho robí prevádzkovú prax.

Pre DORA TLPT a testovanie odolnosti sú obzvlášť dôležité tieto opatrenia prílohy A ISO/IEC 27001:2022:

Clarysec Zenith Controls: Sprievodca krížovým súladom Zenith Controls pomáha organizáciám vyhnúť sa tomu, aby tieto opatrenia vnímali ako izolované položky kontrolného zoznamu. Mapuje opatrenia ISO/IEC 27002:2022 na atribúty, domény, prevádzkové schopnosti, auditné očakávania a vzory naprieč rámcami.

Napríklad Zenith Controls klasifikuje opatrenie ISO/IEC 27002:2022 5.30, pripravenosť IKT na kontinuitu činností, ako „nápravné“, zosúladené s „dostupnosťou“, spojené s konceptom kybernetickej bezpečnosti „reagovať“ a zaradené do domény „odolnosť“. Táto klasifikácia je užitočná pri vysvetľovaní audítorom, prečo cvičenie obnovy nie je len IT operácia, ale opatrenie odolnosti s definovanou úlohou v kontrolnom prostredí.

Zenith Controls tiež klasifikuje opatrenie 8.29, bezpečnostné testovanie vo vývoji a akceptácii, ako preventívne opatrenie podporujúce dôvernosť, integritu a dostupnosť, s prevádzkovými schopnosťami v oblasti bezpečnosti aplikácií, uistenia informačnej bezpečnosti a bezpečnosti systémov a sietí. Pri zisteniach TLPT, ktoré spätne smerujú k slabine návrhu aplikácie, nezabezpečenému správaniu API, slabému autentifikačnému toku alebo nedostatočnej validácii, ide o cestu do správy a riadenia bezpečného vývoja.

Dôležité je aj opatrenie 5.35, nezávislé preskúmanie informačnej bezpečnosti. Podporuje nezávislé preverenie, uistenie správy a riadenia a nápravné zlepšovanie. Interné tímy môžu testovanie koordinovať, ale dôkazy pripravené na audit vyžadujú preskúmanie, eskaláciu a dohľad nad rámec osôb, ktoré testované systémy vybudovali alebo prevádzkovali.

Chráňte systém počas jeho testovania

Jedným z nebezpečných predpokladov pri testovaní odolnosti je, že testovanie je automaticky prospešné. V skutočnosti môže invazívne testovanie spôsobiť výpadky, sprístupniť citlivé údaje, znečistiť logy, spustiť automatizované obranné mechanizmy, prerušiť zákaznícke relácie alebo prinútiť dodávateľov aktivovať núdzové postupy.

Clarysec Politika bezpečnostného testovania a cvičení Red Teamu Security Testing and Red-Teaming Policy poskytuje organizáciám vzor správy a riadenia pre bezpečné vykonanie. Bod 6.1 uvádza:

Typy testov: program bezpečnostného testovania musí zahŕňať minimálne: (a) skenovanie zraniteľností pozostávajúce z automatizovaných týždenných alebo mesačných skenov sietí a aplikácií na identifikáciu známych zraniteľností; (b) penetračné testovanie pozostávajúce z manuálneho hĺbkového testovania konkrétnych systémov alebo aplikácií kvalifikovanými testermi na identifikáciu zložitých slabín; a (c) cvičenia red teamu pozostávajúce zo simulácií skutočných útokov založených na scenároch vrátane sociálneho inžinierstva a ďalších taktík, na otestovanie detekčných a reakčných schopností organizácie ako celku.

Pri TLPT je prvok Red Teamu zrejmý, ale auditná hodnota vyplýva z návrhu programu. Skenovanie zraniteľností, penetračné testovanie, cvičenia Red Teamu, cvičenia odolnosti a opätovné testovanie majú tvoriť cyklus, nie zbierku neprepojených testov.

Bod 6.2 tej istej politiky rieši bezpečné vykonanie:

Rozsah a pravidlá vykonania: pri každom teste alebo cvičení musí STC definovať rozsah vrátane systémov a IP rozsahov v rozsahu, povolených testovacích metód, cieľov, časovania a trvania. Pravidlá vykonania musia byť zdokumentované. Napríklad prevádzkovo citlivé systémy môžu byť označené ako určené len na monitorovanie, aby sa predišlo narušeniu, a každé testovanie v produkcii musí zahŕňať postupy vrátenia zmien a zastavenia. Bezpečnostné opatrenia, napríklad definované časové okná a komunikačné kanály, musia byť stanovené tak, aby sa predišlo neúmyselným výpadkom služieb.

To priamo mapuje na Zenith Blueprint, fázu Controls in Action, krok 21, ktorý sa zameriava na opatrenie prílohy A ISO 27001 8.34, ochranu informačných systémov počas auditného testovania. Zenith Blueprint upozorňuje, že audity, penetračné testy, forenzné preskúmania a prevádzkové hodnotenia môžu zahŕňať zvýšený prístup, invazívne nástroje alebo dočasné zmeny správania systému. Zdôrazňuje autorizáciu, rozsah, časové okná, schválenie vlastníkom systému, vrátenie zmien, monitorovanie a bezpečné nakladanie s testovacími údajmi.

Balík dôkazov pripravený na audit má zahŕňať:

• chartu a ciele TLPT
• súhrn spravodajstva o hrozbách a odôvodnenie scenára
• kritické alebo dôležité funkcie v rozsahu
• systémy, IP rozsahy, identity, dodávateľov a prostredia v rozsahu
• vylúčenia a systémy určené len na monitorovanie
• pravidlá vykonania
• posúdenie rizík testovania v produkcii
• postupy vrátenia zmien a zastavenia
• model notifikovania SOC vrátane toho, čo sa zverejňuje a čo sa zadržiava
• schválenia právneho oddelenia, ochrany súkromia a dodávateľov
• dôkazy o vytvorení a zrušení testovacích účtov
• bezpečné úložisko pre testovacie artefakty a logy

DORA TLPT, ktoré nevie preukázať bezpečnú autorizáciu a riadenie testovacej aktivity, môže odhaliť medzery v odolnosti, ale zároveň vytvára medzery v správe a riadení.

Premeňte výstup TLPT na ošetrenie rizík

Najčastejším zlyhaním po teste je problém správy Red Teamu odloženej do zásuvky. Kvalitná správa je doručená, rozposlaná, prediskutovaná a potom postupne stratí dynamiku. Zistenia zostávajú otvorené. Kompenzačné opatrenia nie sú zdokumentované. Akceptované riziká sú neformálne. Opätovné testovanie sa nikdy neuskutoční.

Politika bezpečnostného testovania a cvičení Red Teamu to robí neprijateľným. Bod 6.6 uvádza:

Náprava zistení: všetky identifikované zraniteľnosti alebo slabiny musia byť zdokumentované v správe o zisteniach s klasifikáciou závažnosti. Po prijatí správy sú vlastníci systémov zodpovední za vytvorenie plánu nápravy s lehotami plnenia; napríklad kritické zistenia musia byť napravené do 30 dní a zistenia s vysokou závažnosťou do 60 dní v súlade s Politikou riadenia zraniteľností a záplat organizácie. STC musí sledovať postup nápravy. Opätovné testovanie sa musí vykonať na potvrdenie, že kritické problémy boli vyriešené alebo primerane zmiernené.

Bod 6.7 pridáva vrstvu správy a riadenia:

Reportovanie: po ukončení každého testu musí byť vydaná formálna správa. Pri penetračnom testovaní musí správa obsahovať súhrn pre manažment, metodiku a podrobné zistenia s podpornými dôkazmi a odporúčaniami. Pri cvičeniach red teamu musí správa podrobne opísať scenáre, úspešné cesty útoku, čo detegoval Blue Team, a získané poznatky týkajúce sa medzier v detekcii a reakcii. CISO musí prezentovať zhrnuté výsledky a stav nápravy vrcholovému manažmentu a podľa relevantnosti ich zahrnúť do ročnej bezpečnostnej správy pre predstavenstvo.

To je v súlade s usmernením ISO/IEC 27005:2022 pre ošetrenie rizík: vybrať možnosti ošetrenia, určiť opatrenia z prílohy A ISO 27001 a odvetvovo špecifických požiadaviek, vytvoriť plán ošetrenia rizík, priradiť zodpovedné osoby, definovať termíny, sledovať stav, získať schválenie vlastníka rizika a zdokumentovať akceptáciu zostatkového rizika.

Každé významné zistenie TLPT sa má stať jednou zo štyroch vecí: nápravným opatrením, zlepšením opatrenia, formálnou akceptáciou rizika alebo požiadavkou na opätovné testovanie.

Cieľom nie je vytvoriť viac dokumentov. Cieľom je, aby každý dokument vysvetľoval ďalšie rozhodnutie.

Testovanie odolnosti musí preukázať obnovu, nielen detekciu

Úspešné TLPT môže ukázať, že SOC detegoval command-and-control prevádzku, zablokoval laterálny pohyb a správne eskaloval. To je hodnotné, ale testovanie odolnosti podľa DORA ide ďalej. Pýta sa, či organizácia dokáže pokračovať v poskytovaní obchodných služieb alebo ich obnoviť.

Zenith Blueprint, fáza Controls in Action, krok 23, vysvetľuje opatrenie 5.30, pripravenosť IKT na kontinuitu činností, jazykom, ktorý by mal každý CISO používať s predstavenstvom:

Z pohľadu auditu sa táto kontrola často testuje jednou vetou: Ukážte mi to. Ukážte mi posledný výsledok testu. Ukážte mi dokumentáciu obnovy. Ukážte mi, ako dlho trvalo prepnutie na záložné prostredie a návrat späť. Ukážte mi dôkaz, že to, čo bolo sľúbené, možno dodať.

Tento štandard „Ukážte mi to“ je rozdielom medzi zrelosťou politiky a prevádzkovou odolnosťou.

Clarysec Politika kontinuity činností a obnovy po havárii pre MSP Business Continuity Policy and Disaster Recovery Policy - SME, zo sekcie „Požiadavky na implementáciu politiky“, bod 6.4.1, uvádza:

Organizácia musí testovať svoje schopnosti BCP aj DR aspoň raz ročne. Testy musia zahŕňať:

Sekcia uplatňovania tej istej politiky, bod 8.5.1, výslovne stanovuje zodpovednosť za dôkazy:

GM musí zabezpečiť, aby boli nasledujúce položky udržiavané a pripravené na audit:

Pre finančný subjekt regulovaný DORA môže byť ročné testovanie minimom, nie ambíciou. Kritické alebo dôležité funkcie s vyšším rizikom by sa mali testovať častejšie, najmä po zmenách architektúry, migrácii do cloudového prostredia, významných incidentoch, nových dodávateľoch IKT, významných vydaniach aplikácií alebo zmenách vystavenia hrozbám.

Silný dôkazový balík testu odolnosti má obsahovať:

• analýzu vplyvov na podnikanie mapujúcu kritickú alebo dôležitú funkciu
• RTO a RPO schválené vlastníkmi biznisu
• mapu závislostí systému vrátane identít, DNS, siete, cloudu, databázy, monitorovania, zálohovania a služieb tretích strán
• výsledky testov zálohovania a obnovy
• časové pečiatky prepnutia na záložné riešenie a návratu späť
• dôkazy o fungovaní bezpečnostných opatrení počas narušenia
• šablóny komunikácie so zákazníkmi, regulátorom a internými stranami
• logy účasti veliteľa incidentu a krízového tímu
• získané poznatky a zlepšovacie opatrenia
• dôkazy opätovného testovania predchádzajúcich medzier v obnove

Práve tu do príbehu vstupuje GDPR. GDPR Articles 2 and 3 zahŕňajú do rozsahu väčšinu SaaS a fintech spracúvania osobných údajov EÚ. Article 4 definuje osobné údaje, spracúvanie, prevádzkovateľa, sprostredkovateľa a porušenie ochrany osobných údajov. Article 5 vyžaduje integritu, dôvernosť a zodpovednosť za konanie, čo znamená, že organizácia musí vedieť preukázať súlad. Ak TLPT alebo testovanie obnovy používa produkčné osobné údaje, kopíruje logy obsahujúce identifikátory alebo validuje reakciu na porušenie ochrany údajov, musia byť zdokumentované ochranné opatrenia na ochranu súkromia.

Dôkazy dodávateľov sú slepým miestom DORA, ktoré audítori nebudú ignorovať

Moderné finančné služby sú zostavené z cloudových platforiem, SaaS aplikácií, poskytovateľov riadených bezpečnostných služieb, spracovateľov platieb, dátových platforiem, poskytovateľov identít, nástrojov pozorovateľnosti, outsourcovaných vývojových tímov a poskytovateľov zálohovania.

DORA Article 28 vyžaduje, aby finančné subjekty riadili riziká tretích strán v oblasti IKT ako súčasť rámca riadenia rizík IKT a zostali plne zodpovedné aj tam, kde sú služby IKT outsourcované. DORA Article 30 vyžaduje písomné zmluvy o službách IKT s opisom služieb, podmienkami subdodávok, miestami spracúvania, ochranou údajov, prístupom a obnovou, úrovňami služieb, asistenciou pri incidentoch, spoluprácou s orgánmi, právami na ukončenie, prísnejšími podmienkami pre kritické alebo dôležité funkcie, právami na audit, bezpečnostnými opatreniami, účasťou na TLPT tam, kde je relevantná, a výstupnými opatreniami.

To znamená, že scenár TLPT sa nemôže zastaviť na firewalle organizácie, ak kritická funkcia závisí od dodávateľa.

Clarysec Politika bezpečnosti tretích strán a dodávateľov pre MSP Third-Party and Supplier Security Policy - SME, zo sekcie „Požiadavky na implementáciu politiky“, bod 6.3.1, uvádza:

Kritickí alebo vysokorizikoví dodávatelia musia byť preskúmaní aspoň raz ročne. Preskúmanie musí overiť:

Politika bezpečnostného testovania a cvičení Red Teamu pridáva v bode 6.9 požiadavku na dodávateľov špecifickú pre testovanie:

Koordinácia testovania s tretími stranami: ak akýkoľvek kritický dodávateľ alebo poskytovateľ služieb spadá do rozsahu celkovej bezpečnosti organizácie, organizácia musí v súlade s Politikou bezpečnosti tretích strán a dodávateľov podľa možností získať uistenie o jeho praktikách bezpečnostného testovania alebo koordinovať spoločné testovanie. Napríklad ak sa používa poskytovateľ cloudových služieb (CSP), organizácia sa môže spoliehať na jeho správy z penetračného testovania alebo ho zahrnúť do spoločných scenárov red teamu, ak to umožňujú zmluvné ustanovenia.

Pri dôkazoch DORA pripravených na audit má byť uistenie dodávateľov prepojené s tým istým rizikovým scenárom ako TLPT. Ak je poskytovateľ identít nevyhnutný pre obnovu platieb, dôkazový balík má obsahovať due diligence dodávateľa, zmluvné bezpečnostné požiadavky, podmienky podpory pri incidentoch, koordináciu testovania, správy o uistení, dôkazy o úrovni služieb, stratégiu ukončenia a obmedzenia testovania.

NIS2 Article 21 je dôležitý aj pre poskytovateľov SaaS, cloudových služieb, riadených služieb, riadenej bezpečnosti, dátových centier, CDN, dôveryhodných služieb, DNS, TLD, online trhovísk, vyhľadávania a sociálnych sietí. Vyžaduje prístup založený na všetkých hrozbách zahŕňajúci analýzu rizík, riešenie incidentov, kontinuitu činností, bezpečnosť dodávateľského reťazca, bezpečný vývoj, posúdenie účinnosti, školenia, kryptografiu, riadenie prístupu, správu aktív, MFA a bezpečnú komunikáciu.

Praktický výsledok je jednoduchý: finančné subjekty by mali vybudovať jeden dôkazový model, ktorý primárne spĺňa DORA, a následne krížovo odkazuje na očakávania NIS2 tam, kde sú zapojení dodávatelia, skupinové subjekty alebo nefinančné digitálne služby.

Praktická dôkazová evidencia Clarysec pre TLPT

Predpokladajme tento scenár:

„Pôvodca hrozby kompromituje administrátorský účet na SaaS podpornej platforme, presunie sa do prostredia platobnej prevádzky, zmení konfiguráciu a naruší spracovanie transakcií.“

Vytvorte dôkazovú evidenciu s jedným riadkom pre každý dôkazový objekt. Nečakajte na koniec testu. Napĺňajte ju počas plánovania, vykonania, nápravy a uzatvorenia.

Následne použite Zenith Blueprint krok 13 na doplnenie sledovateľnosti do registra rizík a Vyhlásenia o uplatniteľnosti. Každá dôkazová položka sa má prepájať s rizikovým scenárom, vlastníkom rizika, vybraným opatrením, plánom ošetrenia a rozhodnutím o zostatkovom riziku.

Ak sa zistenie týka softvérovej slabiny, odkážte na opatrenia bezpečného vývoja a testovania. Clarysec Politika bezpečného vývoja pre MSP Secure Development Policy - SME, zo sekcie „Požiadavky na implementáciu politiky“, bod 6.5.2, vyžaduje:

Testovanie musí byť zdokumentované s:

Ak zistenie vytvorí forenzný materiál, zachovajte reťazec zverenia. Clarysec Politika zberu dôkazov a forenznej analýzy pre MSP Evidence Collection and Forensics Policy - SME, zo sekcie „Požiadavky na správu a riadenie“, bod 5.2.1, uvádza:

Každá položka digitálneho dôkazu musí byť zalogovaná s:

Práve toto mnohé tímy prehliadajú. Dôkazy nie sú iba finálne správy. Sú to riadené záznamy o tom, kto schválil, kto vykonal, čo sa stalo, čo bolo detegované, čo bolo obnovené, čo sa zmenilo, čo zostáva vystavené a kto túto expozíciu akceptoval.

Ako audítori skúmajú tie isté dôkazy TLPT

Dôkazy DORA TLPT sa budú čítať odlišne podľa zamerania audítora. Clarysec navrhuje dôkazové balíky tak, aby každý pohľad našiel to, čo potrebuje, bez toho, aby tímy museli duplikovať prácu.

COBIT 2019 sa objavuje v referencii krížového súladu Zenith Blueprint pre bezpečné vykonanie auditu a testovania vrátane DSS05.03 a MEA03.04. Význam nespočíva v tom, že COBIT nahrádza DORA alebo ISO 27001, ale v tom, že profesionáli v oblasti uistenia podľa prístupu ISACA budú hľadať kontrolované vykonanie, monitorovanie, hodnotenie a dôkazy súladu.

Príbeh pre predstavenstvo: čo musí manažment schváliť

Reportovanie predstavenstvu sa má vyhnúť technickému divadlu. Predstavenstvo nepotrebuje technické detaily exploitov. Potrebuje dôkazy vhodné na rozhodovanie:

• Ktorá kritická alebo dôležitá funkcia bola testovaná?
• Aký scenár hrozieb bol simulovaný a prečo?
• Fungovala detekcia?
• Fungovala eskalácia reakcie?
• Splnila obnova RTO a RPO?
• Ktorí dodávatelia boli zapojení alebo predstavovali obmedzenia?
• Aké významné slabiny zostávajú?
• Aké sú náklady na nápravu, vlastník a časový plán?
• Ktoré zostatkové riziká vyžadujú formálnu akceptáciu?
• Čo sa bude opätovne testovať?

Tu sa stáva dôležitou kapitola 5 ISO 27001. Vrcholový manažment musí zabezpečiť, aby boli politika a ciele informačnej bezpečnosti ustanovené, zosúladené so strategickým smerovaním, integrované do obchodných procesov, vybavené zdrojmi, komunikované a neustále zlepšované. Roly a zodpovednosti musia byť priradené. Ciele musia byť merateľné tam, kde je to uskutočniteľné, a musia zohľadňovať uplatniteľné požiadavky a výsledky ošetrenia rizík.

Ak TLPT zistí, že čas obnovy je šesť hodín oproti štvorhodinovej tolerancii organizácie, nejde iba o položku backlogu infraštruktúry. Je to manažérske rozhodnutie zahŕňajúce apetít na riziko, rozpočet, záväzky voči zákazníkom, regulačnú expozíciu, zmluvy, architektúru a prevádzkovú kapacitu.

Bežné zlyhania dôkazov pri testovaní odolnosti podľa DORA

Preskúmania Clarysec často nachádzajú rovnaké medzery v dôkazoch naprieč finančnými subjektmi a poskytovateľmi služieb IKT pripravujúcimi sa na DORA.

Po prvé, rozsah TLPT sa nemapuje na kritické alebo dôležité funkcie. Test môže byť technicky pôsobivý, ale nepreukazuje odolnosť obchodného procesu, na ktorom regulátorom záleží.

Po druhé, dodávateľské závislosti sú priznané, ale nie sú doložené dôkazmi. Tímy hovoria, že cloudový poskytovateľ, riadené SOC alebo SaaS platforma sú v rozsahu, no chýbajú zmluvy, práva na audit, povolenia na testovanie, podmienky podpory pri incidentoch a plány ukončenia.

Po tretie, testovanie vytvára dôkazy, ale nie ošetrenie. Zistenia zostávajú v správe Red Teamu namiesto toho, aby boli prevedené na aktualizácie registra rizík, zmeny opatrení, vlastníkov, termíny, opätovné testovanie a rozhodnutia o zostatkovom riziku.

Po štvrté, obnova sa predpokladá namiesto toho, aby bola preukázaná. Politiky zálohovania existujú, ale nikto nevie ukázať časové pečiatky prepnutia na záložné riešenie, kontroly integrity obnovy, overenie prístupu alebo potvrdenie vlastníkom biznisu.

Po piate, dôkazy ochrany súkromia a forenzné dôkazy sú neriadené. Logy a snímky obrazovky obsahujú osobné údaje, testovacie artefakty sú uložené v zdieľaných úložiskách, dočasné účty zostávajú aktívne a reťazec zverenia dôkazov je neúplný.

Po šieste, reportovanie manažmentu je príliš technické. Vrcholové vedenie nevidí, či sa odolnosť zlepšila, či je riziko v rámci apetítu, ani aké investičné rozhodnutia sú potrebné.

Každú z týchto medzier možno vyriešiť tým, že sa DORA TLPT bude riadiť ako štruktúrovaný dôkazový pracovný tok ISO 27001.

Integrovaný prístup Clarysec k odolnosti pripravenej na audit

Prístup Clarysec kombinuje tri vrstvy.

Prvou vrstvou je 30-kroková implementačná cestovná mapa Zenith Blueprint. Pre túto tému krok 13 buduje sledovateľnosť ošetrenia rizík a SoA, krok 21 chráni systémy počas auditného testovania a krok 23 validuje pripravenosť IKT na kontinuitu činností. Tieto kroky menia TLPT z technickej udalosti na zdokumentovaný cyklus správy a riadenia.

Druhou vrstvou je knižnica politík Clarysec. Politika bezpečnostného testovania a cvičení Red Teamu definuje typy testovania, rozsah, pravidlá vykonania, nápravu, reportovanie a koordináciu s dodávateľmi. Politika kontinuity činností a obnovy po havárii pre MSP stanovuje očakávania pre ročné testovanie BCP a DR a dôkazy kontinuity pripravené na audit. Politika bezpečnosti tretích strán a dodávateľov pre MSP podporuje uistenie dodávateľov. Politika bezpečného vývoja pre MSP zabezpečuje, aby bolo bezpečnostné testovanie zdokumentované. Politika zberu dôkazov a forenznej analýzy pre MSP podporuje logovanie dôkazov a disciplínu reťazca zverenia.

Treťou vrstvou je Zenith Controls, sprievodca krížovým súladom od Clarysec. Pomáha mapovať opatrenia ISO/IEC 27002:2022 na atribúty, domény, prevádzkové schopnosti a očakávania naprieč rámcami. Pri DORA TLPT nie je najdôležitejším vzorom jedno opatrenie. Je ním vzťah medzi testovaním, kontinuitou, riadením incidentov, riadením dodávateľov, logovaním, monitorovaním, bezpečným vývojom, nezávislým preskúmaním a správou a riadením.

Keď tieto vrstvy fungujú spolu, pondelkový ranný problém CISO sa zmení. Namiesto troch neprepojených otázok predstavenstva, regulátora a interného auditu má organizácia jeden dôkazový príbeh:

„Identifikovali sme kritickú funkciu. Posúdili sme riziko IKT. Vybrali a odôvodnili sme opatrenia. Autorizovali sme a bezpečne vykonali TLPT. Detegovali sme, reagovali a obnovili sme činnosť. Zapojili sme dodávateľov tam, kde to bolo potrebné. Zdokumentovali sme dôkazy. Napravili sme zistenia. Vykonali sme opätovné testovanie. Manažment preskúmal a akceptoval zostávajúce riziko.“

To je odolnosť pripravená na audit.

Ďalšie kroky

Ak je váš program DORA TLPT stále organizovaný okolo správ namiesto dôkazových reťazcov, začnite dôkazovým walkthrough s Clarysec.

Použite Zenith Blueprint Zenith Blueprint krok 13 na prepojenie scenárov TLPT s rizikami, opatreniami a Vyhlásením o uplatniteľnosti. Použite krok 21 na overenie bezpečnej autorizácie, pravidiel vykonania, vrátenia zmien, monitorovania a čistenia. Použite krok 23 na preukázanie pripravenosti IKT na kontinuitu činností pomocou dôkazov obnovy.

Následne zosúlaďte svoje prevádzkové dokumenty s Clarysec Politikou bezpečnostného testovania a cvičení Red Teamu Security Testing and Red-Teaming Policy, Politikou kontinuity činností a obnovy po havárii pre MSP Business Continuity Policy and Disaster Recovery Policy - SME, Politikou bezpečnosti tretích strán a dodávateľov pre MSP Third-Party and Supplier Security Policy - SME, Politikou bezpečného vývoja pre MSP Secure Development Policy - SME a Politikou zberu dôkazov a forenznej analýzy pre MSP Evidence Collection and Forensics Policy - SME.

Nakoniec použite Zenith Controls Zenith Controls na krížové mapovanie dôkazov DORA TLPT na opatrenia ISO 27001, NIS2, GDPR, COBIT 2019 a očakávania audítorov.

Ak chcete, aby váš ďalší test odolnosti priniesol viac než len zistenia, použite Clarysec na jeho premenu na obhájiteľný dôkazový reťazec. Stiahnite si súbory nástrojov, naplánujte posúdenie pripravenosti dôkazov alebo si vyžiadajte walkthrough, ako Clarysec mapuje DORA TLPT na opatrenia ISO 27001:2022 od plánovania až po schválenie predstavenstvom.