Zašto sad i ISO 22301?

Dosad smo na ovom blogu pričali skoro isključivo o ISO 27001 — kako zaštititi informacije, kako ih klasifikovati, ko sme šta da vidi. Ali negde na putu, dok smo prolazili kroz klauzulu 8.4 (kontinuitet informacione bezbednosti), stalno se pojavljivalo isto pitanje: a šta ako sistem padne, a ne zato što je neko hakovan, nego zato što je magacin pod vodom ili je pukla optika u ulici?

Tu na scenu stupa ISO 22301 — standard za sistem upravljanja kontinuitetom poslovanja (Business Continuity Management System, skraćeno BCMS). Nije striktno InfoSec standard, ali se sa njim toliko često preklapa da smo odlučili da ga obradimo na istom mestu, istim stilom kao i 27001: bez žargona, sa konkretnim primerima i bez uljepšavanja koliko je posla zaista potrebno.

Posle ISO 22301 serije, prelazimo i na ISO 27031 — standard koji se fokusira uže na IT/ICT spremnost za kontinuitet poslovanja i koji će vam, ako radite u IT-ju ili bezbednosti, verovatno biti još bliži.

Kompanija koju ćemo pratiti kroz celu seriju

Kao i kod 27001 serije, lakše je pratiti standard kroz konkretan primer nego kroz apstraktna pravila. Kroz ovu seriju pratićemo "Elektrotehnu" — proizvođača i distributera elektro opreme sa 520 zaposlenih, sedištem u Beogradu i dva regionalna skladišta (Novi Sad, Niš). Imaju sopstveni data centar sa ERP sistemom i proizvodnim/skladišnim sistemima on-premise, a deo poslovanja je već prebačen u cloud — e-mail i kancelarijski alati, CRM aplikacija, deo rezervnih kopija.

Ova kombinacija — solidan on-premise sistem plus rastući deo u cloudu, više lokacija, više odeljenja koja moraju da se usklade — je realnost velikog broja srednjih i većih firmi u Srbiji, i upravo je zato Elektrotehna dobar primer za ovaj standard: dovoljno je velika da pokaže sve pokretne delove koje standard traži da se organizuju, a dovoljno prepoznatljiva da se svaki čitalac u nečemu pronađe.

Pratićemo ih kroz celu seriju — uključujući i noć kad im je pao ERP sistem na 30 sati, i sve što su posle toga, klauzulu po klauzulu, promenili da se to ne ponovi.

Šta je zapravo ISO 22301?

ISO 22301:2019 je standard koji od firme traži da odgovori na jedno neprijatno pitanje unapred: šta radimo kad nas nešto ozbiljno prekine u radu, i koliko dugo možemo da izdržimo pre nego što to postane egzistencijalni problem?

To "nešto" ne mora biti sajber napad. Može biti:

• požar ili poplava u poslovnom prostoru ili magacinu,
• nestanak struje ili interneta koji traje duže od par sati,
• ključni dobavljač koji odjednom prestane da isporučuje,
• zaposleni koji zna sve o jednom kritičnom procesu, a ode na duže bolovanje ili da otkaz,
• ili, da — ransomware napad koji vam zaključa sve fajlove.

BCMS ne pokušava da spreči sve ove događaje (to bi bilo nerealno). Umesto toga, traži da unapred znate koji procesi su vam toliko kritični da ne smete da stanete duže od X sati, i da imate plan — proveren, ne samo napisan — kako da nastavite da radite ili se brzo vratite u pogon.

Čime se ISO 22301 razlikuje od ISO 27001?

Najlakše je zapamtiti ovako: ISO 27001 štiti informacije od gubitka poverljivosti, integriteta i dostupnosti. ISO 22301 štiti sposobnost firme da nastavi da posluje, bez obzira na uzrok prekida.

Preklapanje se dešava tačno na dostupnosti. Ako vam padne server sa bazom klijenata, to je i bezbednosni incident (ISO 27001, klauzula 8.4) i scenario kontinuiteta poslovanja (ISO 22301, klauzula 8). Razlika je u fokusu: 27001 vas pita "da li je neko mogao da vidi ili izmeni te podatke", a 22301 vas pita "koliko dugo možemo da radimo bez tog servera, i šta radimo u međuvremenu".

Oba standarda dele istu osnovnu strukturu (tzv. High-Level Structure — klauzule 4 do 10 su konceptualno iste), pa ako ste već prošli kroz našu 27001 seriju, dobar deo terminologije će vam odmah biti poznat: kontekst organizacije, liderstvo, planiranje, podrška, operacija, ocena performansi, poboljšanje.

Zašto bi InfoSec ljudi trebalo da znaju za ovaj standard

U praksi, u firmama u Srbiji, kontinuitet poslovanja često "padne" na istog čoveka koji se bavi i informacionom bezbednošću — jednostavno zato što niko drugi u firmi ne razmišlja sistematski o riziku i otpornosti. Ako ste taj čovek, ISO 22301 vam daje strukturu za nešto što biste verovatno ionako morali da radite parcijalno.

Ima i formalniji razlog: ISO 27001 u klauzuli 8.4 direktno traži da firma planira kontinuitet informacione bezbednosti tokom prekida. Standard vam ne kaže kako da to uradite detaljno — ISO 22301 vam to kaže. Ako već imate sertifikat 27001 ili radite na njemu, elementi BCMS-a (posebno analiza uticaja na poslovanje i planovi oporavka) direktno ojačavaju taj deo vaše dokumentacije.

Za koga je ovo realno relevantno u Srbiji

Ovde ćemo biti iskreni, kao i uvek na ovom blogu: pun ISO 22301 sertifikat ima smisla za relativno uzak krug firmi — one kojima ugovori sa klijentima ili regulativa direktno traže dokazanu otpornost (finansijski sektor, kritična infrastruktura, veći IT/proizvodni igrači koji rade za strane klijente sa strogim zahtevima).

U praksi, standard najviše "diše" kod firmi sličnih Elektrotehni — dovoljno velikih da imaju više odeljenja, više lokacija, i realnu zavisnost od IT sistema koje niko pojedinačno ne kontroliše u potpunosti. Manje firme svakako mogu da primene iste principe u lakšoj formi (o tome smo pisali u prethodnim tekstovima), ali tek kod firmi sa desetinama ili stotinama zaposlenih standard počinje da rešava probleme koje mala firma jednostavno nema — usklađivanje odeljenja, dokumentacija koja ne zavisi od jedne osobe, planovi koji prežive promenu kadra.

Za mnoge od ovih firmi, cilj neće biti sertifikat — cilj će biti da prvi put sednu i napišu odgovor na pitanje "šta bismo mi zaista uradili da nam padne ključni sistem sutra ujutru". To pitanje samo po sebi već vredi više od papira.

Kako je standard strukturiran — kratak pregled

Kao i kod 27001, jezgro standarda su klauzule 4–10:

• 4 – Kontekst organizacije: šta je u obuhvatu BCMS-a, ko su zainteresovane strane i šta očekuju.
• 5 – Liderstvo: posvećenost rukovodstva, politika kontinuiteta, uloge i odgovornosti.
• 6 – Planiranje: ciljevi kontinuiteta poslovanja i upravljanje rizicima koji ga ugrožavaju.
• 7 – Podrška: resursi, kompetencije, svest zaposlenih, komunikacija, dokumentacija.
• 8 – Operacija: srce standarda — analiza uticaja na poslovanje (BIA), procena rizika, strategije i planovi kontinuiteta, program vežbi, evaluacija.
• 9 – Ocena performansi: praćenje, interna provera, preispitivanje od strane rukovodstva.
• 10 – Poboljšanje: postupanje po neusaglašenostima, kontinuirano unapređenje.

Klauzulu 8 ćemo obraditi najdetaljnije kada dođemo do nje — tu se, realno, odlučuje da li firma ima BCMS koji nešto vredi ili samo fasciklu sa planom koji niko nije proverio.

Najčešća zabluda na startu: "Mi imamo IT disaster recovery plan, znači imamo BCM"

Ovo je verovatno najčešća zabluda koju ćemo sretati u ovoj seriji, pa je vredi razjasniti odmah. IT disaster recovery (DR) plan — backup serveri, procedure za vraćanje sistema iz rezervne kopije — jeste deo kontinuiteta poslovanja, ali nije isto što i BCM.

DR plan odgovara na pitanje "kako vraćamo sistem u pogon". BCM odgovara na šire pitanje: "šta rade ljudi dok sistem nije u pogonu, koji procesi moraju da nastave ručno, koga zovemo, ko odlučuje, i kada je prekid dovoljno ozbiljan da se aktivira ceo plan". Firma može imati odličan DR plan za servere, a da nema pojma šta bi magacin radio sutra ujutru da nema pristup sistemu tri dana — tačno ono što ćemo videti da se stvarno desilo Elektrotehni, i kako su to posle rešili.

Ova razlika je i razlog zašto ćemo kasnije, posle ISO 22301 serije, preći na ISO 27031 — taj standard je fokusiran baš na tu IT/ICT stranu (spremnost informaciono-komunikacionih tehnologija za kontinuitet), i logično se nadovezuje kao "dublji zum" na klauzulu 8 iz 22301.

Šta sledi na blogu

Plan je isti kao za 27001 seriju: prvo još par opštih tekstova (realni troškovi uvođenja BCM-a, DIY pristup naspram konsultanta, najčešće zablude), a zatim krećemo klauzula po klauzula, istim formatom koji ste već navikli da čitate: šta klauzula traži, zašto je bitna, primer iz prakse, smernice za dokumentaciju i najčešća greška.

Kroz sve to, pratimo Elektrotehnu — od prvog, bolnog iskustva sa ERP sistemom koji je stao na 30 sati, do sistema koji su, klauzulu po klauzulu, izgradili da se to ne ponovi.