Blogi

Yleisimpiä kysymyksiä ja vastauksia tietovuodoista

Viimeaikaiset tietovuodot ovat herättäneet paljon keskustelua ja kysymyksiä. Trusteq listasi alle muutamia yleisimpiä kysymyksiä ja keräsi niihin vastaukset.
Q: Miten palveluntarjoajan tulisi suojata asiakastiedot?

A: Suojaus tulee olla suhteutettu kerätyn tietoon & määrään. Kaikkien tulee kuitenkin vähintään:

1. Skannata järjestelmät säännöllisesti heikkouksien huomaamiseksi (vulnerability scanning)

2. Pitää järjestelmäpäivitykset ajantasalla

3. Koventaa järjestelmä. Esim. poista kaikki turhat oletustunnukset ja palvelut.

4. Monitoroida käyttäjien ja järjestelmien tapahtumia

5. Kouluttaa henkilöstöä.

 

Q: Miten palveluntarjoaja voi havaita hyökkäyksen?

A: Tässä järjestelmän seurannalla on avainrooli.

1. Seuraa järjestelmän käyttölokeja ja liikenneprofiilia

2. Analysoi muutoksia järjestelmäkonfiguuratioissa tai asennuksissa

3. Pyydä palveluntarjoajaa katsomaan, havaitseko hän jotain poikkeuksellista

4. Aja haitakeskannaukset järjestelmällesi (internal virus/malware scanning)

5. Viritä ‘hunajapurkki’ palvelimelle ja monitoroi sitä. Hunajapurkki on houkutteleva kohde hyökkääjälle (esim. passwords.txt           tai creditcard.db), mutta ei sisällä käytettävää tietoa. Hyökkääjä kuitenkin kiinnostuu tästä.

 

Q: Miten kotikäyttäjät voivat suojata tietonsa?

A: Kotikäyttäjien suojauksessa on kaksi osaa: 1. kotikone ja 2. käytetyt palvelut

Kotikoneelle oleellista on virustorjunnan, henkilökohtaisen palomuurin ja käyttöjärjestelmän päivitysten pitäminen ajantasalla. Palveluiden valinnassa kannataa aina miettiä, mitä tietoja ja mihin tarkoitukseen tulee antaa. Nämä selviävät usein rekisteriselosteesta ja arkaluontoiset tiedot (kuten salasana) tulisi aina siirtää suojatun yhteyden yli.

 

Q: Mitä kotikäyttäjät voivat tehdä tietovuodoissa?

A: Hyvin vähän. Tämä on palveluntarjoajan vastuulla.

 

Q: Auttaako vahva salasana tietovuodossa?

A: Tietovuodot aiheutuvat yleensä palveluntarjoajan virheestä. Tällöin asiakkaan salasanasuojaus kierretään, joten hyväkään asiakkaan salasana ei auta tässä.

 

Q: Tarviiko kuluttajien välittää salasanan vahvuudesta?

A: Kyllä. Vahva salasana ehkäisee tunnuksien väärinkäyttöä. Käyttäjätunnus/salasana vaihtoehdosta tulisi kuitenkin siirtymään kehittyneempiin järjestelmiin esimerkiksi kertakäyttösalasanoihin tai federoituun identiteettiin. Eritysesti federoitu identiteetti on kuluttajille läpinäkyvä vaihtoehto ja vähentää tarvittavien käyttäjätunnuksien ja salasanojen määrää.

 

Q: Mitä federaatio tarkoittaa?

A: Federaatio tarkoittaa, että sallitaan esim. Googlen tunnuksen käyttö muihin kuin Googlen palveluihin. Tällöin salasana tarvitaan vain Google-tunnuksen käyttöön. Toista salana-/käyttäjätunnusparia ei tarvita.

___

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

 

Pörssiyritykselle julistettu sota verkossa – puolustus “Malli Cajander”?

Anonymous Finland on julistanut sodan Talvivaara Oyj:lle sen tavasta hoitaa kaivoksensa ympäristövaikutuksia.

Itse sodan julistus löytyy http://pastebin.com/j5Syj8aB linkin takaa. Ottamatta enempää kantaa syihin, motiiveihin tai resursseihin kummaltakaan puolelta, maalaa tämä näkymää korporaatioiden ja aktivistien lähitulevaisuuteen.

Hyökkääjät käyttävät sissitaktiikkaa väijymällä aktiivisesti nettinäreen juurella etsien huoletonta korporaatiokulkijaa. Voin melkein kuulla äänen sanovan,
Upseer ies. Mis häne pääsä varjo ossuup tuon piene närree kohal, nii sillo hänel tullooki noutaja.

Kuinka mahtaa olla puolustaja valmistautunut tähän sotaan?
Onko tarjota vain kivääri, kokardi ja vyö?

Jonkusen vuoden olen katsellut sekä kuunnellut eri firmojen ja yhteisöjen tietouhkiin valmistautumista ja Wikipediasta löytyi teksti, jolla voi kuvata tilannetta, näin sodan näkökulmasta:

” Kesäkuussa 1939, puoli vuotta ennen talvisodan syttymistä, Cajander ilmoitti tyytyväisyytensä siitä, että Suomen armeijan hankintoja oli osittain lykätty myöhemmäksi, ja että näin säästettäisiin valtion varoja, koska ei ollut ostettu liian aikaisin varusteita, jotka olisivat kuitenkin sodan sattuessa jo vanhentuneita ja osittain käyttökelvottomia. ” Lähde: Wikipedia (http://fi.wikipedia.org/wiki/Malli_Cajander)

Puolustamista ei ehkä kannata aloittaa ostamalla Hornetteja, kuljetushelikoptereita tai kuolontähteä.
Tarkasta omat joukkosi CAG:ta (Consensus Audit Guidelines) vasten ja panosta todelliseen tarpeeseen.

 

Vuosi on nyt 2011, johtaako teillä Cajander?

__

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

 


Suomen suurin tietovuoto

 

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.

Asiakastiedon käyttö ja suojaus

Asiakastieto (kuluttajien esim. verkkopalvelun kautta antamat tiedot tai yrityksen asiakkaalta keräämä tieto) on monelle yritykselle liiketoimintakriittistä tietoa: tiedon tehokas käyttö mahdollistaa entistä tehokkaamman asiakaskontaktoinnin ja -profiloinnin. Tämä asettaa tietoturvapäällikön haastavaan tilanteeseen, kun tieto tulee suojata riittävän hyvin. Samaan aikaan asiaa koskeva lainsäädäntö on kiristymässä niin Euroopassa kuin Yhdysvalloissa lukuisten tietovuotojen ja väärinkäytösten takia.


Rekisteriseloste avainasemassa

Tyypillinen asiakastiedon käytön kehittämisprojekti alkaa kanta-asiakasohjelmien, asiakaspalvelun ja verkkosivujen kautta kerätyn tiedon kartoittamisella. Kerättyjen tietojen yksityiskohdat, käyttötarkoitukset, luovuttaminen ja suojauksen pääperiaatteet tulee dokumentoida rekisteriselosteessa.

Seuraavassa vaiheessa määritetään ja kuvataan nykyiset ja mahdolliset tulevat käyttötapaukset. Rekisteriseloste on avainasemassa asiakasviestinnässä, ja se tulee pitää ajan tasalla. Siitä voidaan kuitenkin rajata pois esimerkiksi oleellisia tiedonkäyttötapauksia, koska asiakastietoja saa käyttää vain rekisteriselosteen mukaisesti.


Kontrolli tiedon luottamuksellisuuden mukaan

Kun asiakastiedot ja niiden käyttö on inventoitu, voidaan aloittaa tietojen suojauksen suunnittelu. Henkilötietolain mukaan asiakastiedot tulee suojata tarvittavilla toimenpiteillä asiattoman pääsyn estämiseksi ja mm. luvatonta luovuttamista vastaan.

Tarvittavien toimenpiteiden määrittely on usein vaikeaa, mutta suojauksen toteuttamiseksi on olemassa useita hyviksi todettuja ratkaisuja. Toimiva identiteetin ja pääsynhallinnan ratkaisu (IAM) on avainasemassa suojauksen suunnittelussa, koska pääsyä asiakastietoon tulee rajoittaa monella eri tasolla (need-to-know -periaate) ja esimerkiksi tiedon käyttöä pitää pystyä seuraamaan ja auditoimaan jälkeenpäin. Pelkkä IAM-järjestelmä ei ole kuitenkaan riittävä väline tarpeellisten toimenpiteiden toteuttamiseksi, vaan erilaisia todennus-, suojaus- ja muita ratkaisuja tulee ottaa käyttöön tiedon määrän mukaan.

 

         ”Perussääntö on, että mitä enemmän ja mitä luottamuksellisempaa tietoa käsitellään, sitä enemmän kontrolleja tarpeellinen suojaus vaatii.

 

Suurissa asiakastietokannoissa kehittyneet ratkaisut, kuten data loss prevention (DLP) ja audit trail, edellyttävät konfiguraation ja haavoittuvuuden seurantaa. Näiden ratkaisujen käyttöönotossa tulee ottaa huomioon organisaation vaatimukset ja muut ympäristöön vaikuttavat tekijät. Tärkeää on kuitenkin määrittää nykyiset kontrollit ja suunnitelma niiden kehittämiseksi.

Viimeisenä vaiheena on vaatimustenmukaisuuden ja kontrollien mittaaminen, joka mahdollistaa myös suojauksen jatkuvan kehittämisen. Erilaiset GRC-tuotteet (governance, risk & compliance) ovat erittäin arvokkaita tässä vaiheessa, koska ne tarjoavat reaaliaikaisen näkymän kontrolleihin ja eliminoivat manuaalisia vaiheita, kuten esimerkiksi itsearviointilomakkeiden ja tarkistuslistojen käsittelyn.

Asiakastiedot ovat yrityksellesi erittäin tärkeää ja arvokasta pääomaa. Pidä siis huolta niiden asianmukaisesta suojaamisesta ja käytön tehokkaasta suunnittelusta.

—–

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


 

APT 2.0

Tietojärjestelmiä vastaan on hyökätty vuosikymmenien saatossa monin eri tavoin. Viruksia, matoja, troijalaisia, brute force, root kitit – ihan noin alkuun pääsemiseksi. Suojaksi on pystytetty palomuureja, antimalware-tuotteita, parannettu ympäristön päivittämistä sekä hardenointiakin on tehty, ja nyt uhkakartalla pyörii Advanced Persistent Threat aka APT. Viime aikoina useassa bloki-kirjoituksissa (1,2,3)on painittu eri hyökkäyksien kanssa ja siitä, ovatko ne olleet oikeita APT-hyökkäyksiä.

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