Detailne juhend: Kuidas luua E-ITS varade ja teenusepakkujate register

Eelmises postituses rääkisime sellest, kuidas äriprotsesside kaardistamine aitab aru saada, mida organisatsioon tegelikult teeb. Nüüd, kui me teame mida me teeme, on aeg küsida järgmine kriitiline küsimus: millega me seda teeme?

Siin tulevadki mängu vara- ja teenusepakkujate registrid. Sa ei saa kaitsta seda, mille olemasolust sa ei tea.

Selles postituses räägime praktiliste näidetega, kuidas infoturbe raamistiku nagu E-ITS või ISO 27001 rakendamisel varasid ja teenusepakkujaid kaardistada.

Mis on “vara” E-ITS kontekstis?

Ametlik E-ITS rakendusjuhend defineerib seda nii:

Vara (asset) – miski, millel on organisatsiooni jaoks väärtus (mõnes kontekstis ka isiku või riigi jaoks); näiteks teave, andmed, tarkvara, füüsiline vara, rahaline vara, teenus, inimressurss, oskusteave, mitteaineline vara (maine, kuvand jms).

Näiteks ühe kooli kontekstis võivad varad olla:

• Teave ja andmed: Õpilaste nimekirjad, hinnetelehed, töötajate isikuandmed.
• Tarkvara: eKool/Stuudium, raamatupidamistarkvara, Microsoft 365.
• Füüsiline vara: Sülearvutid, serveriruum, wifi-ruuterid, koolimaja ise.
• Inimressurss: Õpetajad ja nende oskused.
• Mitteaineline vara: Kooli maine ja usaldusväärsus.

Miks on oluline kaardistada eri tüüpi varasid?

Kui kooli serveriruumis juhtub veeavarii, on see mure füüsilise varaga. Aga selle tagajärjel võivad kaduda andmed (hinnetelehed) või katkeda teenus (õppetöö). Infoturbe eesmärk on kaitsta väärtust, mitte ainult “rauda”.

E-ITS rakendamisel on meil vaja varasid ja varagruppe, et määratleda sihtobjektid. Just sihtobjekt on see “ühik”, mille põhjal me valime hiljem etalonturbe kataloogist sobivad etalonmeetmete moodulid (ehk standardsed kaitsetegevused). Kui me ei tea, mis on meie sihtobjekt, ei saa me valida ka õigeid kaitsemeetmeid.

Kes vararegistri looma peaks?

Tihti eeldatakse ekslikult, et kõik, mis puudutab infoturvet, on automaatselt IT-osakonna mure. See ei ole kindlasti nii. Infoturve on kogu organisatsiooni vastutus.

Infoturbejuht (või seda rolli täitev töötaja) on selles protsessis suunaja ja eestvedaja, mitte ainuisikuline täitja. IT-juht või E-ITS rakendamise töögrupi juht ei pruugi teada, millist spetsiifilist pilveteenust kasutab personaliosakond värbamiseks või milline paberkaust on sotsiaaltöötaja jaoks kriitilise tähtsusega.

Seetõttu on ka varade ja teenusepakkujate kaardistamine meeskonnatöö, kus sisuline vastutus lasub äriprotsesside omanikel. Nemad teavad kõige paremini, mis on nende tööks vajalik – infoturbejuhi rolli täitva inimese ülesanne on aidata see info süsteemselt ja õigesse vormi kirja panna.

Kuidas vararegistrit luua?

1. Võta aluseks olemasolevad andmed

Nii-öelda õpiku järgi looksid vararegistri nullist: mõtled läbi iga äriprotsessi ning dokumenteerid täpselt, millistest varadest ja teenuspakkujatest see sõltub. Reaalses elus on aga alati lihtsam alustada olemasoleva info süstematiseerimise ja täiendamisega, kui alustada tühjalt lehelt.

Sinu organisatsioonis on tõenäoliselt juba olemas andmestikud, mida saad aluseks võtta:

• Raamatupidamise põhivara nimekiri.
• IT-osakonna seadmete nimekiri.
• Tarkvaralitsentside lepingud.
• Töötajate nimekiri.
• Regulaarsed maksed teenuste ja tarkvara eest finantsosakonnas.

Nendest olemasolevatest nimekirjadest saadki kombineerida esialgse vararegistri.

Kus vararegistrit pidada?

Kõige lihtsam on vararegistrit luua tabelarvutusprogrammis – Excelis või Google Spreadsheetis. Tabelarvutusprogramm annab hiljem mugava võimaluse andmeid erinevate parameetrite järgi filtreerida, sorteerida.

Esialgu tasub hoida info (tulbad) iga vara kohta minimaalsed. Alati saab hiljem täiendada, sest töö käigus saab selgemini pildi ette, mida ehk konkreetses organisatsioonis iga vara kohta veel on mõtet dokumenteerida.

Vihje: Excel on hea koht alustamiseks, kuid varade, äriprotsesside ja riskide vaheliste seoste (“mitu-mitmele”) haldamiseks jääb see kiirelt kitsaks. Spetsiaalsed tööriistad (nagu Kordon) aitavad neid seoseid visuaalselt hoida, tagades, et muudatus ühes kohas (nt vara kadumine) kajastub automaatselt ka seotud protsesside riskitasemes.

Mis andmed vararegistris iga vara kohta olema peavad?

Ma toon siin esmalt välja väljad, mida soovitab E-ITS ametlik juhend ning mõningad, mis ma oma kogemusest arvan, et tulevad pikas perspektiivis kasuks. Neid välju on tegelikult päris palju ja eeldatavasti registriloomise algusfaasis kõigi varade kohta kogu infot veel ei ole. See on okei, pigem pane igal sammul nii palju infot kirja kui olemas, ja siis hiljem saab jooksvalt täiendada.

Ametlik juhend soovitab registrisse märkida vähemalt järgmised andmed:

• Vara nimetus: nt “Õpetajate sülearvutid”.
• Unikaalne tunnus: Grupi puhul grupi nimi, üksiku serveri puhul seerianumber või nimi.
• Vastutaja: Kes vastutab selle vara eest? (nt müügijuht, õppealajuhataja).
• Seosed: Kuidas on see vara seotud teiste varadega? (nt “Sisseastumiste süsteem” asub serveris “SRV-01”).

Enda kogemusest soovitaksin lisaks järgnevaid välju:

• Äriprotsessid: Äriprotsess(id), milles see vara või teenusepakkuja osaleb.

Selliste seoste loomine on pikas perspektiivis väga oluline, sest hiljem infoturbe juhtimisüsteemi käitades annab see igapäevastele tegevustele ja kahjuks ka intsidentidele konteksti – mis juhtus, miks juhtus ja mis on laiem mõjualas Ja muidugi on see vajalik info ka E-ITS kohustuslikus dokumentatsioonis – käsitlusala ja kaitseala defineerimisel.

• Kirjeldus: Põgus kirjeldus, mis selgitab vara funktsiooni ja olulisust organisatsioonis.

Mida rohkem infot on keskselt dokumenteeritud ja ei ela kellegi peas, seda parem. See tähendab, et inimeste ja rollide vahetumisel ei lähe see kaduma. Samuti annab see kirjeldus konteksti hilisematele sammudele: riskihindamine, kaitsetarbe valik ning etalonmeetmete valik.

• Asukoht: Kus vara füüsiliselt või loogiliselt asub? (nt “Serveriruum 1”, “Microsoft Azure (Dublin)”, “Klassiruum 12 “).

E-ITS rõhutab, et arvestada tuleb ka füüsilisest perimeetrist väljapoole ulatuvaid asukohti. See on kriitiline info turvameetmete valikul (nt kas on vaja füüsilist valvet või krüpteerimist).

• Haldaja: Kes vastutab vara igapäevase tehnilise halduse eest. (nt IT-juht.)

Vastutaja ja haldaja eristamine aitab vältida huvide konflikti ja tagada kompetentsipõhine vastutus. Vastutaja (äriprotsessi omanik) teab vara väärtust ja kriitilisust — tema otsustab, kes vajab ligipääsu ja kui kiiresti peab süsteem rikete korral taastuma. Haldaja (tehniline spetsialist) omab aga vajalikke oskusi, et need nõuded ellu viia (nt seadistada õigused, teha varukoopiaid).

Kui need rollid on segamini, võib tekkida olukord, kus IT-osakond teeb äriotsuseid (nt keelab vajaliku ligipääsu “turvalisuse” nimel) või vastupidi — äripool jätab tehnilise toe tellimata. Selge eristamine tagab, et äripool ütleb “mida” on vaja kaitsta, ja tehniline pool leiab lahenduse “kuidas” seda teha.

2. Seo varad äriprotsessidega

Kui esialgne nimekiri on olemasolevate registrite põhjal koos, on aeg hakata aktiivselt otsima seni dokumenteerimata varasid. Kõige loogilisem on seda teha äriprotsessi kaupa.

Iga äriprotsessi kohta tuleks esitada küsimus: “Mida meil on veel vaja, et see protsess töötaks?” Kas midagi olulist jäi kahe silma vahele? Selle küsimuse võiks esitada äriprotsessi vastutaja / omanikuga või vähemasti temaga koos.

E-ITS juhend soovitab siinkohal mõelda päris laialt ja otsida varasid järgmistest kategooriatest:

• füüsilised asukohad;
• taristukomponendid;
• sideühendused;
• liidestused välispartneritega;
• töötajad;
• andmed;
• IT-süsteemid;
• riistvara;
• tarkvara.

Võtame näiteks kooli. Üks kriitiline äriprotsess on “Sisseastumiskatsete korraldamine”. Mida on vaja, et see toimuks?

• Andmed: Sisseastujate isikuandmed, testitulemused.
• Tarkvara: Sisseastumiste infosüsteem (SAIS või kooli enda lahendus), tabeltöötlustarkvara tulemuste analüüsiks.
• Riistvara: Komisjoni liikmete sülearvutid, server (kui andmeid hoitakse kohapeal).
• Ruumid: Arvutiklass testide tegemiseks.
• Inimesed: Vastuvõtukomisjoni liikmed, IT-tugi.

Nii tekibki loomulik ja loogiline nimekiri varadest, mis on tegelikult olulised.

3. Grupeeri sarnased varad

Infoturbe juhtimissüsteemis ei ole mõistlik hallata tuhandet rida üksikute arvutitega. Meile piisab teadmisest, et meil on grupp “Sülearvutid”, mida kaitseme ühtemoodi.

Varagrupp on ühesugused varad, millel on sama eesmärk, sama kaitsetarve ja eeldatavasti ka ühesugused turvameetmed.

E-ITS nimetab sellist varagruppi sihtobjektiks. Ametlik definitsioon ütleb:

Sihtobjekt on kaitseala allosa – igasugune infosüsteemi kuuluv kaitsetarbega vara, nagu äriprotsess, rakendus, IT-lahenduse komponent, komponendirühm, hoone, kinnistu, allüksus. Sihtobjektile vastendatakse etalonmoodul(id).

Näidis sihtobjektid koolis:

• “Õpetajate sülearvutid” (Sihtobjekt 1) – neil on spetsiifiline tarkvara, ligipääs erinevatele süsteemidele.
• “Arvutiklassi sülearvutid” (Sihtobjekt 2) – need on mõeldud õpilastele, on piiratud õigustega.
• “Kooli wifi-võrk”.

Nagu näha, on sülearvutid jagatud kahte eraldi gruppi, sest nende kasutusotstarve ja kaitsetarve on erinev. Reegel on lihtne: grupeeri kokku varad, mis on olemuselt sarnased ja mida plaanid kaitsta identsete meetmetega. See muudab hilisema töö (modelleerimise) kordades lihtsamaks.

4. Loo ka teenusepakkujate register

E-ITS rakendusjuhendit lugedes võib jääda kahe silma vahele, et E-ITS defineerib varana ka teenuse, seega on vararegistri loomine hea hetk alustada teenusepakkujate registriga.

Mida teenusepakkujate kohta dokumenteerida?

On väga levinud läheneda teenusepakkujale kui varale. Samas, kuna infoturbe juhtimissüsteemis me lõpuks läheneme varadele ja teenusepakkujatele erinevalt, siis minu soovitus on selguse huvides teenusepakkujad (tarnijad) hoida eraldi registris. Varadele hakkame rakendama E-ITS tehnilisi etalonmeetmeid ning teenusepakkujatele rakendame riskianalüüsist tulenevalt mitte-tehnilisi meetmeid.

Teenusepakkujate puhul dokumenteerida vähemalt järgmise:

• Teenusepakkuja nimi: (nt Telia, Microsoft, Zone).
• Teenuse sisu: Lühikirjeldus, mis teenust ostetakse (nt “Serverimajutus”, “raamatupidamisteenus”) ja miks see organisatsioonile oluline on.
• Kontakt: Klienditugi ja kindlasti eraldi kontakt turvaintsidentideks (ideaalis 24/7).
• Vastutaja / omanik: Kes meie organisatsioonist selle teenuse eest vastutab
• Haldaja: Kes vastutab teenuse igapäevase tehnilise halduse eest. (nt IT-juht.)
• Äriprotsessid: Äriprotsess(id), milles see vara või teenusepakkuja osaleb.
• Varad: Millistele varadele teenusepakkujal ligipääs on.

Näide: Kooli vararegistri väljavõte

Vaatame, kuidas võiks välja näha lihtne väljavõte gümnaasiumi vararegistrist, keskendudes sisseastumise protsessile.

Näide: Kooli teenusepakkujate nimekiri

Lisaks varadele on oluline eraldi välja tuua ka kriitilised partnerid.

Levinumad vead, mida vararegistrit luues vältida

1. Ainult “raua” nägemine: See on kõige fundamentaalsem viga. Ära unusta, et info (andmed) ja tarkvara on tihti väärtuslikumad kui seade, millel need asuvad. Sülearvuti saab poest uue osta, kaotatud sisseastumiseksamite tulemusi mitte.
2. Teenusepakkujate unustamine: Pilveteenused (nt Google Workspace, eKool) on samuti sinu organisatsiooni jaoks väärtuslikud varad, kuigi need ei asu füüsiliselt koolimajas. Need tuleb kindlasti kaardistada!
3. Ülemäärane detailsus (komponendid): Ära koorma registrit komponentidega nagu hiired, klaviatuurid või üksikud kõvakettad. Need on vahetatavad osad. Võta arvele loogilised tervikud (nt “Töötaja töökoht”).

Kuidas Kordon aitab?

Käsitsi eraldi dokumentides haldamise asemel võimaldab Kordon luua infoturbe juhtimissüsteemist automatiseeritud süsteemi. See pole lihtsalt staatiline kirjeldus, vaid dünaamiline vaade, kuhu saab koondada kõik E-ITSi juhendis nõutud andmed alates varadest ja teenusepakkujatest kuni riskihinnangute ja ettevõtte päris siseturvameetmeteni.

Kordoni tõeline väärtus peitub aga seoste loomises. Sa ei pea neid seoseid lihtsalt tekstina kirjeldama, vaid saad luua reaalsed, klikitavad ühendused otse süsteemis, mis annavad igale andmepunktile tähenduse:

• Äriprotsess (mis on meile oluline)
  • sõltub Varadest ja teenusepakkujatest (mida meil on vaja kaitsta)
    • mida ohustavad Riskid (mis võib valesti minna)
      • mida me maandame Turvameetmetega (mida me teeme).

Selline puukujuline vaade annab kaks kriitilist eelist:

1. Selgus “miks” küsimuses: Iga turvameetme taga jookseb niit konkreetse riski, vara ja lõpuks äriprotsessini. Info pole lihtsalt lahtrites, vaid me saame aru seostest – me ei tee turvet turve pärast, vaid äriprotsessi kaitsmiseks.
2. Mõjude analüüs: Kui mingi vara või teenusepakkujaga on probleem (nt server on maas või tarnijal on turvaintsident), on Kordonis kohe näha, milliseid äriprotsesse ja teenuseid see tegelikult mõjutab, kellega ühenduda organisatsiooni sees ning teenusepakkuja pooleli. Exceli rägastikus on sellist seost pea võimatu kiiresti tuvastada.
3. Tööprotsessi juhtimine: Juhtimissüsteem on oma olemuselt pidev protsess, mis koosneb regulaarsetest tegevustest. Selleks, et süsteem toimiks ja vajalikud ülesanded saaksid õigeaegselt tehtud, aitab Kordon vastutajale õigel ajal meelde tuletada, mida ta tegema peab – näiteks millist riski hindama või millist teenusepakkujat analüüsima.

Kokkuvõtteks

Vara- ja teenusepakkujate registrid on elavad dokumendid. Need ei saa kunagi “valmis” samamoodi nagu maja, vaid neid tuleb koguaeg ajakohastena hoida, kui tuleb uusi äriprotsesse, varasid kantakse maha või tulevad uued.