TigerTeam - suomalainen tietoturvablogi

CIA. Kolme kirjainta, jotka useimmat liittävät erään suurvallan tiedustelupalveluun. Samalla nuo kirjaimet kuitenkin muodostavat myös tietoturvan perustan: Confidentiality, Integrity, Availability. Eli luottamuksellisuus, eheys ja saatavuus.

Tiedon on siis pysyttävä vain niiden hallussa joilla on siihen oikeus, sen on oltava yhtenäistä, eli tiedosta ei saa puuttua osia ja sen lisäksi tiedon on pysyttävä saatavilla. Siinä tiedon turvaamisen perusvaatimukset.

Tässä kirjoituksessa otan kantaa tiedon saatavuuteen, sillä se on juuri tähän aikaan vuodesta monen yrityksen ongelma. Eikä ainakaan lähitulevaisuus ole tuomassa siihen parannusta.

Kun kirjoitin tätä yöllä itsenäisyyspäivän tienoilla, kattopelti paukkui tuulessa, nurkissa humisi ja valot räpsyivät. Niin, sähkön saanti oli jälleen kerran veitsen terällä, näin oli jo kolmas kerta viikon sisällä. Ja se on tietoturvaongelma – tiedon saatavuus on jatkuvan uhan alla. Ilman sähköä en pääse käsiksi mihinkään mikä on verkossa, en sen enempää henkilökohtaisiin sähköposteihini kuin työpaikkani järjestelmiin etäyhteyksien avulla.

Hieno tavoite teoriassa, mutta…

Valtioneuvosto asetti vuonna 2008 tavoitteeksi, että käytännössä kaikki vakinaiset asunnot, mikä kattaa yli 99 % väestöstä, sekä yritysten että julkishallinnon organisaatioiden vakinaiset toimipaikat ovat vuoden 2015 loppuun mennessä enintään kahden kilometrin etäisyydellä 100 megabitin yhteyden mahdollistavasta valokuitu- tai kaapeliverkosta.

Hieno tavoite, mutta tässä Suomen valtio lähti aivan väärästä kohtaa liikkeelle. Eihän taloakaan yleensä rakenneta, ennen kuin tontille on vedetty tarpeellinen kunnallistekniikka.

Ilman sähköä ei se kaikenkattava 100 megabitin verkkokaan toimi, ei sitten millään. Sen ovat huomanneet varmasti monet näin syksyisin erityisesti isojen kaupunkien ulkopuolella. Sähkökatkokset vaikeuttavat yhtälailla yritysten toimintaa, kuin kolauttavat monen nuoren nettinatiivin maailmaa World of Warcraftin, Facebookin, Messengerin tai jonkin muun pelin tai palvelun ollessa poissa pahimmillaan vuorokausia. Tämä on siis erityisesti pienten kaupunkien ja haja-asutusalueiden arkipäivää – iso osa nettiyhteyskatkoksista johtuu huonosti toimivista sähköverkoista. Jopa täällä yli 20 000 asukkaan Valkeakoskella sähköt pätkivät taajama-alueella aina kun hieman kovemmin tuulee tai puiden oksille kertyy lunta.

Tässä nouseekin esiin Fingridin ja alueellisten sähkölaitosten merkitys koko maamme nettiyhteyksille. Miten saisimme sähköverkoista luotettavampia ja sen kautta myös nettiyhteyksistä toimivampia? Luonnollisesti kaivamalla kaapelit maahan. Nykyisillä laitteilla jotka samaan aikaan kaivavat kaapeliuraa ja laskevat kaapelia maahan, työ käy juoheasti. Mutta se edellyttäisi isoja investointeja sähköyhtiöiltä.

Tässä pitäisi valtion tulla apuun – ennemmin tavoitteena tulisi olla sähkön saanti maamme yrityksiin ja talouksiin 24/7, vuoteen 2015 mennessä, kuin 100 megan laajakaista.

Yritysten onkin syytä panostaa myös mobiiliverkon käyttömahdollisuuksiin, yhtä lailla kuin yksityisten, sillä sähkökatkon sattuessa mobiiliverkko usein toimii vielä tuntikausia kiinteän verkon ollessa nurin.

Mutta näin ei voi jatkua. Henkilökohtaisesti olen valmis maksamaan sähköstä hieman enemmän, jos saan sitä asuntoomme katkotta 24/7. Tämänhetkinen tilanne kun on se, että joudun hankkimaan muutaman UPS-laitteen sähkökatkosten varalta. Jos olisin yrittäjä, hankkisin UPSien lisäksi mahdollisesti peräkärrygeneraattorin millä varmistaisin sähköntuotannon yhtiölleni kriittisessä tilanteessa.

Niin, kumpi on sinulle tai yhtiöllesi tärkeämpi, 100 megan laajakaista vai varmuus sähkön saannista?

Kirjoittaja Olli Haukkovaara toimii vanhempana tietoturvakonsulttina Nixun Advise-yksikössä.

Sähköpostiosoitteen nykyinen muoto on määritelty jo vuonna 1982 dokumentissa RFC 822. Sen mukaan sähköpostiosoitteessa voi käyttää plus-merkkiä (+).

Useat postinvälitysohjelmat tulkitsevat plus-merkin sähköpostiosoitteessa siten, että plus-merkin ja @-merkin välinen osuus jätetään kokonaan huomiotta. Myös tuo osa välittyy kuitenkin vastaanottajan sähköpostipalvelimelle eteenpäin.

Jos käyttämäsi palveluntarjoajan postinvälitysohjelma toimii yllä esitetyn mukaisesti, voit yksilöidä sähköpostiosoitteesi, kun annat sen vaikkapa rekisteröityessäsi palveluun. Itselläni on käytössä mm. seuraavanlaisia osoitteita:

• pekka.viitasalo+amazon@example.com
• pekka.viitasalo+verkkokauppa@example.com
• pekka.viitasalo+bridge@example.com
• pekka.viitasalo+taloyhtio@example.com

Näihin osoitteisiin lähetetty sähköposti päätyy samaan postilaatikkoon, joka on pekka.viitasalo@example.com, mutta niissä näkyy viestin To-kentässä (Vastaanottaja) koko plus-merkillä varustettu osoite.

Auttaa myös vuodon jäljittämisessä

Sähköpostiosoitteen yksilöinnin perusteella voidaan lajitella sähköposteja nopeasti. Yksilöidystä sähköpostiosoitteesta voi myös päätellä mahdollisessa tietovuototilanteessa mistä palvelusta sähköpostiosoite on vuodettu.

Helppo tapa testata tukeeko palveluntarjoajasi sähköpostiohjelmisto plus-merkkiä on kokeilu. Lähetä omasta sähköpostiohjelmastasi itsellesi sähköpostia omaan yksilöityyn osoitteeseesi (joka on muotoa oma.nimi+testi@example.com) Jos viesti tulee perille, voit jatkossa käyttää plus-merkkiä sähköpostiosoitteesi yksilöintiin.

Yksilöidyn sähköpostiosoitteen käyttö onnistuu kunnolla toteutetuissa palveluissa. Valitettavasti kuitenkin useat sähköpostiosoitteen tarkastusohjelmat ovat väärin toteutettuja, eivätkä hyväksy plus-merkkiä.

SANS-instituutin Ed Skoudis lähestyi taannoin tietoturva-asiantuntijaamme luettuaan ratkaisuehdotuksia sovellustestaamiseen SANS:n murtotestauskurssien postituslistalta. Jaamme nyt nämä Miika Turkian postituslistalle lähettämät vinkit ja ajatukset kuvankaappauksineen blogin lukijoille.

Monet asiakassovellukset lähettävät tietorakenteita tai olioita sarjallistetussa muodossa palvelimelle. Näitä sovelluksia on paljon sekä älypuhelimissa että perinteisen tekniikan PC-ohjelmistoissa. Tällaisen liikenteen testaus vaatii uusia temppuja tavalliseen HTTP/HTTPS-liikenteeseen verrattuna. Perinteisesti sarjallistetun liikenteen testausta on yritetty tehdä hexa-editorilla, jolloin virheiden mahdollisuus kasvaa ja testauksen kattavuus kärsii merkittävästi. Seuraava kuvaruutukaappaus näyttää perinteisen näkymän sarjalliseen liikenteeseen:

Sarjallistetun protokollan tehokas murtotestaus vaatii liikenteen muuttamiseen ymmärrettävään muotoon tutkimista ja muokkausta varten. Tämän jälkeen viesti muutoksineen sarjallistetaan automaattisesti ennen palvelimelle tai asiakassovellukselle lähettämistä. Tämä voidaan tehdä esimerkiksi PortSwiggerin BurpSuite-nimisen työkalun laajennusrajapintaa ja XStream-kirjastoa käyttäen, jolloin käytettävissä on kaikki tutut BurpSuiten testaustyökalut. Sarjallistettu liikenne muutetaan XML-muotoon analyysiä ja testausta varten, kuten seuraava kuvaruutukaappaus osoittaa:

Kuvassa Javan sarjallistettu olio on selväkielisessä muodossa ja muokkaus on varsin helppoa, kun esimerkiksi tekstikentän pituudet lasketaan automaattisesti taustalla. BurpSuiten Intruder -fuzzaus-työkalu onkin esimerkissämme konfiguroitu testaamaan sekä numeerista että tekstimuotoista kenttää sopivilla syötteillä automaattisesti. Jäljelle jää testin varsinainen suoritus ja tulosten analysointi.

Tällä menetelmällä olemme löytäneet huomattavan määrän ongelmia, jotka olisivat ennen menetelmän kehittämistä suurelta osalta jääneet havaitsematta. Esimerkiksi käyttövaltuuksien nostaminen ja toisena käyttäjänä esiintyminen, mielivaltaisten tiedostojen lataus palvelimelta ja SQL-injektio. Kuitenkin ehkä suurin etu tekniikan käytöstä on liiketoimintalogiikan testauksen merkittävä tehostuminen – ellei peräti mahdollistuminen.

Yleisenä havaintona asiakassovellusten testauksesta voi todeta, että erillisen sovelluksen tuottamaan näennäiseen turvaan luotetaan vielä enemmän kuin mitä web-sovelluksissa usein näkee. Asiakassovelluksen erilaiset tarkistukset ja datan piilottaminen kuvitellaan toimivaksi ratkaisuksi, kun verkon yli lähetettävä tieto ei ole selväkielisessä muodossa. Onneksi tällaiset heikkoudet on helppo havaita, kun verkkoliikenne analysoidaan XML-muodossa perinteisen binäärisen “mössön” sijaan.

Varsinainen artikkeli on kirjoitettu tietoturvaorganisaatio SANS:in uuteen murtotestaukseen keskittyvään blogiin, josta kiinnostuneet voivat käydä lukemassa tarkemmat yksityiskohdat. Koko SANS:in uusi murtotestaussivusto on hyödyllinen tietolähde kaikille aiheen parissa työskenteleville.

Kirjoittaja Miika Turkia toimii Nixussa johtavana tietoturvakonsulttina Inspect-yksikössä.

Tietojärjestelmien suunnittelu on edelleen vaikeaa ja valitettavan usein suuret hankkeet epäonnistuvat tavoitteissa budjetin ja aikataulun osalta. Kiire ja puutteellinen suunnittelu aiheuttavat myös vakavia virhetilanteita, jotka puutteellisen testauksen takia havaitaan vasta tuotannossa. Kun ydintoiminnallisuudenkin toteuttaminen on näin vaikeaa, niin miten hyvin suunnittelussa on sitten otettu huomioon järjestelmien tietoturvavaatimukset?

Oma kokemukseni tietojärjestelmien tarkastuksista osoittaa, että tietoturvaa ei edelleenkään oteta riittävissä määrin huomioon suunnittelun alkuvaiheessa. Tietoturva on edelleen tarkistuspiste järjestelmien käyttöönoton yhteydessä.

“Onhan meidän järjestelmät turvallisia, koska meidän koodarit ovat tosi taitavia.”

Ja yleensä koodarit ovatkin taitavia, ongelmana on vain, että toteuttajat toteuttavat asiat määritysten mukaan. Suunnitteluvaiheessa tietoturvakontrolleja otetaan mukaan, silloin kun niitä otetaan, käyttäen apuna yleisesti tunnettuja hyviä käytäntöjä. Yleisesti hyviksi todettujen käytäntöjen hyödyntäminen ei välttämättä ole huono asia, mutta on hyvä muistaa, että ne ovat edelleen yleisiä, eikä kyseiselle järjestelmälle liiketoimintaperusteista johdettuja kontrolleja ja vaatimuksia. Usein lopputulos on, että arkkitehti tai suunnittelija tekee johtajien puolesta päätökset järjestelmälle hyväksytyistä riskeistä, ilman johtajien liiketoimintanäkemystä. Tietenkään johtajilta ei voi ottaa pois vastuuta, joten he joutuvat hyväksymään arkkitehdin näkemykset heidän kyvystään kantaa riskejä. Kuulostaako hyvältä?

Kuinka liiketoimintariskit saadaan prosessiin mukaan?

Kuinka olisi mahdollista kehittää tietojärjestelmät niin, että:

• Tietoturvariskit olisivat liiketoiminnalle selkeästi esitettävissä ja siten tietoisesti hyväksyttävissä

• Järjestelmien suunnittelussa otettaisiin alusta asti huomioon liiketoimintariskit

• Tietoturvakontrolleihin olisi selkeä liiketoiminnallinen tarve

• Liiketoiminnallinen tarve olisi mahdollista jäljittää toteutetussa lopullisessa tietojärjestelmässä tietoturvakontrolliin ja näin perustella sen olemassaolo

Vastauksen näihin haasteisiin tuo SABSA (Sherwood Applied Business Security Architecture). Se kehitettiin jo vuonna 1995, mutta ei ole vielä levinnyt laajalti ammattilaisten tietoisuuteen Suomessa tai Euroopassa yleensäkään. Yhdysvalloissa sekä Aasian ja Australian suunnalla yritykset ovat ottaneet SABSA:n hyvin vastaan ja osaksi organisaatioiden tietoarkkitehtuuristrategiaa. Esimerkiksi Iso-Britannian puolustusministeriö ja Kanadan hallitus ovat adoptoineet standardin kehitysmallikseen.

Suomessa järjestettiin elokuussa ensimmäinen SABSA Foundation -kurssi, johon myös allekirjoittanut osallistui. Kurssia oli yritetty järjestää jo kuutisen vuotta ja viimein se saatiin tänne – sekä vetäjäksi yksi mallin kehittäjistä, David Lynas. SABSA tarjoaa kolmiportaisen sertifiointiohjelman tietoturva-arkkitehdeille: Foundation (SCF), Practitioner (SCP) ja Master (SCM).

SABSA on liiketoiminnan näkökulmasta lähtevä malli kehittää tietoturvaratkaisuja, tietoturva-arkkitehtuureja, organisaation tietoturvastrategiaa, tietoturvapalveluja ja yksittäisiä tietojärjestelmiä tai komponentteja. SABSA:n kuusitasoinen malli kattaa kaikki neljä IT-kehityksen vaihetta: strategia, suunnittelu, toteutus ja hallinta sekä operointi. Riskipohjainen lähestymistapa yhdistettynä kaksisuuntaiseen jäljitettävyyteen toteutuksesta liiketoimintavaatimuksiin ja päinvastoin mahdollistaa selkeän näkymän myös yrityksen johdolle. Toteutetut tietoturvakontrollit ovat myös mitattavissa ja siten niiden hyödyllisyys on todistettavissa. Mallia on mahdollista hyödyntää myös erittäin kompleksisissa ympäristöissä ja se on siten hyvin skaalautuva eri käyttötarkoituksiin. SABSA on myös täysin yhteensopiva muiden mallien kuten ISO 27000, ITIL ja CobIT kanssa.

Laajemmin asiaa voi käsitellä organisaation tietoarkkitehtuuristrategiana (Enterprise Architecture, EA). Tällä hetkellä ehkä suosituin käytetty malli on TOGAF (The Open Group Architecture Framework), joka tarjoaa työkalut informaatioarkkitehtuurin suunnitteluun, kehittämiseen, toteutukseen ja hallintaan (governance). Merkittävä uutinen SABSA:n kannalta on, että TOGAF tulee integroimaan SABSA:n osaksi tietoturvaosuuttaan, mikä tulee varmasti lisäämään SABSA:n käyttöönottoa maailmalla.

Seuraava SABSA-kurssi Suomessa on suunniteltu toukokuulle 2012, joten rohkeasti mukaan!

Kirjoittaja Jari Pesonen toimii Nixussa tietoturva-arkkitehtuurien konsulttina ja tietojärjestelmien auditoijana.

Organisaatiot, jotka ovat tilanneet PCI DSS -tarkastuksia muutamia vuosia sitten, ovat oletettavasti saaneet tarkastukset silloin edullisemmalla hinnalla kuin nykyisin. Tarkastukset olivat silloin myös kevyempiä ja kestivät lyhyemmän ajan. Mikä siis on muuttunut muutamassa vuodessa?

Suurin syy nykyisten tarkastusten raskauteen johtuu kansainvälisen PCI-toimielimen (PCI Security Standars Council, jatkossa PCI Council) tarkentuneista raportointivaatimuksista. Kun aikaisemmin tarkastaja (QSA, Qualified Security Assessor) saattoi kirjata, että vaatimus on kunnossa ja perustella asiaa muutamalla sanalla, tulee tarkastajan nykyisin noudattaa hyvinkin yksityiskohtaista raportointiohjetta. Raportointiohjeessa on purettu auki jokainen vaatimus, ja kerrottu tuleeko kyseisen vaatimuksen kohdalla:

• tarkastaa järjestelmän asetukset

• tarkastaa dokumentaatio

• haastatella henkilöstöä

• havainnoida prosessien toimivuutta

• valita otos

Kun huomioidaan, että PCI-tietoturvastandardissa on yli 200 vaatimusta, muodostuu itse raportoinnista hyvin suuri työ. Tämä näkyy myös raporttien pituuksissa: ennen selvittiin alle sadan sivun tarkastusraporteilla (ROC), nyt tyypillinen raportti on yli 200 sivua pitkä.

Raportointiohjeen ensimmäinen versio, ns. Scoring Matrix, ilmestyi toissa vuonna ja oli tarkoitettu PCI DSS -standardin 1.2-version pisteytykseen. Nimensä mukaisesti kyseinen ohje kertoi vain miten PCI Council pisteyttää raportit, mutta ei juurikaan ohjeistanut QSA-yrityksiä siitä miten varsinainen raportointi tulee tehdä.

Myös tarkastusraporteista tarkempi ohjeistus

Huhtikuussa PCI Council julkaisi ensimmäisen version ohjeesta PCI DSS 2.0 ROC Reporting Instructions. Perusidea on sama kuin em. Scoring Matrix -ohjeessa, mutta pelkän pisteytyksen lisäksi ohje sisältää yksityiskohtaista tietoa siitä, mitä jokaiseen ”In Place” -kohtaan tulee kirjata. Raportointiohje tullee kaikkien saataville myöhemmin tänä syksynä.

Tarkastusten kohteena olevat yritykset voivat myös hyötyä tästä ohjeesta, sillä katsomalla vaatimuksiin liitettyjä neuvoja voi helposti päätellä mitä tarkastaja odottaa näkevänsä kunkin vaatimuksen kohdalla.

Raportointiohje on suoraan sidoksissa PCI Councilin laadunvarmistusohjelman kanssa. PCI Council tarkastaa säännöllisesti, että QSA-yritykset noudattavat sen asettamia määräyksiä toiminnassaan. Tarkastukset voivat liittyä QSA-yrityksen vakuutuksiin, politiikkoihin ja ohjeisiin, mutta myös tarkastusraportteihin.

Raporttien tarkastus tapahtuu siten, että PCI Council pyytää QSA-yritykseltä kaikki raportit tietyltä ajanjaksolta, esimerkiksi kuluvan vuoden kolmas kvartaali (Q3/2011). Ennen raporttien lähettämistä QSA-yritys sanitoi raportit siten, että asiakkaan nimi, osoite, IP-osoitteet ja muu yksilöivä tieto poistetaan. PCI Council käy tämän jälkeen raportit läpi ja tekee sille pisteytyksen. Mikäli raportissa on merkittäviä puutteita, joutuu QSA-yritys ns. remediation-tilaan. Samalla QSA-yrityksen nimi merkitään punaisella QSA-luettelossa. Listaa säännöllisesti seuraavat tietävät, että usea maineikaskin yritys on ollut ko. tilassa jossain vaiheessa QSA-uraansa.

Mitä tämä tarkoittaa asiakkaan kannalta

QSA-yritykset pyrkivät tietysti välttämään joutumasta remediation-tilaan ja ennen kaikkea pääsemään nopeasti pois kyseisestä tilasta. Nixun saamien tietojen mukaan osa QSA-yrityksistä on joutunut jopa kaksinkertaistamaan tarkastuksiin menevän työmäärän täyttääkseen raportointivaatimukset ja sitä kautta saadakseen nimensä pois tuolta “punaiselta listalta”.

Osa tarkastettavista kohteista on kommentoinut, että tarkastusten hintojen korotuksien lisäksi tarkastuksiin vaadittava työmäärä asiakkaan puolella on lisääntynyt kohtuuttomasti. Pahimmillaan tämä on tarkoittanut sitä, että tarkastaja on paikalla asiakkaan tiloissa yhtäjaksoisesti kahdesta kolmeen viikkoon ja varaa ison osan asiakkaan henkilöstöä palavereihin. Tarkastajan on käytävä jokainen standardin kohta läpi numerojärjestyksessä kunnes kaikki yli 200 vaatimusta on käsitelty.

Nixun näkemyksen mukaan raportointivaatimuksien kiristymisen ja sitä kautta kokonaistyömäärän nousun ei pidä suoraan näkyä asiakkaan työmäärissä. Tarkastuksien huolellinen suunnittelu takaa sen, että asiakkaan henkilökuntaa tarvitsee häiritä mahdollisimman vähän ja tarkastus saadaan vietyä nopeasti läpi. Suuri osa työstä on kuitenkin sellaista, jonka QSA voi suorittaa omassa toimistossaan asiakasta häiritsemättä, kuten dokumenttien katselmointi ja raportointi.

Päivitys 15.9.: Tarkentuneista vaatimuksista on myös hyötyä asiakkaille, sillä ne takaavat omalta osaltaan että QSA-yritysten tuottamat auditointipalvelut täyttävät palveluille asetetut kriteerit. Lisäksi ne pakottavat tarkastajan toimimaan riittävällä tarkkuudella, jolloin saadaan parempi varmuus kontrollien toimivuudesta. PCI Councilin mukaan osa yrityksistä luopui vapaaehtoisesti QSA-toiminnastaan uusien raportointivaatimuksien lanseerauksen ja niiden valvomisen alettua. Mikäli yritys ei vapaaehtoisesti luovu QSA-toiminnastaan mutta ei myöskään ole halukas tai kykenevä noudattamaan PCI Councilin asettamia laatuvaatimuksia, voi seurauksena olla ns. revocation, eli QSA-statuksen menetys, kuten eräälle yritykselle äskettäin kävi.

Nixu on ollut aikaisemmin mainitun PCI Councilin rutiinitarkastusten kohteena muutamaan otteeseen. Kuten tarkastuksissa yleensäkin, jotain huomautettavaa on löytynyt, mutta varsinaisessa remediation-tilassa Nixu ei ole ollut.