ISO 27031: Priprema pre incidenta (klauzula 8.1.1–8.1.4)

8.1.1 – Šta se dešava kad nešto otkaže

Svaki incident traži isto:

• potvrditi šta se desilo i koliko je ozbiljno
• preuzeti kontrolu nad situacijom
• rešiti incident
• komunicirati sa svima kojima je bitno

Tim koji to radi – IRT, incident response team, tim za odgovor na incidente – zaustavlja uzrok incidenta, njegov način delovanja i efekat, i vraća poslovnu aktivnost u funkciju. IRBC se uključuje tek kad se pređe prag: RTO ili RPO ne mogu da se ispune, čak ni potencijalno, ili je pogođen bar jedan kritičan poslovni proces. Razlika između običnog odgovora na incident i IRBC-a nije u samom procesu – identičan je. Razlika je u uslovu aktivacije, razmeri uticaja, i nivou ovlašćenja za koordinaciju akcija.

Primer: Kad je domenski kontroler otkazao, incident kod VoxServis-a je tretiran kao standardan tiket, bez IRT-a, bez jasnog trenutka predaje. Zato je test posle incidenta čekao mesec dana na odobrenje tri osobe – ovlašćenje nije bilo unapred definisano kod nikoga.

Šta treba uraditi

• Formalno definisati IRT sa imenovanim ulogama – ko je u timu, ko preuzima kontrolu, ko komunicira sa strankama – umesto da se tim sastavlja improvizovano u trenutku incidenta.
• Definisati prag za eskalaciju na IRBC nivo (RTO/RPO ugroženi, kritičan proces pogođen) i uneti ga u proceduru za upravljanje incidentima kao pisano pravilo, ne kao nepisanu praksu.
• Unapred odrediti ko ima ovlašćenje da eskalira i aktivira IRBC, tako da odobrenje ne čeka na sastanak ili saglasnost više ljudi usred krize.
• Zapisati tok predaje odgovornosti u oba smera – ko preuzima kad se IRBC aktivira, i ko je preuzima nazad kad se kriza reši, radi pripreme izveštaja.

8.1.2–8.1.3 – Sposobnosti oporavka i uspostavljanje IRBC-a

Faza planiranja treba da postavi tri stvari:

• IRBC strategiju i plan, usklađene sa zahtevima iz BIA
• kriterijume po kojima se prati stepen spremnosti IT-a
• spisak resursa (tehničkih i drugih) potrebnih da IRBC timovi rade u dogovorenom roku

Standard je jasan i oko jedne stvari: IRBC ugrađen u IT uslugu od početka je jeftiniji, bolje razumljiv i otporniji od IRBC-a nalepljenog naknadno na već postojeći sistem. Naknadno dodavanje je po pravilu složenije, skuplje i remeti rad sistema koji već funkcioniše.

Primer: VoxServis je u potpunosti u drugoj situaciji – sve već postoji, izgrađeno bez ijedne misli o IRBC-u. To ne može da se promeni unazad, ali svaka sledeća nova usluga, na primer planirano proširenje u Novom Sadu, može od prvog dana da uključi ove zahteve, umesto da im se dodaju naknadno.

Šta treba uraditi

• Za svaku novu IT uslugu, uključiti IRBC zahteve već u fazu dizajna: strategiju usklađenu sa BIA, kriterijume za praćenje spremnosti, i spisak potrebnih resursa – pre nego što usluga krene u produkciju.
• Za postojeću infrastrukturu (kao većinu VoxServis-ovog sistema) svesno prihvatiti da će IRBC biti nadograđen naknadno, i planirati vreme i budžet za to unapred, umesto da se radi na brzinu posle sledećeg incidenta.
• Za svaki novi projekat širenja napraviti kratku listu IRBC pitanja koja se postavljaju pre potpisivanja projekta ili ugovora, ne posle useljenja opreme.
• Dokumentovati ove procese i redovno ih ažurirati – IRBC ne sme da ostane nezapisan dogovor u glavama nekoliko ljudi.

8.1.4 – Postavljanje ciljeva

Ciljevi se ne postavljaju jednom – grade se kroz ponavljajući ciklus:

• popisati poznate scenarije incidenata i znake koji ih najavljuju
• odrediti posle koliko vremena problem mora da bude primećen
• odrediti posle koliko vremena mora da se reaguje
• testirati da li su ti rokovi ostvarivi
• ponoviti proces sa svakim novim iskustvom

Bez konkretnih brojeva, "brzo otkrivanje" i "brz odgovor" ostaju parole bez merljivog sadržaja – niko ne može da kaže da li je sistem ispunio cilj ili ne, jer cilj nikad nije ni bio definisan kao broj.

Primer: Primenjeno na VoxServis-ovu zavisnost identiteta: poznat scenario je kvar servisa sinhronizacije. Znaci koji ga najavljuju su neuspeli pokušaji replikacije i greške u logu. Vreme za detekciju je trenutno nedefinisano – incident je otkriven tek kad su se agenti počeli žaliti. Vreme za odgovor je, iz istog razloga, takođe nedefinisano.

Šta treba uraditi

• Za svaki poznat scenario incidenta, napisati konkretne znake koji ga najavljuju – ne čekati da scenario postane opštepoznat tek posle prvog stvarnog incidenta.
• Postaviti dva konkretna vremenska praga po scenariju: posle koliko minuta se kašnjenje u detekciji smatra problemom, i posle koliko minuta kašnjenje u odgovoru.
• Testirati te pragove kroz vežbe ili simulacije, ne samo na papiru – da bi se videlo da li su realno ostvarivi sa trenutnim resursima i osobljem.
• Posle svakog stvarnog incidenta, dodati novi scenario ili prepraviti postojeći u ovoj listi, tako da se baza scenarija širi sa iskustvom, umesto da ostane ista od prvog dana.