VABAKAVA2: Taaskasutus 😉

 Taaskasutus?

No nii, mis nüüd? Nimelt oli vaja ühe kanditatuuri raames kirjutada essee. No mõeldud tehtud ja tööandjale edastatud, aga mida teha selle täitsa sisuka esseega? Mida muud ikka kui sohki ja taaskasutada seda selle aine raames lisa punktide saamiseks😉.

AI-d kasutasin keelelise korektuuri jaoks põhiliselt, pisut ka proof of concept kinnitamiseks.

Nõrkused ja haavatavused nii inimeses kui masinas ehk kuidas ma kaitsen haiglat ja tervishoiutöötajaid tehnoloogia, masinate ning küberturbe lahendustega.

Tänapäevane suurhaigla on küberturbe mõistes üks keerukamaid ja vastutusrikkamaid keskkondi, kus süsteemide käideldavus ei tähenda pelgalt rahalist võitu või kaotust, vaid otsest mõju inimeludele. Selles enam kui 1000 töötajaga dünaamilises ökosüsteemis peituvad haavatavused kahes peamises kihis: inimeses ja masinas. Inimlikud nõrkused ei tulene reeglina pahatahtlikkusest, vaid ülekoormusest ja õigest fookusest – tervishoiutöötaja peab keskenduma patsiendile, mitte keerulistele IT-nõuetele. Järgnevalt avan oma nägemuse, kuidas sellisele asutusele tagada tugev kaitse ja terviklik ülevaade toimuvast.

Nullusaldus ja identiteedihaldus

Me kõik teame, et valdav enamik tõsistest küberintsidentidest saab alguse varastatud või muul moel kompromiteeritud kasutajakontodest. Selle ohuvektori maandamiseks tuleks rakendada nullusalduse (Zero Trust) printsiipi ning siduda see paroolivaba (passwordless) sisselogimise ja mitmefaktorilise autentimisega (MFA). Viimase saaks mugavalt integreerida näiteks haiglatöötaja läbipääsukaardi või ametitõendiga. Neid põhimõtteid rakendades kaob kasutajatel vajadus ebaturvaliste paroolipraktikate järele (näiteks sama parooli taaskasutamine era- ja tööseadmetes, paroolide ülesmärkimine märkmepaberile jne). Järgmine loogiline samm on ühekordse sisselogimise (Single Sign-On ehk SSO) juurutamine. Nii toimides on samaaegselt tagatud nii kõrge turvatase kui ka kasutajate rahulolu, sest väheneb igapäevane parooliväsimus.

Nullusalduse arhitektuur ei piirdu aga ainult turvalise ühekordse tuvastamisega, vaid eeldab pidevat usalduse hindamist. Siin tuleb mängu kontekstipõhine ligipääs (Conditional Access). Süsteem ei küsi enam ainult „kes sa oled?”, vaid ka „kust, millal ja millise seadmega sa tuled?”. Kui töötaja logib infosüsteemi haigla sisevõrgust ja turvalisest tööarvutist, on riskimäär madal ning ligipääs tagatakse sujuvalt ja kiiresti. Kui aga tuvastatakse mingi anomaalia, näiteks sama töötaja sisselogimiskatse välisriigist töövälisel ajal, hinnatakse risk kohe kõrgeks ning ligipääs võidakse automaatselt blokeerida või nõuda lisatuvastamist.

Zero Trust arhitektuuri edukaks rakendamiseks peab organisatsioonis olema juurutatud tugev identiteedi- ja ligipääsuhalduse (IAM) lahendus, sõltumata sellest, kas tegemist on kohaliku või pilvekeskkonnaga. See lahendus peab tagama vähimate õiguste printsiibi (Least Privilege) ja rollipõhise ligipääsu (RBAC). Neist põhimõtetest lähtumine on kriitilise tähtsusega, et minimeerida ründevektoreid ja võimalikku kahju, kui töötaja või võtmeisiku konto peaks mingil põhjusel kompromiteeritud saama.

Targa IAM-i suurim kasutegur väljendub automatiseerimises. See aitab vältida inimlikke eksimusi õiguste jagamisel ja tagab samal ajal korrektsed logid (dokumenteeritud kontrolljälje), mis on hädavajalikud intsidentide uurimisel ja audiitoritele esitamisel. Samuti on vajalik automatiseerida kasutaja elutsükli haldus (JML ehk Joiner, Mover, Leaver). Kuna näiteks 1000 töötajaga haiglas on personaliliikumist palju, on manuaalse halduse korral inimliku eksimuse tõenäosus palju suurem kui automaatika puhul. IT-toel võib kergesti juhtuda, et lahkunud töötaja konto jääb mõnes kõrvalsüsteemis sulgemata. Need unustatud „kummituskontod“ on ründajatele kõige lihtsamaks tagaukseks.

Automaatika tõhusaks toimimiseks on vaja siduda IAM-lahendus otse personalitarkvaraga. Kui töötaja vahetab osakonda või lahkub töölt, viiakse muudatused ellu kohe ja automaatselt pärast kasutaja andmete uuendamist süsteemis. Nii on tagatud, et endine töötaja ei pääse enam patsientide andmetele ega süsteemidele ligi, mis kõrvaldab kohe ühe potentsiaalse ja väga kriitilise turvariski.

Toimepidevus ja seadmete mikrosegmenteerimine

Kõik eelnev (tsentraalne IAM, SSO ja pidev konteksti hindamine) loob aga süsteemis uue potentsiaalse haavatavuse: kriitilise sõltuvuse võrguühendustest ja erinevate integratsioonide laitmatust toimimisest. Haigla kontekstis ei saa me lubada olukorda, kus plaani A (näiteks pilvepõhise autentimise) ebaõnnestumisel peatub kogu meditsiiniasutuse töö. Kui turvalahendus on disainitud nii, et ühenduse katkemisel ei pääse arst patsiendi elutähtsatele andmetele või seadmetele ligi, oleme turvalisuse sildi all loonud eluohtliku pudelikaela. Seetõttu tuleb lahenduste planeerimisel silmas pidada toimepidevust (Business Continuity).

Iga kriitilise lahenduse juures peab eksisteerima plaan B ja plaan C. Näiteks peab elutähtsatel kohalikel süsteemidel olema võrgukatkestuse korral võimekus töötada autonoomses režiimis (võrguühenduseta ehk offline- ja puhverdatud ehk cached-autentimine), tuginedes viimastele teadaolevatele turvaprofiilidele. Täieliku katastroofi korral peab alati säilima manuaalne ligipääsuvõimalus süsteemidele – näiteks on juurkasutaja (root) konto andmed talletatud paberkandjale ja hoiustatud turvaliselt seifis.

Meditsiinivaldkonnas on seadmed tihti sama või kohati isegi suurema tähtsusega kui inimesed. Kuna spetsiifikat on palju, tuleb eraldi tähelepanu pöörata just neile. Need seadmed on kallid ning töötavad sageli aegunud operatsioonisüsteemidel või arhitektuuridel, mida ei ole garantii või muude piirangute tõttu võimalik turvauuendustega paigata. Seetõttu tuleb sellised seadmed mikrosegmenteerida ehk paigutada iga kriitiline seade omaette võrgusegmenti ja lubada andmevahetus ainult hädavajalike lõpp-punktidega (endpoints). See aitab takistada ründaja külgsuunalist liikumist (lateral movement), kui keegi pahatahtlik peaks siiski võrgule ligi pääsema.

Seire, SIEM ja automaatika

Asutuse küberturve on täpselt sama tugev, kui on tema ülevaade süsteemides toimuvast. Kui logides kajastuvad anomaaliad jäävad märkamata, võib oht märkamatult kriitiliseks kasvada. Selle vältimiseks tuleks paigaldada võimekas logi- ja seiresüsteem. Heaks näiteks on Elastic Cloud Enterprise (ECE), mis suudab koondada ka Check Pointi ja muude lahenduste logid. Süsteemi nõrkade kohtade ehk ühtsete rikkepunktide (Single Point of Failure ehk SPOF) vältimiseks tuleb need lahendused seadistada kõrgkäideldavalt ja klasterdatult.

SIEM-tarkvara juurutamine on ilmselt kõige töö- ja ajamahukam ülesanne terve turbearhitektuuri loomisel. Selle käigus tuleb seadistada teavitused, logihaldus ja andmete talletamine. Samuti tuleb luua profiilid ja töölauad (dashboard'id) süsteemi eri aspektide jälgimiseks. Elasticu puhul saab rakendada ka lokaalset masinõpet, mis hakkaks ise logisid läbi kammima ja haigla taristus potentsiaalseid ohte tuvastama.

Edasiarendusena saab rakendada SOAR-automaatikat. Näiteks juhul, kui mõni seade kompromiteeritakse ja see hakkab võrgus ebatavaliselt käituma, astub süsteem ise vahele. Seade isoleeritakse playbook’i (tegevusjuhise) järgi automaatselt võrgust ning administraatorile edastatakse viivitamatu teavitus. Pideva valmisoleku tagamiseks saab lisaks mängu tuua tehisintellekti (AI) ja katsetada always-on purple teaming’u lahendusi. See võimaldab arhitektuuril end pidevalt ja automaatselt testida, et käia ajaga kaasas ning olla pahatahtlikest ründajatest alati sammu võrra ees.

Juurutamise tegevuskava ja kokkuvõte

Sellise ulatusliku arhitektuuri juurutamine ei ole kindlasti ühe aastaga täielikult teostatav – see eeldab põhjalikku planeerimist, testimist ja kohandamist. Tuleb koolitada nii kasutajaid kui ka administraatoreid ning iga uue faasi alustamisel luua selge plaan ja analüüsida riske. Kuid kuskilt tuleb alustada:

• Esimesel poolaastal võiks välja valida SIEM-lahenduse ja alustada selle juurutamisega, kuna süsteemidest tervikliku ülevaate tagamine on minu silmis kõrgeim prioriteet. Juurutamise põhisammudena näen spetsialistide koolitamist ja arhitektuuri planeerimist (logihaldus, andmegrupid jne), alustades kõige kriitilisematest seadmetest ja süsteemidest.
• Teisel poolaastal jätkuks töö SIEM-lahendusega, kuid paralleelselt alustataks võrkude ja seadmete mikrosegmenteerimisega. Ka see on mahukas projekt, mis tuleb hoolega planeerida. Võimaluse korral võiks alustada IAM-lahenduse planeerimise ja katsetamisega. Kuna eelnevate tööde mahud on suured, on täiesti arusaadav, kui IAM-lahenduse täiemahuline kasutuselevõtt (rollout) jääb järgmisesse aastasse. Kõik sõltub IT-meeskonna suurusest, oskustest ja võimekusest.

Aasta jooksul jõuab katsetada eri lahendusi väiksemas mahus. Näiteks saaks paroolivaba sisselogimist ja IAM-süsteemi esialgu rakendada IT-meeskonnas. See tagab, et meeskonnal on isiklik kogemus, võimekus ja oskused aidata teisi haiglatöötajaid tulevikus ees ootaval suurel üleminekul.

Kokkuvõttes on sellise tervikliku turbearhitektuuri juurutamine reaalsuses pigem 2–3 aasta pikkune teekond. Kuigi see teekond on pikk ja keerukas, saab selle läbimise järel uhkusega tagasi vaadata teadmises, et haigla igapäevatöö on muudetud nii turvalisemaks kui ka kasutajatele mugavamaks.

Essee mahupiirangute tõttu jäid paratamatult käsitlemata mitmed olulised teemad, näiteks tööjaamade spetsiifiline turve ja haldus, taristu üldine seire ning IT-osakonna endaga seotud ohtude maandamine. Kõike üksipulgi lahti kirjutades muutuks see kirjatükk liiga pikaks, seega keskendusin siinkohal suurele pildile ja minu hinnangul kõige kriitilisematele vundamendikividele.

Mõistan hästi, et pärismaailm ei ole alati ideaalne ning sellised suurprojektid nõuavad organisatsioonilt nii aega, pühendumist kui ka märkimisväärset eelarvet. Loodan siiski, et leiate minu mõttekäikudest kasulikke ideid ja värskeid vaatenurki, mida tuleviku planeerimisel arvesse võtta!