O tome što učiniti u incidentu ne bi trebalo odlučivati po hijerarhiji u trenutku kad usluga već ne radi. Incident response plan mora unaprijed odrediti tko vodi odgovor na incident, tko smije izolirati sustav, tko procjenjuje poslovnu posljedicu i tko odobrava komunikaciju. Kada su te ovlasti jasne, tim može djelovati uz nepotpune informacije bez nepotrebnog čekanja. Kada nisu, minute postaju skupe zbog neodlučnosti, a ne samo zbog tehničkog kvara.
Incident response plan nije popis telefonskih brojeva spremljen u mapi koju nitko ne otvara. To je radni okvir za odluke u uvjetima u kojima su činjenice nepotpune, sustavi možda nedostupni, a pritisak raste iz minute u minutu.
U kibernetičkoj sigurnosti tehnički signal često dolazi prije potpune slike. Netko može primijetiti neuobičajenu prijavu, promjenu ovlasti, nedostupnu uslugu ili poruku partnera. Tim ne mora odmah dokazati cijeli napad prije otvaranja zapisa i zaštite poslovanja. Mora znati tko smije napraviti prvi kontrolirani potez.
Najskuplje kašnjenje često nije tehničko. Nastaje kada nitko ne zna smije li isključiti korisnički račun, odvojiti poslužitelj od mreže, zaustaviti integraciju ili promijeniti prioritet rada.
Takve odluke imaju stvarnu poslovnu cijenu. Preširoka izolacija može zaustaviti proizvodni nalog, izdavanje računa ili razmjenu podataka s partnerom. Prespora izolacija može povećati opseg problema i otežati kasniju analizu. Zato plan ne smije sadržavati samo korake. Mora navesti vlasnika odluke, zamjenu te prag nakon kojeg se odluka eskalira.
Korisno je razdvojiti najmanje četiri odgovornosti:
Jedna osoba može u manjoj organizaciji imati više uloga. Plan treba izričito navesti takvu podjelu uloga i zamjenu za nedostupnu osobu. Plan koji pretpostavlja da će uvijek biti dostupan isti stručnjak nije plan za stvarni incident.
Prvi cilj nije napisati konačno objašnjenje. Cilj je stvoriti pouzdanu osnovu za sljedeću odluku i izbjeći promjene koje mogu izbrisati važne tragove.
U prvih petnaest minuta tim bi trebao:
Ovaj popis nije zamjena za tehničku istragu. Njegova je svrha smanjiti zbrku. Ako pet osoba zasebno šalje poruke, mijenja postavke i zove vanjske kontakte, organizacija teško može utvrditi što se dogodilo i koje su odluke već donesene.
Plan treba omogućiti brzu izolaciju, ali uz poznate posljedice. Primjerice, unaprijed se može odrediti da dežurni tehnički vlasnik smije privremeno onemogućiti kompromitirani račun, dok za prekid kritične integracije treba uključiti poslovnog vlasnika usluge i voditelja incidenta. Takav prag nije birokracija. On sprječava da se važna poslovna usluga zaustavi bez procjene posljedice ili da se očita prijetnja ne ograniči zbog čekanja odobrenja.
Vremenski okviri nisu univerzalni rokovi niti dokaz da je svaki incident jednak. Služe kao okvir za vježbu i za provjeru ostaje li neka odluka bez vlasnika. Organizacija ih treba prilagoditi vlastitim uslugama, rizicima, ugovornim obvezama i nadležnostima.
Glavni cilj je potvrditi događaj i zaštititi trag. Potrebno je odlučiti tko vodi incident, na kojem se kanalu komunicira i postoji li razlog za početnu izolaciju.
Glavni cilj je ograničiti širenje i razumjeti početni utjecaj. Tim određuje prioritet pogođenih sustava, procjenjuje treba li vanjsku pomoć i aktivira internu eskalaciju prema poslovnom utjecaju.
Glavni cilj je stabilizirati poslovanje i komunikaciju. U tom se razdoblju donose odluke o privremenom načinu rada, redoslijedu oporavka te potrebi za obavijestima i regulatornom ili ugovornom procjenom.
Glavni cilj je ukloniti uzrok i vratiti uslugu na kontroliran način. Potrebno je odrediti redoslijed povratka, dodatne kontrole i praćenje koje će potvrditi da se problem ne ponavlja istim putem.
Tehnički tim može dobro ograničiti incident, a organizacija svejedno može napraviti štetu proturječnim porukama. Zato jedna osoba ili jasno određena uloga treba upravljati činjenicama: što znamo, što još provjeravamo, koju smo odluku donijeli i kada slijedi sljedeća obavijest.
Za internu komunikaciju ne treba čekati potpunu sigurnost. Treba jasno razlikovati potvrđeno od nepotvrđenog. Poruka poput "provjeravamo mogući neovlašteni pristup i trenutno ograničavamo pogođenu uslugu" korisnija je od šutnje, ali i poštenija od prerane tvrdnje da podaci nisu pogođeni.
Vanjske obavijesti ovise o zakonu, ugovoru, vrsti podatka i nadležnosti. Incident response plan zato treba sadržavati pripremljene kontakte i kriterije koje su pregledale pravna i sigurnosna funkcija. Tijekom incidenta tim ne bi trebao improvizirati tko razgovara s kupcima, partnerima, osiguravateljem ili nadležnim tijelom.
Dostupan backup nije sam po sebi odluka o oporavku. Prije vraćanja sustava u rad tim treba procijeniti je li uzrok dovoljno ograničen, je li odabrana kopija pouzdana, jesu li pristupni podaci promijenjeni gdje je potrebno i može li se isti put ponovno otvoriti.
Oporavak treba slijediti poslovni prioritet, a ne samo tehničku jednostavnost. Možda je važnije vratiti ograničenu funkciju koja omogućuje kritičan proces nego potpuno vratiti manje važan sustav. Poslovni vlasnik treba objasniti posljedicu prekida, dok tehnički vlasnik treba objasniti rizik i ovisnosti povratka u rad. Voditelj incidenta zatim dokumentira odluku i njezin razlog.
Za organizacije koje povezuju ERP, proizvodnju, računovodstvo i vanjske integracije to znači mapirati ovisnosti prije incidenta. Pregled procesa može otkriti koji prekid zaustavlja cijeli tok narudžbe, a koji se može privremeno premostiti ručnim postupkom. ORKA pristup kroz ERP i procesni screening može pomoći strukturirati taj razgovor oko procesa, vlasnika i točaka ovisnosti.
Nakon stabilizacije treba rekonstruirati odluke, a ne pisati priču o savršenom odgovoru. Korisna pitanja su konkretna:
Rezultat reviewa treba imati mali broj promjena, svaku s vlasnikom i rokom. Popis od pedeset općih preporuka često ne vodi do promjene. Prioritet imaju izmjene koje uklanjaju stvarnu nejasnoću: ažuriran kontakt, jasniji prag izolacije, provjerena procedura povratka ili vježba komunikacijskog kanala.
Aktualni stručni okvir NIST SP 800-61 Rev. 3 povezuje odgovor na incident sa širim upravljanjem rizikom kibernetičke sigurnosti. Taj okvir može usmjeriti planiranje, ali organizacija i dalje mora plan uskladiti s vlastitim hrvatskim zakonskim, ugovornim i sektorskim obvezama.
Provedite kratku stolnu vježbu bez tehničkog kvara. Javite malom timu da je važna usluga nedostupna i da postoji sumnja na neovlašteni pristup. Zatim pitajte: tko vodi odgovor, tko smije izolirati sustav, tko procjenjuje poslovni utjecaj, tko šalje internu poruku i koji je prioritet oporavka?
Ako odgovor nije brz i jednoznačan, pronašli ste nalaz koji treba riješiti prije stvarnog incidenta. Zabilježite ga u runbook, dodijelite vlasnika i ponovite vježbu nakon izmjene plana.