Tietomurto, joka muutti yrityksen pilviturvallisuusoletukset
Vuoden 2022 LastPass-tietomurto ei ensisijaisesti kerro salasanahallinnasta. Se kertoo siitä, mitä tapahtuu, kun yritykset luottavat pilvipalvelutoimittajiin arkaluonteisimmalla datallaan ja tuo luottamus petetään — ei huolimattomuuden, vaan ulkopuolelta näkymättömien toteutusheikkouksien vuoksi.
LastPass markkinoi nollatieto-arkkitehtuuria. Käytännössä arkkitehtuuri ei ollut nollatieto. 25 miljoonalla käyttäjällä olivat salatut holdinsa exfiltroitu. Tietomurto ilmoitettiin ensimmäisenä elokuussa 2022 ja päivitettiin useita kertoja myöhäissyksyn 2022 aikana laajuuden laajentuessa.
Terveydenhuollon, rahoituksen ja oikeudellisten palvelujen yrityksille — aloille, joissa datan paljastuminen aiheuttaa sääntelyllistä vastuuta — LastPass-tietomurto ei ollut etäinen tapaus. Se oli ennakkovaroitus järjestelmällisestä ongelmasta.
Toteutuksen yksityiskohdat, jotka ratkaisivat
Tietomurron jälkeinen analyysi paljasti kaksi kriittistä toteutusheikkoutta:
Iteraatiomäärän puute: LastPass käytti PBKDF2:ta avainten johtamiseen. Uudemmissa tileissä käytettiin 100 100 iteraatiota — alle toimialan suosituksen 600 000. Vanhemmissa tileissä (joissain tapauksissa ennen vuotta 2018) iteraatiomäärä oli niinkin alhainen kuin 1 iteraatio. Alemmat iteraatiomäärät tekevät raa'an voiman hyökkäykset salattuihin holdeihin laskennallisesti toteuttamiskelpoisiksi. Holdeja saaneet hyökkääjät pystyivät järjestelmällisesti yrittämään pääsalasanojen murtamista.
Metadatan paljastuminen: Vaikka holdin sisältö oli salattu, metadataa ei ollut. Salasanojen hallinnassa tallennetut URL-osoitteet, käyttäjänimet ja palvelunimet olivat nähtävissä exfiltroidussa datassa. Hyökkääjät pystyivät tunnistamaan, millä palveluilla käyttäjillä oli tilejä, mahdollistaen kohdennetun tietojenkalasteluun ja tunnistetietojen täyttöhyökkäyksiin jopa ilman holvin salauksen purkamista.
Hankintatiimien arvioidessa pilviturvallisuustoimittajia LastPass-tapaus osoittaa, että kaksi kysymystä on vastattava erikseen: "Onko arkkitehtuuri nollatieto?" ja "Onko toteutus oikea?"
Okta-tietomurto: sama kuukausi, eri mekanismi
Lokakuussa 2023 Okta ilmoitti uhkatoimijan käyttäneen varastettua tunnistetietoa Oktan asiakastuen järjestelmään pääsyyn. Tietomurto paljasti yli 600 000 asiakastukitietuetta, mukaan lukien asiakkaiden tukivuorovaikutusten aikana lataamat tiedostot.
Okta on identiteettiturvallisuusalusta. Tietomurto ei ollut perustavanlaatuinen arkkitehtuurivirhe — se oli toimitusketjun pääsynhallinnan epäonnistuminen. Tukiinsinööriltä varastettiin tunnistetiedot, ja hyökkääjä käytti laillista pääsyä arkaluonteisen datan saavuttamiseen.
LastPass ja Okta havainnollistavat kaksi epäonnistumistapaa, joita yrityksen pilvipalvelutoimittajat kohtaavat:
- Arkkitehtuurivirheet: nollatieto-väitteet, jotka eivät ole aidosti toteutettu
- Pääsynhallinnan virheet: lailliset tunnistetiedot, jotka johtavat luvattomaan datan käyttöön
Nollatieto-arkkitehtuuri käsittelee ensimmäistä epäonnistumistapaa. Se ei suojaa päättäväistä hyökkääjää vastaan, jolla on lailliset tunnistetiedot toimittajan tukijärjestelmiin. Mutta se varmistaa, että edes sellainen hyökkääjä ei pääse käsiksi asiakkaan selkotekstiin — koska toimittajan tukijärjestelmillä ei ole koskaan pääsyä purettavissa olevaan dataan.
SaaS-tietoturvapoikkeamat lisääntyivät 300 % kahdessa vuodessa
Obsidian Securityn SaaS-alustojen tietoturvapoikkeamia vuosina 2022–2024 seuraava tutkimus havaitsi 300 %:n kasvun tietoturvapoikkeamissa tänä aikana.
300 %:n luku ei edusta 300 %:n kasvua hyökkääjien kehittyneisyydessä. Se edustaa SaaS-käyttöönoton kasvua yhdistettynä hyökkääjien sopeutumiseen: organisaatioiden siirtäessä yhä enemmän yritystietoa pilvipalveluihin hyökkääjät siirtyivät kohdistamaan resursseja näihin alustoihin. SaaS-toimittajan vaarantamisen tuotto-investointi-suhde — saamalla pääsyn yhtäaikaisesti kymmenien tai satojen yritysasiakkaiden dataan — on huomattavasti korkeampi kuin yksittäisten yritysten kohdistaminen.
Yrityksille, jotka rakensivat toimittajaturvallisuuden arviointiprosessinsa oletukselle, että pilvipalvelutoimittajat ovat turvallisia kohteita, vuosien 2022–2024 data vaatii uudelleenkalibroinnin. Oletus on väärä. SaaS-toimittajat ovat ensisijaisia kohteita.
Auditointitarkistuslista LastPass-tapauksen jälkeen
Yrityksille, jotka uudelleenarvioivat pilvipalvelutoimittajan turvallisuutta LastPass- ja Okta-tapausten jälkeen, käytännön tarkistuslista:
Salauksen toteutus:
- Pyydä avainten johtamisalgoritmi, iteraatiomäärä ja muistimääritykset
- Vahvista, että iteraatiomäärät täyttävät OWASP:n nykyiset suositukset (600 000 PBKDF2-SHA256 tai vastaavat Argon2id-parametrit)
- Vahvista, että avainten johtaminen tapahtuu asiakaspuolella, ei toimittajan palvelimilla
Metadatan suojaus:
- Kysy erityisesti, mitä metadataa tallennetaan selkotekstinä salatun sisällön ohella
- Pyydä datamalli, joka näyttää, mitkä kentät on salattu ja mitkä ovat käytettävissä tietomurtoskenaarioissa
Tukijärjestelmien pääsynhallinta:
- Pyydä dokumentaatio tukiinsinöörien pääsystä asiakastietoihin
- Vahvista, että tukijärjestelmillä ei ole pääsyä asiakkaan selkotekstidataan
Tietomurtoilmoitusten historia:
- Pyydä ilmoitus kaikista aiemmista tietoturvapoikkeamista, mukaan lukien ne, jotka eivät ole saavuttaneet julkisen ilmoittamisen kynnystä
- Arvioi aiempien ilmoitusten läpinäkyvyys ja kattavuus
LastPass-tietomurto oli osittain toteutuksen epäonnistuminen ja osittain läpinäkyvyyden epäonnistuminen toteutuksesta. Yritykset, jotka esittävät yksityiskohtaisia kysymyksiä ennen toimittajavalinnan tekemistä, saavat vastauksia, jotka mahdollistavat tietoisen riskiarvioinnin. Yritykset, jotka hyväksyvät korkean tason väitteitä — "salaamme tietosi" — perivät riskin toteutuksen yksityiskohtien löytämisestä tietomurron jälkeen.
Lähteet: