Ads 468x60px

tiistai 27. syyskuuta 2011

Ympäristön heterogeenisuus tietoturvallista?

Lukaisin jonkin aikaa sitten julkaistun tietoturvatutkimuksen, jonka kirjoittajina olivat Chen, Kataria ja Krishnan (Krishnan muun muassa toimii tietoturvapuolella kuuluisan Carnegie Mellon yliopiston tutkijana). Tutkimus oli julkaistu eräässä alan parhaimmaksi, tai jopa parhaaksi, rankatussa tieteellisessä julkaisussa nimeltä Management Information Systems Quarterly (MISQ). Tarkemmat ja yksityiskohtaisemmat tiedot löytyvät luonnollisesti itse artikkelista, mutta mielenkiintoisinta oli heidän johtopäätös: ohjelmistojen heterogeenisuuteen pyrkivä strategia on eduksi tietyissä tapauksissa ja lisää tietoturvallisuutta. Tutkijoiden väitteen mukaan kun heterogeenisuutta (tutkijat itse käyttävät englanninkielen termiä ”software diversification”) lisätään niin saatavuutta saadaan kasvatettua monimuotoistamalla käytössä olevat ohjelmistot ja näin on todennäköisempää ettei ongelma/haavoituvuus yhdessä ohjelmistossa kosketa koko ympäristöä.

Vastaavasta on käyty keskustelua jo pitkään ammatinharjoittajien keskuudessa. Hyvä esimerkki tästä on ollut keskustelu useampia vuosia sitten siitä tulisiko palomuurit hankkia kahdelta eri valmistajilta vai vain yhdeltä valmistajalta. Selkeyttä (tai ainakin lisäpontta keskustelulle) toi analytiikkayritys Gartnerin raportti, jossa suositeltiin vain yhtä laitevalmistajaa. Muistan kuitenkin tämän keskustelun muokanneen käytännön toteutuksia ja joskus maailmalla työskennellessäni, tällä kertaa kehittyvässä maassa, useammankin eri yrityksen asiantuntijat jakoivat näkemystään, jonka mukaan kahta tietoturvaratkaisua (ei siis vaan palomuuria vaan tietoturvaratkaisua yleensä) ei tulisi milloinkaan hankkia samalta laitevalmistajalta.

Tämä kaikki on myös tällä hetkellä hyvinkin ajankohtaista. Moni käyttäjä haluaa hyödyntää Applen tuotteita yrityskäytössä. Homogeenisuuden suosimisen kautta, kuten tutkijat totesivat, moni yritysverkko on puhtaasti Windows -verkko. Tästä johtuen voidaan esimerkiksi Applen tuotteiden käyttöönotto nähdä juuri artikkelin mukaisena monimuotoistamisena. Johtuen käyttöjärjestelmien hyvinkin suuresta erilaisuudesta, voidaan varmasti olettaa ettei kovin helposti löydetä haavoittuvuuksia, jotka koskisivat molempia käyttöjärjestelmiä (poikkeuksena luonnollisesti sovellushaavoittuvuudet tai esimerkiksi Java-haavoittuvuudet, joita on yleensä voitu hyödyntää yli käyttöjärjestelmärajojen). Voisiko siis tietoturvan lisääntyminen toimia business casena heterogeenisempien ympäristöjen suosimiseksi?
Lopuksi lienee hyvä huomioida, että tutkijat, tarkoituksen mukaisesti, ovat tutkineet asiaa vain valitsemastaan perspektiivistä. Tietoturvallisuus on kuitenkin monimutkaista ja näin ollen heterogeenisuuden vaikutuksia kokonaistietoturvaan on vaikea tai mahdoton arvioida vain näiden tulosten valossa.

Linkki artikkeliin: http://misq.org/correlated-failures-diversification-and-information-security-risk-management.html

maanantai 26. syyskuuta 2011

Seitsemän asiaa, jotka CIO:den tulee huomioida tämän päivän tietoturvatyössä

Niall Brownen (CISO, LiveOps Inc.) on kerännyt kokemuksiaan ja ajatuksiaan listaksi, jotka tämän päivän CIO:n ja (CISO:n) tulisi huomioida kehittäessään yrityksensä tietoturvaa. Lähtökohtana listalle on ollut se, että toimintaympäristömme digitalisoituu kiihtyvällä vauhdille omista haluistamme ja näkemyksistämme välittämättä. Samoin, rikollisuus ja ”cyberhyökkäykset” eivät ole enää pienten rajoittuneiden kohteiden ongelma ja (tietoturva)yritykset ovatkin joutuneet arvioimaan uudelleen vastaavatko heidän olemassa olevat tietoturvarakenteet tämän päivän uhkiin. Niallin näkemyksen mukaan olemassa olevat standardit ovat (edelleen) perusta tietoturvan rakentamiselle, mutta pelkkä vaatimustenmukaisuus ei ole enää tae turvallisuudesta.

Ohessa on tiivistetysti Niall Brownen teesit tämän päivän CIO:lle:
  1. Keskity tietoturvauhkiin vaatimustenmukaisuuden sijasta. Karrikoiden voidaan sanoa, että varashälyttimen asentamisesta etuoveen ei ole mitään iloa, jos takaovemme on jatkuvasti auki. Monesti vaatimustenmukaisuuden ongelma on se, että rakennamme kontrollit niin, että ne täyttävät standardin Z vaatimukset ja näin ollen ne tyydyttävät auditoijaa. Ongelma lähestymisessä on kuitenkin se, että kontrollimme eivät välttämättä suojaa meitä tämän päivän todellisilta uhkilta, näin ollen olemme haavoittuvaisia vaikka olisimmekin vaatimustenmukaisia.

  2. Tiedon suojaamisessa tulee keskittyä tiedon suojaamiseen paikan suojaamisen sijasta. Nykyään tieto on hajaantunut enenevässä määrin ympäri toimintaympäristöämme ja tietoa käsitellään yhä kasvavassa määrin toimiston ulkopuolella mitä erilaisimmilla päätelaitteilla. Tämä on johtanut siihen, että tietoturva ei voi enää nojata toimiston fyysiseen turvallisuuteen vaan meidän on suunniteltava kontrollimme uusiksi. Toisin sanoen tiedon suojauksen on kuljettava tiedon mukana huolimatta tiedon fyysisestä sijainnista.

  3. Ymmärrä sosiaalisen median luonne. Monessa yrityksessä sosiaalinen media nähdään (edelleen) suurena peikkona ja sen käyttö halutaan kieltää tietoturvasyihin vedoten. Pelätään, että työntekijät vuotavat yrityksen tietoa somessa. Äärimmilleen vietynä yritykset ovat estäneet kaikki yhteydet sosiaalisen median palvelimiin työpaikalta, mutta toisaalta yrityksen työntekijät voivat surffata somessa yrityksen kannettavalla kotonaan. Näin ollen suoraviivainen kieltäminen ei ratkaise ongelmaa. Tänä päivänä onkin järkevämpää sallia kontrolloitu pääsy sosiaaliseen mediaan täydellisen kiellon sijasta. Käyttäjiä tulee valistaa olemassa olevista riskeistä ja kertoa heille, kuinka he voivat suojautua näitä riskejä vastaan. Näin käyttäjät saavat paremmat edellytykset tiedon suojaamiseen sijaitsivatpa tiedot sitten yrityksen tiloissa tai niiden ulkopuolella.

  4. Perinteiset tietoturvaryhmät on organisoitava uudelleen. Yritysten ohjelmistokehitys on pitkälti siirtynyt käyttämään ketteriä sovelluskehitysmalleja. Käytännössä tämä tarkoittaa sitä, että perinteisten puolivuosittaisten tai kerran vuodessa olevien julkaisujen sijasta ohjelmistot saavat uusia ominaisuuksia (tyypillisesti) kahden viikon välein. Lisäksi ohjelmoijat harvoin sijaitsevat enää yhdessä paikassa, vaan kehitystyötä saatetaan tehdä jopa ympäri maapalloa. Ketterien sovelluskehitysmenetelmien hyvä puoli on se, että niiden avulla on mahdollista saada uusia toiminnallisuuksia sovelluksiin huomattavasti aikaisempaa nopeammin. Tietoturvan kannalta haaste taas on se, että perinteisen puolen vuoden sijasta tietoturvaryhmällä on aikaa riskien arviointiin vain kaksi viikkoa. Jos 10 ohjelmoijaa toteuttaa 10 toiminnallisuutta per ohjelmoija, niin ohjelmistoon tulee 100 muutosta joka toinen viikko! Näin ollen tietoturvaryhmän on pystyttävä toimimaan samassa tahdissa sovelluskehittäjien kanssa, koska muuten tietoturva jää jälkeen.
    Kun tietoturva jää jälkeen, niin liiketoiminnan riski kasvaa. Jotta liiketoiminnan riski pysyisi hallittavana, niin joko tietoturvaryhmien täytyy pystyä lyhentämään reaktioaikaansa tai vaihtoehtoisesti ohjelmiston julkaisuväliä tulee pidentää. Liiketoiminta harvoin haluaa hidastaa toimintaansa kankean riskienhallinnan takia. Näin ollen tietoturvaryhmien tulee siirtyä ”ketteriin tietoturvamenetelmiin” tai muuten he pian huomaavat etteivät he pysty vastaamaan liiketoiminnan vaatimuksiin.

  5. Järjestä työntekijöille interaktiivista tietoturvakoulutusta. Tietoturvakoulutus, jossa tietoturvaosasto järjestää pakollista koulutusta henkilöstölle kerran vuodessa eilisen tietoturvahuolista on tänä päivänä tehotonta. Sitä vastoin tietoturvaosastojen tulisi jalkautua henkilöstön joukkoon ja pyrkiä valistamaan käyttäjiä jatkuvasti ajankohtaisista uhista. Mahdollisia tapoja tavoittaa käyttäjät ovat esimerkiksi tietoturvalounaat, -julisteet, -visailut, uutiskirjeet ja muut vastaavat tavat, joilla pystytään kasvattamaan henkilöstön tietoisuutta ajankohtaisista aiheista.

  6. Keskity ohjelmistoturvallisuuteen. Valitettavan usein kuvitellaan, että sovelluksien suojaamiseen riittää palomuuri verkon laidalla. Nykyään tämä olettamus ei kuitenkaan enää pidä paikkaansa. Sovellukset kommunikoivat kasvavassa määrin internetin läpi ja ne tarjoava yhä enemmän ja enemmän erilaisia liitäntäpintoja muille sovelluksille (API). Tämä taasen johtaa siihen, että sovellusten haavoittuvuuspinta on kasvanut samalla kuin palomuurin tarjoama suojaus on laskenut. Näin ollen sovellusten on oltava turvallisia itsessään. Tämä taasen vaatii, että tietoturva huomioidaan systemaattisesti koko ohjelmistokehitysprosessin aikana.

  7. Seuraa tietoturvan tilaa jatkuvasti. Monet tietoturvastandardit vaativat, että yrityksessä seurataan tietoturvan tilaa ennalta määritetyn syklin mukaan. Käytännössä tämä voi tarkoittaa, että yrityksessä audioidaan käyttöoikeudet neljänneksittäin tai palomuurisäännöt tarkastetaan puolivuosittain. Valitettavasti hakkerit eivät kuitenkaan toimi ennalta määrätyn aikataulun mukaan. Jos yritys ei seuraa jatkuvasti tietoturvansa tilaa, niin on mahdollista, että väärinkäytös havaitaan vastan viikkojen tai kuukausien kuluttua itse tapahtumasta. Tästä syystä tietoturvan valvonnan tulee olla jokapäiväistä. Tietoturvatyökalujen tulee tarjota käyttäjilleen ajantasaista ja selkeää informaatiota, jotta tietoturvapoikkeamat olisi mahdollisimman helppo havaita ja jotta korjaaviin toimenpiteisiin voitaisiin ryhtyä mahdollisimman nopeasti. Vain näin voidaan suojata tehokkaasti liiketoimintaa olemassa olevilta riskeiltä.
Oman kokemuspohjani perusteella pidän Niallin teesejä varsin mainiona lähtökohtana tietoturvallisuuden rakentamiselle yksinkertaisuudessaan. Esimerkiksi tietoturvaa ja vaatimustenmukaisuutta ei pitäisi tehdä vain auditointeja varten. Hienoista dokumenteista ei ole mitään apua, ellei henkilöstö tunne niiden sisältöä ja toimi ohjeiden mukaan. (Toisaalta, vaatimustenmukaisuus saattaa toisinaan olla edellytys liiketoiminnalle, esimerkiksi tietoturvatasojen tai PCI DSS -standardin täyttäminen, eli emme voi unohtaa muodollisuuttakaan kokonaan.) Samoin, yleensähän tietoturvan heikoin lenkki on itse käyttäjät, joten emme saa koskaan aliarvioida koulutuksen ja valituksen merkitystä kokonaistietoturvan rakentamisessa jne. Summa summarum, Niallin lista kannattaa lukea ajatuksella läpi ja pohtia, ovatko mainitut asia kunnossa itse kunkin organisaatiossa!

Ystävällisin terveisin
Antti

perjantai 23. syyskuuta 2011

Miksi ”kaikki” julkishallinnon IT-projektit epäonnistuvat?

Turun Sanomissa julkaistiin 23.9.2011 artikkeli, jossa todetaan: Valtiontalouden tarkastusviraston mukaan it-alan järjestelmäntoimittajat ovat aiheuttaneet veronmaksajille satojen miljoonien eurojen menetykset. – Julkisella puolella kaikki isot tietojärjestelmähankkeet ovat päätyneet viime aikoina kaaokseen käyttöönottovaiheessa. Tarkastusviraston mukaan syy ei ole ostajissa ja artikkelissa arvotellaan kovin sanoin tiettyjä suuria järjestelmätoimittajia ja heidän kyvyttömyyttään oppia aikaisemmista virheistä.

Olen omassa työssäni saanut seurata monia merkittäviä it-projekteja ja oman kokemukseni mukaan syy ei todellakaan ole pelkästään toimittajassa. Tarkastusviraston omassa raportissakin todetaan että ”Julkinen sektori on ollut tässä suhteessa aivan liian löperö. Maksetaan siitä, että toimittajat korjaavat omia virheitään” Oman kokemukseni mukaan viimeaikaiset it-projektien ongelmat johtuvat:
  • Julkisten hankintojen kilpailutuksesta – ei voida riittävästi keskustella toimittajien kyvystä toteuttaa haluttu kokonaisuus, valinnassa korostuu monesti pelkkä hinta, toimittajien saadessa tasavertaiset laatupisteet. – Hankintalaki asettaa haasteita hankinnalle.
  • Hintakilpailun aiheuttamista paineista toteuttaa voitettu projekti mahdollisimman edullisesti – usein osa työstä ulkoistetaan halvan työvoiman maihin.
    Riittämättömistä ja huonosta projektin hallinnasta ja projektin aikaisten muutosten hallinnan puutteista.
  • Riittämättömästä valvonnasta, riskienhallinnasta ja riippumattoman testauksen / laadunvarmistuksen puutteesta.
  • Kiireestä ja epärealistisista aikataulu tavoitteista.
Yleensä epäonnistuminen johtuu näiden kaikkien tekijöiden yhteisvaikutuksesta eikä kaikki näistä syistä ole pelkästään toimittajien kontrollissa. Toki toimittajilla olisi parantamisen varaa muun muassa sovelluskehityksen tietoturva-osaamisessa. Tämä on selkeä puute ja ongelma, johon itse törmäämme omassa auditointityössämme.

Projektinjohdollinen ja aikatauluihin liittyvä ongelma on se, että silloin kuin tilaaja on ymmärtänyt tilata järjestelmälle tietoturva-auditoinnin ennen käyttöönottoa – ja tässä julkishallinto on parantanut toimintaansa viimevuosina – ei järjestelmä yleensä ole valmis silloin, kun se pitäisi testata ja tuotantoon se pitäisi saada eilen.

Valtiontalouden tarkastusviraston raportissa on kyllä suuri totuuden siemen, mutta vastuu epäonnistumisista on sekä ostajalla että toimittajalla ja osittain myös lainsäädännöllä.

Turun Sanomien artikkeli http://www.ts.fi/online/kotimaa/259794.html

maanantai 19. syyskuuta 2011

Tietoturvakoulutus – hieno juttu, mutta mistä aloittaa?

Monessa yhteydessä on korostettu, että organisaation tulisi kouluttaa henkilöstöään säännöllisesti (myös) tietoturvatietouden osalta. Itse asiassa tämä vaatimus tietoturvakoulutuksesta ei ole mikään uusi juttu, vaan kansanväliset tietoturvakriteeristöt (kuten ISO27001 ja PCI DSS) ovat edellyttäneet säännöllisestä kouluttamista (muodossa tai toisessa) jo pitkään. Kansallisella tasolla tietoturvakoulutuksen merkitystä on pyritty nostamaan mm. niin, että tietoturvatasoihin on tuotu oma vaatimus (1.3.1 Osaamisen ja tietoisuuden kehittäminen sekä sanktiot) tietoturvakoulutukselle.

Karkeasti voidaan sanoa, että kritteeristöjen vaatimukset täyttyvät sillä, että organisaatio järjestäisi itse, tai ostaisi ulkopuoliselta, jonkun satunnaisen tietoturvakoulutuksen kerran vuodessa. En kuitenkaan pidä tätä hyvänä lähestymisenä, koska tällöin hyvin harvoin tarjottu koulutus ja organisaation henkilöstön todellinen koulutustarve kohtaavat.

Näinpä, jos organisaatiossa ei ole (vielä) käynnissä suunnitelmallista tietoturvakoulutusta eikä organisaatiossa oikein edes vielä tiedetä mistä lähteä liikkeelle, niin asiaa voisi alkaa purkamaan alla olevien kysymysten kautta. Vastausten perusteella organisaation pitäisi saada karkea käsityksen siitä, mitä mieltä organisaation henkilöstö on koulutustarpeistaan. Tämä taas on äärimmäisen arvokasta tietoa siinä vaiheessa kun organisaatio miettii mistä lähteä liikkeelle.

Yleisesti ottaen tietoturvakoulutuksen osalta suosin itse mallia, jossa koko organisaation henkilöstölle järjestetään vuosittain ”peruskoulutus”. Tässä koulutuksessa kerrataan kaikille yhteisiä perusteita sekä nostetaan esiin ajankohtaisia aiheita. Tämän lisäksi, esimerkiksi noin puolen vuoden kuluttua peruskoulutuksesta, tulisi eri henkilöstöryhmille järjestää kohdistettua henkilöiden työtehtäviin liittyvää tietoturvakoulutusta. (Kohderyhminä voivat olla esimerkiksi sovelluskehittäjät, järjestelmien ylläpitäjät, asiakaspalvelijat, toimistotyöntekijät jne.) Näin koulutus voidaan räätälöidä henkilöiden tarpeiden mukaan, jolloin myös motivaatio oppimiseen on huomattavasti suurempi. Vielä kun koulutukselle laaditaan pitkän aikavälin suunnitelma; 2011 keskitymme tähän, 2012 tuohon, 2013 on vuorossa se jne, niin organisaatiolla on oivat perusteet onnistuneeseen henkilöstön tietoturvatietotaidon kehittämiseen ja ylläpitoon!


Terveisin

Antti


Kysymyksiä organisaation henkilöstön tietoturvakoulutustarpeen selvittämiseksi

  • Oletko lukenut organisaatiomme tietoturvapolitiikkaa?
    [kyllä | ei]
  • Saatko riittävästi tietoturvakoulutusta?
    [kyllä | ei]
  • Kuinka usein tietoturvakoulutusta tulisi järjestää?
    [kerran vuodessa | kaksi kertaa vuodessa | useammin kuin keksi kertaa vuodessa | harvemmin kuin kerran vuodessa]
  • Miten tietoturvakoulutus tulisi järjestää?
    [Luokkamaisena opetuksena | verkkopohjaisena koulutuksena | pienryhmissä | Muuten: miten?]
  • Mitä aiheita koulutuksessa tulisi käsitellä? (Valitse mielestäsi kolme tärkeintä)
    • Sähköpostin turvallinen käyttö Salasanojen turvallisuus
    • Internetin turvallinen käyttö
    • Työasemien turvallinen käyttö
    • Yksityisyyden suojaaminen verkossa
    • Tiedon käsittely ja sen luokittelu
    • Tietojenkalastelulta suojautuminen (social engineering)
    • Tiedon salaaminen
    • Sosiaalisen median turvallinen käyttö
    • Henkilötietojen oikeaoppinen käsittely
    • Jotain muuta: mitä?
  • Käytätkö työkäytössä olevaa käyttäjätunnusta ja salasanaa henkilökohtaisissa palveluissa?
    [kyllä | ei]
  • Tiedätkö mitkä ovat organisaatiomme suositukset vahvalle salasanalle?
    [kyllä | en | en tiedä organisaatiomme suosituksia, mutta tiedän vahvan salasana vaatimukset]
  • Tiedätkö kuinka sinun tulee käsitellä työtehtäviisi liittyvää aiheistoa työpaikan ulkopuolella Etätyö, työskentely julkisella paikalla)?
    [kyllä | ei | luulisin, mutta tarvitsen lisätietoa]
  • Käytänkö ulkopuolisia henkilökohtaiseen käyttöön tarkoitettuja palveluita työtehtävien hoitamisessa? (Esimerkiksi Google docs, Gmail, Dropbox, jne)
    [kyllä | ei]

Tietoturva Ry:n yritysvierailu KPMG:lle 20.9.2011

Tietoturva ry järjestää yritysvierailun tiistaina 20.9.2011 KPMG:lle. Tapahtuma järjesteteään KPMG:n Kukontorin koulutustiloissa. Tilaisuuden agendalla on kolme esitystä ajankohtaisista aiheista sekä pientä purtavaa esitysten jälkeen.

Vierailun agenda:

17:00 - 17:10: Tilaisuuden avaus, Mika Laaksonen

17:10 - 17:30: Uusi tietohallintolaki ja sen vaikutukset, Seppo Salminen

17:30 - 17:50: Tuleva tietosuojadirektiivi, Mikko Viemerö

17:50 - 18:10: Tekninen esitys: Palomuurin ohittaminen XSS-haavoittuvuutta hyväksikäyttäen, Matti Järvinen & Tuomo Makkonen

18:10 - 20:00: Vapaata seurustelua ja pientä purtavaa


Tilaisuuteen sopii noin 30 osallistujaa.

maanantai 12. syyskuuta 2011

Miksi emme välitä tietoturvasta?

Pidän itseäni tietoturva-ammattilaisena. Väitän tietäväni, miten asiat tulee hoitaa, jotta lopputulos olisi turvallinen. Tästäkin huolimatta yllätin itseni männä viikolla ”housut nilkoista”:

Lyhykäisyydessään tarkoitukseni oli siirtää html-sivuja kotisivuilleni. Valitettavasti operaattorini kuitenkin tuki vain salaamatonta FTP:tä ja näinpä vaihtoehtoni olivat 1) ottaa riski ja käyttää suojaamatonta yhteyttä tai 2) jättää kuvat julkaisematta. (En myöskään halunnut käyttää netistä löytyviä kuvagalleriapalveluja, koska halusin juuri tietynlaisen ulkoasun sivustolleni.)

Lyhyen pähkäilyn jälkeen päädyin siirtämään tiedostot FTP:llä. Suojaamattomasta yhteydestä aiheutuvaa riskiä pyrin pienentämään sillä, että en ole käyttänyt samaa salasanaa missään muussa palvelussa ja vaihdoin välittömästi salasanani uuteen puhtaaseen salasanaan siirron jälkeen. Tässä yhteydessä siis uskon, että toimin riittävän huolellisesti eikä minulle aiheutunut toiminnasta kohtuutonta riskiä.

Mielenkiintoinen sivujuonne tapauksessa on se, että käyttöehdoissaan operaattori edellyttää seuraavaa: ”Asiakkaan tulee huolehtia, että älykortit (esim. sim- tai ohjelmakortti) ja laitteet on suojattu tunnisteilla (esim. käyttäjätunnus, salasana, pin-koodi, suojakoodi), ja että nämä henkilökohtaiset tunnisteet pysyvät vain hänen omana tietonaan.” Tästä seuraa se ongelma, että mikäli joku olisi kaapannut tunnukseni ja olisi tehnyt sillä muutoksia liittymääni, niin kenen olisi vastuu asiasta? Itse tietysti olen sitä mieleltä, että koska olen käyttänyt vahvaa salasanaa ja en ole luovuttanut tunnustani kenenkään haltuun, niin vastuu ei voi olla minun… (Toisaalta minun kuuluisi tietää, että FTP on turvaton.)

Ja miten tämä tarina liittyy mihinkään?

  1. Ihmiset ovat valmiita ottamaan riskejä (= vaarantamaan tietoturvan) hämmentävän helposti. Aivan sama onko kyseessä ammattilainen vai ei.
  2. Jos on mahdollista käyttää turvatonta tapaa, niin ihmiset käyttävät sitä. Aivan sama mitä käyttöehdoissa lukee -> lukeeko kukaan niitä ylipäätään?
  3. Samaa salasanaa ei pidä käyttää monessa ei palvelussa.

Oman näkemykseni mukaan avain onneen tässä tapauksessa onkin asennekasvatus. Jos käyttäjät eivät ymmärrä, miksi joku asia on kiellettyä, niin he tulevat toimimaan jatkossakin ”väärin”. Tilanne on suurin piirtein sama kuin aikuiset yrittäisivät kieltää murrosikäisiä tekemästä jotain.

Summa summarum: tietoturvan rakentaminen ei siis aina vaadi kalliita investointeja. Itse suositan, että organisaatiot pysähtyisivät miettimään tietoturvaansa vaihteeksi asennekasvatuksen kautta: Mitä meidän tulee opettaa käyttäjille, jotta osaisivat toimia tulevaisuudessa viisaammin?

Terveisin
Antti

perjantai 9. syyskuuta 2011

torstai 8. syyskuuta 2011

Muista huomioida dokumenttien metatiedot

Kauppalehti julkaisi tiistaiaamuna 6.9.2011 verkkosivuillaan valtiovarainministeri Jutta Urpilaisesta kertovan uutisen, johon liittyvät kuvan kuvatekstit herättivät runsaasti keskustelua. Kuvateksteissä luki: ”jutta urpilainen sdp demari demarit sosialismi parta-kalle marx epäonnistuminen häviäjä”

Sanat ovat kuvaajan kuvatietoihin kirjoittamia metatietoja, joiden ei normaalisti olisi kuulunut näkyä lukijoille. Kyseessä on hyvä esimerkki eri dokumenttien ja tiedostomuotojen metatietoihin liittyvästä riskistä. Metatietojen on muun muassa tarkoitus helpottaa oikeiden tiedostojen, esimerkiksi tilaisuuteen sopivan kuvan löytämistä. Siksi metatietojen tulee mahdollisimman hyvin kuvata dokumentin sisältöä ja käyttötarvetta. Turhia tai typeriä metatietoja ei kannata lisätä, sillä ne voivat vahingossa paljastua. Osa metatiedoista tulee monesti automaattisesti, esim. kuvauksessa käytettävän kameran tiedostoon lisäämänä.

Toimistotyössä tyypillisemmin käytettävissä Word, Excel ja Power Point tiedostoissa on myös metatietoja. Piilotetuissa tiedoissa voi olla organisaatiota tai itse asiakirjaa koskevia tietoja, joita ei ole tarkoitettu kaikkien nähtäviksi, joten piilotetut tiedot on usein hyvä poistaa ennen asiakirjan jakamista.

Piilotettujen tietojen tarkastaminen onnistuu esimerkiksi Word-ohjelmassa Prepare -> Inspect Document valinnan kautta. Monien muiden tiedostomuotojen osalta piilotettuja dokumentin metatietoja voi tarkastella dokumentin ominaisuudet välilehden kautta.

Microsoftin yksityiskohtaisempi ohje: http://office.microsoft.com/fi-fi/word-help/asiakirjojen-tarkastaminen-piilotettujen-tietojen-ja-henkilokohtaisten-tietojen-poistamiseksi-HA010354329.aspx