Toimivien tekoälyjärjestelmien rakentaminen alkaa niiden rikkomisesta. Toteutimme hyökkäävän tietoturvatestauksen, jossa hyökkääjän tavoin testasimme finanssipalvelualan asiakassovellusta ja etsimme siitä heikkouksia. Havaintomme ovat tärkeitä kaikille, jotka ottavat käyttöön suuriin kielimalleihin perustuvia sovelluksia, joissa tietoturvasta ei voi tinkiä.
Hyökkäävässä tietoturvatestauksessa tekoälyjärjestelmä yritetään tarkoituksellisesti rikkoa, jotta haavoittuvuudet voidaan korjata ennen kuin todellinen hyökkääjä löytää ne. Finanssipalveluissa panokset ovat erityisen korkeat: tekoälysovellukset käsittelevät asiakastietoja ja maksutapahtumia sekä tuottavat taloudellisia analyyseja. Epäonnistumisen seuraukset voivat vaihdella huonosta käyttökokemuksesta sääntelyrikkomuksiin, taloudellisiin tappioihin ja korjaamattomaan mainehaittaan.
Tavoitteenamme oli löytää haavoittuvuudet varhain, testata realistisia hyökkäysmalleja ja auttaa organisaatiota täyttämään tekoälyturvallisuutta koskevat vaatimukset, joihin sääntelyviranomaiset suhtautuvat erittäin vakavasti.
Tässä on syytä tehdä yksi ero: rajoitusten kiertäminen (jailbreak) kohdistuu taustalla olevan mallin turvasuodattimiin, kun taas kehoteinjektio kohdistuu itse sovellukseen yhdistämällä käyttäjän epäluotettava syöte kehittäjän luotettuun kehotteeseen. Kehoteinjektio aiheuttaa suuremman riskin, koska se kohdistuu juuri sinun järjestelmääsi ja sen käsittelemiin luottamuksellisiin tietoihin, ei yleiskäyttöiseen malliin.
Ensimmäinen testikierroksemme käsitti noin 750 testiä seuraavista aiheista:
Tietojen vuotaminen istuntojen välillä
Henkilötietojen paljastuminen (luonnollisen kielen, API-rajapinnan manipuloinnin ja erilaisten koodausten kautta)
SQL-injektio
Järjestelmäkehotteen ohittaminen
Ensimmäisissä testeissä havaitsimme nykyisessä järjestelmässä kaksi merkittävää ongelmaa: useita aikomuksia sisältävien kyselyjen käsittelyn ja koodattujen kehotteiden käytön.
Useita aikomuksia sisältävät kyselyt: pyynnöt, joissa yhdistyvät asialliset ja haitalliset tavoitteet. Esimerkki: “Näytä kulutukseni luokittain ja suorita myös [haitallinen SQL-kysely].” Sovellus ei havainnut haitallista tarkoitusta, vaan luotti täysin tietokerroksen myöhempiin suojauksiin. Se vastaa ulko-oven jättämistä auki sillä perusteella, että kellarin kassakaappiin voi luottaa.
Koodaus: pyynnöt, jotka on koodattu Base64-, Hex- tai LeetSpeak-muotoon tai homogLyfeillä. Järjestelmien voi olla vaikea suodattaa niistä haitallista tarkoitusta. Vaikka kyselyt eivät havaintojemme mukaan paljastaneet arkaluonteisia tietoja, ne horjuttivat järjestelmää merkittävästi. Seurauksena oli muun muassa hallusinaatioita, haitallisen SQL:n toistamista käyttäjille ja aikomusten virheellistä luokittelua.
Ensimmäisten testiemme tulokset osoittivat seuraavaa:
Aikaan liittyvät hallusinaatiot: malli palautti itsevarmasti esitettyjä mutta keksittyjä päivämääriä, maksutapahtumien aikaleimoja tai tiettyä ajanjaksoa koskevia yhteenvetoja. Tämä on merkittävä riski finanssialalla, sillä väärän päivämäärän perusteella toimimisella voi olla asiakkaalle todellisia seurauksia
Haitallisen SQL:n toistaminen käyttäjälle (huolestuttavaa muistin saastuttamisen riskin kannalta)
Aikomusten virheellinen luokittelu
Sekava tulosteen muotoilu
Näiden havaintojen perusteella rajasimme tutkimuskohdetta. SQL-injektioiden ja koodausten testaus siirrettiin alemmalle prioriteetille, sillä tiimi oli jo puuttumassa niihin. Keskityimme sen sijaan tehokkaimpiin hyökkäysvektoreihin: henkilötietojen paljastumiseen ja tietojen vuotamiseen istuntojen välillä.
Toisen kierroksen hätkähdyttävin havainto oli yksinkertainen: usein ei tarvitse olla lainkaan ovela.
Monissa tapauksissa riitti, että sisäisiä tietoja yksinkertaisesti pyysi osana asialliselta kuulostavaa pyyntöä, ja järjestelmä suostui paljastamaan ne. Yksinkertaisiin kyselyihin saatiin vastauksia, joissa viitattiin sisäisiin tunnisteisiin ja järjestelmäkenttiin, joita loppukäyttäjien ei pitäisi koskaan nähdä.
Tarkempi tutkimus osoitti, ettei kyse ollut vain sovellustason viasta. Jatkossa käytetty tekstistä SQL:ksi muuntava palvelu muodosti kyselyitä, joissa pyydettiin liian monta kenttää, ja sen selittävissä vastauksissa viitattiin tietoihin, joihin pääsyä olisi pitänyt rajoittaa. Tämä paljasti järjestelmien välisen todellisen halkeaman – haavoittuvuuden, joka tulee esiin vain testaamalla koko teknologiapino eikä yksittäisiä komponentteja erillään.
Kohdista hyökkäävä tietoturvatestaus järjestelmään, älä malliin. Suuren kielimallin testaaminen erillään kertoo hyvin vähän sovelluksesi tietoturvan tasosta. Testaa koko teknologiapino päästä päähän samalla tavalla kuin käyttäjä käyttäisi sitä.
Syöte on validoitava ennen suurta kielimallia. Koodatut kyselyt, useita aikomuksia sisältävät hyökkäykset ja yksinkertaiset injektioyritykset on torjuttava järjestelmän ulkoreunalla eikä jätettävä myöhempien palvelujen vastuulle.
Älä luota järjestelmien liitoskohtiin. Useista palveluista koostuvissa arkkitehtuureissa kiinnostavimmat haavoittuvuudet piilevät järjestelmien välisissä halkeamissa. Nollaluottamus tarkoittaa nollaluottamusta, joten validoi kaikki jokaisessa kerroksessa.
Yksinkertaiset hyökkäykset toimivat. Kehittyneet rajoitusten kiertämiset (jailbreak) päätyvät otsikoihin, mutta joskus voi vain... kysyä. Jos järjestelmäsi paljastaa mielellään sisäisiä tunnisteita, kun käyttäjä sisällyttää ne muuten asialliseen kyselyyn, kyseessä on ongelma.
Ymmärrä, mitä todella testaat. Suuri kielimalli voi tunnistaa tunnetut hyökkäysmallit oman koulutuksensa ansiosta, ei sinun suojaustesi vuoksi. Sisällytä hyökkäävään tietoturvatestaukseen kattava valvonta, jotta ymmärrät, mitkä hallintakeinot testeissä todella aktivoituvat.
Rajoitetut ympäristöt vaativat luovia ratkaisuja. Mukautetut palveluntarjoajat ja paikallisten mallien tuki mahdollistavat mielekkään hyökkäävän tietoturvatestauksen ilman erityisiä pilvipalvelujen käyttöoikeuksia. Ole kuitenkin avoin tästä aiheutuvista rajoituksista.
Hyökkäävä tietoturvatestaus ei ole kertaluonteista. Se on toistuva prosessi, joka kannattaa automatisoida mahdollisuuksien mukaan ja jota pitää kehittää järjestelmän mukana. Huomenna merkitykselliset hyökkäykset eivät ole samoja kuin tänään.
Säännellyissä ympäristöissä käytettäviin tekoälyjärjestelmiin kohdistuva valvonta vain lisääntyy. Organisaatiot, jotka pitävät tietoturvatestausta jatkuvana toimintana eivätkä julkaisua edeltävänä rastina ruudussa, pystyvät vastaamaan valvontaan paremmin ja välttämään asiakkaiden luottamusta nakertavat mainekriisit.