ISO/IEC 20000-1, klauzula 8.7.3 — Upravljanje informacionom bezbednošću

Šta standard zahteva

Politika informacione bezbednosti (8.7.3.1): rukovodstvo sa odgovarajućim ovlašćenjem mora odobriti politiku informacione bezbednosti relevantnu za organizaciju. Politika mora biti dokumentovana i uzeti u obzir zahteve usluga i obaveze iz klauzule 6.3 c). Politika mora biti dostupna prema potrebi. Organizacija mora komunicirati važnost usaglašenosti sa politikom, i njenu primenljivost na SMS i usluge, relevantnim osobama unutar: organizacije; korisnika i krajnjih korisnika; spoljnih dobavljača, internih dobavljača i drugih zainteresovanih strana.

Kontrole informacione bezbednosti (8.7.3.2): u planiranim intervalima, rizici informacione bezbednosti za SMS i usluge moraju biti procenjeni i dokumentovani. Kontrole moraju biti određene, primenjene i sprovedene radi podrške politici i adresiranja prepoznatih rizika, a odluke o kontrolama moraju biti dokumentovane. Organizacija mora dogovoriti i primeniti kontrole za rizike vezane za spoljne organizacije. Organizacija mora pratiti i pregledati efektivnost kontrola i preduzeti potrebne mere.

Bezbednosni incidenti (8.7.3.3): moraju biti evidentirani i klasifikovani; prioritizovani uzimajući u obzir bezbednosni rizik; eskalirani po potrebi; rešeni; zatvoreni. Organizacija mora analizirati bezbednosne incidente po tipu, obimu i uticaju na SMS, usluge i zainteresovane strane, i izveštavati o njima radi prepoznavanja prilika za unapređenje. Standard napominje da serija ISO/IEC 27000 daje zahteve i smernice za implementaciju sistema upravljanja informacionom bezbednošću, a ISO/IEC 27013 daje smernice za integraciju ISO/IEC 27001 i ISO/IEC 20000-1.

Primer

Primer: Uprava Adria Trade-a formalno odobrava politiku informacione bezbednosti relevantnu za IT sektor, koja uzima u obzir zahteve usluga (na primer, da POS transakcije moraju biti zaštićene) i zakonske obaveze već zapisane u planu upravljanja uslugama (zakon o zaštiti podataka o ličnosti). Politika se deli sa zaposlenima kroz internu obuku, sa rukovodiocima prodavnica u pojednostavljenom obliku, i sa cloud ERP dobavljačem kao deo ugovornih obaveza.

Kvartalno se procenjuju bezbednosni rizici — pokušaji phishing napada na zaposlene, neovlašćen pristup POS sistemu, rizici vezani za samog cloud ERP dobavljača. Na osnovu toga određuju se konkretne kontrole: obavezna dvofaktorska autentikacija za pristup ERP sistemu, redovna bezbednosna obuka zaposlenih, enkripcija podataka pri prenosu. Svaka odluka o kontroli se dokumentuje, uz obrazloženje koji rizik adresira. Za rizike vezane za cloud dobavljača, ugovorom se dogovara obaveza da dobavljač prijavi bilo kakav bezbednosni incident u roku od 24 sata. Efektivnost kontrola se proverava — na primer, kroz povremenu simulaciju phishing napada da se vidi da li zaposleni prepoznaju i prijavljuju sumnjive mejlove.

Kad se otkrije sumnjiv pokušaj prijave na ERP nalog van radnog vremena, taj bezbednosni incident se evidentira, klasifikuje, prioritizuje na osnovu bezbednosnog rizika, i po potrebi eskalira. Nalog se privremeno blokira dok se slučaj istražuje, a incident se zatvara tek pošto se potvrdi da nije bilo neovlašćenog pristupa. Kvartalno se svi bezbednosni incidenti analiziraju zajedno po tipu i obimu — kad se primeti porast pokušaja phishing napada, to postaje konkretan povod za dodatnu bezbednosnu obuku zaposlenih.

Šta treba uraditi

• Obezbediti da politiku informacione bezbednosti formalno odobri neko sa stvarnim ovlašćenjem u organizaciji — ne dozvoliti da politiku napiše i "usvoji" sam IT sektor bez saglasnosti uprave.
• Povezati politiku sa stvarnim zahtevima usluga i zakonskim, regulatornim i ugovornim obavezama već zapisanim u planu upravljanja uslugama (6.3 c) — ne koristiti generički šablon koji ne odgovara vašoj situaciji.
• Aktivno komunicirati politiku svim relevantnim grupama — zaposlenima, korisnicima, i spoljnim i internim dobavljačima — prilagođeno svakoj grupi posebno.
• Redovno procenjivati i dokumentovati bezbednosne rizike specifične za SMS i usluge — ovo se nadovezuje na opšti registar rizika iz klauzule 6.1, ali sa posebnim fokusom na informacionu bezbednost.
• Za svaku odabranu kontrolu zapisati koji rizik ona adresira i zašto je baš ta kontrola odabrana — odluka bez dokumentovanog obrazloženja teško se brani kasnije, i pred auditom i pred sopstvenim timom.
• Ne zaboraviti rizike koji dolaze od spoljnih organizacija — dogovoriti konkretne bezbednosne kontrole i sa dobavljačima, ne samo primeniti kontrole interno.
• Proveravati da li kontrole stvarno funkcionišu, ne samo da li formalno postoje — test ili simulacija često otkrije da kontrola koja izgleda dobro na papiru ne radi u praksi.
• Primeniti isti nivo discipline na bezbednosne incidente kao i na obične — evidentiranje, klasifikaciju, prioritizaciju prema bezbednosnom riziku, eskalaciju, rešavanje i zatvaranje.
• Periodično analizirati bezbednosne incidente zajedno, po tipu i obimu — pojedinačan incident retko govori mnogo, ali trend kroz nekoliko meseci često otkriva gde je potrebna dodatna kontrola ili obuka.
• Ako organizacija paralelno radi i na ISO/IEC 27001, iskoristiti smernice iz ISO/IEC 27013 za integraciju dva sistema — mnoge aktivnosti iz ove klauzule prirodno se preklapaju sa onim što sistem upravljanja informacionom bezbednošću već zahteva, pa nema potrebe za dupliranjem posla.