Mark Fetches, Spinnaker Supportin CTO – Haastattelusarja

Mark Fetches on Spinnaker Supportin EMEA-alueen teknologiajohtaja. Hän neuvoo suuryrityksiä teknologiastrategiassa, tietoturvassa, pilvipalveluissa, tekoälyssä ja laajoissa muutoshankkeissa. Markilla on yli 30 vuoden konsultointi- ja johtamiskokemus Accenturelta, Deloittelta ja PwC:ltä, ja hän on työskennellyt tiiviisti ylimmän johdon ja hallitusten kanssa monimutkaisten yritysympäristöjen modernisoimiseksi sekä teknologiapäätösten sovittamiseksi pitkän aikavälin liiketoimintatavoitteisiin. Britanniassa toimiva Mark auttaa organisaatioita hallitsemaan vanhentuneen teknologian haasteita, operatiivisia riskejä ja digitaalista muutosta käytännöllisillä, liiketoimintalähtöisillä neuvoilla.

Spinnaker Support on johtava maailmanlaajuinen kolmannen osapuolen ohjelmistotuen, hallittujen palvelujen ja tietoturvakonsultoinnin tarjoaja yrityksille, jotka käyttävät Oraclen (ORCL ), SAP:n, JD Edwardsin ja muiden liiketoimintakriittisten alustojen ratkaisuja.

Neuvoit yrityksiä yli 20 vuoden ajan Accenturen, Deloitten ja PwC:n palveluksessa ennen siirtymistäsi Spinnaker Supportin teknologiajohtajaksi. Mitkä väärinkäsitykset teknologiariskeistä ovat kokemuksesi mukaan toistuneet johdossa, ja miten tekoälyn nousu on muuttanut näitä keskusteluja?

Mielestäni suurin väärinkäsitys on aina ollut se, että teknologiariski sijaitsee jotenkin liiketoiminnan sivussa ja sitä voidaan hallita erillisenä asiantuntijakysymyksenä. En ole koskaan nähnyt asiaa niin.

Vakavimmat näkemäni riskit juontuvat yleensä johdon valinnoista: kuinka paljon monimutkaisuutta siedetään, kuinka riippuvaisiksi tullaan vanhoista alustoista tai avaintoimittajista, kuinka voimakkaasti nopeutta tavoitellaan ja luotetaanko liiketoiminnan käyttämään dataan aidosti. Teknologia on paikka, jossa nämä valinnat näkyvät, mutta harvoin niiden alkulähde.

Olen vuosien varrella nähnyt monen johtajan keskittyvän ilmeisiin asioihin, kuten kyberturvallisuuteen, vaatimustenmukaisuuteen ja kustannusten vähentämiseen. Ne ovat tietenkin todellisia kysymyksiä. Yritykset yllättävät riskit ovat kuitenkin usein hiljaisempia: alusta, jonka kaikki tietävät hauraaksi mutta jonka korvaamista lykätään; dataongelma, jota kukaan ei täysin omista; tai ulkoistettu riippuvuus, joka näyttää tehokkaalta kunnes siitä tulee pullonkaula. Ne voivat pysyä taustalla vuosia ja tulla yhtäkkiä näkyviksi jonkin rikkoutuessa.

Mielestäni vaatimustenmukaisuus on myös pitkään sekoitettu häiriönsietokykyyn. Ne eivät ole sama asia. Organisaatio voi läpäistä auditoinnin ja silti olla paljon alttiimpi kuin luulee. Tarkistuslista ei kerro, miten liiketoiminta reagoi paineessa, kuinka nopeasti se palautuu tai näkeekö johto ongelman riittävän selvästi toimiakseen.

Tekoäly on muuttanut huomion tasoa. Aiemmin nämä keskustelut käytiin alempana organisaatiossa. Nyt ne ovat hallitushuoneessa käytävien kasvua, luottamusta, tuottavuutta ja brändiä koskevien keskustelujen ytimessä. Se on erittäin hyvä asia. Samalla on kuitenkin syntynyt uusi yksinkertaistus: ajatus siitä, että käytetty tekoälymalli olisi itse riski. Tavallisesti kokonaisuus on suurempi. Vaikeammat kysymykset koskevat mallia ympäröivää dataa ja hallintoa, päätöksiä joihin se vaikuttaa sekä sitä, missä kohdassa ihmisen harkinnan on yhä oltava ratkaisevaa.

Jos tiivistäisin asian, sanoisin ettei teknologiariski ole koskaan koskenut vain teknologiaa. Se on aina heijastanut johdon harkintaa. Tekoäly on vain tehnyt tämän paljon vaikeammaksi sivuuttaa.

Tietoturvatiimeillä on käytössään enemmän tietoa haavoittuvuuksista kuin koskaan, mutta organisaatiot kamppailevat silti priorisoinnin kanssa. Miksi kyse on mielestänne signaali–kohina-ongelmasta eikä havaitsemisongelmasta?

Sanoisin asian hyvin yksinkertaisesti: alalta ei puutu haavoittuvuusdataa, vaan selkeyttä.

Useimmilla tietoturvatiimeillä on jo enemmän kuin tarpeeksi syötteitä: skannerituloksia, uhkatiedustelua, vakavuusluokituksia, korjaustiedotteita ja raportteja hyväksikäytöistä. Kysymys ei ole siitä, löytävätkö ne heikkouksia, vaan siitä, pystyvätkö ne erottamaan harvat liiketoiminnalle aidosti vahingolliset kohteet lukuisista teknisesti kiinnostavista mutta seurauksiltaan vähäisemmistä.

Siksi pidän tätä signaali–kohina-ongelmana. Havaitseminen on parantunut valtavasti, mutta kontekstin soveltamiskyky ei ole pysynyt mukana. Haavoittuvuudesta tulee todellinen prioriteetti vasta, kun ymmärretään missä se sijaitsee, kuinka alttiina se on, miten kriittinen kyseinen resurssi on, mitä korvaavia hallintakeinoja on käytössä ja mikä olisi hyväksikäytön liiketoimintavaikutus.

Käytännössä monet organisaatiot turvautuvat edelleen helpoimmin tuotettaviin mittareihin, kuten vakavuusluokituksiin, korjausten määriin ja ikääntymisraportteihin. Ne ovat hyödyllisiä, mutta eivät sama asia kuin ihmisen harkinta. Korkean pistemäärän ongelma vähäarvoisessa sisäisessä järjestelmässä voi olla paljon vähemmän merkittävä kuin alemmaksi luokiteltu heikkous asiakasrajapinnassa tai toiminnan kannalta kriittisessä järjestelmässä.

En siis usko, että kyse on pohjimmiltaan näkyvyysongelmasta. Se on liiketoiminnan priorisointiongelma, joka tietoturvatiimien on opittava ratkaisemaan. Olemme erittäin hyviä tuottamaan löydöksiä, mutta vähemmän johdonmukaisia muuttamaan ne lyhyeksi toimenpidelistaksi, jota johto voi tukea luottavaisin mielin.

Tämä on mielestäni todellinen muutos, joka alan on vielä tehtävä: siirryttävä mittaamasta, kuinka paljon pystymme havaitsemaan, siihen että päätämme, mikä liiketoimintavaikutusten kannalta todella merkitsee.

Hallitustasolla kyse on riskin kääntämisestä liiketoiminnan kielelle: pystyykö organisaatio muuttamaan teknisen altistumisen muutamaksi selkeäksi ja toteuttamiskelpoiseksi liiketoimintaprioriteetiksi? Siinä onnistuvat organisaatiot siirtyvät kohinasta signaaliin.

Monet kyberturvallisuustoimittajat väittävät tekoälyn voivan priorisoida haavoittuvuudet ja ennustaa uhkia automaattisesti. Missä näette eron markkinointitarinan ja sen välillä, mitä tekoäly pystyy nykyään realistisesti tuottamaan yritysympäristöissä?

Yksinkertaisimmin sanottuna markkinointi lupaa usein sellaista varmuutta, jota todelliset yritysympäristöt eivät yksinkertaisesti mahdollista.

Toimittajat kuvaavat tekoälyä usein kuin se voisi nousta kohinan yläpuolelle, ottaa kaiken tiedon vastaan ja kertoa tietoturvatiimille luotettavasti, mikä on tärkeintä ja mitä seuraavaksi todennäköisesti tapahtuu. Se on houkutteleva lupaus, koska jokainen tietoturvajohtaja haluaa vähemmän sekavuutta ja enemmän varmuutta. Suuressa organisaatiossa asiat ovat kuitenkin harvoin niin selkeitä, että lupaus toteutuisi näin suoraviivaisesti.

Tekoäly voi ehdottomasti auttaa. Se voi yhdistää kuvioita, vähentää manuaalista lajittelua, nostaa poikkeamia esiin ja auttaa tiimejä käsittelemään tietomääriä, joita olisi muuten vaikea hallita. Tällä on todellista arvoa. Tiimin nopeuttaminen on kuitenkin eri asia kuin sen tietäminen luotettavalla tarkkuudella, mikä juuri kyseisessä ympäristössä on tärkeintä.

Tässä ero näkyy. Useimpien yritysten konteksti on epätasainen: omaisuusluettelot ovat puutteellisia, omistajuus ei ole aina selvä, liiketoimintakriittisyys muuttuu, hallintakeinot vaihtelevat ympäristön osasta toiseen ja datan laatu on kirjavaa. Jos lähtökuva on vajaa, myös tekoälyn tulos jää vajaaksi riippumatta siitä, kuinka viimeistellyltä käyttöliittymä näyttää.

Tämä korostuu erityisesti toimittajien puhuessa ennustamisesta. Väitteillä ”tämä kuvio näyttää riskialttiilta” ja ”näin tapahtuu seuraavaksi” on merkittävä ero. Ensimmäinen voi olla hyödyllinen. Jälkimmäisessä kieli kulkee usein todellisuuden edellä.

Siksi tekoäly kannattaa nykyään ymmärtää vahvistimena, ei auktoriteettina. Se voi auttaa tiimejä lajittelemaan, yhdistämään ja kohdistamaan huomion. Se ei pysty johdonmukaisesti korvaamaan ihmisen harkintaa, paikallistuntemusta ja selkeää ymmärrystä siitä, mistä liiketoiminta todella välittää.

Tässä kulkee todellinen raja. Tarina lupaa varmuutta. Todellisuus on vaatimattomampi mutta myös hypeä hyödyllisempi, jos siitä puhutaan rehellisesti. Tekoäly voi parantaa analyysin laatua ja nopeutta, mutta se ei poista yritysturvallisuuden päätöksenteon sotkuisuutta.

Spinnaker Support työskentelee laajasti Oracle-, SAP- ja JD Edwards -ympäristöjen parissa. Mikä tekee pitkälle räätälöidyistä ERP-ympäristöistä erityisen vaikeita tekoälypohjaisille tietoturvatyökaluille ymmärtää ja arvioida tarkasti?

Näitä ympäristöjä vaikeuttaa se, että riittävän monen vuoden jälkeen ne lakkaavat käyttäytymästä kuin vakiomuotoiset ohjelmistot, joilla tekoälyä on koulutettu, ja alkavat muistuttaa enemmänkin tallennetta siitä, miten liiketoiminta todella toimii.

Tämä pätee kokemukseni mukaan erityisesti voimakkaasti räätälöityihin Oracle-, SAP- ja JD Edwards -ympäristöihin. Paperilla kyse voi yhä olla tunnetusta alustasta. Todellisuudessa vastassa on usein vuosien paikallisia mukautuksia, räätälöityä koodia, perittyjä integraatioita, käyttöoikeusrakenteita, raportointilogiikkaa ja hyvin erityisistä toiminnallisista syistä rakennettuja kiertoteitä. Tekoälypohjaisen tietoturvatyökalun on vaikea tulkita tällaista luotettavasti.

Monet näistä työkaluista toimivat parhaiten, kun ympäristö on suhteellisen yhdenmukainen ja kuvioita on helppo verrata. Pitkälle räätälöidyt ERP-ympäristöt ovat harvoin sellaisia. Logiikka on mutkikkaampaa, dokumentaatio usein puutteellista ja omistajuus voi jakautua tiimien kesken. Epätavalliselta näyttävä asia voi olla täysin tarkoituksellinen, kun taas tavanomaiselta näyttävä voi tukea aidosti kriittistä talous-, toimitusketju- tai tuotantoprosessia.

Tässä vaikeus piilee. Työkalua ei pyydetä vain havaitsemaan haavoittuvuutta tai virheellistä määritystä, vaan ymmärtämään, mitä ongelma merkitsee liiketoimintaprosessin, räätälöidyn riippuvuuden tai sellaisen hallintarakenteen yhteydessä, jota ei ehkä ole missään muualla.

Se on paljon vaikeampi ongelma kuin markkinointi yleensä antaa ymmärtää. Tekoäly voi auttaa löytämään kuvioita, vähentää manuaalista analyysia ja ohjata ihmisiä tarkempaa tutkimusta vaativiin kohteisiin. Jos ympäristö on kuitenkin vain osittain dokumentoitu, vuosien poikkeusten muovaama ja syvästi sidoksissa yrityksen toimintatapaan, automaattisen järjestelmän kyvyllä tulkita sitä itsenäisesti on rajansa.

Todellinen kysymys ei siis ole, näkeekö tekoäly jotakin, vaan ymmärtääkö se ympäröivää kontekstia riittävästi arvioidakseen asian oikein. Voimakkaasti räätälöidyissä ERP-ympäristöissä juuri tässä ihmisen asiantuntemus ratkaisee.

Yksi keskeisistä väitteistänne on, ettei ihmisen asiantuntemus ole poistettava pullonkaula vaan olennainen osa tietoturvaprosessia. Voitteko antaa esimerkkejä tilanteista, joissa ihmisen harkinta tunnisti riskin, jonka tekoälypohjainen priorisointijärjestelmä olisi todennäköisesti ohittanut?

Kyllä, ehdottomasti. Juuri tässä automaattisen priorisoinnin rajat tulevat mielestäni hyvin näkyviksi.

Jotkin riskit käyvät järkeen vasta, kun ympäristö tunnetaan riittävän hyvin ja datan taustalla oleva kokonaisuus ymmärretään. Järjestelmä ei ehkä ulospäin näytä erityisen tärkeältä eikä haavoittuvuuspistemäärä poikkeavalta. Ympäristön tunteva henkilö voi kuitenkin tietää sen tukevan palkanlaskentaa, neljännesvuosiraportointia, haurasta integraatiota tai liiketoimintaprosessia, jonka keskeytymiseen yrityksellä ei ole varaa. Datan signaali voi näyttää tavalliselta, mutta todellinen seuraus ei ole.

Olen myös nähnyt tapauksia, joissa hallintakeinot näyttävät teoriassa paremmilta kuin käytännössä. Tekoäly voi olettaa riskin pienentyneen, koska segmentointi on käytössä, pääsyä on rajoitettu tai valvontakeino on olemassa. Ympäristöä läheltä tunteva ihminen voi kuitenkin tietää, että yhtä keinoa sovelletaan epäjohdonmukaisesti, toinen ohitetaan toiminnan ollessa paineessa ja kolmas on huomaamatta lakannut toimimasta luotettavasti. Tällainen ero ei aina näy selvästi virallisessa järjestelmässä.

Sama tapahtuu räätälöidyissä ympäristöissä. Komentosarja, työnkulku tai käyttöoikeusmalli voi näyttää tavanomaiselta, kun kuvioita skannataan laajassa mittakaavassa. Järjestelmän vuosien mukautukset tuntevalle henkilölle sama yksityiskohta voi erottua välittömästi todellisena altistuksen lähteenä.

Myös ajoitus merkitsee. Haavoittuvuus voi näyttää erillisenä hallittavalta, mutta muuttua paljon vakavammaksi yrityksen ollessa keskellä migraatiota, yrityskauppaa, sääntelymääräaikaa tai toiminnan huippukautta. Automaattisen järjestelmän ei aina ole helppo antaa tällaiselle muutokselle oikeaa painoa.

Kun puhun ihmisen asiantuntemuksesta, en tarkoita epämääräistä vaistoa. Tarkoitan paikallistuntemusta, muistia, harkintaa ja kykyä nähdä, milloin pieni tekninen ongelma liittyy johonkin paljon merkittävämpään.

Siksi en pidä ihmisen asiantuntemusta poistettavana pullonkaulana, vaan osana, joka estää väärän varmuuden. Tekoäly voi auttaa lajittelemaan ja rajaamaan dataa, mutta tärkeimmät riskit tulevat usein näkyviksi vasta, kun joku ymmärtää miten liiketoiminta todella toimii.

Kun organisaatiot kiirehtivät ottamaan tekoälyä käyttöön tietoturvatoiminnoissa, mitkä ovat haavoittuvuuksien hallinnan ja altistuksen arvioinnin liiallisen automatisoinnin suurimmat riskit?

Suurin näkemäni riski on hallinnan vaikutelman luominen ilman todellista ymmärrystä siitä, että tilanne on hallinnassa.

Automaatio on haavoittuvuuksien hallinnassa selvästi arvokasta. Yrityksen mittakaavassa sitä tarvitaan ongelmien löytämiseen, datan yhdistämiseen, laajamittaiseen priorisointiin ja prosessin ylläpitämiseen. Vakavasti toimiva organisaatio ei voi tehdä kaikkea käsin.

Vaara syntyy, kun automaatio alkaa ohjata ohjelmaa ilman riittävää ihmisten tekemää haastamista.

Ensimmäinen ilmeinen riski on väärä priorisointi. Automaattisiin pisteisiin liikaa luottamalla tekninen vakavuus voidaan sekoittaa liiketoimintariskiin. Ne eivät ole sama asia. Kriittinen haavoittuvuus eristetyssä tai korvaavin keinoin suojatussa resurssissa voi käytännössä merkitä vähemmän kuin alemman luokituksen ongelma hyvin altistuneessa, kriittiseen liiketoimintaprosessiin liittyvässä järjestelmässä.

Toinen riski on kontekstin menetys. Automatisoidut ohjelmat ovat vain niin hyviä kuin niiden taustalla olevat omaisuus- ja omistajuustiedot, riippuvuuskartat ja poikkeusten käsittely. Jos tiedot ovat puutteellisia, kuten yrityksissä yleensä osittain ovat, automaatio voi siirtää virheellisiä päätöksiä järjestelmän läpi erittäin tehokkaasti.

Kolmas riski liittyy käyttäytymiseen. Kun ihmiset alkavat luottaa työnkulkuun liikaa, he lakkaavat kyseenalaistamasta sen tuloksia. Tiimit olettavat listan kärkeen nousevien asioiden olevan tärkeimpiä ja muiden voivan odottaa. Se on ymmärrettävää mutta vaarallista, koska kulttuuri siirtyy tietoon perustuvasta riskienhallinnasta koneen järjestyksen passiiviseen hyväksymiseen.

Laajempi strateginen riski on suoritemäärän sekoittaminen turvallisuuden paranemiseen. Suuren haavoittuvuusmäärän sulkeminen näyttää operatiivisesti hyvältä ja tuottaa mittareita sekä vauhdin tuntua. Ellei samalla vähennetä liiketoiminnalle tärkeimpiä altistuksia, organisaatio voi vain oppia näyttämään kiireiseltä entistä nopeammin.

Automaatio saa siis tehdä raskaan työn, mutta sen pitää tukea harkintaa, ei korvata sitä. Muuten prosessi voi olla tehokas, mitattava ja skaalautuva olematta välttämättä turvallisempi.

Olet työskennellyt laajasti IT-muutosten ja yritysarkkitehtuurin parissa. Miten tietoturvajohtajien tulisi tasapainottaa haavoittuvuuksien nopea korjaaminen ja liiketoiminnan kannalta kriittisten järjestelmien häiriöistä aiheutuvat operatiiviset riskit?

Erinomainen kysymys, sillä tällä alueella helppo vastaus on yleensä väärä.

Haavoittuvuudet halutaan tietenkin korjata nopeasti. Yksikään tietoturvajohtaja ei kannata tunnettujen haavoittuvuuksien jättämistä avoimiksi pidempään kuin on tarpeen. Todellisessa yritysympäristössä, etenkin kriittisiä järjestelmiä käytettäessä, nopeus ei kuitenkaan ole itseisarvo. Jos korjaus tehdään huonosti ja liiketoiminnalle tärkeä järjestelmä kaatuu, yksi ongelma on ratkaistu luomalla toinen.

Tasapainossa on siis kyse sen ymmärtämisestä, mitkä riskit ovat välittömiä, mitkä teoreettisia ja mitkä järjestelmät kestävät muutoksen aiheuttamatta ongelmia muualla.

Jotkin haavoittuvuudet vaativat aidosti kiireellisiä toimia. Jos jokin on altis, hyödynnettävissä ja sijaitsee tärkeässä osassa ympäristöä, on toimittava. Usein päätös ei kuitenkaan ole niin ehdoton kuin annetaan ymmärtää. Ongelman ympärillä voi olla muita hallintakeinoja. Järjestelmä voi olla tarkasti eristetty. Muutoksen tekemisen operatiivinen riski tänään voi olla suurempi kuin tilanteen säilyttäminen hetken ajan ja työn tekeminen hallitusti.

Siksi parhaat tietoturvajohtajat pystyvät käymään liiketoiminnan kanssa kypsän keskustelun. Ei vain: ”Tämä on kriittinen, korjatkaa se heti”, vaan: ”Tässä on altistus, näin voi käydä, näin huonosti tehty toimenpide voi epäonnistua ja tätä kautta etenemme turvallisimmin.” Se on uskottavampaa johtamista kuin jokaisen haavoittuvuuden käsitteleminen irrallisena ongelmana.

Mielestäni nämä tilanteet paljastavat myös jotain syvempää itse IT-ympäristöstä. Jos organisaatio pelkää jatkuvasti ydinjärjestelmien korjaamista, koska jokainen muutos tuntuu vaaralliselta, ympäristö on yleensä muuttunut hauraaksi. Piileviä riippuvuuksia on liikaa, testaukseen luotetaan liian vähän ja arkkitehtuurin häiriönsietokyky on heikko. Silloin korjauspäivityksistä käytävä keskustelu on todellisuudessa paljon vanhemman ongelman oire.

Korjatkaa siis nopeasti silloin, kun riski on todellinen ja etenemistapa selvä. Herkässä ympäristössä tehtävänä on kuitenkin vähentää riskiä luomatta suurempaa sotkua. Tästä tasapainossa on kyse.

Rehellisesti sanoen useimmat kokeneet tietoturvajohtajat tietävät tämän jo. Haasteena on soveltaa harkintaa paineen alla, kun aika käy vähiin eikä kukaan halua kantaa vastuuta väärän päätöksen seurauksista.

Spinnakerin toimintamalli yhdistää tekoälypohjaisen analyysin asiantuntijoiden tekemään validointiin. Mitkä tehtävät tekoälyn pitäisi hoitaa ja mitkä päätökset tulisi jättää tiukasti kokeneiden tietoturva-ammattilaisten käsiin?

Mielestäni raja on itse asiassa varsin selvä.

Tekoälyn pitäisi hoitaa työ, joka hyötyy nopeudesta, mittakaavasta ja johdonmukaisuudesta. Suurten datamäärien läpikäynti, signaalien yhdistäminen, kuvioiden tunnistaminen, poikkeavilta näyttävien asioiden merkitseminen ja vaihtoehtojen rajaaminen ovat juuri sellaisia tehtäviä, joissa koneista on hyötyä. Se säästää aikaa, vähentää käsityötä ja antaa tietoturvatiimeille paremman lähtökohdan.

Se soveltuu hyvin myös työn toistuviin osiin: alustavaan luokitteluun, havaintojen tiivistämiseen, samankaltaisten ongelmien yhdistämiseen, toistuvien poikkeusten seurantaan ja niiden kohtien osoittamiseen, joissa tietynlaisia valvonnan heikkouksia ilmenee yhä uudelleen. Mikään tästä ei korvaa asiantuntemusta, mutta se auttaa käyttämään sitä paremmin.

Olisin huomattavasti varovaisempi siinä vaiheessa, kun analyysistä siirrytään päätöksentekoon.

Tärkeiden ratkaisujen pitäisi edelleen kuulua kokeneille tietoturva-ammattilaisille. Onko tämä oikeasti vakava riski juuri tässä liiketoiminnassa vai näyttääkö se vakavalta vain teoriassa? Onko kyse aidosta valvonnan pettämisestä vai hankalasta mutta tunnetusta poikkeuksesta? Jos korjaamme tämän nyt, mitä muuta saatamme häiritä? Jos odotamme, minkä riskin todella hyväksymme? Nämä ovat harkintaa vaativia ratkaisuja.

Ja tämä kaikki tulee ennen asian inhimillisempää puolta. Miksi sama ongelma toistuu? Kantaako organisaatio tämän riskin tietoisesti vai onko se vain lakannut huomaamasta sitä? Onko kyse yksittäisestä ongelmasta vai merkistä taustalla vaikuttavasta kulttuurista? Tällaisella tulkinnalla on edelleen suuri merkitys.

Antaisin siis tekoälyn tehdä lajittelun, ryhmittelyn, ensimmäisen kierroksen ja raskaan työn. En kuitenkaan antaisi sen päättää ilman ihmisen tarkistusta, mistä liiketoiminnan pitäisi olla eniten huolissaan tai mihin toimiin tulisi ryhtyä.

Kun päätöksellä on operatiivisia, taloudellisia tai maineeseen liittyviä seurauksia, kyse ei enää ole vain tiedon käsittelystä. Kyse on harkinnan käyttämisestä.

Ja tietoturvassa sen pitäisi mielestäni edelleen kuulua oikealla älyllä varustetulle ihmiselle.

Monet organisaatiot painottavat edelleen voimakkaasti haavoittuvuuksien lukumääriä ja vakavuuspisteitä. Miksi aito altistuksen hallinta vaatii mielestäsi laajempaa näkökulmaa, joka huomioi korvaavat hallintakeinot, käyttöoikeusrajoitukset, järjestelmäarkkitehtuurin ja liiketoimintaympäristön?

Laajempi näkökulma tarvitaan, koska pelkkä luku ei kerro paljoakaan siitä, kuinka suurissa vaikeuksissa todella ollaan.

Vakavuuspisteillä ja haavoittuvuuksien lukumäärillä on paikkansa. Ne auttavat hahmottamaan ongelman laajuutta ja järjestämään työjonon. Ne eivät kuitenkaan tarkoita samaa kuin altistuksen ymmärtäminen, ja juuri tässä moni organisaatio menee edelleen harhaan.

Haavoittuvuus voi näyttää teoriassa vakavalta mutta olla käytännössä melko hyvin rajattu. Jos pääsy järjestelmään on tiukasti rajoitettu, sen ympärillä on muita korvaavia hallintakeinoja ja se sijaitsee käyttörajoitusten vuoksi vaikeasti saavutettavassa ympäristön osassa, ongelman todellinen haittatodennäköisyys voi poiketa paljon raakapisteiden antamasta kuvasta.

Sitten on päinvastainen tapaus, joka on usein kiinnostavampi. Alempana listalla oleva ongelma voi osoittautua sijaintinsa vuoksi paljon tärkeämmäksi. Se koskettaa kriittistä palvelua, siihen on helpompi päästä tai se sijaitsee arkkitehtuurin osassa, jossa yhden kohteen vaarantuminen antaa hyökkääjälle tilaa edetä. Yksinkertainen vakavuusjärjestys ei selitä tällaista hyvin.

Kun ihmiset puhuvat altistuksen hallinnasta, sen täytyy mielestäni tarkoittaa muutakin kuin haavoittuvuuksien järjestämistä pisteiden mukaan ja listan läpikäymistä ylhäältä alas.

On tiedettävä, mitä ongelman ympärillä on: millaisia hallintakeinoja on jo käytössä, kuka kohteeseen pääsee, onko järjestelmä eristetty vai yhteydessä johonkin tärkeämpään ja mitä hyödyntämisen jälkeen todella tapahtuu.

Muuten päädytään hallitsemaan riskistä annettua kuvaa eikä itse riskiä. Koontinäyttö paranee, tikettien määrät liikkuvat ja raportointi näyttää paremmalta, mutta turvallisuus ei välttämättä lisäänny.

Osasyy tähän on mielestäni se, että luvut tuntuvat lohdullisilta. Ne näyttävät objektiivisilta, tarjoavat siistin esitystavan ja luovat vaikutelman, että ongelma on muutettu mitattavaksi ja hallituksi. Todellinen altistus on kuitenkin yleensä paljon sotkuisempi.

Se syntyy haavoittuvuuden, sitä ympäröivien hallintakeinojen, sen arkkitehtuurin ja mahdollisen liiketoimintavaikutuksen leikkauspisteessä.

Käyttäkää siis pisteitä ja lukumääriä, tietenkin. Älkää kuitenkaan sekoittako niitä ymmärrykseen.

Jos todellinen altistus halutaan löytää, on mielestäni tarkasteltava koko ympäristöä eikä vain siihen liitettyä numeroa.

Yritysohjelmistoympäristöt ovat siirtymässä merkittävään muutosvaiheeseen, kun organisaatiot uudistavat vanhoja järjestelmiään ja ottavat samalla käyttöön tekoälyteknologioita. Miten näet tekoälyn, kyberturvallisuuden ja yritysalustojen välisen suhteen kehittyvän seuraavien kolmen–viiden vuoden aikana, ja mihin teknologiajohtajien tulisi valmistautua jo nyt?

Uskon, että seuraavat kolmesta viiteen vuotta ovat varsin ratkaisevia.

Yritykset pyrkivät uudistamaan vanhoja IT-ympäristöjään samaan aikaan kun ne tuovat tekoälyn mukaan, eikä kumpikaan tehtävä ole yksinään helppo. Niiden tekeminen yhtä aikaa nostaa panoksia.

Ensimmäinen muutos on mielestäni se, että tekoäly lakkaa olemasta sivukokeilu ja muuttuu osaksi liiketoiminnan todellista toimintatapaa. Se tulee työnkulkuihin, tukeen, kehitykseen, tietoturvatoimintoihin ja alustojen hallintaan – ei uutuutena vaan osana perusrakenteita.

Kun näin tapahtuu, kyberturvallisuuskeskustelu muuttuu vakavammaksi. Enää ei kysytä vain, onko työkalu hyödyllinen, vaan mihin se pääsee käsiksi, mihin se voi vaikuttaa, mitä dataa sille syötetään ja mitä seuraa siitä, kun se tekee virheen.

Uskon myös, että tietoturvan ja arkkitehtuurin erottaminen toisistaan vaikeutuu entisestään. Monissa vanhoissa ympäristöissä tietoturvaongelmalta näyttävä asia on todellisuudessa tietoturvamerkin saanut arkkitehtuuriongelma. Heikko identiteettien suunnittelu, liialliset riippuvuudet, epäselvä omistajuus, hauraat integraatiot ja puutteellinen näkyvyys ovat näkyvän ongelman taustalla olevia asioita. Tekoäly ei silota tätä sotkua pois. Se voi pikemminkin paljastaa sen nopeammin.

Tässä onnistuvat mielestäni ne organisaatiot, jotka lakkaavat käsittelemästä tekoälyn käyttöönottoa, kyberturvallisuutta ja alustojen modernisointia kolmena erillisenä työvirtana. Ne ovat yhä enemmän sama keskustelu.

Jos neuvoisin teknologiajohtajia nyt, aloittaisin näkyvyydestä. On saatava paljon selkeämpi käsitys siitä, mitä ympäristössä on, miten osat liittyvät toisiinsa, kenellä on pääsy mihinkin, missä arkaluonteinen data liikkuu ja missä todelliset valvontapisteet sijaitsevat. Ilman tätä tekoälyn lisääminen kasvattaa vain niiden asioiden määrää, joita ei täysin ymmärretä.

Seuraavana tulee hallinto, mutta ei näennäinen sellainen. Tarvitaan todellisia päätöksiä. Missä tekoälyä saa käyttää? Missä ihmisen tarkistuksen on säilyttävä? Miten tulokset tarkastetaan? Mitä dataa ei saa käyttää? Kuka vastaa seurauksista, jos järjestelmä ohjaa väärään toimintaan? Näihin kysymyksiin on vastattava nyt, ei myöhemmin.

Ja rehellisesti sanoen yksinkertaistaminen on tärkeämpää kuin moni haluaa myöntää. Mitä mutkikkaampi ympäristö on, sitä vaikeampi sitä on suojata ja modernisoida sekä käyttää tekoälyä luomatta uutta epävarmuutta.

Sitten on vielä ihmiset. Parhaiten onnistuvat organisaatiot osaavat yhdistää automaation ja harkinnan. Ne eivät vain hyväksy tekoälyn tulosta, koska se on nopea tai viimeistelty. Ne haastavat ja testaavat sitä sekä vastustavat sitä tarvittaessa.

Uskon siis, että tekoäly, kyberturvallisuus ja yritysalustat kytkeytyvät lähivuosina paljon tiiviimmin toisiinsa.

Hyvin valmistautuvat johtajat ymmärtävät mielestäni, ettei kyse ole vain teknologiamuutoksesta. Kyse on muutoksesta siinä, miten päätöksiä tehdään, miten valvontaa toteutetaan ja kuinka häiriönsietokykyinen organisaatio todella on.

Kiitos erinomaisesta haastattelusta. Lisätietoja haluavat lukijat voivat tutustua Spinnaker Supportiin.