DORA TLPT dokazi povezani s ISO 27001 kontrolama

Ponedjeljak je, 07:40, a CISO srednje velike platne institucije gleda u tri verzije istog neugodnog pitanja.

Upravni odbor želi znati može li organizacija preživjeti prekid rada korisničkog platnog portala uzrokovan ransomwareom. Regulator želi dokaz da testiranje digitalne operativne otpornosti nije vježba u PowerPointu. Interna revizija želi jasan trag od DORA obveza do IKT rizika, ISO 27001 kontrola, rezultata testiranja, planova korektivnih mjera, dokaza dobavljača i odobrenja uprave.

CISO ima izvješće crvenog tima. SOC ima snimke zaslona upozorenja. Infrastrukturni tim ima dnevnički zapis vraćanja iz sigurnosne kopije. Pravni odjel ima alat za praćenje spremnosti za DORA. Nabava ima atestacije pružatelja usluga u oblaku.

Ništa od toga nije povezano.

Tu mnogi DORA TLPT programi i programi testiranja otpornosti ne uspijevaju. Ne zato što je testiranje slabo, nego zato što su dokazi fragmentirani. Kada revizor zatraži: “Pokažite mi kako ovaj test dokazuje otpornost kritične ili važne funkcije”, odgovor ne može biti mapa puna snimki zaslona. Mora postojati dokaziv dokazni lanac.

Upravo u tom lancu ISMS usklađen s ISO/IEC 27001:2022 postaje snažan. ISO 27001 daje strukturu opsegu, procjeni rizika, odabiru kontrola, Izjavi o primjenjivosti, operativnoj kontroli, internoj reviziji, preispitivanju od strane uprave i kontinuiranom poboljšavanju. DORA donosi sektorski regulatorni pritisak. Clarysec metodologija i alati za međusobno mapiranje usklađenosti povezuju oboje u jedinstven model dokaza spreman za reviziju.

DORA TLPT je test upravljanja, a ne samo simulacija napada

Penetracijsko testiranje vođeno prijetnjama, odnosno TLPT, lako je pogrešno razumjeti. Tehnički može izgledati kao napredna vježba crvenog tima: obavještajni podaci o prijetnjama, realistični putovi napada, prikrivanje, pokušaji iskorištavanja ranjivosti, scenariji lateralnog kretanja i provjera odgovora plavog tima.

Za DORA, dublje pitanje je digitalna operativna otpornost. Može li financijski subjekt izdržati ozbiljan IKT poremećaj koji utječe na poslovne procese, odgovoriti na njega i oporaviti se od njega? Može li dokazati da kritične ili važne funkcije ostaju unutar dopuštenih razina utjecaja? Može li uprava pokazati da se IKT rizikom upravlja, da je financiran, testiran, otklonjen i poboljšan?

Članak 1 DORA uspostavlja jedinstveni okvir EU-a za sigurnost mrežnih i informacijskih sustava koji podržavaju poslovne procese financijskih subjekata. Obuhvaća upravljanje IKT rizicima, prijavljivanje većih IKT incidenata, testiranje digitalne operativne otpornosti, upravljanje rizicima IKT trećih strana, obvezne ugovorne zahtjeve za IKT dobavljače, nadzor nad kritičnim IKT pružateljima trećih strana i suradnju nadzornih tijela. DORA se primjenjuje od 17. siječnja 2025.

Za organizacije koje su obuhvaćene i NIS2, DORA djeluje kao sektorski poseban pravni akt Unije za preklapajuće zahtjeve kibernetičke sigurnosti. U praksi financijski subjekti trebaju dati prednost DORA za upravljanje IKT rizicima, prijavljivanje incidenata, testiranje i rizik IKT trećih strana kada se režimi preklapaju, uz razumijevanje očekivanja NIS2 za grupne strukture, dobavljače i nefinancijske digitalne usluge.

DORA također postavlja odgovornost na najvišu razinu. Članak 5 zahtijeva da upravljačko tijelo definira, odobri, nadzire i provodi aranžmane upravljanja IKT rizicima. To uključuje strategiju digitalne operativne otpornosti, politiku neprekidnosti poslovanja za IKT, planove odgovora i oporavka, planove revizije, proračune, politike za IKT treće strane, kanale izvješćivanja i dostatno znanje o IKT riziku kroz redovitu obuku.

Stoga revizijsko pitanje nije samo: “Jeste li proveli TLPT?”

Pitanje je:

• Je li TLPT bio povezan s kritičnim ili važnim funkcijama?
• Je li bio odobren, jasno opsežen, siguran i procijenjen s aspekta rizika?
• Jesu li dobavljači, ovisnosti o oblaku i eksternalizirane IKT usluge uključeni gdje je relevantno?
• Je li test proizveo dokaze o otkrivanju, odgovoru, oporavku i naučenim lekcijama?
• Jesu li nalazi pretvoreni u obradu rizika, praćene korektivne mjere, ponovno testiranje i izvješćivanje uprave?
• Je li Izjava o primjenjivosti objasnila koje su kontrole iz Priloga A ISO 27001 odabrane za upravljanje rizikom?

Zato Clarysec tretira DORA TLPT dokaze kao pitanje dokaza u ISMS-u, a ne samo kao isporučevinu penetracijskog testiranja.

Izgradite ISO 27001 dokaznu okosnicu prije početka testa

ISO 27001 zahtijeva da organizacija uspostavi, implementira, održava i kontinuirano poboljšava ISMS koji čuva povjerljivost, cjelovitost i dostupnost kroz proces upravljanja rizicima. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije interna i eksterna pitanja, zainteresirane strane, pravne i regulatorne obveze, sučelja, ovisnosti te potom dokumentira opseg ISMS-a.

Za subjekt reguliran DORA, ovaj korak određivanja opsega mora izričito obuhvatiti kritične ili važne funkcije, IKT imovinu, platforme u oblaku, eksternalizirane operacije, platne sustave, korisničke portale, usluge identiteta, platforme za zapisivanje događaja, okruženja za oporavak i pružatelje IKT usluga trećih strana. Ako se opseg TLPT-a ne mapira natrag na opseg ISMS-a, revizijski trag je već slab.

ISO 27001 točke 6.1.1, 6.1.2 i 6.1.3, zajedno s točkama 8.2 i 8.3, zahtijevaju proces procjene rizika i obrade rizika. Rizici se moraju identificirati u odnosu na povjerljivost, cjelovitost i dostupnost. Vlasnici rizika moraju biti dodijeljeni. Vjerojatnost i posljedice moraju se procijeniti. Kontrole se moraju odabrati i usporediti s Prilogom A. Preostali rizik moraju prihvatiti vlasnici rizika.

To je most između DORA i testiranja spremnog za reviziju.

Clarysecov Zenith Blueprint: 30-koračni plan revizora Zenith Blueprint, u fazi upravljanja rizicima, korak 13, jasno opisuje tu ulogu sljedivosti:

SoA je u stvarnosti povezni dokument: povezuje vašu procjenu/obradu rizika sa stvarnim kontrolama koje imate. Njegovim dovršavanjem dodatno provjeravate jeste li propustili neku kontrolu.

Za DORA TLPT, Izjava o primjenjivosti ne smije biti statični certifikacijski artefakt. Treba objasniti zašto su kontrole kao što su sigurnost dobavljača, upravljanje incidentima, IKT spremnost za neprekidnost poslovanja, zapisivanje događaja, praćenje, tehničko upravljanje ranjivostima, sigurnosne kopije, siguran razvoj i sigurnosno testiranje primjenjive na scenarij otpornosti.

Praktičan scenarij rizika mogao bi glasiti:

“Kompromitacija vjerodajnica pružatelja identiteta s privilegiranim pristupom omogućuje napadaču pristup administrativnim sustavima za obradu plaćanja, izmjenu konfiguracija usmjeravanja i prekid kritične platne funkcije, što uzrokuje prekid usluge, regulatorne obveze izvješćivanja, štetu klijentima i reputacijsku štetu.”

Taj jedan scenarij može usmjeravati opseg TLPT-a, slučajeve uporabe za otkrivanje, uključenost dobavljača, vježbu oporavka, izvješćivanje upravnom odboru i skup dokaza.

Zenith Blueprint također preporučuje izričitu regulatornu sljedivost:

Unakrsno referencirajte propise: ako su određene kontrole implementirane posebno radi usklađivanja s GDPR, NIS2 ili DORA, to možete zabilježiti ili u Registru rizika (kao dio obrazloženja utjecaja rizika) ili u napomenama SoA.

Taj je savjet jednostavan, ali mijenja revizijski razgovor. Umjesto da organizacija revizoru kaže da je DORA uzeta u obzir, može pokazati gdje se DORA pojavljuje u registru rizika, SoA, programu testiranja, skupu politika i preispitivanju od strane uprave.

Mapirajte DORA testiranje na ISO 27001 kontrole koje revizori prepoznaju

Članak 6 DORA očekuje dokumentiran okvir za upravljanje IKT rizicima integriran u cjelokupno upravljanje rizicima. Prilog A ISO 27001 daje katalog kontrola koji to čini operativnim.

Za DORA TLPT i testiranje otpornosti osobito su važne ove kontrole iz Priloga A ISO/IEC 27001:2022:

Clarysecov Zenith Controls: vodič za međusobno mapiranje usklađenosti Zenith Controls pomaže organizacijama da ove kontrole ne tretiraju kao izolirane stavke kontrolnog popisa. Mapira ISO/IEC 27002:2022 kontrole na atribute, domene, operativne sposobnosti, revizijska očekivanja i obrasce između različitih okvira.

Na primjer, Zenith Controls klasificira ISO/IEC 27002:2022 kontrolu 5.30, IKT spremnost za neprekidnost poslovanja, kao “korektivnu”, usklađenu s “dostupnošću”, povezanu s konceptom kibernetičke sigurnosti “odgovor” i smještenu u domenu “otpornosti”. Ta je klasifikacija korisna pri objašnjavanju revizorima zašto vježba oporavka nije samo IT operacija, nego kontrola otpornosti s definiranom ulogom u kontrolnom okruženju.

Zenith Controls također klasificira kontrolu 8.29, Sigurnosno testiranje u razvoju i prihvatu, kao preventivnu kontrolu koja podržava povjerljivost, cjelovitost i dostupnost, s operativnim sposobnostima u sigurnosti aplikacija, osiguranju informacijske sigurnosti te sigurnosti sustava i mreže. Za TLPT nalaze koji se vraćaju na slabost dizajna aplikacije, nesigurno ponašanje API-ja, loš tijek autentifikacije ili nedostatnu validaciju, to je kontrolni put prema upravljanju sigurnim razvojem.

Kontrola 5.35, Neovisni pregled informacijske sigurnosti, također je važna. Podržava neovisno preispitivanje, upravljačku provjeru i korektivno poboljšavanje. Interni timovi mogu koordinirati testiranje, ali dokazi spremni za reviziju zahtijevaju pregled, eskalaciju i nadzor izvan osoba koje su izgradile ili operativno vodile testirane sustave.

Zaštitite sustav dok ga testirate

Jedna opasna pretpostavka u testiranju otpornosti jest da je testiranje automatski dobro. U stvarnosti, intruzivno testiranje može uzrokovati prekide usluge, izložiti osjetljive podatke, zagaditi zapise dnevnika, aktivirati automatizirane obrane, prekinuti korisničke sesije ili navesti dobavljače da pokrenu hitne postupke.

Clarysecova Politika sigurnosnog testiranja i vježbi crvenog tima Politika sigurnosnog testiranja i red-teaminga daje organizacijama obrazac upravljanja za sigurnu provedbu. Točka 6.1 navodi:

Vrste testova: program sigurnosnog testiranja mora uključivati najmanje: (a) skeniranja ranjivosti, koja se sastoje od automatiziranih tjednih ili mjesečnih skeniranja mreža i aplikacija radi identifikacije poznatih ranjivosti; (b) penetracijsko testiranje, koje se sastoji od ručnog dubinskog testiranja određenih sustava ili aplikacija od strane kvalificiranih testera radi identifikacije složenih slabosti; i (c) vježbe crvenog tima, koje se sastoje od scenarijskih simulacija stvarnih napada, uključujući socijalni inženjering i druge taktike, radi testiranja sposobnosti organizacije za otkrivanje i odgovor u cjelini.

Za TLPT je element vježbi crvenog tima očit, ali revizijska vrijednost proizlazi iz dizajna programa. Skeniranja ranjivosti, penetracijsko testiranje, vježbe crvenog tima, vježbe otpornosti i ponovno testiranje trebaju činiti ciklus, a ne skup nepovezanih testova.

Točka 6.2 iste politike uređuje sigurnu provedbu:

Opseg i pravila angažmana: za svaki test ili vježbu STC mora definirati opseg, uključujući sustave i IP raspone u opsegu, dopuštene metode testiranja, ciljeve, vrijeme i trajanje. Pravila angažmana moraju biti dokumentirana. Na primjer, operativno osjetljivi sustavi mogu biti označeni samo za praćenje kako bi se izbjegao poremećaj, a svako testiranje u produkcijskom okruženju mora uključivati postupke povrata i zaustavljanja. Sigurnosne mjere, kao što su definirani vremenski prozori i komunikacijski kanali, moraju se uspostaviti kako bi se spriječili nenamjerni prekidi usluge.

To se izravno mapira na Zenith Blueprint, fazu Kontrole u praksi, korak 21, koji se usredotočuje na kontrolu 8.34 iz Priloga A ISO 27001, Zaštita informacijskih sustava tijekom revizijskog testiranja. Zenith Blueprint upozorava da revizije, penetracijska testiranja, forenzički pregledi i operativne evaluacije mogu uključivati povišena prava pristupa, intruzivne alate ili privremene promjene ponašanja sustava. Naglašava autorizaciju, opseg, vremenske prozore, odobrenje vlasnika sustava, povrat, praćenje i sigurno postupanje s testnim podacima.

Paket dokaza spreman za reviziju treba uključivati:

• TLPT povelju i ciljeve
• sažetak obavještajnih podataka o prijetnjama i obrazloženje scenarija
• kritične ili važne funkcije u opsegu
• sustave, IP raspone, identitete, dobavljače i okruženja u opsegu
• izuzeća i sustave samo za praćenje
• pravila angažmana
• procjenu rizika testiranja u produkcijskom okruženju
• postupke povrata i zaustavljanja
• model obavješćivanja SOC-a, uključujući što se otkriva, a što zadržava
• odobrenja pravnog odjela, privatnosti i dobavljača
• dokaze o stvaranju i ukidanju testnih računa
• sigurnu lokaciju pohrane za testne artefakte i zapise dnevnika

DORA TLPT koji ne može pokazati sigurnu autorizaciju i kontrolu testnih aktivnosti može otkriti praznine u otpornosti, ali istodobno stvara praznine u upravljanju.

Pretvorite TLPT izlaze u obradu rizika

Najčešći neuspjeh nakon testiranja jest problem izvješća crvenog tima koje završi na polici. Kvalitetno izvješće se isporuči, distribuira, raspravi i zatim postupno izgubi zamah. Nalazi ostaju otvoreni. Kompenzacijske kontrole nisu dokumentirane. Prihvaćeni rizici su neformalni. Ponovno testiranje se nikada ne provodi.

Politika sigurnosnog testiranja i vježbi crvenog tima čini to neprihvatljivim. Točka 6.6 navodi:

Otklanjanje nalaza: sve identificirane ranjivosti ili slabosti moraju se dokumentirati u izvješću o nalazima s ocjenama ozbiljnosti. Nakon zaprimanja izvješća vlasnici sustava odgovorni su za izradu plana korektivnih mjera s krajnjim rokovima; na primjer, kritični nalazi moraju se otkloniti u roku od 30 dana, a nalazi visoke ozbiljnosti u roku od 60 dana, u skladu s politikom organizacije za upravljanje ranjivostima i zakrpama. STC mora pratiti napredak korektivnih mjera. Ponovno testiranje mora se provesti kako bi se potvrdilo da su kritični problemi riješeni ili odgovarajuće ublaženi.

Točka 6.7 dodaje upravljački sloj:

Izvješćivanje: po završetku svakog testa mora se izdati formalno izvješće. Za penetracijsko testiranje izvješće mora uključivati sažetak za rukovodstvo, metodologiju i detaljne nalaze s pripadajućim dokazima i preporukama. Za vježbe crvenog tima izvješće mora detaljno opisati scenarije, koji su putovi napada bili uspješni, što je plavi tim otkrio i naučene lekcije o prazninama u otkrivanju i odgovoru. CISO mora predstaviti sažete rezultate i status korektivnih mjera višem rukovodstvu te ih, gdje je relevantno, uključiti u godišnje sigurnosno izvješće upravnom odboru.

To je usklađeno sa smjernicama ISO/IEC 27005:2022 za obradu rizika: odabrati opcije obrade, odrediti kontrole iz Priloga A ISO 27001 i sektorskih zahtjeva, izraditi plan obrade rizika, dodijeliti odgovorne osobe, definirati rokove, pratiti status, pribaviti odobrenje vlasnika rizika i dokumentirati prihvaćanje preostalog rizika.

Svaki značajan TLPT nalaz treba postati jedno od četiri: korektivna radnja, poboljšanje kontrole, formalno prihvaćanje rizika ili zahtjev za ponovno testiranje.

Cilj nije proizvesti više dokumenata. Cilj je da svaki dokument objasni sljedeću odluku.

Testiranje otpornosti mora dokazati oporavak, a ne samo otkrivanje

Uspješan TLPT može pokazati da je SOC otkrio command-and-control promet, blokirao lateralno kretanje i pravilno eskalirao. To je vrijedno, ali DORA testiranje otpornosti ide dalje. Pita može li organizacija nastaviti pružati poslovne usluge ili ih oporaviti.

Zenith Blueprint, faza Kontrole u praksi, korak 23, objašnjava kontrolu 5.30, IKT spremnost za neprekidnost poslovanja, jezikom koji bi svaki CISO trebao koristiti s upravnim odborom:

Iz perspektive revizije, ova se kontrola često testira jednom rečenicom: Pokažite mi. Pokažite mi posljednji rezultat testa. Pokažite mi dokumentaciju oporavka. Pokažite mi koliko je trajalo prebacivanje na pričuvni sustav i povratak. Pokažite mi dokaz da se ono što je obećano može isporučiti.

Taj standard “Pokažite mi” razlika je između zrelosti politike i operativne otpornosti.

Clarysecova Politika neprekidnosti poslovanja i oporavka od katastrofe za SME Politika neprekidnosti poslovanja i oporavka od katastrofe - SME, iz odjeljka “Zahtjevi za provedbu politike”, točka 6.4.1, navodi:

Organizacija mora testirati svoje BCP i DR sposobnosti najmanje jednom godišnje. Testovi moraju uključivati:

Odjeljak provedbe iste politike, točka 8.5.1, izričito utvrđuje odgovornost za dokaze:

GM mora osigurati da se sljedeće održava i bude spremno za reviziju:

Za financijski subjekt reguliran DORA, godišnje testiranje može biti donja granica, a ne ambicija. Kritične ili važne funkcije višeg rizika treba testirati češće, osobito nakon promjena arhitekture, migracije u oblak, većih incidenata, novih IKT dobavljača, značajnih izdanja aplikacija ili promjena izloženosti prijetnjama.

Snažan paket dokaza testiranja otpornosti treba uključivati:

• analizu utjecaja na poslovanje koja mapira kritičnu ili važnu funkciju
• RTO i RPO koje su odobrili vlasnici poslovanja
• mapu ovisnosti sustava, uključujući identitet, DNS, mrežu, oblak, bazu podataka, praćenje, sigurnosno kopiranje i usluge trećih strana
• rezultate testova sigurnosnog kopiranja i vraćanja podataka
• vremenske oznake prebacivanja na pričuvni sustav i povratka
• dokaze o radu sigurnosnih kontrola tijekom poremećaja
• predloške komunikacije prema klijentima, regulatoru i interno
• zapise sudjelovanja voditelja incidenta i kriznog tima
• naučene lekcije i aktivnosti poboljšanja
• dokaze ponovnog testiranja za prethodne praznine u oporavku

Ovdje u priču ulazi i GDPR. Članci 2 i 3 GDPR uvode većinu SaaS i fintech obrada osobnih podataka iz EU-a u opseg. Članak 4 definira osobne podatke, obradu, voditelja obrade, izvršitelja obrade i povredu podataka. Članak 5 zahtijeva cjelovitost, povjerljivost i odgovornost, što znači da organizacija mora moći dokazati usklađenost. Ako TLPT ili testiranje oporavka koristi produkcijske osobne podatke, kopira zapise dnevnika koji sadrže identifikatore ili provjerava odgovor na povredu, zaštitne mjere privatnosti moraju biti dokumentirane.

Dokazi dobavljača slijepa su točka DORA koju revizori neće zanemariti

Moderne financijske usluge sastavljene su od platformi u oblaku, SaaS aplikacija, pružatelja upravljane sigurnosti, procesora plaćanja, podatkovnih platformi, pružatelja identiteta, alata za opservabilnost, eksternaliziranih razvojnih timova i pružatelja sigurnosnog kopiranja.

Članak 28 DORA zahtijeva da financijski subjekti upravljaju rizikom IKT trećih strana kao dijelom okvira za upravljanje IKT rizicima i ostanu u potpunosti odgovorni čak i kada su IKT usluge eksternalizirane. Članak 30 zahtijeva pisane ugovore o IKT uslugama s opisima usluga, uvjetima podugovaranja, lokacijama obrade, zaštitom podataka, pristupom i oporavkom, razinama usluga, pomoći u incidentima, suradnjom s tijelima, pravima raskida, strožim uvjetima za kritične ili važne funkcije, pravima na reviziju, sigurnosnim mjerama, sudjelovanjem u TLPT-u gdje je relevantno i izlaznim aranžmanima.

To znači da TLPT scenarij ne može stati na vatrozidu organizacije ako kritična funkcija ovisi o dobavljaču.

Clarysecova Politika sigurnosti trećih strana i dobavljača za SME Politika sigurnosti trećih strana i dobavljača - SME, iz odjeljka “Zahtjevi za provedbu politike”, točka 6.3.1, navodi:

Kritični ili visokorizični dobavljači moraju se pregledavati najmanje jednom godišnje. Pregled mora provjeriti:

Politika sigurnosnog testiranja i vježbi crvenog tima dodaje zahtjev za dobavljače specifičan za testiranje u točki 6.9:

Koordinacija testiranja trećih strana: kada bilo koji kritični dobavljač ili pružatelj usluga ulazi u opseg ukupne sigurnosti organizacije, u skladu s Politikom sigurnosti trećih strana i dobavljača, organizacija mora, gdje je izvedivo, pribaviti potvrdu o njihovim praksama sigurnosnog testiranja ili koordinirati zajedničko testiranje. Na primjer, kada se koristi pružatelj usluga u oblaku (CSP), organizacija se može osloniti na njegova izvješća o penetracijskom testiranju ili ga uključiti u zajedničke scenarije crvenog tima, ovisno o ugovornim odredbama.

Za DORA dokaze spremne za reviziju atestacije dobavljača trebaju biti povezane s istim scenarijem rizika kao TLPT. Ako je pružatelj identiteta ključan za oporavak plaćanja, paket dokaza treba uključivati dubinsku analizu dobavljača, ugovorne sigurnosne zahtjeve, uvjete podrške za incidente, koordinaciju testiranja, atestacijska izvješća, dokaze o razini usluge, izlaznu strategiju i ograničenja testiranja.

Članak 21 NIS2 također je važan za SaaS, oblak, upravljane usluge, upravljanu sigurnost, podatkovne centre, CDN, usluge povjerenja, DNS, TLD, internetske tržnice, pretraživanje i pružatelje društvenih mreža. Zahtijeva pristup svim opasnostima koji obuhvaća analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, siguran razvoj, procjenu učinkovitosti, obuku, kriptografiju, kontrolu pristupa, upravljanje imovinom, MFA i sigurne komunikacije.

Praktičan je rezultat jednostavan: financijski subjekti trebaju izgraditi jedan model dokaza koji najprije zadovoljava DORA, a zatim unakrsno referencirati očekivanja NIS2 gdje su uključeni dobavljači, grupni subjekti ili nefinancijske digitalne usluge.

Praktičan Clarysec TLPT registar dokaza

Pretpostavimo da je scenarij:

“Akter prijetnje kompromitira administratorski račun na SaaS platformi za podršku, prelazi u okruženje platnih operacija, mijenja konfiguraciju i prekida obradu transakcija.”

Izradite registar dokaza s jednim retkom po dokaznom objektu. Ne čekajte kraj testa. Popunjavajte ga tijekom planiranja, provedbe, korektivnih mjera i zatvaranja.

Zatim upotrijebite Zenith Blueprint korak 13 za dodavanje sljedivosti u registar rizika i Izjavu o primjenjivosti. Svaka stavka dokaza treba se povezati sa scenarijem rizika, vlasnikom rizika, odabranom kontrolom, planom obrade rizika i odlukom o preostalom riziku.

Ako se nalaz odnosi na softversku slabost, navedite kontrole sigurnog razvoja i testiranja. Clarysecova Politika sigurnog razvoja za SME Politika sigurnog razvoja - SME, iz odjeljka “Zahtjevi za provedbu politike”, točka 6.5.2, zahtijeva:

Testiranje mora biti dokumentirano s:

Ako nalaz proizvede forenzički materijal, očuvajte lanac čuvanja dokaza. Clarysecova Politika prikupljanja dokaza i forenzike za SME Politika prikupljanja dokaza i forenzike - SME, iz odjeljka “Zahtjevi upravljanja”, točka 5.2.1, navodi:

Svaka stavka digitalnih dokaza mora se evidentirati s:

To je točka koju mnogi timovi propuštaju. Dokazi nisu samo završna izvješća. To je kontrolirani zapis o tome tko je odobrio, tko je proveo, što se dogodilo, što je otkriveno, što je oporavljeno, što je promijenjeno, što ostaje izloženo i tko je prihvatio tu izloženost.

Kako revizori pregledavaju iste TLPT dokaze

DORA TLPT dokazi čitat će se različito ovisno o profilu revizora. Clarysec oblikuje pakete dokaza tako da svaka perspektiva može pronaći ono što joj treba bez prisiljavanja timova na dupliciranje rada.

COBIT 2019 pojavljuje se u referenci za međusobno mapiranje usklađenosti u Zenith Blueprint za sigurnu provedbu revizije i testiranja, uključujući DSS05.03 i MEA03.04. Važnost nije u tome da COBIT zamjenjuje DORA ili ISO 27001, nego u tome da će stručnjaci za provjeru u ISACA stilu tražiti kontroliranu provedbu, praćenje, evaluaciju i dokaze usklađenosti.

Narativ za upravni odbor: što uprava mora odobriti

Izvješćivanje upravnom odboru treba izbjegavati tehnički teatar. Upravnom odboru nisu potrebni exploit payloadi. Potrebni su mu dokazi za donošenje odluka:

• Koja je kritična ili važna funkcija testirana?
• Koji je scenarij prijetnje simuliran i zašto?
• Je li otkrivanje funkcioniralo?
• Je li eskalacija odgovora funkcionirala?
• Je li oporavak zadovoljio RTO i RPO?
• Koji su dobavljači bili uključeni ili ograničeni?
• Koje značajne slabosti ostaju?
• Koliki su trošak korektivnih mjera, vlasnik i rok?
• Koji preostali rizici zahtijevaju formalno prihvaćanje?
• Što će se ponovno testirati?

Ovdje ISO 27001 točka 5 postaje važna. Najviše rukovodstvo mora osigurati da su politika informacijske sigurnosti i ciljevi uspostavljeni, usklađeni sa strateškim smjerom, integrirani u poslovne procese, resursno podržani, komunicirani i kontinuirano poboljšavani. Uloge i odgovornosti moraju biti dodijeljene. Ciljevi moraju biti mjerljivi gdje je izvedivo i uzeti u obzir primjenjive zahtjeve i rezultate obrade rizika.

Ako TLPT utvrdi da je vrijeme oporavka šest sati u odnosu na poslovnu toleranciju od četiri sata, to nije samo stavka u zaostatku poslova infrastrukture. To je upravljačka odluka koja uključuje apetit za rizik, proračun, obveze prema klijentima, regulatornu izloženost, ugovore, arhitekturu i operativni kapacitet.

Česti neuspjesi dokaza u DORA testiranju otpornosti

Clarysec pregledi često pronalaze iste praznine u dokazima kod financijskih subjekata i pružatelja IKT usluga koji se pripremaju za DORA.

Prvo, opseg TLPT-a ne mapira se na kritične ili važne funkcije. Test može biti tehnički impresivan, ali ne dokazuje otpornost poslovnog procesa koji je važan regulatorima.

Drugo, ovisnosti o dobavljačima se priznaju, ali nisu potkrijepljene dokazima. Timovi kažu da su pružatelj usluga u oblaku, upravljani SOC ili SaaS platforma u opsegu, ali nedostaju ugovori, prava na reviziju, dopuštenja za testiranje, uvjeti podrške za incidente i izlazni planovi.

Treće, testiranje stvara dokaze, ali ne i obradu rizika. Nalazi ostaju u izvješću crvenog tima umjesto da se pretvore u ažuriranja registra rizika, promjene kontrola, vlasnike, datume, ponovno testiranje i odluke o preostalom riziku.

Četvrto, oporavak se pretpostavlja umjesto da se dokazuje. Politike sigurnosnog kopiranja postoje, ali nitko ne može pokazati vremenske oznake prebacivanja na pričuvni sustav, provjere cjelovitosti vraćanja, provjeru prava pristupa ili potvrdu poslovnog vlasnika.

Peto, privatnost i forenzički dokazi nisu kontrolirani. Zapisi dnevnika i snimke zaslona sadrže osobne podatke, testni artefakti pohranjeni su na dijeljenim diskovima, privremeni računi ostaju aktivni, a lanac čuvanja dokaza je nepotpun.

Šesto, izvješćivanje upravi previše je tehničko. Više rukovodstvo ne može vidjeti je li se otpornost poboljšala, je li rizik unutar apetita za rizik ili koje su investicijske odluke potrebne.

Svaka od tih praznina može se riješiti tretiranjem DORA TLPT-a kao strukturiranog ISO 27001 tijeka rada s dokazima.

Clarysecov integrirani pristup otpornosti spremnoj za reviziju

Clarysecov pristup kombinira tri sloja.

Prvi sloj je Zenith Blueprint, 30-koračni plan implementacije. Za ovu temu korak 13 gradi sljedivost obrade rizika i SoA, korak 21 štiti sustave tijekom revizijskog testiranja, a korak 23 provjerava IKT spremnost za neprekidnost poslovanja. Ti koraci pretvaraju TLPT iz tehničkog događaja u dokumentirani ciklus upravljanja.

Drugi sloj je Clarysecova biblioteka politika. Politika sigurnosnog testiranja i vježbi crvenog tima definira vrste testiranja, opseg, pravila angažmana, korektivne mjere, izvješćivanje i koordinaciju s dobavljačima. Politika neprekidnosti poslovanja i oporavka od katastrofe za SME postavlja očekivanja za godišnje BCP i DR testiranje i dokaze neprekidnosti poslovanja spremne za reviziju. Politika sigurnosti trećih strana i dobavljača za SME podržava atestacije dobavljača. Politika sigurnog razvoja za SME osigurava da je sigurnosno testiranje dokumentirano. Politika prikupljanja dokaza i forenzike za SME podržava evidentiranje dokaza i disciplinu lanca čuvanja dokaza.

Treći sloj je Zenith Controls, Clarysecov vodič za međusobno mapiranje usklađenosti. Pomaže mapirati ISO/IEC 27002:2022 kontrole na atribute, domene, operativne sposobnosti i očekivanja različitih okvira. Za DORA TLPT najvažniji obrazac nije jedna kontrola. To je odnos između testiranja, neprekidnosti poslovanja, upravljanja incidentima, upravljanja dobavljačima, zapisivanja događaja, praćenja, sigurnog razvoja, neovisnog pregleda i upravljanja.

Kada ti slojevi rade zajedno, CISO-ov ponedjeljak ujutro izgleda drugačije. Umjesto tri nepovezana pitanja upravnog odbora, regulatora i interne revizije, organizacija ima jednu dokaznu priču:

“Identificirali smo kritičnu funkciju. Procijenili smo IKT rizik. Odabrali smo i obrazložili kontrole. Odobrili smo i sigurno proveli TLPT. Otkrili smo, odgovorili i oporavili se. Uključili smo dobavljače gdje je bilo potrebno. Dokumentirali smo dokaze. Otklonili smo nalaze. Ponovno smo testirali. Uprava je pregledala i prihvatila preostali rizik.”

To je otpornost spremna za reviziju.

Sljedeći koraci

Ako je vaš DORA TLPT program još uvijek organiziran oko izvješća umjesto oko dokaznih lanaca, započnite s Clarysec pregledom dokaza.

Upotrijebite Zenith Blueprint Zenith Blueprint korak 13 za povezivanje TLPT scenarija s rizicima, kontrolama i Izjavom o primjenjivosti. Upotrijebite korak 21 za provjeru sigurne autorizacije, pravila angažmana, povrata, praćenja i čišćenja. Upotrijebite korak 23 za dokazivanje IKT spremnosti za neprekidnost poslovanja dokazima oporavka.

Zatim uskladite svoje operativne dokumente s Clarysecovom Politikom sigurnosnog testiranja i vježbi crvenog tima Politika sigurnosnog testiranja i red-teaminga, Politikom neprekidnosti poslovanja i oporavka od katastrofe za SME Politika neprekidnosti poslovanja i oporavka od katastrofe - SME, Politikom sigurnosti trećih strana i dobavljača za SME Politika sigurnosti trećih strana i dobavljača - SME, Politikom sigurnog razvoja za SME Politika sigurnog razvoja - SME i Politikom prikupljanja dokaza i forenzike za SME Politika prikupljanja dokaza i forenzike - SME.

Na kraju upotrijebite Zenith Controls Zenith Controls za unakrsno mapiranje DORA TLPT dokaza na ISO 27001 kontrole, NIS2, GDPR, COBIT 2019 i očekivanja revizora.

Ako želite da vaš sljedeći test otpornosti proizvede više od nalaza, upotrijebite Clarysec kako biste ga pretvorili u dokaziv dokazni lanac. Preuzmite alate, zakažite procjenu spremnosti dokaza ili zatražite pregled načina na koji Clarysec mapira DORA TLPT na ISO 27001:2022 kontrole od planiranja do odobrenja upravnog odbora.