Andmeturbe olulisi elemente V Turbe korraldamine ja haldus

Andmeturbe olulisi elemente, V Turbe korraldamine ja haldus tüüpses asutuses/organisatsioonis Valdo Praust mois@mois. ee arvuti- ja andmeturbespetsialist isikuandmete kaitse seaduse kaasautor Infoühiskonna harrastusfilosoof Täienduskoolitus IT Kolledzis 12. oktoobril 2004

Turvalisus ja jääkrisk NB! Mitte ühegi turvameetme rakendamine ei loo kunagi absoluutset turvalisust. Need vaid vähendavad turvariski, st tõenäosust, et andmete terviklus, käideldavus või konfidentsiaalsus saavad kahjustatud Absoluutse turbe asemel räägitakse alati aktsepteeritavast jääkriskist, mis vastab teatud konkreetse olukorra mõistlikule turvatasemele Reeglina mõeldakse selle all olukorda, kus turvameetmete maksumus ning prognoositav turvarikest tulenev kahju on omavahel mõistlikus tasakaalus

Turbe majanduslik külg

Organisatsiooni turve Põhitõde: et kaitsta mingis asutuses või organisatsioonis kasutatavaid andmeid (infovarasid), tuleb andmeturbega tegeleda kogu andmetöötlusega seotud organisatsioonis Infovarade turvakadu ehk turvarike avaldab tihti kahjulikku mõju asutuse muudele varadele ja seega kogu asutusele Ka abipersonal on reeglina kaudselt siiski seotud andmete ning nende turvaomadustega

Turbehalduse tegevused ehk kuidas siis turve ikkagi saavutada, I 1. Infoturbe poliitika väljatöötamine 2. Rollide ja kohustuste piiritlemine organisatsioonis 3. Riskihaldus, sh kaitsmisele kuuluvate varade, riskide, turvameetmete, jääkriskide ja kitsenduste piiritlemine ja metoodika (nt ISKE) valimine

Turbehalduse tegevused ehk kuidas siis turve ikkagi saavutada, II 4. Turvaplaani koostamine 5. Turvateadlikkuse programmi evitamine 6. Turvaplaani teostamine 7. Süsteemi käikulaskmine 8. Järeltegevused

Mis on turvapoliitika (Info)turvapoliitika on eeskirjade, juhiste ja menetluste kogum, mis suunavad varade, (peamiselt infovarade) haldust, kaitset ja jaotamist organisatsioonis ning ta IT süsteemides On reeglina iga asutuse turbealane tähtsaim (poliitiline) alusdokument, mis määrab kindlaks põhiprintsiibid

Miks on vaja infoturvapoliitikat? Peapõhjus – enamike (info)varade (eriti andmete) kaitse eeldab süstemaatilist tegevust kogu sellega seotud organisatsioonis, mis arvestab erinevate elualade spetsiifikaid ja nõudeid NB! Infoturvepoliitika ei ole mitte IT spetsialistide pärusmaa, vaid reeglina suure hulga erinevate elualade spetsialistide turbefoorumi koostöö tulem (IT spetsialistid tunnevad reeglina ideaalselt ja detailselt vaid oma kitsast ala)

Tippjuhtkonna oluline osa Vaid tippjuhtkond teab, kuivõrd tähtis osakaal on organisatsiooni tegevuses erinevate varade erinevate omadustel ning kui olulist kahju võib nende kadumine kogu organisatsioonile tekitada Seepärast peab just juhtkond olema see, kes paneb paika, millisel tasemel on erinevate (info)varade erinevaid omadusi on vaja kaitsta. Konkreetsed suunised pannakse aga kokku erinevate alade spetsialistide poolt

Infoturvapoliitika tuleks koostada järgmiste talituste esindajate osavõtul: • kõrgem juhtkond • auditeerimine • rahandus • infosüsteemid (spetsialistid ja kasutajad) • tehnovõrgud ja infrastruktuur (st hoone ehitusliku osa eest vastutajad) • personaliala • üleüldine turve See seltskond kokku kannab nime infoturbefoorum

Turvapoliitika tüüpsisu, I 1. Sissejuhatus • ülevaade • turvapoliitika rakendusala ja eesmärk 2. Turvaeesmärgid ja -põhimõtted • eesmärgid • põhimõtted 3. Turbe organisatsioon ja infrastruktuur • kohustused • (konkreetsete alamsüsteemide) turvapoliitikad • turvaintsidentidest teatamine

Turvapoliitika tüüpsisu, II 4. Infoturbe ja riskianalüüsi strateegia • sissejuhatus • riskianalüüs ja riskihaldus • turbe vastavuse kontroll 5. Informatsiooni tundlikkus ja riskid • sissejuhatus • informatsiooni märgistuse süsteem • ülevaade organisatsiooni informatsioonist • informatsiooni väärtus ja tundlikkustasemed • ülevaade ohtudest, nõrkustest ja riskidest

Turvapoliitika tüüpsisu, III 6. Riistvara ja tarkvara turve • identimine ja autentimine • pääsu reguleerimine • arvestus ja revisjonipäevik • täielik kustutus, ründetarkvara • personaal- ja sülearvutite turve 7. Side turve • võrkude infrastruktuur • Internet • side krüpteerimine ja autentimine

Turvapoliitika tüüpsisu, IV 8. Füüsiline turve • hoone turvalisus ja kaitse, sh teenuste kaitse • volitamata hõive • juurdepääs arvutitele • juurdepääs andmekandjatele • personali kaitse • piksekaitse, kahjutule ja vee kaitse • ohtude avastamine ja teatamine • seadmete kaitse varguse eest • teeninduse ja hoolduse reguleerimine

Turvapoliitika tüüpsisu, V 9. Personali turve • palkamistingimused • turvateadlikkus ja -koolitus • personal ja lepingulised töötajad • kolmandad osapooled 10. Dokumentide ja andmekandjate turve • säilitamine • edastamine • kõrvaldamine (hävitamine)

Turvapoliitika tüüpsisu, VI 11. Tegevus eriolukordades • varundamine, sh varukoopiad • eriolukordade strateegia • olulisemate eriolukordade plaanid 12. Kaugtöö 13. Alltöövõtu poliitika 14. Muudatuste reguleerimine • turvapoliitika muutmispõhimõtted • turvapoliitika staatus organisatsioonis

Turvapoliitika tüüpsisu, VII Lisad: A. Turvajuhendite loend B. Seadused ja eeskirjad C. Organisatsiooni infoturbe eest vastutava isiku pädevus D. Infoturbe foorumi pädevus E. Oluliste alamsüsteemide (komponentide) turvapoliitika sisukord

Turbehalduse organisatsioonilised aspektid Rollid ja kohustused. Hädavajalikud: • infoturbe foorum • üleüldise infoturbe ametnik Järjekindel metoodika: • tegelemine kogu (infosüsteemi) elutsükli vältel • standardite järgimine

Infoturbe ametniku kohustused • side infoturbe foorumiga ja üleüldise turbe ametnikuga • intsidentide uurimise koordineerimine • üldise turvateadlikkusprogrammi juhtimine • turvaplaani täitmise jälgimine ja selle eest vastutamine

Turbe tegelik saavutamine ehk riskihaldusmetoodikad Eesmärk: rakendada täpselt selline kompleks turvameetmeid, mis viiks turvariski meile ettekirjutatud jääkriski piiresse • Nii käideldavuskao risk, tervikluskao risk kui ka konfidentsiaalsuskao risk tuleb viia lubatud jääkriskide piiresse • Tavaliselt on kõikide infovarade korral need kolm riski IT spetsialistile (andmeturbespetsialistile) juhtkonna poolt ette antud • Teostavad IT inimesed ja andmeturbespetsialistid

Riskihaldusmetoodika praktilised alternatiivid 1. Detailne riskianalüüs. On ideaallahendus 2. Etalonturbe metoodika. On odav ja mugav lahendus paljudel praktilistel juhtudel 3. Segametoodika. Võtab eeltoodud kahest parimad küljed, neid kombineerides 4. Mitteformaalne metoodika. On alternatiiv eeltoodud süsteemsetele (formaalsetele) lähenemistele

Detailne riskianalüüs 1. Hinnatakse jääkrisk. Selleks kasutatakse kas kvalitatiivset või kvantitatiivset riskianalüüsi metoodikat 2. Leitakse valdkonnad, kus on jääkriski vaja vähendada 3. Rakendatakse nendes valdkondades vajalikke turvameetmeid 4. Leitakse uus jääkrisk ja hinnatakse, kas see on piisaval tasemel (võrrelduna varade väärtuse ja turvameetmete maksumusega) 5. Kogu protseduuri korratakse, kuni saavutatakse aktsepteeritav jääkrisk

Detailse riskianalüüsi omadused Eelised: • annab olukorrast üsna tõepärase pildi • arvutatud jääkrisk on suure tõenäosusega tegelik jääkrisk • korraliku metoodika kasutamisel ei jää “turvaauke kahe silma vahele” Tõsine puudus: on tohutult ressursimahukas (töö, aeg, raha, spetsialistid)

Detailne riskianalüüs praktikas Järeldus: detailne riskianalüüs tasub ära vaid kalliste ülioluliste infosüsteemide korral, kus arendustöö on jäetud piisavalt aega ja raha Nende infosüsteemide korral, kus arenduseks kulutatavad rahalised vahendid on piiratud või arendustööle on seatud lühikesed tähtajad, detailne riskianalüüs ei sobi Sel juhul tuleb kasutada alternatiivseid riskihaldusmeetodeid

Etalonturbe metoodika olemus Etalonturbe metoodika korral on ette antud komplekt kohustuslikke turvameetmeid, millest kõikide realiseerimine peaks tagama teatud etalontaseme turbe (jääkriski) kõikide süsteemide kaitseks mingil etteantud (etalon)tasemel On peamine alternatiiv detailsele riskianalüüsile juhul, kui rahalised või ajalised ressursid ei võimalda seda realiseerida

Etalonturbe metoodika põhiidee 1. Võetakse ette tüüpiline infosüsteem oma komponentidega (hoone, tööruumid, serverid, riistvara, tarkvara, sideliinid, kasutajad, organisatsioon, pääsu reguleerimine jm) 2. Võetakse ette mingi etteantud turvatase 3. Rakendatakse riskianalüüsi (ühe korra!), nii et see turvatase saavutatakse 4. Fikseeritakse kõik kasutatud turvameetmed ühtse paketina ja loetakse etalonmeetmeteks 5. Eeldatakse, et igal teisel infosüsteemil annab sama paketi meetmete rakendamine sama tugevusega turbe (sama jääkriski komponendid)

Etalonturbe metoodika omadused Eelised: • riskianalüüsiga võrreldes kulub (mõni suurusjärk) vähem ressursse — aeg, raha, töö, spetsialistid • samu meetmeid saab rakendada paljudele erinevatele süsteemidele Puudused: • kui etalontase on kõrgel, võime teha tühja tööd • kui etalontase on liiga madal siis jäävad liiga suured jääkriskid (esineb turvakadu) • unikaalse arhitektuuriga infosüsteemide korral võib mõni valdkond jääda katmata ja tekitada ülisuure turvariski

Segametoodika: olemus Segametoodika võtab nii riskihalduse metoodikast kui ka etalonturbe metoodikast üle mitmeid häid omadusi, leides nende vahel mõistliku kompromissi Segametoodika kaks peamist võtet: 1. Etalonturbe metoodikad (etalonmeetmete komplektid) on välja töötatud mitme erineva turvataseme (käideldavus- terviklus- ja konfidentsiaalsustaseme) jaoks 2. Infosüsteemi kriitilistes valdkondades ja unikaalse arhitektuuriga osades kasutatakse riskianalüüsi, mujal aga odavamat etalonturbe metoodikat

Segametoodika omadused Eelised: • riskianalüüsiga võrreldes on ta vähem ressursimahukam • etalonmetoodikaga võrreldes võimaldab ta samas infosüsteemide (infovarade)ja nende komponentide lõikes individualiseeritumat lähenemist Puudused: • võrreldes riskianalüüsiga annab ta siiski vähem tõepärasema pildi • võrreldes etalonmetoodikaga on ta kallim

Mitteformaalne metoodika Mitteformaalse riskihalduse metoodika korral ei põhine riskide hindamine mitte abstraktsetel meetoditel, vaid spetsialistide (oma töötajad, välised konsultandid) kogemusel Kasutatakse juhul, kui: • riskianalüüs on vaja läbi viia väga kiiresti • etalonturbemetoodikaid ei ole või neid ei saa mingil põhjusel kasutada • riskihalduse metoodikad on liialt ressursimahukad ja seepärast kõlbmatud • on olemas arvestavate kogemustega spetsialistid

Mitteformaalse metoodika omadused Eelised: • pole vaja õppida uusi oskusi ja tehnikaid • saab läbi viia väiksemate ressurssidega (odavamalt) kui detailset riskianalüüsi Puudused: • struktuursuse eiramisega kaasneb alati risk jätta midagi olulist kahe silma vahele • kogemused võivad olla subjektiivsed või sageli hoopis puududa • kulutused turvameetmetele ei ole (juhtkonna ees) sageli põhjendatud • Suured probleemid tekivad analüüsi läbiviija töölt lahkumisel või töösuhte lõpetamisel

Infoturbeplaan on dokument, mis määratleb IT süsteemi turvapoliitika teostamiseks sooritamisele kuuluvad toimingud Toetub läbiviidud riskianalüüsi või etalonturbemetoodika (nt ISKE) tulemustele ja peab hõlmama: • ülevaate riskide hindamisest • turvameetmete evitamiseks vajalike toimingute loetelu • detailse tööplaani turvameetmete evitamiseks, prioriteetide, eelarve ja ajakavaga

Turvameetmete teostamine Infoturbeplaani teostamise eest vastutab IT süsteemi turbe ametnik Tuleb tagada, et: • turvameetmete maksumus jääb kinnitatud piiridesse • turvameetmed oleksid teostatud õigesti, vastavalt infoturbeplaanile • turvameetmeid kasutatakse ja hallataks vastavalt infoturbeplaanile

Lõpuks on süsteem valmis (ja ehk ka turvaline? ) Turbeplaani teostamise lõpus tuleb turvameetmete evitus ametlikult kinnitada NB! Alles peale seda võib IT süsteemi käiku lasta. NB! Iga IT süsteemi kaaluka muudatusega peab kaasnema süsteemi turvaalane korduskontroll, testimine ja kinnitamine.

Infoturbe järeltegevused • hooldus • turvaaudit • seire • intsidentide käsitlus • muutuste haldus

Hooldus Juhtkonna kõigi tasemete kohus on tagada: • ressursside eraldamine turvameetmete hooldusele • turvameetmete perioodiline taasvalideerimine • turvameetmete värskendamist (uute ilmnemisel) • hoolduskohustuste selge määratlus • turvameetmete toime muutumatus tark- ja riistvara muutmisel • tehnoloogia täiustamisega kaasneda võivate uute ohtude ja nõrkuste vältimine NB! Turve ei ole ühekordne projekt, turve on pidev protsess!

Turvaaudit • On turbe vastavuse kontroll (ehk meetmete vastavus nõuetele) • Tuleb läbi viia kas väliste subjektide kaasabil või oma personaliga • Tuleks ühitada teiste plaaniliste tegevustega

Turvaseire Annab juhtkonnale pildi sellest: • mida on saavutatud võrreldes eesmärkidega ja tähtaegadega • kas saavutused rahuldavad või mitte

Intsidentide käsitlus Intsidentide uurimise põhieesmärgid: • annab aluse intsidendile mõistlikule ja tõhusale reageerimisele • aitab õppida intsidentidest nende edaspidiseks vältimiseks Analüüs tuleb dokumenteerida, fikseerides: • mis ja millal juhtus? • kas personal järgis plaani? • kas vajalik teave oli personalile õigel ajal kättesaadav? • mida oleks tulnud teha teisiti?

Muutuste halduse alla kuuluvad kõik: • uued protseduurid • uued omadused • tarkvaratäiendid • riistvara täiustused • uued kasutajad • võrkude laiendamine ja kokkuühendamine

Kokkuvõtteks 1. Organisatsiooni (info)turbe eduka realiseerimise eelduseks on õige turbehaldus 2. Turbega tuleb tegeleda kogu organisatsioonis 3. Initsiatiiv peab tulema organisatsiooni juhtkonnalt, kes peab olema asjast eluliselt huvitatud ja juhtima turbetööd kõrgemal tasemel 4. On vajalik teatud institutsioonide, dokumentide, töökohtade jm olemasolu

Mida on infoturbe halduse standardimise alal Eestis ja maailmas tehtud? • on koostatud standarte pere ISO/IEC TR 13335 • need standardid on tõlkemeetodil üle võetud Eesti rahvuslikeks standarditeks EVSISO/IEC TR 13335 • Käesolev ettekanne põhines neil standarditel

Mis see kõik maksab? Maailmapraktika põhjal statistikat tehes võib öelda, et tüüpilise infosüsteemi korral kulub turbega seotule ca 10% infosüsteemi kogueelarvest • Erijuhtudel (kõrgendatud riskid, ebastandardne lahendus, erisoovid vms võib see olla aga ka kuni 20 -25% • Täpne arv selgub turvaanalüüsi tegemise käigus, mis peab eelnema süsteemi tegelikule projekteerimisele • Kui turbega ei tegelda süsteemi algusest peale, vaid seda püütakse peale ”pookida” hiljem, võivad kulutused kahe- kuni kolmekordistuda

Epiloog Süsteemi turvalisuse määrab ära nõrgim lüli Ei ole võimalik tõestada turvalisust, tõestada saab vaid ebaturvalisust Vrd: Ei ole võimalik tõestada, et ihukaitseb VIPi turvaliselt On võimalik vaid tõestada, et ta kaitseb VIPi ebaturvaliselt – VIP maha lasta

Käesoleva ettekande materjalid (MS Power. Point 2000 vormingus) on saadaval veebis aadressil http: //www. itcollege. ee/~valdo/taiend/plokk 2 -5. ppt Edasised küsimused palun aadressil mois@mois. ee

Tänan tähelepanu eest!