Intsidendihaldus plaan: Mida see sisaldab ja miks on see oluline?
Küberturvalisusest rääkides keskendume sageli ennetusele ja tööriistadele. Investeerime tulemüüridesse, viirusetõrjetesse ja tugevatesse ligipääsukontrolli süsteemidesse, lootes pahalasi eemal hoida. Ent tõsiasi on see, et isegi kõige paremini kaitstud süsteemid võivad sattuda rünnaku alla. See pole mitte pessimistlik, vaid realistlik vaade.
Just seetõttu vajab iga organisatsioon — sõltumata suurusest või tegevusvaldkonnast — läbimõeldud Intsidendihaldus Plaani (IRP ehk Incident Respone Plan).
IRP kui kindlustus
Meil kõigil on kindlustus auto, kodu ja tervise jaoks — mitte seepärast, et ootaksime halvimat, vaid kuna mõistame, kui oluline on olla valmis. IRP on justkui küberturbe kindlustuspoliis — konkreetne tegevusplaan, mis aitab kriisiolukorras tegutseda kiiresti, läbimõeldult ja süsteemselt.
Tihti on see ka nõutud kas mõne strandardi, koostööpartneri, seaduse või näiteks kindlustuspakkuja poolt.
Miks IRP ei ole enam valikuline?
Kübermaailmas ei ole küsimus “kas”, vaid “millal” midagi juhtub. Hästi koostatud IRP aitab:
Minimeerida kahjusid – kiire ja koordineeritud tegutsemine vähendab rahalist, maine- ja ärikahju.
Kiirendada taastumist – teate täpselt, mida järgmisena teha.
Kaitsta mainet – tõhus ja läbipaistev tegutsemine näitab, et võtate turvalisust tõsiselt.
Tagada vastavus nõuetele – näiteks GDPR nõuab intsidentide haldamiseks selget protsessi.
Tugevdada turvapositsiooni – iga intsident annab väärtuslikke õppetunde kui sellele läheneda süstemaatiliselt.
Intsidendihaldus plaani olulisemad osad
IRP on erinev igas organisatsioonis, siiski pakun välja järgmised komponendid mis on pea universaalsed:
1. Ettevalmistus: Alus tugevaks reageerimiseks
Intsidendile reageerimine hakkab alati ennem kui intsident tekib. Selleks on oluline panna paika:
Rollid ja vastutused: Kes kuulub IR (incident response) meeskonda? Millised on nende ülesanded (nt intsidentide juht, tehniline vastutaja, kommunikatsioon, juriidiline)?
Kommunikatsiooniplaan: Kuidas info liigub? Kas on olemas valmis teavitusmallid klientide ja ametkondade jaoks? Kellega peab mis juhul ühendust võtma? Kas kliente on vaja kohe teavitada? Aga CERT-EE?
Tööriistad ja ressursid: Millised turva- ja analüüsivahendid on olemas? Kas neid osatakse IR meeskonnas kasutada? Mis juhtub kui enda ressurssidest ei piisa? Kas partner tuleb appi? Kes? Kas tal ligipääsud on?
Harjutused ja koolitused: Regulaarne testimine aitab meeskonnal tegutseda ka surve all. Terve intsidendihaldus protsess tuleks läbi harjutada ja veenduda, et meeskonnal on vajalik taust olemas. Kui on vaja, siis tuleb ka koolitada meeskonda.
2. Tuvastamine: Anomaaliate märkamine
Ettevalmistusega samal ajal toimub ka pidev tuvastamise etapp. Selles etapis me aktiivselt monitoorime nii seadmeid, võrke kui ka platvorme ja keskkondi kus meie väärtuslik info asub. Peamised komponendid on:
Jälgimis- ja häiresüsteemid: Kas võimalikud sissetungid, logid ja kasutajate käitumine on monitooritud? Kes neid logisi jälgivad?
Triaaž ja analüüs: Kas tegemist on tõelise intsidendiga? Kui tõsine see on?
Intsidendihalduses plaanis tuvastamise eest vastutav isik või isikud peavad tavaliselt omama väga head arusaama nii organisatsioonist kui selle infosüsteemidest ja omama kõrgeid ligipääse. Ei tasu ka ära unustada uute projektide ja lahenduse rakenduse korral konsulteerimist - kas see uus lahendus on monitooritav? Kui jah, siis kuidas? Kas lgipääsud on ja kõik muud küsimused mis olid ka ettevalmistuse etapis tuleb iga uue lahenduse puhul uuesti läbi käia.
3. Analüüs ja piiramine: Kahju leviku tõkestamine
Juhul kui me oleme nüüd kindlad, et intsident on leidnud aset siis me liigume ettevalmistavast ja tuvastamise faasist edasi analüüsi ja piiramise etappi. See ei tähenda, et me lõpetame ettevalmistumise ja tuvastamise. Keerulisemate intsidentide korral võib intsidendihaldus meeskond töötada lahenduse kallal nädalaid. Samal ajal peavad nii ettevalmistavad tegevused kui tuvastamine toimima oma tavalisel võimekusel, et vältida uusi intsidente. Parem ikka üks intsident kui mitu korraga.
Intsidendi analüüsi käigus vaatame üle kõik tõendid mis meil intsidendi kohta on ja esitame järgmised küsimused:
Millal intsident tegelikult algas?
Mis seadmest või süsteemist intsident alguse sai?
Mis seadmetesse või süsteemidesse on intsident laienenud?
Mis võimalused meil teha piiramiseks on?
Esimene fookus ongi mitte intsidendi peatamisel vaid leviku piiramisel. Piiramiseks on meil kaks peamist lähenemist:
Lühiajaline piiramine: Süsteemide eraldamine, IP-de blokeerimine, teenuste ajutine peatamine.
Pikaajaline piiramine: Algpõhjuse leidmine ja kordumise vältimine.
Kui intsidendi levik on edukalt piiratud on meil võimalus rahulikult koguda vajalikke tõendeid nagu logid, algallika IP aadress jmt. mida meil on vaja, et täielik intsidendi ajajoon välja joonistada.
4. Likvideerimine: Ohu eemaldamine
Kui meil on selge täpselt ja täielikult mis juhtus ja miks siis saame koguda oma tõendid millest hiljem õppida ja edasi liikuda intsidendi likvideerimisse. Likvideerimiseks kasutame tavaliselt mõnda või mitut järgmistest variantidest:
Pahavara eemaldamine - Kas käsitsi või mõnda antiviirust kasutades pahavara täielik eemaldamine süsteemist.
Nõrkuste parandamine - Kui on meie enda arendatud tarkvara või infosüsteem siis saame ka ise nõrkused parandada. Kui mitte siis näiteks läbi süsteemiuuenduste saame nõrkuseid likvideerida.
Süsteemide taastamine - Vahest ei aita miski muu kui süsteem uuesti nullist installeerida, et eemaldada pahavara. On ka viiruseid mille puhul peame vahetama riistvara komponente, et pahavarast lõplikult lahti saada.
Eesmärk on siin etapis on likvideerida kogu pahalase poolt süsteemidesse tekitatud haavatavused ja pahavarad. Samuti panna kinni teed mida pahalane kasutas meie süsteemidesse saamiseks, vastasel juhul tuleb ta peale taastamist kohe tagasi.
Likvideerimise faasis ja selle lõpuks ei ole süsteemid veel tagasi kasutuskõlblikus seisus. Sellega tegeleme järgmisena.
5. Taastamine: Tööga jätkamine
Kui me oleme kindlad, et kogu pahavara on edukalt eemaldatud ja mingeid tagauksi ei ole lahti jäetud siis saame liikuda edasi süsteemide tagasi täielikku töökorda toomisega. Selleks teeme tavaliselt mõnda järgmistest sammudest.
Süsteemide taastamine varukoopiatest: Kui koopiaid ei ole siis uuesti algusest installeerimine ja seadistamine.
Testimine ja valideerimine: Kas kõik töötab ja on turvaline? Siin on tihti vaja ka süsteemi peakasutaja abi sest näiteks raamatupidamise tarkvara puhul ei oska reeglina intsidendimeeskond ise testida kas lahendus töötab täielikult nii nagu peab.
Täiendav monitooring: Et olla kindel, et oht ei kordu.
Sellega oleme me nüüd edukalt läbinud intsidendihalduse põhietapid ning süsteemide töö taastanud. Siiski on üks äärmiselt oluline etapp jäänud.
6. Järeltegevused: Õppimine ja täiustamine
Peale igat intsidenti on kriitiliselt oluline istuda korra maha ja vaadata kogu intsidendile uuesti otsa.
Intsidendi kaardistamine: Kas saime ikka kõigest tervikult aru? Kas kõik sai kirja? Kas tõendid toetavad seda?
Õppetunnid: Mis töötas? Mis mitte? Miks?
Dokumentatsioon ja aruandlus: Kas teil on tuleviku jaoks selge pilt?
Plaani uuendamine: Iga intsident on võimalus tugevamaks muutuda.
Kui järeltegevused on tehtud siis läheb intsidendimeeskond tgasi oma tavatöö juurde milleks on ettevalmistamine ja tuvastamine.
Ära jää ootama kuni midagi juhtub!
IRP koostamine võib tunduda ajamahukas, kuid selle väärtus tuleb esile just kriisi ajal. See muudab kaose juhitavaks. Ära jää ootama intsidenti, et hakata mõtlema, mida edasi teha — planeeri juba täna. Sinu organisatsiooni jätkusuutlikkus sõltub sellest.
Kui sul on abi vaja intsidendihaldus plaani loomisel siis võta julgelt meiega ühendust info@f0.ee!
Pakume ka intsidendihaldus plaani koostamise workshopi ja meeskonna koolitamist nii kohapeal kui kaugelt.