ISO/IEC 27001:2022 u praksi — Procena rizika: identifikacija, analiza, vlasnici rizika (klauzula 6.1.2)

ISO/IEC 27001:2022 u praksi — deo 3 od 11

Procena rizika: identifikacija, analiza, vlasnici rizika

Politika je usvojena, uloge dodeljene — Kodni Krug sada dolazi do jezgra celog ISMS-a. Klauzula 6.1.2 zahteva sistematičan proces procene rizika po bezbednost informacija, koji mora biti ponovljiv, dosledan i uporediv iz ciklusa u ciklus — ne slobodna procena na sastanku, već metodologija koja svaki put daje uporedive rezultate.

Šta standard traži: tri C-I-A dimenzije

Standard zahteva da se rizici identifikuju u odnosu na gubitak poverljivosti, integriteta i dostupnosti (Confidentiality, Integrity, Availability — CIA) informacija unutar obima ISMS-a. Ovo je bitna razlika u odnosu na procenu rizika koju smo radili u ISO 22301 seriji — tamo je pitanje bilo "koliko dugo možemo da izdržimo bez ovog procesa" (kontinuitet), dok je ovde pitanje "šta se dešava ako neko neovlašćen pristupi, izmeni ili obriše ovu informaciju" (bezbednost). Isti rizik može imati sasvim različitu težinu u ova dva okvira.

6.1.2 a) — Kriterijumi rizika

Pre same procene, standard traži da se uspostave kriterijumi za prihvatanje rizika i kriterijumi za sprovođenje procene — bez toga, procena od strane dva različita vlasnika rizika ne bi bila uporediva.

Kodni Krug d.o.o. — interni dokument ISMS sistema
Metodologija procene rizika i kriterijumi prihvatanja
Šifra dokumenta: KK-ISMS-DOC-006 Verzija: 1.0 Status: Usvojen
Vlasnik dokumenta: Menadžer bezbednosti informacija Odobrio: Generalni direktor Sledeći pregled: 12 meseci

1. Skala verovatnoće

Nivo Opis
1 — RetkoNije se dogodilo u firmi ni kod sličnih firmi u poslednje 2 godine
2 — MogućeDogodilo se kod sličnih firmi, ali ne kod nas
3 — VerovatnoDogodilo se kod nas najmanje jednom u poslednje 2 godine, ili su uslovi za to prisutni
4 — Skoro izvesnoDešava se ponavljano ili je aktivno u toku

2. Skala posledice

Nivo Opis
1 — ZanemarljivaInterni neugodni trenutak, bez uticaja na klijenta ili podatke
2 — UmerenaOgraničen uticaj na jedan projekat, bez curenja poverljivih podataka
3 — OzbiljnaCurenje ili gubitak podataka jednog klijenta; mogući ugovorni/pravni uticaj
4 — KritičnaCurenje izvornog koda/podataka više klijenata; gubitak poverenja; prekid ugovora; pravna odgovornost

3. Matrica nivoa rizika (verovatnoća × posledica)
Nivo rizika = verovatnoća × posledica, sa rasponom od 1 do 16. Rizici sa vrednošću 1–4 klasifikuju se kao Nizak, 5–9 kao Srednji, 10–16 kao Visok.

4. Kriterijumi prihvatanja rizika
Rizici klasifikovani kao Nizak mogu se prihvatiti bez dodatnog tretmana, uz evidenciju u registru. Rizici klasifikovani kao Srednji ili Visok zahtevaju formalni tretman (Post 4) i odobrenje vlasnika rizika, a rizici Visokog nivoa dodatno zahtevaju odobrenje generalnog direktora pre prihvatanja bilo kog rezidualnog nivoa.

6.1.2 c)–e) — Identifikacija, analiza i evaluacija rizika

Sa uspostavljenom metodologijom, Menadžer bezbednosti informacija je, u saradnji sa vođama projekata, sproveo prvu procenu rizika Kodnog Kruga. Svaki rizik je vezan za konkretnu imovinu (asset) i konkretnu CIA dimenziju, sa imenovanim vlasnikom.

Kodni Krug d.o.o. — interni dokument ISMS sistema
Registar procene rizika bezbednosti informacija
Šifra dokumenta: KK-ISMS-DOC-007 Verzija: 1.0 Status: Usvojen
Vlasnik dokumenta: Menadžer bezbednosti informacija Odobrio: Generalni direktor Sledeći pregled: 12 meseci / po značajnoj promeni
Rizik Imovina CIA Verovatnoća Posledica Nivo rizika Vlasnik rizika
Kompromitovan nalog spoljnog developera (phishing/slaba lozinka)Git repozitorijum, klijentski kodC, I3412 — VisokMenadžer bezbednosti informacija
Kopiranje produkcionih (klijentskih) podataka na lokalnu radnu stanicu radi debagovanjaKlijentski produkcioni podaciC4312 — VisokVođa projekta (po projektu)
Gubitak/krađa ličnog uređaja korišćenog za pristup (BYOD) bez enkripcijeRadna stanica, pristupni tokeniC236 — SrednjiMenadžer bezbednosti informacija
Neovlašćena izmena koda usled nedostatka code review procesaIzvorni kod, CI/CD pipelineI236 — SrednjiTehnički direktor
Pogrešna konfiguracija pristupnih prava u cloud okruženju (AWS/Azure)Cloud infrastruktura, klijentski podaciC, I, A3412 — VisokMenadžer bezbednosti informacija
Nepostojanje formalnog procesa oduzimanja pristupa po prestanku angažmana saradnikaSvi sistemi iz obimaC, I339 — SrednjiRukovodilac ljudskih resursa
Nedostatak enkripcije bekapa razvojne baze podatakaBekap podaciC236 — SrednjiMenadžer bezbednosti informacija
Neažuran popis softverskih zavisnosti sa poznatim ranjivostima (dependency scanning)Klijentske aplikacije u razvojuI, A339 — SrednjiTehnički direktor
Nenamerno deljenje pristupnih kredencijala kroz interni chat/e-mailPristupni podaci, klijentski sistemiC224 — NizakMenadžer bezbednosti informacija

Prioritizacija za tretman (6.1.2 e.2): Tri rizika ocenjena kao Visok (kompromitovan nalog developera, kopiranje produkcionih podataka, pogrešna konfiguracija cloud pristupa) prelaze prvi u fazu tretmana u narednom postu, praćeni rizicima Srednjeg nivoa.

Zašto vlasnik rizika nije uvek Menadžer bezbednosti informacija

Primetite da registar dodeljuje pojedine rizike vođama projekata, Tehničkom direktoru ili Rukovodiocu ljudskih resursa, a ne uvek Menadžeru bezbednosti informacija. Ovo je namerno — vlasnik rizika treba da bude osoba koja stvarno ima ovlašćenje i kontekst da donese odluku o njegovom tretmanu. Rizik "kopiranje produkcionih podataka radi debagovanja" specifičan je za svaki projekat i najbolje ga poznaje vođa tog projekta, ne centralna bezbednosna funkcija koja ne učestvuje u svakodnevnom radu na kodu.

Šta sledi

U narednom postu prelazimo na Klauzulu 6.1.3 i 6.2 — tretman identifikovanih rizika, izradu Izjave o primenljivosti (Statement of Applicability) koja mapira Annex A kontrole na stvarne mere Kodnog Kruga, i formalne ciljeve bezbednosti informacija za narednu godinu.

Comments

Post a Comment

Popular posts from this blog

Šta je ISO 27001 i da li je mojoj firmi stvarno potreban?

  Prvi tekst na blogu InfoSec bez stresa — i pitanje koje sebi postavi skoro svaki vlasnik male ili srednje firme onog trenutka kad prvi put čuje za ovaj standard. Realna situacija Zamislite ovo: firma ima 15 zaposlenih, radi razvoj softvera ili pruža IT usluge, posluje solidno, sve funkcioniše. Onda stigne mejl od velikog klijenta — banke, osiguravajuće kuće ili strane kompanije s kojom se pregovara o saradnji. U prilogu je bezbednosni upitnik, a na dnu jedna rečenica koja pokvari popodne: „Molimo dostavite ISO 27001 sertifikat ili plan implementacije u naredna tri meseca." Ili, druga verzija iste priče: firma konkuriše na tenderu, sve uslove ispunjava — sem jednog. Traži se ISO 27001. Prva reakcija je obično paničan Google upit u stilu „šta je ISO 27001" i „da li mi to stvarno treba", u ponoć, uz osećaj da se upravo otvorila rupa u budžetu i rasporedu koje niko nije planirao. Ako je ovo vaša situacija — ili slutite da bi mogla postati — ovaj tekst je tu da va...
Read more

ISO 22301:2019 u praksi — Praktična obuka na primeru fabrike piva

Ova serija od osam članaka provodi vas kroz sve zahteve standarda ISO 22301:2019 — Sistemi upravljanja kontinuitetom poslovanja (BCMS) , klauzulu po klauzulu, na konkretnom praktičnom primeru: fiktivnoj proizvodnoj pivari „Zeleni Hmelj" d.o.o. , sa sopstvenom varionicom, punionicom i hibridnom IT/OT arhitekturom (SCADA/PLC industrijski sistemi, lokalni ERP i cloud servisi — Microsoft 365, cloud backup/DR, SaaS CRM). Umesto apstraktnog prepričavanja teksta standarda, svaki post gradi stvaran, upotrebljiv dokument — politiku, matricu, BIA analizu, BCP plan, zapisnik — kakav bi auditor tražio na sertifikacionoj proveri. Kroz celu seriju provlači se jedan princip: zahtevi kontinuiteta poslovanja dolaze od biznisa ka IT sektoru, a ne obrnuto — proizvodnja i komercijala definišu koliko dugo mogu da izdrže bez svog sistema, a IT/OT sektor sprovodi tehnička rešenja koja taj zahtev ispunjavaju. Sadržaj serije Deo 1 Uvod u BCMS i Klauzula 4 — Kontekst organizacije Razlika BCMS v...
Read more

ISO 27031: Upravljanje IRBC-om i usklađivanje sa ciljevima kontinuiteta (klauzula 6.1–6.3)

6.1 – Opšte Standard deli uzroke prekida u nekoliko grupa: prirodni uzroci – požar, poplava. Retki, ali fizički pogađaju celu lokaciju odjednom, ne samo jednu komponentu. tehnički kvarovi – hardver, softver, napajanje, klimatizacija. Najčešća kategorija u praksi, i ona za koju firme obično imaju najviše iskustva. ljudska greška – loše podešen bekap, propust u upravljanju izmenama. Retko ko je namerno kriv, ali posledice su iste kao da jeste. namerna akcija – hakovanje, malver, sabotaža. Ovde je pored oporavka bitna i istraga – ko je i kako ušao. društveni faktori – pandemija, štrajk. Ne pogađaju tehnologiju direktno, nego ljude koji je održavaju. cyber napadi – DoS, DDoS, napadi koji preplave sistem saobraćajem dok ne prestane da radi. lanac snabdevanja – prekid kod cloud provajdera, nejasni bezbednosni uslovi u ugovoru sa dobavljačem. Ovde firma nema direktnu kontrolu, samo ugovor i poverenje. Rizik da IT prestane da radi ima jedan prepoznatljiv obrazac: retko se ...
Read more