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, kellele 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, organisatsiooni sees raske prioritiseerida ning mis 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. Võttes lahti äriprotsessi, kuvatakse sulle koheselt kogu sõltuvusahel — süsteemid, mis seda üleval hoiavad, tarnijad, keda kaasatakse, asja varjutavad potentsiaalsed ohud, ning ka ülevaade sellest, kas seda kaitsvad meetmed on korras või ei. Sellisel tasemel ülevaatlikkust on tabelite põhistest mudelitest üliväga raske saavutada.

Prioriteetide seadmine. Turvalisusega tegemiseks napib igas ettevõttes nii aega kui ressurssi. Äriprotsesse sidudes saad kaardid kenasti lauale laduda: asu tööle asjadega, mis kaitsevad ettevõttele operatiivselt kõige kriitilisemaid süsteeme. Seda loogikat on kõigile osalistele väga lihtne põhjendada.

Vastutus. Ärivaldkondade juhid vastutavad piltlikult ju igapäevaselt selle eest, et nende toimetamised oleksid kaitstud. Viies eesmärgile orienteerunult riskid koos nõuetega ja nende lahendustega loogiliselt kokku, oskavad tiimijuhid adekvaatselt sekkuda – riskihinnangust on saanud praktiline abimees, et protsessid püsiks 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 paluks asjad nimetada “äriprotsesside halduseks”, on see mõtteviis terviklikult lahendusse 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 tõikade asetamist reaalsesse raamistikku, ja see on võimatu ilma elemente ja protsesse laiemalt tundmata.

NIS2 kirjutab ootused ette veel otsesemalt. Raamistik eeldab lausa punktipunktilt suuri organisatsioonilisi arusaamu 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 ka mitte koostööpartneritega, on see lihtsalt järjekordne dokument kaustas, millest kellelgi mingit tolku ei ole. Väärtuse loovad seosed.

Liigne detailidesse kukkumine. Infoturve ei ole kindlasti valdkond, kus kulutada aega ja kurnata teisi põhjalike osavõtjate töövoogude diagrammidega. Keegi ei vaja detailset kirjeldust. Lihtsalt ja konkreetselt - mida asjad teevad, kes neid veab, ning kellest nad ise sõltuvad. Pigem sihita algselt näiteks põhilisema 5-20 protsessini kui murra luid 200 lahkartikliga süvamenüüs.

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 palka tulemust - vaid vastutuse võtmata jätmist.

Projektiks pidamine. Nii protsessid kui raamidesüsteemid rulluvad voolaval liinil. Vahetuvad tiimitöölised, vananevad abiseadmed ja teistsuguseid lepinguid koostatakse vastavalt äriilmadele. Asjad muutuvad! Infoturbeprogramm vajab iganädalast hoolt — kaustade uuendamist muudatuste teel —, 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. Ohtude ja partnerite teadmatuses võib juhtuda asju, mis panevad terve maja tööle varju - aga nägemata seoseid ei suudakski keegi asja avastada.

Kuidas Kordon äriprotsesside haldusele läheneb?

Kordonis ei vaadata äriprotsesside peale kuskilt küljelt või teisejärguliselt. Siinses loogikas on need lausa esmase tähtsusklassi märkega – vähemalt samavõrra elulised kui näiteks andmed või konkreetsed infokandjad partneritega kõrvutada.

Iga dokumenteeritud protsessi on võimalik loogiliselt ühendada tema eesmärki üleval hoidva detailirohkusega – ohud, tarnijate taust ning lahendusi otsivad teekaardid püsivad selgelt joondunult arusaadavamas mudelis.

Tervisemudel monitorib süsteemide olukorda visuaalselt. Kui tarnijaga on siduv teene otsa aegunud, kontrollimajäänud ülesanne kripeldab vaates lahendamata asjaloona, kandub detail üle nii raportisse, kui selgelt suunatud ohusignaaliks märkme taha. See on vaade, kus ei pea tuima exceli lõike lappama, vaid andmed hoiavad fookuse õiges asjus selgemaks ja kiiremaks sekkumiseks.

Ärikriitilise täpsuse fookus koondub eriti särava nurga alla olukordades, kus valdkonnatöölised peavad riskipositsioonidest tegema kaugele kaigatuvaid eesmärgipõhiseid järeldusi, vaevamata sealjuures oimukohta infoturbe ja IT terminoloogiasse eksimisest. Kordoni pakutavas mudelis näevad omanikud kõiki probleeme mugavas keskkonnas omas keeles. Loodud mudel seobki eesmärgi ja isiku kokku meeldivasse turvalahendusse - tehes sellest meeskonna lahenduste toovate sündmuste ahela, mitte pelgalt tehnilise joonlaua auditi raames.

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?

Vabastamiseks pingelise kaardistamise vaevast sea eesmärgiks seoste loomise julgus ennem detailset pusimist:

  1. Jäädvusta endale ettevõtte 5-10 elutähtsaimat protsessi - põhilised lahendused, mille seiskumine mõjutaks igapäeva eluliselt. Seejärel saad asuda teemapuud laiendama.
  2. Kinnita kõikide valdkondade teemajuhid — ja hoidu asjalikke kohustusi sokutamisest vaid IT-toe hõlma alla. Protsessi otsast on enamjaolt vajalik otsene asjatundja või osakond laiemalt!
  3. Kaardista elementaarsed esimesed kokkukõlad - missugused ressursid ja teenuseosad saavad asendamatuks iga igapäeva liini töös? Alustage süsteemidest või pakkujatest, kelleta ootab terve protsess krahhi.
  4. Siduge selged takistustetondid - märgistage riskid ning viige nad otsesemalt protsessipuu lehtedesse. Oht on oluline ja vaid oluline risk toob loomu taha tegusat tulemit. Võta appi asised riskiolukorrad!
  5. Analüüsi ning kohenda - detailirikas loogikapuu särab ja toob märksa avaramalt süsteemiväärtusi kättesaadavasse pilti teel pidevalt valmides. Iga pooleldi visuaali haaratav logistikamapp murrab elutundetu vararegistri kaardimängu mättasse!

Peaasi — sinu isiklik mudel ei pea eales olema matemaatiline ideaalsusest kubisev utoopia. Vajadusel kohenduv pilt töötavast maastikust avab sulle otsemad sihid ka elulisemate teemade muresid lahendada, ja teeb lisaks taustajõududele väga efektselt arusaadavaks – mis ja milleks päriselt fookuses olemas püsib.