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.

Tietojärjestelmien suunnittelu on edelleen vaikeaa ja valitettavan usein suuret hankkeet epäonnistuvat tavoitteissa budjetin ja aikataulun osalta. Kiire ja puutteellinen suunnittelu aiheuttavat myös vakavia virhetilanteita, jotka puutteellisen testauksen takia havaitaan vasta tuotannossa. Kun ydintoiminnallisuudenkin toteuttaminen on näin vaikeaa, niin miten hyvin suunnittelussa on sitten otettu huomioon järjestelmien tietoturvavaatimukset?

Oma kokemukseni tietojärjestelmien tarkastuksista osoittaa, että tietoturvaa ei edelleenkään oteta riittävissä määrin huomioon suunnittelun alkuvaiheessa. Tietoturva on edelleen tarkistuspiste järjestelmien käyttöönoton yhteydessä.

“Onhan meidän järjestelmät turvallisia, koska meidän koodarit ovat tosi taitavia.”

Ja yleensä koodarit ovatkin taitavia, ongelmana on vain, että toteuttajat toteuttavat asiat määritysten mukaan. Suunnitteluvaiheessa tietoturvakontrolleja otetaan mukaan, silloin kun niitä otetaan, käyttäen apuna yleisesti tunnettuja hyviä käytäntöjä. Yleisesti hyviksi todettujen käytäntöjen hyödyntäminen ei välttämättä ole huono asia, mutta on hyvä muistaa, että ne ovat edelleen yleisiä, eikä kyseiselle järjestelmälle liiketoimintaperusteista johdettuja kontrolleja ja vaatimuksia. Usein lopputulos on, että arkkitehti tai suunnittelija tekee johtajien puolesta päätökset järjestelmälle hyväksytyistä riskeistä, ilman johtajien liiketoimintanäkemystä. Tietenkään johtajilta ei voi ottaa pois vastuuta, joten he joutuvat hyväksymään arkkitehdin näkemykset heidän kyvystään kantaa riskejä. Kuulostaako hyvältä?

Kuinka liiketoimintariskit saadaan prosessiin mukaan?

Kuinka olisi mahdollista kehittää tietojärjestelmät niin, että:

• Tietoturvariskit olisivat liiketoiminnalle selkeästi esitettävissä ja siten tietoisesti hyväksyttävissä

• Järjestelmien suunnittelussa otettaisiin alusta asti huomioon liiketoimintariskit

• Tietoturvakontrolleihin olisi selkeä liiketoiminnallinen tarve

• Liiketoiminnallinen tarve olisi mahdollista jäljittää toteutetussa lopullisessa tietojärjestelmässä tietoturvakontrolliin ja näin perustella sen olemassaolo

Vastauksen näihin haasteisiin tuo SABSA (Sherwood Applied Business Security Architecture). Se kehitettiin jo vuonna 1995, mutta ei ole vielä levinnyt laajalti ammattilaisten tietoisuuteen Suomessa tai Euroopassa yleensäkään. Yhdysvalloissa sekä Aasian ja Australian suunnalla yritykset ovat ottaneet SABSA:n hyvin vastaan ja osaksi organisaatioiden tietoarkkitehtuuristrategiaa. Esimerkiksi Iso-Britannian puolustusministeriö ja Kanadan hallitus ovat adoptoineet standardin kehitysmallikseen.

Suomessa järjestettiin elokuussa ensimmäinen SABSA Foundation -kurssi, johon myös allekirjoittanut osallistui. Kurssia oli yritetty järjestää jo kuutisen vuotta ja viimein se saatiin tänne – sekä vetäjäksi yksi mallin kehittäjistä, David Lynas. SABSA tarjoaa kolmiportaisen sertifiointiohjelman tietoturva-arkkitehdeille: Foundation (SCF), Practitioner (SCP) ja Master (SCM).

SABSA on liiketoiminnan näkökulmasta lähtevä malli kehittää tietoturvaratkaisuja, tietoturva-arkkitehtuureja, organisaation tietoturvastrategiaa, tietoturvapalveluja ja yksittäisiä tietojärjestelmiä tai komponentteja. SABSA:n kuusitasoinen malli kattaa kaikki neljä IT-kehityksen vaihetta: strategia, suunnittelu, toteutus ja hallinta sekä operointi. Riskipohjainen lähestymistapa yhdistettynä kaksisuuntaiseen jäljitettävyyteen toteutuksesta liiketoimintavaatimuksiin ja päinvastoin mahdollistaa selkeän näkymän myös yrityksen johdolle. Toteutetut tietoturvakontrollit ovat myös mitattavissa ja siten niiden hyödyllisyys on todistettavissa. Mallia on mahdollista hyödyntää myös erittäin kompleksisissa ympäristöissä ja se on siten hyvin skaalautuva eri käyttötarkoituksiin. SABSA on myös täysin yhteensopiva muiden mallien kuten ISO 27000, ITIL ja CobIT kanssa.

Laajemmin asiaa voi käsitellä organisaation tietoarkkitehtuuristrategiana (Enterprise Architecture, EA). Tällä hetkellä ehkä suosituin käytetty malli on TOGAF (The Open Group Architecture Framework), joka tarjoaa työkalut informaatioarkkitehtuurin suunnitteluun, kehittämiseen, toteutukseen ja hallintaan (governance). Merkittävä uutinen SABSA:n kannalta on, että TOGAF tulee integroimaan SABSA:n osaksi tietoturvaosuuttaan, mikä tulee varmasti lisäämään SABSA:n käyttöönottoa maailmalla.

Seuraava SABSA-kurssi Suomessa on suunniteltu toukokuulle 2012, joten rohkeasti mukaan!

Kirjoittaja Jari Pesonen toimii Nixussa tietoturva-arkkitehtuurien konsulttina ja tietojärjestelmien auditoijana.