Võrgu- ja infosüsteemi riskianalüüsi nõuded ning turvameetmeete kirjeldus

Kaitseministeerium Justiitsministeerium Meie 14.05.2018 nr 2-2/17-0344/4227 Sotsiaalministeerium Välisministeerium Rahandusministeerium Siseministeerium Haridus- ja Teadusministeerium Kultuuriministeerium Maaeluministeerium Keskkonnaministeerium „Võrgu- ja infosüsteemi riskianalüüsi nõuded ning turvameetmeete kirjeldus“ määruse eelnõu Majandus- ja Kommunikatsiooniministeerium edastab kooskõlastamiseks „Võrgu- ja infosüsteemi riskianalüüsi nõuded ning turvameetmete kirjeldus“ määruse eelnõu. Lugupidamisega (allkirjastatud digitaalselt) Urve Palo ettevõtlus- ja infotehnoloogiaminister Lisad: 1. Eelnõu 2. Seletuskiri Lisaadressaadid: Eesti Infotehnoloogia ja Telekommunikatsiooni Liit Eesti Haiglate Liit Eesti Vee-ettevõtete Liit Eesti Pangaliit Eesti Kiirabi Liit Eesti Jõujaamade ja Kaugkütte Ühing Eesti Elektritööstuse Liit Eesti Gaasiliit Eesti Õliühing MTÜ Eesti Asfaldiliit MTÜ Eesti Perearstide Selts Eesti Interneti Sihtasutus Eesti Maaomavalitsuste Liit Eesti Linnade ja Valdade Liit Suur-Ameerika 1 / 10122 Tallinn / 625 6342 / [email protected] / www.mkm.ee Registrikood 70003158  Eesti Rahvusringhääling Riigi Infokommunikatsiooni Sihtasutus Madis Raaper 6397615 [email protected] 2 (2)  MÄÄRUS ..…………………… nr ….. EELNÕU 11.05.2018 Võrgu- ja infosüsteemi riskianalüüsi nõuded ning turvameetmete kirjeldus Määrus kehtestatakse küberturvalisuse seaduse § 7 lõike 4 alusel. § 1. Reguleerimisala Määrusega kehtestatakse nõuded küberturvalisuse seaduse § 3 lõikes 1 loetletud teenuste osutamiseks kasutatava võrgu- ja infosüsteemi (edaspidi süsteem) riskianalüüsi koostamisele ja organisatsiooniliste, infotehniliste ja füüsiliste turvameetmete valikule ning turvameetmete kirjeldus. § 2. Nõuded süsteemi riskianalüüsile (1) Süsteemi riskianalüüs on süsteemi turvalisust ja teenuse toimepidevust ohustavate riskide ja nende haldamiseks rakendatavate meetmete kirjeldus. (2) Riskianalüüsis peab sisalduma vähemalt järgmine teave: 1) riskianalüüsis kasutatud metoodika lühikirjeldus, valitud metoodika põhjendus ning viited riskianalüüsiga seotud lisadokumentidele; 2) loetelu teenuse osutamiseks vajalikest kriitilistest tegevustest, mille puudumine toob kaasa teenuse katkestuse või häire, ja loetelu kriitiliste tegevuste toimimiseks vajalikest süsteemidest; 3) loetelu süsteemiga seotud ressurssidest; 4) loetelu ohtudest, mis võivad põhjustada küberintsidendi; 5) loetelu nõrkustest, mis võivad ohtude realiseerumist soodustada; 6) hinnang ohtude realiseerumise tõenäosusele, arvestades tuvastatud nõrkusi ja rakendatud meetmeid; 7) hinnang ohtude realiseerimisel tekkida võiva küberintsidendi tagajärgedele ning tagajärgede raskusaste, arvestades tagajärgede raskusastme määramise kriteeriumitena vähemalt küberintsidendist mõjutatud isikute ligikaudset arvu, teenuse katkemise kestust, küberintsidendi geograafilist ulatust ning tekkida võiva kahju liiki ja määra; 8) riskihinnang ohu realiseerimise tõenäosuse ja tagajärgede raskusastme alusel ning riskide hierarhiline esitus;  2 9) turvameetmete rakendamise tegevuskava koos iga meetme rakendamise eest vastutava isiku ja meetme rakendamise tähtajaga. (3) Teenuse osutaja tagab riskide pideva seire ja uuendab riskianalüüsi iga uue olulise riski ilmnemisel. § 3. Nõuded turvameetmete valikule (1) Teenuse osutaja peab turvameetmete valikul ja rakendamisel lähtuma vähemalt ühest järgnevast infoturbe nõuete kogumist, kui seadus ei sätesta teisiti: 1) infoturbe standard EVS-ISO/IEC 27000 seeriast; 2) turvameetmete süsteem ISKE; 3) teenuse osutaja tegevusvaldkonnas kehtestatud infoturbe nõuded. (2) Turvameetmetega hõlmatakse: 1) protseduure, ressursse, tegevusi ja küberintsidendi lahendamise korraldust; 2) personali tööülesandeid ja vastutust. § 4. Turvameetmete kirjeldus süsteemi turvalisuse tagamiseks (1) Turvameetmetega nähakse ette vähemalt: 1) süsteemi juurdepääsuõiguste haldamine, süsteemi kasutajate identifitseerimine ja autoriseerimine; 2) teenuse osutamiseks vajalikest andmetest regulaarse varukoopiate tegemine ja protseduurid andmete varukoopiatest taastamiseks; 3) süsteemi käitava ja süsteemis käideldava tarkvara ajakohasuse nõue; 4) süsteemis läbiviidavate toimingute logid toimingu teostaja, toimingu liigi ja toimingu teostamise ajaga; 5) tarkvaralised ja riistvaralised lahendused süsteemi turvalisust ohustava tegevuse ja tarkavara tuvastamiseks ning tõrjumiseks; 6) taasteprotseduurid süsteemi turvalisuse või teenuse toimepidevuse taastamiseks. (2) Teenuse osutaja seirab ja ajakohastab turvameetmeid, et tagada turvameetmete vastavus käesoleva määruse § 2 alusel koostatud riskianalüüsis sätestatud riskihinnangutele. § 5. Määruse rakendamine Teenuse osutaja koostab esmakordselt § 2 kohase riskianalüüsi 31. detsembriks 2018. a. Urve Palo ettevõtlus- ja infotehnoloogiaminister Merike Saks kantsler  11.05.2018 Ettevõtlus- ja infotehnoloogiaministri määruse „Võrgu- ja infosüsteemi riskianalüüsi nõuded ning turvameetmeete kirjeldus“ eelnõu seletuskiri 1. Sissejuhatus 1.1. Sisukokkuvõte Määruse eelnõuga kehtestatakse nõuded võrgu- ja infosüsteemide riskianalüüsi koostamisele ning turvameetmete kirjeldus. Eelnõu on seotud Riigikogu menetluses oleva küberturvalisuse seaduse eelnõuga, millega võetakse Eesti õigusesse üle direktiiv (EL) nr 2016/1148 meetmete kohta, mille eesmärk on tagada võrgu- ja infosüsteemide turvalisuse ühtlaselt kõrge tase kogu liidus (ET 19.07.2016 L 194/1). Olemuslikult on samasisulise määruse hädaolukorra seaduse (RT I, 03.03.2017, 1, edaspidi HOS) § 41 lõike 3 alusel välja andnud Vabariigi Valitsus1, kuid küberturvalisuse seaduse jõustumisel tunnistatakse viidatud HOSi säte kehtetuks ning küberturvalisuse seaduse § 7 lõike 4 alusel kehtestab määruse ettevõtlus- ja infotehnoloogiaminister, kuivõrd vajadus Vabariigi Valituse taseme õigusakti järele puudub. Määruse eelnõus kasutatud mõisted „võrgu- ja infosüsteem“, „süsteemi turvalisus“ ning „küberintsident“ on defineeritud küberturvalisuse seaduse eelnõu §-s 2. 1.2. Ettevalmistajad Määruse eelnõu ja seletuskirja on koostanud Riigi Infosüsteemi Ameti teenuste turvalisuse osakonna küberturbe ekspert Ragnar Õun (e-post: [email protected]), Riigi Infosüsteemi Ameti riskijuht Merilin Sülla (e-post: [email protected]) ning Riigi Infosüsteemi Ameti õigusvaldkonna peaspetsialist Elsa Neeme (e-post: [email protected]). Eelnõu juriidilise ekspertiisi teostas Majandus- ja Kommunikatsiooniministeeriumi õigusosakonna õigusnõunik Anne-Ly Normak (tel: 715 3403, e-post: [email protected]) ja keeletoimetuse juhtkonna referent-keeletoimetaja Kristiane Liivoja (tel: 625 6370, e-post: [email protected]). Eelnõu sisu osas on kontaktisikuteks Ragnar Õun ning Merilin Sülla. 1.3. Märkused Eelnõu on seotud Riigikogu menetluses oleva küberturvalisuse seaduse eelnõuga (597 SE2, edaspidi KüTS). 2. Eelnõu sisu ja võrdlev analüüs Eelnõu koosneb viiest paragrahvist. 1 Vabariigi Valitsuse määrus nr 133 „Elutähtsa teenuse infosüsteemide ning nendega seotud infovarade turvameetmed“ (RT I, 09.08.2017, 3). 2 https://www.riigikogu.ee/tegevus/eelnoud/eelnou/61815f7a-1025-4aea-9b0e- d9cf97337e59/Küberturvalisuse%20seadus 1 Eelnõu § 1 sätestab määruse reguleerimisala. Määrusega kehtestatakse nõuded elutähtsa ja ühiskondlikult olulise teenuse osutamiseks kasutatavate võrgu- ja infosüsteemide riskianalüüsile ning täpsustatakse turvameetmete rakendamise nõudeid. Määrus kohaldub juriidilistele isikutele, kes osutavad KüTSi eelnõu § 3 lõikes 1 loetletud teenuseid. Eelnõu § 2 loetleb nõuded teenuse osutaja koostatavale süsteemi riskianalüüsile. Lõikes 1 avatakse riskianalüüsi mõiste. Riskianalüüsile määruse eelnõu kindlaid vorminõudeid ette ei anna, oluline on, et riskianalüüs oleks dokumenteeritud taasesitamist võimaldavas vormis. Elutähtsate teenuste osutajate puhul võib riskianalüüs olla nii HOSi § 38 lõike 3 punktis 1 kirjeldatud teenuse toimepidevuse riskianalüüsi osa kui ka eraldiseisev dokument. Seega ei konkureeri HOSis elutähtsa teenuse toimepidevuse riskianalüüsile kehtestatud nõuded eelnõus sätestatud nõuetega. Riskianalüüsi eesmärk on selgitada välja, kas ja millisel määral mõjutavad võrgu- ja infosüsteemid kriitilise äritegevuse toimepidevust. KüTSi eelnõu §-s 8 sätestatud küberintsidendist raporteerimise kohustuse vaatest ning viidatud sättes kirjeldatud olulise mõjuga küberintsidendi kontekstis on riskianalüüsil küberintsidendi mõju olulisuse künnise hindamise funktsioon. Sealjuures on intsidendi mõju olulisuse hindamise üks eesmärk lahendusvariantide pakkumine, millega on võimalik küberintsidendi (sh olulise ebasoodsa mõjuga küberintsidendi) ärahoidmist maksimeerida. Lõikes 2 sätestatakse loetelu, millist teavet tuleb riskianalüüsis kajastada. Punkti 1 kohaselt tuleb riskianalüüsis lühidalt kirjeldada valitud metoodikat ning seda põhjendada. Eelnõu ei näe ette kindla riskianalüüsi metoodika järgimise kohustust, kuid soovitatav on lähtuda Riigi Infosüsteemi Ameti IT-riskianalüüsi koostamise juhendist3, mis põhineb rahvusvaheliselt tunnustatud standarditel. Lisaks metoodika valikule tuleb riskianalüüsis loetleda riskianalüüsiga seotud lisadokumendid, kui need on teenuse osutajal olemas. Metoodika kirjeldamine on vajalik teenuse osutajale ja välistele osapooltele, kellel on teadmisvajadus riskianalüüsiga tutvumiseks, et oleks selge ülevaade, millisest metoodikast ja nõuetest riskianalüüsi koostamisel on lähtutud. Organisatsioonisiseselt on see teadmine vajalik juhul, kui riskianalüüsi peab ühel hetkel ajakohastama inimene, kes varasemalt polnud riskianalüüsi koostamisse kaasatud ega teadlik, millistest nõuetest on selle koostamisel lähtutud. Kui riskianalüüsi koostamisel on aluseks võetud Riigi Infosüsteemi Ameti juhend 4, siis piisab selle nimetamisest ning metoodika täpsemat kirjeldust ei ole vaja lisada. Punkti 2 kohaselt peab teenuse osutaja analüüsima, milline on võrgu- ja infosüsteemide seos osutatava teenuse kriitiliste tegevustega. Teenuse osutaja peab välja selgitama need kriitilised tegevused, mis on vajalikud teenuse toimepidevuse tagamiseks, ning määratleb süsteemid, mis on vajalikud kriitiliste tegevuste toimimiseks. Kriitiline tegevus on tegevus, mille katkestus ohustab tõsiselt asutuse või ettevõtte võimekust teenust osutada ning takistab asutuse või ettevõtte sõnastatud eesmärkide saavutamist teenuse osutamisel. Kriitilise tegevuse legaalmõiste on avatud HOSi alusel siseministri määruse nr 29 „Elutähtsa teenuse toimepidevuse riskianalüüsi ja plaani, nende koostamise ning plaani kasutuselevõtmise nõuded ja kord“ § 2 lõikes 3, mis on samatähenduslik käesoleva määruse eelnõuga. Siseministri määrus kohaldub elutähtsa teenuse osutajatele teenuse toimepidevuse riskianalüüsi koostamisel ning neil ei tule kriitilisi tegevusi antud määruse eelnõu nõuete kontekstis teisiti käsitleda. 3 Kättesaadav: https://www.ria.ee/ee/kii-alusdokumendid.html 4 Samas. 2 Punkti 3 kohaselt tuleb teenuse osutajal loetleda võrgu- ja infosüsteemidega seotud ressursid ehk infovarad. Andmete töötlemise vahendid on näiteks arvutid, serverid, arvutivõrgud, andmesalvestusseadmed, varundamise seadmed jne. Andmete töötlemise vahendeid toetavad süsteemid ja rajatised (autonoomsed infovarad) on seadmeruumid, tehnilised hooned, varutoite seadmed ja süsteemid (elektrigeneraatorid, puhvertoiteallikad ehk UPSid), serveriruumi kliimaseadmed ning nende juhtimise ja monitoorimise seadmed. Infovarade all tuleb määruse tähenduses vaadelda ka seadmete kasutamisega seotud protseduure ja kehtestatud kordasid. Näiteks on serverite tõrgeteta töö tagamiseks vaja hoida serveriruumi temperatuuri ja õhuniiskust tootja etteantud piirides. Vastava monitooringusüsteemi rikke korral ei ole süsteemi haldajal ülevaadet antud näitajatest ja jahutussüsteemi rikke korral ei anna monitooring õigel ajal häiresignaali. Tulemuseks on katkestus serverite töös ülekuumenemise tõttu. Sellega võib omakorda kaasneda andmekadu, kuna serveri väljalülitumisel jäid mälus olevad andmed kettale kirjutamata. Sarnase tagajärjega on ka elektrisüsteemi katkestus, kus põhilise elektritoite katkemise korral rakendub küll varutoide UPSi näol, kuid UPSe toetav diiselgeneraator ei käivitu. Põhjuseks on diiselgeneraatori testprotseduuri teostamata jätmine. Lisaks elektrikatkestusest tingitud andmekaole võib intsident rikkuda ka serveri riistvara. Punkti 4 kohaselt loetletakse riskianalüüsis ohud, mis on teenuse osutaja vaatest olulised ja asjakohased ning võivad põhjustada küberintsidendi ja seeläbi seada ohtu süsteemi turvalisuse või teenuse toimepidevuse. Ohud võivad pärineda organisatsioonist endast või sellest väljastpoolt ning need võivad olla looduslikud või inimtekkelised (sh nii tahtlikud kui soovimatud). Kõik tuvastatud ohud seostatakse eelnevalt kaardistatud süsteemide ning nendega seotud ressurssidega. Riskianalüüsis tuleb ohtudena käsitleda vähemalt järgnevaid ohu liike ja küberintsidentide põhjustajaid: tarkvara viga, riistvara viga, seadme rike, inimlik eksimus (sh administreerimisviga ja kasutaja viga), küberrünne (sh pahavara, lunavara, teenusetõkestus), sabotaaž, süsteemile/andmetele autoriseerimata ligipääs, võrgukatkestus, elektrikatkestus. Füüsiliste ohtudena tuleb käsitleda füüsilist kahjustust (tuli, vesi jne) kui ka füüsilist rünnet. Lisaks tuleb riskianalüüsi koostamisel arvestada teenuse osutaja valdkonnale iseloomulike ohtudega. Kui see on asjakohane, siis tuleb ohu liikide seas arvestada ka usaldusteenuse katkestust. Ohte tuvastatakse vastavalt statistikale, uuringutele ja eksperthinnangutele. Lähteandmeid võib saada süsteemi omanikelt või kasutajatelt, hoone haldajailt, infoturbe spetsialistidelt, teistelt organisatsioonidelt, riigiasutustest jne. Kindlasti tuleks arvestada toimunud intsidentidest ja varasematest ohtude hindamistest saadud kogemust. Vajaduse korral tasub üldistatud ohtude loetelu täiendamiseks vaadata muid ohtude katalooge, mis võivad olla organisatsiooni- või erialaspetsiifilised. Tahtliku tegevusega (nt küberrünnetega) seotud ohtude kaardistamisel tuleb tähelepanu pöörata teo toimepanija profiili kindlaksmääramisele. Tuleb enda jaoks läbi mõelda, kes ja millistel põhjustel võib organisatsiooni süsteeme rünnata, mis oleks ründajale kõige tõenäolisem sihtmärk ja kui palju ründaja oleks valmis ründe õnnestumiseks ressursse kulutama ning milliseid riske võtma. Tõenäolisemaid ründestsenaariume teades on võimalik paremini planeerida kaitsemeetmeid ja kasutada ressursse nende varade kaitseks, mida kõige tõenäolisemalt rünnatakse. Punkti 5 kohaselt tuleb teenuse osutajal viia läbi süsteemi nõrkuste analüüs, mille eesmärk on tuvastada teenuse osutaja vaatest olulised ja asjakohased nõrkused, mille kaudu saavad realiseeruda süsteemidele, nendega seotud ressurssidele või organisatsioonile kahju põhjustavad ohud. Nõrkus on organisatsiooni varade nõrk koht, mida üks või mitu ohtu on võimelised ära kasutama. Nõrkused süsteemides, protseduurides, poliitikates ja 3 infrastruktuuris leitakse vaatluse ja dokumentidega tutvumise teel. Nõrkuste analüüsimisel on võimalik lähteteavet koguda erinevatest allikatest – näiteks intervjuudest süsteemi omanike ja kasutajatega, statistikast, turvatestimiste tulemustest, (tehnilistest) turvaaudititest, kuid ka dokumentatsiooni läbivaatusel, automaatsete skaneerimisvahendite kaudu, turvameetmete dokumentatsioonist, olemasolevast riskikäsitlusplaanist jne. Kõik nõrkused seostatakse eelnevalt kaardistatud süsteemide ning ohtudega. Riskianalüüsi läbiviimise hõlbustamiseks on loodud erinevaid ohtude ja võimalike nõrkuste katalooge5, mis varieeruvad väga üldistest loeteludest kuni spetsiifiliste ja detailsete tootepõhiste registriteni. Selliseid katalooge saab kohandada konkreetse organisatsiooni iseärasustele, välistades ebatõenäolised ohud või nõrkused ja lisades juurde uusi, organisatsiooni tegevuse ja varadega seotud ohte ja riske. Eesti tingimustes võib näiteks välistada vulkaanipurske kui äärmiselt ebatõenäoliselt esineva klimaatilise sündmuse tekitatud ohu. Võimalike riskide ja eriti uute, päevakajaliste infoturvariskide kohta saab infot erinevate organisatsioonide infoturbeteemaliste veebiportaalide ja viirustõrje vahendite tootjate kodulehtede kaudu6. Organisatsioonis kaardistatud riskid kajastavad tegelikult ainult sellel hetkel teadaolevat riskimaastikku. Praktikas on tegemist pidevalt muutuva keskkonnaga. Muudatused on tingitud tehnoloogia ja kasutatava tarkvara arengust, äsja avastatud turvanõrkustest, muutuvatest ärinõuetest, pilvetehnoloogia ja internetipõhiste teenuste laialdasest kasutuselevõtust ja kasutajate muutunud harjumustest. Kõige sellega peab riskide määratlemisel suutma kohaneda, lisades uusi ja ümber hinnates eelnevalt kaardistatud ohte ja nõrkuseid. On tõenäoline, et juba toimunud intsidendid võivad tulevikus korduda. Eriti kehtib see juhul, kui juurpõhjuste välja selgitamiseks ja olukorra parandamiseks ei ole midagi ette võetud. Nõrkuseid on võimalik liigitada ja grupeerida näiteks järgmiselt: • organisatsioonilised nõrkused; • personaliga seotud nõrkused; • infrastruktuuri nõrkused; • tehnoloogilised nõrkused. Punkti 6 kohaselt hinnatakse ohtude realiseerumise tõenäosust, arvestades tuvastatud nõrkusi ja rakendatud meetmeid. Kui ohu realiseerumise tõenäosus on erinevate süsteemide või nendega seotud ressursside puhul erinev, siis tuleb neid käsitleda eraldi ohustsenaariumitena. Tõenäosuse hinnangu andmisel tuleb arvesse võtta järgmist:  varasem kogemus ja statistika;  tahtlike ohuallikate puhul: võimalike ründajate motivatsioon ja võimekus;  stiihiliste ohuallikate puhul: geograafilised tegurid, nt äärmusliku ilma tõenäosus ja tegurid, mis võivad esile kutsuda inimlikke eksimusi ja seadmete tõrkeid; 5 Näiteks ISKE ohtude kataloog https://iske.ria.ee/8_01/ISKE_ohtude_kataloog, ISO 27005 Lisa C: Tüüpiliste ohtude näited. ISO 27005 Lisa D: Nõrkused ja nõrkuste hindamise meetodid, US-CCU küberturbe kontrollküsimustik https://www.ria.ee/public/KIIK/US_CCU_kontrollkusimustik_081211.pdf. 6 Vt nt ENISA Threat Landscape Report 2017, kättesaadav: https://www.enisa.europa.eu/publications/enisa- threat-landscape-report-2017 ja SANS Threat Landscape survey, kättesaadav: https://www.sans.org/reading- room/whitepapers/threats/2017-threat-landscape-survey-users-front-line-37910. Riigi Infosüsteemi Amet avaldab ohuteateid mh ameti kodulehe ja sotsiaalmeedia (https://www.ria.ee/ee/kuberturvalisuse-uudised.html ja https://twitter.com/cert_ee) kaudu. Lisaks pressiteadetele ja koostööparteritele saadetavatele info- ja uudiskirjadele on Riigi Infosüsteemi Ameti küberturvalisuse teenistuse töötajad ka kübekirjutiste blogisse https://blog.ria.ee/ postitanud infot uute avastatud nõrkuste kohta ja hoiatusi selliste pahavara levitamise kampaaniate kohta, mis võivad mõjutada Eesti riigiasutusi, ettevõtteid ja kodanikke. Näitena saab tuua tarkvara haavatavusi ning üldkasutatavate toodete, näiteks Wordpressi, Joomla, Drupali ja Sauruse tarkvaravead, mis on võimaldanud veebilehti rünnata. 4  nõrkuse iseloom;  olemasolevate turvameetmete efektiivsus. Tõenäosuse hinnangu andmisel selgitatakse välja olemasolevad katkestusi ennetavad ja tagajärgi leevendavad turvameetmed, mis on rakendatud, et minimeerida või vähendada ohu realiseerumise tõenäosust. Ennetavad ja avastavad meetmed on suunatud ohu realiseerumise vältimiseks, mida kasutatakse pidevalt selleks, et ohu realiseerumist tuvastada ning ohu realiseerumisel tekkinud situatsiooni defineerida ja täpsustada. Leevendavad meetmed on suunatud ohu realiseerumisel võimalike negatiivsete mõjude vähendamiseks või vältimiseks. Meetmete kaardistamisel tuleb erilist tähelepanu pöörata infotehnoloogilistele (tark- ja riistvaralised), füüsilistele (pääsuõigused, füüsiline turve) ja organisatsioonilistele (poliitikad, korrad) turvameetmetele. Vajalikud tegevused olemasolevate turvameetmete välja selgitamiseks:  vaadata läbi meetmete kohta teavet sisaldavad dokumendid;  küsida sisendit infoturbe eest vastutavalt töötajalt (samuti füüsilise turvalisuse tagamise eest vastutajailt), milliseid meetmeid konkreetsele infovarale tegelikult rakendatakse;  sooritada füüsiliste ja infotehnoloogiliste meetmete kohapealne läbivaatus;  vaadata läbi auditite tulemused. Teenuse osutaja defineerib ise tõenäosuse hindamise skaala ning esitab riskianalüüsis tõenäosuse hinnangu kriteeriumite selgitused. Näiteks kui kasutatakse viie palli skaalat (nt „väga suur“, „suur“, „keskmine“, „väike“, „väga väike“), siis kirjeldab teenuse osutaja, millistele tingimustele iga kriteerium vastab. Punkti 7 kohaselt tuleb riskianalüüsis anda hinnang ohtude realiseerumisel tekkida võiva küberintsidendi tagajärgedele ning määrata tagajärgede raskusaste. Tagajärgede raskusastme määramisel tuleb IT-riskianalüüsis kriteeriumitena arvesse võtta vähemalt küberintsidendist mõjutatud isikute (nii füüsilised kui juriidilised isikud) ligikaudset arvu, teenuse katkestuse kestust, küberintsidendi geograafilist ulatust, küberintsidendi tulemusena tekkida võiva kahju liiki ja määra (sh hinnanguliselt mõõdetavat) ning teenuse taastamise keerukust. Raskusastme skaala peab olema vähemalt neljaastmeline. Kui ohu realiseerumisel tekkida võivad tagajärjed on süsteemide või nendega seotud ressursside puhul erinevad, siis tuleb neid käsitleda riskianalüüsis eraldi ohustsenaariumitena. Kahju võib olla otsene või kaudne varaline kahju (sh ka saamata jäänud tulu) või mittevaraline (nt tervisekahjustus, mainekahju). Seda, kas on tegemist märkimisväärse kahjuga, tuleb hinnata proportsioonis teenuse osutaja tegevuse mahuga. Riskianalüüs peab sisaldama tagajärgede raskusastme määramise kriteeriumite selgitusi. Tagajärgede kaalukuse hindamisel on oluline meeles pidada, et negatiivsed tagajärjed ei tulene ainult sellest kui teenust ei saa mingil põhjusel osutada. Lisaks käideldavuse kaole tuleb arvestada ka kahjudega, mis tekivad teenusega seotud andmete konfidentsiaalsuse ja tervikluse rikkumisest. Teenuse osutaja defineerib tagajärgede raskusastme skaala ning esitab riskianalüüsis vastavate kriteeriumite selgitused. Näiteks kui kasutatakse viie palli skaalat (nt „katastroofiline“, „väga raske“, „raske“, „kerge“, „vähetähtis“), siis kirjeldab teenuse osutaja, millistele tingimustele iga kriteerium vastab. Punkti 8 kohaselt annab teenuse osutaja riskihinnangu ehk määratleb igale ohustsenaariumile riskiklassi ning sellega saab ohust risk. Riskiklass põhineb eelmistes punktides välja selgitatud ohu realiseerumise tõenäosusel ja tagajärgede raskusastme määrangul: „Riskiklass“ 5 = „Tagajärg“ × „Tõenäosus“. Riski saab vaadelda süsteemiga seotud ohu ning nõrkuse kombinatsioonina. Risk eksisteerib, kui mõlemad komponendid on esindatud. Teenuse osutaja defineerib riskiklassi skaala ning esitab riskianalüüsis vastavate riskiklasside selgitused. Näiteks kui kasutatakse viie palli skaalat (nt „väga kõrge risk“, „kõrge risk“, „keskmine risk“, „madal risk“, „väga madal risk“), siis kirjeldab teenuse osutaja, milles iga riskiklass seisneb. Riskianalüüsis otsustab teenuse osutaja riskidega tegelemise (riskikäsitluse) viisi ja meetodi vastavalt organisatsiooni riskitaluvusele ja valitud strateegiale. Riski käsitlemiseks on võimalik kasutada näiteks nelja erinevat võimalust: riski vältimine, riski vähendamine, riski jagamine ja riski aktsepteerimine. Teenuse osutaja määrab kindlaks kriteeriumid, millest lähtudes on võimalik kaaluda riskide aktsepteerimist, mille puhul täiendavaid turvameetmeid riski maandamiseks ei rakendata. Kuna kõikide riskide kõrvaldamine on üldjuhul ebapraktiline või isegi võimatu, siis on vajalik ohu realiseerumise mõju vähendamiseks planeerida ning rakendada sobivaimaid ja asjakohaseid maandamistegevusi (ennetavad ning tagajärgi leevendavad turvameetmed). Meetmete kirjeldamisel tuleb lähtuda riskiklassi prioriteetsusest ning valida turvameetmed vastavalt sellele, kui oluline on süsteem ja sellega seotud komponendid ning kui suured on nendega seotud riskid. Võib arvata, et esmajärjekorras tuleb tegeleda riskidega, mis on saanud endale kõige kõrgema prioriteedi. Praktikas tuleb arvestada ka sellega, et ühe riski avaldumine ja seotud intsidendid võivad endaga lumepalliefektina kaasa tuua ka teiste riskide avaldumise. Üheaegselt avaldunud riskid võivad kokkuvõttes tuua märksa olulisema kahju, kui nende kogukahjude summad kokku liites. Kõige lihtsamini kohaldatav meetod on riski vältimine. Organisatsioon kohandab oma siseseid protsesse ümber, et risk ei oleks enam päevakorras. Näiteks lõpetatakse organisatsioonis Windows XP tööjaamade kasutamine, sest toetuseta operatsioonisüsteemi kasutamine on seotud erinevate turvariskidega. Kui ettevõtte hooned asuvad üleujutusohtlikus piirkonnas, võib riski vältimiseks olla mõistlik ettevõtte kriitilised tegevused sealt ära kolida. Riski vähendamine toimub eelkõige turvameetmete ja organisatsioonis kontrollide rakendamise kaudu. Meede võib olla võetud kasutusele ühe või mõne konkreetse riskiga seotud ohu või nõrkuse vähendamiseks. Turvameetmete rakendamine organisatsioonis vajab ressursse, seega tuleb hoolega kaaluda, millised kulutused infoturbele on otstarbekad ja millised mitte. Teoreetiliselt on võimalik leida selline taluvuspunkt, millest suuremaid eeldatavaid kahjusid organisatsioon ei aktsepteeri. Iga taluvuspiiri ületava riski vähendamiseks tuleb rakendada meetmeid, mis toovad eeldatava kahju allapoole määratud taluvuspiiri. Riski jagamist käsitletakse kui kindlustusasutusest kindlustuse võtmist või väliste teenusepakkujate kasutamist. Kui välise teenusepakkuja juures midagi juhtub, siis on see teenuse pakkuja, mitte teenuse saaja risk. Riski jagamine ei võta organisatsioonilt andmete ja teiste varade kaitsemise kohustust ja vastutust oma klientide, omanike ja teiste seotud osapoolte ees. Kõikide riskide elimineerimine on paratamatult võimatu ning seega peab iga organisatsioon enese jaoks kehtestama taseme, millest alates ollakse nõus riskide aktsepteerimisega . Riskide aktsepteerimine on päevakorral kui täiendavate riskimaandamise meetmete rakendamine osutub majanduslikult või muudel põhjustel ebaotstarbekaks. Teistel puhkudel ei ole riski vähendamisega mõistlik tegeleda, kuna eeldatavad kahjud riski avaldumisel on nii väikesed, et ei põhjusta sellega organisatsioonile märgatavaid probleeme. Riski aktsepteerimine peab olema kalkuleeritud otsus ja seda ei tohi segamini ajada riski 6 ignoreerimisega. Aktsepteeritud riske tuleb perioodiliselt üle vaadata, sest muutuvas ärikeskkonnas võib riskitolerants ajas muutuda. Punkt 9 sätestab, et riskianalüüsis tuleb esitada turvameetmete rakendamise tegevuskava koos iga meetme rakendamise eest vastutava isiku ja meetme rakendamise tähtajaga. Lõige 3 sätestab teenuse osutaja kohustuse tagada pidev riskide seire ja riskianalüüsi uuendamine iga uue olulise riski ilmnemise järel. Riskide korrapärasel järelevaatusel tuleb üle vaadata varem kirjeldatud riskid ja vajadusel korrigeerida seniseid riskihinnanguid ning samuti täiendada kirjeldatud riske vastavalt uutele ohtudele, nõrkustele, sõltuvustele jne. Samuti võib olla vajalik kirjeldatud riske uuendada/täiendada, kui ilmnevad uued kriitilised asjaolud või realiseeruvad olulise mõjuga intsidendid. Riskid ei ole kunagi staatilised. Ohud, nõrkused, ohu realiseerumise tõenäosus ja tagajärjed on dünaamilised ja võivad kiiresti muutuda, seda eriti IT-valdkonnas. Seetõttu on muutuste avastamiseks vajalik tagada pidev seire. Riskide hindamine peab kaasnema iga olulise muudatusega süsteemides või protsessides. Süsteemi muutuste planeerimisel tuleb kindlaks teha, kas ja kuidas muudatus süsteemi ja protsessi turvalisust mõjutab, ning vähendada igakülgselt muudatusega kaasnevate riskide mõju. Riskide seire peab hõlmama järgnevat:  lisandunud süsteemid ja nendega seotud komponendid ning ressursid;  uued ohud, mida pole varem hinnatud;  uued või suurenenud turvanõrkused, mille kaudu ohud realiseeruda saavad;  varem tuvastatud nõrkused, mis on avatud uutele või taas ilmnenud ohtudele;  ohtude, nõrkuste ja riskide suurenenud toime, mis tekitab vastuvõetamatu riskitaseme;  küberintsidendid;  kõik riskid tuleb üle hinnata ning riskiklass uuesti määrata (st välja selgitada, kas riski komponendid on ajas muutunud). Teenuse osutaja peab kindlustama, et riskianalüüsi tulemused ja riskikäsitlusplaanid oleksid asja- ja ka ajakohased. Tuleb silmas pidada seda, et uuendamise nõue ei tähenda, et teenuse osutajal tuleb koostada uus riskianalüüs. Kuivõrd riskide hindamine on dünaamiline ja pidev tegevus, siis tuleb riskianalüüsi uuendada vajadusel ning üksnes muutunud osas. Eelnõu § 3 lõige 1 sätestab, milliseid infoturbe nõuete kogumeid tuleb turvameetmete valikul ja rakendamisel järgida. Infoturbe korraldamisel on mõistlik esmalt tutvuda parimate rahvusvaheliselt tunnustatud praktikatega, mille hea näide on ISO/IEC 27000 standardite sari, kuid lähtuda võib ka konkreetses tegevusvaldkonnas kehtestatud nõuetest.7 Kui teenuse osutajale ei ole infoturbealaseid nõudeid kehtestatud, on soovitatav lähtuda EVS-ISO/IEC 27000 seeria infoturbe standardist või ISKE-st, kuid seejuures tuleb arvestada, et ISO 27000 seeria standardi soetamine on tasuline, ISKE kasutamine seevastu on tasuta ning kättesaadav veebist: https://iske.ria.ee/8_02. 7 Näiteks kohalduvad krediidiasutustele finantssektori regulatsioonid ning juhendid. Infoturbe korralduse osas on Finantsinspektsioon andnud 23.01.2017 välja soovitusliku juhendi „Nõuded finantsjärelevalve subjekti infotehnoloogia ja infoturbe korraldusele“, kättesaadav: https://www.fi.ee/public/20170123_Soovituslik_juhend_IT_ja_infoturbe_korraldusele.pdf 7 Lõige 2 sätestab, et organisatsioonilised, infotehnilised ja füüsilised turvameetmed peavad hõlmama protseduure, ressursse ja tegevusi, küberintsidentide lahendamise korraldust ning personali tööülesandeid ja vastutust. Teisisõnu kirjutab säte ette nõude rakendada turvameetmeid terviklikult ja süsteemselt, mis teisisõnu tähendab, et teenuse osutajal peavad olema kehtestatud vajalikud mehhanismid organisatsiooni küberturvalisuse tagamist toetavate protseduuride osas (ka käitumisreeglid küberintsidentide lahendamiseks). Organisatsioonilised, infotehnilised ja füüsilised turvameetmed on osa organisatsiooni üldisest juhtimissüsteemist ning koosnevad poliitikatest, protseduuridest, juhistest ning nendega seotud ressurssidest ja tegevustest, mida organisatsioon kollektiivselt haldab, eesmärgiga tagada infovarade kaitse. Turvameetmete valik peab tagama organisatsiooni infovarade kaitse ja huvipooltes usalduse. Rakendamisele kuuluvate turvameetmete valikul tuleb arvestada osutatavate teenus(t)e spetsiifikaga ja oluliste riskidega, mis selgitatakse välja meetmete valikule eelneva riskide hindamise käigus. Turvameetmete kataloog sisaldab meetmeid kolmest järgmisest blokist:  planeerimine – sisaldab meetmeid infoturbe käsitusala määramiseks ja infoturbe juhtimise süsteemi loomiseks ning käigus hoidmiseks;  kaitsmine – sisaldab meetmeid küberintsidentide ennetamiseks (ja küberintsidentide avastamiseks) võimalikele ründajatele raskesti ligipääsetavaks muutmise teel. Kaitsemeetmete eesmärgiks peab olema andmelekete ja küberintsidentide aset leidmise tõenäosuse vähendamine;  taastamine – sisaldab meetmeid küberintsidentide lahendamiseks ja normaalse töökeskkonna taastamiseks. Taastemeetmete eesmärk on vähendada küberintsidentide tagajärjel tekkivat potentsiaalset kahju. Punkti 1 kohaselt peavad turvameetmed hõlmama protseduure, ressursse, tegevusi ja küberintsidentide lahendamise korda. Protseduurid koosnevad erinevatest tegevustest. Ressursiks, mida turvameetmed peavad hõlmama, saab lugeda näiteks teenuse osutamise infrastruktuuri kuuluvaid tehnilisi vahendeid ja riistvara, rakendusi ja tarkvara, mille abil teenust osutatakse, aga ka personali. Korras tuleb ette näha käitumisreeglid ja tegevused küberintsidentide haldamiseks8 (ka küberintsidendist teavitamiseks). Tegevusreeglistik, mille loomisel võib kasutada Riigi Infosüsteemi Ameti veebis avaldatud näidisdokumenti „Tuvaintsidentide käsitlemise kord“ (kättesaadav: https://www.ria.ee/ee/raamdokumentide- naidised.html), peab muu hulgas arvestama intsidendi võimaliku eskaleerumisega. Punkti 2 kohaselt peavad turvameetmed hõlmama personali tööülesandeid ja vastutust. Üldine vastutus ettevõttes turvameetmete rakendamise eest on ettevõtte juhtkonnal, kes peab veenduma, et ettevõttes toimib efektiivne infoturbe juhtimise süsteem9, mille rakendamisel infoturbe riske ning juurutatud kaitsemeetmeid perioodiliselt hinnatakse. Protseduurid ja tegevused ning personali infoturbe tagamisega seotud töökorraldus peavad olema kinnitatud ettevõtte juhtkonna poolt. Eelnõu § 4 lõikes 1 loetletakse minimaalsed ehk mitteammendavad turvameetmed, mida teenuse osutaja peab võrgu- ja infosüsteemide turvalisuse tagamiseks rakendama. Olenevalt osutatava teenuse spetsiifikast, kuid ka teenuse osutaja küpsustasemest lisandub kindlasti veel turvameetmeid, mida süsteemi turvalisuse ja teenuse toimepidevuse tagamiseks tuleb 8 Intsidentide haldus hõlmab protsesse intsidentide avastamiseks, neist teatamiseks, nende hindamiseks, neile reageerimiseks, nende käsitluseks ja neist õppimiseks (ISO/IEC 27000). 9 Vt lähemalt „Juhised infoturbe halduse süsteemi loomiseks.“ Mai 2017. Kättesaadav: https://www.ria.ee/public/KIIK/Juhised_infoturbe_halduse_susteemi_loomiseks.pdf. 8 rakendada, mistõttu eelnõuga konkreetsemaid ja ammendavaid suuniseid küberturvalisuse korraldamiseks (nt seireks, konfiguratsioonihalduseks jne) ette ei anta. Rakendamisele kuuluvate turvameetmete valikul tuleb arvestada osutatavate teenus(t)e spetsiifikaga ja oluliste riskidega, mis selgitatakse välja meetmete valikule eelneva riskide hindamise käigus. Punktis 1 sätestatakse, et teenuse osutaja peab ette nägema turvameetmed süsteemi juurdepääsuõiguste haldamiseks ning süsteemi kasutajate identifitseerimiseks ja autoriseemiseks. Juurdepääsuõiguste haldamisel määratletakse süsteemi juurdepääsukohad (seda nii lokaalsel tasemel – töökoha arvutile, operatsioonisüsteemile kui ka terve andmeside võrgu ulatuses – sisevõrgule, rakendustele, internetile), aga ka turvameetmed kasutajate identifitseerimise kaitseks (kasutajatunnuse ja paroolide keerukus ja kehtivusaeg ning mitmetasandiline identifitseerimine). Punkti 2 kohaselt tuleb tagada andmetest varukoopiate tegemine. Kuivõrd teenuse osutamiseks olulised andmed (näiteks isikuandmed, oskusteave, dokumentatsioon, andmebaasid, rakenduste failid, süsteemide konfiguratsioon, logid) eksisteerivad ainult digitaalselt, siis on eluliselt kriitiline tagada nende säilimine, et oleks võimalik pärast küberintsidendi toimumist teenuse osutamine ja süsteemi tavapärane töörežiim tõrgeteta taastada selleks ettenähtud aja jooksul. Varukoopiate tegemise protseduur peaks käsitlema varukoopiate tegemise ulatust ja sagedust, varukoopiate säilitamise aega, kuid kindlasti tuleb seejuures testida ka andmete taastamist. Varukoopiate säilitamine tuleks korraldada viisil ja asukohas, mis välistab varukoopiatele volitamata juurdepääsu. Eelnõuga ei sätestata varukoopiate tegemisele ega säilitamisele üksikasjalikumaid nõudeid lahenduste varieeruvuse tõttu. Näiteks kaugvarunduse (remote backup) puhul toimub andmete varukopeerimine võrgu kaudu asukohta, mis võib kuuluda andmete omanikule või varundusteenuse pakkujale. Varundamise dokumentatsiooni loomisel on soovitatav tutvuda Riigi Infosüsteemi Ameti veebis IT-halduse raamdokumentide rubriigis vastavate näidisdokumentidega10. Punkti 3 kohaselt tuleb turvameetmete rakendamisega tagada süsteemi käitava ja süsteemis käideldava tarkvara ajakohasus. Tarkvara (ka viirustõrje tarkvara) ajakohasuse hoidmisele suunatud muudatuste haldamiseks tuleb ette näha paigahaldus (Patch Management), et operatsioonisüsteemide ja tarkvara uuendamiseks vajalikud paigad11 oleks õigeaegselt alla laetud ja paigaldatud. Seetõttu tuleb tarkvara terviklust ka regulaarselt kontrollida ja olla avastatud turvaaukudega aegsasti kursis, et paigad võimalikult operatiivselt installeerida. Punkt 4 sätestab nõude logide pidamisele, mis tagab süsteemis läbiviidavatest toimingutest ülevaate omamise, et tuvastada süsteemide toimimises häireid või võimalikke käideldavuse, tervikluse või konfidentsiaalsuse rikkumisi. Logid peavad kätkema infot süsteemi sisenemise, info vaatamise ja päringute tegemise toimingutest (sh ka autoriseerimata toimingutest) – seda nii süsteemi kasutajate tehtud toimingutest kui ka süsteemis käideldavate riist- ja tarkvaraliste rakenduste tehtud toimingutest. Kriitilisi logifaile on soovitatav kaitsta signeeritud või räsitud ajatempliga12. Logihalduse korraldamise puhul on oluline tagada erinevates serverites logitud andmete ajaline ühtsus ehk teisisõnu peavad serverite kellaajad olema vastu ajaserverit sünkroniseeritud. Sellest tulenevalt peaks sisevõrku olema sisse seatud server, mis varustab 10 Kättesaadav: https://www.ria.ee/ee/raamdokumentide-naidised.html ning https://www.ria.ee/public/ISKE/naidisdokumendid/LISA1.07.Varundamise_ja_arhiveerimise_kord.doc 11 Tarkvaratoote suhteliselt väikeseks muutmiseks, näiteks programmivea või nõrkuse kõrvaldamiseks määratud koodi- ja/või andmekogum, mille väljastab enamasti selle tarkvara väljatöötaja oma toote hoolduse raames ja mis installeeritakse automatiseeritult (Andmekaitse ja infoturbe leksikon, https://akit.cyber.ee/term/1019- paik#t_1019). 12 Sellist teenust pakuvad näiteks SK ID Solutions AS ja Guardtime. 9 kõiki süsteeme õige süsteemiajaga. See võib toimuda näiteks Network Time Protocol ehk NTP-teenusel. Lisaks tuleks kaaluda sisevõrku eraldi ajaserveri paigutamist. Punkt 5 sätestab nõude võtta kasutusele tarkvaralised ja riistvaralised automatiseeritud lahendused süsteemi turvalisust ohustava tegevuse ja tarkavara tuvastamiseks. Teisisõnu tähendab see kohustust rakendada turvameetmeid nii süsteemi välise perimeetri kaitseks (näiteks tulemüüri kasutamine võrguliikluse kaitsmiseks) kui ka süsteemis sisalduvate andmete terviklikkuse ja käideldavuse kaitseks (näiteks viirustõrje tarkvara kasutamine, e-posti liikluse filtreerimine). Üks lahendus selleks on sissetungi tuvastamise süsteem (Intrusion-Detection System ehk IDS), mis analüüsib võrgu kaudu liikuvat andmevahetust ja on võimeline ründeid tuvastama ning suudab edastada hoiatusi. Selleks rakendatavad analüüsitehnikad jagunevad kategooriatesse „väärkasutus“ (Misuse) ja „anomaaliate tuvastamine“ (Anomaly Detection). Misuse Detection analüüsitehnika püüab tuvastada teadolevaid ründemustreid. Anomaly Detection lähtub seevastu põhimõttest koguda infot lubatud käitumismustrite kohta ja tuvastada nende kõrvalekaldumised rünnetena. Sissetungi tõrje süsteem (Intrusion Prevention System ehk IPS) analüüsib kõiki sissetulevaid võrgupakette ning on suuteline algatama ka asjakohaseid vastureaktsioone, mis võivad seisneda näiteks ühenduse blokeerimises. Punkt 6 sätestab kohustuse rakendada turvameetmeid, mis aitavad taastada olulise teenuse osutamiseks vajalike süsteemide töö küberintsidendi lahendamise järel. Lõige 2 täpsustab turvameetmete rakendamise kohustust nõudega, et turvameetmeid tuleb rakendada sel määral, mis vastaks süsteemi käideldavus-, konfidentsiaalsus- ja terviklusnõuetele ning tagaks riskianalüüsis kirjeldatud riskide haldamise. Turvameetmete rakendamise piisavust tuleb pidevalt seirata ning kontrolli tulemused peavad olema ajakohased kogu võrgu- ja infosüsteemi elutsükli vältel. Ajakohasus tähendab, et elutsükli vältel süsteemis läbiviidud muudatuste korral või uute turvaohtude ilmnemisel tuleb asjakohaseid süsteemi turvemeetmeid kontrollida vahetult muudatuse rakendamise järel, seejuures tuleb teenuse osutajal KüTSi § 7 lõike 2 punkti 2 kohaselt turvameetmete rakendamise kontrolli tulemused ka dokumenteerida. Eelnõu § 5 sätestab määruse nõuete täitmiseks riskianalüüsi osas üleminekuaja. Vabariigi Valitsuse 03.08.2017 määrus nr 133 „Elutähtsa teenuse infosüsteemide ning nendega seotud infovarade turvameetmed“, mis kohaldub KüTSi eelnõu § 3 lõike 1 punktides 1–6 ja 9 loetletud elutähtsat ja muud olulist üldhuviteenust osutavatele juriidilistele isikutele, näeb ette, et riskianalüüs tuleb koostada 1. juuliks 2018 (§ 6). Ehkki käesolev eelnõu näeb võrreldes viidatud määrusega riskianalüüsi sisule ette üksikasjalikumad nõuded, pole need olemuslikult siiski täiesti uued. Seepärast on seni koostatud riskianalüüside vastavusse viimiseks eelnõuga ette nähtud üleminekuajaks 6 kuud. Riskianalüüsi tuleb eelnõu kohaselt uuendada iga uue olulise riski ilmnemise järel või vähemalt üks kord kahe aasta jooksul. Nimetatud 2-aastane välp on sama, mis on kehtestatud elutähtsa teenuse osutajatele siseministri määruse nr 29 „Elutähtsa teenuse toimepidevuse riskianalüüsi ja plaani, nende koostamise ning plaani kasutuselevõtmise nõuded ja kord“ (RT I, 28.06.2017, 6) § 4 lõikes 1 HOSi alusel koostatud elutähtsa teenuse toimepidevuse riskianalüüsi ja plaani uuendamisele. Edaspidi võivad elutähtsat teenust osutavad ettevõtted riskianalüüsi uuendada HOSi alusel koostatud elutähtsa teenuse toimepidevuse riskianalüüsi ja plaaniga samal ajal ehk vähemalt kord kahe aasta jooksul. 3. Eelnõu vastavus Euroopa Liidu õigusele 10 Määruse eelnõus kehtestatud nõuded täpsustavad teenuse osutajale KüTSi § 7 lõigetes 1 ja 2 sätestatud kohustusi riskianalüüsi koostamisel ja turvameetmete rakendamisel, mis vastavad direktiivi (EL) nr 2016/1148 artikli 14 lõigetele 1 ja 2. 4. Määruse mõjud Sotsiaalne, sealhulgas demograafiline mõju Määruse kehtestamisega ei kaasne otseseid sotsiaalseid ega demograafilisi mõjusid. Mõju riigi julgeolekule ja välissuhetele Määruse kehtestamisega ei kaasne otseseid mõjusid riigi julgeolekule ja välissuhetele. Majanduslik mõju Määruse kehtestamisega ei kaasne majanduslikke mõjusid. Määrusel puudub mõju elu- ja looduskeskkonnale, regionaalarengule, riigiasutuste ja kohaliku omavalitsuse korraldusele ning muud otsesed ja kaudsed mõjud. 5. Määruse rakendamisega seotud tegevused, vajalikud kulud ja määruse rakendamise eeldatavad tulud Enamik KüTSi kohaldamisalas olevaid teenuse osutajaid on pidanud teenuse osutamisega seotud süsteemide elektroonilist turvalisust tagama alates 2013. aastast (HOSi vana redaktsiooni § 40 lõike 2 alusel Vabariigi Valitsuse välja antud määruse alusel) ning samasisuline kohustus (riskianalüüsi läbiviimise ning turvameetmete rakendamise osas) on sätestatud ka kehtiva HOSi § 41 lõike 3 alusel antud määruses ning seega ei ole määruse rakendamisega seonduvalt KüTSi § 3 lõike 1 punktides 1–6 ja 9 nimetatud teenuse osutajatele määruse eelnõus sätestatud kohustuste täitmiseks täiendavate tegevuste läbiviimine vajalik. Käesoleva eelnõuga täpsustatakse nõudeid üksnes selles osas, millele tuleb IT-riskianalüüsi läbiviimisel tähelepanu pöörata. Teiseks täpsustatakse määrusega vähimaid turvameetmeid, mis sisalduvad kõikides infoturbe standardites. Seega ei saa määruse nõuete täitmine tingida enamikule KüTSi kohaldamisalasse jäävatele ettevõtetele kulude suurenemist. 6. Eelnõu kooskõlastamine Riigi Infosüsteemi Amet küsis määruse eelnõu ettevalmistamisel selle tööversioonidele arvamust KüTSi eelnõu kohaldamisalasse jäävatelt ettevõtetelt ning saadud märkusi arvestati eelnõu väljatöötamisel. Eelnõu esitatakse kooskõlastamiseks eelnõude infosüsteemi EIS kaudu kõikidele ministeeriumitele ning arvamuse avaldamiseks Eesti Infotehnoloogia ja Telekommunikatsiooni Liidule, Eesti Haiglate Liidule, Eesti Vee-ettevõtete Liidule, Eesti Pangaliidule, Eesti Kiirabi Liidule, Eesti Jõujaamade ja Kaugkütte Ühingule, Eesti Elektritööstuse Liidule, Eesti Gaasiliidule, Eesti Õliühingule, Eesti Asfaldiliidule, Eesti Perearstide Seltsile, Eesti Interneti SA-le. Eesti Rahvusringhäälingule ja Riigi Infokommunikatsiooni SA-le, Eesti Maaomavalitsuste Liidule ja Eesti Linnade ja Valdade Liidule. 7. Määruse jõustumine Määrus jõustub üldises korras ehk kolmandal päeval pärast Riigi Teatajas avaldamist. 11