E-ITS rakendamine: millest väiksem organisatsioon alustama peaks?

1. Kõigepealt kontrolli, milline nõue organisatsioonile tegelikult kohaldub

E-ITS-i, esmaste turvameetmete, valdkondliku määruse või lepingulise nõude kohaldumine sõltub organisatsiooni rollist ja teenustest. Kõik ettevõtted ei pea läbima samas mahus protsessi ega tellima ametlikku auditit.

Alustada tasub kohaldumise kirjalikust selgitusest: millise õigusakti, järelevalvenõude, omanikuotsuse või kliendilepingu alusel infoturbe meetmeid rakendatakse. Kui kohaldumine on ebaselge, tuleb see enne suure töö tellimist pädeva õigus- või järelevalveallikaga kinnitada.

2. Infoturve vajab juhtkonna otsust, mitte ainult IT-spetsialisti

IT-spetsialist saab kirjeldada nõrkusi ja tehnilisi lahendusi, kuid juhtkond otsustab, milline katkestus, andmekadu või mainekahju on organisatsioonile vastuvõetav. Juhtkond määrab käsitlusala, rollid, ressursid ja riskide aktsepteerimise põhimõtted.

Praktiline algusotsus võiks määrata:

• infoturbe eest vastutava rolli;
• protsesside ja üksuste juhid, kellelt kogutakse sisendit;
• käsitlusala ja esialgse ajakava;
• otsuste kinnitamise korra;
• kuidas dokumenteeritakse erandid ja jääkriskid.

Väikese organisatsiooni vastutav isik ei pea olema täiskohaga infoturbejuht. Oluline on, et roll ei jääks nimeliseks ning inimesel oleks ligipääs juhtkonnale ja vajalikule infole.

3. Kaardista äriprotsessid, käsitlusala ja kaitsetarve

Infoturvet ei rakendata lihtsalt „arvutitele”. Kaitstakse organisatsiooni võimet osutada teenust: patsiendi vastuvõtt, arvete koostamine, klientide teenindamine, dokumentide säilitamine või tootmise juhtimine.

Iga olulise protsessi juures tuleb küsida:

• milliseid andmeid ja süsteeme protsess vajab;
• mis juhtub, kui andmed lekivad;
• mis juhtub, kui andmeid muudetakse või need muutuvad ebausaldusväärseks;
• kui kaua saab süsteem või teenus olla kättesaamatu;
• millised partnerid ja pilveteenused on protsessist sõltuvad.

Nende vastuste põhjal kujuneb kaitsetarve ja käsitlusala. Liiga lai käsitlusala tekitab haldamatu projekti; liiga kitsas ala jätab kriitilised sõltuvused välja.

4. Loo vararegister, mida on võimalik päriselt ajakohasena hoida

Vararegister ei tähenda ainult sülearvutite seerianumbreid. Registris peaksid olema protsesside toimimiseks olulised infovarad, rakendused, pilveteenused, seadmed, võrgud, füüsilised asukohad, partnerid ja vastutajad.

Väiksema organisatsiooni vararegister võib alata tabelist, kus iga vara kohta on vähemalt:

• vara või teenuse nimetus;
• omanik või vastutaja;
• seos äriprotsessiga;
• asukoht või teenusepakkuja;
• olulisus ja kaitsetarve;
• peamised sõltuvused;
• elutsükli või ülevaatuse kuupäev.

Registrit tuleb siduda päris tööprotsessidega. Kui uus pilveteenus võetakse kasutusele ilma registrit ja ligipääsude nimekirja täiendamata, vananeb dokumentatsioon kiiresti.

5. Meetmete rakendusplaan muudab standardi tegevusteks

Meetmete rakendusplaan ei peaks olema lihtsalt koopia standardi tekstist. Iga meetme juures peab olema selge, kas see on rakendatud, osaliselt rakendatud, plaanitud või põhjendatult mittekohalduv.

RIA rakendusjuhendi järgi tuleb plaanis kajastada muu hulgas meetme identifikaatorit ja nimetust, rakendatuse seisu, selgitust, vastutajat ning tähtaega. Kui meedet ei rakendata, peab organisatsioon põhjendama mittekohaldamist või aktsepteerima jääkriski.

Hea rakendusplaan vastab küsimusele „kes teeb mida ja mis ajaks?”. Näiteks „rakendada mitmikautentimine” on liiga üldine. Parem tegevus kirjeldab sihtgruppi, keskkonda, vastutajat, sõltuvusi ja valmiskriteeriumi.

6. Riskianalüüs aitab otsustada, mida teha esimesena

Riskianalüüsi eesmärk ei ole genereerida võimalikult palju punaseid lahtreid. See aitab siduda ohu, nõrkuse, võimaliku tagajärje ja otsustatava meetme.

Praktilises töötoas võib iga olulise riski kohta kirjeldada:

1. milline sündmus võib juhtuda;
2. milline nõrkus selle võimalikuks teeb;
3. milline protsess või vara saab kahjustada;
4. kui tõenäoline ja raske tagajärg on;
5. kas riski välditakse, vähendatakse, antakse üle või aktsepteeritakse;
6. kes vastutab meetme ja jääkriski eest.

Riskihinnang peab olema korratav. Kui hinnang põhineb ainult ühe inimese tunnetusel ja skaala tähendus pole kirjas, ei saa juhtkond hiljem otsuseid võrrelda.

7. Dokumentatsioon ja koolitus peavad kirjeldama tegelikku töökorraldust

Infoturvapoliitika, kasutusreeglid, intsidendi käsitlemise kord, varunduse kord ja ligipääsude haldus ei tohi olla üldised mallid, mis ei vasta organisatsiooni süsteemidele.

Dokumentide kõrval on vaja töötajate juhendamist. Koolitus peab käsitlema nende päris olukordi: patsiendi või kliendi andmete saatmine, kahtlane e-kiri, tundmatu USB-seade, kaugtöö, ekraani lukustamine ja intsidendist teatamine. Ühekordne slaidikoolitus ei asenda juhtide eeskuju ja korduvaid meeldetuletusi.

8. Rakendamine ei lõpe kontrolliks dokumentide esitamisega

Infoturbe meetmed vajavad käigushoidu. Kasutajad vahetuvad, pilveteenused lisanduvad, seadmed vananevad ja ohuolukord muutub. Seetõttu tuleb määrata, mida mõõdetakse ja kui sageli üle vaadatakse.

Väiksema organisatsiooni seire võib hõlmata näiteks:

• lahkunud kasutajate kontode kontrolli;
• mitmikautentimise katvust;
• varundustööde ja taastetestide tulemusi;
• uuendamata seadmete või tarkvara arvu;
• intsidentide ja õppimiskohtade kokkuvõtet;
• meetmete rakendusplaani tähtaegu;
• juhtkonna perioodilist ülevaadet.

Vajadusel järgneb sõltumatu hindamine või ametlik audit, kuid rakendamise nõustaja ei tohiks esitleda enda tehtud kontrolli sõltumatu auditina.

9. Tüüpilised vead E-ITS-i rakendamisel

Prevent IT on aidanud ligikaudu kümnel organisatsioonil kaardistada varasid ja protsesse, koostada riskianalüüse, rakendusplaane ja dokumentatsiooni ning koolitada töötajaid. Vaata infoturbe ja E-ITS teenuse sisu.