Mitä seurauksia on asiakastietojen huonolla suojauksella?

Viime viikonlopun 16 000 henkilön tietovuoto on hyvä esimerkki, mitä seurauksia asiakastietojen puutteellisella suojauksella voi olla.

Vaikka yksityiskohtaisia tietoja vuodetun informaation keruusta ei ole vielä saatavilla, yksi asia on varmistunut: vuodetut tiedot on koottu useasta eri lähteestä.

Tämä tarkoittaa, että useat eri tahot eivät ole täyttäneet lain mukaisia tarpeellisia teknisiä ja organisatorisia toimenpiteitä henkilötietojen suojaamiseksi asiattomalta pääsyltä. Täydellistä suojausta asiatonta pääsyä vastaan ei ole taloudellista toteuttaa, mutta tämä vuoto kertoo samaa (ottamatta kantaa tämän hyökkäyksen tekijään), mitä Anonymous Finland julkaisussaan sanoo: suomalaiset viranomaiset, yritykset ja instituutiot eivät suojaa asiakastietojansa kunnolla, koska vuodettu tieto on pystytty keräämään useasta eri lähteestä.

Miten saavuttaa riittävä suoja?

Riittävän suojauksen määrittäminen on aina tietoa keräävän yrityksen tai yhteisön vastuulla. Vaikka mitään minimivaatimuksia riittävälle suojaukselle ei ole asetettu, useat eri suositukset (esimerkiksi CAG – consensus audit guidelines) antavat hyvät lähtökohdat minimivaatimusten toteuttamiseksi. Pelkkien vähimmäistoimenpiteiden, kuten oletusasetusten välttäminen ja säännölliset ohjelmistopäivitykset, toteuttaminen usein estää automaattisten hyökkäysten onnistumisen. Tämä parantaa asiakastietojen suojaa merkittävästi verrattuna tilanteeseen, että mitään ei ole tehty. Vähimmäistoimenpiteiden lisäksi rekisterinpitäjän tulee kehittää suojaustaan jatkuvasti, koska jatkuvat muutokset ympäristössä mahdollistavat uusia heikkouksia järjestelmässä.

Tämä tietovuoto on vain yksi esimerkki, mitä huonosta asiakastietojen suojauksesta voi seurata. Toivottavasti tämä toimii useille tahoille hyvänä muistutuksena, että näiden tietojen suojaukseen tulee panostaa. Jos omaa osaamista tilanteen korjaamiseen ei ole, kannattaa ottaa yhteyttä ulkoisiin asiantuntijoihin tilanteen parantamiseksi.

___

Tomi Mikkonen toimii Trusteqissa hankejohtajana, jonka vastuualueita ovat verkkoturvallisuus, kuluttajatietojen suojaaminen, turvallinen tuote- ja järjestelmäkehitys sekä palvelukehitys.

Pikainen kertaus APT:hen löytyy http://en.wikipedia.org/wiki/Advanced_persistent_threat

Suojaus vuodelta miekka ja kivi

Jos ympäristön tietoturva luottaa siihen vanhaan tilan pitävään palomuuriin, josta on ulos sallittu vähintään DNS- ja http/s-protokollat ja koneilla pyörii perinteiset antivirussoftat, uhan ei tarvitse olla erikoisen edistynyt ollakseen tuon ympäristön APT.

Toisaalla voi olla tehty puolustusta syvyydessä, viimeisimmät antimalware-systeemit, valvonnat, päivitykset ja kovennukset sekä kuuminta hottia oleva APT, joka käyttää kaikkia kikkoja toimiakseen ja pysyäkseen toimivana. Sekin on APT tuolle ympäristölle.

Haitake identiteettivarkaana

Haitakkeilla on oma elinkaarensa:

1. Pääse sisään
2. Tee itsestäsi pysyvä
3. Soita kotiin ohjeita varten
4. Lähetä varastettu data kotiin tai hyödynnä ympäristön resursseja muuten

Haitakkeet käyttävät jotain sen hetken tietoturva-aukkoa päästäkseen sisään ympäristöön. Tulevaisuudessa sisälle päästyään ne sulautuvat “lailliseksi” osaksi ympäristöä.

Haitake voi luoda itselleen tunnuksen AD:hen tai muuhun master-hakemistoon. AD:ta ja paikallisia ryhmiä hyödyntäen, haitake saa lähes pääkäyttäjätasoiset oikeudet ympäristöönsä lisäämällä itsensä eri ryhmiin. Nämä eri ryhmät eivät yksittäisinä ole erityisen arvokkaita mutta yhdessä niillä saa huomattavat oikeudet.

Pääkäyttäjätasoisuus voi merkitä myös, että tunnus tekeytyy joksikin toiseksi ja käyttää ympäristön oikeiden pääkäyttäjien tai avainhenkilön identiteettiä omiin tarkoituksiinsa, eli impersonoituu.

Lokeissa ympäristön oikea henkilö näyttää tekevän normaaleja asioita, kuten lukee viikon päästä julkaistavaa pörssitiedotetta…

Takaovesta takaisin juhliin

Siltä varalta että haitake-tili huomataan, se luo takaoven ympäristöön muuttamalla vaikkapa jonkin websivun koodia, tehden sinne “koodausvirheen”. Koodausvirhe mahdollistaa verkkopalvelimen haltuunoton ilman uutta 0-päivähyökkäystä. Monessakaan ympäristössä ei valvota webpalvelimien sivujen lähdekoodia tuotannossa, varsinkin,  jos muutos tehdään valmisohjelman koodiin. On sanomattakin selvää, että AV-tuotteet eivät katselmoi verkkosivun koodia.

Data lähetetään ulos salasanasuojattuna dokumenttina, kuvana, kryptattuna, ftp:llä tai selaimella.

Nyt joku älähtää, että moinen on kiellettyä tai ainakin valvottua toimistoverkossa.

CxO:t, asiantuntijat sekä pääkäyttäjät tuppaavat kantamaan koneensa kotiin, jossa tuskin valvotaan liikennettä tuolla tasolla, työaseman turvavälineet on tässä kohtaa jo sokeutettu, joten taustalla oleva selain puhaltanee lastia johonkin uuteen, kaukaiseen kotiin viimeistään silloin.

Yllä olevalla esimerkillä on tarkoitus kuvata sitä, että muokkaamalla ympäristöä “normaalisti”, joskin pahantahtoisella tavalla, päästää ohi nykyisistä puolustuksista.

Asetusten, muutosten ja muutostapahtumatietojen monitorointi ja ymmärtäminen tulee nousemaan arvoon tässä vaiheessa.

1.0 on passé

Nyt alkaa olla viimeinen aika siirtää antiikkinen, tilan pitävä, perus palomuuri joko eläkkeelle tai laittaa sen hyväksi kaveriksi web2.0-verkon tietoturvaa ymmärtävä ratkaisu. Pikavoittoja saat toteuttamalla ainakin Quick Winit 20 Critical Security Controls – Version 3.0 dokumentista

http://www.sans.org/critical-security-controls/guidelines.php

Jussi Perälämpi on Trusteqin Security Practice Lead, jolla on yli kymmenen vuoden kokemus mm. tietoturva-arkkitehtuurista, hardenoinnista ja tietoturva-automaatiosta.

Seuraa Jussia Twitterissä: @JussiPeralampi

Datan saattajana toimi ex-työntekijä, ilmankos se Jeppe vihelteli mennessään.

Talouselämän artikkelissa kerrotaan melkoisen lohduttomasta tilanteesta, jossa tietoinfrastruktuurin ylläpitäjät sekä käyttäjät eivät koe hirmuista pistosta rinnassaan viedessään dataa ulos luvatta. Tilanteena voi olla duunarin oma päätös siirtyä toisaalle tai odotettavissa oleva irtisanominen. Molemmissa tapauksissa tekijällä saattaa olla runsaastikin aikaa suunnitella ja toteuttaa uraa tai omaa taloutta edistävä ”varmuuskopioiminen”.

Se Jeppe ohitti DLP:n 

Näissä tilanteissa ensimmäinen askel tuntuu olevan aina tekninen ratkaisu, esimerkiksi  tahallisten ja tahattomien tietovuotojen ehkäisyyn tarkoitettu Data Loss Prevention (DLP) -järjestelmä.

Mutta jos ja kun tekijällä on aikaa ja oikeudet käyttää tietojärjestelmiä normaalisti, hän kerkiää hyvin työtehtäviin liittyen haalimaan oleellista dataa talteen. Tekijä saattaa myös olla teknisesti niin taitava että hän pystyy ohittamaan tekniset suojaukset. Varastettavan tiedon voi salata, sen muotoa voidaan muuttaa, tai se voidaan pyöräyttää ulos sellaisen järjestelmän kautta, jossa ei ole DLP-tukea. Lisäksi hakukoneet auttavat, jos mielikuvitus ja osaaminen loppuvat mutta tahto säilyy. DLP ei siis ole välttämättä riittävä ratkaisu pahan sisäpiiriläisen varalle.

Dokumenttikohtaiset oikeudet

Jos itselläni olisi suojattavaa dataa, pyrkisin ratkaisuun, jossa data olisi salattua ja johon pitäisi erikseen määritellä ketkä voisivat sitä käyttää ja miten. Määrittely voi olla esim. ”kaikki firman työntekijät”, myyjät, Jory sekä Hallitus. Tärkeässä dokumentissa voi olla estetty printtaaminen ja sen saa auki vain määrätty ryhmä käyttäjiä. Ratkaisun pitäisi tukea sähköpostia sekä yleisimpiä toimistosovelluksia. Kun varas vie datan eikä ole enää firman palveluksessa, hänen käyttöoikeudet poistetaan ja samalla käyttäjä menettää oikeudet dokumenttiin. Tuloksena on, että hänellä on dokumentteja, jotka ovat salattuja “Lorem ipsum dolor sit amet, consectetur”, josta ei juuri ole iloa ellei osaa vahvasti salattua tietokoneajan munkkilatinaa. Esimerkkinä edellämainitusta tekniikasta on Microsoftin Active Directory Rights Management Services (AD RMS). Se toimii melkoisen hyvin toimiston peruskäyttäjien kanssa mutta pahoilla pääkäyttäjillä on omat pääsykeinonsa dataan. On varmuuskopioita, tietokantadumppeja, oikeuksien väärinkäyttöä, huijaamista sekä lukematon kasa muita likaisia temppuja.

Tietokoneen pitää valvoa lokeja

Pääkäyttäjiin tehoaa edellämainittujen lisäksi esimerkiksi työtehtävien kierrättäminen, ”separation of duties”, ja lokien seuranta. Työtehtävien kierrättäminen on vanha tietoturvakäytäntö, jossa yhdessä tehtävässä ollaan vain rajoitetun ajan, jotta ei kerkiä alkaa epärehelliseksi. Nykyresursseilla tämä tosin on hieman haastavaa – ainakin IT -osastolla, joista harvoin löytyy useampaa ”kaikkien alojen asiantuntijaa”.

Separation of duties tarkoittaa sitä, että eri tehtäviä jaetaan niin, että itse ei voi valvoa omaa toimintaansa. Pääkäyttäjillä saattaa olla täydet oikeudet esim. intranetiin tai jopa koko ympäristöön mutta lokien seuranta on hänen ulottumattomissaan ja lokiin jää merkintä, jos joku on alkanut ”luovaksi”. Nyt haasteeksi saattaa nousta työntekijöiden vähyys, joka voidaan ratkaista ulkoistamalla valvonta.

Näppärä pääkäyttäjä voi aiheuttaa tulvan tapahtumia lokeihin ja tehdä kolttosensa lokisumun takana, jos lokeja nyt muka joku ihminen sattuisi katsomaan. Ihminen ei kuitenkaan pysty seuraamaan ympäristön tapahtumia ilman hyvää lokien ja tietoturvatapahtumien analysointiohjelmistoa. Siksi tietokoneen pitää valvoa lokeja. Tällaiset ratkaisut tunnetaan yleensä nimikkeellä Security and Information Event Management (SIEM).

Mutta miksi Jeppe vei datan?

Edelläkuvattu on tekniikkaa ja käyttöönotto vaatii suunnittelua, kartoituksia ja hieman sitoutumista. Mutta miksi Jeppe vei datan? Valitettavasti Internetin laajasta tietoturvalaitteiden ja teorioiden kirjosta ei ole löytynyt Layer8 -tuotetta, jolla Jeppe voitaisiin luodata. Ratkaisua odotellessa pitänee tyytyä tietoturvaosaamiseen ja -tekniikkaan.

__

Jussi Perälämpi on Trusteqin Security Practice Lead, jolla on yli kymmenen vuoden kokemus mm. tietoturva-arkkitehtuurista, hardenoinnista ja tietoturva-automaatiosta.

Seuraa Jussia Twitterissä: @JussiPeralampi

Miten tämä sitten olisi voitu estää? Valitettava tosiasia on, että harvoin tietoturvallisuuden puutteisiin reagoidaan ennen kuin on liian myöhäistä. Jos tietoturvamielessä heikkoon järjestelmään olisi suoritettu puolueeton auditointi, näin ei olisi päässyt tapahtumaan.

Miten sitten kriittiset järjestelmät tulisi suojata uhkia vastaan? Ratkaisuja on useita, niin myös niistä syntyviä tapahtumia eli lokeja. Jokainen järjestelmä tuottaa lokeja omalla tavalla ja kielellään. Kymmenien järjestelmien valvominen on erittäin aikaa vievää ja hankalaa.

Security Information and Event Management (SIEM) mahdollistaa alustariippumattoman tavan kerätä eri järjestelmistä tapahtumat sekä yhdistää ne yhden järjestelmän alle, jolla saadaan valvottua kaikkia verkon komponentteja reaaliaikaisesti sekä vaivattomasti. Epäilyttävistä toiminnoista verkossa järjestelmä voidaan asettaa lähettämään hälytyksen ylläpidolle, jolloin vahinko ei vielä välttämättä ole päässyt tapahtumaan.

Selvennettäköön, että SIEM ei ole tuote, SIEM on ratkaisu. Markkinoilla on olemassa hyviä työkaluja SIEM:n käyttöönottoon, mutta ilman sopivaa tarvetta ja sitoutumista prosessiin SIEM:in ominaisuudet jäävät auttamattomasti hyödyntämättä.  Ainoastaan hyvin suunniteltuna SIEM toimii organisaation tietoturvaprosessia tukevana ratkaisuna.

Syvennytään SIEM:n maailmaan myöhemmissä blogikirjoituksissa.