Dokazila za DORA TLPT s kontrolami ISO 27001

Ponedeljek je, 07:40 zjutraj, in CISO srednje velike plačilne institucije gleda tri različice istega neprijetnega vprašanja.

Organ upravljanja želi vedeti, ali lahko organizacija preživi izpad portala za plačila strank, ki ga povzroči izsiljevalska programska oprema. Regulator želi dokaz, da preizkušanje digitalne operativne odpornosti ni vaja v PowerPointu. Notranja revizija želi jasno sled od zahtev DORA do tveganj IKT, kontrol ISO 27001, rezultatov testiranja, načrtov odprave pomanjkljivosti, dokazil dobaviteljev in odobritve vodstva.

CISO ima poročilo Red Team. SOC ima posnetke zaslona opozoril. Infrastrukturna ekipa ima dnevnik obnovitve varnostne kopije. Pravna služba ima sledilnik pripravljenosti na DORA. Nabava ima potrdila ponudnika storitev v oblaku.

Nič od tega ni povezano.

Tu odpove veliko programov DORA TLPT in preizkušanja odpornosti. Ne zato, ker bi bilo testiranje šibko, temveč zato, ker so dokazila razdrobljena. Ko presojevalec vpraša: “Pokažite mi, kako ta preizkus dokazuje odpornost kritične ali pomembne funkcije,” odgovor ne more biti mapa, polna posnetkov zaslona. Biti mora zagovorljiva dokazna veriga.

Prav pri tej verigi postane ISMS, usklajen z ISO/IEC 27001:2022 ISO/IEC 27001:2022, zares uporaben. ISO 27001 daje strukturo obsegu, oceni tveganj, izbiri kontrol, Izjavi o uporabljivosti, operativnemu nadzoru, notranji presoji, vodstvenemu pregledu in nenehnemu izboljševanju. DORA dodaja sektorsko specifičen regulativni pritisk. Metodologija Clarysec in orodja za navzkrižno skladnost oboje povežejo v enoten model dokazil, pripravljen za presojo.

DORA TLPT je preizkus upravljanja, ne le simulacija napada

Penetracijsko testiranje na podlagi groženj oziroma TLPT je mogoče zlahka napačno razumeti. Tehnično je lahko videti kot napredna vaja Red Team: obveščevalni podatki o grožnjah, realistične poti napada, prikrito delovanje, poskusi izkoriščanja, scenariji lateralnega premikanja in preverjanje odziva Blue Team.

Pri DORA je globlje vprašanje digitalna operativna odpornost. Ali lahko finančni subjekt vzdrži resno motnjo IKT, ki vpliva na poslovne procese, se nanjo odzove in po njej obnovi delovanje? Ali lahko dokaže, da kritične ali pomembne funkcije ostajajo znotraj toleranc vpliva? Ali lahko vodstvo izkaže, da se tveganja IKT upravljajo, financirajo, testirajo, odpravljajo in izboljšujejo?

Člen 1 DORA vzpostavlja enoten okvir EU za varnost omrežnih in informacijskih sistemov, ki podpirajo poslovne procese finančnih subjektov. Zajema upravljanje tveganj IKT, poročanje o večjih incidentih, povezanih z IKT, preizkušanje digitalne operativne odpornosti, upravljanje tveganj tretjih oseb na področju IKT, obvezne pogodbene zahteve za dobavitelje IKT, nadzor nad kritičnimi tretjimi ponudniki storitev IKT in sodelovanje nadzornih organov. DORA se uporablja od 17. januarja 2025.

Za organizacije, ki jih zajema tudi NIS2, DORA deluje kot sektorsko specifičen pravni akt Unije za prekrivajoče se zahteve kibernetske varnosti. V praksi morajo finančni subjekti dati prednost DORA za upravljanje tveganj IKT, poročanje o incidentih, testiranje in tveganja tretjih oseb na področju IKT, kadar se režima prekrivata, hkrati pa še vedno razumeti pričakovanja NIS2 glede skupinskih struktur, dobaviteljev in nefinančnih digitalnih storitev.

DORA odgovornost postavlja tudi na vrh organizacije. Člen 5 zahteva, da organ upravljanja opredeli, odobri, nadzoruje in izvaja ureditve za tveganja IKT. To vključuje strategijo digitalne operativne odpornosti, politiko neprekinjenega poslovanja IKT, načrte odziva in obnovitve, načrte presoj, proračune, politike za tretje osebe na področju IKT, kanale poročanja ter zadostno znanje o tveganjih IKT z rednim usposabljanjem.

Zato revizijsko vprašanje ni zgolj: “Ali ste izvedli TLPT?”

Vprašanja so:

• Ali je bil TLPT povezan s kritičnimi ali pomembnimi funkcijami?
• Ali je bil odobren, ustrezno opredeljen po obsegu, varen in predmet ocene tveganja?
• Ali so bili vključeni dobavitelji, odvisnosti od oblaka in zunanje izvajane storitve IKT, kjer je bilo to relevantno?
• Ali je test ustvaril dokazila o zaznavi, odzivu, obnovitvi in pridobljenih izkušnjah?
• Ali so bile ugotovitve pretvorjene v obravnavo tveganja, spremljano odpravo pomanjkljivosti, ponovno testiranje in poročanje vodstvu?
• Ali je Izjava o uporabljivosti pojasnila, katere kontrole iz Priloge A ISO 27001 so bile izbrane za obvladovanje tveganja?

Zato Clarysec dokazila za DORA TLPT obravnava kot vprašanje dokazil ISMS, ne le kot rezultat penetracijskega testiranja.

Pred začetkom testa zgradite dokazno hrbtenico ISO 27001

ISO 27001 zahteva, da organizacija vzpostavi, uvede, vzdržuje in nenehno izboljšuje ISMS, ki z uporabo procesa obvladovanja tveganj varuje zaupnost, celovitost in razpoložljivost. Točke 4.1 do 4.4 zahtevajo, da organizacija razume notranje in zunanje dejavnike, zainteresirane strani, zakonske in regulativne obveznosti, vmesnike, odvisnosti ter nato dokumentira obseg ISMS.

Za subjekt, reguliran z DORA, mora ta korak določanja obsega izrecno zajeti kritične ali pomembne funkcije, sredstva IKT, oblačne platforme, zunanje izvajane operacije, plačilne sisteme, portale za stranke, storitve identitet, platforme za beleženje, okolja za obnovitev in tretje ponudnike storitev IKT. Če se obseg TLPT ne preslika nazaj na obseg ISMS, je revizijska sled že šibka.

Točke 6.1.1, 6.1.2 in 6.1.3 ISO 27001 skupaj s točkama 8.2 in 8.3 zahtevajo proces ocenjevanja tveganj in obravnave tveganj. Tveganja je treba identificirati glede na zaupnost, celovitost in razpoložljivost. Določiti je treba lastnike tveganj. Oceniti je treba verjetnost in posledice. Kontrole je treba izbrati in primerjati s Prilogo A. Preostalo tveganje morajo sprejeti lastniki tveganj.

To je most med DORA in testiranjem, pripravljenim za presojo.

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint v fazi upravljanja tveganj, korak 13, jasno opisuje to vlogo sledljivosti:

SoA je dejansko povezovalni dokument: povezuje vašo oceno/obravnavo tveganj z dejanskimi kontrolami, ki jih imate. Ko ga izpolnite, hkrati še enkrat preverite, ali ste katero kontrolo spregledali.

Za DORA TLPT Izjava o uporabljivosti ne sme biti statičen certifikacijski artefakt. Pojasniti mora, zakaj so kontrole, kot so varnost dobaviteljev, upravljanje incidentov, pripravljenost IKT za neprekinjeno poslovanje, beleženje, spremljanje, upravljanje tehničnih ranljivosti, varnostne kopije, varen razvoj in varnostno testiranje, uporabne za scenarij odpornosti.

Praktičen scenarij tveganja bi se lahko glasil:

“Kompromitacija poverilnic privilegiranega ponudnika identitet napadalcu omogoči dostop do administrativnih sistemov za obdelavo plačil, spremembo konfiguracij usmerjanja in prekinitev kritične plačilne funkcije, kar povzroči izpad storitve, regulativne obveznosti poročanja, škodo strankam in škodo za ugled.”

Ta en scenarij lahko določa obseg TLPT, primere uporabe za zaznavanje, vključitev dobaviteljev, vajo obnovitve, poročanje organu upravljanja in nabor dokazil.

Zenith Blueprint priporoča tudi izrecno regulativno sledljivost:

Navzkrižno sklicevanje na predpise: če so določene kontrole uvedene posebej zaradi skladnosti z GDPR, NIS2 ali DORA, lahko to navedete bodisi v registru tveganj (kot del utemeljitve vpliva tveganja) bodisi v opombah SoA.

Nasvet je preprost, vendar spremeni revizijski pogovor. Namesto da organizacija presojevalcu pove, da je upoštevala DORA, lahko pokaže, kje se DORA pojavi v registru tveganj, SoA, programu testiranja, naboru politik in vodstvenem pregledu.

Preslikajte testiranje DORA na kontrole ISO 27001, ki jih presojevalci prepoznajo

Člen 6 DORA pričakuje dokumentiran okvir upravljanja tveganj IKT, integriran v celovito upravljanje tveganj. Priloga A ISO 27001 zagotavlja katalog kontrol, ki to pretvori v operativno prakso.

Za DORA TLPT in preizkušanje odpornosti so posebej pomembne naslednje kontrole iz Priloge A ISO/IEC 27001:2022:

Clarysecov Zenith Controls: The Cross-Compliance Guide Zenith Controls pomaga organizacijam preprečiti, da bi te kontrole obravnavale kot ločene postavke kontrolnega seznama. Kontrole ISO/IEC 27002:2022 preslika na atribute, področja, operativne zmogljivosti, revizijska pričakovanja in vzorce med okviri.

Na primer, Zenith Controls razvršča kontrolo ISO/IEC 27002:2022 5.30, pripravljenost IKT za neprekinjeno poslovanje, kot “korektivno”, usklajeno z “razpoložljivostjo”, povezano s konceptom kibernetske varnosti “odziv” in umeščeno v področje “odpornost”. Ta razvrstitev je uporabna pri pojasnjevanju presojevalcem, zakaj vaja obnovitve ni zgolj IT-operacija, temveč kontrola odpornosti z opredeljeno vlogo v kontrolnem okolju.

Zenith Controls tudi razvršča kontrolo 8.29, varnostno testiranje pri razvoju in prevzemu, kot preventivni kontrolni ukrep, ki podpira zaupnost, celovitost in razpoložljivost, z operativnimi zmogljivostmi na področju varnosti aplikacij, zagotavljanja informacijske varnosti ter varnosti sistemov in omrežij. Pri ugotovitvah TLPT, ki izhajajo iz slabosti zasnove aplikacije, neustreznega vedenja API, šibkega toka avtentikacije ali nezadostnega preverjanja, je to kontrolna pot v upravljanje varnega razvoja.

Pomembna je tudi kontrola 5.35, neodvisni pregled informacijske varnosti. Podpira neodvisno preverjanje, zagotovilo upravljanja in korektivno izboljševanje. Notranje ekipe lahko usklajujejo testiranje, vendar dokazila, pripravljena za presojo, zahtevajo pregled, eskalacijo in nadzor zunaj oseb, ki so testirane sisteme zgradile ali upravljale.

Med testiranjem zaščitite sistem

Nevarna predpostavka pri preizkušanju odpornosti je, da je testiranje samo po sebi vedno koristno. V resnici lahko invazivno testiranje povzroči izpade, razkrije občutljive podatke, onesnaži dnevnike, sproži avtomatizirane obrambne mehanizme, prekine seje strank ali povzroči, da dobavitelji aktivirajo postopke za nujne primere.

Clarysecova Politika varnostnega testiranja in vaj Red Team Politika varnostnega testiranja in vaj Red Team organizacijam daje model upravljanja za varno izvedbo. Točka 6.1 določa:

Vrste testov: program varnostnega testiranja mora vključevati najmanj: (a) skeniranje ranljivosti, ki obsega avtomatizirana tedenska ali mesečna skeniranja omrežij in aplikacij za identifikacijo znanih ranljivosti; (b) penetracijsko testiranje, ki obsega ročno poglobljeno testiranje določenih sistemov ali aplikacij s strani usposobljenih preizkuševalcev za identifikacijo kompleksnih slabosti; in (c) vaje red team, ki obsegajo simulacije dejanskih napadov na podlagi scenarijev, vključno s socialnim inženiringom ter drugimi taktikami, za testiranje zmožnosti organizacije za zaznavanje in odzivanje kot celote.

Pri TLPT je element Red Team očiten, vendar revizijska vrednost izhaja iz zasnove programa. Skeniranje ranljivosti, penetracijsko testiranje, vaje Red Team, vaje odpornosti in ponovno testiranje morajo tvoriti cikel, ne zbirko nepovezanih testov.

Točka 6.2 iste politike obravnava varno izvedbo:

Obseg in pravila izvajanja: za vsak test ali vajo mora STC opredeliti obseg, vključno s sistemi in razponi IP v obsegu, dovoljenimi metodami testiranja, cilji, časom in trajanjem. Pravila izvajanja morajo biti dokumentirana. Operativno občutljivi sistemi so lahko na primer označeni kot sistemi samo za spremljanje, da se prepreči motnja, vsako testiranje v produkciji pa mora vključevati postopke povrnitve in ustavitve. Za preprečitev nenamernih izpadov storitev je treba vzpostaviti varnostne ukrepe, kot so določena časovna okna in komunikacijski kanali.

To se neposredno preslika na Zenith Blueprint, fazo Controls in Action, korak 21, ki se osredotoča na kontrolo 8.34 iz Priloge A ISO 27001, zaščito informacijskih sistemov med revizijskim testiranjem. Zenith Blueprint opozarja, da lahko revizije, penetracijski testi, forenzični pregledi in operativna ocenjevanja vključujejo povišan dostop, invazivna orodja ali začasne spremembe vedenja sistema. Poudarja odobritev, obseg, časovna okna, odobritev lastnika sistema, povrnitev, spremljanje in varno ravnanje s testnimi podatki.

Sveženj dokazil, pripravljen za presojo, mora vključevati:

• listino TLPT in cilje;
• povzetek obveščevalnih podatkov o grožnjah in utemeljitev scenarija;
• kritične ali pomembne funkcije v obsegu;
• sisteme, razpone IP, identitete, dobavitelje in okolja v obsegu;
• izključitve in sisteme samo za spremljanje;
• pravila izvajanja;
• oceno tveganja testiranja v produkciji;
• postopke povrnitve in ustavitve;
• model obveščanja SOC, vključno s tem, kaj se razkrije in kaj zadrži;
• pravne odobritve, odobritve glede zasebnosti in odobritve dobaviteljev;
• dokazila o ustvarjanju in preklicu testnih računov;
• varno lokacijo hrambe za testne artefakte in dnevnike.

DORA TLPT, ki ne more pokazati varne odobritve in nadzora testnih dejavnosti, lahko razkrije vrzeli odpornosti, vendar hkrati ustvarja vrzeli v upravljanju.

Pretvorite izhod TLPT v obravnavo tveganj

Najpogostejša napaka po testiranju je problem poročila Red Team, ki obleži na polici. Kakovostno poročilo je predano, razposlano, obravnavano, nato pa postopoma izgubi zagon. Ugotovitve ostanejo odprte. Kompenzacijske kontrole niso dokumentirane. Sprejeta tveganja so neformalna. Ponovno testiranje se nikoli ne izvede.

Politika varnostnega testiranja in vaj Red Team to izrecno preprečuje. Točka 6.6 določa:

Odprava ugotovitev: vse identificirane ranljivosti ali slabosti morajo biti dokumentirane v poročilu o ugotovitvah z ocenami resnosti. Po prejemu poročila so lastniki sistemov odgovorni za pripravo načrta odprave pomanjkljivosti z roki; kritične ugotovitve je treba na primer odpraviti v 30 dneh, ugotovitve visoke resnosti pa v 60 dneh, skladno s politiko organizacije za upravljanje ranljivosti in popravkov. STC mora spremljati napredek odprave pomanjkljivosti. Ponovno testiranje je treba izvesti, da se potrdi, da so kritične težave odpravljene ali ustrezno ublažene.

Točka 6.7 dodaja plast upravljanja:

Poročanje: ob zaključku vsakega testa mora biti izdano formalno poročilo. Pri penetracijskem testiranju mora poročilo vključevati povzetek za vodstvo, metodologijo in podrobne ugotovitve s podpornimi dokazili in priporočili. Pri vajah red team mora poročilo podrobno opisati scenarije, katere poti napada so bile uspešne, kaj je zaznala Blue Team in pridobljene izkušnje glede vrzeli pri zaznavanju in odzivanju. CISO mora povzetek rezultatov in status odprave pomanjkljivosti predstaviti višjemu vodstvu ter jih, kjer je relevantno, vključiti v letno varnostno poročilo upravnemu odboru.

To je skladno z usmeritvami ISO/IEC 27005:2022 za obravnavo tveganj: izbrati možnosti obravnave, določiti kontrole iz Priloge A ISO 27001 in sektorsko specifičnih zahtev, pripraviti načrt obravnave tveganja, določiti odgovorne osebe, opredeliti časovne roke, spremljati status, pridobiti odobritev lastnika tveganja in dokumentirati sprejem preostalega tveganja.

Vsaka pomembna ugotovitev TLPT mora postati ena od štirih stvari: sanacijski ukrep, izboljšava kontrole, formalni sprejem tveganja ali zahteva za ponovno testiranje.

Cilj ni ustvariti več dokumentov. Cilj je, da vsak dokument pojasni naslednjo odločitev.

Preizkušanje odpornosti mora dokazati obnovitev, ne le zaznavanje

Uspešen TLPT lahko pokaže, da je SOC zaznal promet ukazovanja in nadzora, blokiral lateralno premikanje in pravilno eskaliral. To je dragoceno, vendar preizkušanje odpornosti po DORA zahteva več. Sprašuje, ali lahko organizacija nadaljuje ali obnovi poslovne storitve.

Zenith Blueprint, faza Controls in Action, korak 23, razlaga kontrolo 5.30, pripravljenost IKT za neprekinjeno poslovanje, z izrazom, ki bi ga moral vsak CISO uporabljati z organom upravljanja:

Z vidika revizije se ta kontrola pogosto preverja z enim samim stavkom: Pokažite mi. Pokažite mi zadnji rezultat testa. Pokažite mi dokumentacijo obnovitve. Pokažite mi, koliko časa je trajal preklop na rezervno okolje in nazaj. Pokažite mi dokazila, da je mogoče izpolniti obljubljeno.

Ta standard “Pokažite mi” je razlika med zrelostjo politike in operativno odpornostjo.

Clarysecova Politika neprekinjenega poslovanja in obnovitve po nesreči za MSP Politika neprekinjenega poslovanja in obnovitve po nesreči - MSP v razdelku “Zahteve za izvajanje politike”, točka 6.4.1, določa:

Organizacija mora vsaj enkrat letno testirati zmožnosti svojega BCP in DR. Testi morajo vključevati:

Razdelek o izvajanju iste politike, točka 8.5.1, izrecno določa odgovornost za dokazila:

GM mora zagotoviti, da se naslednje evidence vzdržujejo in so pripravljene za revizijo:

Za finančni subjekt, reguliran z DORA, je letno testiranje lahko spodnja meja, ne cilj. Kritične ali pomembne funkcije z višjim tveganjem je treba testirati pogosteje, zlasti po spremembah arhitekture, migraciji v oblak, večjih incidentih, novih dobaviteljih IKT, pomembnih izdajah aplikacij ali spremembah izpostavljenosti grožnjam.

Močan sveženj dokazil preizkušanja odpornosti mora vključevati:

• analizo vpliva na poslovanje, ki preslika kritično ali pomembno funkcijo;
• RTO in RPO, ki ju odobrijo lastniki poslovnih procesov;
• zemljevid odvisnosti sistemov, vključno z identiteto, DNS, omrežjem, oblakom, podatkovno bazo, spremljanjem, varnostnim kopiranjem in storitvami tretjih oseb;
• rezultate testov varnostnega kopiranja in obnove;
• časovne žige preklopa na rezervno okolje in povratka;
• dokazila o delovanju varnostnih kontrol med motnjo;
• predloge komunikacije s strankami, regulatorjem in interno komunikacijo;
• dnevnike sodelovanja vodje incidenta in krizne ekipe;
• pridobljene izkušnje in ukrepe za izboljšanje;
• dokazila ponovnega testiranja za prejšnje vrzeli pri obnovitvi.

Tu v zgodbo vstopi tudi GDPR. Člena 2 in 3 GDPR vključujeta večino obdelav osebnih podatkov EU v SaaS in fintech v področje uporabe. Člen 4 opredeljuje osebne podatke, obdelavo, upravljavca, obdelovalca in kršitev varnosti osebnih podatkov. Člen 5 zahteva celovitost, zaupnost in odgovornost, kar pomeni, da mora biti organizacija zmožna dokazati skladnost. Če TLPT ali testiranje obnovitve uporablja produkcijske osebne podatke, kopira dnevnike z identifikatorji ali preverja odziv na kršitev, morajo biti dokumentirani zaščitni ukrepi za zasebnost.

Dokazila dobaviteljev so slepa pega DORA, ki je presojevalci ne bodo spregledali

Sodobne finančne storitve so sestavljene iz oblačnih platform, aplikacij SaaS, ponudnikov upravljane varnosti, procesorjev plačil, podatkovnih platform, ponudnikov identitet, orodij za opazljivost, ekip za zunanji razvoj in ponudnikov varnostnega kopiranja.

Člen 28 DORA zahteva, da finančni subjekti upravljajo tveganja tretjih oseb na področju IKT kot del okvira upravljanja tveganj IKT in ostanejo v celoti odgovorni tudi, kadar so storitve IKT zunanje izvajane. Člen 30 zahteva pisne pogodbe o storitvah IKT z opisi storitev, pogoji podizvajanja, lokacijami obdelave, varstvom podatkov, dostopom in obnovitvijo, ravnmi storitev, pomočjo pri incidentih, sodelovanjem z organi, pravicami do odpovedi, strožjimi določili za kritične ali pomembne funkcije, pravicami do revizije, varnostnimi ukrepi, sodelovanjem pri TLPT, kjer je relevantno, in izstopnimi ureditvami.

To pomeni, da se scenarij TLPT ne more ustaviti pri požarnem zidu organizacije, če je kritična funkcija odvisna od dobavitelja.

Clarysecova Politika varnosti tretjih oseb in dobaviteljev za MSP Politika varnosti tretjih oseb in dobaviteljev - MSP v razdelku “Zahteve za izvajanje politike”, točka 6.3.1, določa:

Kritične dobavitelje ali dobavitelje z visokim tveganjem je treba pregledati vsaj enkrat letno. Pregled mora preveriti:

Politika varnostnega testiranja in vaj Red Team v točki 6.9 dodaja zahtevo za dobavitelje, specifično za testiranje:

Usklajevanje testiranja s tretjimi osebami: kadar je kateri koli kritični dobavitelj ali ponudnik storitev v obsegu celovite varnosti organizacije, mora organizacija skladno s politiko varnosti tretjih oseb in dobaviteljev, kjer je izvedljivo, pridobiti zagotovilo glede njihovih praks varnostnega testiranja ali uskladiti skupno testiranje. Kadar se na primer uporablja Cloud Service Provider (CSP), se lahko organizacija opre na njegova poročila o penetracijskem testiranju ali ga vključi v sodelovalne scenarije red team, ob upoštevanju pogodbenih določil.

Za dokazila DORA, pripravljena za presojo, morajo biti zagotovila dobaviteljev povezana z istim scenarijem tveganja kot TLPT. Če je ponudnik identitet ključen za obnovitev plačil, mora sveženj dokazil vključevati skrbni pregled dobavitelja, pogodbene varnostne zahteve, pogoje podpore pri incidentih, usklajevanje testiranja, poročila o zagotovilih, dokazila o ravni storitev, izstopno strategijo in omejitve testiranja.

Člen 21 NIS2 je pomemben tudi za ponudnike SaaS, oblaka, upravljanih storitev, upravljane varnosti, podatkovnih centrov, CDN, storitev zaupanja, DNS, TLD, spletnih tržnic, iskalnikov in družbenih omrežij. Zahteva pristop za vse vrste nevarnosti, ki zajema analizo tveganj, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varen razvoj, oceno učinkovitosti, usposabljanje, kriptografijo, nadzor dostopa, upravljanje sredstev, MFA in varne komunikacije.

Praktični rezultat je preprost: finančni subjekti morajo zgraditi en model dokazil, ki najprej zadosti DORA, nato pa navzkrižno sklicuje pričakovanja NIS2, kadar so vključeni dobavitelji, subjekti v skupini ali nefinančne digitalne storitve.

Praktična evidenca dokazil Clarysec za TLPT

Predpostavimo naslednji scenarij:

“Akter grožnje kompromitira administratorski račun na podporni platformi SaaS, se premakne v okolje plačilnih operacij, spremeni konfiguracijo in prekine obdelavo transakcij.”

Ustvarite evidenco dokazil z eno vrstico za vsak dokazni predmet. Ne čakajte do konca testa. Dopolnjujte jo med načrtovanjem, izvedbo, odpravo pomanjkljivosti in zaključkom.

Nato uporabite Zenith Blueprint korak 13 za dodajanje sledljivosti v register tveganj in Izjavo o uporabljivosti. Vsak dokazni element mora biti povezan s scenarijem tveganja, lastnikom tveganja, izbrano kontrolo, načrtom obravnave tveganja in odločitvijo o preostalem tveganju.

Če se ugotovitev nanaša na slabost programske opreme, navedite kontrole varnega razvoja in testiranja. Clarysecova Politika varnega razvoja za MSP Politika varnega razvoja - MSP v razdelku “Zahteve za izvajanje politike”, točka 6.5.2, zahteva:

Testiranje mora biti dokumentirano z:

Če ugotovitev ustvari forenzično gradivo, ohranite verigo skrbništva. Clarysecova Politika zbiranja dokazov in forenzike za MSP Politika zbiranja dokazov in forenzike - MSP v razdelku “Zahteve upravljanja”, točka 5.2.1, določa:

Vsak element digitalnih dokazov mora biti zabeležen z:

To je točka, ki jo številne ekipe spregledajo. Dokazila niso samo končna poročila. So nadzorovan zapis o tem, kdo je odobril, kdo je izvedel, kaj se je zgodilo, kaj je bilo zaznano, kaj je bilo obnovljeno, kaj je bilo spremenjeno, kaj ostaja izpostavljeno in kdo je to izpostavljenost sprejel.

Kako presojevalci pregledajo ista dokazila TLPT

Dokazila DORA TLPT se berejo različno glede na ozadje presojevalca. Clarysec oblikuje svežnje dokazil tako, da lahko vsak pogled najde, kar potrebuje, ne da bi morale ekipe podvajati delo.

COBIT 2019 se pojavi v referenci navzkrižne skladnosti Zenith Blueprint za varno izvedbo revizij in testiranja, vključno z DSS05.03 in MEA03.04. Pomen ni v tem, da COBIT nadomešča DORA ali ISO 27001, temveč v tem, da bodo strokovnjaki za zagotovila v slogu ISACA iskali nadzorovano izvedbo, spremljanje, vrednotenje in dokazila o skladnosti.

Pripoved za organ upravljanja: kaj mora odobriti vodstvo

Poročanje organu upravljanja se mora izogniti tehničnemu gledališču. Organ upravljanja ne potrebuje koristnih obremenitev izkoriščanja. Potrebuje dokazila za odločanje:

• Katera kritična ali pomembna funkcija je bila testirana?
• Kateri scenarij grožnje je bil simuliran in zakaj?
• Ali je zaznavanje delovalo?
• Ali je eskalacija odziva delovala?
• Ali je obnovitev dosegla RTO in RPO?
• Kateri dobavitelji so bili vključeni ali omejeni?
• Katere bistvene slabosti ostajajo?
• Kakšni so stroški odprave pomanjkljivosti, kdo je lastnik in kakšen je časovni načrt?
• Katera preostala tveganja zahtevajo formalni sprejem?
• Kaj bo ponovno testirano?

Tu postane pomembna točka 5 ISO 27001. Najvišje vodstvo mora zagotoviti, da so politika informacijske varnosti in cilji vzpostavljeni, usklajeni s strateško usmeritvijo, vključeni v poslovne procese, podprti z viri, komunicirani in nenehno izboljševani. Vloge in odgovornosti morajo biti dodeljene. Cilji morajo biti, kjer je izvedljivo, merljivi ter upoštevati veljavne zahteve in rezultate obravnave tveganj.

Če TLPT ugotovi, da je čas obnovitve šest ur ob štiriurni poslovni toleranci, to ni zgolj postavka v zaostanku nalog infrastrukture. To je odločitev vodstva, ki vključuje apetit po tveganju, proračun, zaveze strankam, regulativno izpostavljenost, pogodbe, arhitekturo in operativno zmogljivost.

Pogoste napake pri dokazilih v preizkušanju odpornosti po DORA

Clarysecovi pregledi pogosto odkrijejo iste vrzeli pri dokazilih pri finančnih subjektih in ponudnikih storitev IKT, ki se pripravljajo na DORA.

Prvič, obseg TLPT ni preslikan na kritične ali pomembne funkcije. Test je lahko tehnično impresiven, vendar ne dokazuje odpornosti poslovnega procesa, ki zanima regulatorje.

Drugič, odvisnosti od dobaviteljev so priznane, vendar niso podprte z dokazili. Ekipe pravijo, da so ponudnik storitev v oblaku, upravljani SOC ali platforma SaaS v obsegu, vendar manjkajo pogodbe, pravice do revizije, dovoljenja za testiranje, pogoji podpore pri incidentih in izstopni načrti.

Tretjič, testiranje ustvarja dokazila, ne pa obravnave. Ugotovitve ostanejo v poročilu Red Team, namesto da bi bile pretvorjene v posodobitve registra tveganj, spremembe kontrol, lastnike, datume, ponovno testiranje in odločitve o preostalem tveganju.

Četrtič, obnovitev se predpostavlja, ne dokazuje. Politike varnostnega kopiranja obstajajo, vendar nihče ne more pokazati časovnih žigov preklopa na rezervno okolje, preverjanj celovitosti obnovitve, preverjanja dostopa ali potrditve lastnika poslovnega procesa.

Petič, dokazila o zasebnosti in forenzična dokazila niso nadzorovana. Dnevniki in posnetki zaslona vsebujejo osebne podatke, testni artefakti so shranjeni na deljenih pogonih, začasni računi ostanejo aktivni, veriga skrbništva dokazil pa je nepopolna.

Šestič, poročanje vodstvu je preveč tehnično. Višje vodstvo ne vidi, ali se je odpornost izboljšala, ali je tveganje znotraj apetita po tveganju oziroma katere investicijske odločitve so potrebne.

Vsako od teh vrzeli je mogoče odpraviti tako, da DORA TLPT obravnavamo kot strukturiran dokazni delovni tok ISO 27001.

Integriran pristop Clarysec k odpornosti, pripravljeni za presojo

Clarysecov pristop združuje tri plasti.

Prva plast je 30-koračni izvedbeni časovni načrt Zenith Blueprint. Pri tej temi korak 13 vzpostavi sledljivost obravnave tveganj in SoA, korak 21 zaščiti sisteme med revizijskim testiranjem, korak 23 pa preveri pripravljenost IKT za neprekinjeno poslovanje. Ti koraki TLPT pretvorijo iz tehničnega dogodka v dokumentiran cikel upravljanja.

Druga plast je knjižnica politik Clarysec. Politika varnostnega testiranja in vaj Red Team opredeljuje vrste testiranja, obseg, pravila izvajanja, odpravo pomanjkljivosti, poročanje in usklajevanje z dobavitelji. Politika neprekinjenega poslovanja in obnovitve po nesreči za MSP določa pričakovanja za letno testiranje BCP in DR ter dokazila neprekinjenega poslovanja, pripravljena za presojo. Politika varnosti tretjih oseb in dobaviteljev za MSP podpira zagotovila dobaviteljev. Politika varnega razvoja za MSP zagotavlja dokumentiranje varnostnega testiranja. Politika zbiranja dokazov in forenzike za MSP podpira evidentiranje dokazil in disciplino verige skrbništva.

Tretja plast je Zenith Controls, Clarysecov vodnik za navzkrižno skladnost. Pomaga preslikati kontrole ISO/IEC 27002:2022 na atribute, področja, operativne zmogljivosti in pričakovanja med okviri. Pri DORA TLPT najpomembnejši vzorec ni ena kontrola. Pomembno je razmerje med testiranjem, neprekinjenim poslovanjem, upravljanjem incidentov, upravljanjem dobaviteljev, beleženjem, spremljanjem, varnim razvojem, neodvisnim pregledom in upravljanjem.

Ko te plasti delujejo skupaj, se ponedeljkov jutranji problem CISO spremeni. Namesto treh nepovezanih vprašanj organa upravljanja, regulatorja in notranje revizije ima organizacija eno dokazno zgodbo:

“Identificirali smo kritično funkcijo. Ocenili smo tveganje IKT. Izbrali in utemeljili smo kontrole. TLPT smo odobrili in varno izvedli. Zaznali smo, se odzvali in obnovili delovanje. Dobavitelje smo vključili, kjer je bilo to zahtevano. Dokumentirali smo dokazila. Odpravili smo ugotovitve. Izvedli smo ponovno testiranje. Vodstvo je pregledalo in sprejelo preostalo tveganje.”

To je odpornost, pripravljena za presojo.

Naslednji koraki

Če je vaš program DORA TLPT še vedno organiziran okoli poročil in ne dokaznih verig, začnite s Clarysecovim pregledom dokazil.

Uporabite Zenith Blueprint Zenith Blueprint korak 13 za povezavo scenarijev TLPT s tveganji, kontrolami in Izjavo o uporabljivosti. Uporabite korak 21 za preverjanje varne odobritve, pravil izvajanja, povrnitve, spremljanja in čiščenja. Uporabite korak 23 za dokazovanje pripravljenosti IKT za neprekinjeno poslovanje z dokazili obnovitve.

Nato svoje operativne dokumente uskladite s Clarysecovo Politiko varnostnega testiranja in vaj Red Team Politika varnostnega testiranja in vaj Red Team, Politiko neprekinjenega poslovanja in obnovitve po nesreči za MSP Politika neprekinjenega poslovanja in obnovitve po nesreči - MSP, Politiko varnosti tretjih oseb in dobaviteljev za MSP Politika varnosti tretjih oseb in dobaviteljev - MSP, Politiko varnega razvoja za MSP Politika varnega razvoja - MSP in Politiko zbiranja dokazov in forenzike za MSP Politika zbiranja dokazov in forenzike - MSP.

Na koncu uporabite Zenith Controls Zenith Controls, da dokazila DORA TLPT navzkrižno preslikate na kontrole ISO 27001, NIS2, GDPR, COBIT 2019 in pričakovanja presojevalcev.

Če želite, da vaš naslednji preizkus odpornosti ustvari več kot le ugotovitve, uporabite Clarysec in ga pretvorite v zagovorljivo dokazno verigo. Prenesite komplete orodij, dogovorite presojo pripravljenosti dokazil ali zahtevajte predstavitev, kako Clarysec preslika DORA TLPT na kontrole ISO 27001:2022 od načrtovanja do odobritve organa upravljanja.