Testiranje obnovitve, pripravljeno za presojo, za ISO 27001, NIS2 in DORA

Ura je 07:40 v ponedeljek zjutraj in Sarah, direktorica informacijske varnosti (CISO) hitro rastočega finančnotehnološkega podjetja, v realnem času spremlja nastajanje krize. Finančni direktor ne more odpreti platforme za odobravanje plačil. Služba za pomoč uporabnikom meni, da gre za težavo s shrambo. Infrastrukturna ekipa sumi izsiljevalsko programsko opremo, ker več deljenih map zdaj prikazuje šifrirana imena datotek. Generalni direktor želi vedeti, ali je obračun plač varen. Pravna služba sprašuje, ali je treba obvestiti regulatorje.
Sarah odpre nadzorno ploščo za varnostno kopiranje. Polna je zelenih kljukic.
To bi moralo pomiriti, vendar ne pomiri. Uspešno opravilo varnostnega kopiranja ni dokaz uspešne obnovitve. To je podobno, kot bi na steni videli gasilni aparat, ne da bi vedeli, ali je napolnjen, dostopen in uporaben pod pritiskom.
Sarahino podjetje je vključeno v obseg ISO 27001:2022, po NIS2 se obravnava kot pomembni subjekt, kot finančni subjekt pa zanj velja DORA. Vprašanje ni več, ali organizacija izvaja varnostno kopiranje. Vprašanje je, ali lahko obnovi prave sisteme, na pravo časovno točko, znotraj odobrenih ciljnih časov obnovitve in ciljnih točk obnovitve ter z dokazili, ki so dovolj trdna za presojevalca, regulatorja, stranko, zavarovalnico in upravni odbor.
Tu odpove veliko programov varnostnega kopiranja. Imajo opravila varnostnega kopiranja. Imajo nadzorne plošče. Imajo posnetke. Morda imajo celo shrambo v oblaku. Ko pa nastopi pritisk, ne morejo dokazati, da so kritični sistemi obnovljivi, da so bili testi obnovitve izvedeni, da so neuspešni testi sprožili korektivne ukrepe in da se dokazila jasno preslikajo na pričakovanja ISO 27001:2022, NIS2, DORA, NIST in COBIT 2019.
Testiranje varnostnega kopiranja in obnovitve je postalo vprašanje operativne odpornosti na ravni upravnega odbora. NIS2 dviguje pričakovanja glede upravljanja tveganj kibernetske varnosti in neprekinjenega poslovanja. DORA določa digitalno operativno odpornost IKT kot temeljno obveznost finančnih subjektov in njihovih kritičnih ponudnikov storitev IKT. ISO 27001:2022 zagotavlja strukturo sistema upravljanja za obseg, tveganja, izbiro kontrol, dokazila, presojo in nenehno izboljševanje.
Praktični izziv je tehnični test obnovitve pretvoriti v dokazila, pripravljena za presojo.
Varnostna kopija ni dokazilo, dokler obnovitev ni dokazana
Uspešno zaključeno opravilo varnostnega kopiranja je samo delni signal. Pove, da so bili podatki nekam kopirani. Ne dokazuje pa, da je podatke mogoče obnoviti, da so odvisnosti aplikacije neokrnjene, da so šifrirni ključi na voljo, da storitve identitete še delujejo ali da obnovljeni sistem podpira dejanske poslovne operacije.
Presojevalci to vedo. Regulatorji to vedo. Napadalci to vedo.
Tehnično zrel presojevalec se ne bo ustavil pri posnetku zaslona, ki prikazuje 97-odstotno uspešnost opravil varnostnega kopiranja. Vprašal bo:
- Kateri sistemi so kritični ali imajo velik vpliv?
- Kateri RTO in RPO veljata za posamezni sistem?
- Kdaj je bil izveden zadnji test obnovitve?
- Ali je bil test celovit, delen, na ravni aplikacije, na ravni podatkovne baze ali na ravni datotek?
- Kdo je po obnovitvi validiral poslovni proces?
- Ali so bile napake evidentirane kot neskladnosti ali ukrepi za izboljšanje?
- Kako dolgo se hranijo dnevniki in zapisi testov obnovitve?
- Ali so varnostne kopije geografsko ali logično ločene?
- Kako se dokazila preslikajo na register tveganj in izjavo o uporabnosti?
Zato je jezik politik Clarysec namenoma neposreden. Politika varnostnega kopiranja in obnovitve za MSP [BRP-SME], razdelek Zahteve upravljanja, klavzula politike 5.3.3, zahteva:
Testi obnovitve se izvajajo najmanj četrtletno, rezultati pa se dokumentirajo za preverjanje zmožnosti obnovitve
Ta en stavek spremeni pogovor pri presoji. Organizacijo premakne iz izjave »imamo varnostne kopije« v izjavo »zmožnost obnovitve preverjamo po določeni periodiki in hranimo rezultate«.
Ista Politika varnostnega kopiranja in obnovitve za MSP, razdelek Izvajanje in skladnost, klavzula politike 8.2.2, krepi obveznost glede dokazil:
Dnevniki in zapisi testov obnovitve se hranijo za namene presoje
Ta klavzula preprečuje, da bi testiranje obnovitve postalo nedokumentirano institucionalno znanje. Če infrastrukturni inženir reče: »To smo testirali marca,« zapis pa ne obstaja, to niso dokazila, pripravljena za presojo.
Ista politika obravnava tudi odpornost z raznolikostjo hrambe. V razdelku Zahteve za izvajanje politike, klavzula politike 6.3.1.1, morajo biti varnostne kopije:
Hranjene na najmanj dveh lokacijah (lokalno in v oblaku)
To je praktično izhodišče. Ne nadomešča ocene tveganja, vendar zmanjšuje verjetnost, da bi ena fizična ali logična domena odpovedi uničila tako produkcijske podatke kot varnostne kopije.
Veriga dokazil ISO 27001:2022 se začne pred testom
Organizacije skladnost varnostnega kopiranja pogosto obravnavajo kot temo operacij IT. V smislu ISO 27001:2022 je to preozko. Testiranje varnostnega kopiranja in obnovitve mora biti vgrajeno v sistem upravljanja informacijske varnosti, povezano z obsegom, tveganji, izbiro kontrol, spremljanjem, notranjo presojo in nenehnim izboljševanjem.
Clarysecov Zenith Blueprint: 30-koračni časovni načrt presojevalca [ZB] začne to verigo dokazil še pred izvedbo katerega koli testa obnovitve.
V fazi Temelji in voditeljstvo ISMS, korak 2, Potrebe zainteresiranih strani in obseg ISMS, Zenith Blueprint organizacijam naroča, naj opredelijo, kaj je vključeno v ISMS:
Ukrep 4.3: Pripravite osnutek izjave o obsegu ISMS. Navedite, kaj je vključeno (poslovne enote, lokacije, sistemi), in morebitne izključitve. Osnutek posredujte najvišjemu vodstvu za povratne informacije – strinjati se mora, kateri deli poslovanja bodo predmet ISMS. Smiselno je tudi preveriti razumnost tega obsega glede na predhodni seznam zahtev zainteresiranih strani: ali vaš obseg zajema vsa področja, potrebna za izpolnitev teh zahtev?
Pri testiranju obnovitve obseg opredeli obnovitveni univerzum. Če so platforma za odobravanje plačil, ponudnik identitete, podatkovna baza ERP, strežnik za upravljanje končnih točk in objektna shramba v oblaku v obsegu, jih morajo dokazila o obnovitvi vključevati ali pa mora biti utemeljeno, zakaj niso vključeni. Če je sistem izključen, mora biti izključitev zagovorljiva glede na zahteve zainteresiranih strani, pogodbene obveznosti, regulativne dolžnosti in potrebe neprekinjenega poslovanja.
Naslednja povezava je tveganje. V fazi Upravljanje tveganj, korak 11, Izdelava in dokumentiranje registra tveganj, Zenith Blueprint opisuje register tveganj kot osrednji zapis tveganj, sredstev, groženj, ranljivosti, obstoječih kontrol, lastnikov in odločitev o obravnavi.
Vnos tveganja, povezan z varnostnim kopiranjem, mora biti praktičen, ne teoretičen.
| Element tveganja | Primer vnosa |
|---|---|
| Sredstvo | Platforma za odobravanje plačil in podporna podatkovna baza |
| Grožnja | Šifriranje z izsiljevalsko programsko opremo ali destruktivno dejanje administratorja |
| Ranljivost | Varnostne kopije se ne obnavljajo četrtletno, odvisnosti aplikacije pa niso validirane |
| Vpliv | Zamuda pri obračunu plač, regulatorna izpostavljenost, vpliv na zaupanje strank |
| Obstoječe kontrole | Dnevna opravila varnostnega kopiranja, nespremenljiva shramba v oblaku, četrtletni test obnovitve |
| Lastnik tveganja | Vodja infrastrukture |
| Odločitev o obravnavi | Zmanjšanje tveganja s testiranimi varnostnimi kopijami, dokumentiranimi dokazili o obnovitvi in posodobitvami BCP |
Tu varnostno kopiranje postane preverljivo pri presoji. Ne gre več za »imamo varnostne kopije«. Gre za »identificirali smo poslovno tveganje, izbrali kontrole, dodelili lastništvo, testirali kontrolo in hranili dokazila«.
Zenith Blueprint, faza Upravljanje tveganj, korak 13, Načrtovanje obravnave tveganj in izjava o uporabnosti, zapre zanko sledljivosti:
Preslikajte kontrole na tveganja in klavzule (sledljivost)
Zdaj, ko imate načrt obravnave tveganj in SoA:
✓ Preslikajte kontrole na tveganja: v načrtu obravnave v registru tveganj ste za vsako tveganje navedli določene kontrole. Vsakemu tveganju lahko dodate stolpec »Sklic na kontrolo iz Priloge A« in navedete številke kontrol.
Za varnostno kopiranje in testiranje obnovitve mora izjava o uporabnosti scenarij tveganja povezati s kontrolami iz Priloge A ISO/IEC 27001:2022, zlasti 8.13 Varnostno kopiranje informacij, 5.30 pripravljenost IKT za neprekinjeno poslovanje, 8.14 redundantnost objektov za obdelavo informacij in 5.29 informacijska varnost med motnjami.
SoA teh kontrol ne sme zgolj označiti kot uporabne. Pojasniti mora, zakaj so uporabne, katera dokazila o implementaciji obstajajo, kdo je lastnik kontrole in kako se obravnavajo izjeme.
Zemljevid kontrol, ki ga pričakujejo presojevalci
Clarysecov Zenith Controls: Vodnik za navzkrižno skladnost [ZC] ne ustvarja ločenih ali lastniških kontrol. Uradne standarde in okvire organizira v praktičen pogled navzkrižne skladnosti, da lahko organizacije razumejo, kako ena operativna praksa, kot je testiranje obnovitve, podpira več obveznosti.
Za kontrolo 8.13 Varnostno kopiranje informacij iz ISO/IEC 27002:2022 Zenith Controls kontrolo razvršča kot korektivno, povezano s celovitostjo in razpoložljivostjo, usklajeno s konceptom kibernetske varnosti Recover, ki podpira operativno zmožnost neprekinjenega poslovanja in je umeščena v varnostno področje zaščite. Tak profil varnostne kopije preoblikuje v zmožnost obnovitve, ne zgolj v proces hrambe.
Za kontrolo 5.30 pripravljenost IKT za neprekinjeno poslovanje iz ISO/IEC 27002:2022 Zenith Controls kontrolo razvršča kot korektivno, osredotočeno na razpoložljivost, usklajeno z odzivanjem, ki podpira neprekinjeno poslovanje in je umeščena v področje varnosti odpornosti. Tu se testiranje obnovitve neposredno poveže z operativno odpornostjo.
Za kontrolo 8.14 Redundantnost objektov za obdelavo informacij iz ISO/IEC 27002:2022 Zenith Controls opredeli preventivno kontrolo, osredotočeno na razpoložljivost, usklajeno z zaščito, ki podpira neprekinjeno poslovanje in upravljanje sredstev ter je povezana s področjema zaščite in odpornosti. Redundantnost in varnostne kopije niso isto. Redundantnost pomaga preprečiti prekinitev. Varnostne kopije omogočajo obnovitev po izgubi, okvari ali napadu.
Za kontrolo 5.29 Informacijska varnost med motnjami iz ISO/IEC 27002:2022 Zenith Controls prikazuje širši profil: preventivno in korektivno, ki zajema zaupnost, celovitost in razpoložljivost, je usklajeno z zaščito in odzivanjem, podpira neprekinjeno poslovanje ter je povezano z zaščito in odpornostjo. To je pomembno pri obnovitvi po izsiljevalski programski opremi, ker obnovitev ne sme ustvariti novih varnostnih odpovedi, kot so obnavljanje ranljivih slik, obhod beleženja ali ponovna aktivacija prekomernih privilegijev.
| Kontrola iz Priloge A ISO/IEC 27001:2022 | Vloga pri odpornosti | Dokazila, ki jih pričakujejo presojevalci |
|---|---|---|
| 8.13 Varnostno kopiranje informacij | Dokazuje, da je podatke in sisteme mogoče obnoviti po izgubi, okvari ali napadu | Urnik varnostnega kopiranja, zapisi testov obnovitve, merila uspešnosti, dnevniki, izjeme, dokazila o hrambi |
| 5.30 Pripravljenost IKT za neprekinjeno poslovanje | Kaže, da zmožnosti IKT podpirajo cilje neprekinjenega poslovanja | BIA, preslikava RTO/RPO, operativni priročniki za obnovitev, poročila o testih, pridobljene izkušnje |
| 8.14 Redundantnost objektov za obdelavo informacij | Zmanjšuje odvisnost od enega samega objekta za obdelavo ali storitvene poti | Arhitekturni diagrami, rezultati testiranja preklopa na rezervno okolje, pregled zmogljivosti, mapiranje odvisnosti |
| 5.29 Informacijska varnost med motnjami | Ohranja varnost med degradiranim delovanjem in obnovitvijo | Zapisi kriznega dostopa, odobritve nujnih sprememb, beleženje, časovnica incidenta, varnostna validacija po obnovitvi |
Praktična lekcija je preprosta. Test obnovitve ni ena izolirana kontrola. Je dokazilo vzdolž verige odpornosti.
Skrita vrzel pri presoji: RTO in RPO brez dokazov
Ena najpogostejših ugotovitev pri presoji neprekinjenega poslovanja je vrzel med dokumentiranimi RTO/RPO in dejansko zmožnostjo obnovitve.
Načrt neprekinjenega poslovanja lahko določa, da ima portal za stranke štiriurni RTO in enourni RPO. Platforma za varnostno kopiranje se lahko izvaja vsako uro. Toda med prvo realistično vajo obnovitve ekipa ugotovi, da obnovitev podatkovne baze traja tri ure, spremembe DNS zahtevajo še eno uro, certifikat aplikacije je potekel, integracija identitete pa nikoli ni bila vključena v operativni priročnik. Dejanski čas obnovitve je osem ur.
Dokumentirani RTO je bil fikcija.
Clarysecova Politika neprekinjenega poslovanja in obnovitve po nesreči za MSP [BCDR-SME], razdelek Zahteve upravljanja, klavzula politike 5.2.1.4, zahtevo glede neprekinjenega poslovanja izrecno določa:
Ciljni časi obnovitve (RTO) in ciljne točke obnovitve (RPO) za vsak sistem
To je pomembno, ker »hitro obnoviti kritične storitve« ni merljivo. »Obnoviti podatkovno bazo za odobravanje plačil v štirih urah z največ eno uro izgube podatkov« je merljivo.
Ista Politika neprekinjenega poslovanja in obnovitve po nesreči za MSP, razdelek Zahteve za izvajanje politike, klavzula politike 6.4.2, testiranje pretvori v izboljševanje:
Vse rezultate testov je treba dokumentirati, pridobljene izkušnje pa je treba evidentirati in uporabiti za posodobitev BCP.
Neuspešna obnovitev ni samodejno katastrofa pri presoji. Neuspešna obnovitev brez dokumentiranih pridobljenih izkušenj, lastnika, popravka in ponovnega testa pa je.
Za poslovna okolja Clarysecova Politika varnostnega kopiranja in obnovitve [BRP] zagotavlja bolj formalno upravljanje. V razdelku Zahteve upravljanja, klavzula politike 5.1, določa:
Osrednji urnik varnostnega kopiranja se mora vzdrževati in pregledati letno. Določati mora:
Ta uvodna zahteva vzpostavi temeljni artefakt upravljanja. Osrednji urnik varnostnega kopiranja mora opredeliti sisteme, podatkovne nize, pogostost varnostnega kopiranja, hrambo, lokacijo, lastništvo, razvrstitev, odvisnosti in periodiko testiranja.
Ista Politika varnostnega kopiranja in obnovitve, razdelek Zahteve upravljanja, klavzula politike 5.2, povezuje pričakovanja glede varnostnega kopiranja z vplivom na poslovanje:
Vsi sistemi in aplikacije, razvrščeni kot kritični ali z visokim vplivom v analizi vpliva na poslovanje (BIA), morajo:
Tu se BIA in upravljanje varnostnega kopiranja združita. Kritični sistemi in sistemi z visokim vplivom zahtevajo močnejše zagotovilo obnovitve, pogostejše testiranje, boljše mapiranje odvisnosti in bolj disciplinirana dokazila.
En model dokazil za ISO 27001:2022, NIS2, DORA, NIST in COBIT 2019
Ekipe za skladnost se pogosto spopadajo s podvajanjem okvirov. ISO 27001:2022 zahteva izbiro kontrol in dokazila na podlagi tveganj. NIS2 pričakuje ukrepe za upravljanje tveganj kibernetske varnosti, vključno z neprekinjenim poslovanjem. DORA pričakuje digitalno operativno odpornost IKT, odziv in obnovitev, postopke varnostnega kopiranja in obnovitve ter testiranje digitalne operativne odpornosti. NIST in COBIT 2019 uporabljata spet drugačen jezik.
Odgovor ni vzpostaviti ločenih programov varnostnega kopiranja za vsak okvir. Odgovor je vzpostaviti en model dokazil, ki ga je mogoče pregledovati skozi več presojnih pogledov.
| Pogled okvira | Kaj dokazuje testiranje varnostnega kopiranja in obnovitve | Dokazila, ki naj bodo pripravljena za presojo |
|---|---|---|
| ISO 27001:2022 | Tveganja se obravnavajo z izbranimi kontrolami, testirajo, spremljajo in izboljšujejo prek ISMS | Obseg, register tveganj, SoA, urnik varnostnega kopiranja, zapisi obnovitve, rezultati notranje presoje, dnevnik CAPA |
| NIS2 | Bistvene ali pomembne storitve lahko prenesejo kibernetsko motnjo in se po njej obnovijo | Načrti neprekinjenega poslovanja, krizni postopki, testi varnostnih kopij, povezave z odzivom na incidente, nadzor vodstva |
| DORA | Storitve IKT, ki podpirajo kritične ali pomembne funkcije, so odporne in obnovljive | Mapiranje sredstev IKT, RTO/RPO, poročila o testih obnovitve, dokazila o odvisnostih od tretjih oseb, postopki obnovitve |
| NIST CSF | Zmožnosti obnovitve podpirajo odporne rezultate kibernetske varnosti | Načrti obnovitve, preverjanja celovitosti varnostnih kopij, komunikacijski postopki, pridobljene izkušnje |
| COBIT 2019 | Cilji upravljanja in vodenja so podprti z merljivimi kontrolami in jasno odgovornostjo | Lastništvo procesov, kazalniki, uspešnost kontrol, spremljanje zadev, poročanje vodstvu |
Za NIS2 je najneposrednejši sklic Article 21 o ukrepih za upravljanje tveganj kibernetske varnosti. Article 21(2)(c) posebej vključuje neprekinjeno poslovanje, kot so upravljanje varnostnih kopij, obnovitev po nesreči in krizno upravljanje. Pomemben je tudi Article 21(2)(f), ker obravnava politike in postopke za ocenjevanje učinkovitosti ukrepov za upravljanje tveganj kibernetske varnosti. Testiranje obnovitve je prav to: dokazilo, da ukrep deluje.
Za DORA so najmočnejše povezave Article 11 o odzivu in obnovitvi, Article 12 o politikah in postopkih varnostnega kopiranja, postopkih in metodah obnovitve ter Article 24 o splošnih zahtevah za testiranje digitalne operativne odpornosti. Za finančne subjekte sam test obnovitve podatkovne baze morda ne zadošča, če je poslovna storitev odvisna od identitete v oblaku, povezljivosti s plačilnim prehodom, zunanjega gostovanja ali upravljanega spremljanja. Dokazila po pristopu DORA morajo biti na ravni storitve, ne zgolj na ravni strežnika.
| Kontrola ISO/IEC 27001:2022 | Povezava z DORA | Povezava z NIS2 |
|---|---|---|
| 8.13 Varnostno kopiranje informacij | Article 12 zahteva politike varnostnega kopiranja ter postopke in metode obnovitve | Article 21(2)(c) vključuje upravljanje varnostnih kopij in obnovitev po nesreči kot ukrepe neprekinjenega poslovanja |
| 5.30 Pripravljenost IKT za neprekinjeno poslovanje | Article 11 zahteva zmožnost odziva in obnovitve, Article 24 pa zahteva testiranje odpornosti | Article 21(2)(c) vključuje neprekinjeno poslovanje in krizno upravljanje |
| 8.14 Redundantnost objektov za obdelavo informacij | Articles 6 in 9 podpirata upravljanje tveganj IKT, zaščito, preprečevanje in zmanjšanje enojnih točk odpovedi | Article 21 zahteva ustrezne in sorazmerne ukrepe za upravljanje tveganj za omrežne in informacijske sisteme |
| 5.29 Informacijska varnost med motnjami | Odziv in obnovitev iz Article 11 zahtevata nadzorovano obnovitev med incidenti | Ukrepi za upravljanje tveganj iz Article 21 zahtevajo neprekinjeno poslovanje brez opuščanja varnostnih kontrol |
To je učinkovitost poenotene strategije skladnosti. Četrtletni test obnovitve plačilnega sistema lahko podpira dokazila iz Priloge A ISO 27001:2022, pričakovanja glede neprekinjenega poslovanja po NIS2, zahteve DORA glede obnovitve IKT, rezultate NIST CSF Recover in poročanje o upravljanju po COBIT 2019, če so dokazila pravilno strukturirana.
Praktičen test obnovitve, ki postane dokazilo, pripravljeno za presojo
Vrnimo se k Sarahinemu ponedeljkovemu jutranjemu scenariju, vendar si predstavljajmo, da se je njena organizacija pripravila z orodji Clarysec.
Platforma za odobravanje plačil je v BIA razvrščena kot kritična. Odobreni RTO je štiri ure. Odobreni RPO je ena ura. Platforma je odvisna od gruče podatkovnih baz, ponudnika identitete, repozitorija skrivnosti, cevovoda beleženja, DNS, certifikatov in izhodnega e-poštnega posrednika.
Sarahina ekipa četrtletni test obnovitve zgradi okoli šestih korakov.
Korak 1: Potrdite obseg in odvisnosti
Z uporabo Zenith Blueprint koraka 2 Sarah potrdi, da so plačilna platforma, podatkovna baza, integracija identitete, infrastruktura varnostnega kopiranja in obnovitveno okolje znotraj obsega ISMS. Pravna služba potrdi regulativno relevantnost. Finance potrdijo poslovni vpliv. IT potrdi odvisnosti.
S tem se izogne klasični napaki, ko se obnovi samo podatkovna baza, prezre pa se avtentikacijska storitev, potrebna za dostop do aplikacije.
Korak 2: Povežite test z registrom tveganj
Z uporabo Zenith Blueprint koraka 11 register tveganj vključuje scenarij: »Izguba ali šifriranje podatkov platforme za odobravanje plačil prepreči plačilne operacije in povzroči regulatorno izpostavljenost.«
Obstoječe kontrole vključujejo dnevne varnostne kopije, nespremenljivo shrambo v oblaku, varnostne kopije na več lokacijah, četrtletno testiranje obnovitve in dokumentirane operativne priročnike za obnovitev. Lastnik tveganja je vodja infrastrukture. Poslovni lastnik so finančne operacije. Odločitev o obravnavi je zmanjšanje tveganja.
Korak 3: Preslikajte obravnavo v SoA
Z uporabo Zenith Blueprint koraka 13 SoA preslika tveganje na kontrole iz Priloge A ISO/IEC 27001:2022 8.13, 5.30, 8.14 in 5.29. SoA pojasni, da testiranje varnostnih kopij zagotavlja korektivno zmožnost obnovitve, postopki neprekinjenega poslovanja IKT podpirajo neprekinjeno poslovanje, redundantnost zmanjšuje verjetnost izpada, varnost med motnjami pa preprečuje nevarne bližnjice pri obnovitvi.
Korak 4: Uporabite klavzule politike kot merila testa
Ekipa uporabi klavzulo 5.3.3 Politike varnostnega kopiranja in obnovitve za MSP za četrtletno testiranje obnovitve, klavzulo 8.2.2 za hrambo dokazil in klavzulo 6.3.1.1 za hrambo na več lokacijah. Uporabi klavzulo 5.2.1.4 Politike neprekinjenega poslovanja in obnovitve po nesreči za MSP za cilje RTO/RPO ter klavzulo 6.4.2 za pridobljene izkušnje in posodobitve BCP.
| Merilo testa | Cilj | Dokazilo |
|---|---|---|
| Periodika obnovitve | Četrtletno | Koledar testiranja in odobren urnik |
| RTO | 4 ure | Začetni čas, končni čas, pretečeni čas obnovitve |
| RPO | 1 ura | Časovni žig varnostne kopije in validacija transakcij |
| Lokacije | Na voljo lokalni viri varnostnih kopij in viri v oblaku | Poročilo repozitorija varnostnih kopij |
| Celovitost | Preverjanja doslednosti podatkovne baze so uspešna | Dnevniki validacije |
| Aplikacija | Uporabnik iz financ lahko odobri testno plačilo | Poslovna validacijska odobritev |
| Varnost | Beleženje, kontrole dostopa in skrivnosti validirane po obnovitvi | Varnostni kontrolni seznam in posnetki zaslona |
Korak 5: Izvedite obnovitev in zabeležite dejstva
Obnovitev se izvede v izoliranem obnovitvenem okolju. Ekipa zabeleži časovne žige, identifikatorje nabora varnostnih kopij, korake obnovitve, napake, rezultate validacije in odobritve.
Dober zapis testa obnovitve mora vključevati:
| Polje testa obnovitve | Primer |
|---|---|
| ID testa | Q2-2026-PAY-RESTORE |
| Testirani sistem | Platforma za odobravanje plačil |
| Uporabljeni nabor varnostnih kopij | Varnostna kopija plačilne platforme iz odobrene točke obnovitve |
| Lokacija obnovitve | Izolirano obnovitveno okolje |
| Ciljni RTO | 4 ure |
| Ciljni RPO | 1 ura |
| Dejanski čas obnovitve | 2 uri 45 minut |
| Dejanska točka obnovitve | 42 minut |
| Validacija celovitosti | Preverjanja doslednosti podatkovne baze uspešna |
| Poslovna validacija | Uporabnik iz financ odobril testno plačilo |
| Varnostna validacija | Beleženje, kontrole dostopa, skrivnosti in spremljanje potrjeni |
| Rezultat | Uspešno s pogojem |
| Odobritev | CISO, vodja infrastrukture, lastnik finančnih operacij |
Med testom ekipa odkrije eno težavo. Obnovljena aplikacija ne more pošiljati e-poštnih obvestil, ker seznam dovoljenih za e-poštni posrednik ne vključuje obnovitvenega podomrežja. Osnovno odobravanje plačil deluje, delovni tok pa je degradiran.
Korak 6: Zabeležite pridobljene izkušnje in korektivni ukrep
Tu se veliko organizacij ustavi prezgodaj. Pristop Clarysec težavo prenese v sistem izboljševanja.
V fazi Presoja, pregled in izboljševanje, korak 29, Nenehno izboljševanje, Zenith Blueprint uporablja dnevnik CAPA za spremljanje opisa težave, temeljnega vzroka, korektivnega ukrepa, lastnika, ciljnega datuma in statusa.
| Polje CAPA | Primer |
|---|---|
| Opis težave | Obnovljena plačilna platforma ni mogla pošiljati e-poštnih obvestil iz obnovitvenega podomrežja |
| Temeljni vzrok | Obnovitveno omrežje ni bilo vključeno v zasnovo seznama dovoljenih za e-poštni posrednik |
| Korektivni ukrep | Posodobiti obnovitveno arhitekturo in postopek seznama dovoljenih za e-poštni posrednik |
| Lastnik | Vodja infrastrukture |
| Ciljni datum | 15 delovnih dni |
| Status | Odprto, čaka na ponovni test |
Ta en test obnovitve zdaj ustvari verigo dokazil, pripravljeno za presojo: zahtevo politike, potrditev obsega, preslikavo tveganj, preslikavo SoA, načrt testa, zapis izvedbe, poslovno validacijo, varnostno validacijo, zapis težave, korektivni ukrep in posodobitev BCP.
Kako različni presojevalci pregledajo ista dokazila
Močan paket dokazil predvideva presojevalčev pogled.
Presojevalec ISO 27001:2022 bo običajno začel pri sistemu upravljanja. Vprašal bo, ali so zahteve glede varnostnega kopiranja in obnovitve zajete v obsegu, utemeljene na tveganjih, implementirane, spremljane, notranje presojane in izboljševane. Pričakoval bo sledljivost od registra tveganj prek SoA do operativnih zapisov. Neuspešne teste in korektivne ukrepe lahko poveže tudi s klavzulo 10.2 ISO/IEC 27001:2022 o neskladnosti in korektivnem ukrepu.
Pregledovalec DORA se bo osredotočil na digitalno operativno odpornost IKT za kritične ali pomembne funkcije. Želel bo videti obnovitev na ravni storitve, odvisnosti od tretjih ponudnikov IKT, testiranje na podlagi scenarijev, nadzor upravljalnega organa in dokazila, da so postopki obnovitve učinkoviti.
Nadzorniški pogled NIS2 bo iskal ustrezne in sorazmerne ukrepe za upravljanje tveganj kibernetske varnosti. Dokazila o varnostnem kopiranju in obnovitvi po nesreči morajo pokazati, da lahko bistvene ali pomembne storitve ohranijo ali obnovijo delovanje po incidentih, pri čemer je vodstvo seznanjeno s preostalim tveganjem.
Ocenjevalec, usmerjen v NIST, se bo osredotočil na rezultate kibernetske varnosti prek funkcij Identify, Protect, Detect, Respond in Recover. Sprašuje lahko o nespremenljivih varnostnih kopijah, privilegiranem dostopu do repozitorijev varnostnih kopij, obnovitvi v čista okolja, komunikacijah in pridobljenih izkušnjah.
Presojevalec v slogu COBIT 2019 ali ISACA bo poudarjal upravljanje, lastništvo procesov, kazalnike, poročanje vodstvu in spremljanje zadev. Tehnično elegantna obnovitev ga bo manj prepričala, če lastništvo in poročanje nista jasna.
Ista dokazila lahko zadovoljijo vse te poglede, vendar le, če so popolna.
Pogoste napake pri testiranju obnovitve, ki ustvarijo ugotovitve presoje
Clarysec vedno znova opaža iste preprečljive vrzeli v dokazilih.
| Vzorec napake | Zakaj ustvarja tveganje pri presoji | Praktična rešitev |
|---|---|---|
| Uspeh varnostnega kopiranja se obravnava kot uspeh obnovitve | Zaključeno kopiranje ne dokazuje zmožnosti obnovitve | Izvajajte dokumentirane teste obnovitve z validacijo |
| RTO in RPO sta opredeljena, vendar nista testirana | Cilji neprekinjenega poslovanja so lahko nerealistični | Med testi izmerite dejanski čas obnovitve in dejansko točko obnovitve |
| Obnovitev validira samo infrastruktura | Poslovni proces je lahko še vedno neuporaben | Zahtevajte odobritev poslovnega lastnika za kritične sisteme |
| Zapisi testov so razpršeni | Presojevalci ne morejo preveriti doslednosti | Uporabite standardno predlogo poročila o testu obnovitve in mapo z dokazili |
| Neuspešni testi se obravnavajo v razpravi, vendar se jim ne sledi | Ni dokazil o nenehnem izboljševanju | Težave evidentirajte v CAPA z lastnikom, rokom in ponovnim testom |
| Varnostne kopije so hranjene v eni logični domeni odpovedi | Izsiljevalska programska oprema ali napačna konfiguracija lahko uniči zmožnost obnovitve | Uporabite ločene lokacije, nespremenljivo hrambo in nadzor dostopa |
| Odvisnosti so izključene | Obnovljene aplikacije morda ne bodo delovale | Mapirajte identitete, DNS, skrivnosti, certifikate, integracije in beleženje |
| Varnost je med obnovitvijo prezrta | Obnovljene storitve so lahko ranljive ali nespremljane | Vključite varnostno validacijo po obnovitvi |
Cilj ni birokracija. Cilj sta zanesljiva obnovitev pod pritiskom in zagovorljiva dokazila pri presoji.
Zgradite paket dokazil o obnovitvi za upravni odbor
Izvršno vodstvo ne potrebuje surovih dnevnikov varnostnega kopiranja. Potrebuje zagotovilo, da so kritične storitve obnovljive, da so izjeme znane in da ukrepi za izboljšanje napredujejo.
Za vsako kritično storitev poročajte:
- ime storitve in poslovnega lastnika
- kritičnost iz BIA
- odobrena RTO in RPO
- datum zadnjega testa obnovitve
- dosežena RTO in RPO
- rezultat testa
- odprti korektivni ukrepi
- odvisnosti od tretjih oseb, ki vplivajo na obnovitev
- izjavo o preostalem tveganju
- naslednji načrtovani test
| Kritična storitev | RTO/RPO | Zadnji test | Rezultat | Odprta težava | Sporočilo vodstvu |
|---|---|---|---|---|---|
| Platforma za odobravanje plačil | 4h/1h | 2026-04-12 | Uspešno s pogojem | Seznam dovoljenih za obnovitveno podomrežje e-poštnega posrednika | Osnovno odobravanje plačil obnovljeno znotraj cilja, odprava delovnega toka obveščanja poteka |
| Portal za stranke | 8h/2h | 2026-03-20 | Neuspešno | Obnovitev podatkovne baze je RTO presegla za 90 minut | Potrebna sta izboljšanje zmogljivosti in procesa obnovitve |
| Obnovitev ponudnika identitete | 2h/15m | 2026-04-05 | Uspešno | Brez | Podpira obnovitev odvisnih kritičnih storitev |
Tak slog poročanja ustvarja most med tehničnimi ekipami, presojevalci in vodstvom. Podpira tudi vodstveni pregled ISMS in nadzor odpornosti po NIS2 in DORA.
Praktični presojni kontrolni seznam za naslednjih 30 do 90 dni
Če se vaša presoja približuje, začnite z dokazili, ki jih že imate, in najprej zaprite vrzeli z največjim tveganjem.
- Identificirajte vse kritične sisteme in sisteme z visokim vplivom iz BIA.
- Potrdite RTO in RPO za vsak kritični sistem.
- Preverite, da je vsak kritični sistem naveden v osrednjem urniku varnostnega kopiranja.
- Potrdite lokacije varnostnih kopij, vključno z lokalnimi repozitoriji, repozitoriji v oblaku ter nespremenljivimi ali ločenimi repozitoriji.
- Izberite vsaj en nedavni test obnovitve za kritično storitev ali test takoj načrtujte.
- Zagotovite, da zapisi testov obnovitve prikazujejo obseg, časovne žige, nabor varnostnih kopij, rezultat, dosežena RTO/RPO in validacijo.
- Pridobite odobritev poslovnega lastnika za obnovitev na ravni aplikacije.
- Po obnovitvi validirajte varnost, vključno z nadzorom dostopa, beleženjem, spremljanjem, skrivnostmi, certifikati in izpostavljenostjo ranljivostim.
- Preslikajte dokazila na register tveganj in SoA.
- Evidentirajte težave v CAPA, dodelite lastnike in spremljajte ponovni test.
- Povzemite rezultate za vodstveni pregled.
- Pripravite pogled navzkrižne skladnosti za presojne pogovore o ISO 27001:2022, NIS2, DORA, NIST CSF in COBIT 2019.
Če pred presojo ne morete dokončati vsake postavke, bodite transparentni. Presojevalci se običajno bolje odzovejo na dokumentirano vrzel z načrtom korektivnih ukrepov kot na nejasne trditve o zrelosti.
Naj bo testiranje obnovitve vaše najmočnejše dokazilo odpornosti
Testiranje varnostnega kopiranja in obnovitve je eden najjasnejših načinov dokazovanja operativne odpornosti. Je oprijemljivo, merljivo, poslovno relevantno in neposredno povezano z ISO 27001:2022, NIS2, DORA, NIST, COBIT 2019, poročanjem upravnemu odboru, programi zagotavljanja zaupanja naročnikov in pričakovanji zavarovalnic.
Vendar le, če je pravilno dokumentirano.
Clarysec organizacijam pomaga operacije varnostnega kopiranja pretvoriti v dokazila, pripravljena za presojo, prek Politike varnostnega kopiranja in obnovitve, Politike varnostnega kopiranja in obnovitve za MSP, Politike neprekinjenega poslovanja in obnovitve po nesreči za MSP, Zenith Blueprint in Zenith Controls.
Vaš naslednji praktični korak je preprost. Ta teden izberite eno kritično storitev. Izvedite test obnovitve glede na njen odobreni RTO in RPO. Dokumentirajte rezultat. Preslikajte ga v register tveganj in SoA. Zabeležite vsako pridobljeno izkušnjo.
Če želite, da je ta proces ponovljiv v ISO 27001:2022, NIS2, DORA, NIST in COBIT 2019, vam Clarysecov nabor orodij zagotavlja strukturo za dokazovanje obnovitve brez gradnje labirinta skladnosti od začetka.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


