Craig Riddell, Wallarmin Global Field CISO – Haastattelusarja

Craig Riddell, Wallarmin Global Field CISO, on kokenut kyberturva-asiantuntija, joka keskittyy auttamaan yrityksiä hallitsemaan kasvavaa riskiä, joka liittyy API:hin ja tekoälyjärjestelmiin. Nykyisessä roolissaan hän työskentelee läheisesti CISO:iden, CIO:iden ja insinöörijohtajien kanssa kääntämällä todelliset hyökkäysmallit ja väärinkäytön tilanteet toimiviksi turvallisuusstrategioiksi, joissa on vahva painopiste havainnollisuudessa – ymmärtäessä, miten API:t ja tekoälyjärjestelmät toimivat tuotannossa ympäristössä, sovelluksissa ja integraatioissa. Uransa aikana hän on toiminut johtotehtävissä identiteetin ja pääsyritysten hallinnassa, nollatuotannon arkkitehtuurissa ja yrityksen turvallisuudessa organisaatioissa, kuten Netwrix, Kron ja HP, joissa hän on johtanut laajamittaisia IAM-muutoksia ja modernisoinut turvallisuuskehyksiä. Riddellin asiantuntemus keskittyy uusiin uhkiin, kuten liiketoimintalogiikan hyökkäyksiin, API-väärinkäyttöön, tekoälyjärjestelmien poikkeamaan ja petokseen, jossa on jatkuvasti painopistettä siltaa rakentamassa turvallisuuden strategian ja toiminnan toteutuksen välillä.

Wallarm on kyberturva-alan yritys, joka erikoistuu suojaamaan API:itä, sovelluksia ja tekoälyjärjestelmiä modernissa pilviympäristöissä. Sen alusta tarjoaa jatkuvan löytämisen, testaamisen ja reaaliaikaisen suojauksen uhkilta, kuten API-väärinkäytölta, liiketoimintalogiikan hyökkäyksiltä ja automaattisilta hyökkäyksiltä, samalla tarjoten syvän näkyvyyden siihen, miten järjestelmät toimivat monimutkaisissa infrastruktuureissa. Monipilvi- ja pilvi-alkuperäisille arkkitehtuureille suunniteltu Wallarm integroituu olemassa oleviin DevOps- ja turvallisuustyövirtoihin, mahdollistaen organisaatioiden havaita ja estää hyökkäykset, kun ne tapahtuvat, eikä vasta sen jälkeen. Yhdistämällä API-inventoinnin, tekoälyohjatun uhkien havaitsemisen ja automaattisen vastauskyvyn, alusta vastaa kasvavaa todellisuutta, jossa API:t ja tekoälyjärjestelmät ovat modernien digitaalisten liiketoimintojen ensisijainen hyökkäyspinta.

Millaisia avainmuutoksia urallasi on ollut siirryttäessäsi suoraan järjestelmien ja infrastruktuurin kanssa työskentelystä johtotehtäviin, jotka keskittyvät identiteetin, pääsyn, API:n ja tekoälyn turvallisuuteen? Mitkä näistä muutoksista johtivat siihen, että todellinen riski on siirtynyt reuna-alueelta API:hin ja konepohjaisiin järjestelmiin?

Urani alussa painopiste oli reuna-aluetta suojaamassa. Palomuurit, segmentointi, infrastruktuurin lujittaminen. Tämä malli toimi, kun järjestelmät olivat enemmän staattisia ja luottamuksen rajat olivat helpommin määriteltävissä.

Mitä muuttui, oli se, miten sovellukset rakennettiin ja miten järjestelmät vuorovaikuttivat. API:t tulivat kaiken toiminnan yhdistäjäksi, ja tekoäly kiihdytti tätä edelleen. Nyt järjestelmät tekevät päätöksiä, kutsuvat toisia järjestelmiä ja suorittavat toimintoja mittakaavassa ja nopeudessa, joka ei vaadi ihmisten osallistumista.

Tässä vaiheessa reuna-alueesta tulee vähemmän merkittävä. Todellinen riski siirtyy siihen, missä päätökset tehdään ja toimintoja suoritetaan, eli API:hin ja konepohjaisiin työnkulkuihin.

Jos sinulla ei ole näkyvyyttä ja valvontaa siellä, luotat käyttäytymiseen, jota et voi täysin nähdä. Siinä ilmenee liiketoimintariski, joka voi johtaa taloudelliseen altistumiseen, tahattomiin seurauksiin ja toiminnan keskeytymiseen.

Miten kyberkäsittely, jolla järjestelmät luovat luottamuksen ja vaihtavat toimintoja yhä monimutkaisemmissa API- ja automaattisten prosessien ketjuissa, näyttäytyy hajonneena nykyisissä yritysympäristöissä?

Useimmissa ympäristöissä järjestelmät luottavat toisiinsa identiteetin ja todennuksen perusteella. Tunniste on voimassa, pyyntö on hyvin muodostettu, ja vuorovaikutus on sallittu.

Ongelma on, että tämä olettaa, että voimassa oleva on sama kuin turvallinen. Tämä ei enää pidä paikkaansa.

Me todennamme identiteetin, mutta emme vahvista aikomusta. Me vahvistamme pääsyn, mutta emme käyttäytymistä ketjun ylitse.

Palvelu saattaa olla valtuutettu kutsumaan toista palvelua, joka laukaisee alasvirtaisia toimintoja useiden API:iden yli. Jokainen vaihe näyttää lailliseksi erillään, mutta koko ketjussa alkaa ilmetä tahattomia käyttäytymisiä tai loogisen väärinkäytön.

Tekoälyohjatuissa ympäristöissä tämä ilmiö vahvistuu. Agentit voivat ketjuttaa toimintoja ja suorittaa työnkulkua ilman ihmisten tarkastelua.

Käsittely tapahtuu edelleen, mutta kukaan ei kysy, onko käyttäytyminen järkevää asiayhteydessä. Luottamus on luotu, mutta sitä ei jatkuvasti vahvisteta.

Miksi tekoäly- ja API-riski usein jää organisaatioiden rajojen väliin eikä kuulu selkeästi kenellekään?

Siksi, että järjestelmät eivät vastaa sitä, miten organisaatiot on rakennettu.

DevOps omistaa toimituksen. Turvallisuus omistaa politiikan. Liiketoimintatiimit omistavat tulokset. Datatiimit omistavat mallit. Jokainen ryhmä omistaa osan, mutta kukaan ei omista järjestelmää sellaisenaan tuotannossa.

API:t suorittavat liiketoimintalogiikkaa järjestelmien yli. Tekoäly tuo mukaan epädeterministisen päätöksenteon sen lisäksi. Yhdessä ne leikkaavat jokaisen rajan.

Ne on rakennettu yhdellä tiimillä, turvattu toisella ja kulutettu kolmannella, epäjohdonmukaisella seurannalla kaikissa.

Tästä syystä syntyy aukkoja, jotka eivät ole tiimien epäonnistumisia, vaan toimintamallin epäonnistumisia heijastaa, miten modernit järjestelmät tosiasiassa toimivat.

Kuka tiimeistä yleensä olettaa omistavansa tekoälyriskin, ja missä kohdissa turvallisuus, DevOps ja liiketoimintayksiköt ovat sokeat?

Turvallisuustiimit ovat taipuvaisia omistamaan tekoälyriskin hallinnon ja vaatimustenmukaisuuden näkökulmasta. DevOps omistaa käyttöönoton ja luotettavuuden. Liiketoimintatiimit keskittyvät tuloksiin.

Sokeat kohdat ilmenevät näiden alueiden välillä.

Turvallisuus määrittää, mitä pitäisi tapahtua. DevOps varmistaa, että järjestelmä toimii. Liiketoiminta keskittyy tuloksiin. Mutta harvat tiimit tarkkailevat jatkuvasti, mitä järjestelmä tekee todella reaaliajassa.

Tässä kuilussa asuu riski, erityisesti silloin, kun käyttäytyminen on teknisesti voimassa, mutta asiayhteydessä väärä.

Monet modernit hyökkäykset näyttäytyvät voimassa olevana ja todennettuna käyttäytymisenä eikä ilmeisinä tunkeutumisina. Miten organisaatioiden tulisi uudelleenarvioida havaitsemista tässä uudessa todellisuudessa?

Meidän on siirryttävä “pahojen” pyyntöjen tunnistamisen ulkopuolelle.

Monissa tapauksissa pyyntö on voimassa. Tunnisteet ovat legitimejä. API-kutsu on odotettu. Mitä ei odoteta, on toimintojen järjestys, määrä tai tulos.

Havaitseminen on muuttunut käyttäytymiseksi ja asiayhteydelliseksi. Se ei ole enää yhden pyynnön estämistä, vaan ymmärtämistä, miten järjestelmät vuorovaikuttavat ajan kuluessa.

Lähestymistavat, jotka todella kestävät mittakaavassa, siirtyvät mallien vastaamisesta. Ne purkavat pyynnöt rakenteellisesti, käsitellen jokaista vuorovaikutusta joukkona käyttäytymisen merkkejä eikä yritä vastata tunnettuja huonoihin mallipohjaisiin.

Tämä mahdollistaa ymmärtämään, miten käyttäytyminen kehittyy ja missä se poikkeaa, vaikka kaikki näyttäisi pinnan alla olevan voimassa.

Jos luotat staattisiin sääntöihin tai allekirjoituksiin, sinä jätät väliin suurimman osan siitä, mikä on merkittävää.

Mitä tarkoittaa merkityksellinen havainnollisuus API:ille ja tekoälyjärjestelmille tuotannossa?

Merkityksellinen havainnollisuus ei ole vain lokit ja mittarit. Se on ymmärtäminen käyttäytymisestä asiayhteydessä.

API:ille se tarkoittaa täydellistä pyyntö- ja vastausnäkyvyyttä, miten päätepisteitä käytetään ja miten vuorovaikutukset kehittyvät ajan kuluessa.

Tekoälyjärjestelmille se tarkoittaa ymmärtämistä syötteistä, päätöksistä ja tuloksellisista toimista.

Ennen kaikkea se tarkoittaa yhdistämistä näitä järjestelmiä yhdistäviin työnkulkuihin, eikä erillisiin tapahtumiin.

Ilman tätä olet toimintaa oletuksilla järjestelmän käyttäytymisestä, eikä todellisuuden perusteella.

Miksi perinteinen ihmisten tarkastus- ja hyväksymismalli muuttuu vähemmän tehokkaaksi konepohjaisissa ympäristöissä?

Siksi, että nopeus ja mittakaava ovat muuttuneet.

Järjestelmät tekevät tuhansia tai miljoonia kutsuja minuutissa, ja hyökkäykset tai tahattomat käyttäytymiset voivat kehittyä minuuteissa tai sekunneissa. Et voi realistisesti laittaa ihmistä silmänkulmaan jokaisen päätöksen kohdalla ilman, että rikot suorituskykyä.

Tekoälyjärjestelmät eivät myöskään aina ole deterministisiä, mikä tekee ennalta hyväksymismalleista vähemmän tehokkaita.

Ihmisten valvonta on edelleen tärkeää, mutta se tarvitsee siirtymistä yksittäisten toimien hyväksymisestä käyttäytymisen reunaehtojen määrittelyyn ja tulosten seuraamiseen.

Mitkä ovat yleisimpiä toiminnallisia aukkoja, joita näet, kun yritykset yrittävät turvata tekoälyjärjestelmiä perinteisten turvallisuuskehyksen avulla?

Suurin aukko on suuri riippuvuus suunnitteluaikaisista ohjaimista.

Organisaatiot keskittyvät turvaamaan malleja, tarkastamaan koodia ja määrittämään käytäntöjä ennen käyttöönottoa. Tämä on tärkeää, mutta se olettaa, että järjestelmät toimivat odotetusti, kun ne ovat käyttöönotettu.

Todellisuudessa järjestelmät kehittyvät. API:t muuttuvat. Tekoälymallit vuorovaikuttavat uuden datan ja työnkulkujen kanssa. Käyttäytyminen muuttuu ajan kuluessa.

Ilman jatkuvaa käyttäytymisen vahvistamista tuotannossa organisaatiot ovat käytännössä sokeat käyttöönoton jälkeen.

Millainen on käytännöllinen toimintamalli, kun useat sidosryhmät jakavat vastuun tekoäly- ja API-riskistä?

Se alkaa siitä, että kukaan tiimi ei voi omistaa tätä kokonaisuutena.

Käytännöllinen malli määrittää jaettua vastuuta, joka on ankkuroitu yhteiseen totuuteen: tuotannon käyttäytyminen.

Turvallisuus määrittää riskin ja politiikan. Insinöörit rakentavat ja operoivat järjestelmiä. Liiketoiminta määrittää hyväksyttävät tulokset.

Tiimit, jotka pääsevät tämän asian eteen, toimivat suljetussa silmukassa. Jatkuva löytäminen, pakkauksen teko ja parannus, johdettuna siitä, mitä järjestelmät tekevät todella tuotannossa, eikä siitä, mitä oletettiin suunnitteluaikana.

Kaikkien sidosryhmien on oltava näkyvyyttä siihen, miten järjestelmät toimivat tuotannossa. Siitä tiimit voivat sopia siitä, miltä “hyvä” näyttää, havaita poikkeamat ja reagoida.

Muutos on siirtymässä omistamisesta koordinoituun vastuuseen, joka perustuu tuotannon näkymään.

Edetessäsi eteenpäin, odotatko turvallisuuden vastuun keskittyvän uudelleen tai jatkuvan hajaantumisenä, kun järjestelmät tulevat yhä autonomisemmiksi?

Vastuu on jakautunut, koska se heijastaa, miten järjestelmät on rakennettu.

Mitä muuttuu, on se, miten tämä vastuu koordinoidaan.

Näemme yhdenmukaisempia hallintomalleja, joissa tiimit omistavat omat alueensa, mutta toimivat jaetulla näkyvyydellä ja asiayhteydellä.

Onnistuneet organisaatiot eivät ole niitä, jotka yrittävät keskittää kaikkea. Ne ovat niitä, jotka kohdistavat sidosryhmät ymmärtämään, miten järjestelmät toimivat todellisessa maailmassa.

Siksi, että jos kukaan ei ymmärrä tuotannon käyttäytymistä, kukaan ei todella omista riskiä.

Kiitos haastattelusta. Lukijat, jotka haluavat oppia lisää, voivat vierailla Wallarm-sivustolla.