TigerTeam - suomalainen tietoturvablogi

Organisaatiot, jotka ovat tilanneet PCI DSS -tarkastuksia muutamia vuosia sitten, ovat oletettavasti saaneet tarkastukset silloin edullisemmalla hinnalla kuin nykyisin. Tarkastukset olivat silloin myös kevyempiä ja kestivät lyhyemmän ajan. Mikä siis on muuttunut muutamassa vuodessa?

Suurin syy nykyisten tarkastusten raskauteen johtuu kansainvälisen PCI-toimielimen (PCI Security Standars Council, jatkossa PCI Council) tarkentuneista raportointivaatimuksista. Kun aikaisemmin tarkastaja (QSA, Qualified Security Assessor) saattoi kirjata, että vaatimus on kunnossa ja perustella asiaa muutamalla sanalla, tulee tarkastajan nykyisin noudattaa hyvinkin yksityiskohtaista raportointiohjetta. Raportointiohjeessa on purettu auki jokainen vaatimus, ja kerrottu tuleeko kyseisen vaatimuksen kohdalla:

• tarkastaa järjestelmän asetukset

• tarkastaa dokumentaatio

• haastatella henkilöstöä

• havainnoida prosessien toimivuutta

• valita otos

Kun huomioidaan, että PCI-tietoturvastandardissa on yli 200 vaatimusta, muodostuu itse raportoinnista hyvin suuri työ. Tämä näkyy myös raporttien pituuksissa: ennen selvittiin alle sadan sivun tarkastusraporteilla (ROC), nyt tyypillinen raportti on yli 200 sivua pitkä.

Raportointiohjeen ensimmäinen versio, ns. Scoring Matrix, ilmestyi toissa vuonna ja oli tarkoitettu PCI DSS -standardin 1.2-version pisteytykseen. Nimensä mukaisesti kyseinen ohje kertoi vain miten PCI Council pisteyttää raportit, mutta ei juurikaan ohjeistanut QSA-yrityksiä siitä miten varsinainen raportointi tulee tehdä.

Myös tarkastusraporteista tarkempi ohjeistus

Huhtikuussa PCI Council julkaisi ensimmäisen version ohjeesta PCI DSS 2.0 ROC Reporting Instructions. Perusidea on sama kuin em. Scoring Matrix -ohjeessa, mutta pelkän pisteytyksen lisäksi ohje sisältää yksityiskohtaista tietoa siitä, mitä jokaiseen ”In Place” -kohtaan tulee kirjata. Raportointiohje tullee kaikkien saataville myöhemmin tänä syksynä.

Tarkastusten kohteena olevat yritykset voivat myös hyötyä tästä ohjeesta, sillä katsomalla vaatimuksiin liitettyjä neuvoja voi helposti päätellä mitä tarkastaja odottaa näkevänsä kunkin vaatimuksen kohdalla.

Raportointiohje on suoraan sidoksissa PCI Councilin laadunvarmistusohjelman kanssa. PCI Council tarkastaa säännöllisesti, että QSA-yritykset noudattavat sen asettamia määräyksiä toiminnassaan. Tarkastukset voivat liittyä QSA-yrityksen vakuutuksiin, politiikkoihin ja ohjeisiin, mutta myös tarkastusraportteihin.

Raporttien tarkastus tapahtuu siten, että PCI Council pyytää QSA-yritykseltä kaikki raportit tietyltä ajanjaksolta, esimerkiksi kuluvan vuoden kolmas kvartaali (Q3/2011). Ennen raporttien lähettämistä QSA-yritys sanitoi raportit siten, että asiakkaan nimi, osoite, IP-osoitteet ja muu yksilöivä tieto poistetaan. PCI Council käy tämän jälkeen raportit läpi ja tekee sille pisteytyksen. Mikäli raportissa on merkittäviä puutteita, joutuu QSA-yritys ns. remediation-tilaan. Samalla QSA-yrityksen nimi merkitään punaisella QSA-luettelossa. Listaa säännöllisesti seuraavat tietävät, että usea maineikaskin yritys on ollut ko. tilassa jossain vaiheessa QSA-uraansa.

Mitä tämä tarkoittaa asiakkaan kannalta

QSA-yritykset pyrkivät tietysti välttämään joutumasta remediation-tilaan ja ennen kaikkea pääsemään nopeasti pois kyseisestä tilasta. Nixun saamien tietojen mukaan osa QSA-yrityksistä on joutunut jopa kaksinkertaistamaan tarkastuksiin menevän työmäärän täyttääkseen raportointivaatimukset ja sitä kautta saadakseen nimensä pois tuolta “punaiselta listalta”.

Osa tarkastettavista kohteista on kommentoinut, että tarkastusten hintojen korotuksien lisäksi tarkastuksiin vaadittava työmäärä asiakkaan puolella on lisääntynyt kohtuuttomasti. Pahimmillaan tämä on tarkoittanut sitä, että tarkastaja on paikalla asiakkaan tiloissa yhtäjaksoisesti kahdesta kolmeen viikkoon ja varaa ison osan asiakkaan henkilöstöä palavereihin. Tarkastajan on käytävä jokainen standardin kohta läpi numerojärjestyksessä kunnes kaikki yli 200 vaatimusta on käsitelty.

Nixun näkemyksen mukaan raportointivaatimuksien kiristymisen ja sitä kautta kokonaistyömäärän nousun ei pidä suoraan näkyä asiakkaan työmäärissä. Tarkastuksien huolellinen suunnittelu takaa sen, että asiakkaan henkilökuntaa tarvitsee häiritä mahdollisimman vähän ja tarkastus saadaan vietyä nopeasti läpi. Suuri osa työstä on kuitenkin sellaista, jonka QSA voi suorittaa omassa toimistossaan asiakasta häiritsemättä, kuten dokumenttien katselmointi ja raportointi.

Päivitys 15.9.: Tarkentuneista vaatimuksista on myös hyötyä asiakkaille, sillä ne takaavat omalta osaltaan että QSA-yritysten tuottamat auditointipalvelut täyttävät palveluille asetetut kriteerit. Lisäksi ne pakottavat tarkastajan toimimaan riittävällä tarkkuudella, jolloin saadaan parempi varmuus kontrollien toimivuudesta. PCI Councilin mukaan osa yrityksistä luopui vapaaehtoisesti QSA-toiminnastaan uusien raportointivaatimuksien lanseerauksen ja niiden valvomisen alettua. Mikäli yritys ei vapaaehtoisesti luovu QSA-toiminnastaan mutta ei myöskään ole halukas tai kykenevä noudattamaan PCI Councilin asettamia laatuvaatimuksia, voi seurauksena olla ns. revocation, eli QSA-statuksen menetys, kuten eräälle yritykselle äskettäin kävi.

Nixu on ollut aikaisemmin mainitun PCI Councilin rutiinitarkastusten kohteena muutamaan otteeseen. Kuten tarkastuksissa yleensäkin, jotain huomautettavaa on löytynyt, mutta varsinaisessa remediation-tilassa Nixu ei ole ollut.

Monelle kauppiaalle helpoin tapa saavuttaa PCI DSS -yhdenmukaisuus on siirtyminen päästä päähän salaaviin maksupäätteisiin. Oikein valituin tuottein ja integrointiratkaisuin PCI DSS -laajuus jää tällöin maksupäätteisiin ja kauppiasta koskee enää vain muutama PCI DSS -vaatimus.

Julkaisimme mm. päästä päähän salaavan maksupääteratkaisun hyötyjä käsittelevän suomenkielisen white paperin joulukuussa.

Usein maksupääteratkaisu rakennetaan entisen magneettijuovakortteja lukevan ratkaisun tilalle. Vanha ratkaisu on saattanut tallentaa eri järjestelmiin tuhansia maksukorttitietoja – näistä tiedoista iso osa voi olla uratietoja, joita PCI DSS:n mukaan ei saa tallentaa laisinkaan. Syy siihen, että uratietoja on tallennettu on aikaisemmissa ohjeissa, jotka edellyttivät tätä. Lisäksi kauppiaalle on saattanut syntyä mittava kuittivarasto sellaisista kuiteista, joissa koko korttinumero näkyy.

Jotta kauppias saavuttaisi PCI DSS -yhdenmukaisuuden, kaikki vanha maksukorttitieto tulee joko poistaa tai tallentaa asiallisesti. Magneettisella medialla oleva uratieto pitää tuhota ja tallennetut korttinumerot tulee joko tuhota tai salata. Kauppiaskuiteilla olevat korttinumerot tulee osittain säilyttää ja osittain tuhota.

Kirjanpitolaki ei edellytä korttimaksutapahtuman kauppiaskuitin säilyttämistä, jos ostotapahtumasta on jokin muu luotettava tosite. Maksupalvelulaki edellyttää korttimaksutapahtuman kauppiaskuitin säilytystä 18 kuukauden ajan.

PCI-standardi ottaa kantaa kuittien käsittelyyn

Korttinumerollisia kuitteja koskevat useat PCI DSS -vaatimukset:

• Kuitit tulee säilyttää fyysisesti suojattuina

• Kuitit on inventoitava säännöllisesti

• Tarpeettomat kuitit tulee tuhota

Tälle kaikelle tulee laatia prosessit ja lisäksi vielä ongelmatilanteita – kuten kuittien katoamista varten – tulee laatia omat prosessinsa.

Koska uudet päästä päähän salaavat maksupäätteet eivät tulosta kauppiaskuitille koko korttinumeroa, PCI DSS:n alaisten kuittien määrä vähenee jatkuvasti ja putoaa nollaan 18 kuukauden kuluttua maksupäätteiden käyttöönoton jälkeen.

Kassat ja kassapalvelimet sisältävät lähes varmasti sekä uratietoa että korttinumeroita. Hyvin useat kassaratkaisut ovat tallentaneet koko elinkaarensa ajan kaikki lukemansa korttitiedot levylle ja sieltä löytyvä korttitiedon määrä voi olla hyvinkin merkittävä. Ura- ja korttitietoa löytyy tietokannoista, tilapäistiedostoista, lokitiedostoista, debug-tiedostoista sekä varaamattomasta tilasta levyn pinnalta.

Hyvin usein varmin ja edullisin ratkaisu vanhan korttitiedon poistamiselle on levyjen päällekirjoitus joko kaupallisella tuotteella (esim. Blancco) tai open source -tuotteella (esim. DBAN).

Mikäli levyjä ei ole mahdollista tyhjentää kokonaan, levyllä oleva ura- ja korttitieto tuleekin löytää ja sille tulee laatia käsittelysuunnitelma. Useimmiten suunnitelmaksi riittää tiedon tuhoaminen, mutta joskus tallennetut korttinumerot täytyy liiketoimintasyistä säilyttää. Mikäli korttinumeroita säilytetään, ne tulee salata.

Väärät hälytykset korttinumerometsästyksessä yleisiä

Ura- ja korttitiedon löytäminen on haasteellinen tehtävä. Korttinumero on säännöllisen muotoinen ja siinä on Luhn-algoritmiin pohjautuva tarkistussumma, joten päältä katsoen löytämisessä ei pitäisi olla mitään ongelmia. Osittain näin onkin eli työkalut, jotka etsivät levyltä ja tiedostojärjestelmistä säännöllisillä lausekkeilla (regular expression) korttitietoja, löytävät kyllä kaikki korttitiedot, mutta mukana tulee hyvin usein samanmoinen tai jopa isompi saalis vääriä positiivisia. Löydökset vaativatkin runsaasti jatkokäsittelyä, jotta voidaan varmistua siitä, että kyseessä on todellinen korttinumero tai uratieto.

Aitojen löydösten perusteella voidaan laatia poistosuunnitelma, johon tulee kuulua poistetavan tiedon päällekirjoitus jollain ohjelmalla. Suunnitelma tulee testata ja testauksen yhteydessä levyltä tulee etsiä uudelleen korttitieto. Mikäli mitään ei enää löytynyt, suunnitelman mukaiset toimenpiteet voidaan tehdä kaikille puhdistettaville järjestelmille.

Kassojen ja kassapalvelinten varmistusnauhat (tai muut varmistusmediat) sisältävät pääsääntöisesti samat tiedot kuin varmistetut laitteet. Varmistusmediat on syytä tuhota, jos se vain on mahdollista. Mikäli lainsäädäntö tai liiketoimintasyyt pakottavat varmistusmedian säilytykseen säilytysprosessista ei ole mitenkään mahdollista saada PCI DSS:n mukaiseksi. Tällaisessa tapauksessa säilytystä varten on laadittava kompensoiva menettely. Tyypillisesti kompensoiva menettely on varmistusmedian säilytyksen korkea fyysinen turvallisuus.

Luottokorttiyhtiöiden laatima tietoturvastandardi PCI DSS koskee kaikkia korttimaksuja vastaanottavia yrityksiä. Yritykset tulevat standardin piiriin sopimustensa kautta. Tyypillisesti kauppias tekee sopimuksen maksun vastaanottajan (acquirer) kanssa ja sitoutuu tässä sopimuksessa sekä noudattamaan kyseistä standardia että korvaamaan vahingot, mikäli kauppiaan järjestelmistä anastetaan maksukorttinumeroita.

PCI DSS -standardin vaatimukset koskevat kaikkia järjestelmiä, jotka on kytketty samaan lähiverkkoon kuin laite, joka käsittelee varsinaiset maksukorttitapahtumat.

Hyvin usein näihin kuuluvat myymälän vaa’at, turvakamerat ja pullonpalautuslaitteet.

PCI DSS -standardin vaatimusten toteuttamisen kustannukset pienessäkin vähittäiskaupassa saattavat nousta kymmeniin tuhansiin euroihin.

Standardin vaatimusten täyttämisestä syntyviä kustannuksia voi vähentää merkittävästi ottamalla käyttöön maksupääte, joka salaa maksukorttiliikenteen päästä päähän. Tällaisen maksupäätteen käyttöönotto siirtää sopimusteitse suuren osan PCI DSS -vaatimuksista maksupäätetoimittajan vastuulle ja tietyin edellytyksin poistaa kassan ja kassalähiverkon standardin vaikutusalueen ulkopuolelle.

Nixun uusi julkaisu Maksupäätteet ja PCI DSS käsittelee asioita joita maksupäätteeltä ja palveluntarjoajalta edellytetään, jotta kauppiaan PCI DSS -vastuut voidaan siirtää suurelta osin maksupäätetoimittajalle.

Muita PCI-stardardin aihepiiriin kuuluvia blogikirjoituksiamme voit lukea tästä.

PCI DSS -standardista on julkaistu eilen versio 2.0. Versio korvaa tämän kansainvälisten korttiyhtiöiden ylläpitämä maksukorttialan turvallisuusstandardin edellisen version 1.2 sekä viime vuonna julkaistun v1.2.1-korjauspäivityksen. Uuden version käyttö on pakollista vuoden 2012 alusta ja sitä saa käyttää vuonna 2011 tehtävissä tarkastuksissa. Standardi tulee olemaan voimassa kolme vuotta entisen kahden vuoden sijaan.

PCI DSS -standardin pääversionumeron kasvattaminen tuntuu ensisilmäyksellä liioittelulta: standardiin on tullut vain kaksi sellaista muutosta, jotka muutoslokissa luokitellaan termillä “evolving requirement” eli aito muutos vaatimukseen. Tarkempi tarkastelu kuitenkin osoittaa, ettei 2.0 ole liikaa, koska useat “tarkennukset” saattavat vaikuttaa hyvinkin merkittävästi sekä teknisesti että taloudellisesti.

Esimerkki mitättömän oloisesta muutoksesta, jolla kuitenkin voi olla suuria vaikutuksia. on vaatimus testi- ja tuotantoympäristöjen tehtävien erottamisesta. Aikaisemmassa standardiversiossa vaatimus oli 6.3.3 ohjelmistokehityksen alla. Uudessa standardissa vaatimus on täsmälleen samoilla sanoilla numerolla 6.4.2, mutta nyt se on muutostenhallinnan alla.

Vanhan standardin puitteissa oli mahdollista tulkita, että eriyttäminen koski vain ohjelmistokehitystä. Täällä Nixussa ei oltu tällaista tulkintaa tehty. Nyt tällaista mahdollisuutta tulkinnaksi ei enää laisinkaan ole ja vaatimus koskee kategorisesti testi- ja tuotantoympäristöjen henkilöstöä.

Nixu on laatinut yhteenvedon uuden standardiversion muutosten vaikutuksista. Yhdeksänsivuinen dokumentti on saatavissa PDF-muodossa Julkaisut-sivultamme.

Myös PA DSS (Payment Application Data Security Standard) eli maksusovelluksien turvallisuudelle asetettavat standardit määrittelevä dokumentti on päivittynyt versioon 2.0. Myös tässä standardissa on kaksi muutosta, jotka kuuluvat PCI-toimielimen mukaan luokkaan “evolving requirement”. Nämä muutokset ovat vaatimus keskitetyn lokituksen tuelle sekä vaatimus haavoittuvuuksien luokittelusta riskipohjaisesti. Muita näkyvimpiä muutoksia on se, että aiemman standardin PCI DSS -viittaukset on korvattu muokatuilla vaatimuksilla varsinaisessa PA DSS -tekstissä.

Kansainvälinen PCI-toimielin PCI Council on julkaissut tiedot ensimmäisistä muutoksista lähiaikoina päivittyviin PCI DSS - ja PA-DSS -standardeihin. Dokumentti Summary of Changes - Hihglights löytyy pdf-muodossa täältä. Dokumentin tarkoituksena on auttaa eri osapuolia valmistautumaan uuteen standardiin, joka samalla syrjäyttää nykyisen 1.2-version.

Samalla kun uusi standardi julkaistaan 28. lokakuuta astuu voimaan myös uudistunut elinkaari PCI-standardeille. Nykyisen kahden vuoden sijaista elinkaari pitenee kolmeen vuoteen. Mallin mukaan uusi standardi julkaistaan lokakuussa, se astuu voimaan ensi tammikuussa ja seuraava versio julkaistaan vuonna 2013. Tällä välin toimielin implementoi uuden standardin, ottaa vastaan palautetta sekä kehittää uutta standardia.

Uuden standardin muutokset näyttäisivät olevan suoraviivaisia eikä mitään kovin mullistavaa ole luvassa. Monessa tapauksessa muutokset liittyvät tarkennuksiin ja vaatimuksen tarkoituksen avaamiseen. Nixua ilahduttaa erityisesti tieto siitä, että PCI-ympäristön (scope) määrittelyyn on luvassa lisätietoa. Myös virtualisointiin on tulossa tarkennuksia. Standardi pyrkii myös lisäämään riskipohjaisen lähestymistavan käyttöä, ja siten antamaan organisaatiolle enemmän vaihtoehtoja vaatimusten toteuttamiseen.

Nixu seuraa tilannetta aktiivisesti ja kerromme prosessin etenemisestä tässä blogissa.

Mediassa on viime päivinä keskusteltu Suomen oloissa poikkeuksellisen laajasta maksukorttitietojen varkaudesta. Itähelsinkiläisestä kahvilasta on viety yli 100 000 korttitietoa. Mediassa olleiden tietojen mukaan tietomurto tehtiin etähallintaohjelman sekä vakoiluohjelman avulla. Lisäksi mainitaan, että syy olisi kassajärjestelmän asentaneen yhtiön päälle jättämä “oletusasetus”. Tietomurto paljastui Luottokunnan valvonnan ansiosta.

Oli vain ajan kysymys, milloin ensimmäinen suuri korttitietomurto tapahtuu Suomessa. Payment Card Industry Data Security Standard (PCI DSS) - implementointi on vielä hyvin monella kauppiaalla kesken, ja pienimmät kauppiaat eivät edes tiedä, että heidän tulisi noudattaa kyseistä tietoturvastandardia. PCI DSS:n noudattaminen olisi todennäköisesti estänyt tämänkin tietomurron:

PCI DSS edellyttää, että oletusasetuksia ei käytetä, etäyhteydet vaativat vahvan autentikoinnin ja virustorjuntaohjelmisto sekä tiedostojen eheysvalvontajärjestelmä hälyttävät haittaohjelmista. Lisäksi järjestelmien toimintaa tulee seurata päivittäin. Näin korttitietojen lähettäminen Yhdysvaltoihin ja Romaniaan paljastuisi omalla valvonnalla, eikä asia tulisi kauppiaalle “ihan puskista”.

On tietysti ymmärrettävää, että yksittäisellä kauppiaalla ei aina löydy riittävää tietotaitoa järjestelmien turvalliseen pystyttämiseen ja ylläpitoon. Tällöin kauppiaan tuleekin vaatia palveluntarjoajaltaan, että toiminta noudattaa vähintäänkin PCI-standardia. Lisäksi maksujärjestelmän tulisi olla Payment Application Data Security Standard -luokituksen mukainen eli PA-DSS-validoitu. Mahdollisissa tietomurtotapauksissa kauppiaan tulisi voida asettaa palveluntarjoaja vastuuseen, mikäli PCI-standardia ei ole noudatettu. Mikäli kauppias ei näin toimi, jää vastuu kauppiaalle ja seuraukset voivat olla hyvinkin ikäviä.

Niki Klaus vastaa Nixun PCI-liiketoiminnan kehittämisestä ja on tehnyt useita PCI-auditointeja Suomessa ja ulkomailla.