Infoturbeprogrammid on enamasti ehitatud raamistike ümber. Valid ISO 27001, NIS2 või SOC 2, paned meetmed kirja ja tuled (loodetavasti) auditist edukalt läbi. Ja siis teed aasta pärast täpselt sama kadalipu uuesti läbi.
Selline lähenemine on küll abiks sertifikaatide ja tõendite tootmisel. Aga see ei vasta tegelikult küsimusele, mis äri jaoks päriselt loeb: mis juhtub siis, kui midagi läheb valesti?
Just siin peitub lõhe turbe ja äri vahel. Puudu on ärikontekst. Äriprotsesside haldus on täpselt see viis, kuidas see lõhe ületada.
Mis on äriprotsess infoturbe vaates?
Infoturbe vaates on äriprotsess korduv tegevuste jada, mis laseb organisatsioonil väärtust luua või igapäevaselt toimida. See ei ole konkreetne osakond, süsteem ega inimene. See on pigem operatiivne üksus, millest ettevõtte toimimine sõltub.
Mõned näited:
- Uute klientide pardaletoomine (onboarding)
- Finantsaruandlus
- Töötajate värbamine ja haldus
- Tarkvaraarendus ja -juurutus
- Intsidentidele reageerimine
Turbe vaatepunktist on äriprotsessi puhul kõige olulisem, et selle toimimine sõltub teistest asjadest. See sõltub varadest — süsteemidest, andmetest ja infrastruktuurist. Ta sõltub tarnijatest. Teda ohustavad murepilvedena erinevad riskid. Ja mis kõige tähtsam – igal protsessil on äri poolel omanik. Talle läheb päriselt korda, et asi töötaks sujuvalt.
Just seetõttu ongi äriprotsessid infoturbeprogrammides nii võimas ankur. Need asuvad täpselt seal, kus igapäevane operatiivne reaalsus ja turbemured kokku puutuvad.
Miks infoturbeprogrammid selle sageli vahele jätavad — ja mida see maksab?
Praktikas on paljud infoturbeprogrammid üles ehitatud meetmete ja nõuete, mitte tegelike protsesside ümber. Tulemuseks on paberil meede “varukoopiate haldus”, meede “ligipääsuhaldus” või risk “lunavara”. Aga mitte kuskil pole selges keeles kirjas: kui meie arvete esitamise protsess seiskub, siis mis on tegelikult kaalul ja miks.
Sellise lahenduse tulemuseks on infoturbeprogramm, mida on juhtkonnale keeruline selgitada ja organisatsiooni sees raske prioritiseerida. See on lahti ühendatud sellest loogikast, kuidas äri tegelikult töötab.
Selle tagajärjel korduvad vääramatult kolm probleemi:
1. Riskide prioritiseerimisest saab puhttehniline harjutus. Kui riske hinnatakse vaakumis — ilma seoseta protsessidega, mida nad ohustavad —, peegeldavad riskihinnangud pigem tehnilist kõhutunnet kui tegelikku ärimõju. Nii võibki juhtuda, et mõnda harva kasutatavat süsteemi ähvardav risk saab kõrgema prioriteedi kui esmapilgul tühine oht maksete töötlemise protsessile.
2. Varade ja tarnijate otsused kaotavad konteksti. Kui süsteeme ja partnereid ei seota protsessidega, mida nad toetavad, on pagana raske selgitada, miks mõni süsteem või koostööpartner vajab põhjalikumat turvakontrolli kui teine. Miks me peame seda ühte SaaS-tööriista nii hoolikalt auditeerima? Sest see on ainus süsteem uute klientide onboardingus, ja kui see on maas, jääb kogu uus tulu ettevõttesse toomata.
3. Turbetiim räägib täitsa teises keeles. Kui turvalisus elab ainult IT- ja turvameeskonna peas, jääb side teiste ärijuhtidega kaugeks. Teema protsesside kaudu raamistamine on just see, mis nad kaasa toob. Protsessi omanik mõistab oma protsessi olulisust ja teema läheb talle korda. Samas mingist meelevaldsest meetmest nimega „loogiline ligipääsuhaldus“ ei saa ta ei sooja ega külma.
Kolm seost, mis muudavad mängureegleid
Kui äriprotsessid on kord juba kirja pandud, aitavad kolm olulist seost muuta su infoturbeprogrammi lihtsast vastavusharjutusest reaalselt töötavaks operatiivseks mudeliks.
1. Varad seotuna äriprotsessidega
Varade sidumine protsessidega annab vastuse põhilisele küsimusele: kui see süsteem rikki läheb, siis mis meil töötamast lakkab?
See on eluliselt tähtis mitmel põhjusel. Esiteks annab see tõelise sisu süsteemide kriitilisuse hindamisele. Süsteem, mis toetab vaid ühte majasisest töövoogu, on hoopis teistsuguse riskiprofiiliga kui see, millest asub sõltuvuses kolm elutähtsat äriprotsessi. See vahe peakski dikteerima, kui palju me selle vara kaitsmisse aega ja vaeva panustame.
Teiseks toob see päevavalgele kontsentratsiooniriski — olukorrad, kus peotäis kriitilisi protsesse sõltuvad kõik täpselt samast lahendusest. Sellist süsteemset ohtu vararegistrist lihtsalt välja ei loe. Sul võib olla laual ideaalselt hooldatud vararegister ning ikkagi võid sa mitte teada, et see üks kontorisise server on potentsiaalne pudelikael poole ettevõtte igapäevatööle.
Kolmandaks võimaldab see targemalt planeerida talitluspidevust (business continuity). Kui tead, milliseid protsesse mingi fail või süsteem toetab, saad taastamistöid eelistada tegeliku ärimõju, mitte lihtsalt tehniliste valikute järgi.
2. Tarnijad seotuna äriprotsessidega
Kolmandatest osapooltest sõltumine on enamikule ettevõtetele üks suurimaid operatiivriske — ja ühtlasi üks neid riske, mida on turbeseltskonnast väljapoole kõige raskem kommunikeerida.
Kui aga seod tarnijad äriprotsessidega, saab risk ootamatult ärilise konteksti. Tuima tõdemuse “tarnijal X on leping aegunud ja turbeaudit tegemata” asemel saad öelda: “protsessil, kus hoiakse kõiki meie kliendiandmeid, on väline pimeala”.
See aitab eeskätt kahel moel. Esiteks on juhtidele olukorda lihtsam esitleda, kuna potentsiaalne äriline tagajärg on must valgel näha. Teiseks toob see kaasa hulga realistlikumad kõnelused selle üle, kui mitu funktsiooni ikkagi päriselt partneritest sõltuvad. Enamasti on neid kordades rohkem, kui esialgne Excel oletada lubas.
See aitab luua korda ka tarnijate halduses laiemalt. Iga teenusepakkuja ei vaja samaväärset mikroskoopilist tähelepanu. Tarnijate jaotamine protsesside järele muudab partnerite kontrollimisele kuluva aja astmestamise aga väga lihtsaks ja ratsionaalseks.
3. Riskid seotuna äriprotsessidega
Riske äriprotsessidega seoses muudad muidu tuima riskiregistri teravaks töövahendiks prioriteetide seadmisel.
Kui risk on paaris vaid teise vara või meetmega, põhineb vastus küsimusele „kui tõsi see on“ tihti lihtsalt intuitsioonil või standardi raskustabelitel. Kui valid seose äriprotsessiga, on küsimus fookuses ja paigas: mis juhtub selle protsessiga, kui risk päriselt realiseerub? Ja mis kõige tähtsam - kui tõenäoline see stsenaarium tegelikult on?
Seeläbi haaratakse diskussiooni väga loomulikult kaasa valdkonnajuht ehk protsessi omanik. Ta ei näe enam lihtsalt igavat ja abstraktset IT-ohtude nimekirja, vaid saab selge ülevaate riskidest, mis ohustavad vahetult objekte, mida ta igapäevaselt tüürib. Sellises vestluses tahab ta ka päriselt osaleda – ja just see on tugeva infoturbeprogrammi võti.
Mida see kõik sulle tegelikult annab: nähtavus, fookus, vastutus
Ühendatud mudeli reaalsed kasutegurid paistavad välja peamiselt kolmes aspektis.
Nähtavus. Kui avad äriprotsessi, näed koheselt kogu sõltuvusahelat — süsteeme, mis seda üleval hoiavad, tarnijaid, keda kaasatakse, ohte, mis seda varjutavad, ning ülevaadet sellest, kas kaitsvad meetmed on korras või mitte. Sellisel tasemel ülevaatlikkust on tabelipõhistest mudelitest väga raske saavutada.
Prioriteetide seadmine. Turvalisusega tegelemiseks napib igas ettevõttes nii aega kui ressurssi. Äriprotsesse sidudes saad kaardid kenasti lauale laduda: asu tööle asjadega, mis kaitsevad ettevõtte operatiivselt kõige kriitilisemaid süsteeme. Seda loogikat on kõigile osalistele väga lihtne põhjendada.
Vastutus. Ärivaldkondade juhid vastutavad ju igapäevaselt selle eest, et nende tegevused oleksid kaitstud. Kui riskid, nõuded ja lahendused on omavahel loogiliselt seotud, oskavad tiimijuhid adekvaatselt sekkuda – riskihinnangust on saanud praktiline abimees, et protsessid püsiksid kindlad ja korras. Täpselt nõnda saabki turvalisus osaks ühisest, jagatud vastutusest.
Mida raamistikud tegelikult ootavad?
Kuigi ISO 27001 standardis ei ole eraldi klauslit, mis nõuaks asjade nimetamist “äriprotsesside halduseks”, on see mõtteviis terviklikult standardisse sisse programmeeritud. Peatükk 4 nõuab organisatsiooni ja sidusrühmade konteksti mõistmist. Ulatuse määratlus samas peatükis vajab arusaama seotud protsessidest. Terviklikum riskianalüüs peatükis 6 rõhutab tugevalt vajadust siduda riskid reaalse kontekstiga, ja see on võimatu ilma elemente ja protsesse laiemalt tundmata.
NIS2 kirjutab ootused ette veel otsesemalt. Raamistik eeldab punkt-punktilt sügavat arusaamist esmastest ärifunktsioonidest ning neile baasi loovatest varadest ja välisteenustest.
Igaks juhuks on hea teada ka asjaolu, et audiitoridki ootavad näha tugevat seost ettevõtte ametlike raamistike ja praktilise sisekorralduse vahel. Tuimalt IT terminoloogiat sisaldav riskiregister teeb end iga kvartaliga järjest raskemalt ja ebaveenvamalt kaitstavaks.
Tüüpilised vead, mida vältida
Protsessid pannakse kirja, aga ei seota millegi muuga. Kui äriprotsesside nimekiri lihtsalt valmib, ent sa ei vii detaile kokku ei varade, seotud riskide ega koostööpartneritega, on see lihtsalt järjekordne dokument kaustas, millest kellelegi mingit kasu ei ole. Väärtuse loovad seosed.
Liigne detailidesse kukkumine. Infoturve ei ole kindlasti valdkond, kus kulutada aega ja kurnata teisi liiga detailsete töövoo-diagrammidega. Keegi ei vaja detailset kirjeldust. Lihtsalt ja konkreetselt - mida asjad teevad, kes neid veab, ning kellest nad ise sõltuvad. Pigem sihi algul näiteks 5-20 põhiprotsessini, kui takerdu 200 alamlehega süvamenüüsse.
Omanikuks lükatakse pimesi IT osakond. Infotehnoloogia osakond haldab küll süsteeme, kuid antud funktsioonidega peab esmalt tegelema ning suuna näitama äriline valdkonnajuht - ehk valdkonna otsene töötav spetsialist. IT hoovasse langemise mure ei too tulemust - vaid vastutuse võtmata jätmist.
Projektiks pidamine. Nii protsessid kui raamistikud arenevad pidevalt. Vahetuvad meeskonnaliikmed, vananevad tööriistad ja lepinguid koostatakse vastavalt muutuvatele äritingimustele. Asjad muutuvad! Infoturbeprogramm vajab iganädalast hoolt — dokumentide pidevat ajakohastamist —, ja see ei lähe kokku laisa paigale fikseerimisega.
Kontsentratsiooniriskide ehk jagatud süsteemidega mitte arvestamine. Paljud olulised süsteemid koonduvad alatasa selgete, kitsaste pudelikaelade ümber. Teadmatus ohtudest ja partneritest võib kaasa tuua olukordi, mis seavad kogu ettevõtte töö ohtu - aga nägemata seoseid ei suudakski keegi asja avastada.
Kuidas Kordon äriprotsesside haldusele läheneb?
Kordonis ei vaadata äriprotsesse kõrvalt ega teisejärgulisena. Need on esmatähtsad — sama olulised kui andmed, tarnijad või riskid.
Iga dokumenteeritud protsessi saab loogiliselt siduda kõige sellega, mis toetab selle eesmärki — ohud, tarnijate taust ja lahenduskäigud püsivad selges, arusaadavas mudelis.
Tervisemudel jälgib süsteemide olukorda visuaalselt. Kui tarnijaga sõlmitud leping on aegunud või mõni kontroll jäänud tegemata, ilmub see vaates lahendamata ülesandena ja kandub nii raportisse kui ka selge ohusignaalina. Nii ei pea tuimi Exceli tabeleid läbi kammima — andmed ise suunavad fookuse õigele kohale kiiremaks sekkumiseks.
See täpsus loeb kõige rohkem olukordades, kus valdkonnajuhid peavad riskipositsioonide põhjal tegema kaugeleulatuvaid ja eesmärgipäraseid järeldusi, ilma et nad peaksid muretsema infoturbe ja IT terminoloogia pärast. Kordoni pakutavas mudelis näevad omanikud kõiki probleeme mugavas keskkonnas omas keeles. See seob eesmärgi ja inimese üheks toimivaks tervikuks, mitte pelgalt tehniliseks auditiks.
Märkimisväärne kergendus saavutatakse nii infoturbe spetsiifilisemate valdkondade asjatundjatele kui igapäevaselt aruandeid jälgivate igapäevatöötajate pultidele! Riskitegurit märgistav analüüsis osak viib vaatlejal pilgud seletavasse protsessi kulgu, ning pakub detailsust tegelikkusetaju riivamata tegelaste taustsüsteemi ja kaitsemõjuriteni välja. Kogu lahendus paigutub ettevõtte asisesse laadi – ja seiklusi paberil suhestab see igal juhul otseselt organisatsiooni enda argipäevaste valdkondadega.
Kust alustada?
Selleks et vabaneda pingelisest kaardistamisvaevast, sea eesmärgiks pigem julgus luua seoseid kui kohe detailidesse takerduda:
- Kirjuta üles ettevõtte 5-10 elutähtsaimat protsessi — need, mille seiskumine mõjutaks igapäeva eluliselt. Seejärel saad asuda protsessipuud laiendama.
- Määra igale valdkonnale vastutav juht — ära jäta sisulisi kohustusi ainult IT-toe kanda. Iga protsessi taga peab olema otsene vastutaja või osakond, mitte üldine “kellegi asi”.
- Kaardista esimesed olulisemad sõltuvused — millised ressursid ja teenusepakkujad on iga igapäevase protsessi jaoks asendamatud? Alusta süsteemidest või pakkujatest, kelleta kogu protsess kokku kukuks.
- Seo riskid protsessidega — märgista riskid ja lisa need otse protsessipuu vastavatesse harudesse. Nii saab iga risk konkreetse konteksti ja reaalse kaalu. Kaasa ka praktilised riskiolukorrad!
- Analüüsi ning kohenda — mida detailsem ja korrastatum su mudel, seda parema ülevaate see süsteemide tegelikust väärtusest annab, kuna see areneb koos ettevõttega pidevalt edasi.
Peaasi — sinu isiklik mudel ei pea kunagi olema matemaatiliselt ideaalne utoopia. Vajadusel kohanduv pilt töötavast maastikust aitab sul kiiremini lahendada kõige olulisemaid muresid ja teeb kõigile selgelt arusaadavaks, mis ja miks päriselt fookuses püsib.