Tämän vuoden haastajalistan nimet olivat vaihtuneet kahta lukuun ottamatta. (lähde: tivi.fi)

Näiden kahden vuoden jälkeen Trusteqin tavoitteena on poistua haastajalistalta ja siirtyä 200 suurimman joukkoon tuonne 250 -listalle.

Virtu-speksi on derivoitu yliopistojen käyttämästä Haka-speksistä. Julkishallinnon toimintaympäristö on kuitenkin kovin erilainen kuin yliopistojen välinen avoin yhteistyö. Haka:ssa kaikki käyttäjästä tarvittavat tiedot (= attribuutit) ovat mukana federointiviestissä ja järjestelmät poimivat siitä tiedot tarpeen mukaan käyttöönsä. Businessmaailmassa, jossa julkishallintokin käytännössä elää, asia on kuitenkin kovin erilainen. Iso osa sovellutuksista, joiden käyttöä juuri Virtu helpottaisi, pyörii kolmansien osapuolien ylläpitäminä tai omistamina. Ja usein näille kolmansille osapuolille on tarpeen tietää tarkka käyttäjämäärä esim. laskutusperusteeksi. Lisäksi osalla sovellutuksista on pitkä historia ja sovellus on pultattu kiinni käyttäjädataan niin tiivisti, ettei sitä pystytä purkamaan. Näissä tapauksissa käyttäjädata siis pyörii sovellutuksessa ja sitä ei voida federoida “lennossa” sovellukseen. Tällaisille sovelluksille federointi on vain puolet ratkaisusta ja käytännössä täyttää vain SSO:n vaatimukset. Käyttäjähallinnan haasteet jäävät kuitenkin jäljelle. Tällaisia ovat esimerkiksi käyttäjätilien perustaminen sovellukseen (provisioiminen) ja niiden poistaminen (deprovisiointi) ja nämä ovat usein vähintäänkin yhtä iso ongelma automatisoida kuin itse federoinnin toteutus.

Virtuun liittymisen vaatimuksiin on listattu myös valtiohallinnon tietoturvatasojen mukaiset auditoinnit. Auditointi on varsin raskas prosessi ja mielestäni jokseenkin turha vaihe pakottaa tehtäväksi tässä yhteydessä. Olisi hyvä, että auditointiin kannustettaisiin organisaatioiden oman parhaan vuoksi, eikä sitä asetettaisi rasitteeksi uusien tekniikoiden käyttöönotolle. Lisäksi sovellusten vaatimat tietoturvatasot tulisi olla määriteltyinä ennen kuin vaaditaan IdP-järjestelmille jotain tiettyä tasoa, muuten tietoturvatasot menettävät merkitystään.

Yleisesti on suositeltava, että julkishallinnon organisaatioiden olisi hyvä omistaa oma IdP tai sitten olla mukana jossakin yhteisessä IdP:ssä. IdP:n hankinta ei nykypäivänä ole ongelma, tarjontaa löytyy niin Open Source kuin kaupalliseltakin puolelta ja myös Virtuun erikoistuneita konsulttitaloja löytyy. IdP:n voi myös hankkia SaaS-palveluna, jolloin oma investointikin on minimaalinen. Viralliseen Virtuun liittyminenkään ei aina ole pakollista (tietoturva-auditoinnit) vaan tarvittaessa IdP – SP tahojen välillä voidaan tehdä kahden väliset sopimukset vaikkakin itse federointiviesti olisi Virtun mukainen. Tällöin organisaatio voisi joustavasti liittyä Virtuun suorittamalla tietoturvatasojen mukaisen auditoinnin, infra kuitenkin olisi jo yhteensopiva siihen. Jos organisaatiolla ei kuitenkaan ole perus IAM-infra kunnossa, niin IdP:n täysimittainen käyttäminen voi olla vaikeaa.

Suurimpana ongelmana näen käyttäjätietojen hallinnan (provisiointi ja deprovisiointi). Niin kauan kuin tähän problematiikkaan ei tule malliratkaisuja, joita julkishallinnon piirissä käytettäisiin, federoinnin leviäminen on hidasta ja siitä ei saada täyttä hyötyä irti. Myös tietoturva-aspektista tilanne on haastava niin kauan kun esim. deprovisioinnin laadusta ei voida mennä varmuuteen. Tätä problematiikkaa käsittelee mm. Gartnerin raportti “The Emerging Architecture of Identity Management“.

Kun miettii tarkemmin yllämainittuja seikkoja ja myöntää sen faktan, että federoinnista on turhalla jargonilla tehty hyvin monimutkainen asia ymmärtää, niin Virtun käyttöönoton innostuksen puutetta on helppo ymmärtää.

Perinteisesti tietoturvanäkökohdista nostetaan esiin tiedon hakeminen ja yrityksen resursseihin muodostetut yhteydet ei-luotetuista lähteistä. Yrityksen työntekijöistä seikkailija-Pete, jonka kesäloman kohokohta on nettiin pääseminen Bagdadin Bunker Bar:in julkiselta koneelta, nostetaan esiin, ja ratkaisuna yrityksen access management -laitteistoista käännetään tietoturvanupit kaakkoon. Tällä saadaan luonnollisesti ratkottua kiusallinen ongelma, jossa yrityksen resursseja käsitellään epämääräisellä kioski-linux/windows -koneella. Mielestäni tämän ongelman ratkomisesta on puhuttu tarpeeksi, ja suurimmasta osasta tietoturvalaitteiden powerpoint-suosta löytyy joku ehdoitelma tai ratkaisu ongelmaan.

Tässä blogikirjoituksessa onkin tarkoitus puuttua mielestäni paljon kiinnostavampaa ongelmaan. Nimittäin oikeuksien myöntämiseen ja hallinnointiin lomien aikana. Governance -mallissa oikeuksien myöntäminen voidaan yksinkertaistaa oikeuksien hallintaan ja oikeuksien hallinan seuraamiseen.
Otetaan leikkisä esimerkki, jossa edellä mainittu Pete toimii osa-aikaisena työntekijänä koulun ohella, ja joka talvella on puuhastellut projekti A:n parissa. Kesällä, projekti A:n pysähtyessä, halutaan Peten luova panos siirtää projekti B:n käyttöön. Kiusallisesti projekti B:n oikeuksien myöntäminen tapahtuu projekti B:n esimiehen toimesta, joka istuskelee mökillään, josta myrsky on katkonut sähköt ja kalja lämpenee kaapissa. Petelle oikeuksien saaminen vaatisi kaksi erillistä vaihetta. Lomien alkaessa voidaan delegoida oikeus antaa oikeuksia projektin resursseihin, ja myönnetyistä oikeuksista pitää jäädä selvä ja näkyvä audit trail jota voidaan myöhemmin seurata ja varmistaa että oikeuksien antamisessa käytettiin valmista myöntämismallia. Tähän löytyy runsaasti ratkaisuita, mutta helppona esimerkkinä voidaan mainita Microsoft Forefront Identity Managerin ryhmienhallintatyökalut. Valmiiksi kuvatut prosessit ja integroidut hallintatyökalut mahdollistavat joustavan ja seurattavan vastuuiden siirron ja auttavat yritystä säilyttämään ketteryytensä ilman heikkenevää tietoturvaa.

Kevään hiihtolomat ovat jo kulman takana, joten ei muuta kuin suunnittelemaan.

Tässä ensimmäisessä kirjoituksessa käyn läpi sitä, mitä roolitieto on ja mihin sitä käytetään, sekä miksi sen haltuunottoon lähdetään usein väärästä päästä, eli softatuotteen ostamisesta.

Käytännönläheisen tekijäfirman, kuten Trusteqin, kannalta asia on erittäin mielenkiintoinen, mutta minusta perusymmärryksen haltuunotto on suositeltavaa kaikille tietoturvasta kiinnostuneille, sillä kuten kaikki tiedämme, on olemassa oikeaa tietoturvaa ja sitten valitettavasti paljon valohoitoa, jolla ei välttämättä ole tietoturvan kanssa mitään tekemistä.

Niinikään minusta on hieman epämiellyttävä ajatus, että toistaiseksi yksikään roolienhallintaan käytettävän ohjelmistotuotteen edustaja ole juurikaan ymmärtänyt mistä olen heille puhunut kun avaan keskustelua roolitiedonhallinnasta. Tässä asiassa ostajan on helppo olla myyjää fiksumpi ja näin saada itselleen onnistunut hanke.

Tiedonhallintamielessä asia on minusta päivänselvä. Roolitietoa tarvitaan kaikissa organisaation osissa ja kaikkien organisaation osien olisi hyvä ymmärtää roolitieto samalla tavalla, oli sitten kyse ihmisistä tai tietojärjestelmästä. Mitä sitten tämä roolitieto on? No, kaikissa organisaatioissa esitetään jatkuvasti seuraavia kysymyksiä osana yrityksen jokapäivästä toimintaa:

• Kuka on kenenkin esimies?
• Mikä osasto on vastuussa mistäkin?
• Mikä on työntekijän A toimenkuva?
• Mihin järjestelmiin pitäisi A:n päästä toimenkuvansa puolesta?

Roolitieto siis toimii tienviittana, kun organisaatiossa jaetaan vastuita ja velvollisuuksia. Ja näiden vastuiden ja velvollisuuksien toisaalta pitäisi kohtuullisen tarkasti heijastella pääsyä tietojärjestelmiin, jotta voidaan puhua hallitusta ja turvallisesta järjestelmästä. Roolitieto kuvaa siis osaltaan sitä loogista rakennetta, mitä organisaatio on ja mitä sen sisällä tulisi tapahtua vastuumielessä kun jotain työtä tehdään.

Eli meillä on tietoa, joka toisaalta pitäisi ymmärtää samalla tavalla joka puolella organisaatiota ja joka toisaalta pistäisi olla jotenkin hallittu siten, että sekä liiketoiminta että IT-järjestelmät voisivat toimia yhteen tehokkaalla tavalla. Mitä tämä tieto siis tiedonhallinnallisesti on?  Tämä on se kysymys mihin roolienhallintasovellusten valmistajat minusta eivät ymmärrä vastata oikein. Aivan oikein, kysymys on organisaation master datasta. Keskimäärin kuitenkaan role management-hanke ei ole lähelläkään master data management-hanketta lähestymistavan, resursoinnin tai käytettyjen menetelmien kannalta katsottuna.

Olen myös synkkänä päivänä miettinyt, että voiko tämän melko itsestäänselvän havainnon sivuuttaminen olla tarkoitusellista? Jokainen master data- tai data management hankkeita läpikäynyt tietää, että kyseessä ei ole helppo homma. Ensimmäinen tapa mokata ko. hanke on ostaa softatuote, jonka sitten toivotaan ratkaisevan ongelman. Roolien hallinta, kuten data management yleensäkin, on lopulta hyvin prosessi- ja ajatusintensiivistä puuhaa johon toki tarvitaan työkaluja, mutta itse ongelma ei työkaluilla ratkea.

Jos ajatellaan vaikkapa tietoa joka on yleisesti hyväksytty master dataksi, huomataan miksi näin on. Valitaan esimerkiksi tuotedata, eli mitä tuotteita yritys myy ja mitä tietoa näihin liittyy (versioriippuvuudet, dokumentaatio, hinta, vastuullinen osasto jne). Uskooko joku, että on olemassa ohjelmistotuote, joka automaattisesti selvittää mitä tuotteita yritys valmistaa ja keräilee näistä kaiken niihin liittyvän tiedon? Ei varmasti. Toisin sanoen, tarvitaan ihmisiä muokkaamaan dataa informaatioksi, joka sitten syötetään tietojärjestelmään, joka toimii tuotetiedon master-järjestelmänä.

Tilanne ei muutu juuri mitenkään kun tuotetieto vaihdetaan roolitiedoksi. Edelleenkään softa ei sitä automaattisesti muodosta, vaan roolitiedon hallintahankkeeseen tarvitaan mukaan osaavia ihmisiä, jotka tutkimalla organisaatiota ja tallennettua tietoa selvittävät, mitä rooleja firmassa oikeasti on ja miten nämä parhaiten organisoidaan rooleiksi.

Toinen, jopa ehkä vahvempi argumentti sen puolesta, miksi roolienhallinta tulisi tehdä ennemmin tiedonhallintahankkeena on, että roolit muuttuvat organisaation muuttuessa ja niiden luonti, muutos ja poisto tulisi tehdä osana jotain ei-teknistä (esim. HR) prosessia ennemmin kuin IT-osaston toimesta. Loogisella tasolla tiedonhallinta on lähempänä business arkkitehtuuria kuin IT-arkkitehtuuria ja prosessien mallinnus on osa business arkkitehtuuria eikä niinkään IT-työ. Varsinaiset vastuut prosessien ja informaation mallintamisesta toki vaihtelevat yrityksittäin, joten tätä on vaikeampi perustella. Tärkeää kuitenkin on, että oikean alan osaajat tekevät työn ja prosessien pyörittämisen vastuu luovutetaan sinne, missä se parhaiten pystytään hoitamaan.

Loppuyhteenvetona: Roolitieto, eli mitä kenenkin on tarkoitus tehdä firmassa ja kuka kantaa vastuun, on minusta selvästi organisaation master dataa. Tästä syystä roolienhallintahankkeita, jotka usein ovat osana IAM-hanketta, tulisi suunnitella, johtaa ja toteuttaa tiedonhallintahankkeina. Kun roolitieto on muodostettu ja hallittu oikein organisaatiossa, IAM-hankkeessa on suhteellisen helppo muodostaa näistä pääsynvalvonnan kannalta merkityksellisiä järjestelmärooleja, jotka sitten edelleen myöntävät oikeuksia eri tietojärjestelmiin.

Seuraavassa kirjoituksessa ajattelin pureutua tarkemmin siihen, miten roolitiedon mallinnus sitten oikeastaan pitää sisällään. Jatketaan harjoituksia pian!

1.6.2010 alkaen olemme entistä monipuolisempi tietoturvatalo.

Uudistuksemme liittyy 1.6.2010 voimaan tulleeseen yrityskauppaan, jonka seurauksena tietoturvatalo Optisec Oy siirtyi osaksi Trusteq Oy:tä. Yrityskaupan tavoitteena on tarjota entistä parempaa ja monipuolisempaa osaamista nykyisille ja tuleville asiakkaille.

Optisec Oy jatkaa toimintaansa Trusteq Consulting -nimen alla, tarjoten organisaatioille korkeatasoista asiantuntijaosaamista tietoturvaan ja tietoliikenteeseen liittyvissä hankkeissa ja projekteissa: hankejohto, projektijohto, riskienhallinta, -arkkitehtuurisuunnittelu ja konsultointi

Trusteq Solutions on keskittynyt erityisesti pääsyn- ja käyttäjätiedon hallintaan sekä web-tietoturvaan. Se tarjoaa koulutusta, konsultointi, teknistä tukea sekä valmisohjelmistoja. Palvelutarjontaamme pääset tutustumaan helpoiten Palvelut -osion kautta.

Lisätietoja palveluistamme saat tarvittaessa myös myynnistämme. Ota siis rohkeasti yhteyttä! Asiantuntijamme vastaavat mielellään kaikkiin  sinua askarruttaviin kysymyksiin ja auttavat sopivan ratkaisun löytämisessä.

Ethän unohda Blogiamme. Viimeisimmät uutiset ja arviot tietoturva-alan ratkaisuista, tuotteista, palveluista ja tapahtumista päivitetään juuri sinne.

Ensimmäinen käyttötapaus on extranet-sovelluksen julkaiseminen suoraan UAG:n läpi. Suoralla julkaisulla voidaan hyödyntää UAG:n laajoja tietoturvaominaisuuksia, ja mahdollistaa monipuolisemmat autentikointimallit. Käyttötapauksen hyötynä on kevyet asennus- ja kustoimointivaatimukset. UAG näkyy loppukäyttäjälle mahdollisesti lomakeautentikointina tai haluttaessa se voidaan piilottaa täysin. Julkaistaessa esimerkiksi sharepoint, voidaan hyötyä suoraan laajasta tuesta ja sharepoint-pakettien natiivikäsittelystä (http://technet.microsoft.com/en-us/library/dd857299.aspx). Vahvalle pohjalle rakentaminen mahdollistaa käytön laajentamisen helposti myöhemmässä vaiheessa.

Toisena käyttötapauksena voidaan eritellä UAG:n käyttö portaalina extranet-palveluihin. Tämä mahdollistaa useiden palveluiden julkaisemisen yhdestä näkymästä. Palveluiden keskittäminen ja julkaiseminen ei vielä muodosta merkittävää uutta innovaatiota, mutta mahdollisuudet palvelun hallintaan ja mukauttamiseen ovat huimat. Portaalin muokkaamiseen on käytössä enemmän mahdollisuuksia kuin koskaan aikaisemmin ja merkittäviä osia SharePoint toiminnallisuudesta voidaan toteuttaa UAG:n portaalissa. Tämä mahdollistaa luovien ja kiinnostavien portaalien kehittämisen, jossa voidaan hyödyntää aplikaatiokohtaiset autentikointi-/tietoturvavaatimukset. UAG:n vahvuus onkin nimenomaan liiallinen monipuollisuus. Tämä asettaa projektin suunnittelussa haasteen asioiden tuottamisen oikeassa kohtaa hierarkiaa. Merkittävät vaatimukset monimutkaisista landin page -kombinaatioista voidaankin toteuttaa UAG:n sisällä, joka on tietoturvan kannalta merkittävä kehitysaskel. Sanomattakin lienee selvää että loppukäyttä arvostaa työtä, joka on portaalin kehittämiseen käytetty. Perinteisen tylstän portaalinäkymän sijaan saadaan saumaton käyttökokemus koko extranetin laajuudelta.

Entä ne muut UAG:n ominaisuudet? Direct Access? No se onkin sitten toinen tarina, johon liittyy olennaisesti sama kiusallinen liiallinen monipuolisuus. Sisäverkon käyttäjien päästäminen yrityksien resursseihin eroaa merkittävästi extranet vaateista. Tämän takia onkin suositeltavaa miettiä onko järkevämpää ajatella extranet käytössä UAG kokonaan itsenäisenä kokonaisuutena.

Ei muuta kuin Dream BIG with UAG

Vierailin messuilla kumpanakin tapahtumapäivänä 13.-14.4.2010, ja myönnettäköön, että väkeä oli paikalla kiitettävästi.  Tapahtuman mediaseksikkäät teemat aina sosiaalisesta mediasta pilvipalveluihin olivat olivat vetäneet kansan messukeskukseen. Siitäkin huolimatta että aiheena ne alkavat olla jo läpikoluttuja. Facebookia,  hakukonemarkkinointia, Cloudia ja virtualisointia on käsitelty kuluneen vuoden aikana lähestulkoon kaikissa mahdollisissa medioissa, seminaareissa ja tapahtumissa, joten on vaikea löytää niistä enää mitään uutta ja jännittävää. Eikä sellaista messuilla löytynytkään.

ICT-alan ammatilaisille messuilla ei mielestäni ollut paljoa uutta tarjottavaa, mutta suurelle yleisölle tapahtuma toimi toki mukavana tapana paeta työpöydän äärestä ihmisten pariin. Harmi vain että suuri osa seminaarivieraista, etenkin Internet Expo –tapahtumssa, joutuivat seuraamaan luentoja ja paneelikeskusteluja seisaaltaan tai lattialta käsin, koska istumapaikkoja oli varattu vain muutamalle kymmenelle. Ehkäpä tässä on kehityksen paikka seuraavia messuja ajatellen.

Tietoturvan, erityisesti identiteetin ja pääsynhallinnan osalta näkyvyys messuilla oli pieni.  Kaikki tärkeimmät IAM-asiantuntijatalot Accenturesta Secproofiin ja Fujitsusta Nixuun loistivat poissaolollaan.  Kyllä, myös Trusteq. Lieneekö syynä ollut juuri tapahtuman yleisluontoisuus, sillä ottaen huomioon viimeaikaiset tietoturvamurrot esim.  Suomi24 –palveluun, olisi aihe ollut enemmän kuin ajankohtainen. Toisaalta toimivan identiteetin ja pääsynhallinnan sekä Web –tietoturvan pohtiminen ei kuulu kuluttajan tai työntekijän harteille, vaan yritysjohdon, ennen kaikkea HR:n ja tietohallinnon vastuulle. Ja tätä porukkaa varten on olemassa ihan omat messut.

Listätietoa IAM-alan tapahtumista löydät mm. Tapahtumat –sivuiltamme.

Suomen kasvun veturia on nyt postNokia aikana etsitty kissojen ja koirien kanssa. Perusteollisuudella ei oikein taideta nostetta enää aikaansaada. Jossain vaiheessa biolääketieteen tuli pelastaa Suomi, sitten taas palvelusektorin ja nyt energia- ja ympäristöteknologian. Yhtä kaikki, tomialalla ei kai niin väliä, kunhan homma perustuu osaamiseen. Kännykänkuoria maalamalla emme ole enää pitkään aikaan pärjänneet itämaisille ystävillemme. Onneksi Ohjelmistoyrittäjät ovat ryhdikkäästi lähteneet suomalaisten ohjelmistoalan kasvuyritysten äänitorveksi. Vaikuttamista tarvitaan.

Meidän IAM-toimialamme kasvu näyttäisi varsin tasaiselta. Intialaiset kolleegamme ovat tehneet napakan yhteenvedon Gartnerin tuoreesta markkinakatsauksesta. Sen mukaan IAM-markkina tulee tänä vuonna kasvamaan 8% maailman laajuisesti. Itse uskon Euroopassa ja etenkin pohjoismaissa paljon kovempiin lukuihin. Jenkkien kasvupyrähdys oli jo vuosi pari sitten Enronien ja SOXien seurauksena. Meillä aletaan vasta nyt näkemään liiketoiminnalliset vaatimukset käyttäjähallinnalle. Näistä etunenässä säädösten mukaisuus, auditoitavuus ja toiminnan tehostaminen ovat selkeitä tietoturvaan ja jatkuvuuteen liittyviä liiketoimintahyötyjä.

Trusteq kasvoi viime vuonna 51%. Teimme sen vielä erittäin kannattavasti. Olimme Talouselämän Menestyjät listalla Suomen 10. paras tietojenkäsittelypalveluyritys viidellä tähdellä (*****). Sen lisäksi melkein tuplasimme henkilökuntamme.

Meillä kasvu merkitsee liikettä. Aika usein se on myös synonyymi muutokselle, jonka hallitseminen on aina haastavaa. Kasvun tekijöille eli henkilökunnallemme se tuo mahdollisuuksia kehittyä, ottaa vastaan uusia haasteita ja vastuuta, saada lisää ammatillista pätevyyttä ja joskus myös urakehitystä uuden tyyppisiin tehtäviin. Eli sitä todellista PÄÄomaa. Ilman kasvua tämä ei olisi mahdollista. Ja rohkeutta.

Näitä rohkeita miehiä ja naisia on taas haussa trusteq.kasvaa.fi.

Vaikka esitetty vertaus ei pitäisikään sataprosenttisesti paikkaansa, kaikki jotka ovat olleet mukana käynnistämässä ja muotoilemassa keskivertoa suurempia IT-hankkeita voivat varmasti allekirjoittaa havainnon siitä, että organisaation rakenteen ja organisaatiossa työskentelevien ihmisten välisen dynamiikan ymmärtäminen on yksi hankkeen tärkeimpiä menestystekijöitä. Ihmisiä ei vaan voi sokeasti laittaa lokeroihin ja toivoa, että homma toimii. Muita tällaisia menestystekijöitä ovat luonnollisesti budjetin, kalenteriajan ja työn oikean rajauksen realistinen suhde ja johdon sitoutuminen hankkeeseen. Kirjoitetun tiedon määrä siitä, miten näiden ja muiden vastaavien muuttujien paineessa synnytetään hanke, joka onnistuu, on valtava.

En millään muotoa väheksy kirjatietoa ja jokaisella pitää olla perusymmärrys koulutuksen kautta työhönsä, mutta väitän, että meissä kaikissa on sisäänrakennettuna muutamia ominaisuuksia, joita emme saisi koulutuksemme ja kokemuksemme myötä unohtaa. Kun opiskelemme joko työn tai koulutuksen kautta jotain asiaa, vaikkapa projektin suunnittelua, käy usein niin, että näitä viimeisimpänä opittuja asioita aletaan preferoimaan toimintamalleina vain siksi, että ne ovat uusimpina ja tuoreimpina aivoissamme.

Kykyjä, joita olemme monesti saaneet jo lapsena hiekkalaatikolla usein väheksytään, sillä niitä ei voi kirjoittaa kovin eksaktisti CV:hen ja toisaalta monet C-luokan julkkikset ovat tehokkaasti mustamaalanneet näitä ominaisuuksia. Esimerkiksi eduskuntaan pyritään pitkästyttävän usein peruskoulun jälkeen (pahimmassa tapauksessa reality-tv:ssä) hankitulla “tunneälyllä, positiivisuudella ja ihmisläheisyydellä”.

Hienoimmat menestystarinat mitä olen asiakasorganisaatioissa nähnyt, on rakennettu yhdistämällä määrätietoisesti oikeaan tiimiin, oikeissa ihmisissä ja oikeassa suhteessa rooliin nähden, sekä näitä pehmeitä kykyjä, että toisaalta kovan luokan substanssiosaamista. Niinikään poikkeuksetta ison hankkeen osatavoitteiden saavuttamiseen ei riitä vain kommunikaation tai esimerkiksi tekniikan painottaminen.

Kirjapinon korkeus on oire tästä. Ihmismielen ja motivaation monimutkaisuutta yritetään sovittaa johonkin tiedetyillä muuttujilla ennustettavasti käyttäytyvään kehykseen, joka voidaan yksinkertaistaa lukijalle niin, että lukija kokee oppineensa jotain. Toisaalta taas koulutusinvestointi ei kanna oikeasti hedelmää sen jälkeen kun kirja on luettu tai kurssi käyty, vaan hyöty syntyy vasta siinä vaiheessa kun opittua päästään rauhassa soveltamaan oikeassa hankkeessa, ja tällä aikavälillä tieto jäsentyy ja osittain unohtuu ihmisen päässä. Tämä vaikuttaa siihen mitä valintoja jokapäiväisessä työssä preferoidaan.

Kaikki IAM-alueen ohjelmistotuotteet esimerkiksi toimivat aina jonkin kehysajatuksen mukaan. Jos tuotetta käytetään tätä ajatusta vastaan, tästä seuraa perustavaa laatua olevaa tehottomuutta. Tuotteet itsessään pyritään kouluttamaan niin, että niiden käyttäjät seuraisivat työssään tuotteen ajattelumallia. Tätä kuitenkaan harvoin sanotaan koulutuksessa ääneen, ja tämä johtaa siihen, että koulutetut asiantuntijat soveltavat tietämättään tuotteen toimintamallia IAM-hankkessaan ja levittävät sitä ympärilleen ainoana totuutena. Tämä malli on harvoin, jos koskaan, yksi yhteen sen kanssa, miten IAM-hankkeen ympärillä toimiva organisaatio toimii ja tuottaa tietoa. Jonkun täytyy siis muuttua, jotta tehottomuudelta vältytään ja homma saadaan pakettiin.

Organisaation toimintamallia pystytään muuttamaan, kunhan tämä muutos ymmärretään ja sitä osataan johtaa. Ymmärrys yksittäisen organisaation toiminnasta on puolestaan tyypillisesti jotain sellaista mitä opitaan etupäässä hiekkalaatikolla hankituilla pehmeillä kyvyillä ja pitämällä silmät ja korvat auki. On harvoin niin, että se henkilö, joka tuntee IAM-tuotteen ja sen ajattelumallin, on se henkilö joka on kovin kiinnostunut johtamaan organisaatiomuutosta (muuten kuin ehkä teknisestä näkökulmasta). Tämä varsin triviaali havainto selittää hyvin usein sen miksi IAM-hankkeissa monesti aletaan joko kustomoimaan identiteetinhallintatuotetta vastaamaan organisaatiota tavalla joka luo tehottomuutta tai vaihtoehtoisesti ei vaan yksinkertaisesti päästä mihinkään.

IAM-hanke on organisaation toiminnan muutos, etenkin jos identiteetinhallinta ja pääsynvalvonta ei ole ollut aikaisemmin kovin kypsällä tasolla. Tällä blogikirjoituksella haluaisin vaan muistuttaa, että sitä pitää johtaa sellaisena.

Verizonin Business Risk Team on julkaissut raportin vuonnna 2009 käsittelemistään tietomurroista  Tuossa tutkimuksessa käsitellään 90 tietomurron joukkoa. Tuossa joukossa yllättävän pieni osa hyökkäyksistä kohdistui verkkolaitteisiin (kytkimet, reitittimet jne) Esimerkiksi WLANiin kohdistunutta hyökkäistä käytettiin vain yhdessä raportoidussa tapauksessa.

Yli kolmannes hyökkäyksistä kohdistui käyttäjätietoihin, niiden varastamiseen ja väärinkäyttöön. Arvatenkin osa hyökkäyksistä tehtiin varastettujen tunnusten avulla. Hälyttävän suuri osa hyökkäyksistä tehtiin kuitenkin jaettujen tunnusten tai järjestelmien oletustunnusten avulla. Toinen esille noussut hyökkäyskeino oli huonosti toteutetut pääsynhallintalistat (ACL), jotka käytännössä antoivat vapaan pääsyn kaikille käyttäjille. Molemmat hyökkäystyypit olisi kuitenkin erittäin helppo estää hyvin suunnitellulla ja toteutetulla IAM politiikalla. Jos tietomurtoa varten tarvitsi saada haltuun tunnuksia, useimmiten käytetiin hyväksi sovellusten haavoittuvuuksia. Yksinkertaisemmillaan käytettiin SQL injektiota, jossa toivotaan, että kohdesovellus ei tarkista saamaansa syötettä riittävän hyvin.

No, mitä teki kohdeyritys tietomurron jälkeen? Raportin mukaan ei mitään, viikkoon tai kuukausiin. 75% tietomurroista nimittäin havaittiin vasta viikkojen tai kuukausien päästä tietomurron tapahtumisesta. Tietomurtoja ei edes havaittu yrityksessä, vaan 70% tietomurroista havaitiin yrityksen ulkopuolisten henkilöiden toimesta. 13% tapauksista havaittiin muiden työtehtävien ohessa ja ainoastaan 19% tietojärjestemien toiminnan heikkenemisen, auditoinnin tai lokien avulla. Onneksi tietomurtojen havainnointiin on parempiakin keinoja kuin luottaa satunnaisten ohikulkijoiden hyväsydämisyyteen.

Karkeasti ottaen kaikesta mitä tietojärjestelmissä tapahtuu jää (tai ainakin pitäisi jäädä) merkintä lokeihin. Juuri noiden lokimerkintöjen avulla Verizonin raportin 90 tapausta on tutkittu ja selvitetty. Useissa tapauksissa lokeihin jää merkkejä tulevasta tietomurrosta, kun rikollinen vasta valmistelee varsinaista hyökkäystä, tutustuu järjestelmään ja kerää tarvittavia tietoja.

Security Information and Event Management (SIEM) ratkaisu tarjoaa apua tietomurtojen sekä niiden valmistelujen havainnointiin. Ensimmäinen tehtävä on tietysti määritellä mitä on järjestelmän normaali käyttö sekä millainen käyttö on epäilyttävää tai virheellistä. SIEM ei tietenkään pysty yksinään ratkaisemaan koko ongelmaa. SIEM ratkaisun tulisi teitää millaisia käyttäjärooleja järjestelmässä on, kenellä on oikeus mihinkin rooliin ja mitä kyseisellä roolilla on oikeus tehdä. Parhaimmillaan SIEM ratkaisu saadaankin integroitua käyttäjätietojen- ja roolienhallintajärjestelmiin. Esimerkiksi sovelluskehittäjällä ja tietokantaadministraattorilla voi olla hyvinkin erilaiset oikeudet käsitellä tietokannan tietoja ja tämän tulisi heijastua SIEM järjestelmän sääntöihin.

Todellisessa maailmassa kaikki järjestelmät eivät integroidu toisiinsa, yrityksessä ei ole tehty roolipohjaista pääsyn hallintaa yms. Lokien automaattisella analysoinnilla voidaan tällaisissakin tapauksissa saada hyviä tuloksia. Tunnus saattaa ottaa yhteyttä oudosta IP osoitteesta ei tuettuihin portteihin, käy läpi järjestelmän hakemistoja ja asentaa haittaohjelmistoja. Tunnuksella saatetaan tallentaa huomattavia määriä tietoja ja tietoa siirretään käyttäen erikoisia portteja. Kun nämä tiedot saada kerättyä yhteen paikkaan ja tulkittua oikeiden sääntöjen mukaan tietomurron havainnointiin on huomattavasti paremmat mahdollisuudet kuin raportin antamat luvut: 70% hyökkäyksistä havaitaan ulkopuolisten toimesta ja havainnot 75% tapauksissa viikojen tai kuukausien kuluttua. Parhaassa tapauksessa havaitaan jo tietomurron valmistelu ennen kuin arvokasta tietoa päätyy rikollisten käsiin.