A: Suojaus tulee olla suhteutettu kerätyn tietoon & määrään. Kaikkien tulee kuitenkin vähintään:

1. Skannata järjestelmät säännöllisesti heikkouksien huomaamiseksi (vulnerability scanning)

2. Pitää järjestelmäpäivitykset ajantasalla

3. Koventaa järjestelmä. Esim. poista kaikki turhat oletustunnukset ja palvelut.

4. Monitoroida käyttäjien ja järjestelmien tapahtumia

5. Kouluttaa henkilöstöä.

Q: Miten palveluntarjoaja voi havaita hyökkäyksen?

A: Tässä järjestelmän seurannalla on avainrooli.

1. Seuraa järjestelmän käyttölokeja ja liikenneprofiilia

2. Analysoi muutoksia järjestelmäkonfiguuratioissa tai asennuksissa

3. Pyydä palveluntarjoajaa katsomaan, havaitseko hän jotain poikkeuksellista

4. Aja haitakeskannaukset järjestelmällesi (internal virus/malware scanning)

5. Viritä ‘hunajapurkki’ palvelimelle ja monitoroi sitä. Hunajapurkki on houkutteleva kohde hyökkääjälle (esim. passwords.txt           tai creditcard.db), mutta ei sisällä käytettävää tietoa. Hyökkääjä kuitenkin kiinnostuu tästä.

Q: Miten kotikäyttäjät voivat suojata tietonsa?

A: Kotikäyttäjien suojauksessa on kaksi osaa: 1. kotikone ja 2. käytetyt palvelut

Kotikoneelle oleellista on virustorjunnan, henkilökohtaisen palomuurin ja käyttöjärjestelmän päivitysten pitäminen ajantasalla. Palveluiden valinnassa kannataa aina miettiä, mitä tietoja ja mihin tarkoitukseen tulee antaa. Nämä selviävät usein rekisteriselosteesta ja arkaluontoiset tiedot (kuten salasana) tulisi aina siirtää suojatun yhteyden yli.

Q: Mitä kotikäyttäjät voivat tehdä tietovuodoissa?

A: Hyvin vähän. Tämä on palveluntarjoajan vastuulla.

Q: Auttaako vahva salasana tietovuodossa?

A: Tietovuodot aiheutuvat yleensä palveluntarjoajan virheestä. Tällöin asiakkaan salasanasuojaus kierretään, joten hyväkään asiakkaan salasana ei auta tässä.

Q: Tarviiko kuluttajien välittää salasanan vahvuudesta?

A: Kyllä. Vahva salasana ehkäisee tunnuksien väärinkäyttöä. Käyttäjätunnus/salasana vaihtoehdosta tulisi kuitenkin siirtymään kehittyneempiin järjestelmiin esimerkiksi kertakäyttösalasanoihin tai federoituun identiteettiin. Eritysesti federoitu identiteetti on kuluttajille läpinäkyvä vaihtoehto ja vähentää tarvittavien käyttäjätunnuksien ja salasanojen määrää.

Q: Mitä federaatio tarkoittaa?

A: Federaatio tarkoittaa, että sallitaan esim. Googlen tunnuksen käyttö muihin kuin Googlen palveluihin. Tällöin salasana tarvitaan vain Google-tunnuksen käyttöön. Toista salana-/käyttäjätunnusparia ei tarvita.

___

Tomi Mikkonen toimii Trusteqissa hankejohtajana, jonka vastuualueita ovat verkkoturvallisuus, kuluttajatietojen suojaaminen, turvallinen tuote- ja järjestelmäkehitys sekä palvelukehitys.

Anonymous Finland on julistanut sodan Talvivaara Oyj:lle sen tavasta hoitaa kaivoksensa ympäristövaikutuksia.

Itse sodan julistus löytyy http://pastebin.com/j5Syj8aB linkin takaa. Ottamatta enempää kantaa syihin, motiiveihin tai resursseihin kummaltakaan puolelta, maalaa tämä näkymää korporaatioiden ja aktivistien lähitulevaisuuteen.

Hyökkääjät käyttävät sissitaktiikkaa väijymällä aktiivisesti nettinäreen juurella etsien huoletonta korporaatiokulkijaa. Voin melkein kuulla äänen sanovan,
Upseer ies. Mis häne pääsä varjo ossuup tuon piene närree kohal, nii sillo hänel tullooki noutaja.

Kuinka mahtaa olla puolustaja valmistautunut tähän sotaan?
Onko tarjota vain kivääri, kokardi ja vyö?

Jonkusen vuoden olen katsellut sekä kuunnellut eri firmojen ja yhteisöjen tietouhkiin valmistautumista ja Wikipediasta löytyi teksti, jolla voi kuvata tilannetta, näin sodan näkökulmasta:

” Kesäkuussa 1939, puoli vuotta ennen talvisodan syttymistä, Cajander ilmoitti tyytyväisyytensä siitä, että Suomen armeijan hankintoja oli osittain lykätty myöhemmäksi, ja että näin säästettäisiin valtion varoja, koska ei ollut ostettu liian aikaisin varusteita, jotka olisivat kuitenkin sodan sattuessa jo vanhentuneita ja osittain käyttökelvottomia. ” Lähde: Wikipedia (http://fi.wikipedia.org/wiki/Malli_Cajander)

Puolustamista ei ehkä kannata aloittaa ostamalla Hornetteja, kuljetushelikoptereita tai kuolontähteä.
Tarkasta omat joukkosi CAG:ta (Consensus Audit Guidelines) vasten ja panosta todelliseen tarpeeseen.

Vuosi on nyt 2011, johtaako teillä Cajander?

__

Jussi Perälämpi on Trusteqin Security Practice Lead, jolla on yli kymmenen vuoden kokemus mm. tietoturva-arkkitehtuurista, hardenoinnista ja tietoturva-automaatiosta.

Seuraa Jussia Twitterissä: @JussiPeralampi

Mitä seurauksia on asiakastietojen huonolla suojauksella?

Viime viikonlopun 16 000 henkilön tietovuoto on hyvä esimerkki, mitä seurauksia asiakastietojen puutteellisella suojauksella voi olla.

Vaikka yksityiskohtaisia tietoja vuodetun informaation keruusta ei ole vielä saatavilla, yksi asia on varmistunut: vuodetut tiedot on koottu useasta eri lähteestä.

Tämä tarkoittaa, että useat eri tahot eivät ole täyttäneet lain mukaisia tarpeellisia teknisiä ja organisatorisia toimenpiteitä henkilötietojen suojaamiseksi asiattomalta pääsyltä. Täydellistä suojausta asiatonta pääsyä vastaan ei ole taloudellista toteuttaa, mutta tämä vuoto kertoo samaa (ottamatta kantaa tämän hyökkäyksen tekijään), mitä Anonymous Finland julkaisussaan sanoo: suomalaiset viranomaiset, yritykset ja instituutiot eivät suojaa asiakastietojansa kunnolla, koska vuodettu tieto on pystytty keräämään useasta eri lähteestä.

Miten saavuttaa riittävä suoja?

Riittävän suojauksen määrittäminen on aina tietoa keräävän yrityksen tai yhteisön vastuulla. Vaikka mitään minimivaatimuksia riittävälle suojaukselle ei ole asetettu, useat eri suositukset (esimerkiksi CAG – consensus audit guidelines) antavat hyvät lähtökohdat minimivaatimusten toteuttamiseksi. Pelkkien vähimmäistoimenpiteiden, kuten oletusasetusten välttäminen ja säännölliset ohjelmistopäivitykset, toteuttaminen usein estää automaattisten hyökkäysten onnistumisen. Tämä parantaa asiakastietojen suojaa merkittävästi verrattuna tilanteeseen, että mitään ei ole tehty. Vähimmäistoimenpiteiden lisäksi rekisterinpitäjän tulee kehittää suojaustaan jatkuvasti, koska jatkuvat muutokset ympäristössä mahdollistavat uusia heikkouksia järjestelmässä.

Tämä tietovuoto on vain yksi esimerkki, mitä huonosta asiakastietojen suojauksesta voi seurata. Toivottavasti tämä toimii useille tahoille hyvänä muistutuksena, että näiden tietojen suojaukseen tulee panostaa. Jos omaa osaamista tilanteen korjaamiseen ei ole, kannattaa ottaa yhteyttä ulkoisiin asiantuntijoihin tilanteen parantamiseksi.

___

Tomi Mikkonen toimii Trusteqissa hankejohtajana, jonka vastuualueita ovat verkkoturvallisuus, kuluttajatietojen suojaaminen, turvallinen tuote- ja järjestelmäkehitys sekä palvelukehitys.

Rekisteriseloste avainasemassa

Tyypillinen asiakastiedon käytön kehittämisprojekti alkaa kanta-asiakasohjelmien, asiakaspalvelun ja verkkosivujen kautta kerätyn tiedon kartoittamisella. Kerättyjen tietojen yksityiskohdat, käyttötarkoitukset, luovuttaminen ja suojauksen pääperiaatteet tulee dokumentoida rekisteriselosteessa.

Seuraavassa vaiheessa määritetään ja kuvataan nykyiset ja mahdolliset tulevat käyttötapaukset. Rekisteriseloste on avainasemassa asiakasviestinnässä, ja se tulee pitää ajan tasalla. Siitä voidaan kuitenkin rajata pois esimerkiksi oleellisia tiedonkäyttötapauksia, koska asiakastietoja saa käyttää vain rekisteriselosteen mukaisesti.

Kontrolli tiedon luottamuksellisuuden mukaan

Kun asiakastiedot ja niiden käyttö on inventoitu, voidaan aloittaa tietojen suojauksen suunnittelu. Henkilötietolain mukaan asiakastiedot tulee suojata tarvittavilla toimenpiteillä asiattoman pääsyn estämiseksi ja mm. luvatonta luovuttamista vastaan.

Tarvittavien toimenpiteiden määrittely on usein vaikeaa, mutta suojauksen toteuttamiseksi on olemassa useita hyviksi todettuja ratkaisuja. Toimiva identiteetin ja pääsynhallinnan ratkaisu (IAM) on avainasemassa suojauksen suunnittelussa, koska pääsyä asiakastietoon tulee rajoittaa monella eri tasolla (need-to-know -periaate) ja esimerkiksi tiedon käyttöä pitää pystyä seuraamaan ja auditoimaan jälkeenpäin. Pelkkä IAM-järjestelmä ei ole kuitenkaan riittävä väline tarpeellisten toimenpiteiden toteuttamiseksi, vaan erilaisia todennus-, suojaus- ja muita ratkaisuja tulee ottaa käyttöön tiedon määrän mukaan.

         ”Perussääntö on, että mitä enemmän ja mitä luottamuksellisempaa tietoa käsitellään, sitä enemmän kontrolleja tarpeellinen suojaus vaatii.”

Suurissa asiakastietokannoissa kehittyneet ratkaisut, kuten data loss prevention (DLP) ja audit trail, edellyttävät konfiguraation ja haavoittuvuuden seurantaa. Näiden ratkaisujen käyttöönotossa tulee ottaa huomioon organisaation vaatimukset ja muut ympäristöön vaikuttavat tekijät. Tärkeää on kuitenkin määrittää nykyiset kontrollit ja suunnitelma niiden kehittämiseksi.

Viimeisenä vaiheena on vaatimustenmukaisuuden ja kontrollien mittaaminen, joka mahdollistaa myös suojauksen jatkuvan kehittämisen. Erilaiset GRC-tuotteet (governance, risk & compliance) ovat erittäin arvokkaita tässä vaiheessa, koska ne tarjoavat reaaliaikaisen näkymän kontrolleihin ja eliminoivat manuaalisia vaiheita, kuten esimerkiksi itsearviointilomakkeiden ja tarkistuslistojen käsittelyn.

Asiakastiedot ovat yrityksellesi erittäin tärkeää ja arvokasta pääomaa. Pidä siis huolta niiden asianmukaisesta suojaamisesta ja käytön tehokkaasta suunnittelusta.

—–

Tomi Mikkonen toimii Trusteqissa hankejohtajana, jonka vastuualueita ovat erityisesti verkkoturvallisuus, kuluttajatietojen suojaaminen, turvallinen tuote- ja järjestelmäkehitys sekä palvelukehitys.

Pikainen kertaus APT:hen löytyy http://en.wikipedia.org/wiki/Advanced_persistent_threat

Suojaus vuodelta miekka ja kivi

Jos ympäristön tietoturva luottaa siihen vanhaan tilan pitävään palomuuriin, josta on ulos sallittu vähintään DNS- ja http/s-protokollat ja koneilla pyörii perinteiset antivirussoftat, uhan ei tarvitse olla erikoisen edistynyt ollakseen tuon ympäristön APT.

Toisaalla voi olla tehty puolustusta syvyydessä, viimeisimmät antimalware-systeemit, valvonnat, päivitykset ja kovennukset sekä kuuminta hottia oleva APT, joka käyttää kaikkia kikkoja toimiakseen ja pysyäkseen toimivana. Sekin on APT tuolle ympäristölle.

Haitake identiteettivarkaana

Haitakkeilla on oma elinkaarensa:

1. Pääse sisään
2. Tee itsestäsi pysyvä
3. Soita kotiin ohjeita varten
4. Lähetä varastettu data kotiin tai hyödynnä ympäristön resursseja muuten

Haitakkeet käyttävät jotain sen hetken tietoturva-aukkoa päästäkseen sisään ympäristöön. Tulevaisuudessa sisälle päästyään ne sulautuvat “lailliseksi” osaksi ympäristöä.

Haitake voi luoda itselleen tunnuksen AD:hen tai muuhun master-hakemistoon. AD:ta ja paikallisia ryhmiä hyödyntäen, haitake saa lähes pääkäyttäjätasoiset oikeudet ympäristöönsä lisäämällä itsensä eri ryhmiin. Nämä eri ryhmät eivät yksittäisinä ole erityisen arvokkaita mutta yhdessä niillä saa huomattavat oikeudet.

Pääkäyttäjätasoisuus voi merkitä myös, että tunnus tekeytyy joksikin toiseksi ja käyttää ympäristön oikeiden pääkäyttäjien tai avainhenkilön identiteettiä omiin tarkoituksiinsa, eli impersonoituu.

Lokeissa ympäristön oikea henkilö näyttää tekevän normaaleja asioita, kuten lukee viikon päästä julkaistavaa pörssitiedotetta…

Takaovesta takaisin juhliin

Siltä varalta että haitake-tili huomataan, se luo takaoven ympäristöön muuttamalla vaikkapa jonkin websivun koodia, tehden sinne “koodausvirheen”. Koodausvirhe mahdollistaa verkkopalvelimen haltuunoton ilman uutta 0-päivähyökkäystä. Monessakaan ympäristössä ei valvota webpalvelimien sivujen lähdekoodia tuotannossa, varsinkin,  jos muutos tehdään valmisohjelman koodiin. On sanomattakin selvää, että AV-tuotteet eivät katselmoi verkkosivun koodia.

Data lähetetään ulos salasanasuojattuna dokumenttina, kuvana, kryptattuna, ftp:llä tai selaimella.

Nyt joku älähtää, että moinen on kiellettyä tai ainakin valvottua toimistoverkossa.

CxO:t, asiantuntijat sekä pääkäyttäjät tuppaavat kantamaan koneensa kotiin, jossa tuskin valvotaan liikennettä tuolla tasolla, työaseman turvavälineet on tässä kohtaa jo sokeutettu, joten taustalla oleva selain puhaltanee lastia johonkin uuteen, kaukaiseen kotiin viimeistään silloin.

Yllä olevalla esimerkillä on tarkoitus kuvata sitä, että muokkaamalla ympäristöä “normaalisti”, joskin pahantahtoisella tavalla, päästää ohi nykyisistä puolustuksista.

Asetusten, muutosten ja muutostapahtumatietojen monitorointi ja ymmärtäminen tulee nousemaan arvoon tässä vaiheessa.

1.0 on passé

Nyt alkaa olla viimeinen aika siirtää antiikkinen, tilan pitävä, perus palomuuri joko eläkkeelle tai laittaa sen hyväksi kaveriksi web2.0-verkon tietoturvaa ymmärtävä ratkaisu. Pikavoittoja saat toteuttamalla ainakin Quick Winit 20 Critical Security Controls – Version 3.0 dokumentista

http://www.sans.org/critical-security-controls/guidelines.php

Jussi Perälämpi on Trusteqin Security Practice Lead, jolla on yli kymmenen vuoden kokemus mm. tietoturva-arkkitehtuurista, hardenoinnista ja tietoturva-automaatiosta.

Seuraa Jussia Twitterissä: @JussiPeralampi

Datan saattajana toimi ex-työntekijä, ilmankos se Jeppe vihelteli mennessään.

Talouselämän artikkelissa kerrotaan melkoisen lohduttomasta tilanteesta, jossa tietoinfrastruktuurin ylläpitäjät sekä käyttäjät eivät koe hirmuista pistosta rinnassaan viedessään dataa ulos luvatta. Tilanteena voi olla duunarin oma päätös siirtyä toisaalle tai odotettavissa oleva irtisanominen. Molemmissa tapauksissa tekijällä saattaa olla runsaastikin aikaa suunnitella ja toteuttaa uraa tai omaa taloutta edistävä ”varmuuskopioiminen”.

Se Jeppe ohitti DLP:n 

Näissä tilanteissa ensimmäinen askel tuntuu olevan aina tekninen ratkaisu, esimerkiksi  tahallisten ja tahattomien tietovuotojen ehkäisyyn tarkoitettu Data Loss Prevention (DLP) -järjestelmä.

Mutta jos ja kun tekijällä on aikaa ja oikeudet käyttää tietojärjestelmiä normaalisti, hän kerkiää hyvin työtehtäviin liittyen haalimaan oleellista dataa talteen. Tekijä saattaa myös olla teknisesti niin taitava että hän pystyy ohittamaan tekniset suojaukset. Varastettavan tiedon voi salata, sen muotoa voidaan muuttaa, tai se voidaan pyöräyttää ulos sellaisen järjestelmän kautta, jossa ei ole DLP-tukea. Lisäksi hakukoneet auttavat, jos mielikuvitus ja osaaminen loppuvat mutta tahto säilyy. DLP ei siis ole välttämättä riittävä ratkaisu pahan sisäpiiriläisen varalle.

Dokumenttikohtaiset oikeudet

Jos itselläni olisi suojattavaa dataa, pyrkisin ratkaisuun, jossa data olisi salattua ja johon pitäisi erikseen määritellä ketkä voisivat sitä käyttää ja miten. Määrittely voi olla esim. ”kaikki firman työntekijät”, myyjät, Jory sekä Hallitus. Tärkeässä dokumentissa voi olla estetty printtaaminen ja sen saa auki vain määrätty ryhmä käyttäjiä. Ratkaisun pitäisi tukea sähköpostia sekä yleisimpiä toimistosovelluksia. Kun varas vie datan eikä ole enää firman palveluksessa, hänen käyttöoikeudet poistetaan ja samalla käyttäjä menettää oikeudet dokumenttiin. Tuloksena on, että hänellä on dokumentteja, jotka ovat salattuja “Lorem ipsum dolor sit amet, consectetur”, josta ei juuri ole iloa ellei osaa vahvasti salattua tietokoneajan munkkilatinaa. Esimerkkinä edellämainitusta tekniikasta on Microsoftin Active Directory Rights Management Services (AD RMS). Se toimii melkoisen hyvin toimiston peruskäyttäjien kanssa mutta pahoilla pääkäyttäjillä on omat pääsykeinonsa dataan. On varmuuskopioita, tietokantadumppeja, oikeuksien väärinkäyttöä, huijaamista sekä lukematon kasa muita likaisia temppuja.

Tietokoneen pitää valvoa lokeja

Pääkäyttäjiin tehoaa edellämainittujen lisäksi esimerkiksi työtehtävien kierrättäminen, ”separation of duties”, ja lokien seuranta. Työtehtävien kierrättäminen on vanha tietoturvakäytäntö, jossa yhdessä tehtävässä ollaan vain rajoitetun ajan, jotta ei kerkiä alkaa epärehelliseksi. Nykyresursseilla tämä tosin on hieman haastavaa – ainakin IT -osastolla, joista harvoin löytyy useampaa ”kaikkien alojen asiantuntijaa”.

Separation of duties tarkoittaa sitä, että eri tehtäviä jaetaan niin, että itse ei voi valvoa omaa toimintaansa. Pääkäyttäjillä saattaa olla täydet oikeudet esim. intranetiin tai jopa koko ympäristöön mutta lokien seuranta on hänen ulottumattomissaan ja lokiin jää merkintä, jos joku on alkanut ”luovaksi”. Nyt haasteeksi saattaa nousta työntekijöiden vähyys, joka voidaan ratkaista ulkoistamalla valvonta.

Näppärä pääkäyttäjä voi aiheuttaa tulvan tapahtumia lokeihin ja tehdä kolttosensa lokisumun takana, jos lokeja nyt muka joku ihminen sattuisi katsomaan. Ihminen ei kuitenkaan pysty seuraamaan ympäristön tapahtumia ilman hyvää lokien ja tietoturvatapahtumien analysointiohjelmistoa. Siksi tietokoneen pitää valvoa lokeja. Tällaiset ratkaisut tunnetaan yleensä nimikkeellä Security and Information Event Management (SIEM).

Mutta miksi Jeppe vei datan?

Edelläkuvattu on tekniikkaa ja käyttöönotto vaatii suunnittelua, kartoituksia ja hieman sitoutumista. Mutta miksi Jeppe vei datan? Valitettavasti Internetin laajasta tietoturvalaitteiden ja teorioiden kirjosta ei ole löytynyt Layer8 -tuotetta, jolla Jeppe voitaisiin luodata. Ratkaisua odotellessa pitänee tyytyä tietoturvaosaamiseen ja -tekniikkaan.

__

Jussi Perälämpi on Trusteqin Security Practice Lead, jolla on yli kymmenen vuoden kokemus mm. tietoturva-arkkitehtuurista, hardenoinnista ja tietoturva-automaatiosta.

Seuraa Jussia Twitterissä: @JussiPeralampi

Hivenen höperöstä nimestään huolimatta on PRINCE2 “häkellyttävän kurko” ratkaisu juuri IT-projektien hallintaan. Mallina PRINCE2 on yleispätevä projektinhallintamenetelmä joka sopii mihin tahansa projektiin, mutta skaalautuvuutensa ja dynaamisuutensa ansiosta se on erittäin oivallinen ratkaisu tietojärjestelmähankkeen tai -projektin rungoksi. Tämä kirjoitus ei ole lyhyt oppimäärä PRINCE2:sta tai mainosluontoinen esitelmä myynnillisessä mielessä, ainoastaan allekirjoittaneen mielipide PRINCE2:sta projektihallintamenetelmänä. Se nimittäin ”rokkaa”!

Parasta PRINCE2:ssa on, että se ei itsessään millään tavalla rajaa käytettävää projektimetodologiaa tai työkaluja, vaan antaa mahdollisuuden esimerkiksi erilaisten ketterien menetelmien, kuten SCRUM:in käyttöön silloin, kun sellaisesta on hyötyä jonkin tietyn projektin vaiheen toteutuksessa. Jos tuntuu, että kankeus on valttia, on sekin PRINCE2:ssa mahdollista.

Muokattavuus tukee halutun lopputuloksen saavuttamista

PRINCE2 koostuu seitsemästä periaatteesta, seitsemästä teemasta ja seitsemästä prosessista. Periaatteet ohjaavat päätöksentekoa koko projektin elinkaaren ajan, teemat kuvaavat syitä projektin toteutukselle sekä näkökulmaa projektin hallintaan ja prosessit aktiviteetteineen ohjaavat projektin etenemistä suunnitelman mukaisesti. Menetelmänä PRINCE2 on tuotelähtöinen (Product Focused) ja edellyttää, että on olemassa oleva liiketoimintaperusteinen ongelma, joka pitää ratkaista (Business Justification). Liiketoimintaongelman (Business Case) jatkuva arviointi ja tarkastelu koko projektin toteutuksen ajan takaavat, että harhalaukauksia ei tule ammuttua, kun maali pysyy tukevasti paikallaan. Oman kokemukseni mukaan IT-projekteissa maali(t) tuppaavat usein heilumaan sen mukaan, mistä päin tuulee. Liiketoimintaongelman uudelleenarviointi kunkin vaiheen päättämisen ja hyväksymisen yhtenä kriteerinä edesauttaa maalin ankkurointia paikalleen.

Mielestäni PRINCE2:n ehdottomia vahvuuksia ovat Tailored to fit –periaate eli projektimallin muokattavuus lopputuotteen mukaan, vaiheittainen hallinta (Manage by Stages), jonka avulla on helppo määritellä päätöksentekokohdat ja suunnitella projektille järkevä ja täsmällinen vaiheistus, sekä poikkeuksilla hallitseminen (Manage by execption). Poikkeuksilla hallitsemisen ehdoton vahvuus on projektin päättäjien ”vaivaaminen” vain silloin, kun on oikeasti käsillä asioita, joilla on vaikutus projektiin – KAIKKI vihaavat turhia kokouksia. Edellä mainitsemani vahvuudet kuvaavat PRINCE2 -projektimallin tapaa korostaa ohjausryhmätyöskentelyn arvoa ja painottaa, että ohjausryhmän on oltava aktiivinen osa projektia nakitus- ja tylytysautomaattina toimimisen sijaan (Directing a project).

Projektipäällikön työkalut – miten hallita lisätäytteet listan ulkopuolelta?

Projektipäällikön työkalut PRINCE2 -mallissa ovat eri vaiheiden (Controlling a Stage) ja vaiherajojen hallinta ja seuraaminen yhdessä ohjausryhmän kanssa (Managing a Stage Boundary). Jotta projektipäällikkö ei joutuisi roikkumaan stressin partaalla ja alakierteisten baseball-syöttöjen lailla viuhuvien nakkien kurimuksessa, on vaiheiden suunnittelu ja niistä viestiminen ohjausryhmään ensiarvoisen tärkeää. Kun projekti on jaettu selkeisiin vaiheisiin, on projektipäällikön helppo seurata ja hallita projektiin liittyviä kokonaisuuksia ja tuoda ohjausryhmälle julki esiin nousevia poikkeuksia, jotka vaativat päätöksentekoa.

Erityisesti IAM -projektien ja –hankkeiden kohdalla projektin laajuus ja aikataulu saattaa muuttua, kun toivotut toiminnallisuudet laukaisevat tarpeita uusille järjestelmäintegraatioille ja kehitystarpeille, ja tätä kautta tuovat kokonaisuuteen lisää vaatimuksia uusille tarvemäärittelyille. Loogistahan on, että jos pitsaan laittaa lisää täytteitä listan ulkopuolelta, on pitsalaatikon koonkin jossain vaiheessa kasvettava vastaamaan uutta sisältöä, muuten paketti leviää ennen kuin se päätyy asiakkaalle asti. Tähän lisätäytteiden ikuiseen ongelmaan, joka IT-projekteja tuntuu epidemian lailla vaivaavan, on ratkaisuna projektin vaiheittainen toteutusmalli ja poikkeuksien kautta hallitseminen. Näiden kahden PRINCE2-prosessin myötä projektipäällikön on helpompi pysyä kartalla projektin nykytilasta ja nostaa lippu pystyyn tunnistaessaan asian, jolla on aikataulu- tai kustannusvaikutus, tai kun tunnistettu seikka uhkaa muuttaa projektin ennalta sovittua laajuutta.

Uuden vaatimuksen tai tarpeen noustessa tapetille arvioidaan sen vaikutus liiketoimintaongelmaan ja sitä ratkaisevaan lopputuotteeseen. Mitään muutoksia ei jyrätä käynnissä olevan toteutusvaiheen päälle ilman asianmukaista muutoshallintaprosessia. Muutoshallintaprosessi käynnistetään, kun projektipäällikkö tunnistaa poikkeustilanteen ja raportoi tämän ohjausryhmään tai hankkeen/projektin omistajalle.

Hyvä esisuunnittelu ja muutoksenhallinta kampittavat kiirettä

Identiteetinhallinnan projektien kanssa vaatimukset liittyvät usein integroitavien järjestelmien määrittelyihin tai tarkemmin sanottuna niiden puutteeseen, yhteinen nimittäjä edellä mainituille ongelmille on kiire. Kiire on asia, joka on alituisesti läsnä tietotekniikkaprojektissa. Kiire johtuu lähes poikkeuksetta siitä, että ei tutkittu ennen kuin alettiin hutkia. Jos on syöksytty suoraan toteutuksen kimppuun ilman asianmukaista määrittelyvaihetta, ovat ongelmat jatkossa takuuvarma asia. Kiirettä PRINCE2 pyrkii taklaamaan esisuunnitteluvaiheella (Initiating a project), jonka tarkoituksena on kirjoittaa auki ja määrittää liiketoimintaongelma, sitouttaa ohjausryhmä projektiin ja päätöksentekoon sekä määrittää tulevia tehtäviä ja projektin laajuutta.

Omasta kokemuksestani voin sanoa, että jos taustaprosessit eivät ole selvillä, ei lopputuloskaan voi olla kovin ruusuinen. Tosin, jos ”ruma, mutta toimiva” kelpaa ensimmäiseksi tuotokseksi, voi alkuperäisen projektin jatkoksi luoda (on jopa suotavaa) uuden vaiheen tai projektin, jonka tarkoitus on säilyttää ja parantaa jo saavutettua toiminnallisuutta. Näin toimittaessa voidaan oppia aiemmin koetusta, joka on myös yksi PRINCE2:n periaatteista (Learn from Experience). Olennaisena osana PRINCE2 -projektiin liittyy, että projektin käynnistysvaiheessa, ennen projektin todellista aloitusta, kerätään, käydään läpi ja summataan aiemmista vastaavista toteutuksista saatu aineisto ja ohjataan toimintaa ja projektin vaiheistusta sitä kautta mahdollisimman järkevään ja strukturoituun suuntaan.

Olennaista PRINCE2:lle on, että projektisuunnitelma on nimenomaan suunnitelma, kolmeen kivitauluun hakatun ehdottoman toimintatapamääräyksen ja kiinteäksi jäädytetyn aikataulun sijaan. Edellisen lauseen tarkoituksena ei suinkaan ole sanoa, että PRINCE2:lla on helpompaa luistaa aikatauluista kuin aiemmin, vaan tukea käsitystä, että tietojärjestelmäprojektit ovat tuomittuja alituiseen muutokseen. Muutosten ja projektin hallintaan on olemassa toimiva menetelmä, jota käyttämällä voidaan isotkin muutokset hallita ja kanavoida niin, etteivät mittarit pärähdä punaiselle, kulut nouse kattoon ja projektiryhmä päädy kököttämään työpisteidensä ääreen tyhjä katse silmissään ja sormet painamaan Enteriä To-Do listan hipoessa alempia pilvikerroksia. Poikkeuksilla hallitseminen, vaiherajojen tarkkailu ja kunkin vaiheen hallittu kontrollointi vähentävät huomattavasti turhista yllätyksistä aiheutuvaa hötkyilyä.

Helposti lähestyttävän ja nopeasti omaksuttavan PRINCE2:sta tekee se, että se perustuu maalaisjärkeen ja valmiiksi pähkäiltyihin parhaisiin käytäntöihin (Best Practises). Pyörällä on kummasti mukavampi lähteä ajamaan, kun ei tarvitse keksiä sitä ennen ajelua vaan voi ottaa käyttöön jo koeponnistetun ja toimivaksi havaitun menopelin. Mielestäni PRINCE2 on projektin toteutusmallina kuningasvalinta, koska se vähentää ja tehostaa projektin hallintaan kuluvaa ajankäyttöä ja sen tarjoamien metodien avulla on suhteellisen helppoa saada kaikki projektiin olennaisesti liittyvät sidosryhmät ymmärtämään haluttu lopputulos samalla tavalla.

Exchange, SharePoint ja Office Communicator tarvitsevat varmenteita toimiakseen oikein ja muodostaakseen tietoturvallisen toimintaympäristön. Tämä on lisännyt PKI:n tunnettavuutta, ja siitä on muodostunut osa suurempia infrastruktuurihankkeita.

Nyt Microsoft tuo markkinoille seuraavan keskeisen teknologian. Blogissammekin paljon puhuttu federointi on valittu tehokkaimmaksi tavaksi toteuttaa saumaton loppukäyttäjäkokemus kun kirjaudutaan Microsoftin pilvipalveluihin.

Federointi helpottaa pilvipalveluun siirtymistä

Federointi ei varsinaisesti ole vaatimus Office 365 käyttöönottoon, mutta ratkaisee suuren osan juuri niistä pahimmista kipukynnyksistä, joita on pilvipalveluun siirtymisessä. Tästä hyvänä esimerkkinä on kertakirjautuminen, vahvatunnistautuminen tai pragmaattinen esimerkki mahdollisuudesta siirtää loppukäyttäjän postilaatikko pilveen ilman tarvetta Outlook-profiilin uusimiseen.

Se, mikä näkyy loppukäyttäjälle sähköpostilaatikon saumattomana siirtymisenä, tarkoittaa pellin alla saman identiteetin säilymistä. Tämä saattaa kuulostaa joko todella huimalta tai merkityksettömältä. Eron ratkaisee se kuinka vahvasti identiteetin merkitys on sisäistetty.

Samoin kuin PKI:n käyttöönoton suunnittelussa myös federoinnin yhteydessä on hyvä ymmärtää, mitä mahdollisuuksia se tarjoaa, ja mitä ollaan varsinaisesti tekemässä. Kun siirrytään Microsoftin pilvipalveluihin tavoitteena voi olla säilyttää käyttäjähallinta aidosti paikallisessa aktiivihakemistossa tietojen replikoimisen sijaan.

Palvelimiin investointi maksaa itsensä takaisin

Tavoitteen saavuttamiseksi vikasietoiseen federointiympäristöön joutuu investoimaan neljän palvelimen verran (vikasietoinen federointi – ja vikasietoinen federointi proxy -palvelin). Palvelimet antavat lisää levytilaa sekä laskentatehoa ja palvelut helpottavat käyttöä, eikä käyttäjän tarvitse esimerkiksi kirjautua useaan järjestelmään vaan kertakirjautuminen riittää.

Jotta palvelimiin investoimisesta saataisiin kaikki hyöty irti, on hyvä miettiä mitä muita tekniikoita vaadittu AD FS 2.0 mahdollistaa. Esimerkiksi voidaan mainita seuraavat hyödyt:

• kumppanit voivat federoitua yrityksen itse tuottamaan sisältöön
• tiedon suojaamiseen käytettyjen RMS-palveluiden federointi
• mahdollisuus federoitua muihin pilvipalveluihin (matkalaskut, jne), ja
• mahdollisuus toteuttaa hallittuja ympäristöjä oman aktiivihakemiston ulkopuolelle, joihin federoidaan omien työntekijöiden identiteetit.

Federointistrategiasta paljon hyötyä

Blogin tarkoituksena on herättää keskustelua siitä, miten yhden ongelman ratkaisuun vaadittua teknologiaa voidaan hyödyntää laajemmin, mutta vaatimuksena on teknologian ymmärrys. Federointi ei itsessään tarkoita mitään vaan on lähinnä kattotermi useammalle toteutustavalle, kilpaileville standardeille, ja toisestaan hyvin poikkeaville tuotteille.

Vaikka federointi tai pilvipalvelut eivät tuntuisikaan vielä ajankohtaiselta, suosittelen että yrityksen kannattaisi tehdä federointistrategia. Tällä strategialla voidaan varmistaa, että käyttöönotetut ratkaisut tukevat valittuja teknologioita sekä vaadittuja tietoturva- ja toiminnallisuusvaatimuksia.

Strategian avulla voidaan palveluita ostaessa varmistaa, että yhdellä hankitulla ratkaisulla voidaan ratkaista ostettujen palveluiden identiteettivaatimukset. Lisäksi voidaan varmistaa, että yhteistyöyritysten kanssa rakennettaviin palveluihin valitaan ratkaisuja, jotka myös tukevat valittua linjaa.

Miten toteuttaa pääsynhallinta itse palveluun?

Yleisimmin todennus toteutetaan joko käyttäjätunnus/salasana -periaatteella tai vahvaa tunnistusta hyväksi käyttäen (two-factor authentication). Määrittelyvaiheessa tulisikin kartoittaa tarpeet sen mukaan, kuinka luottamuksellista materiaalia taustapalveluun tuodaan käyttäjien käsiteltäväksi sekä millainen hierarkinen malli palvelun kirjastoissa on käytössä.

Ensimmäiseksi olisi syytä miettiä miten edustapalvelun todennus eli Front End Authentication kannattaisi toteuttaa. Sijaitseeko jo ensimmäisen vaiheen tunnistautumisen takana luottamuksellista materiaalia vai onko tarkoitus julkaista vain käyttäjäystävällinen sivusto, jonka sisältö on kaikkien tunnistautuneiden luettavissa? Sivuston sisältäessä kaikille luettavaksi tarkoitettua materiaalia voidaan hyvinkin harkita käyttäjätunnus/salasana -mallista tunnistautumista, mutta aina kannattaa ottaa huomioon, että tämä avaa yhden lisäoven osaavalle hyökkääjälle.Mutta jätetäänpä pelottelu sikseen. Tärkeää on, että lukija ymmärtää ratkaisujen tuomat hyödyt sekä riskit. Toisena varteenotettavana vaihtoehtona voitaisiin toteuttaa edustapalvelun todentaminen vahvaa tunnistusta hyväksi käyttäen, jolloin palveluun päästäkseen käyttäjätunnuksen sekä salasanan lisäksi käyttäjän tulisi syöttää esimerkiksi kertakäyttöinen salasana, jonka palvelu toimittaa käyttäjälle ensimmäisen vaiheen tunnistautumisen jälkeen esimerkiksi matkapuhelimeen tai sähköpostiin. Tällöin hyökkääjällä tulisi olla jollain tavalla pääsy hyökättävän käyttäjän omaisuuteen, jotta hyökkäys voisi onnistua.

Edustapalvelun todennuksen lisäksi tulisi miettiä taustapalvelujen todennus (Back End Authentication). Voidaanko käyttäjille sallia pääsy taustapalveluihin joustavasti (kertakirjautuminen, single sign-on) vai tuleeko käyttäjän tunnistautua myös taustapalvelua varten? Edusta- ja taustapalvelun ratkaisut eivät ole kytköksissä toisiinsa, vaan on mahdollista määritellä palvelukohtaisesti millaista suojaustasoa käytetään käyttäjän siirtyessä kuhunkin palveluun. Tällä tavoin saadaan luottamuksellinen materiaali suojattua pääsynhallintapolitiikoilla, ja ainoastaan palveluun valtuutetuilla (auktorisoiduilla) käyttäjillä on pääsy tiettyihin taustapalveluihin. Joustavilla pääsynhallintapolitiikoilla saadaan aikaan toivottuja ratkaisuja ilman turhaa pelkoa tiedon leviämisestä vääriin käsiin.

Harkinnan arvoinen asia on myös se, miten pääsynhallintapolitiikka erotellaan yrityksen sisäisten ja ulkoisten käyttäjien välillä. Haluammeko, että sisäisillä käyttäjillä on suora pääsy extranet-palveluun vai halutaanko saavuttaa prosessietuja yhdistämällä sekä sisäisten että ulkoisten käyttäjien pääsynhallinta yhden ja saman komponentin avulla?

Tällaisen vaihtoehdon tarjoaa esimerkiksi Microsoftin Forefront Unified Access Gateway, joka nimensä mukaisesti toimii yhtenäisenä yhdyspisteenä ja reunatason pääsynhallintaratkaisuna kaikille käyttäjille riippumatta siitä, ovatko he yrityksen sisäisiä työntekijöitä vai ulkoisia kumppaneita. Aiemmin mainittu edusta- ja taustapalvelujen todennus on häiritsevän helppoa toteuttaa taustapalvelukohtaisesti. Kertakirjautumistapojen toteutusmahdollisuuksia on useita, Windows-ympäristöissä Kerberos tai NTLM, sekä muissa ympäristöissä lomaketunnistautuminen (Forms Based Authentication). Riippuen valittavasta todentajasta (Authentication Provider) on mahdollista määrittää sisäisille ja ulkoisille käyttäjille saman pääsypisteen (access point) kautta toisistaan eroavat todennustavat käyttäjien päätyessä kuitenkin samaan palveluun.

Jos (ja kun) palveluumme yritetään hyökätä?

Yleisimpiä hyökkäyskeinoja extranet-palvelutapauksissa on tietojen kalastelu (Social Engineering), LDAP-injektioyritykset sekä palvelunestohyökkäykset (Denial of Service).  Forefront Unified Access Gatewayssa on kahden jälkimmäisen varalle sisäänrakennetut mekanismit, joilla hyökkäykset saadaan pysäytettyä ilman, että koko palvelu kaatuu. Tietojen kalastelu voi tuottaa aina tulosta, kun tiedon luovuttamisesta vastaa  hyökkäyksen kohteena oleva käyttäjä, mutta vahvaa tunnistusta käyttäessä hyökkäyksen onnistumisen mahdollisuudet pienenevät huomattavasti.

Kuten kirjoituksesta on toivottavasti luettavissa, on olemassa useita tapoja toteuttaa turvallinen ja toimiva extranet-ratkaisu. Avainasemassa on huolellinen suunnitelu ja määrityksien tekeminen, jotta palvelusta saadaan mahdollisimman ketterä,mutta silti turvallinen juuri teidän tarpeitanne varten.

Tietoturvalla (tai tietoturvallisuudella) tarkoitetaan tietojen, palvelujen, järjestelmien ja tietoliikenteen suojaamista.

Joidenkin mielestä automaatio johtaa korkeampaan työllisyyteen. Erään kirjoittajan mukaan automaation vaikutukset toimivat seuraavasti: Kun automaatio alun perin tuli käyttöön, se herätti laajalti pelkoa. Luultiin että ihmisten korvaaminen tietokoneistetuilla järjestelmillä johtaisi työttömyyteen (sama ilmiö tapahtui myös mekanisaation kehittyessä vuosisatoja aiemmin). Todellisuus on kuitenkin päinvastainen, vapautunut työvoima mahdollistaa yhä useamman siirtymisen tehdastyöstä toimistotyöhön, joka on yleensä paremmin palkattua.

- Wikipedia

Tietoturva-automaatio tarvitsee pohjakseen päätöksen siihen panostamisesta. Päätöstä tietoturvan automatisointiin siirtymisestä saattaa helpottaa tieto siitä, että kustannussäästöjä on tiedossa, tietoturvariski pienenee ja IT-resursseja voidaan ohjata uusiin tehtäviin.

Kun myönteinen päätös on tehty, voidaan aloittaa perusasioiden selvittäminen.

• Missä suojattava data sijaitsee?
• Kuinka data virtaa ympäristössä?
• Haluttu/tarvittava tietoturvan taso?
• Mikä on ympäristön tila?

Saattaa olla vaikeaa päättää mikä on haluttu tietoturvan taso, joten pohjaksi voidaan ottaa yhdysvaltalainen SP800-53-standardi, kansainvälinen ISO 27001 -standardi tai kotimainen VAHTI-ohjeisto. Kaikki kolme sisältävät melkoisen määrän erilaisia tietoturvakontrolleja, joiden implementointi vaatii esivalmisteluja, suunnittelua, työaikaa, rahaa ja johdon tukea. Haasteeksi tulee myös päättää missä järjestyksessä kontrollit otetaan käyttöön. Mikä on siis tärkeintä?

Consensus Audit Guidelines (CAG)
Koska harvalla organisaatiolla on sekä rahaa että resursseja loputtomasti, päästään käytännön suunnittelun sekä toteutuksen alkuun ottamalla pohjaksi Consensus Audit Guidelines eli CAG. CAG on lista 20 kriittisestä osa-alueesta, joiden tarkoitus on estää yleisimpien sekä vaarallisimpien hyökkäysten onnistuminen nyt sekä oletettavassa tulevaisuudessa.

Jokaisen listan kohdan taustalla on ryhmä kontrolleja. Kontrollit on jaoteltu neljään ryhmään ”pikaisista voitoista” advanced tasolle. Nämä kontrollit on myös liitetty 800-53-ohjeistuksen kontrolleihin, joten kun top 20 lista on valmis, voidaan helposti jatkaa eteenpäin 800-53:n mukaisesti.

Tässä kohtaa meillä on jo hyvä käsitys siitä mitä ollaan tekemässä, mutta kuinka kontrollit implementoidaan esimerkiksi XP, Vistan tai Win7 kohdalla? Kuinka konfigurointi tai hardenointi tehdään ja mitä rekisteriarvoa oikeasti pitäisi muuttaa?

Security configuration baselines aka hardenointi
Hardenointiin löytyy valmiita pohjia. Voidaan ottaa käyttöön Microsoftin omat EC- tai SSLF-määritykset tai jos halutaan edetä CAG:n eli 800-53:n hengessä, valitaan Federal Desktop Core Configuration (FDCC) XP- ja Vista-koneille tai United States Government Configuration Baseline (USGCB) Win7:lle.

Materiaalia hardenoinnista löytyy myös muidenkin IT-alan toimittajien tuotteille. DISA:lla on pitkä lista, joka tunnetaan nimellä Security Technical Implementation Guides eli STIG. Erikseen mainitsen Redhat Enterprise Linux:lle tehdyn ohjeistuksen ja siihen liittyvän SCAP-materiaalin.

FDCC ja USGCB tarjoavat valmiit GPO:t, jotka voidaan importoida AD:hen ja siellä liittää GPO:hon. Luonnollisesti GPO:hon liitetään testi OU:hun alku vaiheessa. Kun GPO:t on testattu ja mahdollisesti tarvittavat muutokset on toteutettu, voidaan asennusimageenkin liittää kyseiset GPO:t paikalliseksi politiikaksi.

Tässä kohtaa alkaa yleensä kuohupullojen aukaisu ja selkään taputtelut, ja onhan siihen toki aihetta.

Mutta… Suojaukset tulevat happanemaan ajan kanssa, niitä pitää valvoa ja uusia tietoturvauhkia ilmestyy ja ne vaativat muutoksia ympäristöön. Entä kuinka mitataan, että tavoiteltu tietoturvan taso on olemassa ja paljonko sen ylläpito maksaa? Ja millaisia tapahtumia on havaittu ja paljonko ne olisivat tulleet maksamaan, jos olisi jatkettu ”niin kuin aina ennenkin”?

Security Content Automation Protocol (SCAP)
Havainnointi, vaatimusten mukaisuuden valvominen sekä raportointi ovat tietoturva-automaation perusasioita.
Edellä mainittujen asioiden toteuttamiseen on olemassa Security Content Automation Protocol eli SCAP.
SCAP:iä tukevilla työkaluilla voidaan toteuttaa vaadittua valvomista ja saadaan raportit, joilla voidaan seurata sekä mitata ympäristön ja sen ylläpitäjien toimintaa.

Tietoturvan parantaminen on siis entistä helpompaa. Löytyy valmiit ohjeistukset ja niistäkin tiivistetty lista, jolla päästään alkuun. On tavat automatisoida, valvoa, mitata sekä raportoida tietoturvaa, jolloin siitä saadaan konkreettisemmin mitattavaa.

__

Jussi Perälämpi on Trusteqin Security Practice Lead, jolla on yli kymmenen vuoden kokemus mm. tietoturva-arkkitehtuurista, hardenoinnista ja tietoturva-automaatiosta.

Seuraa Jussia Twitterissä: @JussiPeralampi