Gašenje požara nije upravljanje rizikom: zašto incidente moramo povezati s upravljanjem problemima

Kada se dogodi kibernetički incident, organizacija se prirodno usredotočuje na zaustavljanje neposredne štete.

Treba izolirati kompromitirani sustav, blokirati korisnički račun, zaustaviti neovlašteni pristup, obnoviti podatke, ponovno pokrenuti poslovnu uslugu i obavijestiti relevantne osobe.

To je nužno. Međutim, nije dovoljno.

Ako se nakon ponovne uspostave poslovanja incident samo administrativno zatvori, bez utvrđivanja njegovih uzroka i provedbe korektivnih mjera, organizacija je uklonila posljedicu, ali nije nužno smanjila rizik.

Isti incident tada se može ponoviti za nekoliko dana, mjeseci ili na drugom dijelu informacijskog sustava.

Incident je događaj, problem je ono što mu je omogućilo da se dogodi

U svakodnevnom jeziku riječ „problem” često znači bilo kakvu poteškoću.

U kontekstu upravljanja informacijskom sigurnošću i poslovnim uslugama, incident i problem imaju različite uloge.

Incident je događaj koji je izazvao ili može izazvati prekid poslovanja, narušavanje sigurnosti, gubitak podataka, neovlašteni pristup ili drugi negativan učinak.

Problem je temeljni uzrok ili skup uvjeta koji su omogućili nastanak jednog ili više incidenata.

Upravljanje incidentom prvenstveno je usmjereno na ograničavanje štete i obnovu poslovanja.

Upravljanje problemom usmjereno je na razumijevanje uzroka, uklanjanje slabosti i sprječavanje ponavljanja.

Jednostavno rečeno:

Upravljanje incidentom vraća organizaciju u funkciju. Upravljanje problemom smanjuje vjerojatnost da će se ista situacija ponoviti.

Primjer: kompromitirani korisnički račun

Zaposlenik zaprimi uvjerljivu lažnu poruku i unese svoje pristupne podatke na lažnu stranicu.

Napadač se prijavljuje u njegov račun, pristupa elektroničkoj pošti i pokušava poslati lažne naloge za plaćanje.

Aktivnosti upravljanja incidentom mogu uključivati:

• blokiranje kompromitiranog računa
• poništavanje aktivnih korisničkih sesija
• promjenu zaporke
• provjeru pravila za prosljeđivanje elektroničke pošte
• pregled izvršenih aktivnosti
• obavještavanje financija i uprave
• procjenu potrebe za regulatornom ili ugovornom prijavom
• očuvanje dokaza za daljnju analizu

Nakon tih aktivnosti incident može biti stavljen pod kontrolu.

Međutim, povezani problem još uvijek nije riješen.

Analiza može pokazati da su incidentu pridonijeli:

• nepostojanje višefaktorske autentifikacije
• mogućnost prijave sa svih lokacija i uređaja
• preširoke korisničke ovlasti
• nedovoljno praćenje neuobičajenih prijava
• nepostojanje jasnog postupka provjere promjene podataka za plaćanje
• nedovoljna osposobljenost zaposlenika
• nejasan kanal za prijavu sumnjivih poruka

Ako organizacija samo promijeni zaporku, uklonila je neposrednu posljedicu. Ako uvede odgovarajuće tehničke kontrole, promijeni proces odobravanja plaćanja, osposobi zaposlenike i unaprijedi nadzor, počela je rješavati problem.

Zašto incidenti nisu samo odgovornost IT odjela

Kibernetički incident gotovo nikada nije isključivo tehnički događaj.

Ransomware može zaustaviti proizvodnju. Kompromitacija dobavljača može prekinuti ključnu uslugu. Krađa korisničkog računa može dovesti do financijske prijevare. Gubitak osobnih podataka može pokrenuti pravne i regulatorne obveze. Nedostupnost aplikacije može onemogućiti isporuku usluge klijentima.

Zato odgovor na incident zahtijeva donošenje poslovnih odluka, primjerice:

• koji se procesi moraju najprije obnoviti
• koliko dugo organizacija može poslovati bez određene usluge
• treba li privremeno zaustaviti dio poslovanja
• koje klijente, partnere ili nadležna tijela treba obavijestiti
• tko može odobriti izvanredne troškove
• koje informacije smiju biti javno komunicirane
• treba li aktivirati plan kontinuiteta poslovanja ili kriznog upravljanja

IT i sigurnosni stručnjaci mogu objasniti tehničko stanje, ali prioritete i prihvatljive poslovne posljedice mora odrediti poslovno vodstvo.

NIS2 postupanje s incidentima izričito uključuje među mjere upravljanja kibernetičkim rizicima, dok upravljačka tijela imaju ulogu u odobravanju i nadzoru provedbe tih mjera. DORA za financijske subjekte propisuje uspostavljanje i provedbu procesa upravljanja incidentima povezanima s IKT-om.

Što kvalitetno upravljanje incidentom mora obuhvatiti

Dobar proces ne započinje u trenutku napada. On započinje mnogo ranije, pripremom organizacije.

1. Priprema

Organizacija mora unaprijed definirati:

• što smatra sigurnosnim događajem, a što incidentom
• kategorije i razine ozbiljnosti incidenata
• kriterije za aktiviranje odgovornog tima
• uloge, odgovornosti i ovlasti
• kontakte internih i vanjskih sudionika
• pravila eskalacije i izvještavanja
• način čuvanja zapisa i dokaza
• povezanost s kontinuitetom poslovanja i kriznim upravljanjem

Bez unaprijed dogovorenih pravila, vrijeme tijekom incidenta troši se na raspravu o tome tko treba odlučiti i što treba učiniti.

2. Otkrivanje i prijava

Zaposlenici, tehnički sustavi, dobavljači i vanjski partneri moraju znati kako prijaviti sumnjivi događaj.

Prijavljivanje mora biti jednostavno i dovoljno brzo. Organizacija u kojoj zaposlenici skrivaju pogreške ili odgađaju prijavu zbog straha od krivnje gubi dragocjeno vrijeme.

3. Procjena i klasifikacija

Nije svaki sigurnosni događaj jednako ozbiljan.

Procjena treba uzeti u obzir:

• pogođene poslovne procese
• vrstu i osjetljivost podataka
• broj pogođenih korisnika
• trajanje i opseg prekida
• financijske posljedice
• učinak na klijente i dobavljače
• regulatorne i ugovorne obveze
• mogućnost širenja incidenta

Tehnička ozbiljnost i poslovna ozbiljnost nisu uvijek jednake. Kompromitacija jednog računala može biti ograničena, ali kompromitacija računala osobe koja odobrava plaćanja može predstavljati velik poslovni rizik.

4. Ograničavanje i oporavak

Cilj je zaustaviti širenje incidenta, ukloniti neposrednu prijetnju i sigurno obnoviti poslovanje.

Brzina jest važna, ali nekontrolirano brzo vraćanje sustava može ponovno aktivirati istu prijetnju ili uništiti važne dokaze.

Zato odluke o oporavku moraju uzeti u obzir sigurnost, kontinuitet poslovanja i potrebe istrage.

5. Komunikacija i izvještavanje

Neusklađena komunikacija može dodatno povećati štetu.

Organizacija mora znati:

• tko izvještava upravu
• tko komunicira sa zaposlenicima
• tko kontaktira klijente i partnere
• tko procjenjuje regulatorne obveze
• tko smije komunicirati s medijima
• kako se bilježe donesene odluke

Informacije moraju biti točne, pravodobne i prilagođene primatelju. Upravi nije potreban popis tehničkih zapisa. Potrebni su joj poslovni učinak, mogući scenariji, odluke koje mora donijeti i procjena razvoja situacije.

ISO/IEC 27035 upravljanje incidentima postavlja kao strukturirani proces koji uključuje pripremu, otkrivanje, prijavljivanje, procjenu, odgovor i primjenu naučenih lekcija.

Incident nije završen dok organizacija nije iz njega nešto naučila

Nakon stabilizacije poslovanja treba provesti strukturirani pregled incidenta.

Svrha takvog pregleda nije pronaći osobu koju treba okriviti. Cilj je razumjeti kombinaciju okolnosti koja je incident učinila mogućim.

Analiza treba obuhvatiti najmanje četiri skupine čimbenika:

Tehnologiju, primjerice ranjivosti, konfiguracije, nadzor, sigurnosne kopije i kontrolu pristupa.

Procese, primjerice odobravanje promjena, upravljanje korisnicima, postupanje s dobavljačima i način eskalacije.

Ljude, primjerice osposobljenost, opterećenje, komunikaciju i dostupnost stručnih osoba.

Upravljanje, primjerice nejasne odgovornosti, neprihvaćene rizike, nedostatna ulaganja i neprovedene preporuke.

Incident rijetko ima samo jedan uzrok. Češće nastaje zbog lanca tehničkih, procesnih i organizacijskih slabosti.

Korektivne mjere moraju biti konkretne i provjerljive

Zaključak poput „potrebno je povećati sigurnost” nije korektivna mjera.

Dobra korektivna mjera mora sadržavati:

• jasno opisanu aktivnost
• odgovornu osobu ili funkciju
• rok provedbe
• potreban prioritet
• potrebne resurse
• dokaz izvršenja
• način provjere učinkovitosti

Primjer loše mjere:

Potrebno je dodatno educirati zaposlenike.

Primjer bolje mjere:

Do 30. rujna funkcija informacijske sigurnosti provest će ciljanu edukaciju i simulaciju phishing napada za zaposlenike financija i nabave. Učinkovitost će se provjeriti usporedbom rezultata simulacije i broja pravodobno prijavljenih sumnjivih poruka.

Mjera nije završena zato što je označena kao provedena. Završena je kada organizacija može pokazati da je smanjila utvrđeni rizik.

Što bi uprava trebala tražiti nakon ozbiljnog incidenta

Nakon svakog značajnijeg incidenta uprava bi trebala dobiti jasan odgovor na sljedeća pitanja:

1. Što se dogodilo i kada je incident započeo?

2. Kada je incident otkriven?

3. Koji su poslovni procesi i podaci bili pogođeni?

4. Kakve su stvarne i moguće posljedice?

5. Koje su odluke donesene i na temelju kojih informacija?

6. Koji su temeljni i doprinosni uzroci?

7. Što je tijekom odgovora funkcioniralo, a što nije?

8. Koje su korektivne mjere dogovorene?

9. Tko je odgovoran za svaku mjeru i koji je rok?

10. Kako će se provjeriti da su mjere učinkovite?

11. Postoji li ista slabost u drugim sustavima ili procesima?

12. Treba li ažurirati procjenu rizika, plan kontinuiteta ili krizne procedure?

Takav pregled pretvara incident iz neugodnog događaja u izvor stvarnog organizacijskog poboljšanja.

Pokazatelji koje vrijedi pratiti

Broj prijavljenih incidenata sam po sebi nije dovoljan pokazatelj sigurnosti. Veći broj prijava ponekad može značiti da su zaposlenici bolje osviješteni i da je kultura prijavljivanja sazrela.

Korisniji pokazatelji uključuju:

• vrijeme od nastanka do otkrivanja incidenta
• vrijeme potrebno za ograničavanje incidenta
• vrijeme potrebno za obnovu ključnih poslovnih procesa
• broj ponovljenih incidenata istog uzroka
• broj otvorenih korektivnih mjera
• udio korektivnih mjera provedenih u roku
• broj incidenata kod kojih je proveden naknadni pregled
• procijenjeni financijski i operativni učinak
• broj utvrđenih slabosti koje postoje i u drugim dijelovima organizacije

Najvažniji pokazatelj nije koliko je incidenata administrativno zatvoreno, nego koliko je njihovih uzroka stvarno uklonjeno.

Najčešće pogreške organizacija

U praksi se često pojavljuju isti obrasci:

• incident se smatra isključivo IT problemom
• nema unaprijed definiranih ovlasti za donošenje odluka
• zaposlenici ne znaju kome prijaviti sumnjivi događaj
• dokumentira se tehnički tijek, ali ne i poslovne odluke
• oporavak se provodi bez očuvanja potrebnih dokaza
• analiza završava pronalaženjem krivca umjesto uzroka
• korektivne mjere nemaju vlasnike ni rokove
• mjere se formalno zatvaraju bez provjere učinkovitosti
• naučene lekcije ne prenose se na druge sustave i procese
• uprava dobiva tehničke detalje, ali ne i jasnu sliku poslovnog rizika

Svaka od tih pogrešaka povećava vjerojatnost da će se organizacija ponovno suočiti s gotovo istim incidentom.

Zrela organizacija ne očekuje da se incidenti nikada neće dogoditi

Potpuno uklanjanje kibernetičkog rizika nije realan cilj.

Zrela organizacija zato ne gradi sigurnost samo oko prevencije. Ona razvija sposobnost brzog otkrivanja, kvalitetnog odlučivanja, ograničavanja posljedica, obnove poslovanja i sustavnog učenja.

Upravljanje incidentima zaustavlja neposrednu štetu.

Upravljanje problemima pretvara iskustvo incidenta u trajno poboljšanje kontrola, procesa i poslovne otpornosti.

Zato nakon sljedećeg incidenta ne treba pitati samo:

Je li sustav ponovno dostupan?

Treba pitati i:

Što smo promijenili kako se ista situacija ne bi ponovila?

Tek kada organizacija može jasno odgovoriti na oba pitanja, incident je doista zatvoren.