ISO 27031: Vođenje vežbe, učenje iz testova i audit – zatvaramo klauzulu 11 (11.2.4–11.5)

11.2.4 – Planiranje vežbe

Vežba treba pažljivo da se planira da bi se smanjio rizik da incident tokom vežbe naruši sposobnost same usluge. Upravljanje tim rizikom treba da odgovara nivou vežbe koja se sprovodi, i može uključivati:

• obezbeđivanje da su svi podaci bekapovani neposredno pre vežbe
• sprovođenje vežbi u izolovanim okruženjima
• zakazivanje vežbi van radnog vremena ili u tihim periodima poslovnog ciklusa, uz znanje krajnjih korisnika

Vežbe treba da budu realistične, pažljivo isplanirane i dogovorene sa zainteresovanim stranama, radi minimalnog rizika ometanja poslovnih procesa – i ne treba da se sprovode tokom stvarnih incidenata. Svaka vežba treba da ima "referentni okvir", dogovoren i potpisan unapred od strane sponzora vežbe, koji može uključivati petnaest elemenata:

• opis
• ciljeve
• obim
• pretpostavke
• ograničenja
• rizike
• kriterijume uspeha
• resurse
• uloge i odgovornosti
• okviran raspored
• prikupljanje podataka tokom vežbe
• evidenciju otvorenih pitanja
• evidentiranje toka vežbe/incidenata
• debrifing
• post-vežbovne akcije (praćenje i izveštavanje)

Ovaj spisak od petnaest elemenata pretvara "hajde da testiramo" u nešto što se stvarno može odobriti i ponoviti – bez njega, svaka vežba je ad hoc improvizacija koja zavisi od toga ko je te nedelje slobodan da je organizuje.

Primer: Za prvu planiranu vežbu oporavka identiteta kod VoxServis-a, referentni okvir bi trebalo da precizira: cilj (proveriti da li se sinhronizacija identiteta može vratiti u dogovorenom roku), obim (samo domenski kontroler i njegova sinhronizacija, ne cela infrastruktura), pretpostavke (vežba se izvodi van radnog vremena, agenti u Novom Sadu su unapred obavešteni), rizike (mogućnost da vežba sama izazove kratak prekid, ublažena time što se radi van radnog vremena uz sveže bekapovane podatke), i kriterijume uspeha (sinhronizacija se vraća za manje od 30 minuta, uz uspešno korišćeno privremeno rešenje tokom trajanja vežbe). Bez ovog dokumenta, potpisanog unapred, VoxServis bi rizikovao da vežba postane baš onaj neplanirani incident koji pokušava da spreči.

Šta treba uraditi

• Napraviti šablon referentnog okvira sa svih petnaest elemenata, tako da se za svaku novu vežbu samo popunjava, ne izmišlja iznova.
• Tražiti potpis sponzora vežbe pre izvođenja – ne posle, kad je rizik već preuzet.
• Posebno razraditi deo o riziku same vežbe – šta se dešava ako vežba, umesto da testira prekid, sama izazove pravi prekid.
• Izbegavati najčešću grešku – vežbu organizovanu neformalno, bez potpisanog referentnog okvira, gde niko unapred nije procenio rizik koji sama vežba nosi, niti definisao jasne kriterijume uspeha.

11.2.5 – Faze zasnovane na uzbuni i različiti nivoi oporavka

Organizacija treba da vežba sve elemente oporavka IT usluge, srazmerno svojoj veličini, složenosti i opsegu upravljanja kontinuitetom poslovanja. Vežbanje ne treba da se fokusira isključivo na oporavak i nastavak rada, nego treba da uključi i pouzdanost sposobnosti otpornosti, praćenje sistema i upravljanje uzbunama. Standard opisuje progresiju kroz četiri faze, sa rastućim poverenjem:

• familijarizacija – stoni pregled procesa aktivacije i oporavka, bez diranja produkcije
• komponenta – testovi pojedinačne aplikacije ili infrastrukturne komponente
• integrisano – integrisani testovi oporavka usluge od kraja do kraja
• digitalna otpornost – IT komponente i usluge od kraja do kraja stvarno prebacuju između primarne i sekundarne strane, uživo

U svakoj vežbi treba razmotriti devet elemenata:

• uređaje vezane za fizičku bezbednost unutar serverske sobe – detekcija požara/curenja vode, evakuacija, klimatizacija, monitoring okruženja, protokoli uzbune, električne instalacije
• infrastrukturu – otpornost mrežne povezanosti, raznovrsnost, bezbednost mreže uključujući antivirus i detekciju upada
• hardver
• softver
• podatke
• usluge
• procese
• ljude
• ulogu i odgovor dobavljača

Ova četvorostepena progresija je preciznija verzija onoga što smo neformalno opisali u prošlom tekstu – sad imamo tačna imena i tačan redosled: familijarizacija, komponenta, integrisano, digitalna otpornost. Devetorka elemenata je podjednako korisna – lako je testirati samo hardver i softver, a zaboraviti fizičku bezbednost prostorije, ljude, ili ulogu dobavljača, iako su svi podjednako deo iste slike.

Primer: Primenimo četiri faze na identitetsku zavisnost kod VoxServis-a: familijarizacija – tim prolazi kroz zapisanu proceduru za stolom; komponenta – restore domenskog kontrolera testiran izolovano, van produkcije; integrisano – ceo lanac testiran zajedno (autentifikacija → CRM → telefonija), da bi se videlo da li integracije rade kad se sve poveže; digitalna otpornost – stvaran, uživo failover sa Beograda na Novi Sad, dok sistem radi, sa pravim (ili gotovo pravim) saobraćajem poziva. VoxServis trenutno nije prošao nijednu od ove četiri faze formalno. Od devet elemenata koje treba razmotriti, fizička bezbednost serverske sobe i uloga dobavljača verovatno nikad nisu ni pomenuti u kontekstu ove vežbe – pažnja ide skoro isključivo na softver i hardver.

Šta treba uraditi

• Proći kroz sve četiri faze redom – familijarizacija, komponenta, integrisano, digitalna otpornost – sa jasnim kriterijumima za prelazak na sledeću.
• Za svaku fazu, potvrditi da su svih devet elemenata razmotreni, ne samo tehnički (hardver, softver).
• Posebno uključiti elemente koji se lako preskoče – fizičku bezbednost prostorije i ulogu dobavljača – u plan vežbe, ne samo u teoriji.
• Izbegavati najčešću grešku – pokušaj da se preskoči direktno na "integrisano" ili čak "digitalnu otpornost" bez prve dve faze, ili testiranje samo hardvera/softvera dok se ignorišu fizička bezbednost, ljudi i dobavljači.

11.2.6 – Vođenje vežbe

Treba razviti jasnu kontrolnu strukturu vežbe sa ulogama i odgovornostima dodeljenim odgovarajućim pojedincima, koja može uključivati:

• kontrolora vežbe – učesnik ili učesnici sa ukupnom kontrolom nad testom
• komunikacije tokom vežbe
• potvrdu da ima dovoljno osoblja da se vežba bezbedno sprovede
• dovoljno posmatrača i/ili facilitatora da zabeleže tok vežbe i vode evidenciju otvorenih pitanja
• ključne prekretnice vežbe
• protokole za kraj vežbe
• protokole za hitno zaustavljanje vežbe

Vežba treba da se vodi kroz tu kontrolnu strukturu kako bi se obezbedilo da ciljevi i ključne prekretnice budu ispunjeni, da sav materijal i aktivnosti vežbe imaju odgovarajući nivo poverljivosti, da se tekući rizici prate i ublažavaju, da su posetioci/posmatrači ovlašćeni, da se tok vežbe dosledno beleži, i da svi učesnici prođu debrifing, uz prikupljene povratne informacije.

Protokol za hitno zaustavljanje je element koji se najlakše preskoči, jer niko ne voli da planira scenario u kom sopstvena vežba krene po zlu – ali baš to je razlika između kontrolisanog rizika i nekontrolisanog. Bez unapred definisanog "stop" mehanizma, tim koji primeti da vežba izmiče kontroli gubi dragoceno vreme odlučujući ko ima ovlašćenje da je prekine.

Primer: Za planirani uživo failover test kod VoxServis-a, potrebno je unapred odrediti ko je kontrolor vežbe sa ovlašćenjem da je zaustavi, šta tačno pokreće hitno zaustavljanje (na primer, ako stvarni pozivi klijenata počnu da se gube, ne samo testni saobraćaj), i kojim tačno koracima se vežba bezbedno prekida i vraća na prethodno stanje. Bez ovoga, ako uživo test identiteta stvarno počne da utiče na prave pozive, tim bi improvizovao odluku o prekidu usred vežbe.

Šta treba uraditi

• Imenovati kontrolora vežbe za svaku planiranu vežbu, sa jasnim ovlašćenjem da je zaustavi.
• Definisati eksplicitan protokol i uslove za hitno zaustavljanje – šta tačno pokreće prekid, ne samo opšti osećaj da "nešto nije u redu".
• Planirati debrifing i prikupljanje povratnih informacija odmah posle vežbe, ne posle nekoliko dana kad se detalji zaborave.
• Izbegavati najčešću grešku – vežbu isplaniranu do detalja u pogledu "šta testiramo", bez ikad definisanog "kako je bezbedno prekidamo ako krene po zlu".

11.3 – Učenje iz testova

Na kraju vežbe, njeni nalazi treba odmah da se pregledaju i isprate. Ovo treba da uključi:

• prikupljanje rezultata i nalaza
• analizu rezultata i nalaza naspram ciljeva vežbe i kriterijuma uspeha
• identifikovanje rupa
• dodeljivanje akcionih tačaka sa definisanim rokovima
• kreiranje izveštaja o vežbi za formalno razmatranje od strane sponzora vežbe
• konsolidovanje i praćenje akcija iz izveštaja

Ovo je isti obrazac "zatvaranja kruga" koji smo videli kod de-eskalacije posle stvarnog incidenta – samo sad primenjen na vežbu. Bez formalnog izveštaja i praćenih akcija, čak i uspešno sprovedena vežba gubi veći deo svoje vrednosti, jer pouke ostaju u sećanju učesnika umesto u sistemu.

Primer: Posle prve vežbe oporavka identiteta kod VoxServis-a, ciklus bi trebalo da izgleda: rezultati se prikupljaju (izmereno vreme detekcije, izmereno vreme odgovora, da li je privremeno rešenje funkcionisalo), porede se sa kriterijumima uspeha iz referentnog okvira, identifikuju se rupe (možda se ispostavi da je detekcija i dalje presporija nego što je potrebno), dodeljuju se konkretne akcije sa rokovima, i piše se izveštaj koji sponzor vežbe formalno pregleda. Bez ovog poslednjeg koraka, rizik je da se prva vežba proglasi uspešnom "u principu" i da se identifikovane rupe nikad zvanično ne zatvore.

Šta treba uraditi

• Posle svake vežbe, proći kroz svih šest koraka redom – od prikupljanja rezultata do praćenja akcija, ne stati na neformalnom "prošlo je dobro".
• Pisati kratak izveštaj za svaku vežbu i tražiti formalni pregled sponzora, čak i kad je vežba mala.
• Pratiti dodeljene akcije do zatvaranja, ne samo do dodele – rok bez praćenja retko se ispuni.
• Izbegavati najčešću grešku – vežbu posle koje tim neformalno zaključi da je "prošlo dobro", bez pisanog izveštaja, dodeljenih rokova, ili garancije da će rupe zaista biti zatvorene.

11.4 – Audit IRBC-a

Plan internog audita IRBC-a treba da definiše i dokumentuje kriterijume, obim, metod i učestalost audita. Interni auditi IRBC-a treba da se sprovode godišnje. Plan audita treba da obezbedi da su imenovani kvalifikovani auditori, uz objektivnost i nepristrasnost procesa audita. Treba uspostaviti plan otklanjanja nedostataka da bi se obezbedilo da se nedostaci identifikovani internim auditima isprave. Plan audita treba da obuhvati i spoljne strane – na primer, dobavljače usluga autsorsinga treba auditovati za njihovu sposobnost da podrže IRBC strategije i planove organizacije, i u svakodnevnom radu i u odgovoru na katastrofu. Interni audit treba sprovesti i kad postoje značajne promene kritičnih IT servisa, zahteva kontinuiteta poslovanja, ili IRBC zahteva. Rezultati IRBC audita treba da se beleže i izveštavaju, a menadžment treba da pregleda rezultate i status korektivnih akcija.

"Godišnje, plus svaki put kad se nešto značajno promeni" je konkretan, merljiv zahtev koji sprečava da audit postane formalnost koja se radi "kad se neko seti". Uključivanje dobavljača u obim audita direktno se nadovezuje na proveru sposobnosti dobavljača iz ranijeg teksta – nije dovoljno jednom proveriti sposobnost dobavljača, nego to periodično auditovati kao deo istog programa.

Primer: VoxServis trenutno nema definisan godišnji IRBC audit ciklus. Kad ga uvede, prvi audit bi trebalo da otkrije tačno one rupe koje smo identifikovali kroz celu ovu seriju – nedostatak formalnog vlasništva, nedostatak monitoring pragova, i nedostatak testirane sposobnosti cloud dobavljača. Uvođenje cloud CRM-a pre dve godine je bila tačno ona "značajna promena" koja je trebalo da pokrene vanredni audit – da postoji definisan okidač za to, propust ne bi ostao neotkriven dve godine.

Šta treba uraditi

• Uspostaviti godišnji plan IRBC audita sa definisanim kriterijumima, obimom i metodom.
• Definisati okidače za vanredne audite – značajne promene servisa, zahteva ili IRBC-a – ne čekati na godišnji ciklus ako se nešto bitno promeni u međuvremenu.
• Proširiti obim audita da eksplicitno uključi kritične dobavljače, ne samo interne procese.
• Izbegavati najčešću grešku – izostanak audita IRBC-a jer ne postoji spoljni auditor koji to zahteva, za razliku od sertifikacionog audita za ISO 27001 ili 22301.

11.5 – Kontrola dokumentovanih informacija

Kontrole treba uspostaviti nad IRBC zapisima da bi se obezbedilo da ostanu čitljivi, lako prepoznatljivi i dostupni za pronalaženje, uz odgovarajuće čuvanje i zaštitu. Kontrole nad IRBC dokumentacijom treba da obezbede da:

• dokumenti su odobreni za adekvatnost pre izdavanja
• dokumenti se pregledaju i ažuriraju po potrebi i ponovo odobravaju
• izmene i trenutni status revizije dokumenata su identifikovani
• relevantne verzije primenljivih dokumenata su dostupne na mestima upotrebe
• dokumenti spoljnog porekla su identifikovani, uz kontrolisanu distribuciju
• nenamerna upotreba zastarelih dokumenata je sprečena, uz odgovarajuću oznaku takvih dokumenata ako se zadržavaju iz bilo kog razloga

Ovo se nadovezuje direktno na raniji zahtev da plan postoji na više lokacija – sad standard dodaje ključan uslov: sve te kopije moraju biti iste, ažurne verzije. Više kopija zastarelog dokumenta je jednako loše kao nedostatak dokumenta uopšte, možda i gore, jer stvara lažan osećaj sigurnosti.

Primer: Ako VoxServis sad, posle ove serije, napiše i odobri proceduru oporavka identiteta, kontrola dokumentacije znači da svaka kopija – na deljenom disku, štampana u fascikli kod supervizora, na ličnom uređaju odgovorne osobe – mora biti ista verzija, sa jasno vidljivim datumom poslednjeg pregleda. Kad se infrastruktura sledeći put promeni, sve te kopije moraju da se ažuriraju zajedno – ne da neko za šest meseci izvuče staru, štampanu verziju iz fascikle koja više ne odgovara stvarnoj arhitekturi.

Šta treba uraditi

• Napraviti spisak svih lokacija/kopija svakog kritičnog IRBC dokumenta, sa procesom koji obezbeđuje da se sve ažuriraju istovremeno.
• Staviti jasno vidljiv datum poslednjeg pregleda i odobrenja na svaki dokument.
• Posebno obratiti pažnju na štampane i lokalno sačuvane kopije – njih je najlakše zaboraviti pri ažuriranju.
• Izbegavati najčešću grešku – ažuriranje dokumenta na jednom mestu, dok zastarele kopije ostaju u opticaju i mogu da budu upotrebljene tačno u trenutku kad je najbitnije da procedura bude aktuelna.