Euroopan kemikaalivirasto Echa (European Chemicals Agency) on YLE:n tietojen mukaan kärsinyt viime päivinä verkkoiskuista, joilla pyritään vaikeuttamaan kemikaalitietojaan verkkopalvelun kautta rekisteröivien yrityksien toimintaa. Esirekisteröinnin takaraja päättyy ensi yönä.

Käytännössä tämä tarkoittaa sitä, että rekisteröinnistä myöhästynyt toimija ei voi harjoitttaa tuotteidensa markkinointia.

Teknisenä suojautumiskeinona virasto näyttää käyttävän paikoin esimerkiksi captcha-tunnistuskuviota kirjautumis- ja rekisteröitymissivullaan. Oikein käytettynä tällä keinolla voidaan ehkäistä automaattisten menetelmien käyttö esimerkiksi uusia käyttäjätietoja luotaessa. Lisäksi virasto kehottaa olemaan käyttämättä automatisoituja skriptejä ja estää vihamieliset kirjautumiset IP-osoitteen perusteella.

Kemikaaliviraston Reach IT -sivustolle on esimerkiksi viime päivinä jätetty jopa 100 000 rekisteröintitietoa päivässä.

Tapaus on esimerkki siitä, kuinka verkkorikolliset pyrkivät lamauttamaan pelkästään verkossa toimivia palveluja estääkseen niiden käytön ja vaikeuttamalla siten verkkopalvelua käyttävien yritysten liiketoimintaa. Esimerkiksi lähettämällä suuren määrän epätodellista tietoa palveluun voidaan kuormittaa tietojen käsittelyprosessia.

Esimerkiksi Suomen EU-puheenjohtajuuden aikana toissa vuonna virallisen puheenjohtajuussivuston lisäksi verkossa oli lukuisia ns. varjosivustoja, joissa samankaltaisia verkko-osoitteita käytettiin hyväksi. Sama verkkotunnuksien kaappaustekniikka eli domain hijacking -ilmiö toistui myös saman vuoden syksyllä ASEM 6 -kokoussivustolle juuri huippukokouksen alla.

Alkuviikolla IT-alan uutisissa on käsitelty Applen suositusta käyttää useita virustorjuntaohjelmia OS X -tietokoneissa.

Kyseinen valmistajan tukiartikkeli on nyt poistettu Applen verkkosivuilta. Useat uutissivustot viittasivat artikkeliin Applen päivitettyä artikkelia 21.11 ja nyt tällä viikolla. Kyseessä oli kuitenkin dokumentti, joka on ollut verkossa jo useiden vuosien ajan. Dokumentti on valmistajan mukaan poistettu vanhentuneena ja epätarkkana.

Useat Mac-haittaohjelmista ovat tähän saakka olleet niin sanottuja Proof of Concept –haittaohjelmia. Tämä tarkoittaa erityisen esimerkkikoodin julkaisua, jolla todennetaan kyky valmistaa itse varsinainen haittaohjelma.

Käytännössä Mac-haittaohjelmia ei ole myöskään ollut levityksessä. Tällä viikolla julkistettiin kuitenkin tietoja RSPlug-troijalaisohjelman uudesta muunnoksesta, jota on levitetty aikuisviihdesivustoilla. Vuosi sitten löydetystä haittaohjelmasta on nyt levityksessä viides muunnos eli OSX.RSPlug.E.

Kyseisen troijalaisen asentamisessa hyödynnetään viime kuukausina Windows-haittaohjelmista tuttua menetelmää, jossa käyttäjä huijataan lataamaan videotiedostojen katselua varten erillinen koodekkiohjelma. Tässä tapauksessa on käytetty tekaistua Video ActiveX Object Error –varoitustekstiä. Lisäksi vastikään on raportoitu OSX/Jahlev.A-troijalaisesta, joka naamioituu MacAccess-asennusohjelmaksi.

Virustorjunta ei ole ainoa suoja

Virustorjuntaohjelmiston antama suoja ei ole ikinä sataprosenttinen. Mac-virustorjuntaohjelmien käyttöaste ja myyntiluvut ovat pieniä eikä virustorjuntatoimijoiden kannata ylläpitää Mac-versioille raskasta päivitys- ja tukikoneistoa. OS X –versioita virustorjuntaohjelmistosta on saatavilla myös muilta kuin Applen listaamilta valmistajilta sekä maksullisina että ilmaisina versioina.

Verkkorikollisten motiivit laatia OS X -haittaohjelmia kasvavat käyttöjärjestelmän levinneisyyden myötä. Net Applicationsin Market Share –mittauksen mukaan käyttöjärjestelmän markkinaosuus oli marraskuussa hieman vajaat yhdeksän prosenttia. Myös Applen iPhone-puhelin käyttää OS X:ään pohjautuvaa iPhone OS –käyttöjärjestelmää.

OS X –käyttöjärjestelmään kuuluva tietoturvaominaisuus on kysyä käyttäjältä lupaa käynnistää Internetistä ladattu sovellus. Vahvistusikkuna näyttää sovelluksen nimen, latausosoitteen sekä latausajankohdan.

Virustorjuntaohjelman tarve lisääntyy, mikäli käytettävään sähköpostipalveluun ei kuuluu virustorjuntaratkaisua.

Lisäksi käyttöjärjestelmän ja Safari-selaimen tietoturvapäivityksistä huolehtiminen vähentää riskiä joutua haittaohjelmahyökkäyksen kohteeksi.

VISA Europe on julkaissut uuden PCI DSS -vaatimuksenmukaisuutta koskevan aikarajan. 31.12.2008 jälkeen on kiellettyä tallentaa ja säilyttää ns. arkaluontoista korttitietoa (sensitive authentication data, esim. koko magneettiraita ja CVV2-tieto).

Tietojemme mukaan vaatimusta aiotaan tehostaa 5.000 euron sanktiomaksulla.

Luottokunnan tiedote asiasta löytyy Luottokunnan PCI-tiedotesivustolta.

Nixun tulkinta asiasta

Vaatimus arkaluontoisen korttitiedon säilyttämisestä ei ole uusi, vaan se on aina ollut osa PCI-tietoturvastandardia (vaatimus 3.2). Luottokorttiyhtiöt ovat myös aikaisemmin asettaneet erilaisia aikarajoja standardin noudattamiseen liittyen, mutta ensimmäistä kertaa sanktiot koskettavat myös Suomea. On oletettavaa, että tulevaisuudessa vastaavia aikarajoja ja sanktiota tulee lisää.

Ottaen huomioon asetetun aikarajan sekä vuodenajan, on aikaraja Nixun näkemyksen mukaan todella tiukka: mikäli organisaatio tallentaa arkaluontoista korttitietoa, on tallennuksen lopettaminen sekä jo olemassa olevan tiedon tuhoaminen äärimmäisen haasteellista näin lyhyellä aikavälillä.

Nixu kehottaa asiakkaitaan edelleen lähestymään PCI-vaatimuksenmukaisuutta riskienhallinnan pohjalta: arkaluontoisen korttitiedon säilyttäminen nostaa merkittävästi mahdollisesta tietoturvapoikkeamasta aiheutuvaa riskiä. Arkaluontoisen korttitiedon avulla on mahdollista tehdä vakavampia luottokorttipetoksia, minkä johdosta tällainen tieto on erityisen haluttua rikollisten keskuudessa. Mahdollinen tietoturvapoikkeama, jossa arkaluontoista korttitietoa joutuisi rikollisten käsiin, aiheuttaisi siten myös suuremmat vahingonkorvausvaatimukset.

Miten toimia mikäli tallennat arkaluontoista korttitietoa?

Ensimmäinen askel on lopettaa arkaluontoisen korttitiedon tallentaminen, mikä voi vaatia muutoksia useisiin sovelluksiin.

Tässä asiassa kannattaa kääntyä järjestelmätoimittajien puoleen: heidän tulee muuttaa järjestelmänsä siten, että tällaista tietoa ei enää tallenneta. Etäkauppiaiden (card-not-present) tulisi lisäksi tarkistaa ettei CVV2-tietoa tallenneta kortin varmennuksen jälkeen.

Vaikeaa voi olla myös löytää jo tallennettu arkaluontoinen korttitieto, sillä tieto on yleensä levinnyt useaan järjestelmään. Nixun kokemuksen mukaan arkaluontoista korttitietoa voi löytyä esimerkiksi seuraavista paikoista:

• Kassatyöasemat (transaktiolokit, transaktiotiedostot, paikallinen tietokanta)
• Kassapalvelimet
• Tietokantapalvelimet
• Pankkiyhteysohjelmisto ja tiedonsiirtopalvelu
• Raportit (erityisesti CVV2-tieto)
• Varmistusjärjestelmät ja mediat (esim. varmistusnauhat)
• Asiakassopimukset (erityisesti card-not-present-kauppiaat ja CVV2-tiedon tallennus)
• Työasemat (erityisesti card-not-present-kauppiaat ja CVV2-tiedon tallennus)

Valtioneuvosto on hyväksynyt Suomelle uuden kansallisen tietoturvastrategian vuosiksi 2009-2015. Toimenpideohjelma strategialle (pdf) laaditaan kevään 2009 aikana. Strategia on saanut nimen ”Turvallinen arki tietoyhteiskunnassa – Ei tuurilla vaan taidolla –”.

Painopistealueita strategiassa on kaikkiaan kolme:

• perustaidot arjen tietoyhteiskunnassaan

• tietoihin liittyvien riskien hallinta

• toimintavarmuus sekä kilpailukyky ja kansainvälinen verkostoyhteistyö

Palveluiden tietoturvasta vastaa ohjeistuksen mukaan palvelun tarjoaja yhdessä palvelun tuottamiseen osallistuvien toimijoiden kanssa.

Saatesanat korostavat tietoturvan kokonaisvaltaisen hallinnan varmistamista palveluita ulkoistettaessa ja hankintoja ketjutettaessa.

Lähivuosina on myös tarkoitus selvittää kansallisen tietoliikenneturvallisuusviranomaisen (NCSA) perustamisen tarvetta maahamme.

Periaatepäätös korvaa viisi vuotta sitten laaditun tietoturvastrategian. Tuolloin sai alkunsa kansallinen tietoturvapäivä, joka järjestetään kuudetta kertaa 10. helmikuuta 2009. Strategian toimintasuunnitelman laati nyt Arjen tietoyhteiskunnan neuvottelukunnan alainen tietoturvallisuusryhmä.

“…systems that store, process, or transmit cardholder data…”

Helpoin keino hoitaa ongelmalliset tilanteet on ulkoistaa ne, sanotaan. PCI-vaatimusten osalta voisi olla helppo ymmärtää, että ne koskevat vain luottotietoja käsittelevää järjestelmää, mutta näin asia ei kuitenkaan ole. PCI:n skooppiin kuuluvat kaikki järjestelmät, jotka käsittelevät, tallentavat tai kuljettavat luottokorttitietoja. Tämän voisi helposti ymmärtää niin, että jos organisaatio ei käsittele, tallenna tai kuljeta omistamaansa PCI-dataa organisaationsa sisällä, eivät PCI:n vaatimuksetkaan kosketa heitä. Asia ei kuitenkaan ole aivan näin yksiselitteinen. Vaikka kauppiasorganisaatiolla itsellään ei missään tilanteessa olisi edes pääsyä korttitietoihin, vaan kaikki siihen liittyvä olisi ulkoistettu palveluntarjoajalle, viime kädessä vastuu luottokorttitietojen suojaamisesta kuuluu kuitenkin tietojen omistajalle.

PCI on-site -auditointi kohdistuu aina luottokorttitietoja käsittelevän järjestelmän omistajaan, jonka tulee täyttää kaikki PCI-standardin vaatimukset soveltuvin osin, tallensi, käsitteli tai siirsi se luottokorttitietoja omassa ympäristössään ja omien työntekijöidensä toimesta tai ei. Kaikilta osin standardin vaatimukset eivät kuitenkaan tällaisissa tilanteissa ole soveltuvia, mutta tietyt vaatimukset kuten yrityksen tietoturvapolitiikkaan ja palveluntarjoajien sopimuksiin liittyvät tulee silti ottaa huomioon. Tällaisissa tapauksissa pääosa vaatimuksista kuitenkin kohdistuu palvelun toimittajaan, jonka toimintojen tulee asiakkaan järjestelmän osalta täyttää PCI:n vaatimukset.

Omalta osaltaan tilannetta monimutkaistavat suositut SaaS-, PaaS- ja cloud computing -mallit, joissa tarjottavan palvelun rajat sekä sisältö hämärtyvät ja itse palvelu on asiakkaalle usein pelkkä musta laatikko. Usein näissä tilanteissa sopimusehdot eivät myöskään aina mahdollista vaatimuksen 11 edellyttämiä säännöllisiä teknisiä tarkastuksia. Nämäkään seikat eivät kuitenkaan ole perustelu PCI-vaatimusten noudattamatta jättämiselle. Vaatimus 12.8.2 määrittelee, että palveluntarjoaja tulee kirjallisella sopimuksella velvoittaa noudattamaan PCI-standardin vaatimuksia. Pienelle yritykselle, puhuttaessa suurista globaaleista toimijoista, PCI-vaatimusten ujuttaminen palvelusopimuksiin voi olla vaikeaa ellei mahdotonta. Suositeltavin vaihtoehto onkin, että palveluntarjoajat sertifioituvat tilaamalla omille toiminnoilleen PCI-auditoinnin, mutta ainakaan toistaiseksi tällä rintamalla ei suuria liikkeitä ole nähty. Mikäli palveluntarjoaja ei itse halua sertifioitua, tullaan vaatimustenmukaisuus selvittämään erikseen heidän jokaisen asiakkaansa auditoinnin yhteydessä. Sertifioimalla palvelunsa oma-aloitteisesti toimittajat paitsi helpottaisivat omalta osaltaan asiakkaidensa sertifiointiprosesseja ja sitä kautta vähentäisivät myös omia auditointeihin liittyviä tukitehtäviään, myös saisivat PCI-sertifioinnillaan selkeää etua kilpailijoihinsa nähden. Toisaalta standardin tarkan tulkinnan mukaan, mikäli palveluntarjoaja ei suostu ottamaan soveltuvin osin vastaan PCI-velvoitetta sopimuksissaan, on kauppiaan mahdollista saavuttaa PCI-sertifiointi vain vaihtamalla toimittajaa.

On luonnollista, että standardissa ei voida ottaa yksiselitteistä kantaa kaikkiin olemassa oleviin palvelumalleihin ja arkkitehtuureihin, mutta palvelujen ulkoistaminen on yhä suositumpaa ja vaatimuksia on nykymuodossaan haastavaa soveltaa käytäntöön kaikissa tilanteissa. Luonnollisesti näissäkin tilanteissa “lain” henki on tärkeämpi kuin sen kirjain ja auditoinneissa asiaa voidaan lähestyä riskienhallinnan menetelmin, mutta tilanteen yleisyyden vuoksi tarkemmat linjanvedot olisivat paikallaan. Toivottavasti asian tulkintaan saadaan tulevaisuudessa tarkennuksia PCI SSC:n toimesta. Sitä odotellessa kannattaa noudattaa vanhaa nyrkkisääntöä: “toimintoja voi ulkoistaa, mutta vastuuta ei.”