Aneks A, deo 7: A.5.29–5.30 — Kontinuitet poslovanja

Sedmi deo serije o Aneksu A. Do sada smo se uglavnom bavili sprečavanjem da se nešto loše desi. Ove dve kontrole postavljaju drugačije pitanje: šta ako se ipak desi nešto što poremeti normalan rad firme — kako bezbednost informacija opstaje kroz taj poremećaj?

Šta ove kontrole traže

A.5.29 — Bezbednost informacija tokom poremećaja. Firma treba da planira kako će održati odgovarajući nivo bezbednosti informacija tokom poremećaja u poslovanju — kad se, na primer, uslovi rada iznenada promene i ljudi moraju da rade drugačije nego inače.

A.5.30 — Spremnost IKT sistema za kontinuitet poslovanja. Spremnost IKT infrastrukture treba da bude planirana, primenjena, održavana i testirana, na osnovu ciljeva kontinuiteta poslovanja i zahteva za kontinuitet IKT sistema.

Zašto su ove kontrole bitne

Kriza je, paradoksalno, trenutak kad bezbednosna pravila najčešće prva padaju — ne zato što ih neko svesno ukine, nego zato što pažnja ide na to da se posao nastavi, a pravila deluju kao sporedna stvar „za posle". Upravo tada su firme najranjivije, jer i eventualni napadači znaju da se u haosu lakše provuku. A.5.29 traži da se to spreči unapred, a A.5.30 traži nešto podjednako važno, a često potpuno zanemareno — da rezervne kopije i planovi oporavka zaista rade, ne samo da postoje na papiru.

Primer iz prakse

A.5.29, poremećaj koji je zaista testirao pravila: posle nevremena, zgrada u kojoj se nalazi kancelarija knjigovodstvene agencije ostala je bez struje nekoliko dana. Ceo tim je morao da pređe na rad od kuće, van plana i bez pripreme. Umesto da se pravila privremeno „stave po strani dok se stvari ne slegnu", koordinatorka je eksplicitno podsetila tim, u kratkoj poruci pre nego što je iko počeo da radi od kuće, da individualni nalozi sa dvofaktorskom autentifikacijom, uspostavljeni kroz proces opisan u klauzuli 8.1, i dalje važe podjednako kao i u kancelariji, i da pravila o slanju osetljivih dokumenata iz klauzule 5.14 nisu privremeno ukinuta zbog vanredne situacije. Bezbednosna disciplina nije zavisila od toga da li je situacija normalna.

A.5.30, test koji je otkrio problem pre nego što je postao kriza: agencija je jednom godišnje sprovodila test obnavljanja podataka iz rezervne kopije — namerno birajući nasumičan fajl i proveravajući da li se stvarno može vratiti u ispravnom stanju, ne samo da li je rezervna kopija formalno napravljena. Prilikom jednog takvog testa, otkrili su da rezervna kopija lokalnog servera zapravo nije radila ispravno poslednja tri meseca, zbog isteklog prostora za skladištenje o kome niko nije bio obavešten. Greška bi ostala potpuno neotkrivena da nije bilo baš tog testa — sve dok rezervna kopija zaista ne bi zatrebala, u trenutku kad bi bilo prekasno da se bilo šta popravi.

Gde se dokumentuje

A.5.29 dokumentuje se kroz kratak plan — koji osnovni bezbednosni zahtevi ostaju na snazi tokom poremećaja, i kako se to komunicira timu kad se poremećaj desi. Nema potrebe za detaljnim scenarijem za svaku moguću vrstu poremećaja; dovoljno je jasno stanovište da pravila ne prestaju da važe samo zato što su okolnosti vanredne. A.5.30 dokumentuje se kroz jednostavan zapisnik o testu obnavljanja — datum testa, šta je testirano, rezultat, i, ako je nešto otkriveno kao u primeru iznad, preduzeta korektivna mera po istom obrascu opisanom u klauzuli 10.2.

Najčešća greška

Najčešća greška kod A.5.29 je prećutno popuštanje bezbednosnih pravila tokom vanredne situacije, uz obrazloženje da „sad nije vreme za to" — tačno suprotno od onoga što ova kontrola traži. Kod A.5.30, daleko najčešća i najskuplja greška jeste postojanje rezervnih kopija koje se nikad ne testiraju — firma pretpostavlja da rade, sve dok ih stvarno ne zatreba, i tek tada otkrije da nisu. Redovan, makar jednom godišnje sproveden test obnavljanja, kao u primeru iznad, jedina je stvarna garancija da rezervna kopija radi kad je najpotrebnija.

Šta sledi

Sledeći deo serije ide na kontrole A.5.31–5.34 — pravnu usklađenost i zaštitu podataka, gde se vraćamo na teren koji smo dotakli još u prvom tekstu na blogu, sada detaljnije, kroz konkretne kontrole standarda.