ISO 27031: Određivanje IRBC strategija – opšti pristup, veštine i objekti (klauzula 9.1–9.2.3)

9.1 – Opšte

Organizacija treba da razmotri niz opcija za spremnost svojih kritičnih IT servisa na incidente, uzimajući u obzir i povećanje zaštite i pripremu za oporavak i restauraciju posle neplaniranog prekida. Opcije mogu uključivati:

  • interne aranžmane
  • usluge koje se firmi isporučuju
  • usluge koje pružaju jedna ili više spoljnih strana

IRBC strategije treba da definišu pristupe za sprovođenje potrebne sposobnosti oporavka tako da principi prevencije, detekcije, odgovora, oporavka i restauracije budu na mestu. Strategija treba da bude dovoljno fleksibilna da prati različite poslovne strategije, i da uzme u obzir sledeća interna ograničenja i faktore:

  • poslovne ciljeve i prioritete
  • strategije kontinuiteta poslovanja
  • budžet
  • dostupnost resursa
  • potencijalne troškove i koristi
  • tehnološka ograničenja
  • apetit organizacije za rizik
  • postojeću IRBC strategiju firme, ako postoji

Ovo je eksplicitna odbrana od najčešće greške u praksi – kupovine rešenja pre nego što se opcije uopšte razmotre. Standard traži da se razmotri niz opcija, ne da se prva ideja odmah pretvori u nabavku.

Primer: Za zavisnost identiteta koju pratimo kroz seriju, dosadašnji "pristup" VoxServis-a bio je jednostavan – kupiti jači server i nadati se da se incident neće ponoviti. Klauzula 9.1 traži da se prvo formalno razmotri niz opcija: da li je bolje uvesti drugi domenski kontroler (interni aranžman), preći na spoljnu identitetsku uslugu koja već ima ugrađenu redundansu (eksterna opcija), ili nešto treće – uz svestan izbor zasnovan na budžetu, apetitu za rizik i postojećim ograničenjima, ne prvi predlog koji je pao na sto.

Šta treba uraditi

  • Za svaki kritičan servis, napraviti kratak pregled razmotrenih strategijskih opcija – ne samo izabrane – sa razlozima zašto je jedna opcija odabrana u odnosu na druge, prema budžetu, riziku i tehničkim ograničenjima.
  • Pre nego što se bilo šta nabavi, proveriti da li su opcije zaista upoređene naspram sve osam navedenih ograničenja, ili je odluka doneta samo na osnovu tehničke izvodljivosti.
  • Izbegavati najčešću grešku – biranje prve tehnički izvodljive opcije bez formalnog poređenja sa alternativama, tipa "uzećemo ono što IT sektor predlaže" umesto svesnog vrednovanja.

9.2.1 – Opšte i strategijske opcije na visokom nivou

Strategijske opcije zavise od strukture IT-a, koja može biti vrlo složena, i treba da uzmu u obzir različite scenarije:

  • nedostupnost IT objekata
  • gubitak fizičkog hardvera
  • kompromitovan softver
  • kompromitovani podaci
  • kompromitovan lanac snabdevanja IT-a
  • nedostupnost kompetentnog IT osoblja

Na visokom nivou, standard nudi sedam obrazaca strategije koji se mogu kombinovati za različite servise:

  • dvostruka lokacija – više data centara
  • saradnja – slična organizacija preuzima ulogu
  • povratak u bezbedno stanje – dokumentovane procedure za vraćanje sistema
  • oporavak podataka – implementacija strategija bekapa
  • preuzimanje od strane dobavljača – delegiranje aktivnosti dobavljačima
  • alternativno snabdevanje – identifikacija alternativnih dobavljača radi redundanse funkcija koje se inače pružaju interno
  • minimizacija – izolacija IT-a i određivanje parametara koji omogućavaju minimalnu uslugu dok se ne izvrši puna restauracija

Ova sedmorka je koristan zajednički rečnik – umesto da svaka firma izmišlja sopstvenu terminologiju. Retko je potrebna samo jedna strategija po servisu; većina realnih rešenja je mešavina dve ili tri.

Primer: Za zavisnost identiteta, realno rešenje kombinuje bar tri od sedam obrazaca. Dvostruka lokacija: VoxServis već ima dve lokacije (Beograd i Novi Sad) – drugi domenski kontroler u Novom Sadu je prirodno proširenje postojeće infrastrukture, ne nova investicija od nule. Povratak u bezbedno stanje: dokumentovana, testirana procedura restore-a, umesto improvizacije. Minimizacija: definisan degradiran režim rada u kom agenti mogu da se uloguju lokalno i rade sa keširanim podacima dok se sinhronizacija ne vrati, umesto potpunog gašenja rada. Sve troje zajedno je realističnije i jeftinije rešenje od pokušaja da se postigne "visoka redundansa za sve" primenom samo jedne strategije.

Šta treba uraditi

  • Za svaki kritičan servis, zapisati koja kombinacija od sedam strategijskih obrazaca je izabrana i zašto, uz mapiranje na scenarije koje strategija pokriva – gubitak objekta, hardvera, softvera, podataka, lanca snabdevanja, osoblja.
  • Proveriti da izabrana kombinacija pokriva više od jednog scenarija – jedna strategija retko rešava sve.
  • Izbegavati najčešću grešku – oslanjanje samo na jedan obrazac, najčešće "oporavak podataka" odnosno bekap, uz pretpostavku da to pokriva sve scenarije. Bekap ne pomaže ako je problem u dostupnosti objekta, softvera ili osoblja, ne u gubitku podataka.

9.2.2 – Veštine i znanje

Firma treba da identifikuje strategije za održavanje ključnih IT veština i znanja, što se može proširiti i van zaposlenih na ugovarače i druge sa specijalističkim znanjem. Strategije uključuju:

  • dokumentovanje načina na koji se kritični IT servisi izvode
  • višestruku obuku (cross-training) IT osoblja i ugovarača radi redundanse veština
  • namerno razdvajanje ključnih veština radi smanjenja koncentracije rizika – fizičko razdvajanje osoblja sa ključnim veštinama, ili obezbeđivanje da više od jedne osobe poseduje potrebnu ključnu veštinu
  • zadržavanje i upravljanje znanjem

Ovo direktno rešava problem koji smo identifikovali još u ranijim tekstovima ove serije – znanje koncentrisano kod jedne osobe je rizik koji retko ko formalno prepozna kao rizik, jer "ta osoba je uvek tu, dok jednog dana nije".

Primer: Sad kad smo tri puta prošli kroz istu rupu, rešenje postaje konkretno kod VoxServis-a: dokumentovati tačan postupak oporavka sinhronizacije identiteta korak po korak; obučiti bar još jednu osobu da ga izvede pod nadzorom, pa samostalno; i svesno izbeći da ta ista osoba bude jedina koja ima administratorski pristup i cloud i on-premise strani sistema. Ovo poslednje je posebno bitno – ako je ista osoba jedina koja zna i domensku stranu i cloud stranu, koncentracija rizika je duplo veća nego što izgleda.

Šta treba uraditi

  • Dokumentovati korak-po-korak postupak za svaku kritičnu IT veštinu.
  • Voditi evidenciju ko je obučen za koju veštinu, sa ciljem od najmanje dve osobe po ključnoj veštini.
  • Napraviti plan zadržavanja znanja pri odlasku ključnog osoblja – predaja, dokumentacija, period preklapanja.
  • Izbegavati najčešću grešku – cross-training koji postoji na papiru kao ideja ("trebalo bi da se obučimo međusobno"), ali se nikad ne sprovede u praksi jer redovan posao uvek ima prioritet, dok se ne desi incident u kom se ispostavi da druga osoba ipak ne zna dovoljno.

9.2.3 – Objekti

Prema identifikovanim rizicima, firma treba da osmisli strategije za smanjenje uticaja nedostupnosti normalnih IT objekata, što može uključivati:

  • alternativne objekte (lokacije) unutar organizacije, uključujući privremeno raseljavanje drugih aktivnosti
  • alternativne objekte koje obezbeđuju druge organizacije
  • alternativne objekte koje obezbeđuju specijalizovane treće strane
  • rad od kuće ili sa drugih udaljenih lokacija
  • druge dogovorene odgovarajuće radne prostore
  • korišćenje alternativne radne snage na već uspostavljenoj lokaciji
  • alternativne objekte koji mogu da se transportuju do mesta poremećaja radi direktne zamene dela fizičke imovine

Pri razmatranju alternativnih prostora, standard traži da se uzmu u obzir: bezbednost lokacije, pristup osoblja, blizina postojećim objektima, dostupnost, i profil rizika u slučaju cloud rešenja. "Blizina postojećim objektima" je namerno dvosekla stavka koju standard postavlja bez razrešenja – previše blizu, i alternativa deli isti regionalni rizik (nestanak struje, poplava, isti telekom čvor) kao i primarna lokacija; predaleko, i osoblju je teško da fizički stigne kad zatreba. Ravnoteža zavisi od konkretne firme.

Primer: VoxServis već ima prirodnu alternativu ugrađenu u sopstvenu strukturu – lokaciju u Novom Sadu. Pitanje koje standard traži da se svesno postavi jeste da li je ta udaljenost dovoljna da izbegne deljeni regionalni rizik (drugačiji elektrodistributivni sistem, drugačiji internet provajder, dovoljno daleko da ne dele isti incident), a istovremeno dovoljno blizu da osoblje iz Beograda može, ako zatreba, fizički da stigne. Za manji tim koji radi hibridno, rad od kuće je već delimično postojeća opcija – ali nikad formalno definisana kao IRBC strategija sa jasnim uslovima aktivacije: koji sistemi su dostupni od kuće, kojim putem, sa kakvim bezbednosnim merama.

Šta treba uraditi

  • Za svaki kritičan servis izabrati strategiju za objekte, sa procenom bezbednosti, pristupa osoblja, blizine i dostupnosti.
  • Za hibridnu ili cloud komponentu, proceniti i profil rizika te alternative – šta se dešava ako i sam cloud region ima problem.
  • Konkretno proveriti da li druga lokacija firme deli infrastrukturu sa primarnom (isti elektrodistributivni sistem, isti internet provajder na poslednjoj milji) – ne pretpostaviti da je "druga lokacija" automatski nezavisna.
  • Izbegavati najčešću grešku – da se druga lokacija firme automatski smatra "dovoljnom" alternativom bez ikad proverene procene deljenog rizika.

Comments

Popular posts from this blog

Šta je ISO 27001 i da li je mojoj firmi stvarno potreban?

ISO 22301:2019 u praksi — Praktična obuka na primeru fabrike piva

ISO 27031: Upravljanje IRBC-om i usklađivanje sa ciljevima kontinuiteta (klauzula 6.1–6.3)