Johtaja - kanna vastuu ja määritä politiikka

Turvasatama

Tietoturvallisuus palveluiden tuottamisessa, osa 3

Tarkistuslistaa XaaS-palveluita hankkivalle

Kuten tässä sarjassa on jo havaittu, ulkoistettuja palveluita hankittaessa, joista oikeat pilvipalvelut ovat vain yksi tuotantomalli, eteen tulee lukuisa määrä ad hoc tyyppisiä, ratkaisavia asioita. Itse suosittelen ehdottomasti tutustumaan Cloudsecurityalliance.orgin tuottamaan materiaalin, keskeisimpänä heidän tietoturvaohjeistukseensa – Security Guidance for critical areas of focus in cloud computing V 3.0. Toinen suosittelemisen arvoinen asiakirja on NISTin Guidelines on Security and Privacy in Public Cloud Computing. Seuraava listani on osittain kokoelma edellisistä asiakirjoista ja muista kokemuksista ja keskusteluista esille nousseita suosituksia, järjestys on ihan tajunnanvirtatasolla:

1. Tarkista ja selvitä, onko palveluiden ulkoistaminen ylipäätään mahdollista ja mikäli on, millaisia rajoituksia tietoturva- tai yksityisyydensuojavaatimusten osalta vastaan tulee?

On palveluita, joiden ulkoistamisessa pitää olla erityisen huolellinen johtuen joko niiden liiketoimintakriittisyydestä (raha, maine, muut syyt) tai tietoturvallisuudesta (L-E-S). Henkilötietoja sisältävien palveluiden osalta täytyy tuntea henkilötietolaki ja muu lainsäädäntö käsiteltäessä ja siirrettäessä henkilötietoja. Palaan näihin erityskysymyksiin seuraavissa osissa.

2. Voitko salata tiedot – miten avaintenhallinta on toteutettu?

Nettiin voi tallentaa mitä tahansa tietoa, myös pilvipalveluihin, kunhan tiedon salauksesta on huolehdittu myös salausavainten tasolla. Nettiin on julkaistu useita kriittisiä, salassa pidettäviä asiakirjoja tyyliin ”jos minulle tapahtuu jotakin, riittävän monella henkilöllä on avaimet salaisuuksien purkamiseksi”. Se, että palvelutoimittaja mainostaa tiedonsalausta, voi yksinkertaisimmillaan tarkoittaa valitettavasti vain sitä, että tietoliikenneyhteys palveluun voidaan tarvittaessa suojata SSL-salauksella. Tiedon salausta käytetään liikaa yleisenä markkinointijargonina, joka ei välttämättä oikeasti tarkoita mitään.

3. Sopimuksen ymmärtämistä ei voi ylikorostaa!

Riippuen käyttöön hankittavasta tai kilpailutettavasta palvelusta, organisaation ja toimittajan välisen sopimuksen tärkeyttä ei voi korostaa liikaa. Organisaatio saa sen perusteella palvelua ja vastaavasti toimittaja voi laskuttaa palvelusta sopimuksen mukaisesti. Jos jokin asia ei ole sopimuksessa, voit varautua ylimääräiseen kädenvääntöön kyseisestä asiasta. Mitä aidommasta pilvipalvelusta on kyse, varaudu sitä yksipuolisempaan sopimusmalliin ”Ota tai jätä, otat kuitenkin!”.

4. Miten business toimii käyttökatkon aikana? Ulkoistetun palvelun osalta tilanne on yleensä haastavampi kuin itse palvelua tuotettaessa.

Jotta organisaatio voi arvioida palvelun ulkoistamisesta syntyviä riskejä, sen täytyy tietää kohtalaisen tarkasti se, miten toimittaja palvelua tulee tuottamaan. Tällöin voidaan arvioida tästä syntyvät riskit sekä häiriöiden todennäköisyys, kesto sekä vaikutukset liiketoimintaan. Vaikka ulkoistetut palvelut, etenkin globaalit pilvipalvelut ovat saatavuuden osalta hyvässä maineessa, useimmilta toimittajilta löytyy lähihistoriasta yksi tai useampia jopa tuntien mittaisia käyttökatkoja.

5. Miten voit varmistua siitä, että voit vaihtaa tarvittaessa palvelua?

Eräs itse tuotetun palvelun etu on riippumattomuus; ei tarvitse huolehtia siitä, että nyt x vuoden päästä organisaatio joutuu (julkishallinnossa) monimutkaiseen kilpailuttamissessioon, jonka pitää mennä hankintalain mukaisesti – by the book. Samoin itse tuotettaessa palvelua etuna on myös se, että tällöin ei joudu miettimään sitä, miten sopimuksissa ja oikeassa elämässä huolehditaan siitä, että voimme tarvittaessa siirtää palvelut nykyiseltä toimittajalta toiselle tai (ainakin teoriassa) sisäistää eli ottaa takaisin ne omaan hallintaan. Niin, aivan varmastihan toimittaja lupaa auliisti auttaa organisaatiota palvelua vaihdettaessa ("Hyvästi") ?

6. Kuinka huolehdit integraatioista tietoturvallisesti eri palveluiden välillä?

Mitä useampi tietojärjestelmä, sitä useampia integraatioita ja muita rajapintoja niiden välille rakennetaan. Kun kaikki pyörii omassa konesalissa omassa sisäverkossa, kokonaisuuden suunnittelu, hallinta ja valvonta sekä tietoturvallisuuden toteuttaminen ja valvonta on vielä kohtalaisen helppoa. Entäs jos vaikkapa viisi palvelua ulkoistetaan ja edes osalla niistä tulee eri toimittajat. Miten voit toteuttaa, kuinka kauan kestää ja maksaa sekä miten huolehdit näiden tietoliikenneyhteyksien riittävästä tietoturvallisuudesta? Varaudu pahimmassa tapauksessa show stoppereihin!

7. Kuinka yksityiskohtaisella lokitasolla saan tietoa palveluntuottajan ylläpitämien virtuaalipalvelinteni toiminnasta?

Suosikkiongelmakysymykseni liittyy virtuaalipalvelinympäristön hallintaan. Jokainen, joka on rakentanut tai operoinut virtuaalipalvelin- tai työasemaympäristöä, tietää kuinka kätevää ja nopeaa on ottaa snapshot tai muu image-tiedosto virtuaalikoneesta ja heittää se vaikkapa omalle usb-kovalevylle ja tehdä sille tarkempaa analyysiä rauhassa kotikoneella. Miten organisaatio voi varmistua siitä, että toimittajan henkilöstö noudattaa sovittuja ohjeita ja toimintatapoja (turvallisuussopimusta), ellei kaikesta virtuaalipalvelinten toiminnasta ja hallinnasta tuoteta yksityiskohtaista, kaiken kattavaa lokia, jonka organisaatio saa halutessaan / automaattisesti tarkistettavaksi?

8. Miten tietosi varmistetaan – hei, ei siis monisteta!

Pilvipalveluita mainostetaan sillä, että tiedot replikoidaan useampaan fyysiseen paikkaan, jopa eri maanosiin. Tämä ei ole tietojen varmuuskopiointia vaan tiedon saatavuudesta huolehtimista. Jos toimittajan levyjärjestelmässä tapahtuu merkittävä häiriö, joka replikoituu myös muualle, toimittajan pitää kyetä palautumaan aikaisempiin versioihin. Miten tämä on sopimuksissa huomioitu? Entäs voiko organisaatiolla olla jossakin oma suojakopio sen omistamista tiedoista vai luotetaanko pelkästään toimittajaan?

9. Mitä jos toimittajaani, palvelun muuta asiakasta tai minua vastaan hyökätään?

Käytettäessä jaettua kapasiteettia, niin tietoliikenteen kuin palvelinkapasiteetin osalta, saattaa yksittäinen palvelunestohyökkäys tai muu tekninen ongelma aiheuttaa haittaa ja vahinkoa myös muille asiakkaille kuin sille, jota DoS tai alkuperäinen ongelma koskee. Ammattitaitoisella toimittajalla on tätä varten harjoiteltu toimintamallit ja oma ryhmä, joka pystyy ottamaan tällaiset erityistilanteet omaan johtoon ja hallintaan. Mitä huonompi sopimus, SLA ja sanktiot, sitä vähemmän toimittajalla on tarpeita tällaista toimintaa kehittää ja harjoitella.

10. Millaista (tietoturva)raportointia palvelusta on saatavilla?

Jälleen kerran jos verrataan itse tuotettuun palveluun, ollaan hyvin pitkällä sopimuksen varassa ja toimittajan ”armoilla”. Liiketoiminta- ja ict-johtoa kiinnostaa yleensä raportointi ja sen perusteella tapahtuva palvelun- ja kapasiteetinlaskutus, mutta tietoturvallisuudesta tulisi olla saatavilla ainakin perustason raportointi. Jos raportointia ei ole saatavilla, edes erikseen tilattaessa ja maksettaessa, tulee se herättämään huolestuneita kysymyksiä yleensä palvelun laadusta. Miten toimitaan siinä tapauksessa, että mahdollisen väärinkäytöksen / rikoksen selvittelyssä tarvitaan lokitietoja, mutta toimittaja ei kykene niitä tuottamaan? Tai julkisuudessa leviää tieto tunnetusta ko. palvelun infrastuktuuriin liittyvästä kriittisestä tietoturvahaavoittuvuudesta, mistä organisaatio saa tietää siitä, onko se on korjattu?

Jatkuu ensi viikolla …

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Tietoturvallisuus palveluiden tuottamisessa, osa 2

Millaista pilveä tarvitaan - omasta konesalista eroon?

XaaS - terminologiaa

Itse käytän näistä termeistä seuraavia kuvauksia

IaaS – Infrastructure as a Service-mallissa organisaatio ostaa käyttöönsä kaikkia perinteisiä palvelinympäristön tuottamiseen tarvittavia komponentteja (prosessori-, tallennus-, tietoliikennepalvelut). Organisaatio pystyy hallitsemaa palvelimia tai niissä ajettavia sovelluksia käyttöjärjestelmätasolla sekä käytössään olevaa tallennuskapasiteettia ja tietoliikennettä esimerkiksi palomuuritasolla. Sen sijaan organisaatio ei pysy hallitsemaan tai ohjaamaan IaaS-palvelun taustalla toimivaa palvelun tuottajan rakentamaa virtualisoitua palvelinympäristöä.

PaaS – Platform as a Service-mallissa organisaatio voi kehittää tai toteuttaa toimittajan tuottamassa palvelussa itse kehittämiään tai muulla tavalla tuottamiaan sovelluksia käyttäen palveluntarjoajan tuottamia sovelluskehitysmahdollisuuksia sekä API-rajapintoja. Organisaatiolla on mahdollisuus hallita lähinnä sovellukseen liittyviä asioita sekä sovelluksen tietoturvallisuutta sekä sen edellyttämää palvelinympäristöä esimerkiksi käyttäjähallinnan näkökulmasta. Palveluntarjoaja vastaa käytännössä taustalla toimivasta palvelin-, tallennus- ja tietoliikenneympäristöstä ja sitä kautta kokonaisuuden tietoturvallisuudesta.

SaaS – Software as a Service-mallissa organisaatio ostaa toimittajan tuottaman palvelun sellaisenaan varustettuna niillä ominaisuuksilla, jotka toimittaja on sopimuksessa luvannut palvelun sisältävän. Normaalisti organisaatiolla ei ole juurikaan mahdollista vaikuttaa palvelun tuottamiseen, jossain palveluissa voidaan asiakaskohtaisesti kenties räätälöidä yksittäisiä asetus- tai muita konfiguraatiomuutoksia.

Luovuttaisiinko omasta konesalista?

Olen vuosien varrella vieraillut erilaisissa konesaleissa, hienoimpia ei välttämättä konesaleiksi tunnista, ellei erikseen kerrota. Tilat ovat kliiniset, siistit ja lämmön, kosteuden sekä ilmastoinnin hallinnan osalta toimivammat kuin monet toimistokäyttöön tarkoitetut tilat. Lähinnä tasainen humina ja siellä täällä räkeissä tai ovien takana näkyvät vilkkuvalot kertovat, että jotain siellä tapahtuu. Muistan hyvin, kuinka eräs tuttu kertoi lapselleen työpaikkaansa esitellessään, että ”Iskän tehtävänä on huolehtia, että nämä valot vilkkuvat vihreänä”. Toisaalta, kukapa ei ole törmännyt ”konesaliin”, joka toimii a) it-tukihenkilön pöydän alla tai b) siivouskomerossa - usein jopa vuositolkulla 100% palvelutasolla.

Fyysisen turvallisuuden osalta useimmat oikein toteutetut toimittajien konesalit ovat yleensä paremmin toteutettuja kuin tavallisen organisaation itse rakentamat ja ylläpitämät konesalit. Totta kai poikkeuksia löytyy. Kun palvelun toimittaja keskittää satoja tai tuhansia fyysisiä palvelimia yhteen keskitettyyn sijaintiin, fyysinen turvallisuus voidaan ja pitää toteuttaa paremmalla tasolla mitä yksittäinen organisaatio voi tehdä. Sama koskee yleensä varavoima-, rikosilmoitus-, kulunvalvonta- ja muita tilaturvallisuuteen liittyviä ratkaisuja.

Kuinka monella organisaatiolla on aidosti mahdollista rakentaa 24/7/365-valvottu, vikasietoinen ratkaisu, joka on fyysisesti kahdennettu palvelinlaitteisto ja joka tarvittaessa myös maantieteellisesti on kahdennettu ”riittävän kauaksi” toisistaan? No, jos organisaatiolla on kaksi eri toimipistettä, toki tämä onnistuu, mutta jälleen molempiin paikkoihin pitää investoida merkittävästi näiden konesalien sekä ict- että muuhun teknologiaan. XaaS-tuotantomallien keskeinen idea on päästä tästä kaikesta omasta omaisuudesta ja tekemisestä eroon!

90-luvun NT-opeilla ei tulla enää toimeen

Eräs merkittävimpiä muutoksia, joka aiheuttaa monelle pienemmälle organisaatiolle ongelmia on palvelinteknologian monimutkaistuminen. Olen itse 90-luvulla ”rakentanut”, myöhemmässä vaiheessa 2000-luvulla ollut ottamassa käyttöön useimpien tunnettujen palvelinvalmistajien palvelinympäristöjä. Ei onnistuisi todennäköisesti enää; vikasietoisen virtualisoidun palvelinympäristöhärpättimen, sisältäen levyjärjestelmähimmelin, kuitukytkinhässäkän ja muun tietoliikenteen suunnittelu, toteutus ja hallinnointi on nykyään tehtävä, joka ei onnistu ns. satunnaiselta sunnuntai-it-nanotukihenkilöiltä vaan vaatii yhä syvällisempää erikoistumista.

Edellä kuvatut asiat pätevät suunniteltaessa minkälaista tahansa omien ict-palveluiden ulkoistusta. Käytännössä siis fyysisen / toimitilaturvallisuuden puolelta useimmilla organisaatioilla palveluiden hankkiminen ulkoistettuna palveluna parantaa niiden turvallisuutta.

IaaS – infraa palveluna tai pilvestä

IaaS –palvelua voidaan hankkia usealla eri tavalla. Organisaatio voi hankkia kotimaiselta palveluntarjoajalta vastaavanlaisen konesalikokonaisuuden, jota se on itse ylläpitänyt - toki nykyaikaisemmalla tekniikalla. Ympäristö voi olla dedikoitu sille kokonaan, joka tietoturvallisuuden kannalta tarjoaa organisaatiolle paremman kontrollin kuin sellainen toteutus, jossa organisaation ympäristö toteutetaan joko kokonaan tai osittain käyttäen usealle eri organisaatiolle tarkoitettua palvelinympäristöä (jaettu kapasiteetti).

Kuten olen aikaisemmin tässä blogissa korostanut, tietoturvallisuudessa ei ole olemassa yhtä ainoa oikeaa ratkaisua vaan pitää muistaa lähestyä tilannetta tuotettavien palveluiden näkökulmasta. Tietoturvallisuus ei saa olla itseisarvo! Kuinka kriittisiä palvelut ovat organisaation liiketoiminnalle (jatkuvuus, palvelutasot), millaisia vaatimuksia palvelussa käsiteltäviin tietoaineistoihin liittyy luottamuksellisuuden, eheyden ja saatavuuden kannalta sekä mitkä muut velvoitteet pitää palveluita hankittaessa ottaa huomioon?

Älä unohda näitä

Edellisten ohella pilvipalveluihin liittyvät API-rajapinnat, tietoliikenneyhteydet sekä muut prosessit edellyttävät erityistä huomiota verrattuna omasta konesalista tuotettavaan palveluun. Samoin XaaS-palvelua ei saa ottaa käyttöön, ellei organisaatio ole suunnitellut sitä huolellisesti osana muuta arkkitehtuurisuunnittelua. Tämän ohella XaaS-palveluiden käyttöönotto pitää tehdä hankkeistaa samalla lailla kuin muutkin tietojärjestelmähankkeet, koska muussa tapauksessa todennäköisyys mennä pilven sijaan syvälle metsään, jonne aurinki ei paista – erityisesti tietoturvallisuuden osalta kasvaa oleellisesti.

Olen itse kauhulla kuunnellut tarinoita siitä, miten jokin liiketoimintayksikkö ”meni ja osti ja siirsi kaiken datansa” sinne tai tänne pilvipalveluun itsenäisesti konsultoimatta organisaation tietohallintoa, puhumattakaan selvittämättä ratkaisun tietoturvallisuutta! Halpaa kuulemma oli, varjo-tietohallinto toteaa. Tarina ei yleensä kerro, mitä olemassa olevalle palvelulle tehtiin, todennäköisestihän ne jäävät jonkun muun vastuulle ja kustannukseksi. HUH!

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Tietoturvallisuus palveluiden tuottamisessa, osa 1

Keskeiset tuotantomallit

Organisaatiolla on useita vaihtoehtoisia tapoja ict-palveluiden tuottamiseksi. Ensimmäinen rajaus tulee siitä, kuinka paljon organisaatio haluaa itse osallistua palveluiden tuottamiseen. Käytännössä tällä ensimmäisellä päätöksellä vaikutetaan siihen, tuotetaanko palvelu itse vai ulkoistetaanko se toimittajalle. Palvelua voidaan ajatella tuotettavan seuraavilla eri malleilla:

1. Kokonaan tai pääosin itse tuotettu palvelu

a) tuotetaan itse omassa palvelinsalissa oman henkilöstön toimesta
b) organisaatio omistaa ympäristön, mutta osa tai kokonaan palveluiden tuottamiseen liittyvästä työstä ostetaan toimittajalta
- tietoturvallisuuden osalta vastataan itse hyvin pitkälle kontrolleista

2. Pääosin toimittajalta hankittu palvelu

a) toimittaja vastaa kokonaan palvelinten ja palveluiden ylläpidosta ja tuotannosta, ympäristö on dedikoitu pelkästään organisaation käyttöön
b) kuten edellinen kohta, mutta samaa teknistä ympäristöä tarjotaan myös muiden asiakkaiden käyttöön
- tästä on lisäksi vielä erilaisia variaatioita siitä, missä palvelimet ja asiakkaan tiedot fyysisesti sijaitsevat sekä mistä maasta palveluiden tuottamiseen liittyvää työtä tehdään

- tietoturvallisuuden osalta organisaation mahdollisuudet valvoa kokonaisuutta pienentyy ja toimittajan vastuu kasvaa

3. Aidot pilvipalvelut

a) organisaatio ei ota kantaa siihen, missä sen palvelu ja tiedot sijaitsevat, ketkä näitä palvelimia ja tietoaineistoja ylläpitävät tai millä tavalla toimittaja ylipäätään palvelua tuottaa. Myöskään palveluiden auditoiminen ei ole mahdollista. Palvelua voidaan skaalata helposti tarpeen mukaan ylös- ja alaspäin ja laskutus tapahtuu käytetyn kapasiteetin mukaan.

- käytännössä tätä käytetään useimmissa koti- tai vapaa-ajan käyttöön tarkoitetuissa palveluissa sekä sellaisissa organisaatioiden käyttöön tarkoitetuissa palveluissa, joissa palveluun kohdistuvat vaatimukset ovat sellaisia, että aitoa pilvipalvelua on mahdollista käyttää

- tiedon luottamuksellisuuden merkityksen kasvaessa mahdollisuudet tuottaa palvelua aitona pilvipalveluna heikentyvät, ellei palvelussa ja tietoliikenteessä voida hyödyntää tehokkaasti tiedon salausta ja huolehtia siitä, että salausavainten hallinta on organisaatiolla, ei toimittajalla

- sama koskee saatavuuden osalta; vaikka pilvipalveluiden palvelutasoja on totuttu pitämään hyvänä, useimmissa pilvipalveluissa on koettu jo esimerkkejä pitemmistä tuotantokatkoksista

- organisaation mahdollisuus hallita tai valvoa tietoturvallisuutta on hyvin vähäinen ja pohjautuu sopimukseen, joka voi olla yksipuolinen

Itse tuotettu kapasiteetti – kontrolli organisaatiolla

Jos organisaatio päättää tuottaa palveluita itse, voidaan omassa tuotannossa pyrkiä hyödyntämään niitä samoja teknologioita, mitä kaupalliset toimittajat tekevät, ainoastaan pienemmässä mittakaavassa. Oman palvelutuotannon rakentaminen tulisi tapahtua tällöin nykyaikaisia virtualisointiteknologioita hyödyntäen silloin kun se on esimerkiksi lisenssimallien osalta mahdollista.

Palvelinvirtualisointi ei ole aina se autuaaksi tekevä asia vaan on käyttökohteita, joissa edelleen palvelu pitää tuottaa stand-alone-tyyppisillä dedikoiduilla, omilla palvelimilla. Syynä voi olla em. lisessienhallinnan ohella suorituskyvyn tai tietoturvallisuuden hallintaan liittyvät vaatimukset. Tällöin tekninen tietotekniikkaympäristö koostuu tyypillisesti yhdistelmästä koko infrastruktuurin osalta kaikille jaettuja komponentteja (levy- ja varmistusjärjestelmä, tietoliikenneverkko ja -ympäristö, tietoturvallisuuden yhdyskäytäväratkaisut ja palomuurit) sekä dedikoiduista komponenteista (yksittäiset palvelimet ja niiden omat levyt, virtuaalisesti toteutetut verkko-ympäristöt ja palomuurista erotellut verkkosegmentit).

Mitä vaaroja ulkoistamisessa piilee?

Ennen kuin mennään tietoturvallisuuden osalta löytyviin haasteisiin, aluksi yleishavaintona ulkoistamisen kilpailuttamiseen liittyvät haasteet. Kun organisaatio on tehnyt ensimmäisen merkittävän ulkoistamisen ja haluaa sen jälkeen sopimuskauden loppupuolella kilpailuttaa käyttöpalvelunsa uudelleen laskeakseen kustannuksia, miten voidaan realistisesti arvioida sitä työtä ja kustannuksia, joka syntyy laajaa, monimutkaista, paljon järjestelmien välisiä integraatioita sisältävän kokonaisuuden siirtämisestä vanhalta toimittajalta mahdolliselle uudelle toimittajalle? Tällaiselle meediolle olisi kysyntää…

Eräs ratkaisu on omistaa tekninen tietotekniikkaympäristö itse ja kilpailuttaa siihen ulkopuolelta hankittava asiantuntijatyö. Kun sopimus loppuu tai toimittajasta muusta syystä halutaan päästä eroon, onnistuu se merkittävästi helpommin kuin jos organisaatio on jo siirtänyt eli ulkoistanut koko teknisen tietojenkäsittely-ympäristön toimittajalle.

Tietoturvallisuuden osalta mietittäessä käyttöpalveluiden tuotantomallia tulee olla selvillä liiketoiminnan kannalta ne organisaation vaatimukset, jotka tietotekniikkaympäristön toteutuksessa tulee huomioida. Mitkä ovat luottamuksellisuuden, eheyden ja saatavuuden osalta vaatimukset sekä tarvittava kyky selviytyä erilaisista toimintahäiriöistä tietojärjestelmä- ja laajemmin koko toimintaprosessin tasolla (varautuminen)?

Ulkoistamista tai XaaS-palveluiden käyttöä ei tule pelätä. Mikäli hankintavaiheessa vaatimusmäärittely on kunnossa, tietoturva- ja muu sopimuspuoli saadaan sovittua kuten organisaatio on suunnitellut, tietoturva-auditoinnissa löydetyt havainnot korjattua, auditointi on mahdollista ja palvelusta saadaan sovitun mukaisia raportteja sekä palvelu toimii vaaditut palvelutasovaatimukset täyttäen, ei kai kukaan voi olla muuta kuin tyytyväinen tilanteeseen?

TOP 3 – selvitä nämä ensin huolella ennen kuin hyökkäät pilveen!

1. Onhan organisaatiosi määritellyt ja luokitellut tiedot ja palveluiden tärkeyden liiketoiminnan näkökulmasta? Ja tätä työtä eivät saa tehdä ict - tai tietoturvaheebot.

2. Jaa ulkoistettavat & mahdollisesti pilveistettävät palvelut kolmeen koriin: mahdottomat tai erittäin hankalat toteuttaa, mahdolliset sekä helpot eli pikavoitot. Aloita pikavoitoista!

3. Tee edellisten perusteella riskienarviointi ottaen huomioon myös muut liiketoiminnan vaatimukset näille palveluille. Tee malli-swot. Lähde tämän perusteella miettimään, millainen organisaatiosi strategia voisi olla.

Ensi viikolla pureudutaan tarkemmin eri XaaS-malleihin tietoturvallisuuden näkökulmasta.

Kotikäyttövinkki – salasanat talteen!

Mikäli olet opettanut kotikoneen selaimellesi keskeiset eri palveluiden salasanat, olet törmännytkin jo siihen ongelmaan, että miten ne salasanat muistaa muilla koneilla? Ei mitenkään, ellei niistä tee joko a) liian yksinkertaisia tai b) käytä samoja salasanoja useimpiin palveluihin. Älä kuitenkaan toimi näin vaan lataa käyttöösi ilmainen KeePass-apuohjelma! (valitse uusin Professional Version). Voit sen avulla ylläpitää tiedot salasanoista vahvasti salatussa tiedostossa (AES) ja voit kuljettaa tämän tiedoston avulla salasanasi mukana. Saat myös automatisoitua salasanojen syöttämisen. Windowsin ohella ohjelman saa ladattua yleisimpiin muihinkin käyttöympäristöihin, myös mm. Android- ja iOS-laitteisiin.

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

10 kohdan ohje kilpailuttamiseen – osa 3

8. Käyttöönotto – mitä hallitummin, sitä parempi

Riippuen hankitun kohteen tuotantomallista, saattaa nakki viuhahtaa oman organisaation tietohallintoon tai sitten enemmän tai vähemmän ulkoistetulle taholle. Käyttöönotoissa mielenkiintoinen haaste tulee testauksesta ja/tai pilotoinnista. Kuinka kauan ja perusteellisesti ratkaisua tulee tai voi pilotoida ennen varsinaista, laajamittaisempaa käyttöönottoa? Tähän ei ole olemassa yhtä ratkaisua, vaan pitää miettiä jokaisessa käyttöönotossa erikseen.

Samoin tilanteeseen vaikuttaa se, onko taustalla vanhaa järjestelmää, joka tullaan korvaamaan jolloin näitä voidaan ajaa rinnakkain vai onko kyseessä aivan uusi prosessi ja it-järjestelmä. Jos kyseessä on kokonaan ulkoistettuna ostettu SaaS-palvelu, teoriassa käyttöönoton pitäisi olla yksinkertainen verrattuna esimerkiksi organisaatiolle räätälöityyn ratkaisuun.

Muistathan tehdä tarvittavan tietoturva-auditoinnin?

Vaikka hankittu järjestelmä ei sisältäisi tietoaineistojen luottamuksellisuuden kannalta salassa pidettävää tietoa, tällöin tietojen eheys ja ennen kaikkea saatavuus ovat sitäkin tärkeämmässä roolissa. Mitä tärkeämmästä prosessista ja it-järjestelmästä organisaation liiketoiminnalle tässä on kyse, sitä tärkeämpää on huolehtia palvelun auditoinnista vaatimusmäärittelyä ja sopimusta vastaan.

Jos ja kun auditoinnissa paljastuu poikkeamia, niiden korjaamisesta tulee huolehtia siten, että järjestelmää ei oteta tuotantokäyttöön ennen kuin kaikki vähintään kriittiset ja riskiarvioin perusteella matalamman tason poikkeamat on korjattu. Auditointi maksaa, mutta niiden korjaaminen tuotantovaiheessa tai niiden kautta tapahtuvat tietoturvapoikkeamat maksavat sitäkin enemmän!

9. Tuotannonaikaisesta toiminnasta huolehtiminen

Kuoharit on korkattu ja järjestelmä on siirtynyt tuotantoon eli ns. jatkuvaksi palveluksi. Tästä alkaa toivottavasti pitkä ja rauhallinen jakso, jossa palvelua tuotetaan sopimuksen mukaisesti ilman sen suurempia huolia. Jotta mahdolliset käytönaikaiset ongelmat eivät aiheuta ylimääräistä kädenvääntöä, tulisi asiat olla sovittu etukäteen.

Edeltävissä osissa olen korostanut vaatimusten ja sopimusten merkitystä, haasteiden tullessa vastaan sopimuksen merkitys edelleen korostuu.

Tietoturvallisuuden hallinnan osalta keskeisimpiä asioita ovat palveluun liittyvien muutosten hallinta (uudet versiot, tietoturva- ja muut päivitykset) sekä palvelun sopimuksenmukaisten palvelutasojen saavuttaminen ja tietoturvallisuuden osalta tätä koskeva raportointi, ml mahdolliset poikkeamat.

Helpointa tämä on toteuttaa kuvaamalla jo hankintavaiheen määrittelyvaiheessa kaikki ne raportit ja muut toimintamallit, jotka toimittajan täytyy tuottaa osana säännöllisiä asiakas-toimittajayhteistyötapaamisia yhteisesti läpikäytäväksi. Entäs kun väistämättä tarvitaan muutoksia, kuka kantaa vastuun?

Ota RACI-malli avuksi

Koska yllätyksiä tulee joka tapauksessa vastaan, miten niihin voidaan varautua? Suosittelen käyttämään RACI-mallia. Mallissa R-kirjain tarkoittaa Responsible eli kenen vastuulla ko. toiminnon tai asian tekeminen on.

A eli Accountable tarkoittaa roolia, jolla on valtuus tehdä tarvittavat päätökset, esimerkiksi prosessin omistajaa.

C eli Consulted voi olla henkilö tai ryhmä, jota tarvitaan toteutuksessa apuna kaksisuuntaisesti, nimensä mukaisesti konsultoivassa roolissa.

I eli informed on henkilö(t) tai ryhmä, jolle toiminnasta tulee yksisuuntaisesti raportoida, esimerkiksi kun toimenpide on valmis.

Kaksi ensimmäistä eli R ja A tulisi olla normaalisti vain yksi nimetty henkilö. Sama henkilö ei voi olla useammassa roolissa, poikkeuksena jossakin tilanteessa R+A voivat olla sama henkilö.

Jossakin yhteydessä mukaan tulee myös S-kirjain eli RASCI-malli, jolloin S eli Support-henkilöt auttavat R-henkilöä tavoitteen saavuttamisessa.

10. Vanhan järjestelmän alasajo – samalla myös kustannusten alasajo

Miksi organisaatio on jotain hankkinut? Yksi perimmäinen syy on tehokkuuden ja tuottavuuden parantaminen. Nämä voidaan saavuttaa usealla eri tavalla, prosessien ja henkilöiden toimintatapa yhdistettynä uusien ict-järjestelmien tuomiin mahdollisuuksiin on se perinteinen keino.

Valitettavan usein jää tekemättä eräs keskeisimmistä toimenpiteistä käyttöönoton loppuvaiheessa; hallittu vanhojen jälkien siivoaminen eli vanhojen, korvattujen prosessien ja niihin liittyvien tietojärjestelmien alasajot. Kuinka moni on törmännyt siihen, että vanha it-järjestelmä jää kummittelemaan? Kun olen kysynyt tähän syitä, ovat ne moninaiset. Vakiovastaus kiireen ohella eräs syy on pelko, että uusi järjestelmä ei toimi tai jostakin syystä tarvitaan vanhassa järjestelmässä lojuvia tietoaineistoja.

Hyvään projektisuunnitelmaan kuuluu se, että siinä määritellään yksiselitteisesti vanhojen prosessien ja it-järjestelmien alasajot siten, että niistä ei jää roikkumaan piilokustannuksia. Siis kaikki turhat palvelimet, lisenssit, tietoliikenneyhteydet, valvonta- ja hallintapalvelut pois – on ne tuotettu itse tai ostettu palveluna!

Tällä edesautetaan myös sitoutumista uuteen prosessiin ja it-järjestelmään. Jos vanha, kaikille tuttu ja helppo ratkaisu jää käyttöön, osa käyttäjistä kaikesta ohjeistuksesta huolimatta jää sen käyttäjiksi eivätkä siirry ja sitoudu uuteen prosessiin ja järjestelmään. Tämän takia vanha järjestelmän käyttö tulee esimerkiksi estää ja rajoittaa vain siihen tarkoitukseen, mitä suunnitelmissa on sovittu.

Koska vanha tietojärjestelmä saattaa sisältää salassa pidettäviä tietoaineistoja, organisaation tulee huolehtia näiden tietojen tietoturvallisesta hävittämisestä, näihin kuuluu myös vanhan järjestelmän varmuus- ja suojakopiot.

Nyt on perattu tietojärjestelmien hankintaa useamman blogin voimalla! Ensi viikolla alkaa useampiosainen kokonaisuus, jossa käydään läpi virtualisoitujen, dedikoitujen ja jaettujen ICT-käyttöpalveluiden haasteita tietoturvallisuuden näkökulmasta. Näiden jälkeen sitten erikseen jutustellaan pilvipalveluista, joka onkin kokonaan ihan eri juttu.

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

10 kohdan ohje kilpailuttamiseen – osa 2

5. Tarjousten arviointi – tietoturvallisuuden pisteyttäminen

... pitäisi olla nykyaikana pässinlihaa. Jos aikaisemmin on ollut mahdollista kenties ”säätää” pisteytystä, näin ainakin urbaanit legendat väittävät, niin nykyisin tarjouspyyntö pitäisi olla toteutettu siten, että toimittajalla on varsin hyvä ennakkokäsitys siitä, millaisia pistemääriä he tulevat saavuttamaan. Samoin kaikkien pisteytettävien, arvosteltavien vaatimusten osalta tulisi olla selkeä perustelu siitä, miksi jokin toimittaja on jäänyt ko. kohdassa eniten pisteitä saaneesta toimittajasta. Voiko pisteytystä koskaan avata ja perustella liian perusteellisesti, tuskin?!

Kuten aikaisemmin totesin, tietoturvallisuuden osalta kannattaa tarkkaan miettiä, mitä laitetaan toivottaviksi, arvioitaviksi eli pisteytettäviksi vaatimuksiksi. Otetaan esimerkki. Tarjouspyynnössä on 15 pisteytettävää vaatimusta, organisaatio saa kaikkiaan 12 tarjousta. Jonkun pitää siis vertailla nämä keskenään, tehdä sen perusteella puolueeton pisteytys ja perusteltava tämä kirjallisesti. Jos tähän menee keskimäärin aikaa *hyvin tehtynä* 10 minuuttia / vaatimus, tarkoittaa 180 kohdan pisteytys 30 tuntia. Jos toimittajat ovat perusteellisia ja haluavat maksimipisteet, he liittävät hyvin perusteelliset kirjalliset kuvaukset jokaiseen pisteytettävään kohteeseen ja tämän takia aikaa, energiajuomaa ja hikeä kuluu sekä toimittajilla näiden tuottamiseen että organisaatiolla perustelujen vertailemiseen!

Pakkopullavaatimuslistat vain kasvavat?

Jos tarjouspyynnössä on suuri määrä pakollisia, tietoturvallisuuteen liittyviä vaatimuksia, jotka on vain pakko täyttää, saattaa se tuntua toimittajista hieman pakkopullalta valita kaikkiin 300 kohtaan toteamus että Kyllä, täytämme tämän vaatimuksen. Miksi määrä on näin suuri tietoturvallisuuden ja yleensä hankittavan kohteen vaatimusten osalta? Tämä johtuu siitä, että jos toiminnallisuuksia ja ominaisuuksia ei ole vaadittu yksityiskohtaisesti tarjouspyynnössä ja saada sitä kautta mukaan myös lopulliseen sopimukseen, ei kukaan toimittaja suostu tekemään mitään laskuttamatonta, sopimuksen ulkopuolista työtä sopimuksen allekirjoittamisen jälkeen. Perinteinen muna-kana-(euro)-ongelma.

6. Hankintapäätös

Hyvin tehty hankintapäätös ei jätä mutinoille tai muulle vatuloinnille, puhumattakaan markkinaoikeusprosessiin sijaa. Mitä paremmin tarjouspyyntö on suunniteltu, vaatimukset sekä pisteytys on toteutettu, sitä ainakin teoriassa parempia tarjouksia organisaatio tulee vastaanottamaan, jonka tulisi näkyä myös hankintapäätöksen ja koko prosessin laadukkuudessa.

On selvää, että jos kahden toimittajan välille jää minimaalinen piste- ja prosenttiero, hankintapäätös ja pisteytyksen perustelut syynätään erityisen tarkasti. Muille sijoille tulleille toimittajille tarjousprosessi ja hankintapäätös sekä mahdollisuus asianomaisena tutustua ainakin osaan muiden toimittajien julkiseksi luokitellusta tarjousaineistoista, vähintään hintatietoihin, tarjoaa selkeän mahdollisuuden kehittää omaa kilpailukykyä, prosessia ja hintatietoisuutta.

7. Pääpaino sopimukseen

Jos hankinnasta pitäisi korostaa kaksi sanaa, olisivat ne vaatimusmäärittely ja sopimus, yksittäisenä sanana valitsisin sanan sopimus. Mitä pitemmästä sopimuskaudesta optioineen on kysymys, sitä tärkeämmässä roolissa sopimus on. Tiedän, että pienemmissä organisaatioissa on suuri houkutus oikaista ja käyttää esimerkiksi toimittajan tarjoamaa sopimusmallia, mutta miksi antaa pirulle pikkusormi? Suosittelen käyttämää omaa sopimusmallia, jonka laatimisessa voi nojautua pitkälle olemassa oleviin, jo muualla käytössä oleviin sopimusmalleihin, sopimusehtoihin ja hyviin käytäntöihin. Älä säästä väärässä kohtaa vaan käytä tarvittaessa ulkopuolista apua – samaa sopimusmallia voit käyttää pohjana jatkossakin.

Jos eli kun toivottavasti tarjouspyynnössä on ollut mukana organisaation oma sopimusmalli, jonka organisaatio edellyttää toimittajan tarjouspyynnössä hyväksyvän ja allekirjoittavan sellaisenaan, sopimusneuvotteluiden pitäisi olla ”siinä”. Lyhyt kahvihetki ja nimet alle. Jos sopimusneuvotteluihin toimittajan kanssa alkaa kulua aikaa ja sopimusmuutosehdotuksia ilmaantua, on se yleensä huolestuttava merkki ja kannattaisi kaivaa esiin se kuuluisa pilli – ja puhaltaa siihen!

Kiire ei koskaan saisi olla se syy, minkä takia sopimusten allekirjoitusta joudutaan kiirehtimään!

Kolmannessa ja viimeisessä osassa keskitytään hankinnan hyväksymisestä ja viemisestä tuotantoon ja tuotannon aikaisesta toiminnasta ja raportoinnista. Eikä unohdeta vanhan järjestelmän tietoturvallista, hallittua alasajoa ja sitä kautta tapahtuvaa kustannusten minimoimista.

Kotikäyttövinkki – miten rajoittaa ja turvata kotona nettisurfausta?

Itse suosittelen ohjeistusta ja koulutusta, mutta on tilanteita, joissa tarvitaan teknistä tietoturvaa. Blue Coat K9 Web Protection on loistava ilmaisohjelma kotikäyttöön nettikäytön rajoittamiseen. Ohjelmalla voi estää tietoturvaa vaarantavien sivustojen (Spyware / Malware sources) ohella myös aikuisviihde- tai muut yli 70 kategorian perusteella valittujen sivujen avaamisen. Voit sallia yksittäisiä sivustoja tai kategorioita salasanan avulla. Ohjelma tuottaa kattavan tilastoinnin netin käytöstä sekä mahdollisuuden estää nettikäyttö myös kellonajoittain. Ohjelma vaatii tuoteavaimen, jonka saa lataamisen yhteydessä omaan sähköpostiin.

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

10 kohdan ohje kilpailuttamiseen – osa 1

Kukapa ei haluaisi hankkia kotiin aina välillä jotain uutta kivaa? Fiilis ei ole välttämättä yhtä hyvä, kun organisaatiossa tulee tarve lähteä kilpailuttamaan uutta ratkaisua. Vaikka keskityn tässä blogissa tietoturvallisuuteen, tuon tässä esille myös muita osa-alueita, joihin kilpailuttamisessa tulee kiinnittää huomiota.

1. Mitä ollaan hankkimassa?

2. Kilpailuttaminen ei ole itsestäänselvyys

3. Vaatimukset takaavat laadun

4. Huono tarjouspyyntö – takuuvarmat ongelmat

5. Tarjousten arviointi – tietoturvallisuuden pisteyttäminen

6. Hankintapäätös

7. Pääpaino sopimukseen

8. Käyttöönotto

9. Tuotannonaikaisesta toiminnasta huolehtiminen

10. Vanhan järjestelmän alasajo – kustannusten kotiuttaminen

Tässä ensimmäisessä osassa keskitytään neljään ensimmäiseen kohtaan ja seuraavassa osassa käsitellään loput.

1. Mitä ollaan hankkimassa?

Valitettavan usein kuulen tapauksesta, jossa palkataan konsultti määrittelemään, mitä meidän tulisi hankkia! Jos organisaatio ei itse tiedä, mitä sen toiminta edellyttää, ulkopuolisen konsultin käyttäminen ei ole välttämättä se oikea tapa purkaa ongelmaa. Kuinka moni menee autokauppaan ja pyytää myyjää kertomaan, millaisen auton sinä tarvitset? Kun organisaatiolla on itsellään tarvittava tieto ja osaaminen, ulkopuolista tahoa voidaan käyttää apuna vaatimusten määrittelyssä, muiden asiakirjojen laadinnassa sekä saapuvien tarjousten käsittelyssä. Konsultti on hyvä renki, mutta isännäksi sitä ei saa päästää!

2. Kilpailuttaminen ei ole itsestäänselvyys

Nykyisin pidetään liian itsestään selvänä sitä, että nyt meidän pitää kilpailuttaa tai ulkoistaa sitä tai tätä. Ensimmäiseksi tulisikin selvittää, onko kilpailuttaminen ylipäätään mahdollista; ovatko meidän vaatimukset sellaisia, että markkinoilta löytyy toimittajia, jotka vaatimukset voivat täyttää ja että käytettävissä oleva budjetti on realistinen, laskettuna järjestelmän elinkaarikustannuksilla. On tilanteita, joissa tässä kohtaa havaitaan, että kohdetta ei ole mahdollista hankkia toimittajilta vaan se pitää tuottaa itse. Kaikkea ei ole mahdollista eikä järkevää ulkoistaa, vaikka kuinka mieli tekisi!

3. Vaatimukset takaavat laadun

Omasta mielestäni kilpailutuksen onnistumisen merkittävin osa-alue on vaatimusmäärittely. Siinä voidaan tehdä pahimmillaan sellaisia virheitä, jotka saattavat joko aiheuttaa sen, että kukaan ei tarjoa mitään (mahdottomat, liian tiukat vaatimukset) tai kokonaisuuden, jonka hinta tulee vuosien myötä karkaamaan käsistä (liian yleisiä vaatimuksia, merkittäviä vaatimuksia puuttuu).

Itse suosittelen määrittämään tietoturvallisuuden pääsääntöisesti pakollisiksi vaatimuksiksi, koska jos organisaatio määrittää pisteytettäviä, tietoturvallisuuteen liittyviä toivottavia vaatimuksia, tällaisten asioiden arvioiminen objektiivisesti vaatii paljon aikaa ja osaamista sekä ennalta-arvaamattomia kustannuksia.

Tietoturvallisuuteen liittyvät vaatimukset voidaan jakaa lakisääteisiin, sidosryhmiltä & asiakkailta tuleviin, jotka voivat olla jo olemassa olevissa sopimuksissa sekä muiden vaatimusten kautta tuleviin, esimerkiksi jokin PCI-DSS tai jokin muu tunnettu viitekehys.

Suosittelen myös määrittämään kaikki keskeiset käyttöönottoon tietoturvallisuuden kannalta edellytettävät vaatimukset osaksi käyttöönoton hyväksymisedellytyksiä. Tällä vältät sen tilanteen, että toimittaja toteaa ”sovitaan toi tietoturvaraportointi siinä vaiheessa kun järjestelmä on tuotannossa” –tyyppiset ongelmat. Jotta järjestelmä saadaan käyntiin ja toimittaja saa viimeiset maksupostit käyttöönotosta ja voidaan siirtyä jatkuvien palveluiden mukaiseen laskutukseen, nämä pienet tietoturvallisuuteen liittyvät haasteet tulee yleensä hoidettua ennakoivasti kuntoon. Jos jotain jää tekemättä, motivoi toimittajaa jättämällä sopiva summa maksettavaksi vasta siinä vaiheessa kun kaikki on kunnossa – esimerkiksi auditoinnissa havaitut, yhteisesti sovitut korjaukset on suoritettu loppuun.

Tarjouspyynnön vaatimukset tulee päätyä sellaisenaan osaksi sopimusta, jossa voi olla myös liitteenä erillinen turvallisuussopimus. Huolehdi myös tarvittavien auditointimahdollisuuksien sisällyttämisestä osaksi käyttöönottoa sekä jatkuviin palveluihin. Sitä saa mitä vaatii – jos sopimukset ovat kunnossa!

Apuna kannatta käyttää JHS 173 ICT-palvelujen kehittäminen: Vaatimusmäärittely.

4. Huono tarjouspyyntö – takuuvarmat ongelmat

Etenkin julkishallinnon kilpailutuksissa hankintalain syvällinen tuntemus on edellytys onnistuneelle kilpailutukselle. Sama koskee hankkivan organisaation ohella tarjoajia. Valitettavan usea, jopa loistava, mahdollisesti kilpailutuksen voittanut tarjous on jouduttu hylkäämään pienen muotovirheen ohella. Mitä selkeämpi ja yksiselitteisempi tarjouspyyntö on, sitä helpompi toimittajien on siihen vastata.

Tarjouspyynnössä organisaatio mahdollistaa kysymykset tiettyyn ajankohtaan mennessä, tätä mahdollisuutta tulee käyttää. Vaikka kaikki kilpailussa olevat toimittajat saavat kaikki kysymykset ja organisaation niihin toimittamat vastaukset tietoonsa, eivät kaikki välttämättä ymmärrä oikealla tavalla muotoillun kysymyksen perusideaa.

Juttu jatkuu Rouskun seuraavassa blogauksessa.

Kotikäyttövinkki – uups, poistit väärät tiedostot?

Kukapa ei joskus vahingossa poistaisi vääriä tiedostoja? Oletuksenahan kannattaa dyykata roskakori sekä kokeilla kansion kohdalla hiiren kakkospainikkeen valinta Palauta aiemmat versiot. Jos näistä poistettua tiedostoa ei löydy, voit kokeilla erillistä Undelete-ohjelmaa. Suosittelen kokeilemaan MiniTool Power Data Recovery-ohjelmaa, jonka ilmainen kotikäyttöversio sallii enintään 1 Gt tiedostomäärän palauttamisen

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Ict-henkilöstön 7 kuolemansyntiä - tietoturvallisuus

Ei kahta ilman kolmatta eli päätän tämän syntisarjan henkilöstön ja johdon jälkeen katsauksella siihen, mitkä ovat ict-ammattilaisille sellaisia asioita, joita ei mielestäni riittävästi tietoturvallisuudessa huomioida.

1. Huomioi tietoturvallisuus suunnittelussa

Valitettavan usein ict-ammattilaisetkaan eivät muista ottaa huomioon tietoturvallisuuteen liittyviä menettelytapoja uusia prosesseja / palveluita / tietojärjestelmiä suunniteltaessa. Yleisimmät perustelut liittyvät kiireeseen, tietämättömyyteen sekä selkeän projekti-/suunnittelumallin olemassaoloon. Jos organisaatiossa on käytössä projektisalkunhallinnan prosessit sisältäen tietoturvallisuuden, ongelmaa ei pitäisi olla.

Etenkin softanvääntäjille voisi painottaa ”edes” OWASP top 10-riskien huomioimisesta koodissaan, auditoinneissa löytyy vielä aivan liikaa ihan perustason puutteita, esimerkiksi tietojen syötteentarkistuksen osalta.

Sama koskee sekä tietoliikenne- (salaus, palomuuri- ja muut säännöt) että palvelin- ja työasemaympäristöjä (esimerkiksi kovennukset).

2. Huolehdi it-hallinnan prosessien toiminnasta!

Jos hyvin suunniteltu on kokonaan tekemättä, sama koskee organisaation käyttöön ottamia Itilin toimintaprosesseja. Jos tietoturvallisuus ei ole osana muutoshallintaa, tai muita keskeisiä organisaation Itilistä poimimia ja käyttöön ottamia toimintamalleja, tietoturvallisuus elää omaa elämää tai jää kokonaan huomioimatta. Esimerkiksi miten ja kuka hyväksyy tietoturva- ja muut ohjelmistopäivitykset? Entäs miten prosessi toimii, kun Microsoft julkaisee normaalisyklin ulkopuolisen ”out of band” päivityksen?

3. Huolehdi ja sovi raportoinnista

Tietoturvallisuutta koskeva raportointi on osa edellistä, mutta sen tärkeyden takia haluan nostaa tämän erilliseksi kohteeksi. Tietoturvallisuudesta tulee raporoitoida usealla eri tasolla niin organisaation sisällä kuin asiakas/sidosryhmien kesken. Tietoturvaorganisaatio ei vastaa raportoinnista tai muutenkaan tietoturvallisuuden toteutumisesta vaan se ainoastaan luo edellytykset tietoturvallisuuden toteutumiselle ja tukemiselle organisaatiossa. Tällöin tietoturvallisuus määrittää, mitä asioita pitää kyetä raportoimaan minkälaisella aikataululla ja käytettävät & tuotettavat palvelut / järjestelmät tulee toteuttaa siten, että suunniteltu raportointi on mahdollista toteuttaa. Ja ellei tätä ole aikanaan osattu kilpailutuksessa => sopimuksissa huomioida, raportointi tulee maksamaan ylimääräistä, ellei kysessä ole todella ”kiltti ja yhteistyötahoinen” toimittaja. Sitä saa mitä sopii!

4. Tarkista ja valvo sopimuksia – miten vastuista on huolehdittu?

Ict-henkilöt ovat mukana palveluiden tuottamiseen liittyvässä toimittajayhteistyössä, jossa säännöllisesti (kuukausittain - neljännesvuosittain) käydään palvelun tuottamiseen liittyvät asiat vakioagendan mukaisesti läpi. Jos kaikki toimii sovitusti, ongelmia esimerkiksi vastuiden ja kustannusten osalta ei pitäisi esiintyä, mutta entäs kun niitä kuitenkin tupsahtaa? Jos asiat on sovittu sopimuksissa niin sen mukaan edetään. Ja vaikka sopimus olisikin ok, suosittelen kaikkien osapuolien työnjaon selvittämiseksi RACI-mallin käyttöä vastuiden määrittelemiseksi, mielellään jo osana hankintaa. Helpottaa ja vähentää merkittävästi ”Ei ole meidän ongelma / vika vaan XXX vastaa” tilannetta, kun ongelmatilanne ja teflonsuojaus isketään päälle. Kuka teillä valvoo sitä, että toimittaja täyttää sopimusvelvoitteensa vai pääseekö toimittaja kuin koira veräjästä pienistä sopimusrikkomuksista, koska nyt jos me käytetään sanktio-kohtaa, palvelu heikentyy entisestään?

5. Harjoittele poikkeamia

Kun poikkeama syntyy, koskee se tietoturvallisuutta tai muuta teknistä ongelmaa, organisaatio joka on asiaa harjoitellut ja jolla on käytössä toimivat prosessit, kykenee palauttamaan toiminnan vakiotasolle merkittävästi nopeammin kuin mutu- / rahi-mallilla toimiva. Vastuu tästäkin on prosessin omistajalla, mutta ict on tässä keskeisessä roolissa ja sen tulisi omalta osaltaan huolehtia tarvittavasta harjoittelusta ja yhteistyöstä koko toimintaverkoston osalta.

6. Muista yksityisyydensuoja!

Mitä teet kun pomo pyytää sinua katsomaan sähköpostipalvelimen lokista, ”Tuliko Makelle eilen illalla viestiä Kakelta?” tai kun hän pyytää sinua hakemaan lomalla olevan Lissun saapuneista viesteistä viime viikolla tullutta tärkeätä sopimusluonnosta? Jos et tiedä, mikä on sallittua ja mikä ei ole, parempi olla tekemättä mitään ja selvittää mitkä ovat oikeat toimintamallit. Sähköisen viestinnän tietosuojalain tuntemus tulisi olla jokaisen ict-ammattilaisen listalla. Tietosuojavaltuutetun sivulta löytyy lisää lukuisia hyviä ohjeita, muutenkin suositeltavan listan viimeisenä löytyy kattava ohje ”Yhteisötilaajan oikeus käsitellä tunnistamistietoja väärinkäytöstapauksissa”, josta löytyy v 2009 Lex Nokia-muutoksesta lisätietoja.

Se, että sinä saat laillisesti vianselvityksen takia selville jonkin henkilön teletunnistetietoja, ei oikeuta kertomaan sitä toiselle it-henkilölle, ellei hän hoida samaa työtehtävään liittyvää tapausta. Organisaation henkilöstön nettisurffailutaipumukset eivät saa olla tietotekniikkaryhmän kahvipöydän vakiokeskusteluaihe, ainakaan lokitietotasolla selvitettynä ja henkilöitynä.

7. Dokumentoi plz edes tärkeimmät asiat

Jos organisaation it-tuotantoon liittyvät prosessit ovat kunnossa, tällöin henkilöstö on velvoitettu ja koulutettu dokumentoimaan ja tiketöimään keskeiset työtehtäviin liittyvät asiat. Valitettavan usein pienemmissä organisaatioissa tilanne ei kuitenkaan ole näin ruusuinen. Itsekin muistan aikanani syyllistyneeni siihen, että ei jotain asiaa kannattanut dokumentoida, koska olin ihan varma, että muistan kyllä jatkossa varmasti kehittämäni ratkaisun ja ei tätä tietoa kukaan muu tarvitse. Kuinka väärässä olinkaan! Entäs kun henkilö on sairaslomalla, jättää organisaation tai Alz Heimer vahvistuu? Korvien välinen nahkakansio on monella henkilöllä korvaamaton. Jollei muuta, perusta keskeisistä toiminnoista sähköpostisosoitteet ”palvelinX.doku@organisaatio.fi”, ”ad.doku@organisaatio.fi” ja lähetä niihin vaikkapa ranskalaisilla viivoilla kirjattuna keskeisimmät muistettavat asiat. Sekä itsellesi että muille!

Kotikäyttövinkki – AXCrypt - helppo tiedostojensalaaja

Joskus saattaa tulla tilanne vastaan, että kotoa pitäisi lähettää jokin liitetiedosto salattuna toiselle henkilölle tai esimerkiksi arkistoida tiedosto turvallisesti nettiin, vaikkapa omalle Hotmail- tai Gmail-postitilille. Voit salata tällaisen tiedon useilla ilmaisohjelmilla, itse olen käyttänyt ilmaista, avoimeen lähdekoodiin pohjautuvaa AxCrypt- salausohjelmaa. Salauksen ohella ohjelmalla voi poistaa tiedostoja tietokoneelta tietoturvallisesti päällekirjoittamalla ensin poistettava tiedosto satunnaiselle tiedolla ennen kuin tiedosto poistetaan.

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

7 kuolemansyntiä - henkilöstö

Viime blogissa kävin läpi organisaation johdon myyttejä oman leiviskän hoitamiseksi paremmin tietoturvallisuuden osalta. Ei jätetä hommaa kesken vaan tällä kertaa otetaan kohderyhmä joka koskee meitä kaikkia, henkilöstö. U and mii. Niin, johto ei sitten lopeta lukemista tähän vaan te kuulutte henkilöstöön samalla tavalla kuin kaikki muutkin!

1. ”Tietoturvaohjeet eivät koske minua, koska tiedän kyllä mitä teen”

Jos muistat 80-luvun lopun hurtin toimintasarjan Sledge Hammerin ja hänen mottonsa ”Trust me. I know what I'm doing.", voit lakata jo noudattamasta mantraa – olemme 2010-luvulla. Ohjeet on laadittu kaikille noudatettavaksi. Hyvät ohjeet koostuvat perusteluista, miksi jokin asia on kielletty tai miksi jokin asia pitää tehdä määrätyllä tavalla. Nykyaikana pelkkä Kielletty/Estetty/Rajoitettu ei riitä selitykseksi ja perusteeksi.

Jos aikuisviihdesivustojen selaaminen työnantajan käyttöösi antamilla välineillä on kielletty ja vaikka sitä ei olisi teknisesti estetty, ei se tee siitä sallittua. Tai usb-tikulta ajettavia sovelluksia. Sama koskee älypuhelintasi, sen sijaan omalla puhelimella/tabletilla/kotikoneella voit tehdä mitä haluat, mutta jos katsot statistiikkaa, mitä av-sivustoilta yritetään koneisiin upottaa, jättäisin selaamisen väliin.

2. Opettele luokittelemaan käsittelemiesi tietojen tärkeys

Oletuksena voisi veikata, että jokainen täysikäinen ja aika paljon nuorempikin henkilö tunnistaa keskeiset suomalaiset euron setelit, ei varmasti kaikkia, koska osa on niin harvinaisia, mutta useimmat ovat kuulleet ainakin huhuja 500 ja 1000 euron seteleistä. Sama koskee käsittelemiäsi tietoja, sinun pitää käsitellä osaa tiedoista (200 € seteli) huolellisemmin kuin jotain perusmateriaalia (20 sentin kolikko). Se, että ei tiedä tai ei vaan osaa (EVO) luokitella käsittelemiensä tietojen arvoa ja tärkeyttä ei voi olla selitys vaan silloin pitää kysyä ja kouluttautua. Ja toi 1000 € seteli on urbaani legenda.

3. ”Jos jokin vaikuttaa liian hyvältä ollakseen totta, epäile huijausta”

Kannattaa lukaista oma esimerkkini muutaman vuoden takaa, jonka opit ovat edelleen käyttökelpoisia. Verkkorikollisista tulee yhä ovelampia, ”oman mummon myyminen” sähköisesti ei ole paljoakaan hankalampaa kuin perinteisin keinoin. Tämän takia organisaatioiden tulee jatkuvasti kehittää omia teknisiä vastakeinoja, koska olemme muutenkin koko ajan heitä jäljessä (mm. meidän pitää noudattaa lakeja).

4. Toimi työpaikalla kuten toimit kotona!

Miksi monella henkilöllä on Jekyll ja Hydemainen toimintatapa; kotona he ovat kuuliaisia perheenisiä ja –äitejä, mutta työpaikalla heistä tulee mistään piittaamattomia, kurittomia teinejä?! Useat organisaation tietoturvallisuuteen liittyvät riskit jäisivät toteutumatta tai ne pienentyisivät, jos henkilöstö toimisi työpaikalla kuten kotona. Klassinen käyttämäni esimerkki, kuinka moni palaa takaisin juna-asemalta tai bussipysäkiltä jos epäilee, että silitysrauta, puhumattakaan ulko-ovesta saattoi jäädä päälle tai auki?

Vastaavasti kuinka moni varmistaa että työpaikan ovi sulkeutui kunnolla päästyään kahden metrin päähän ulko-ovesta?

5. Ilmoita aina epäilyksistäsi

Jos näet kaupassa todennäköisen murtovarkaan, mitä teet? Tai jos näet mahdollisen ratti/ruori/tankojuopon lähtevän autolla / veneellä / polkupyörällä liikkeelle? Et mitään? Me suomalaiset delegoimme mielellämme tällaiset ilmoitusvelvollisuudet muille ajatellen, että kyllä toi toinen henkilö tuossa vieressä on jo tästä varmaan ilmoittanut. *EI OLE* ! Tietoturvahenkilöstö ottaa mielellään vastaan päällekkäisiä hälytyksiä oletetusta tietoturvapoikkeamasta kuin että vasta viikkoa myöhemmin todetaan, että kyllä se SSL-suojaus meidän nettipostista oli tippunut pois päältä. Miksei kukaan ilmoittanut siitä?

6. Osallistu koulutuksiin

Edellä olevat positiiviset asiat jäävät toteutumatta, ellei niistä muodostu organisaatioon positiivista asennetta ja toimintakulttuuria. Jotta koulutuksiin voi osallistua, organisaation pitää niitä säännöllisesti järjestää. Organisaatiosi voi aloittaa pienimuotoisen tietoturvakampanjan vaikka näillä tämän vuoden tietoturvaviikon sarjakuvilla ja julisteilla. Tiedän organisaatioita, joissa käyttöoikeudet tippuvat pois, jos koulutuksiin ei osallistu. Ja se ei tarkoita myöskään sitä, että töitä ei tällöin tarvitse tehdä.

7. Ja lue ne tärkeimmät ohjeet …

Niin kauan kun et ole lukenut (tai edes ”katselmoinut”) ohjeita, et voi väittää noudattavasi tai olla edes noudattamatta jotain tiettyä organisaatiosi ohjeita. RTFM.

Kotikäyttövinkki

Saat kotikoneen tietoturvallisuuden tilan selville Secunian PSI-ohjelmalla. Ohjelma tutkii kaikki tietokoneellesi olevat ohjelmat ja laskee niistä prosentti-indeksin sekä kertoo ohjelmiesi tilanteen, siis mm. mistä ohjelmista puuttuu tietoturvapäivitykset. Ohjelmalla voi myös ladata, jopa osin automaattisesti myös muitakin kuin Windows-käyttöjärjestelmä- ja sovellustietoturvapäivityksiä.

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Johdon 7 kuolemansyntiä - tietoturvallisuus

Kuten olen aikaisemmin useissa yhteyksissä nostanut esille, tietoturvallisuusasenne lähtee organisaation ylimmästä johdosta ja se jalkautuu aikaa myötä tietoturvakulttuuriksi niin hyvässä kuin pahassa. Mitkä ovat tyypilliset johdon seitsemän kuolemansyntiä?

1. Älä tingi tietoturvallisuudesta

Mitä tiukemmat taloudelliset ajat koettavat, sitä tiukemmalle tietoturvallisuus joutuu kun punakynä alkaa heilumaan. Tietoturvallisuuteen liittyy useita pakollisia velvoitteita, mm. lakeja, joita organisaation PITÄÄ noudattaa – tietyt perusasiat on kyettävä aina toteuttamaan. Jos tietoturvallisuus on osa kaikkea toimintaa prosessitasoisena, se on toteutettu kustannustehokkaasti eikä siitä ole edes tarvetta tinkiä – miksi kajota toimivaan prosessiin?

2. Opiskele perusteet ja yritä pysyä ajan hermolla

Onneksi olkoon lukija, etenkin jos olet johtaja tai esimies! Tämä osoittaa valveutuneisuutesi tietoturvallisuuden osalta ja saat saman tien papukaijamerkin ja voit henkisesti palkita itsesi. Johdon on helppo jättää tietoturvallisuus huomioimatta, jos ei edes ymmärretä tämän vaikean osa-alueen perusteita. Seitsemän vuoden takaisesta tietoturvaosaamisesta on yhtä paljon hyötyä kuin MS-DOSin edlin-editorista vuoden 2013 toimintasuunnitelmaa kirjoitettaessa.

3. Ei meillä ole ollut ongelmia => tietoturvallisuus kunnossa –asenne

Se, että organisaatiossa ei ole tapahtunut julkisuuteen päätynyttä tai organisaation sisälle jäänyttä poikkeamaa ei tarkoita sitä, että sillä on tietoturvallisuus kunnossa. Vasta siinä vaiheessa kun johto saa säännöllistä, mittaukseen pohjautuvaa raportointia tietoturvallisuuden tilasta, johto voi huoahtaa ja todeta tämän prosessin toimivan ja kuvitella, että raportointihetkellä tilanne oli ok.

4. EMOLMT - ”Ei meillä ole mitään tärkeää” –hokema yhdistettynä EVVK

Ei kukaan ole meistä kiinnostunut, koska meillä ei ole mitään tärkeätä tietoja ja eivät nämä kiinnosta ketään – edes muuten minua. Miksi teillä on sitten ovet lukossa, kulunvalvonta, hälytinjärjestelmä, vartiointiliike, salasanat tietojärjestelmissä sekä rajoitetut käyttöoikeudet? Vaikka organisaatiossa ei olisi muuta kuin sen omaan toimintaan liittyviä liikesalaisuuksia tai muuta salassa pidettävää tietoa, organisaatio voi tarjota pääsyn tietoverkkorikollisen kannalta johonkin huomattavasti houkuttelevampaan kohteeseen. Organisaation velvoitteena on huolehtia sopimusten mukaisesta velvoitteiden hoitamisesta myös tietoturvallisuuden osalta.

5. Olemme ulkoistaneet tietoturvallisuuden –luulo

Me ostamme kaiken palveluna ja sen takia meidän ei tarvitse siitä enää huolehtia. TÖÖÖT – väärin! Organisaatio ei KOSKAAN voi täydellisesti ulkoistaa jonkin prosessin tai toiminnallisuuden vastuuta, se pitää aina säilyä organisaatiossa. Jos olette ulkoistaneet ICT-palvelutuotannon, saatteko siitä myös kattavaa kohdan 3 mukaista raportointia? Eihän vain ole mennyt lapsi pesuveden mukana?

6. Meillähän on tietoturvapäällikkö! -kuvitelma

Ei tietoturvallisuus kuulu mulle / meille, sitä varten palkkasimme tuon kalliiksi tulevan tietoturvapäällikön. TÖÖT ja TÖÖT! Jos organisaatiossa on talous- ja/tai henkilöstöpäällikkö/johtaja, antaako johto heidän huseerata täysin itsenäisesti ja toteaa että ei talous- tai henkilöstöhallintoasiat kuulu meille? Tietoturvallisuuden tehtävänä on TUKEA ja kehittää toimintaa, se ei vastaa operatiivisessa toiminnasta vaan se vastuu kuuluu edelleen prosessin / toiminnon / palvelun omistajalle! Jos tämän kohdan alkuperäiseen toteamukseen vastasit ”ja, ja, ja” että näinhän se on, voit oikeastaan jo lopettaa lukemisen tähän …

7. Johto on osa henkilöstöä!

Kuinka moni on huomannut, että johto saa tietoturvallisuuden vihreän kaistan, jota tavallinen pulliainen ei voisi kuvitella koskaan ajavansa tai että johto voi olla noudattamatta yleisiä, kaikille käyttäjille tarkoitettuja ohjeita ja pelisääntöjä? Jos johto ei noudata sen itsensä päättämiä ohjeita ja toimi mallina kaikessa toiminnassa, ei henkilöstöltä voi odottaa samaa. Niin, ensi numerossa käydään läpi henkilöstön kuolemansynnit, jotka koskevat kaikkia, ml johto ja esimiehet – onneksi vain tietoturvallisuuden osalta …

Kotikäyttövinkki.

Haluatko tehdä tietokoneellesi paaston yhteydessä tehtävän suolihuuhtelun? Täh? Jep, tietokoneellesi kertyy kuona-aineita, joista on hyvä päästä säännöllisesti eroon enkä tarkoita haittaohjelmia. Windowsin omalla Järjestä uudelleen (Disk cleanup) ohjelmalla voit poistaa joitakin turhaa tilaa vieviä tiedostoja, mutta suosittelen ajamaan säännöllisesti ilmaista CCleaner-ohjelmaa - . Ohjelmalla voit levyn ohella puhdistaa myös koneesi rekisterin turhasta sakasta!

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Jatkuvuuden takaaminen on organisaation elinehto

Koska dinosauruksilla ei ollut jatkuvuussuunnitelmaa, ne kuolivat sukupuuttoon! Jos tietoturvallisuuden keskeinen tehtävä on huolehtia L-E-S-mallin toteutumisesta, jatkuvuus- ja toipumissuunnittelun avulla huolehditaan ennen kaikkea tietoaineistojen, ennemmin sanoisin toimintaprosessien saatavuudesta ja välillisesti myös tietojen eheyden takaamisesta.

Kuten edellisessä blogissa toin esille, jokaisella häiriöllä on hinta, johon vaikuttaa keskeisesti häiriön kesto ja sen vaikutus organisaation (liike)toimintaan. Jos häiriöllä ei ole merkitystä lainkaan tai mitätön vaikutus, ei meidän tarvitse tällöin edes miettiä näitä asioita.

Keskity olennaisimpaan!

Kaikilla meillä on kiire ja ei kukaan ehdi miettiä ja varautua kaikkeen kuviteltavissa olevaan eikä se ole tarkoituskaan. Organisaation jatkuvuussuunnitelman tulisi sisältää toimintamallit kuitenkin sellaisten häiriötilanteiden varalta, joihin ei ole olemassa ohjeita, jotta aikaa ei käytetä ad hoc tyyppiseen tilanteen vatulointiin vaan toiminta etenee ennakolta suunnitellusti. Vaikka artikkelissani pääpaino ja näkymä näihin asioihin on ICT-tulokulmasta, hyvä erilainen esimerkki mahdollisesta häiriötilanteesta on tarve vetää jokin organisaation tuote pois markkinoilta siitä paljastuneen tuotevirheen takia. Vaikuttaako toimintaan – takuuvarmasti!

Ennen kuin tähän on päästy, kenties tärkein tehtävä on tunnistaa ja kuvata organisaation toimintakyvyn kannalta tärkeimmät prosessit, niiden riippuvuudet ja riskienarvioinnin kautta arvioida tätä kokonaisuutta. Riskienarvioinnissa keskitytään ennen kaikkea liiketoiminnan ulkopuolisiin riskeihin, koska liiketoiminnan vakioriskit ovat yleisesti tunnettuja ja hallittuja. Entäs jos meillä ei ole toimivia, tunnistettuja ja kuvattuja prosesseja? Käytännössä jokaiseen organisaatioon on muodostunut prosessit, joko epäviralliset ja viralliset joten tässä yhteydessä ne tulee käydä läpi. Prosessi ei saa olla itseisarvo vaan toimia laadukkaamman toimintatavan mahdollistajana.

Toipuminen toteutetaan tietojärjestelmätasolla

Jos jatkuvuussuunnitelmassa keskitytään laajempien toimintakokonaisuuksien ja prosessien turvaamiseen, toipumissuunnitelmien avulla huolehditaan yksittäisten prosessien osien ja ICT-näkökulmasta tietojärjestelmätasolla toimintojen palauttamisesta.

Otetaan tästä pari käytännön esimerkkiä. Organisaation toimitilan ulkopuolella tapahtuu putkirikko, joka aiheuttaa tulvan, jonka takia organisaation toimitiloihin kulku estyy sekä syntyy vaaratilanne ja uhka, että organisaation toimitiloista pitää sammuttaa sähkönsyöttö. Käytännössä tämä tarkoittaa useiden organisaation perustoimintojen ja varmasti myös ydinprosessien keskeytymisen – mitkä ovat ne varamenettelyt, jotka organisaatiossa pitäisi ottaa tilanteessa käyttöön? Sitä varten pitäisi kaivaa esille paperilla oleva(t) toipumissuunnitelma(t) ja jatkaa toimintaa sen mukaisesti – tarvittaessa kynttilävalossa eli missä ne taskulamput olivatkaan?. Huomaa, tässä tilanteessa ei ole välttämättä edes yksikään tietojärjestelmä alhaalla, koska jos sähköt on jouduttu panemaan poikki, varavirtajärjestelmännehän kestää sen kaksi tuntia…

Pahennetaan tilannetta: kyseinen putkirikko aiheutti vesivuodon palvelinhuoneeseen siten, että organisaation palvelinhuoneessa oleva Active Directory-hakemistosta vastaava ensisijainen palvelin kastui ja sen seurauksena hajosi. AD on varmasti yksi niistä järjestelmistä, jonka toiminta tulisi olla otettuna huomioon jatkuvuus- mutta etenkin toipumissuunnittelussa. Jos organisaation AD-hakemisto lamaantuu, menee yleensä samalla DNS-nimipalvelut ja muut organisaation toimintakyvyn kannalta keskeiset infrapalvelut alas ja pian huomataan että mikään palvelu ei toimi.

Jotta toiminnan priorisointi tapahtuu tällaisessa tilanteessa tarkoituksenmukaisesti, tulisi tietojärjestelmien ja palveluiden riippuvuudet toisistaan olla selvillä ja tämä tulisi olla otettuna huomioon priorisoitaessa organisaation palveluita ja niille laadittavia suunnitelmia. Älä aloita helpoimmasta päästä vaan siitä, joka voi lamaannuttaa toiminnan nopeasti ja todennäköisimmin!

Entäs kun me ollaan ulkoistettu kaikki?

Toivottavasti ette ihan kaikkea, koska silloin teitä viedään kuin kuuluisaa pässiä narussa, tietty osaaminen ja vastuu pitää *aina* säilyä organisaatiossa! Yhä useampi meistä ostaa kuitenkin ICT-palvelut ulkoistettuna, miten jatkuvuus- ja toipumissuunnitelmat pitäisi tällöin toteuttaa? Jotta nämä asiat olisivat toteutettu hyvin, on se edellyttänyt sitä, että ne ovat olleet mukana kilpailutuksessa vaatimusmäärittelyssä ja sitä kautta myös otettuna mukaan sopimuksiin. Korostan taas kerran sopimuksen tärkeyttä.

Mitä laajemmasta organisaation toimintakokonaisuudesta on kyse, sitä laajemmasta mahdollisesta toimittaja- ja alihankinta -verkostosta on kyse, jonka tulee kyetä myös häiriötilanteessa toimimaan sujuvasti yhteistyössä. Jos näitä asioita ei etukäteen sovita ja millään tavalla harjoitella, kokemuksesta voidaan sanoa, että ensimmäinen oikea ongelmatilanne tulee olemaan todellinen koettelemus. Vaikka aikaa ja rahaa ei olisi oikeaan jatkuvuus- tai toipumisharjoittelun toteuttamiseen, tulisi ainakin olemassa olevat näihin liittyvät toimintaprosessit sopia ja käydä yhdessä eri osapuolien kanssa läpi. Äläkä unohda sopia viime blogissa läpikäytyä häiriöviestintää, koska se ratkaisee hyvin pitkälle sen, millainen mielikuva asiakkaalle sinun toiminnastasi muodostuu!

Kotitehtävät

• Onko organisaatiossasi tarvittavat jatkuvuus- ja toipumissuunnitelmat?
• Mistä asioista ne on laadittu??
• Onko näihin liittyvät vastuut organisaatiossa selvitetty?
• Milloin niitä on viimeksi katselmoitu / päivitetty / harjoiteltu??
• Miten jatkossa nämä asiat huomioidaan vaatimusmäärittelyissä ja sopimuksissa?

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Entäs kun häiriö iskee – toimiihan viestintä?

Joka paikassa toitotetaan, kuinka haavoittuva sähköistynyt yhteiskuntamme on ja viimeisen vuoden aikana tästä on tullut kiihtyvällä tahdilla konkreettisia esimerkkejä. Otetaan ekana esimerkki kotoa.

Jos kotona jää nauhoittamatta jokin ohjelma digiboksin sekoilun takia, se ei ole mikään iso ongelma. Sen sijaan kun kodin ainoa nettiliittymä alkaa tökkiä, viestintä- ja muu yhteydenpito sukulaisiin ja kavereihin sekä pankki- ja muu asiointi alkaa kärsiä. Saatko ilmoituksen näistä ongelmista toimittajalta vai pohjautuuko kaikki ongelman selvitys sinun omaan osaamiseen ja aktiivisuuteesi?

Kaikki ovat kuitenkin tottuneet siihen, että tällaiset asiat kuuluvat asiaan teknisten laitteiden kanssa ja ei niille mitään voi mitään. Onneksi nämä kodin ongelmat yleensä ovat satunnaisia ja esimerkiksi nettiliikenneongelmat selviävät yleensä siinä vaiheessa kun pääsee internet-palveluntarjoajansa puhelinpalvelun kanssa asiaa selvittelemään.

Häiriö – mitä me menetetään?

Kun edellinen näkökulma siirretään kotoa yritykseen, tilanne muuttuu oleellisesti. Pääsääntöisesti jokaisella organisaation toimintaan vaikuttavalla häiriöllä on jonkinlainen merkitys sen liike- / ydintoimintaan ja välittömästi tai välillisesti sen asiakkaisiin. Organisaation jatkuvuus- ja toipumissuunnitelmien avulla pyritään optimoimaan koetun häiriön kesto ja taloudelliset sekä muut (esimerkiksi julkisuuskuva) vaikutukset. Kaikkia skenaarioita on turha yrittää mallintaa ja poistaa, tärkeintä on löytää riskienhallinnan ja liiketoiminnan vaikutusanalyysin kautta sellaiset tilanteet prosessit, jotka pitää olla etukäteen mietitty, dokumentoitu, koulutettu ja mielellään harjoiteltu.

Jos organisaation nettikaupan kertaluonteinen alhaalla olo 2 tuntia maksaa 2 000 euroa, mutta järjestelmä toteuttaminen vikasietoisena siten, että tällaisen todennäköisyys pienentyy merkittävästi tai katkon kesto on vain minuutteja ja parannus maksaa 1000 € / kk, ei investointi kannata – ainakaan heti. Sen sijaan organisaatiolla tulisi olla valmiina häiriötiedote kertomaan, että ongelmaa parhaillaan korjataan ja meidän TOP 10-myydyt tuotteet ja tarjouksemme ovat nämä ja tervetuloa tilaamaan vaikkapa puhelimella tai sähköpostitse.

Jokaisella häiriöllä on hintalappu, joka saattaa näkyä eri muodoissa. Raha ei ole ainoa mittayksikkö, millaisen mielikuvan organisaatio muodostaa sillä, että sen yleistä tietoa jakava www-palvelin on alhaalla säännöllisesti, vaikkapa kuukausittain? Tai kun asiakkaalle tarjottu palvelu ei toimi ja asiakas ei saa siitä tietoa kuin esimerkiksi sosiaalisen median kautta tai kavereiltaan?

Häiriöviestintä ei saa tökkiä!

Ennen kuin päästään häiriön korjaamiseen ja siitä toipumiseen, pitää organisaatiolla olla huolella mietittynä prosessi häiriöviestinnän toteuttamiseksi. Pieni ongelma, josta ei osata tiedottaa asiakkaalle ärsyttää tyypillisesti enemmän kuin sellainen laajempikin ongelma, josta asiakkaalla on koko ajan tilannekuva ja tunne siitä, että asiaa hoidetaan ammattitaitoisesti. Vaikka ongelmanselvitys etenee mutta palvelu ei tule kuntoon, tulee myös tällöin siitä säännöllisesti tiedottaa ja kertoa, milloin seuraavan kerran voi tulla nettisivulle lukemaan lisätietoa korjaamisen etenemisestä. Viestinnän tekee haasteelliseksi se, että jokainen meistä haluaa saada tietoa eri tavoilla. Häiriöviestintää voi ajatella toteutettavaksi monikanavatekniikalla siten, että jokainen asiakas löytää itselleen mieleisen tavan, on se sitten sähköposti, sms-viesti, rss-syöte, Twitter, Fb tai organisaation www-häiriösivusto/tiedote.

Muista Wiion legendaariset lait – seuraa somea

Myös häiriöviestinnässä kannattaa pitää mielessä Osmo A. Wiion legendaariset lait (http://fi.wikipedia.org/wiki/Osmo_A._Wiio) koskien viestintää. Häiriöviestintää koskee etenkin viestinnän ensimmäinen ”Viestintä yleensä epäonnistuu, paitsi sattumalta” sekä kuudes laki ”Uutisen tärkeys on kääntäen verrannollinen etäisyyden neliöön”. Häiriöviestintä sujuu hyvin harvoin kuten Strömsössä ja valitettavan usein käy niin, että viesti ongelmasta ei mene perille virallisen, organisaation kuvitteleman prosessin mukaisesti vaan aivan muita kanavia pitkin. Tällöin sisältökin muuttuu sopivasti ja ongelmakin kasvaa merkittävästi ja pian organisaatio huomaa siitä keskusteltavan hallitsemattomasti sosiaalisessa mediassa. Onhan organisaatiossasi mietitty, miten tällöin toimitaan ja kuka vastaa tällaisten virheellisten some-viestin korjaamisesta? Vai pitääkö niihin vastata?

Hyödynnä jokainen häiriö oppimistilanteena ja kerää sen hoitamisesta palautetta niin sisäisesti kuin merkittävien häiriöiden osalta ulkoisilta asiakkailta.

Kotitehtävät

• Kun häiriö tapahtuu, mistä organisaatio saa tietää siitä?
• Kuka luokittelee ja määrittää ongelman tason ja vakavuuden?
• Mistä organisaatiossasi löytyy häiriöviestinnän ohjeistus?
• Onko kaikilla selvää, mitkä tehtävät ovat kenenkin vastuulla?
• Jos ongelma on merkittävä ja asiakkaiden lisäksi media kiinnostuu ongelmasta, kuka saa antaa lausuntoja medialle?
• Käydäänkö jokainen merkittävä häiriötilanne läpi oppimisen näkökulmasta, teknisen selvityksen ohella myös viestinnän osalta?
• Miten me hyödynnämme somea?

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Hallitsetko sinä riskejä vai riskit sinua?

Jos organisaatiossa ei harrasteta riskienhallintaa, organisaatio on kuin Titanic, joka vain odottaa sopivaa jäävuorta; ”tuurillahan ne laivatkin seilaa”. Riskienhallinta on prosessi, jolla pyritään varmistamaan organisaation liike- / ydintoimintatavoitteiden saavuttaminen.

Olen tämän blogin aikaisemmissa osissa nostanut esille L(uottamuksellisuus), E(heys) ja S(aatavuus) keskeisiksi suojattavaa kohdetta koskeviksi osa-alueiksi. Jotta tämä voidaan toteuttaa mahdollisimman kustannustehokkaasti, tulee organisaation toteuttaa kokonaisvaltaista riskienhallintaa toimintansa turvaamisessa.

Kuten kaikissa muissa tietoturvallisuuden osa-alueissa, toiminta pitää aina suhteuttaa organisaation kokoon ja tarpeeseen. Riskit eivät ole aina negatiivisia uhkia vaan niihin liittyy myös positiivinen mahdollisuus. Otetaan esille esimerkkini perus-snagari tai toisena esimerkkinä kymmenen hengen konsulttipalveluita tarjoava yritys.

Snagarin omistaja ei varmastikaan tietoisesti mieti riskienhallintaa sellaisenaan, mutta se tulee kuitenkin läpi kaikessa toiminnassa. Omistaja harrastaa tietämättään mielessään riskienhallintaprosessia investointeja suorittaessaan (”kannattaako nyt ostaa uusi uuni?”), henkilöitä palkatessaan ja uusia tuotteita ruokalistalle suunnitellessaan.

Sen sijaan 10 hengen konsulttifirmassa riskienhallinnan tulisi olla jo selvästi määrätietoisempaa ja sitä voidaan ohjata mahdollisen riskienhallintapolitiikan avulla oikeaan kohteeseen. Kuten tietoturvallisuus kokonaisuutena, ei riskienhallinnan tule olla itseisarvo vaan se tulee aidosti olla hyödyllistä ja siitä tulee nähdä sen tarjoamat mahdollisuudet ja aidot hyödyt. Jos riskienhallintaa tehdään vain sen takia kuin on pakko, kannattaa ennemmin jättää tekemättä ja käyttää vapautuva aika motivoivampaan, tuottavampaa työhön mitä se sitten sattuukaan olemaan.

PK-RH tarjoaa kattavan www-sivustokokonaisuuden riskienhallinnan toteuttamiseen nimeltään PK-RH, PK-yrityksen riskienhallinta. Sivustolta löydät esimerkiksi riskilajit. Tässä yhteydessä tulee erityisesti huomata se, että tietoriskit ovat vain yksi osa-alue, jonka tarkoituksena on huolehtia L-E-S-mallin mukaisesti tietoaineistojen suojaamisesta.

Käytännössä riskienhallinnan tulisi olla säännönmukainen prosessi, josta löytyy esimerkiksi seuraavia osa-alueita:

1. Riskien tunnistaminen

2. Riskien käsittely (analyysi)

3. Riskienhallintamenetelmien valinta

4. Varautuminen

5. Riskienhallinnan seuranta

1. Tunnista riskisi!

Em. sivustolta löytyy erilaisia käytännön vinkkejä riskien tunnistamiseen. ICT-alalla eräs keino on käydä läpi työpajatyyppisesti avainhenkilöiden kanssa mahdollisia riskejä eli niitä, jotka ovat jo toteutuneet tai läheltä piti tilanteita sekä mahdollisesti tunnistettuja, mutta toteutumattomia riskejä. Netistä löytyy myös tarkistuslistoja sekä valmiita riskirekistereitä, joita voi käyttää mallina oman organisaation toimintamallia kehitettäessä. Yleensä tämä on prosessin helpoin osa-alue!

2. Arvioi ne!

Perinteinen tapa arvioida riskin vaikutus on tapahtuman todennäköisyys * tapahtuman seuraus. Todennäköisyys voi olla kolme tai neliportainen alkaen epätodennäköisestä mahdollisuudesta päätyen todennäköiseen, yleensä jo tapahtuneeseen. Tapahtuman seuraus voi olla samalla tavalla kolme- tai neliportainen, jossa seuraukset voivat olla erittäin vähäisiä tai erittäin merkittäviä. Seuraus voi olla taloudellinen, rahassa mitattavissa tai se voi olla esimerkiksi välillinen, vaikkapa organisaation julkisuuskuvaan liittyvä seuraus.

Näiden yhdistelmästä saadaan jokaisella tunnistetulle riskille arvio, joka määrittelee riskiluokan. Jos tällä tavalla löytyy riski, joka on molemmilla asteikolla ns. tapissa, voidaan puhua sietämättömästä riskistä, jonka osalta pitää aloittaa toimenpiteet välittömästi riskin poistamiseksi, käytännössä tietoriskejä käsiteltäessä useimmiten sen alentamiseksi matalammalle tasolle.

3. Käsittele löydetyt riskit

Kun edellisellä mallilla on saatu poimittua ne riskit, jotka nousevat riittävän korkealle tasolle, esimerkiksi todennäköisyys on mahdollinen (voi sattua) ja seuraus on vähintään haitallinen, pitää kaikki nämä tietyn raja-arvon ylittävät riskit käsitellä. Tällöin haetaan riskille keinoja sen käsittelemiseksi, tyypillisiä keinoja ovat esimerkiksi:

• Riskin siirtäminen ja / tai jakaminen
• Riskin välttäminen
• Riskin poistaminen
• Riskin pienentäminen
• Riskin pitäminen omalla vastuulla

Riskin siirtäminen / jakaminen tarkoittaa käytännössä esimerkiksi vakuuttamista; hanki vakuutus suurten riskien varalta, kaikista pienimpien vakuuttaminen ei ole kustannustehokasta, ellei se ole osa laajempaa vakuutuskokonaisuutta eikä maksa ylimääräistä rahaa. Toinen tapa on jakaa riski sopimuksen avulla yhden tai useamman alihankkijan avulla. Otetaan esimerkiksi internet-verkon tuomat vaarat; käytännössä et voi oikein ostaa vakuutusta siltä varalta ja samoin harva internet-palveluntarjoaja suostuu jakamaan organisaatiosi riskiä sellaisenaan, vaan edellyttää teknisiä apuvälineitä.

Riskin välttäminen kuulostaa hienolta ja kannattavalta, mutta usein se on mahdotonta, ellei organisaatiossa kokonaan luovuta kyseisestä toimintatavasta. Internet-verkosta tulevia vaaroja vastaan voitaisiin välttyä olemalla käyttämättä kokonaan internet-verkon palveluita; herätys, ei ole siis mahdollista. Tällöin tapahtuisi riskin poistaminen, joka ICT-alalla on harvoin käytettävissä oleva mahdollisuus.

Ennen kaikkea tietoriskien osalta usein valittu keino on riskin pienentäminen. Jotta tämä tapahtuu käytännössä, joko todennäköisyyden tai tapahtuman seurauksen tulisi laskea, yleensä voit paremmin vaikuttaa todennäköisyyteen kuin seuraukseen eli yritä pienentää sen mahdollisuutta. Esimerkiksi internet-käytön kautta tulevien riskien todennäköisyyttä voidaan pienentää teknisillä ratkaisuilla, henkilöstön kouluttamisella ja ohjeistamisella. Tapahtuman seurausta voidaan pienentää parantamalla salassa pidettävien tietoaineistojen käsittelyä sellaisissa ympäristöissä, joissa ne ovat yhteydessä internet-verkkoon.

Jokainen organisaatio joutuu yleensä pitämään tiettyjä riskejä omalla vastuulla eli ottamaan ns. tietoisia riskejä. Vaikka meillä olisi millaiset vakuutukset ja sopimukset taustalla, aina niistä jää organisaation kannettavaksi tietty osuus. Kun organisaation liittyy internet-verkkoon, se on tietoinen riski, joka on vain pakko hyväksyä. Käytännössä tätä riskiä yritetään pienentää pienentämällä sitä sekä teknisillä (”rautaa rajalle”) että hallinnollisille keinoilla (henkilöstön ohjeistaminen, käyttöpolitiikat siitä mikä on sallittua ja mikä kiellettyä perusteluineen, koulutus).

Itse pidän tätä prosessin tärkeimpänä vaiheena sen takia, koska tässä pitää myös tehdä ehdotus siitä, kuka ottaa asian vastuulle, mitä ja miten käytännössä toimenpide toteutetaan ja millä aikataululla. Jos tätä ei saada tehtyä, voidaan koko prosessin toiminta kyseenalaistaa!

4. Varaudu riskeihin!

Entäs jos kaikesta huolimatta jokin löytämämme riski toteutuu? Tätä varten meillä tulisi olla näitä tunnistettuja riskejä varten erilaisia häiriötilanteiden hallintaan liittyviä prosesseja sekä jatkuvuus- ja toipumissuunnitelmia, joilla häiriön aiheuttama vahinko saadaan pidettyä tarkoituksenmukaisena. Jos häiriö ei juuri vaikuta haitallisesti liike-/ydintoimintaan, se saa tarvittaessa kestää kauan, mutta jos eurot alkavat juoksemaan kiihtyvää vauhtia häiriön pitkittyessä, sitä tärkeämmäksi nopea häiriötilanteesta toipuminen muodostuu. Palaan tähän asiaan tarkemmalla tasolla seuraavassa blogissa!

5. Kokonaisuuden seuranta ja raportointi

Pidän tätä osa-aluetta valitettavan usein laiminlyötynä osana. Kun kerta riskit on tunnistettu, arvioitu ja valittu toimenpiteet, tulee tämän kokonaisuuden osalta ehdottomasti seurata sitä, miten valitut toimenpiteet purevat. Jos esimerkiksi internet-käytön riskiä on haluttu pienentää ottamalla käyttöön kehittynyt liikenteen sisältöä valvova ja rajoittava tekninen tuote, tulisi jollakin aikataululla selvittää, miten se on vaikuttanut riskiin.

Samoin organisaation johto, joka oli huolestunut tästä kohonneesta riskistä ja myönsi rahoituksen tälle investoinnille, jotta riskiä saataisiin pienennettyä, haluaisi kuulla miten kannattava investointi on ollut. Tai jos henkilöstölle on järjestetty tietoiskuja internet-käytön vaaroista, näkyvätkö tulokset pienentyneinä haittaohjelmatorjunnan hälytyksinä?

Vaikka organisaatiossa olisi kuinka hyvä riskienhallintakulttuuri ja asenne, kaikkeen ei voi varautua. Tämän takia prosessia pitäisi kyetä kehittämään sekä tuomaan mukaan uusia, läheltä piti-tilanteiden tai toteutuneiden, aikaisemmin tunnistamattomien tilanteiden aiheuttamia uhkia.

Hyvä esimerkki on parin vuoden takainen Euroopan laajuinen lentokaaos, joka syntyi Islannissa Eyjafjöll-tulivuoren purkauksen myötä. Aika harvalla oli tällaisen vulkaanisen toiminnan perusteella syntynyt riski sen hetkisessä riskikartassa, nyt varmasti löytyy ainakin niiltä, joilla syntyi läheltä piti tai kallis, lauennut seuraus.

Kotitehtävät

• onhan meillä riskienhallinta otettu käyttöön?
• onko se suunnitelmallista eli perustuu esimerkiksi vuosikelloon?
• seurataanko toimenpiteiden etenemistä?
• kuka ja kenelle näistä asioista raportoidaan?
• tutustu ISO 31000:2009 ja COSO-ERM-viitekehyksiin

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Alkuvuoden puheenaiheet

Mistä tietoturvallisuudessa alkuvuoden aikana on keskusteltu?

Alkuvuoden keskeisimmät puheenaiheet ovat liittyneet ns. kestoaiheisiin eli BYOD ja pilvipalvelut, uutena kansainvälisenä vaikuttajana nähdään EU:n uusi tietosuoja-asetus. Uusina asioina esillä ovat olleet Suomen menestyminen viime aikojen tietoturvavertailuissa sekä kyberturvallisuus. Kansallinen tietoturvaviikkokin on jo takana. Hyvän katsauksen vuoden 2011 tapahtumiin löytyy Viestinviraston CERT-FI 2011 vuosikatsauksesta.

BYOD-malli (Bring Your Own Device)

Joskus tietoturvaihmisiä väitetään jämähtäneisyydestä vanhoihin kaavoihin ja nyt kun ikkunoista, omenoista ja pingviineistä yritetään tunkea näitä käyttäjien omia laitteita organisaatioiden turvallisten käyttötapojen listalle, tietoturvaa on jälleen helppo syyttää mallin hidastamisesta. Tässä kohtaa tulee aina muistaa se, että kyllä työnantajalla on edelleen oikeus määrätä, mitä työvälineitä henkilöstön pitää käyttää työtehtävien hoitamisessa. Tässä on huomattavissa hieman sama ilmiö kuin henkilöjohtamisessa, enää ei uskalleta suoraan sanoa että ”nythän sinä teet tuon työn, joka sinulle kuuluu, tai itket ja teet, vaikka se ei miellytäkään tai kiinnosta.”

Se, että organisaatiojohto määrää, että nyt ne sähköpostit ja kalenterit pitää saada iTablettiini koska sen satuin hankkimaan ja kaikilla muillakin johtajakollegoillani muissa firmoissa se on, ei voi olla ainoa peruste. Kuinka monelle toimitusjohtajalle on kerrottu, mitä ratkaisun toteuttaminen maksaa (tarvittavat uudet tekniset ratkaisut, henkilöstöltä kuluva aika omien ja kavereiden IT-ongelmien selvittämiseen) sekä selvitetty jäljelle jäävä jäännösriski? Jos ainoa syy on helppokäyttöisyys (ei tarvitse avata läppäriä kotona), voisiko sitä kenties parantaa kouluttamalla johtoa käyttämään nykyisiä työvälineitä tehokkaammin (virransäästö)?

Edellinen ei tarkoita sitä, etteikö BYOD-malli toimisi, siinä pitää vain investoida riittävästi taustalla toteutettavaan tekniseen tietoturvallisuuteen, uusiin prosesseihin sekä henkilöstön lisäkoulutukseen ja ohjeistamiseen, jotta he toimivat uusissa käyttötilanteissa oikealla tavalla. Kehitettävän ratkaisun tulee olla geneerinen, jolloin se saadaan skaalattua kustannustehokkaasti jatkossa mihin tahansa tulevaisuuden päätelaitteeseen. Kysymys oikeastaan on se, milloin ja millä ratkaisuilla organisaation kannattaa BYOD-mallia lähteä ensin pilotoimaan ja vasta sen jälkeen tekemään päätöstä sen laajemmasta käyttöönotosta.

Pilvipalvelut huolettavat

Voisiko epämääräisempää otsikkoa kirjoittaa, mutta tuo hyvin kuvaa sitä tilannetta, mitä pilvipalvelu-termillä ymmärretään; siis melkein mitä tahansa. Tässä yhteydessä nostan esille ensimmäisenä uhkakuvana netissä olevat ilmaispalvelut käyttäjien tallentaessa niihin mahdollisesti salasssa pidettäviä tietoja käyttäen heikkoja salasanoja. Tältä osin ongelmaan on helppo pureutua muistuttamalla käyttäjiä siitä, mitkä ovat sallitut tavat käsitellä tietoa organisaatiossa. Ongelmaa ei saa ratkaista sillä, että salassa pidettävä tietoaineisto tiputetaan Dropboxiin kun se ei mahdu perinteiseen sähköpostiin. Sen sijaan jos käyttäjä salaa tiedoston ja käsittelee salausavainta organisaation hyväksymällä tavalla, tilanne on parempi.

Kun puhutaan tietojärjestelmien tuottamiseen liittyvistä pilvipalveluista, on se sitten IaaS, PaaS tai SaaS, sitä saa mitä vaatimusmäärityksissä vaaditaan ja aikanaan sopimuksissa lukee. Tässä korostan kahta sanaa: vaatimusmäärittely ja sopimus. Ja vielä uudelleen: vaatimusmäärittely ja sopimus. Olen verrannut pilvipalvelua kenkään numero 39, väriltään harmaa ja soveltuu kohtalaisen hyvin myös talvikäyttöön enintään -18 asteen pakkaselle, ei nauhoja, unisex. Jos kengännumerosi on kokoa 46 mallia ”siro”, jalan ahtaminen koon 39 kenkään voi olla hankalaa ja kivuliasta, mutta mahdollista. Sen sijaan numeron 32 ”kevytkenkäisellä” voi olla hieman helpompaa, koska kasvuvaraakin on.

Jos pilvipalvelu ei täytä organisaation edellyttämiä vaatimuksia, voi olla ettet saa niitä sinne millään rahasummalla. Pilvi- kuten muissa palveluissa, sopimuksen merkitys on noussut entisestään. Se mitä ei sinulla sopimuksesta löydy tai se löytyy sieltä epämääräisesti ilmaistuna, tulee maksamaan organisaatiolle rahaa, hunajaa ja mirhamia, jos jotain uutta sopimuksen ulkopuolella olevaa toiminnallisuutta tarvitaan.

EU:n uusi tietosuoja-asetus – seurattavien asioiden listalle

EU:n loppuvuodesta nettiin ”vahingossa vuotaneesta” tulevasta tietosuoja-asetuksesta on saatu nyt ulos viralliset versiot. Uusi asetus on siinä mielessä merkittävä, että sen avulla voidaan korjata useita ongelmalliseksi koettuja asioita koskien esimerkiksi henkilötietojen käsittelyä globalisoituvassa maailmassa ja pilvipalveluissa sekä tietomurtoihin liittyviä ilmoittamisvelvollisuuksia sisältäen mahdolliset sanktiot.

Muistutan tässä henkilörekistereiden ylläpitäjiä siitä, että teillä pitäisi olla tieto siitä, missä teidän tietonne on fyysisesti tallennettu tai minne tietoja luovutetaan. Ongelma saattaa tulla vastaan kun tietoja tallennetaan EU/ETA-alueen ulkopuolisiin maihin. Lista EU:n hyväksymistä turvallisista maista löytää täältä sekä muuta tarvittavaa lisätietoa Tietosuojavaltuutetun toimiston sivustolta.

Suomi – tietoturvallisuuden ihannemaa?

Suomi on pärjännyt hyvin kahdessa alkuvuodesta julkaistussa tutkimuksessa. Microsoft Computing Safety Index (MCSI) -tutkimuksessa olimme kolmansia 27 maan välisessä vertailussa koskien käyttäjien nettikäyttöön liittyviä toimintatapoja.

McAfeen tukemassa Kyber-valmiutta koskevassa tutkimuksessa Suomi oli kolmen kärkimaan joukossa yhdessä Israelin ja Ruotsin kanssa.

Olemme varmasti teknisesti ajateltuna maailman kärkipäätä, kun ajatellaan tietoliikenneoperaattoreidemme yhdessä CERT-FI:n kanssa tekemää tietoverkkojen puhdistamiseen liittyvää työtä. Microsoftin SIR-raportissa (Security Intelligence Report; pdf) suomalaisten käyttäjien työasemat ovat myös maailman puhtaimmasta päästä.

Kun mennään organisaatio- ja tietojärjestelmätasolle, voisi heittää tietysti epäilyksen varjon, että jos me pärjätään tällä menolla ”näin hyvin”, kuinka p€rs€€llään onkaan tilanne muissa maissa? Valitettavasti tilanne ei ole edes meillä Suomessa näin hyvä, koska tutkimuksia esimerkiksi nettiin tai rajatummin vain asiakkaille näkyvien palveluiden tietoturvallisuudesta ei ole laillisesti kovinkaan helppo toteuttaa.

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Tekninen tietoturvallisuus - rautaa rajalle, mutta miksi?

Usealle käyttäjälle tietoturvallisuus on sama kuin virustorjunta ja palomuuri. Tekninen tietoturvallisuus on tärkeä asia, joka pitää olla kunnossa, mutta se on vain osa kokonaisturvallisuudesta.

Jokaisessa organisaatiossa on henkilöstölle laadittu tietoturva-ohjeistus, jonka laajuus vaihtelee yhdestä A4-sivusta satojen sivujen ohjekokonaisuuteen. Omasta mielestäni keskeisimmät ohjeet koskevat tietoaineistojen käsittelyä ja Internetin sekä muiden työvälineiden käyttöön liittyviä määräyksiä – perusteluineen, miksi jokin asia on kielletty. Selkeää ohjeistusta tukevat tekniseen tietoturvallisuuteen liittyvät tekniset ratkaisut, hallinnolliset prosessit ja tarvittava koulutus sekä tietoturvaviestintä.

Miksei pelkkä ohjeistus riitä?

Jos kerta käyttäjiä on ohjeistettu, miksi taustalla tarvitaan vielä teknisiä ratkaisuja? Hieman sama asia, miksi grillikioskin pitäjällä pitää olla hälytysjärjestelmä tai ostoskeskuksessa vartijat ja tuotteissa hälyttimet? Koska emme toimi niiden sääntöjen mukaisesti, joita meiltä edellytetään. Sama koskee tietoturvaohjeistusta; vaikka ohjeissa kielletään epämääräisten www-sivujen selaaminen tai epäilyttävien sähköpostiin saapuvien viestien linkkien ja liitetiedostojen avaaminen, käyttäjät eivät toimi ohjeiden mukaisesti ja siten vaarantavat oman ja organisaationsa tietoturvallisuuden.

Näitä käyttäjiä sekä tuntemattomien uhkakuvien varalta tarvitaan ns. rautaa rajalle eli mahdollisimman vähän käyttäjälle näkyviä teknisiä ratkaisuja, joilla organisaatio voi huolehtia tietoturvallisuuden L-E-S-mallin toteutumisesta. Jossain tilanteissa on hyvä, että suojakeinot näkyvät (haittaohjelmien torjuntaohjelmat vs vartijat) ja joissakin tilanteissa on parempi pitää ne piilossa (roskapostien- ja haittaohjelmaviestien automaattinen pysäytys vs valvontakamerat, hälyt).

Rautaa saa rahalla, what so?

Tekninen tietoturvallisuus on toteutettavissa huomattavasti helpommin kuin hallinnollinen tietoturvallisuus ja siihen liittyvät prosessit. Miten? Ostamme yleensä jokin appliance-tyyppisen laitteen, sovelluksen, palvelun tai muun toiminnallisuuden, joka edellyttää tyypillisesti vain muutaman henkilön yhteistyötä käyttöönoton ja toteutuksen osalta.

Toiminnallisuus otetaan käyttöön osana tietoliikenne-, työasema- tai palvelinarkkitehtuuria ja sen jälkeen hankittu toiminnallisuus on käytettävissä. Tämä kaikki on helpompaa sen takia, koska bitit tottelevat ja toimivat sovitulla tavalla, ainakin teoriassa paremmin kuin ihmiset. Kuukausien tai jopa vuosien hallinnollisen prosessin, toimintatapamuutoksen ja kenties tähän liittyvän vastustuksen sijaan tekninen hanke on toteutettu viikoissa tai muutamassa kuukaudessa.

Teknologiaan ei saa luottaa liikaa

Organisaatioissa teknologiaan luotetaan liikaa. Teknologia vaatii aina valvontaa, joka edellyttää yleensä ihmistyötä prosessin eri vaiheissa. Kun tietoturvallisuudessa tapahtuu jokin poikkeama, osasyy voi olla tekniikan toimimattomuus; toiminnallisuus ei ole joko toiminut lainkaan tai se ei ole toiminut ennakolta odotetulla tavalla. Kun tähän yhdistetään inhimillinen toiminta, joko tahattomasti tai tarkoituksenmukaisesti, katamme useimmat tietoturvapoikkeamiin liittyvät mahdollisuudet. Kuinka usein kuulemmekaan selityksen ”Tämän ei pitänyt olla mahdollista”, ”Ei sen olisi pitänyt noin toimia” tai ”Tapahtui inhimillinen erehdys.”

Lentokoneessa tai muissa kriittisissä laitteissa ja toiminnoissa (ydinvoimalat) on useita jopa kokonaan toisistaan erotettuja, moninkertaisia järjestelmiä. Yhden järjestelmän pettäessä saadaan toiminnallisuus toteutettua varajärjestelyillä tai estettyä muuten virheellinen toiminta, osittain samaa voidaan edellyttää organisaatiossa niiltä toiminnoilta, jotka ovat sille kriittiset. Mitkä ovat kriittisiä? Hyödynnä BIA (Business Impact Analysis) eli liiketoiminnan vaikutusanalyysiä

Hyvä esimerkki on aikaisemmin mainitsemani klassinen haittaohjelmien torjunta. Monikerroksesisella, sipulimallisella suojauksella pyrimme estämään haitallisen ohjelmakoodin pääsyn käytettävään päätelaitteeseen tai palveluun. Tämä tapahtuu esimerkiksi valitsemalla tarkoitukseen sopiva päätelaite ja käyttöjärjestelmä, haittaohjelmien ja roskapostien torjunta työasema-, palvelin-, sovellus- ja yhdyskäytävätasolla, tietoturva- ja muiden päivitysten keskitetty jakelu-, päivitys ja skannaus, palomuuri(t) sekä erilaisia keinoja tunkeutumisen havainnoimiseksi ja estämiseksi (IDS/IPS).

Vaikka organisaatiolla olisi kaikki nämä käytössä, niitä hallitaan ammattitaitoisesti 24/7 ja ne päivittyvät automaattisesti ajan tasalle ja siitä huolimatta tietoturvallisuus pettää, mitäs sitten?

APT – täsmävakoilulle ei löydy vastakeinoja?

Vuonna 2011 lanseerattiin APT-lyhenne (Advanced Persistent Threat), joka kuvaa huolella suunniteltuja, mahdollisesti pitkällä aikavälillä ja kalliilla rahalla toteutettuja täsmähyökkäyksiä ennalta määritetyn, hyvin suojatun tiedon tai muun omaisuuden anastamiseksi. Jos johtavilta Yhdysvaltalaisilta sotateollisuuden yrityksiltä on mahdollista varastaa heidän salassa pidettävää tietoaineistoa, tehtävä on huomattavasti helpompi merkittävästi huonommin varustautuneiden organisaatioiden osalta. Voimme siis osoittaa, että teknologia ei riitä, tarvitsemme avuksi ihmisen!

APT-hyökkäyksissä käytetään kaikkia kuviteltavia ihmismielen heikkouksia, joiden avulla tietoverkkorikollinen yrittää päästä kiinni organisaatioon ja siellä kohteena olevaan tietoon. Tämän takia mikään perinteinen, tunnettu käytettävissä oleva teknologia ei riitä, koska se heikoin lenkki olet sinä tai minä, joko tietoisesti, tiedostamatta tai inhimillisen erehdyksen seurauksena. Kuinka moni voi olla napauttamatta aviopuolisolta tullutta viestiä, jossa pitäisi olla hauska valokuva?

Sähköistä tiedon holvaamista

Aikaisemmin kaikki kallisarvoinen tieto sijoitettiin pelkästään kassakaappeihin ja –holveihin, joka toteuttaa L-E-S-periaatteen kaksi ensimmäistä osaa hyvin. Näiden heikkous on kolmas kirjain S eli saatavuus ja helppokäyttöisyys; kukaan ei mielellään raahaa mukanaan 500 kg – 2 tn kassakaappia, jonka avaamiseen menee joka kerta minuutteja.

Osa organisaation salassa pidettävistä tiedoista on sellaisia, että niiden suojelemiseksi tulee toteuttaa tarvittavat suojaukset kuitenkin tiedon saatavuus säilyttäen. Käytännössä tämä tarkoittaa tiedon salaamista ja holvaamista siten, että tietoon ei pääse yksinkertaisesti kiinni pelkästään tunkeutumalla sopivaan kohteeseen ja anastamalla esimerkiksi käyttäjätunnus ja salasana, vaan käyttöoikeutta pitää pystyä rajoittamaan usealla eri tavalla.

Samalla tavalla mitä yritämme estää perinteisten haittaohjelmien leviämistä usealla keinolla, teknisen tietoturvallisuuden puolella tarvitsemme samaa kriittisten tietoaineistojen L-E-S:in takaamisessa. Esimerkiksi tällaisen käyttöoikeuden osalta käyttäjätunnistamisessa pelkkä käyttäjätunnus ja salasana eivät saisi riittää, vaan käyttäjältä ja päätelaitteelta tulisi edellyttää näiden vahvaa tunnistamista. Samoin tieteiselokuvista tutut biometriset tunnisteet arkipäiväistyvät seuraavan 10 vuoden sisällä lisävarmenteina.

Kuten kaikessa tietoturvallisuudessa, teknisen tietoturvallisuuden puolella tulisi etsiä heikointa lenkkiä ja yrittää parantaa sitä. Älä osta kaltereita ikkunaan, jos ovessa ei ole lukkoa! Riskienarvioimisella edesautetaan investointien kohdistamista kustannustehokkaasti, älä osta kallista tunkeutumisenhallintajärjestelmää jos sinulla ei ole esimerkiksi käytössä kattavaa työasemien ja palvelimien sovellusten ja päivitysten jakelu- ja päivitysmekanismia.

Hyvää tietoturvaviikkoa!

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Voiko snagari unohtaa tietoturvan?

Heitetään ilmaan pari teoreettista kysymystä:

”Pyöritän sivutoimisena muutamana iltana viikosta pientä snagaria, pitääkö jotain tehdä vai voinko pyyhkiä tietoturva-asioilla ahteriani?”

Tai ”Tuotamme valtionhallintoon palvelua, jossa käsitellään kansainvälisiä turvallisuusluokiteltuja tietoaineistoja – pitääkö jotain huomioida palvelua tuotettaessa?”

Vaikka aluksi mieli tekisi vastata ensimmäiseen kohtaan ”pyyhi”, pakko todeta molempiin että ”pitää”.

Case snagari. On yrityksen koko tai liiketoiminta kuinka pientä tahansa, liikkuu toiminnassa kuitenkin rahaa. Siellä missä liikkuu rahaa, myös (tietoverkko)rikolliset pyrkivät apajille. Vaikka tässä blogissa keskityn tietoturvallisuuteen, snagarin omistajalle fyysiseen turvallisuuteen liittyvät asiat ovat ne tärkeimmät. Maksupääte ja mahdolliset snagarin www-mainossivut, kirjanpito- ja muut pakolliset palvelut - niissä riittää että toimitaan annettujen ohjeiden mukaisesti.

Kun puhutaan laajemmasta liiketoiminnasta, jossa yrityksellä on omien salassa pidettävien tietojen ohella käsiteltävänä asiakkailta- tai muilta sidosryhmiltä saatavaa salassa pidettävää tietoa tai se tuottaa palveluita asiakkaiden toimeksiannosta, ollaankin aivan eri tilanteessa (suossa). Yritys joutuu tällöin täyttämään ne vaatimukset ja velvoitteet, joita siltä edellytetään eri kautta, pääasiassa sopimusvelvoitteina.

Yksi tietoturvakoko sopii kaikelle? Herätys!

Kuvitellaan että yrityksellä on 20 asiakasta, joista 15 on hyväksynyt yrityksen oman sopimusmallin ja turvallisuussopimuksen, mutta viiden muun kanssa on jouduttu tekemään erilliset sopimukset koskien heille tarjottavia palveluita.

Tässä päästään samanlaiseen ongelmaan, jos meillä kotona tarvittaisiin satunnaisesti asunnosta riippuen kylmän ja kuuman veden rinnalle kolme muuta hanaa, joista yhdestä tulee kahvia, toisesta virvoitusjuomaa ja kolmannesta XO-konjakkia. Ei kannata kuvitella, että noiden kolmen hanan asentaminen jälkikäteen ja sieltä tuleva sisältö olisi yhtä halpaa kuin kaikille tarjottava perusvesi.

Edellinen koskee hyvin sitä haastetta, joka osalle yrityksiä tulee vastaan. Asiakkailta tulee omia vaatimuksia, jotka pitää täyttää, jotta kauppaa saadaan klousattua tai kilpailutus voitettua. Tällöin ainakin teoriassa voidaan arvioida, kuinka paljon yritys joutuu kehittämään toimintaansa (prosesseja), jotta se saa täytettyä edellytettävät vaatimukset ja mitä se tulee yritykselle maksamaan. Jos tällainen prosessien kehitys tulee vain yhden tai muutaman asiakkaan maksettavaksi (koska asiakashan loppujen lopuksi kaiken maksaa), saattaa se tulla asiakkaalle liian kalliiksi ja kauppaa ei synnyt tai muussa tapauksessa yritys joutuu itse maksamaan oman prosessiensa kehitystyön.

Asiakas => toimittaja <= alinhankintaverkosto

Tietoturvallisuudella on tällä tavalla tarkasteltuna ainakin kolme näkökulmaa: sidosryhmä- ja muun yhteistyön kautta tulevat velvoitteet, ostettaessa palveluita muilta organisaatioilta (meidän vaatimukset heille) sekä meidän tarjotessa palveluita asiakkaillemme (asiakkaan vaatimukset meille).

Tähän voisi osaksi asiakkaalle tarjottavia palveluita laskea vielä toimittajan omasta alihankintaverkostosta huolehtimisen, koska normaalisti asiakas olettaa yrityksen vastaavan alihankintaverkoston työstä ja toiminnasta ”kuten omastaan”. Näiden ohella organisaatio on saattanut sitoutua muihin velvoitteisiin esimerkiksi sertifioinnin johdosta ja niin, pitäisihän niitä lakejakin muistaa noudattaa.

Selvitäänkö yhdellä vaatimuskokonaisuudella? Nope.

Jos kaikki toimisi kuten Strömsössä, velvoitteet olisi helppo täyttää ja mistään ei aiheutuisi ylimääräisiä kustannuksia kenellekään. Hyvä esimerkki on PCI-DSS-standardi, jonka ”noudattaminen on pakollista kaikille korttitapahtumia vastaanottaville, välittäville tai tallentaville tahoille, kuten kaikille kauppiaille, jotka vastaanottavat maksukortteja sekä kaikille palveluntarjoajille, jotka käsittelevät maksukorttitapahtumia.”

Tämän ohella esimerkiksi valtionhallinnon organisaatiot edellyttävät sille valtionhallinnon palveluita tuotettaessa tietoturvallisuusasetuksen sekä sitä täydentävän Vahti 2/2010 täytäntöönpano-ohjeessa virastoille määritetyistä tietoturvataso-vaatimuksista johdettuja palvelun tuottamisessa edellytettäviä vaatimuksia.

Kyseiset vaatimukset löytyvät Valtion ICT-hankintojen tietoturvaohjeen 3/2011 sivulta 48 alkaen. Alun esimerkissä nostin toisena esimerkkinä organisaation, jolta edellytetään kansainvälisten turvallisuusluokiteltujen tietoaineistojen käsittelykykyä, tällöin esiin kaivetaan vielä uusi asiakirja nimeltään Kansallinen turvallisuusauditointikriteeristö (Katakri) , jota käytetään arvioitaessa tällaisten palveluiden turvallisuutta.

Jos nämäkään eivät vielä riitä, huoltovarmuuskeskus on tuottanut Sopiva-suositukset, joissa on valmiita mallilausekkeita, joita voidaan käyttää palveluiden toimintavarmuuteen ja jatkuvuuteen liittyvistä asioista sovittaessa. Valtionhallinnossa valmistuu lisäksi kevään 2012 aikana päivitetyt, viralliset ICT-varautumisen vaatimukset, joita tullaan jatkossa edellyttämään tärkeiltä valtionhallinnon tai yhteiskunnan toimivuuteen liittyviltä toiminnoilta.

Vaatimuksia on paljon, mutta ovatko no toistensa kanssa kuinka yhteensopivia tai kuinka edellä mainitut asiat voidaan optimoida? Valitettavasti em. vaatimukset ovat yhteensopivia vain yleisellä tasolla, esimerkiksi riskienhallintaa vaaditaan, mutta käytännön tasolla yksittäiset vaatimukset voivat olla hyvinkin erilaisia. Oikeassa elämässä yritys joutuu analysoimaan jokaisen heitä sopimuksien kautta tulevan velvoitteen erikseen ja yrittää miettiä mahdollisimman kustannustehokasta keinoa vaatimusten toteuttamiseksi.

Tietoturvallisuudesta kilpailuetua?

Tästä päästään siihen, miten tietoturvallisuus voi toimia kilpailuetuna. Nyt kun näyttää siltä, että erääksi 2010-luvun rooliltaan yhä merkittävämmäksi tekijäksi tulee tietoturvallisuuden ja yksityisyydensuojan toteuttaminen palveluissa, yritys joka pystyy ketterästi ja kustannustehokkaasti toteuttamaan nämä prosesseissaan ja akkreditoinneilla / sertifioinneilla osoittamaan tämän, on vahvoilla.

Tammikuu on sujunut hallinnollisen tietoturvallisuuden puolella, ensi viikolla revitellään teknisen tietoturvallisuuden haasteiden parissa unohtamatta kansallista tietoturvaviikkoa ja -päivää 7.2.

Palautetta kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Johtaja - kanna vastuu ja määritä politiikka

Kenelle kuuluu organisaatiossa vastuu tietoturvallisuudesta? Jos organisaation asiakastietokanta sujahtaa nettiin yleiseen jakeluun, kuka on syytettyjen penkillä?

a) Toimitusjohtajaa

b) Tietoturvapäällikkö

c) Henkilö, jonka takia tietokanta on vuotanut

Entäs kenen tehtävä on huolehtia siitä, että tietoturva-asiat ovat kunnossa ja niitä julmetun_piiiitkiä_kuivia_ilman_kuvia_olevia_ja_kaiken_tuottavuuden_tappavia_ohjeita noudatetaan?

a) Toimitusjohtajan

b) Tietoturvapäällikön

c) Henkilöstön

Yhdeksän eri vaihtoehtoa? TÖÖÖÖÖT – väärin. Jos olet valinnut vain yhden jälkimmäiseen, olet väärillä jäljillä, mieti uudelleen.

Vastuu tietoturvallisuudesta kuuluu ylimmälle johdolle, käytännössä linjaorganisaatiossa esimerkiksi toimitusjohtajalle. Sen sijaan että hän oikeasti vastaisi käytännön toteutuksesta, samalla tavalla mitä muun johtamisen osalta, hän delegoi päätöksentekoa tietoturvaorganisaatioille, esimerkiksi tietoturvapäällikölle.

Jos valitsit alempaan vaihtoehtoon yhden vaihtoehdon, pieleen meni. Sama juttu kuin työhyvinvointiasioissa, organisaatio on niin terve ja hyvinvoiva kuin kaikki sen yhdessä kokevat yhdessä työilmapiirin muodostaen. Sama koskee tietoturvallisuutta, kuten edellisessä blogissani korostin, tietoturvallisuus on osa asennetta, kulttuuria ja prosessia, sen pitää olla läsnä kaikkialla. Tämän takia tietoturvallisuus on kaikkien yhteinen asia ja jokaisen tulee siitä huolehtia omien vastuiden ja työtehtävien mukaisesti.

Mitä johdon tulee vähintään tietää?

Valtionhallinnon tietoturvallisuuden johtoryhmän 2/2011 Johdon tietoturvaohje määrittelee seuraavat asiat johdon tietoturvavelvoitteiden muistilistalle:

1. Lainmukaisuuden varmistaminen
2. Riskienhallinnan- ja hallintajärjestelmän toteuttaminen
3. Tietoturvapolitiikkaan sitoutuminen
4. Tietoturvajohtaminen
5. Tietoturvavastuuhenkilön nimeäminen
6. Tietoturvallisuuden organisointi
7. Tietoturvallisuuden toteutumisen varmistaminen
8. Tietoturvallisuuden TTS-suunnitteluedellytysten luonti
9. Poikkeama- ja erityistilanteiden hallinta
10. Tietoturvaraportointivelvollisuuksista huolehtiminen

Tätä kokonaisuutta tukee asiakirja nimeltään tietoturvapolitiikka tai –linjaus tai mitä nimitystä tästä ohjausasiakirjasta halutaankaan käyttää. Edellä mainitusta VAHTI-ohjeesta löydät myös malliesimerkin politiikasta, mutta tiivistettynä siitä tulisi löytyä ainakin seuraavia asioita:

1. Johdanto eli miksi tällainen asiakirja tarvitaan; ”kyllä, tietoturvallisuus on meille tärkeä asia ja olemme sitoutuneet siihen kybällä”
2. Tavoitteet eli mihin tällä kaikella pyritään? L-E-S (Luottamuksellisuus – Eheys – Saatavuus)
3. Velvoitteet - minkä takia tietoturvallisuus on meille niin tärkeää?
4. Organisointi ja vastuut – kuka vastaa ja tekee mitäkin, tässä on otettava huomioon myös ulkoiset toimijat, ei pelkästään sisäinen toiminta, kehittämistä ei saa unohtaa.
5. Riskienhallinta- ja muut keskeiset periaatteet, ohjeet ja linjaukset jonka mukaan organisaatio tulee toimimaan. Nämä muodostavat muun dokumentaation kanssa erillisen, laajemman ohjekokonaisuuden.
6. Koulutus. Yksikään politiikka tai ohje ei siirry käytäntöön ilman koulutusta (ja jalkautusta) sellaisen tekemällä ja pelkällä määräyksellä (poikkeukset vahvistaa säännön). Pelkkä verkkokoulutus ei riitä vaan tässä tarvitaan oikeaa ADIDASta ja sähköisen kohtaamisen rinnalla face-to-face-jalkautusta. Pelkkä koulutus ei riitä, yhtä tärkeää on säännöllinen tiedottaminen uusista uhkakuvista, muuttuneista käytännöistä ja vinkkejä turvallisista, hyvistä käytännöistä.
7. Koska kyse on ihmisistä, ei bittitasolla toimivista laitteista, miten huolehditaan henkilöstön motivoinnista? Keppi ei toimi, tarvitaan porkkanaa. Kaikki keskeiset tutkimukset toitottavat sitä, että henkilöstö on se kuuluisa heikoin lenkki. Politiikan pitää olla kirjoitettu napakasti ja ymmärrettävästi.
8. Seuranta ja raportointi; kuka huolehtii siitä, että asiat tehdään sovitulla tavalla tai mitä tapahtuu, jos joku rikkoo näitä sääntöjä?

Tietoturvapäällikkö (tai konsultti) ei saa tehdä politiikkaa yksin ja hyväksyttää se kumileimasimena toimivana vedetään-pässiä-kuin-narussa johtoryhmällä vaan johto pitää osallistaa ja sitoa työhön jotta he ymmärtävät, mitä politiikka käytännön tasolla tarkoittaa. Pelkkä politiikka ei valitettavasti vielä riitä vaan se osa tietoturvallisuuden hallintajärjestelmää, jonka avulla organisaatio huolehtii tietoturvallisuuden jatkuvasta kehittämisestä.

Kotitehtäviä:

• tietoturvapolitiikka on julkinen asiakirja, ellei se ole netissä kaikkien luettavissa niin ainakin edes intranetissa – missä teidän tietoturvapolitiikka on ja milloin se on päivitetty? Mikäli se on vanhentunut, kannattaa se katselmoida ja päivittää ajan tasalle! Onko politiikka ymmärrettävä ja löytyykö organisaatiosta tarvittavat lisätiedot ja ohjeet politiikan tueksi?

• miten organisaatiossasi henkilöstö on motivoitu huolehtimaan tietoturvallisuudesta, siis jotenkin muuten kuin että ”pakko”?

• milloin olet viimeksi osallistunut tietoturvakoulutukseen? Mitä seuraa, jos rikot tietoturvaohjeita?

• onko organisaatiosi tietoturvallisuuden kehittäminen sattumanvaraista vai suunnitelmallista? Onko tietoturvallisuuden hallintajärjestelmä tunnistettavissa?

Palautetta – kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.

Turvasatama

Tästä tietoturvallisuudessa on kyse!

Tervetuloa uuteen viikottaiseen blogiin, joka tulee tarkastelemaan tietoturvallisuutta sekä organisaation että yksilön, niin työntekijän kuin yksityishenkilön roolista, etenkin kun kyseeseen tulee yksityisyydensuoja. Viikoittaisen pääaiheen ohella nostan esille mahdollisesti jonkin viime aikojen keskeisen aiheeseen liittyvän uutisen tai muun tapauksen, josta muutkin voivat oppia.

Kaiken takana on kolme eri näkökulmaa tietoon

Tietoturvallisuuden tehtävänä on huolehtia tietojen tarkoituksen- ja vaatimusten mukaisesta suojaamisesta luottamuksellisuuden (confidentiality), eheyden (integrity) ja saatavuuden (accessibility) näkökulmasta. Tästä englanninkielisestä CIA-lyhenteestä tulen jatkossa käyttämään lyhennettä L-E-S. Vaikka tieto olisi julkista, sillä voi olla organisaation toiminnan kannalta edelleen suuri merkitys joko eheyden (tieto ei saa muuttua) ja/tai saatavuuden (tieto on saatavilla 24/7 tai 99,99% SLA) suhteen.

Ajatellaan käytännön esimerkkinä (pienen) organisaation verkkokauppaa, toki asiakas- ja käyttäjätietojen luottamuksellisuuden säilyttäminen on tärkeää, mutta tärkeätä on se että kaupassa olevat tiedot ovat oikein sekä kauppa on pystyssä silloin kuin asiakkaat haluavat jotain ostaa. Entäs organisaation julkinen www-palvelin?

Unohdetaan jo lintukotoajattelu!

Olemme tuudittautuneet kenties liikaa siihen tunteeseen, että elämme lintukodossa, jonne rajatusta kielialueesta johtuen tietoturvauhat eivät voi rantautua. Tcp/ip-protokollan ip-paketin saapuminen Euroopasta Suomeen kestää vain muutaman kymmenen millisekuntia pitempään.

Viime syksynä julkisuuteen päätyneet tietomurtojen avulla varastetut ja nettiin julkistetut laittomat henkilötiedot ovat vain pieni esimerkki siitä, mitä voi tapahtua kun asiat eivät ole kunnossa. On turha kuvitella, että tämä on vain ohimenevä ilmiö, vaan tietovuoto- ja –murtouutisista tulee jatkossa pysyvä ilmiö, uusimpana tämän vuoden kasvavana ilmiönä yksittäisiin organisaatioihin liittyvät vuoto (leaks)-sivustot.

Säästä rahaa riskienhallinnalla

Tietoturvallisuudella ei pidä pelotella. Kuinka moni jättää organisaatioon hankkimatta rikos- ja kulunvalvonta-, palohälytin- ja sammutusjärjestelmiä ajatellen, että eihän meille ole ennenkään murtauduttu tai ei meillä ole ollut koskaan tulipaloa?

Jos organisaation asiakastiedot vuotavat nettiin, millainen imago- ja sitä kautta liiketoimintaan liittyvä vaikutus sillä organisaatiolle on? Mitä maksaa nykytilanteen tekninen auditointi / haavoittuvuusskannaus kyseiseen järjestelmään sekä organisaation omien hallinnollisten prosessien läpikäynti – verrattuna riskin laukeamisessa tapahtuvaan vahinkoon ja sitä kautta syntyviin vahinkoihin?

Yleensä organisaation johto myöntää rahan ”avoimella valtakirjalla” sen jälkeen kun ensimmäinen merkittävä riski on toteutunut – ”laittakaa asia kuntoon!”. Riskin tunnistaminen etukäteen ja sen pienentäminen on yleensä edullisempaa kuin sen toteutumisesta aiheutuvat vahingot. Tämä on se myyntiargumentti, jolla riskienhallinta osana tietoturvallisuutta tulee organisaation johdolle myydä. Samoin jos riskienhallintaa ei tehdä, organisaatio haaskaa euroja aivan vääriin parannuksiin, koska investoinnit tehdään mutu & rahi-periaatteilla kustannustehokkuutta tuovan riskienhallintaprosessin sijaan.

Kiteytettynä ongelma on se, että a) riskienhallintaprosessia joko ei käytetä lainkaan, b) se kohdistetaan vääriin kohteisiin tai c) esille nostettujen riskien korjaustoimenpiteitä ei seurata. Mistä voi lähteä liikkeelle? Tutustu esimerkiksi PK-RH:n sivuihin.

Tietoturvallisuus on osa asennetta, toimintakulttuuria, prosessia sekä SOPIMUKSIA!

Niin kauan kuin tietoturvallisuus elää organisaatiossa, ihmisissä, ajatuksissa ja teoissa omana erikseen mietittävänä osa-alueena, se ei tue liiketoimintaa ja aiheuttaa takuuvarmasti ylimääräisiä kustannuksia => negatiivinen menoerä, joka ei maksa ikinä itseään takaisin. Tietoturvallisuuteen liittyvät asiat pitää olla integroituna osaksi toimintaprosesseja ja asennetta, myös ICT:n ulkopuolella, esimerkiksi henkilöiden käyttäytymisessä.

Kuten kaikessa muussa johtamisessa, on se henkilö- tai toiminnanjohtamista, organisaation johdon merkitys myös tietoturvallisuuden kehittämisessä ja levittämisessä on korvaamaton. Jos johto ei tekemisellään, puheillaan ja toimintatavoillaan osoita kiinnostusta ennen kuin jotain tapahtuu – jos silloinkaan, ei henkilöstäkään tule sitä tekemään.

Jos tietoturvallisuuteen liittyviä asioita ei ole sovittu osapuolien välillä kirjallisilla sopimuksilla, ollaan kuuluisilla heikoilla jäillä. Mitä tärkeämmäksi tietoaineistojen luottamuksellisuuden rooli muodostuu, sitä tärkeämpää on sopia tietoaineistojen käsittelystä esimerkiksi erityisellä turvallisuussopimuksella. Jos kerta palvelutasoluokista (SLA) pitää sopia, miksei sama koskee tietoaineistojen käsittelyä? Löydät hyvän turvallisuussopimusmallipohjan muokattavaksesi uunituoreesta VAHTI 3/2011 Valtion ICT-hankintojen tietoturvaohjeen sivulta 81 alkaen.

Palautetta – kimmo@ict-tuki.fi

Kimmo Rousku on toiminut sivutoimisena tietokirjailijana ja esiintyjänä vuodesta 1985 alkaen. Päätoimenaan hän kehittää tietoturvallisuutta valtionhallinnossa. Yllä mainitut mielipiteet eivät edusta hänen työnantajansa kantaa, vaan ovat hänen henkilökohtaisia mielipiteitään.