ISO 27031: Čeklista za samoprocenu IRBC spremnosti

Poslednji tekst u seriji o ISO/IEC 27031. Umesto nove klauzule, alat: čeklista koja sažima svih devetnaest prethodnih tekstova u pitanja na koja možete sami da odgovorite sa da ili ne. Nije zamišljena kao formalni audit – to smo pokrili u dvanaestom tekstu – nego kao brz način da vidite gde stojite i odakle da počnete, bez potrebe da ponovo čitate celu seriju.

Kako da je koristite: nemojte očekivati da odgovorite "da" na sve. Većina firmi koje ozbiljno krenu u ovo prvi put odgovori "ne" na dve trećine pitanja – to je normalan početak, ne razlog za paniku. Vrednost čekliste nije u konačnom skoru, nego u tome da precizno pokaže koja dva-tri "ne" nose najveći rizik za vašu firmu, pa tu krećete.

Upravljanje i vlasništvo

• [ ] Postoji jedna imenovana osoba, formalno ovlašćena od top menadžmenta, odgovorna za IRBC politiku i implementaciju – ne neko ko ove aktivnosti radi na sopstvenu inicijativu, pored redovnog posla.
• [ ] Postoji definisan prag – konkretan uslov (na primer, pogođen sistem plus vreme trajanja) – posle kog se "obična" IT intervencija formalno eskalira u IRBC odgovor.
• [ ] IRBC ciljevi su eksplicitno povezani sa ciljevima kontinuiteta poslovanja koje je top menadžment već odobrio – ne postavljeni samostalno od strane IT sektora.
• [ ] Znanje o tome kako se kritični sistemi oporavljaju je dokumentovano i preneto na bar dve osobe – ne postoji kod samo jedne osobe u firmi.
• [ ] Top menadžment je taj koji formalno bira i potpisuje IRBC strategiju između ponuđenih opcija – ne samo naknadno obaveštava se o odluci koju je IT već doneo.

Rizik, BIA i ciljevi spremnosti

• [ ] Rizik gubitka dostupnosti kritičnih IT servisa postoji kao imenovan unos u istom risk registru koji firma već koristi za informacionu bezbednost – ne u posebnom, odvojenom dokumentu.
• [ ] Za svaku prioritetnu poslovnu aktivnost postoji izmeren (ne procenjen) RTO i RPO, izveden iz stvarnog poslovnog zahteva – u idealnom slučaju direktno iz ugovora ili SLA.
• [ ] RTO poslovne aktivnosti je razložen na RTO pojedinačnih IT servisa koji je podržavaju, tako da je jasno koja komponenta je najsporija karika.
• [ ] Firma prati bar pet dimenzija spremnosti, ne samo brzinu oporavka – ranu detekciju, sprečavanje naglog kvara, prihvatljivu degradaciju, brzinu oporavka, i minimizaciju posledica.
• [ ] Definisan je MBCO (minimalni prihvatljiv nivo usluge tokom poremećaja) za svaku prioritetnu aktivnost – ne otkriva se tek usred incidenta.
• [ ] Svaka veća IT promena (nova usluga, migracija, novi dobavljač, gašenje sistema) prolazi kroz formalnu proveru uticaja na IRBC pre puštanja u produkciju.

Hibridna infrastruktura i zavisnosti

• [ ] Postoji dokumentovan, end-to-end lanac zavisnosti za svaki kritičan servis – uključujući cloud komponente, mrežne veze između lokacija, i dobavljače, ne samo ono što fizički stoji u serverskoj sobi.
• [ ] Firma je eksplicitno proverila šta cloud/SaaS dobavljač stvarno pokriva u smislu bekapa i oporavka podataka, a šta ostaje njena sopstvena odgovornost – ne pretpostavlja da visoka dostupnost platforme znači rešen kontinuitet.
• [ ] Identitet/autentifikacija, DNS, i integracije između on-premise i cloud sistema su eksplicitno mapirani kao kritične zavisnosti – ne tretiraju se kao "nevidljiva infrastruktura" koja se podrazumeva.
• [ ] Mrežna veza između lokacije i cloud okruženja je prepoznata kao potencijalna jedinstvena tačka otkaza, ne samo serveri na oba kraja.
• [ ] Za svakog kritičnog dobavljača postoji analiza jaza između njihove sopstvene sposobnosti oporavka i RTO koji je firmi potreban – ne samo spisak dobavljača bez te provere.
• [ ] Ugovori sa kritičnim dobavljačima sadrže odredbe o odgovoru na veće incidente, učestalosti vežbanja, i sposobnosti da izdrže istovremenu aktivaciju za više klijenata odjednom.

Strategija

• [ ] Za svaki kritičan servis, razmotren je niz strategijskih opcija (interne, kod dobavljača, eksterne treće strane) pre nego što je doneta odluka – ne prva tehnički izvodljiva ideja.
• [ ] Strategija je svesno birana kroz svih šest kategorija – ljudi, objekti, tehnologija, podaci, procesi, dobavljači – ne samo kroz tehnologiju, koja obično dobije svu pažnju.
• [ ] Nivo redundanse (hladno/toplo/vruće/visoka redundansa) je svesno dodeljen svakoj kritičnoj komponenti na osnovu njenog RTO zahteva, ne na osnovu istorijske slučajnosti šta je kupljeno kad.
• [ ] Redundantne komponente su fizički razdvojene na različitim lokacijama – ne samo logički odvojene u istoj prostoriji.
• [ ] Gde IRBC trenutno ne može da ispuni poslovni zahtev, postoji eksplicitna odluka – zatvoriti jaz ili ga svesno prihvatiti i upisati u risk registar – ne siva zona koja živi neopredeljeno.

Plan

• [ ] Postoji pisana, korak-po-korak procedura oporavka za svaki kritičan servis, dovoljno detaljna da je kompetentna osoba može izvršiti bez improvizacije.
• [ ] Plan postoji na više lokacija i u više formata, tako da ne zavisi od sistema koji bi upravo mogao da otkaže.
• [ ] Sve kopije plana su iste, ažurne verzije – postoji kontrola koja sprečava da se zastarela verzija slučajno upotrebi.
• [ ] Postoji dokumentovano privremeno rešenje (workaround) za period dok traje pun oporavak – i vlasnici pogođene poslovne aktivnosti, ne samo IT, znaju kako da ga sprovedu.
• [ ] Definisan je tok aktivacije i eskalacije sa jasno imenovanim ulogama u svakom koraku, uključujući formalnu de-eskalaciju i izveštaj kad se kriza reši.

Testiranje

• [ ] Firma je bar jednom sprovela stvaran test (ne samo čitanje dokumenta oko stola) za svaki kritičan servis, sa izmerenim, ne procenjenim, rezultatima.
• [ ] Postoji postepen program vežbi – od familijarizacije, preko testa komponente i integrisanog testa, do uživo testa sa stvarnim prebacivanjem između primarne i sekundarne strane.
• [ ] Svaka vežba ima unapred potpisan referentni okvir sa definisanim ciljevima, rizicima i kriterijumima uspeha – ne organizuje se neformalno u hodu.
• [ ] Postoji definisan protokol za hitno zaustavljanje vežbe ako ona sama počne da ugrožava produkciju.
• [ ] Posle svake vežbe piše se formalan izveštaj sa dodeljenim akcijama i rokovima, koji se prati do zatvaranja – ne ostaje na nivou "prošlo je dobro, u principu".

Kontinuirano unapređenje

• [ ] Interni audit IRBC-a se sprovodi bar jednom godišnje, po mogućstvu usklađen sa postojećim ISO 27001 audit ciklusom.
• [ ] Sposobnost kritičnih dobavljača se periodično ponovo proverava, ne samo jednom pri potpisivanju ugovora.
• [ ] IRBC strategije se redovno preispituju od strane top menadžmenta, ne ostaju odobrene jednom pa zaboravljene.
• [ ] Postoji plan proširenja na sledeći kritičan servis po prioritetu iz BIA rezultata, ne po tome šta je tehnički najlakše.

Kako pročitati rezultat

Ako ste odgovorili "da" na manje od trećine – normalan početak; vratite se na četvrti i osamnaesti tekst ove serije za realan plan prvih koraka, i krenite od jednog servisa, ne od svih odjednom. Ako ste između trećine i dve trećine – osnova verovatno postoji, ali fragmentarno; potražite obrazac u tome koje kategorije stalno ostaju prazne (najčešće: hibridne zavisnosti i testiranje) i usmerite sledeći kvartal tamo. Ako ste iznad dve trećine – verovatno ste bliže godišnjem ritmu iz devetnaestog teksta nego prvom krugu, i vredi proveriti da li je poslednja trećina "ne" odgovora svesno prihvaćen rizik (klauzula 12) ili prosto nikad formalno adresirana.

Ovim se zatvara serija o ISO/IEC 27031 – od uvoda u IRBC, kroz svih trinaest klauzula standarda, do plana primene i ove čekliste. Ako se pojavi potreba za dodatnim tekstom – recimo, dubljim pogledom na neki deo koji se u praksi pokaže kao čest kamen spoticanja – tu smo.