InfoSec bez stresa

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 ...

Prošli tekst je proveo VoxServis kroz šesnaest nedelja za jedan servis – zavisnost identiteta. Ovaj tekst odgovara na pitanje koje neizbežno sledi: dobro, a šta sad sa svime ostalim? Tri teme: kako se ciklus širi na ostale kritične servise, kako IRBC prestaje da bude poseban projekat i postaje deo postojećih ISO 27001 i ISO 22301 procesa, i kako izgleda godina kad program više nije novost nego rutina. Širenje na sledeće servise Dobra vest: drugi krug ne traje šesnaest nedelja. Najveći deo prvog ciklusa – imenovanje vlasnika, definisanje praga eskalacije, uspostavljanje šablona za mapiranje i planove – rađen je jednom, za celu firmu, ne za jedan servis. Ono što se ponavlja za svaki novi servis je suštinski faza 2 do faze 5 iz prošlog teksta: BIA i mapiranje, izbor strategije, izgradnja plana, prva vežba. Realno, to skraćuje sledeći ciklus na osam do deset nedelja, a sa iskustvom i još kraće. Pitanje koje ostaje jeste redosled – koji servis ide sledeći. Odgovor dolazi direktno iz BIA ...

Sedamnaest tekstova kasnije, imamo kompletnu teoriju. Ovaj tekst je drugačiji – ne objašnjava novu klauzulu, nego slaže sve što smo do sad naučili u jedan konkretan, hronološki plan. Ako ste firma veličine VoxServis-a i danas, u ponedeljak, odlučite da počnete, evo tačno šta radite, nedelju po nedelju, za jedan kritičan servis – ne za celu infrastrukturu odjednom. Zašto samo jedan servis? Zato što smo u četvrtom tekstu ove serije bili eksplicitni: bolje je potpuno sprovesti ceo krug za dve ili tri prioritetne aktivnosti nego površno skicirati trideset. Ovaj plan prati VoxServis-ovu zavisnost identiteta – onu koju smo pratili kroz celu seriju – kao radni primer, ali koraci važe za bilo koji prvi kritičan servis koji izaberete. Faza 0 (pre početka) – Dobiti sponzora Pre bilo kog tehničkog koraka, potreban je jedan razgovor sa nekim u top menadžmentu ko može da odobri vreme ljudi i budžet. Ne treba vam ceo IRBC program odobren unapred – treba vam dozvola da sprovedete ovaj šesnaestoned...

12 – Finalni MBCO Zavisno od situacije, moguće je da IRBC u početku ne može da ispuni MBCO koji je poslovanje postavilo koristeći IT. U tom slučaju, IRBC ne ispunjava zahteve kontinuiteta koje je poslovanje postavilo. Ako postoji jaz između zahteva i sposobnosti, postoje samo dve opcije: zatvoriti jaz unapređenjem sposobnosti prihvatiti jaz i uključiti ga u risk registar Kad se bira zatvaranje jaza, u zavisnosti od troška unapređenja IRBC-a, organizacija treba da preispita svoje poslovne zahteve i mogućnosti unapređenja IRBC-a, tako da se u budućnosti MBCO za IT može unaprediti i približiti ispunjavanju zahteva kontinuiteta poslovanja. Ovaj pregled i unapređenje IRBC-a treba da se sprovede kroz BCM, od strane odgovarajućeg menadžmenta. Ovo je trenutak u standardu kad se konačno zatvara priča koju pratimo kroz celu seriju. Zavisnost identiteta nije problem koji "treba rešiti jednog dana" – standard traži da se, na osnovu svega što je utvrđeno, donese jedna od samo d...

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 ...

11.1 – Kriterijumi učinka Kriterijumi učinka za IRBC mogu biti kvalitativni ili kvantitativni. Kvalitativni kriterijumi su subjektivni kad se koriste za određivanje učinka IRBC-a, ali obično zahtevaju manje resursa u procesu merenja – što može biti prikladno za malu ili srednju organizaciju sa ograničenim resursima. Mogu uključivati određivanje efikasnosti procesa korišćenih u planiranju, pripremi i izvršavanju IRBC aktivnosti, merenih kroz: anketu sa strukturisanim ili nestrukturisanim upitnikom povratne informacije od učesnika i zainteresovanih strana sprovođenje radionica za povratne informacije i drugih fokus-grupa Ovo je koristan podsetnik da mereni kvantitativni pristup nije jedini "ispravan" način – firma ne treba da odustane od merenja učinka samo zato što nema resurse za sofisticiranu kvantitativnu metriku. Anketa posle vežbe je bolja od ničega, i standard to eksplicitno legitimiše. Primer: VoxServis, sa 560 zaposlenih i realnim finansijskim posledicama ...

10.4 – Privremena rešenja Kritični poslovni procesi treba da budu najmanje pogođeni u slučaju IT poremećaja. Tokom perioda potrebnog da se ponovo izgradi neophodna IT infrastruktura, organizacije treba da dozvole aktivaciju "privremenih rešenja" – privremenu popravku ili drugi način da se poslovna aktivnost obavi, ili da se IT usluga vrati na upotrebljiv nivo, bez ispravljanja osnovnog uzroka. Privremeno rešenje smanjuje uticaj incidenta ili problema za koji rešenje još nije spremno. Može biti potpuno ručno, delimično ručno, ili potpuno automatizovana usluga, aktivirana interno ili, eventualno, uz spoljne partnere. Efikasnost može biti niža nego u normalnim uslovima – i to je očekivano, ne znak neuspeha. Ključna, lako propuštena poruka: privremeno rešenje sprovode vlasnici pogođene aktivnosti – u VoxServis-ovom slučaju, supervizori kontakt centra, ne (samo) IT sektor. IT radi na pravom uzroku; poslovna strana u međuvremenu radi po unapred dogovorenom, sniženom scenariju. ...

10.2 – Aktivacija plana oporavka Aktivacija IKT plana kontinuiteta je deo šire BCM strukture cele organizacije i primenjuje se kad ozbiljan incident pogodi IT operacije. Odluka o aktivaciji donosi se prema mandatu koji je postavio BCM; IT menadžment aktivira odgovarajući plan zavisno od prirode incidenta prema IRBC-u. Standard opisuje tok odluke: upravljanje incidentima utvrđuje da je incident ozbiljan i IT-vezan obaveštava IT menadžment i/ili krizni menadžment po potrebi ovlašćeni menadžment odlučuje da aktivira IKT plan planovi za druge delove organizacije takođe mogu biti aktivirani ako je krizni menadžment već aktivan Eskalacija od upravljanja incidentima ka IRBC-u je proces koji podiže odgovornost i ovlašćenje na viši nivo, i zavisi od kriterijuma koje postavljaju i upravljanje incidentima i IRBC menadžment zajedno – kriterijumi treba da uzmu u obzir vreme potrebno da se incident reši u odnosu na RTO, i razmeru uticaja na kontinuitet poslovanja. Treba postojati proces k...

10.1.1 – Određivanje i uspostavljanje organizacije za oporavak Organizacija treba da, na osnovu IRBC strategije i plana, definiše sposobnost kroz strukturu, uloge i odgovornosti. Top menadžment određuje ko preuzima ukupnu odgovornost za IRBC. IRBC strategije treba da se implementiraju tek posle odobrenja top menadžmenta – u tom trenutku počinje faza implementacije, koja podrazumeva organizacionu strukturu, planove i procedure potrebne da se podrži sprovođenje. Organizacija treba da upravlja resursima, procedurama i radom IRBC-a, kao i da sprovede programe obuke i podizanja svesti. Implementacija treba da se vodi kao projekat kroz formalni proces upravljanja izmenama i kontrole projekta unutar BCM-a, radi pune vidljivosti i izveštavanja za menadžment. Ovo je razlika između IRBC-a kao skupa dobrih namera i IRBC-a kao stvarnog projekta sa vlasnikom, budžetom i rokovima. Strategija sama po sebi ne sprovodi se sama – treba joj formalna implementaciona faza, sa istim nivoom projektne dis...

9.2.4 – Tehnologija IT servisi od kojih zavise prioritetni procesi treba da budu dostupni unapred, pre nego što se dependentne poslovne aktivnosti vrate u pogon – rešenja moraju da obezbede dostupnost aplikacija u okviru RTO vrednosti određenih kroz BIA. Standard nabraja trinaest faktora koje treba razmotriti pri izboru tehnološke IRBC strategije: RTO i RPO vrednosti za kritične IT servise lokacija i udaljenost između tehnoloških lokacija broj tehnoloških lokacija udaljeni pristup sistemima zahtevi hlađenja zahtevi napajanja bezbednosni zahtevi korišćenje neposedovanih ("mračnih") lokacija naspram lokacija sa osobljem telekomunikaciona povezanost i redundantno rutiranje priroda "failback-a" – da li je za aktivaciju alternativnog IT rešenja potrebna ručna intervencija ili se to dešava automatski potreban nivo automatizacije zastarelost tehnologije povezanost eksternog pružaoca usluga i druge spoljne veze Ova lista je vredna jer prisiljava na pitan...

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 u...