Ads 468x60px

maanantai 28. tammikuuta 2013

BYOD – pitäisikö niissäkin muuten olla privacy filterit käytössä?

Viime aikoina olen törmännyt useisiin eri organisaatioihin, jotka tuskailevat käyttäjien omien laitteiden kanssa. Pitäisikö omat laitteet sallia vai pitäisikö kuitenkin yrittää ”pakottaa” käyttäjät käyttämään vain organisaation hallitsemia laitteita? Entä sallimmeko käyttäjien käyttää omia puhelimia mutta kiellämmekö käyttäjiltä omat tabletit? Vai sallimmeko tablettien käytön mutta puhelin tulee olla firmanluuri? Mielenkiintoisia kysymyksiä.

Ohessa muutamia ajatuksia tuskaan: Itse en tee ensinnäkään eroa puhelimien ja tablettien välille. Mielestäni tiedon suojaamisen kannalta ei merkitystä voiko laitteella soittaa perinteisiä GSM-puheluita. Sekä puhelimista että tableteista löytyvät samat käyttöjärjestelmät, molempiin pystyy asentamaan uusia sovelluksia ja molemmilla pystyy käsittelemään yleensä jossain muodossa organisaation tietoa. Ainoa erottava tekijä onkin monesti oikeastaan vain näytön koko.

Netistä löytyy pienellä hakemisella valtavasti erilaisia periaatteita BYOD-käyttösääntöjä varten. Tyypillisesti mallisäännöissä, tai politiikoissa, suositellaan hallintasovelluksen käyttöä (MDM), käsketään määrittämään sallitut / kielletyt laitteet, sallitut / kielletyt sovellukset, käytettävät turva-asetukset (yleensä tosin edellytetään vain pin-koodin käyttöä), kenen vastuulla on laitteen päivittäminen ja varmuuskopioiden ottaminenn ja miten laitteen käytön lopettaminen. Edellä mainittuja asioita on kieltämättä hyvä miettiä. Toisaalta, omasta mielestäni ennen BYOD-käyttösääntöjen (tai politiikan) määrittämistä tulee löytää vastaukset seuraaviin kysymyksiin:

  1. mitä haluamme suojella (mitä tietoa laitteella käsitellään, mitä tietoa laitteeseen tallentuu tai mitä tietoa laitteella tuotetaan) ja
  2. keneltä haluamme suojella ensimmäisessä kohdassa tunnistettuja asioita?
Esimerkiksi organisaatiossa voidaan tunnistaa, että mobiililaitteissa halutaan suojella laitteeseen tulevia sähköposteja (ja niiden liitteitä), kalenterimerkintöjä ja kontaktitietoja. Näiden lisäksi voidaan haluta varautua ”ylisuuriin” puhelinlaskuihin mutta kuvista, videoista ja esimerkiksi paikkatiedoista ei olla huolissaan. Jälkimmäisen kysymyksen vastaus taas voi olla, että kaikilta ei-organisaatioon kuuluvilta (näin ollen esimerkiksi kalenterimerkinnät saavat näkyä kollegoille). Tämän jälkeen onkin huomattavasti helpompi valita soveltuvat kontrollit BYOD-riskien hallitsemiseksi.

Ja sitten pienenä yksityiskohtana privacy filtteriiin: Jos omien laitteiden käyttö on sallittu, niin monesti omalla laitteella voi käyttää yrityksen tiedoista missä tahansa. Kuitenkaan jostain syystä missään näkemässäni esimerkkisäännöissä ei edellytä privacy filterin käyttöä, vaan tämä on jätetty puhtaasi käyttäjien itsensä valistuneisuuden varaan. Jotenkin siis tuntuu siltä, ettei omia tabletteja (tai älypuhelimia) käytettäisi esimerkiksi busseissa, junissa, julkisissa kahviloissa ja niin edelleen... ja missä niitä omia laitteita siis käytettiinkään eniten?

Leppoisin terveisin
Antti

tiistai 22. tammikuuta 2013

Tietoturvan ulkoistaminen Intiaan?

Tämän aamun Kauppalehdessä oli artikkeli "Tietoturvan ulkoistaminen Intiaan lisää riskejä". Artikkelissa käsiteltiin viimeaikaisia Nokian uutisia tietohallinnon ja  tietotekniikkatoimintojen ulkoistamisesta Intiaan. Otsikko on tarkoituksellisen raflaavasti valittu. Vaikka ihan Intiaan asti ei olisikaan ulkoistamassa, asiaan tulee kiinnittää huomiota. Varsinkin pienemmissä ulkoistuksissa tulee vahingossa ulkoistaneeksi myös tietoturvansa ja samalla nostettua huomaamatta riskitasoaan.

Kaikissa ulkoistuksissa tulee huomioida myös tietoturvaan ja tietosuojaan liittyvät asiat. Vaikka kysymys olisikin vain siivoustoiminnan ulkoistamisesta siivousfirmalle, tulee siivojien luotettavuudesta varmistua, jos siivoojat työskentelevät toimistoaikojen ulkopuolella organisaation tiloissa. Kun ulkoistetaan tietojärjestelmien/tietotekniikan ylläpitoa, tulee asiaan kiinnittää erityistä huomiota. Kauppalehden artikkeli painotti ansiokkaasti tätä asiaa.

Ulkoistuksen perussääntöjä on, että ei kannata ulkoistaa asiaa, jota ei itse osaa. Silloin ei varmasti saa tarvitsemaansa palvelua ja ulkoistuksesta haettavat hyödyt jäävät toteutumatta. Ulkoistajan tulee tietää mm. ulkoistamiensa tietojärjestelmien sisällöt, tärkeys organisaatiolle, niihin kohdistuvat vaatimukset ja niitä säätelevä lainsäädäntö. Jo ulkoistussopimusta solmittaessa tulee osata sopia ja vaatia näitä asioita, sekä määritellä miten ulkoistettavan palvelun tilasta raportoidaan ja miten sen onnistumista mitataan. Auditointioikeus kannattaa aina sisällyttää sopimuksiin.

Yksi keino varmistua ulkoistetun palvelun tietoturvallisuudesta on pyytää palveluntarjoajalta ISAE 3402/3000 -lausunto. ISAE 3402 tunnettiin aiemmin nimellä SAS 70 ja se liittyi taloudellisen raportoinnin oikeellisuuteen ja Yhdysvaltain SOX-lainsäädännön vaatimusten toteuttamiseen. ISAE 3000 taas on suunniteltu nimenomaan nykypäivän IT-ulkoistustarpeita varten, ja sen avulla voidaan paremmin varmistua esim. pilvipalveluiden tietoturvan ja tietosuojan toteutumisesta. Tietosuojan toteutumisesta (varsinkin ulkoistettaessa EU:n ulkopuolelle) tulisi varmistua Binding Corporate Rules (BCR) -menettelyllä.

ISAE-lausunnot tunnetaan myös SOC1 (ISAE3402), SOC2 (ISAE3000) ja SOC3 -nimillä (SOC = Service Organization Control report). SOC3 -lausunto on tiivistelmä suoritetusta SOC1 tai SOC2 -tarkastuksesta ja sen antaminen vaatii aina kyseisen tarkastuksen toteuttamisen.

Valveutuneet ulkoistustalot/palvelutoimittajat osaavat jo tarjouskilpailuvaiheessa mainita lausunnoistaan ja esittävät kontrolliympäristönsä sisällön. Nykyaikana palvelun tietoturvan laatu osoitetaan usein jo myyntivaiheessa annettavalla SOC3-lausunnolla.

Muistetaan siis huolehtia ulkoistuksen tietoturvasta, ei tietoturvan ulkoistamisesta!

perjantai 18. tammikuuta 2013

Hunt for the Red October


Tietoturvayhtiö Kaspersky Lab raportoi alkuvuodesta selvittäneensä laajan APT-tyyppisen Red October -haittaohjelman avulla tehdyn vakoiluhankkeen. Haittaohjelman toiminnasta on myös tehty kattava tekninen raportti, joka on suositeltavaa luettavaa kaikille asiasta syvemmällä tasolla kiinnostuneille.


Itse haittaohjelman toiminnassa ja levitystavassa ei näyttäisi olevan merkittävästi uusia innovaatioita tämän hetkisen tiedon perusteella, muutoin kuin hyvin modulaarinen ja mukautuva rakenne - joka viittaa pidempään kehitystyöhön ja moniulotteisiin motiiveihin sen kehittäjillä. Raportin mukaan esimerkiksi levitys on tapahtunut suurelta osin mm. perinteisellä spear-phishing tekniikalla, missä käyttäjä houkutellaan avaamaan sähköpostin liitetiedostona oleva haitallinen MS Office -tiedosto. Vakoiluverkoston ohjauksessa taas käytetään Command and Control (C&C) -palvelimia, jotka hoitavat kohdekoneen kontrolloinnin ja tiedonkeräyksen. Positiivista on että tähän liittyen on julkaistu myös lista muutamasta varmistetusta C&C-palvelimesta maailmalla, viimeisimmän tiedon mukaan siinä on ollut mukana ainakin seuraavia palvelimia (Lähde: Kaspersky Lab):




Koska raportin mukaan myös suomalaisia osoitteita on tunnistettu haittaohjelman leviämisalueelta, niin monet organisaatioiden tietoturvavastaavat ja ylläpitäjät saattavatkin pohtia mahdollisia riskejä, ja vaihtoehtoja varotoimenpiteille omassa ympäristössään. Analyysiä vakoiluohjelman toiminnasta löytyy netistä jo useampia, ja lisää tietoa julkaistaan päivittäin, mutta ensimmäisenä vinkkinä tähän voisikin suositella yrityksen Internet-palomuurien lokihistorian tarkistusta. Etsinnän kohteeksi kannattaa ottaa merkit liikenteestä tai sen yrityksistä näiden listattujen C&C –palvelimien IP-osoitteisiin.  Se on varmasti helpoin ja nopein tapa etsiä ensimmäisiä johtolankoja tähän kyseiseen haittaohjelmaan liittyen omasta organisaatioympäristöstä. Vaatimuksena tietysti että liikennelokeja on tallessa mahdollisimman pitkälle, ja että tämän toisinaan hyvinkin massiivisen lokidatan läpikäynti sujuu edes kohtuullisessa ajassa.

Toinen hyvä esimerkki siitä miksi oman organisaation liikennelokeja ja yhteyksien kohteita, esimerkiksi palomuureilta, VPN-laitteilta ja reitittimiltä on hyvä aika ajoin käydä kriittisemmin läpi, on tämä osittain tragikoominenkin tapaus missä sovelluskehittäjä oli ulkoistanut oman työnsä kaikessa hiljaisuudessa Kiinaan - Ja siinä samalla avannut ulkopuolisille täysin avoimen takaoven yrityksen sisäverkkoon VPN-tunnelin kautta:

Log audit reveals developer outsourced his job to China
http://www.net-security.org/secworld.php?id=14247

Lokidatassa on siis paljon arvokasta tietoa mistä on hyötyä jälkeenpäinkin käytettynä, jos sitä vain osataan analysoida ja suodattaa oikein, kuten tämäkin tapaus osoittaa.

Tietoturvallista vuodenalkua kaikille!

tiistai 15. tammikuuta 2013

0-päivähaavoittuvuus Java 7:ssa – korjaus julkaistu

Oracle on julkaissut Java SE 7:skaan uuden päivityksen (Update 11) [1]. Tämä päivitys korjaa Java SE 7 Update 10:ssä olleen nollapäivähaavoittuvuuden [2]. Yleinen suositus on, että Update 11 asennettaisiin mahdollisimman pikaisesti kaikkiin Java SE 7 asennuksiin.

Huomion arvoista aiheessa on, että nollapäivähaavoittuvuus ei koskenut Java SE 6:den käyttäjiä. (ks. Edellinen postaukseni Java SE 6:den päivitysten loppumisesta). Näinpä tällä kertaa organisaatiot, jotka eivät kiirehtineet päivitystä, säästyivät ylimääräiseltä jumpalta. Noh, Java SE 6:den kehitys on kuitenkin tulossa tiensä päähän, joten tästäkin haavoittuvuudesta huolimatta, Java SE 6:sta käyttävien organisaatioiden on hyvä aloittaa valmistautuminen Java SE 7:ään siirtymistä varten.

Terveisin
Antti

lauantai 5. tammikuuta 2013

Java SE 6 päivitykset loppuvat helmikuun 2013 jälkeen

Oletko edelleen Java SE 6:den käyttäjä? Jos olet, niin nyt on hyvä hetki aloittaa valmistautuminen versiota 7 varten. Oracle on ilmoittanut, että se lopettaa päivitysten kehittämisen Java SE 6:teen helmikuun 2013 jälkeen [1].

Käytössä olevan Java version voi tarkastaa helposti Javan sivuilta: http://www.java.com/verify

  • Viimeisin Java SE 7 versio kirjoitushetkellä: Java SE 7 Update 10
  • Viimeisin Java SE 6 versio kirjoitushetkellä: Java SE 6 Update 38

Javan suhteen on hyvä muistaa, että lähtökohtaisesti vanhoja Java versiota ei tarvitse (eikä pidä) säilyttää koneella, sillä uudemmat versiot ovat yhteensopiva taaksepäin. Oraclen suositus onkin, että kaikki vanhat Java versiot poistettaisiin koneelta, koska päivittymättömät Java versiot muodostavat merkittävän tietoturvariskin [2]. (Kuten viime syksyltä muistamme, niin Javasta on löytynyt useita vakavia haavoittuvuuksia [3].)

Samassa yhteydessä on hyvä arvioida, tarvitseeko Javaa lainkaan koneellaan. Mikäli mieleesi ei tule yhteen sovellusta tai web-sivua, joka edellyttäisi Javaa (JavaScript ei tarvitse Javaa), etkä ole DanskeBankin asiakas, niin suositus on poistaa Java kokonaan koneeltasi. (Isäni totesi aikanaan autostaan, ”että puuttuvat ominaisuudet eivät mene rikki”. Sama pätee myös sovelluksiin, jos sovellusta ei ole lainkaan, niin se ei myöskään aiheuta tietoturvaongelmia.) Mikäli taas tarvitset Javaa, niin pidä huolta siitä, että se on päivitetty viimeisimpään version.

Hyvää vuoden alkua!
Antti