Ads 468x60px

maanantai 29. kesäkuuta 2015

Turvapostin tarjoama lisäturva?

Usealle blogin lukijoista turvaposti on tuttu aihe vähintään konseptina. Turvapostin tavoitteena on tarjota mahdollisuus lähettää ja vastaanottaa salattuja sähköposteja ilman ohjelmistoasennuksia. Turvaposti tarjoaa lähettäjälle myös mahdollisuuden kontrolloida jo lähetettyä sähköpostia, esimerkiksi tietoa siitä onko vastaanottaja lukenut viestin tai jopa mahdollisuuden poistaa lähetetty viesti. Tässä blogitekstissä haluan keskittyä erityisesti turvapostin salauksen tuottamaan lisäturvaan.

Turvapostin käyttö perustuu siihen, että linkki turvapostin sivuille lähetetään vastaanottajan normaaliin sähköpostiin. Linkin vastaanottaja menee lukemaan viestin sisällön verkkoselaimellaan klikkaamalla/kopioimalla saamansa linkin sähköpostista, jolloin selain huolehtii SSL/TLS salatun yhteyden muodostamisesta. Tämä salattu yhteys takaa tiedon luettavuuden ja eheyden. Vai takaako sittenkään? Tämän kaltaisessa toteutus ei käytännössä tuota sen suurempaa lisäturvaa kuin perinteinen sähköposti. Syy tähän on siinä, että turvapostia käytettäessä ei luoteta siihen, että sähköpostiliikenne organisaatioiden välillä olisi salattua. Tämä on sinäänsä ihan varteenotettava uhka, koska kaikki organisaatiot eivät tosiaan salaa sähköpostiliikennettä. No, mitä sitten, kun linkki turvapostiin lähetetäänkin salaamattomana sähköpostina? Tässä tapauksessa salaamatonta kommunikaatiota (turvapostilinkin sisältämän sähköpostin välitystä) kuunteleva taho saa selville linkin turvapostiin, jonka hän voi avata verkkoselaimella ja käydä lukemassa turvapostista.

Mitä lisäturvaa turvaposti on lähettäjän ja vastaanottajan väliseen kommunikaatioon tuottanut? On totta, että suojattava tieto ei ole missään vaiheessa liikkunut verkossa salaamattomana mutta se ei tosiaankaan tarkoittanut sitä, etteikö ulkopuolinen taho päästä siihen käsiksi. Turvaposti vaatii käytännössä  hyökkääjän aktiivisia toimia (linkin lukeminen), eikä pelkkä passiivinen hyökkäys (salaamattoman liikenteen kuuntelu) riitä. Muutamilla turvapostia käyttävillä organisaatioilla on käytössä puhelinnumeron etukäteinen rekisteröinti, jolla esitetyn kaltaiset uhat voidaan torjua. Vastaanottajan ilmoitettua puhelinnumeronsa saa hän turvapostin vastaanoton jälkeen kertakäyttöisen salasanan puhelimeensa, jonka turvaposti vaatii syötettäväksi ennen viestin avaamista. Näin onnistutaan torjumaan liikennettä salakuuntelevan tahon aiheuttama uhka ja käytetään tietynlaista kaksivaiheista tunnistautumista, jonka murtaminen vaatii kykyä sekä sähköpostiliikenteen että matkapuhelinliikenteen kuuntelemiseen. Onkin erittäin suositeltavaa, että kaikki turvapostia käyttävät organisaatiot ottaisivat käyttöön puhelinnumeron etukäteisen rekisteröinnin.

Miten sähköpostin luotettavuudesta ja eheydestä tulisi varmistua? Turvaposti on ajatuksena hyvä mutta se ei vastaa kaikkiin realistisiin uhkiin. Tietoturva-asiantuntijan näkökulmasta S/MIME (Secure/Multipurpose Internet Mail Extensions) tai PGP (Pretty Good Privacy) ovat parhaita end-to-end salausratkaisuita, joiden avulla voidaan varmistua tiedon eheydestä ja luottamuksellisuudesta. Erityisesti S/MIME:n käyttöönotto ja käyttö on kohtalaisen suoraviivainen prosessi, koska suurin osa organisaatioista käyttää Microsoftin Outlook -sähköpostisovellusta, joka integroituu hyvin S/MIME:n kanssa. Tällä hetkellä sekä S/MIME:n että PGP:n suurin ongelma on luotettava avainten jakelu. Esimerkiksi Suomessa ei ole mitään keskitettyä ja luotettua palvelinta, joihin suurin osa organisaatioista luottaa ja jota voitaisiin käyttää avainten jakeluun. Toinen vaihtoehto on esimerkiksi Viestintäviraston käyttämä tapa, jossa PGP-avaimet jaellaan heidän verkkosivujen kauttan. Toinen haaste, jonka end-to-end sähköpostisalaukset aiheuttavat on sähköpostiliikenteen analysointil. Jos organisaatiolla on käytössä sähköpostin virustarkistus tai sandbox-analysointi, niin tällaisten järjestelmien ei ole mahdollista analysoida päästä päähän salattua sähköpostia.

Turvallista sähköpostiviestintää ja hyviä kesäkelejä toivottaen,
Jesse

keskiviikko 10. kesäkuuta 2015

Strategiasta sen tavoitteita toteuttavaan toimintaan



Palveluyksikössä on saatu tärkeäksi koettu hanke valmiiksi ja hankkeen lopputulokset tuotantoon. Hanke on sujunut hyvin, se on tuottanut suunnitellut tulokset ja on pysynyt aikataulussaan ja budjetissaan. Tulokset on otettu käyttöön ongelmitta. Mutta miksi organisaation ylin johto ei koe tuloksia tärkeinä ja antaa ymmärtää olevansa tyytymätön yksikön toimintaan. Missä vika? Onko hankkeessa kenties tehty vääriä asioita?

Johdon tärkeä työkalu on strategia. Organisaation strategiaan kuvataan tavoitetila, jossa organisaation halutaan olevan tulevaisuudessa. Strategia asettaa organisaation toiminnalle ja kehittämiselle päämäärät. Strategiaan kirjataan organisaation toiminnalle selkeät tavoitteet, jotka täyttämällä päämäärät on tarkoitus saavuttaa.

Kun tavoitteet on kirjattu, on analyysin paikka. Onko organisaatio kykenevä saavuttamaan strategiset tavoitteensa? Tarvitaanko kenties uudenlaista toimintakykyä tai uutta osaamista? Ehkä on rakennettava uusi tietojärjestelmä tukemaan uutta toimintaa. Tai sitten olemassa olevia toimintaprosesseja on muutettava ja olevia järjestelmiä kehitettävä.  Analyysin tuloksena saadaan käsitys uusista ja kehitettävistä kyvykkyyksistä, joita tarvitaan strategian tavoitteiden toteuttamiseksi.
Kyvykkyydet toteutetaan kehittämishankkeissa. Kullekin hankkeelle asetetaan tavoitteeksi toteuttaa tietty osa tarvittavista uusista kyvyistä. Näin kullakin hankkeella on suora kytkentä strategiaan ja sen tavoitteisiin. Hankkeet on hyvä koota hankesalkkuun, jotta säilytetään kokonaisnäkemys siitä, mitä kaikkea kehittämistä, kenen vastuulla ja koska on käynnissä. Kun uudet ja muutetut kyvyt on toteutettu ja otettu käyttöön, on organisaatio kykenevä strategiaa toteuttavaan toimintaan.

Yksittäisiä kehittämishankkeita on ohjattava niin, että niiden tuottamat lopputulokset istuvat osaksi organisaation toiminnallista ja järjestelmäteknistä kokonaisuutta. Sitä varten on oltava käsitys organisaation toimintojen, tietojen, järjestelmien ja teknologian muodostaman kokonaisuuden nykytilasta sekä suunnitelma kokonaisuuden halutusta tavoitetilasta.

Organisaation kokonaisuuden suunnittelu on hankkeiden ulkopuolista jatkuvaa toimintaa, joka on tehtävä järjestelmällisesti ja hallitusti. Kokonaisuuden suunnitteluakin ohjaavat strategiassa asetetut tavoitteet.

Organisaation kokonaissuunnitelmaa kutsutaan myös kokonaisarkkitehtuuriksi.

Jukka Uusitalo
Arkkitehti,
Manager, Management Consulting

perjantai 5. kesäkuuta 2015

Digitaalinen identiteetti saapuu Töölönlahdelle.

KPMG on varmasti kaikille tuttu toimija etenkin tilintarkastuksen ja liikkeenjohdon konsultoinnin alueilla. Näin tuoreena KPMG:läisenä minulle on tullut kuitenkin yllätyksenä Suomen KPMG:n toimituskyky tietoturvan ja IT -neuvontapalveluiden osalta. Näiden palveluiden parissa työskentelee pitkälti yli sata asiantuntijaa, ja yli 10% talon liikevaihdosta tulee näistä IT -alueen asiantuntijapalveluista.

Tietoturvapuolella KPMG on panostanut merkittävästi niin hallinnollisen, kuin teknisenkin tietoturvan palveluiden tarjontaan. Siinä missä hallinnollinen tietoturva määrittelee erilaisten viitekehyksien kautta järkevän tavan toteuttaa liiketoimintaa siten että riskit pysyvät hallinnassa, tekninen tietoturva tekee mm. auditointeja ja penetraatiotestausta alan neuvontatehtävien lisäksi.

Identiteetinhallinnan (IAM, Identity and Access Management) ratkaisut luetaan yleisesti osaksi tietoturvapalveluita, mutta asia ei ole oikeasti ihan niin suoraviivainen. IAM ratkaisee toki tietoturvaan ja riskienhallintaan liittyviä asoita, mutta monesti IAM -hankkeen laukaisee käytettävyys tai kustannussäästöasiat, tai yhä useammin halu parantaa sähköisten palveluiden asioinnin asiakaskokemusta. Suomalainen identiteetinhallinnan skene on varsin rikas. Täältä löytyy useita ohjelmistotaloja, asiantuntijaorganisaatioita, ja jokainen merkittävä käyttöpalvelutoimittajakin on sekaantunut Identiteetinhallinan palveluiden tarjoamiseen. Missään muussa pohjoismaassa tällaista tietoturvan ja IT-palveluiden niche-alueen osaamisklusteria ei ole syntynyt. Tarkkaa syytä tähän en tiedä, mutta veikkaan että menestysvuosien Nokia alan suurena palveluostajana on suurin syy alan kehittymiselle, jonka jälkeen tarjonta on lisännyt myös kysyntää.

Trusteq oli ensimmäinen suomalainen täysin identiteetinhallinnan palveluihin keskittynyt asiantuntijaorganisaatio. Olin itse perustamassa Trusteqia tammikussa 2003. Kasvoimme kahden hengen organisaatiosta lähes 50 asiantuntijaa työllistäväksi merkittäväksi toimijaksi reilussa kymmenessä vuodessa. KPMG Oy Ab:n ostaessa Trusteqin osakekannan alkuvuonna 2015, se sai riveihinsä ison joukon osaavia ja motivoituneita digitaalisen identiteetin palveluiden asiantuntijoita.

Mitä identiteetinhallinta ja digitaalisen identiteetin palvelut sitten konkreettisesti tarkoittavat ? 


Periaatteen tasolla kyse on samasta asiasta. Siinä missä identiteetinhallinta tai ”identiteetinhallinnan projekti" voidaan ehkä nähdä enemmän prosesseihin tai teknologiaan liittyvänä, kenties talon sisäisen IT:n parantamisena, digitaalinen identiteetti ja sähköinen asiointi tarkoittaa enemmänkin sitä että yritys voi pitää liiketoimintansa käynnissä verkossa, ympäri vuorokauden ja sitä, miten huolehditaan palvelun käytettävyydestä, ilman että käyttäjää vaivataan ylimääräisillä kirjautumisilla tai ylläpitäjän työpäivä täytetään salasanojen palauttelulla. Hyvä verkkopalvelu mahdollistaa käyttäjälle itsepalvelun myös omien tietojen ylläpitoon, ja integraatiot muihin liiketoiminnan järjestelmiin.

Jokainen on kuullut puhuttavan tämän päivän megatrendeistä. Joka puolella puhutaan digitalisaatiosta, kuluttajistumisesta, pilvipalveluista ja esineiden internetistä. Miten identiteetinhallinta tai digitaalinen identiteetti liittyy näihin? Miten ne liittyvät KPMG:n palveluihin? Ei kai tässä olla rakentamassa jotain erillistä saareketta?

Todennäköisesti jokainen verkkopalvelu, jolta odotetaan hyvää käytettävyyttä, vaatii käyttäjän tunnistamisen jollain tasolla. Mikäli verkkopalvelun avulla on tarkoitus tehdä liiketoimintaa, käyttäjä on yleensä tunnistettava henkilökohtaisesti, ja asiakkuushistoriaakin olisi hyvä tuntea. Trusteq on ollut toteuttamassa monia tällaisia järjestelmiä siltä osin, mikä kuuluu käyttäjän tunnistamiseen ja sen jälkeen tapahtuvaan valtuuttamiseen eri palveluissa. Olemme myös suunnitelleet ja toteuttaneet tarvittavat prosessit, joilla esimerkiksi yritysten välisissä verkkopalveluissa vähennetään kirjautumisen tarvetta sekä koitetaan minimoida kaikkeen käyttäjätiedon ylläpitoon kuluva aika.

Trusteq ei kuitenkaan ole toteuttanut kokonaisuudessaan yhtäkään verkkopalvelua, mutta KPMG:n IT-neuvontapalveluille se on ihan arkipäiväistä tekemistä. Esineiden internetissä kuluttaja- tai käyttäjäidentiteettien sijaan joudutaan ottamaan kantaa laitteiden identiteetteihin ja ”valtakirjalla toimimiseen”, jolloin laite voi toimia määrättynä aikana ja tietystä positiosta tietyn käyttäjän oikeuksin. KPMG tuottaa teollisen ja esineiden internetin neuvontapalveluja. Trusteqin asiantuntemus tuo vahvan panoksen identiteetteihin liittyvällä osaamisella.

Palvelua ympäri vuorokauden

Yhdessä voimme reagoida nopeammin asiakkaalla tapahtuviin poikkeustilanteisiin. Voi olla että esimerkiksi erilaisten tarkastusten tai audiointien kautta paljastuu asioita, jotka pitää voida korjata tai muuttaa nopeasti. Tässä Trusteqilta peritty ”hands-on”-asiantuntemus on arvokasta. Mainittakoon myös että Trusteq Garant -palvelukeskus, joka palvelee asiakkaita Espoosta käsin tällä hetkellä 23 aikavyöhykkeellä ja 24/7 mahdollistaa monenlaisten palveluiden tarjoamisen myös tässä koko KPMG:n kontekstissa niin kotimaassa kuin ulkomaillakin.

KPMG ja Trusteq voivat yhdessä toteuttaa merkittävästi isompia kokonaisuuksia; se on asia josta hyötyy asiakaamme ja heidän asiakkaansa. Trusteqin henkilökunta pystyy laajentamaan osaamistaan monelle muulle IT-neuvontapalveluiden ja teknisen tai hallinnollisen tietoturvan osa-alueelle. Palvelutuotteistuksen osaamisemme on otettu ilolla vastaan KPMG:n puolella, ja olemme jo viemässä osaamistamme muihin maihin. Tästä on tulossa hieno matka.

keskiviikko 3. kesäkuuta 2015

Useimmissa web-sivustoissa vakavia haavoittuvuuksia

Hiljattain julkaistiin raportti, jossa oli analysoitu kymmeniä tuhansia sivustoja tietoturvanäkökulmasta. Tutkimuksen teki WhiteHat Security ja se ajoittui viime vuoteen. Dataa kerättiin sadoilta tunnetuilta organisaatioilta, ja analysoitua dataa kertyi satoja teratavuja. Raportin mukaan useimmista web-sivustoista löytyi ainakin yksi vakava haavoittuvuus. Hälyyttävää on se, että haavoittuvuudet olivat vaarantaneet sovellusten tietoturvaa useiden kuukausien ajan.

Analyysissä vertailtiin eri toimialoja keskenään. Huonoiten haavoittuvuusvertailussa menestyi julkishallinto, jonka sivustoista 64 prosenttia oli haavoittuvia päivittäin ympäri vuoden. Huonosti menestyivät myös logistiikka-ala, tuotanto,  majoitus- ja ravitsemusala sekä vähittäiskauppa, joiden web-sivustoista suurimmassa osassa todettiin olevan jatkuvasti ainakin yksi vakava haavoittuvuus. Terveydenhoitoalan sivustoista jatkuvasti haavoittuvia oli puolet ja rahoitus- ja vakuutusalan web-sivustoistakin yli kolmasosa.

Haavoittuvuudet voivat vaarantaa useita järjestelmiä ja niitä hyväksikäyttämällä hyökkääjä voi saada käyttäjien tietoja tai ottaa ottaa jopa haltuunsa käyttäjätilejä. Tämä aiheuttaa organisaatioille vakavan maineriskin ja voi johtaa asiakkaiden menetykseen, sakkoihin ja oikeusjuttuihin.

Kuinka asian sitten voisi korjata? Tutkimuksessa havaituista haavoittuvuuksista ainoastaan prosentti tai pari oli sellaisia, jotka olivat korjattavissa tietoturvapäivityksillä. Suurin osa haavoittuvuuksista löytyi kustomoitujen web-sovellusten ohjelmistoista. Murtotestaus on yksi keino, jolla voidaan löytää web-sovelluksissa olevia haavoittuvuuksia. Tutkimuksessa havaittiin, että sen jälkeen kun organisaatiot alkoivat käyttää murtotestaajia, haavoittuvuuksien määrä laski keskimäärin 65 prosenttia.

WhiteHat selvitti noin sadankahdenkymmenen yrityksen otannalta syytä siihen miksi näitä haavoittuvuuksia ei korjata. Suurin yksittäinen tekijä oli ylläpitopolitiikka. Toinen merkittävä tekijä liittyi siihen kirjattiinko löydetyt haavoittuvuudet haavoittuvuuksienseurantajärjestelmään. Organisaatiot, joissa lähetetään haavoittuvuus- ja murtotestauksien havainnot seurantajärjestelmään - sen sijaan että vain kerrottaisiin ohjelmistokehittäjille - oli keskimäärin 45 prosenttia vähemmän haavoittuvuuksia. Parhaana käytäntönä voidaankin pitää säännöllisten tietoturvatestausten tekemistä ja seurantajärjestelmän käyttöönottamista ja integroimista osaksi ohjelmistokehityksen prosesseja.

sunnuntai 24. toukokuuta 2015

Kun tietoturva ja käytäntö kohtaavat - Case sovellusasennus

Sattuipa viime viikolla elävässä elämässä: minun piti toteuttaa asiakkaalle projektia, jonka toteutukseen tarvittiin normaalista poikkeavia yhteyksiä asiakkaan sisäverkkoon. Yhteyksien toteuttamiseen minun piti, tai olisi pitänyt, asentaa erillinen sovellus pääkäyttäjän oikeuksin omalle koneelleni. No pahus, minulla ei ole pääkäyttäjän oikeuksia koneeseeni, mutta olin budjetoinut, että teen tuota projektia kyseisenä päivänä. Asiakaskin olisi ollut tyytyväinen, jos hän olisi saanut jotain konkreettista jo päivän päätteeksi. Mutta, ei auta, ei-standardeille sovelluksille on oma asennusprosessinsa, jota pitää noudattaman. Prosessiin kuuluu, että sovelluksesta tehdään virallinen asennuspyyntö, ennalta hyväksymättömien sovelluksien aiheuttamat riskit arvioidaan, asennus kirjataan ylös ja tämän jälkeen helpdesk saa luvan asentaa sovellus oman prioriteettilistansa puitteissa. Eli, pyyntö sisään ja odottamaan, että helpdesk ottaa pyynnön toteutukseen. Valistunut lukija voi otsikosta arvata, onnistuuko asennus saman päivän aikana...

Niinpä niin, ja tietoturvan piti edistää liiketoimintaa. Miten tässä näin kävi, että homma jäi toteuttamatta tietoturva takia? Muutama vuosi sitten homma olisi onnistunut. Tällöin ihmiset saattoivat kävellä helpdeskiin ja pyytää helpdeskiä syöttämään salasanan suoraan asennusohjelmaan. Tehokkuus maksimoitui, mutta toisaalta organisaation näkökulmasta hallittavuus oli nolla. Koneista löytyi mitä erilaisimpia sovelluksia eikä kelläkään ollut hajua mitä sovelluksia todellisuudessa tarvittiin, salliko sovellusten lisensointi sovellusten käyttämisen, mitä haavoittuvuuksia sovelluksissa oli ja niin edelleen. Lisäksi, teoriassa käyttäjien olisi toki pitänyt poistaa sovellukset sen jälkeen kun niitä ei enää tarvittu, mutta kuinka moni on poistanut sovelluksia koneestaan, tai puhelimestaan, jos levytilasta ei ole akuuttia puutetta?

Koska asennus ei siis onnistunut suoraan, niin jäin miettimään voisinko tehdä poikkeuksen prosessiin? Eikai nyt yksi pikku luistiminen haittaisi? Ehkä hieman kaukaa haluttu esimerkki, mutta näin varmaan Hillary Clintonkin ajatteli, kun hän käytti henkilökohtaista sähköpostia virkatehtäviin. Hän päätti tietoisesti rikkoa sääntöjä voidakseen toimia (omasta näkökulmastaan) tehokkaammin. Noh, toki hommat hoituivat, kyseessä tapauksessa ei Hillaryn onneksi sattunut pahoja tietovuotoja (tai katoamisia) ja jälkipyykkikin saatiin selvittyä pienin vaurioin avustajien avulla.

Tästä päästään siihen, että edes tietoturvamaailma ei ole täysin musta-valkoinen. Tietoturvassa on mahdollista tehdä poikkeuksia ja niitä pitää myös perustelluista syistä pystyä tekemään. Tällöin päädymme arvioimaan millaisen riskin poikkeus meille aiheuttaa ja miten aiomme tämän uuden riskin hallita. Hillaryn tapauksessa näyttää siltä, että hän kesti sääntöjen rikkomisesta aiheutuneen riskin. Oliko tämä sitten hallittua ja laskelmoitua riskin ottamista, niin sen tietää vain Hillary itse.

Niin tai näin, mitä sitten opin ylläolevassa harjoituksesta? Ainakin seuraavat asiat:
  1. Jokaisen, joka määrittelee jotain prosesseja, tulee joutua itse käyttämään kyseistä prosessia. Määrittelijän ja käyttäjä tarpeet eivät aina ole samat ja eri tarpeiden väliltä joudutaan etsimään molempia tahoja tyydyttävä kompromissi.
  2. Vaikka prosessit tuovat hitautta joskus yksilötasolla, niin kokonaisuuden kannalta prosessit ovat välttämättömiä. Vaikka minä tiedän tämän, niin minun tulee pystyä kertomaan tämä isokuva myös muille loppukäyttäjille.
  3. Mieti etukäteen miten poikkeukset tulee hoitaa. Mikä on se oikopolku, jota voidaan käyttää poikkeavassa tilanteessa? Tässä kohden on hyvä muistaa, että ”mikä prosessin oikaisussa säästetään, niin se hävitään (yleensä monin kertaisesti) jälkikäteisselvityksessä”.
Bonus: Mittaa aikaa, joka kuluu sovelluksen asennuspyynnöstä siihen, kun sovellus on saatu asennettua. Näin käyttäjien arki konkretisoituu.

Hallittuja sovellusasennuksia!
Antti

keskiviikko 22. huhtikuuta 2015

Tuntematon uhka tanskassa

KPMG Suomi julkaisi loppuvuodesta 2013 Tuntematon uhka suomessa tutkimuksen. KPMG Ruotsi seurasi perässä ja julkaisi oman tutkimuksensa Ruotsin tilanteesta elokuussa 2014. Nyt vuorossa on KPMG Tanska, joka esitteli Unknown Threat in Denmark tutkimuksensa 21.4.2015 ISACA Nordic konfrenssissa (Tutkimusmateriaalia ei ole 22.4.2015 julkaistu vapaasti ladattavaksi).

Tuntematon Uhka tanskassa tutkimuksessa oli mukana 18 organisaatiota niin julkiselta kuin yksityiseltä sektorilta. Mukana olleiden organisaatioiden toimialat vaihtelivat, eikä niitä anonymiteetin takia ole julkaistu. Tutkittavat organisaatiot olivat kooltaan yli 500 henkilön tai niissä oli käytössä suuri määrä päätelaitteita. Tutkimusdata kerättiin helmikuun 2015 aikana.

Tuntematon uhka tutkimuksien tulosten vertailu
Tanskan tutkimuksen tulokset ovat ehkä jopa huolestuttavampia kuin mitä Suomessa ja Ruotsissa toteutettujen tutkimusten tulokset ovat. Kaikkien tutkimusten tuloksista löytyy selkeitä yhtäläisyyksiä: yli puolesta (Tanskassa kaikista) tutkimuksessa mukana olleista organisaatioista pystyttiin tunnistamaan haittaohjelmaliikennettä sisäverkosta, havaitusta haittaohjelmaliikenteestä merkittävä osa on ns. tuntemattomien uhkien aiheuttamaa (perinteiset AV-ohjelmistot eivät tunnista niitä) ja että lähes kaikista tutkituista organisaatioista siirtyi yrityksen dataa hyökkääjälle tutkimusdatan keräyshetkellä.

Merkittävimpänä erona aikaisempiin Tuntematon Uhka tutkimuksiin nähden voidaan pitää mobiililaitteisiin kohdistettujen haittaohjelmien määrän lisääntymistä. Tutkimuksen aikana havaituista mobiilihaittaohjelmista 93% toimi Android-alustalla ja loput 7% iOS-alustalla. Aiemmin toteutetuissa tutkimuksissa mobiililaitteisiin kohdennettujen haittaohjelmien aiheuttama liikenne on ollut vähäistä, eikä sitä ole merkittävästi tunnistettu. Tämä saattaa myös johtua siitä, että Suomessa organisaatioiden mobiilikäyttäjät ovat usein eriytetty sisäverkosta ja että mobiililaitteisiin hyökkäävien haittaohjelmien määrä on kasvanut viimeisen 1.5 vuoden aikana.Toinen Tanskan tutkimuksen merkittävä huomio on, että 94 % kaikista havainnoista aiheutui kontrolloimattomista päätelaittesta (päätelaitteista joiden tietoturva-asetuksia ei ole vahvistettu tai ne ovat loppukäyttäjän vastuulla). Toisaalta, 74 % havainnoista, jotka syntyivät kontrolloiduista päätelaitteista olivat riskiltään merkittäviä tai kriittisiä.

Päätelaitteeseen asetettujen tietoturvakontrollien merkitys
Tuntematon Uhka Tanskassa tutkimuksen perusteella mobiililaitteisiin kohdistettujen haittaohjelmien määrä on lisääntynyt aikaisempiin Suomessa ja Ruotsissa toteutettuihin tutkimuksiin nähden. Havaitut hyökkääjät olivat myös entistä motivoituneempia tavoittelemaan rahallista hyötyä toimistaan. Tutkimuksessa selviää, että jo perustason tietoturvakontrollit vähentävät huomattavasti haittaohjelmatartuntojen määrää - on parempi toteuttaa edes perustason suojausmekanismit kuin olla tekemättä mitään.Tutkimuksen aikana havaittiin, että osa organisaatioista kärsii edelleen ylimmän johdon tuen puutteesta tietoturvan suhteen (tämä ei kuitenkaan tarkoita, että ylintä johtoa ei kiinnosta).

Mitä tämä kaikki käytännössä tarkoittaa? Tärkeintä olisi muuttaa työntekijöiden ajatusmaailmaa - tietoturvan ei tarvitse olla toimintaa vaikeuttava taakka, vaan se voi olla kilpailuetu, jonka johdosta asiakkaat valitsevat teidät. Hyvin toteutettu tietoturva myös tukee liiketoimintaa paremmin, jolloin esimerkiksi IT-järjestelmien vioista ja onnistuneista hyökkäyksistä aiheutuvat kustannukset ovat pienemmät. Usein tämä myös tarkoittaa parempaa mahdollisuutta siirtyä käyttämään uusia digitaalisia palveluita ja kykyä tehostaa omaa liiketoimintaa.

-Jesse

maanantai 20. huhtikuuta 2015

Tietoturvatasot – Arvioidaanko yksi, neljä vai kahdeksan Vahti-ohjetta?

Tietoturvatasot, ah  tuo meille monelle niin rakas ja tuttu aihe. Kukapa ei olisi kuullut "legendaarisesta" Vahti 2/2010 ohjeesta ja sisältämistä kontrolleista?  Noh, siitä huolimatta, että tietoturvatasot ovat niin tuttu juttu, niin silti ajattelin kirjoittaa niistä mutaman sanasen.

1. heinäkuuta 2010 annettiin Valtioneuvoston asetus tietoturvallisuudesta valtionhallinnossa [1]. Tämä asetus on siinä mielessä erittäin merkityksellinen, että kyseisessä asetuksessa säädetään ”valtionhallinnon viranomaisten asiakirjojen käsittelyä koskevista yleisistä tietoturvallisuusvaatimuksista sekä asiakirjojen luokittelun perusteista ja luokittelua vastaavista asiakirjojen käsittelyssä noudatettavista tietoturvallisuusvaatimuksista”. Asetuksen 5 §, tietoturvallisuuden perustason toteuttaminen, määrittää 10 kohtaa, jotka organisaatioiden tulee toteuttaa tietoturvallisuuden perustasolla. Tämän lisäksi asetuksessa on lukuisia muita vaatimuksia, jotka tulee huomioida eri suojaustasojen käsittelysäännöissä. Tietoturvallisuusasetus tuli voimaan 1.10.2010. Asetukseen sisältyi siirtymäaika, jonka mukaisesti organisaatioiden tuli saavuttaa asetuksen 5 §:ssä säädetty perustason 30.9.2013 mennessä.

Koska asetus määrittää perustason vaatimukset vain ja ainoastaan ylätasolla, niin tämä aiheutti merkittävän määrän kysymyksiä kuinka asetuksen vaatimukset tulee täyttää. Tätä ongelmaa poistamaan laadittiin Vahti-ohje 2/2010 Ohje tietoturvallisuudesta valtionhallinnossa annetun asetuksen täytäntöönpanosta. Erityisen vahvan aseman on saanut ohjeen liite 5, jossa määritellään erilaisia vaatimuksia perustasolle, korotetulle tasolle ja korkealle tasolle. Tästä liitteestä onkin tullut synonyymi tietoturvatasojen vaatimuksille. Osin tämä johtuu siitä, että ohjeen julkaisun jälkeen suurin osa tietoturvatasoauditoinnesta on toteutettu vain kyseisen liitteen 5 kontrolleja vastaan.

Hämmentävää kyllä, mutta käsitykseni mukaan tietoturvatasojen korotettua tasoa tai korkeaa tasoa ei ole virallisesti määritelty missään. Perustason vaatimukset löytyvät siis asetuksesta, mutta korotetun tai korkean tason vaatimuksia ei ole määritelty. Tämän johdosto on yleisesti katsottu, että Vahti 2/2010 Liite 5:n vaatimukset *ovat* korotetun ja korkean tason vaatimukset.

Tietoturvatasot - auditointinäkökulma 

Mielenkiintoiseksi kysymys menee siinä vaiheessa, kun pohdimme mitä kriteeristöä vastaa organisaatio tulee auditoida tietoturvatasoauditoinnissa. Klassinen tulkinta on, että tällöin käytetään vain Vahti 2/2010 liitteen 5 vaatimuksia. Kuitenkin, mikäli organisaatio auditoidaan tietoturvatasoja vastaan viranomaisauditointina, niin tällöin auditoinnissa tulee arvioida 2/2010 lisäksi seuraavien Vahti-ohjeiden täyttyminen [2]:
  • Sisäverkko-ohje (VAHTI 3/2010), 
  • Teknisen ICT-ympäristön tietoturvataso-ohje (VAHTI 3/2012) ja 
  • Valtionhallinnon toimitilojen tietoturvaohje (VAHTI 2/2013). 
(Kannattaa myös huomata, että tällöin korotetun tai korkean tason ympäristö ei saa olla suoraa yhdessä internettiin [3].)

Ja jotta asiaa saataisiin vielä hämmennettyä, niin uusi Vahti 2/2014 Tietoturvallisuuden arviointiohje määrittää [4], että tietoturvatasovaatimuksia toteutettaessa ja arvioitaessa on huomioitava VAHTI 2/2010 -ohjeen lisäksi erityisesti seuraavat ohjeet:
  • VAHTI 3/2010 Sisäverkko-ohje,
  • VAHTI 3/2011 Valtion ICT-hankintojen tietoturvaohje, 
  • VAHTI 3/2012 Teknisen ympäristön tietoturvataso-ohje, 
  • VAHTI 1/2013 Sovelluskehityksen tietoturvaohje, 
  • VAHTI 2/2013 Toimitilojen tietoturvaohje,
  • VAHTI 4/2013 Henkilöstön tietoturvaohje ja 
  • VAHTI 5/2013 Päätelaitteiden tietoturvaohje.
Vahti 2/2014 ohjeesta tulee huomata, että "arviointioh­jeen tavoitteena on tukea,kehittää ja lisätä valtionhallinnon tietoturvalli­suuden arviointeja. Ohje on valtionhallinnon tietoturvallisuuden arviointien yleisohje ja se korvaa aikaisernmat ohjeet Tietoturvallisuuden arviointi val­tionhallinnossa, VAHTI 8/2006 sekä Tietoturvallisuuden hallintajärjestelmien arviointisuositus,VAHTI 3/2003".
Jos siis olen menossa auditoimaan tietoturvatasoa vastaan, niin montako kontrollia minun tulee katsoa ja mistä ohjeista???


Edellisen pohjalta olen kerännyt oheiseen taulukkoon yhteenvedon eri auditointivaatimuksista.

(Kiitokset Kari Saarelaiselle taulukkoajatuksesta)

Taulukkoa tulkintaan niin, että rivillä 1 on ”perinteinen” tietoturvatasoauditointi. Rivillä 2 on tietoturvatasoauditointi, jolla tähdätään viranomaishyväksyntään tietoturvatasojen mukaisesti. Rivillä 3 on tietoturvatasoauditointi Vahti 2/2014 mukaisesti. Vastaavasti taulukon sarakkeet osoittavat mitkä Vahti-ohjeista tulee missäkin auditoinnissa huomioida. Taulukkoa on myös yksinkertaistettu sen verran, että taulukosta ei näy miten uudet Vahti-ohjeet korvaavat vanhempia ohjeita (Esimerkiksi Vahti 5/2013 korvaa osittain Vahti 3/2010 vaatimuksia päätelaitteiden osalta).

Bonuksena taulukkoon on merkitty myös KATAKRI-auditoinnit. Kuten taulukosta havaitaan, niin KATAKRI-kriteeristöjä ei sovelleta missään tietoturvataso-auditoinnissa.


Näin ollen, jos organisaatio on arvioitu tietoturvatasoja vastaan ennen vuotta 2015, niin tällöin organisaatio on hyvin todennäköisesti arviotu pelkästään Vahti 2/2010 liite 5 ohjetta vastaan. Mikäli organisaatio haluaa, että se arvoidaan tietoturvatasoja vastaan 2015 tai tämän jälkeen, niin arvioinnissa tulee ensin määrittää halutaanko viranomaishyväksyntä tietoturvatasojen mukaisesti vai riittääkö pelkkä "tietoturvatasoauditointi". Jos päädytään, että viranomaishyväksyntää ei tarvita, niin tällöin tulee määrittää mitkä Vahti-ohjeet arvioinnissa tulee huomioida (tai ainakin määrittää toteutetaanko  auditointi Vahti 2/2010 vai 4/2014 mukaisesti).

Entäs korotettu taso? 

Laki ei määritä suoraan, mitkä velvoitteet organisaation tulee täyttää, mikäli se haluaa täyttää korotetun tason (tai korkean tason) vaatimukset. Näin ollen jokaisen tietoturvatasoaudioinnin yhteydessä on äärimmäisen tärkeää määrittää yksikäsitteisesti, mitkä Vahti-ohjeet tulee ottaa mukaan ja minkä tason vaatimuksia tulee tarkastella. Samoin, mikäli olet hankkimassa palveluja ja haluat palvelun olevan jonkun ”tietoturvatasojen” mukainen, niin sinun tulee muistaa huomioida yllä mainitut vaihtoehdot.

Terveisin
Antti