Dilberti koomiksis on üks hea pilt sellest, milline on tüüpiline turvaintsidentidele reageerimise tegevusplaan: põgenemine ja appi karjumine. See pole muidugi kuigi toimiv lahendus, aga paraku päris tihti just nii ongi. Samas on tegevusplaani alles kriisis koostama hakata juba liiga hilja.

Viimatine Solarwindsi juhtum, kui rünnati suuri ja soliidseid organisatsioone (vaata ülevaadet lähemalt siit) näitab, et ettevõttes võivad olla küll väga targad ja kogenud inimesed, kes pole kaugeltki saamatud, aga ikkagi võib neid rünnak tabada. Seega pole mingit põhjust ennast süüdistada või toimunut varjama hakata. Kui kõik varjavad, siis tekib petlik tunne, et tegelikult midagi ei toimugi, maailm on turvaline. Kui intsidendid hoitakse vaid enda teada ning mõnikord ei jagata seda infot isegi ettevõtte sees, siis küsivad juhid, et miks üldse investeerida infoturbesse, kui midagi ei juhtu?

Selline seis on paljudes suuremates ettevõtetes ja puudu on plaan, mille järgi tegutseda, kui infoturbeintsident peaks tõesti toimuma.

Mis on IT turvaintsident?

IT turvaintsident on ettevõtte infoturbe poliitika rikkumine või otsene rikkumise oht, mille puhul rakendatakse selle jaoks koostatud eeskirju, tegevusplaane või standardseid turvapraktikaid.

Näiteks on toimunud turvaintsident, kui

• …ründaja annab robotite võrgule (botnet) käsu saata serverile suur hulk ühendustaotlusi, millega server ei suuda enam oma tegelikke kliente teenindada ja teenus lõpetab töötamise
• …kasutajatele on petukirjaga saadetud n-ö majandusaruanne, mis sisaldab tegelikult pahavara ja nakatab arvuteid, luues hiljem ühendused välise hostiga edasisteks rünnakuteks
• …ründaja saab kätte sensitiivsed andmed ja ähvardab, et lunaraha maksmata need avalikustatakse
• …firma enda kasutaja pakub või avaldab delikaatset teavet teistele mõne failijagamisteenuse kaudu.

Nende juhtumite puhuks peab olema valmis varem koostatud tegevusplaan. See eeldab ka ohu- ja riskianalüüsi läbiviimist, et teaks arvestada, mida erinevate juhtumite puhul tuleb teha.

Tegevusplaanis alusta lihtsamast

Selleks, et turvaintsidentidele reageerimise plaani teha, ei pea tuhandeid lehekülgi dokumente koostama. Alusta lihtsamatest toimingutest, nagu näiteks sellest, kes vastutab erinevate tegevuste eest, mismoodi edasist kahju peatada, kuidas olukordi testida ning kasvõi seda, kuidas varundusest taastamine töötab.

Tegevusplaani peaks tegema ettevõttes koos teistega, mitte IT- või infoturbejuht üksi. Kindlasti on vaja varem ka eel-autoriseerimist juhtidelt, mida nad intsidendi puhul kohe lubavad teha, et ei peaks kriisihetkel hakkama helistama ja kooskõlastama, kui maja juba nii-öelda põleb.

Kui plaan valmis, testid tehtud ja ettevõtte juhtkond kursis, milline tegevus reageerimiseks vajalik, siis edaspidi peaks see jõudma justnagu tegijate lihasmällu: igaüks teab, mida kriisiolukorras vaja ette võtta.

Küber-intsidendi lahendamiseks on vaja kiirelt reageerida

Tõsisemate infoturbejuhtumitega alahindavad inimesed vajadust teenuseid kohe isoleerima hakata, kardetakse ülereageerimist. Paraku pole aega isegi õhtuni oodata, nagu näitab hiljutine uuendamata Exchange´i serveritarkvara kompromiteerimine (vaata lähemalt toimunu ajajoont siit ja Postimehe uudist siit). Tegutseda tuleb kohe, kuigi näiteks e-posti teenus on ettevõtte jaoks väga oluline ja selle katkestamine isegi lühemaks ajaks tõsine samm. Hilinedes võib aga juhtuda, et ühe kaitse langemisel (nt Exchange´i sisse pääsedes) langevad edasi ka juba teised kõrgemad tasemed, näiteks Active Directory ligipääs ja siis on olukord ettevõtte jaoks juba väga halb – selgelt halvem, kui lühiajaline e-posti teenuse katkemine.

Lisaks oma jõududele on paljude intsidentide lahendamisel vaja tihti ka välist abi:

• ISP-d ehk internetiteenuse pakkujat võrgupõhiste massirünnakute blokeerimisel või nende allika träkkimisel.
• Ründe allikate IP aadresside omanikku, kui ründajad kasutavad mõne teise ettevõtte kompromiteeritud võrku ja vahendeid.
• CERT-EE abi, kui probleem on suurem ja vajab riikliku organisatsiooni sekkumist.
• Tarkvaratootjaid, kui põhjus võib olla tarkvara turvaaugus või veas. Samuti võib arendaja aidata leida logidest sissetungi jälgi või tüüpilisi rünnakuid lahendada.
• Teised sedasorti turvaintsidente lahendavad firmad aitavad oma oskustega keerulisemate rünnete tõrjumisel ja kaitsmisel, kuna igas ettevõttes ei pruugi vastavaid oskusi leiduda.
• Partnerite ja klientide abi, kui rünnak puudutab ka nende andmeid ja turvalisust.

Mille vastu peaks valmistuma?

Küber-intsidendid ja rünnakud pärinevad erinevatest allikatest ning neile reageerimiseks peaksid olema juhised. Siin on mõned levinuimad ründevektorid, mida arvestada juhiste koostamiseks:

• Väline/eemaldatav andmekandja – rünnak toimub läbi välise seadme, näiteks nakatunud USB-mälupulgalt, kust süsteemi siseneb pahatahtlik programmikood
• Ülekoormusrünnakud kasutavad toorest jõudu süsteemi ressursside ummistamiseks, võrgud või teenused lakkavad teenusetõkkerünnakuga normaalselt toimimast. Toore jõuga rünnates võidakse lisaks teenuste kahjustamisele proovida murda autentimismehhanismi, näiteks paroolidega, CAPTCHA tõestusega või muud moodi ligipääsu.
• Veebirünnak viiakse läbi veebisaidilt või veebipõhisest rakendusest – näiteks kasutades ära uuendamata veebitarkvara turvaauku, mis annab ligipääsu teistele süsteemidele ettevõttes.
• Skriptirünnak on kasutusel sessioonide kaaperdamiseks või kasutaja ümbersuunamiseks saidile, mis kasutab ära veebibrauseri haavatavust, installides kasutaja arvutisse pahavara edasisteks rünneteks.
• E-posti rünnak viiakse tavaliselt läbi meilisõnumi või meililisandiga, kasutades näiteks e-kirjaga kaasa pandud varjatud koodi. Mõnikord piisab ka e-kirjaga lingi saatmisest, millel klikkides käivitatakse kahjulik kood lingitud saidilt.
• Asendusrünnak asendab millegi ettevõtte jaoks vajaliku pahavaraga või võltslahendusega, nii et kasutaja ei saa sellest aru. Siin on levinumateks näideteks Man in the middle rünnakud, kui infot võetakse vahelt, võltsitud traadita võrgu tugijaamad ning SQL-i süstimine (SQL injection).
• Ebaõige kasutamine – siia alla kuuluvad kõik juhtumid, mis tulenevad organisatsioonis vastu võetud kasutamise eeskirjade rikkumisest. Näiteks rikutakse volitatud kasutaja eeskirju ja antakse ligipääs või vahendid kellelegi teisele, keegi installib failide jagamise tarkvara, mis viib tundlike andmete lekkimiseni jne.
• Seadmete kadumine või vargus – kui sülearvuti, nutitelefon või autentimisseade kaotatakse ja see satub kellegi kätte, kes võib seadmest kätte saada sensitiivset infot või ligipääsu.

Mis saab pärast?

Kui intsident on juba toimunud, siis pärastised tegevused on samuti väga olulised. Mida me sellest kõigest õppisime ja millised on kahjud?

Juhtumitele reageerimise üks olulisemaid osi ehk järeldused ja kokkuvõtted on üsna tihti tegevuskavadest puudu. Meeskond peaks iga intsidendiga õppima ja edasi arenema, et paremini avastada uusi ohte, täiustada tehnoloogiat ja saada uusi kogemusi. Tegevused kriisiolukorras peaksid testides ja harjutades jõudma nii-öelda lihasmällu, et kõik toimiks automaatselt. Järeldustesse peaksid jõudma järgmised kokkuvõtted:

• Mis täpselt juhtus ja millal?
• Kui hästi töötajad ja juhtkond vahejuhtumiga toime tulid? Kas kõik sai dokumenteeritud?
• Millist infot oleks olnud vaja varem?
• Kas võeti ette mingeid samme või toiminguid, mis võisid intsidendist taastumist raskendada?
• Mida teeksid töötajad ja juhtkond teisiti, kui järgmine kord toimub sarnane turvaintsident?
• Kuidas oleks võimalik parandada infovahetust teiste organisatsioonidega?
• Millised parandused võivad sarnaseid juhtumeid tulevikus ära hoida?
• Milliseid täiendavaid tööriistu või ressursse on vaja tulevaste juhtumite avastamiseks, analüüsimiseks ja ärahoidmiseks?

Turvaintsidentide vähesus on illusioon

Eestis on praegu üldist teadlikkust turvaintsidentideks ettevalmistamisel vähe, sest endiselt arvatakse üsna tihti, et minu ettevõtet see ei puuduta. Tegelikult on see illusioon, mille ongi osaliselt tekitanud intsidentide maha vaikimine ja salgamine. Olukorda parandab kindlasti see, kui rääkida neist asjadest, muidu midagi ei parane ja keegi ei teagi, et midagi võib juhtuda.

Internetis on selle kohta infot palju, tasub lugeda ja teha oma ettevõttele vajalikud versioonid tegevuskavadest. Üks võimalik allikas oma maja juhendite koostamiseks on näiteks siin.

Paljudel infoturbega tegelevatel spetsialistidel on enda jaoks mingeid infoturbe tegevusplaane kindlasti ka juba sahtlisse kirjutatud, aga sellest on vähe, kui ülejäänud organisatsioon on selles osas pime. Seda tuleks ka teistega jagada, eriti aga juhtkonnaga.

Turvariskid aastatega aina kasvavad, seega ei saa lootma jääda, et meiega midagi niikuinii ei juhtu. Tegelikult juhtub ettevõtetega turvaintsidente palju ja tunduvalt rohkem, kui avalikuks tuleb ning uudistesse jõuab.

Kui Sul on turvaintsidentide käsitlemise kohta küsimusi, võta Lakeforest Consult`iga julgesti ühendust.