TigerTeam - suomalainen tietoturvablogi

Äskettäinen vakava tietoturvalöydös GitHubissa nostatti varmasti monien kulmakarvoja. Vaikka kyseessä ei ollut pahantahtoinen yritys hyökätä järjestelmää ja sen tietoja vastaan, koko kuviossa on monta mielenkiintoista ja huolestuttavaakin puolta.

Ensinnäkään moni ei varmaankaan ole oikeasti miettinyt, kuinka paljon avoimiin open source -komponentteihin oikeasti luotetaan. Tässä tapauksessa olisi ollut verrattain triviaalia saada ujutettua pahantahtoista koodia sopiviin projekteihin. Ehkä asia olisi huomattu, ehkä ei. Moni ei ole itse käynyt läpi käyttämäänsä avoimen lähdekoodin koodia, mutta voi toivoa että projektin kehittäjät kiinnittäisivät asiaan huomiota.

Toisekseen haavoittuvuuden käsittely (varsinaisesti Ruby on Railsissa) ei ehkä mennyt kaikkien taiteen sääntöjen mukaan. Selviönä ei voi pitää, että aina vakavatkaan ongelmat saataisiin oikeasti nopeasti korjattua.

Asiasta on kuitenkin nostettava esille sen perimmäinen ongelma, eli Ruby on Railsissa oleva haavoittuvuus. Se ei ole mitenkään uniikki, vaan samanlaisia ongelmia on nähty muissakin teknologioissa.

Entä kun parametreina onkin vihamielistä sisältöä

Teknisesti GitHubin tapauksessa kyse oli Ruby on Railsin ns. Mass Assignment -toiminnon väärinkäytöstä, jossa tietokantaa päivitetään automaattisesti käyttäjän lisäämien parametrien perusteella. Näin tapahtuu myös niiden kenttien osalta, joita ei ollut tarkoitettu päivitettäväksi.

Hyvin samantyyppinen ongelma todettiin vuonna 2008 Spring MVC -frameworkissa, tapaus tunnetaan nimellä Data Submission to Non-Editable Fields. Spring MVC:ssä todettiin pari vuotta sitten myös vakavampikin ongelma, jossa käyttäjän lähettämät request-parametrit käsiteltiin niin, että tuloksena palvelin lähti lataamaan taglibien koodia hyökkääjän antamasta HTTP-osoitteesta – uskomatonta mutta totta. Haavoittuvuus referensseineen on kuvattu CVE-2010-1622-dokumentissa.

Vastaavanlainen tapaus on Strutsin OGNL-lausekkeiden käsittely. Struts käsittelee käyttäjän antamia OGNL-muotoisia request-parametreja automaattisesti ja mahdollistaa esimerkiksi järjestelmäkomentojen ajamisen etänä palvelimella. Tekniikkaan liittyy lukuisa määrä vakavia haavoittuvuuksia (vanhimmasta uusimpaan CVE-2007-4556, CVE-2008-6504, CVE-2010-1870, CVE-2012-0391 ja CVE-2012-0838). Nämä haavoittuvuudet ovat siis olemassa vaikkei kyseistä toimintoa varsinaisesti käyttäisikään.

Kaikki tapaukset ovat vakavia tietoturvaongelmia. Parhaiten niitä kuvaa seuraava Dr Dobb’s Journalissa esitetty kaavio (Thompson, Whittaker: ”Testing for Software Security”, Dr Dobb’s Journal November 2002):

Pääosin ohjelmisto tekee sen mitä sen on speksattu tekevän. Kuitenkaan kaikilta osin se mitä järjestelmän speksataan tekevän, ei välttämättä päädy toteutukseen. Tällöin syntyy juuri niitä tyypillisiä ohjelmistobugeja. Yllättävää kyllä, ohjelmisto toisaalta tekee asioita, joita sen ei ole tarkoitettu tekevän.

Nämä ovat hyviä kandidaatteja tietoturvaongelmien lähteiksi, ja juuri tällaisista asioista edellä mainituissa tapauksissa on kyse.

Mistä tällainen speksaamaton toteutus sitten syntyy? Tietenkään harva koodailee järjestelmään ylimääräisiä kiemuroita ilman mitään varsinaista tarvetta, oli se kirjattu spekseihin tai ei.

Käytännössä kyse on jostain seuraavista asioista:

• Järjestelmän toimintalogiikkaa ei ole mietitty riittävän kattavasti, joten tietyillä syötteen arvoilla oikea toiminta on jätetty määrittämättä. Koska järjestelmän täytyy kuitenkin tehdä jotain syötteelle, ollaan vaarallisella vyöhykkeellä. “Hauskimpia” esimerkkejä ovat online-ostospalvelut, joissa voi esimerkiksi jättää palvelulle negatiivista tippiä. Tällöin ostoksen loppusumma pienenee sopivasti. Koska missään ei erikseen määritelty (tai mietitty) mitä negatiivisille arvoille tehdään, niin järjestelmä luonnollisesti laskee loppusumman ostosten hinnan ja tipin matemaattisena summana.

• Järjestelmässä käytetään komponentteja, jotka helpottavat koodaajan työtä ja tekevät erilaisia asioita automaattisesti ja pyytämättä. Erilaiset automaattiset request-parametrien käsittelyt menevät juuri tähän kategoriaan. Kätevä toiminto, kyllä, mutta kovin vaarallinen. Jos miettii millainen määrä koodia oikeasti ajaa tyypillistä web-tietojärjestelmää, niin räätälöidyn ohjelmakoodin osuus on häviävän pieni verrattuna frameworkeihin, komponentteihin, sovelluspalvelimen koodiin ja muuhun ajettavaan koodiin, vaikka jättäisi käyttöjärjestelmätason kokonaan huomioimatta. Tämän huomaa helposti katsomalla virhetilanteiden yhteydessä näkyviä ns. stack traceja, joissa kutsupuun muutama taso on räätälöityä koodia ja 100 tasoa kaikenlaista muuta koodia.

• Järjestelmässä on tuotantokäytön kannalta kuollutta koodia, esimerkiksi testaukseen ja vianselvitykseen käytettävää logiikkaa. Tällaista logiikkaa voi tietenkin olla myös muualla kuin räätälöidyssä koodissa, tyypillisesti vaikkapa frameworkin esimerkkikoodin muodossa.

Pahantahtoisen koodin ja takaporttien mahdollisuutta ei tietenkään voi sulkea pois, mutta käytännössä tällaiset tapaukset ovat kovin harvinaisia.

Mitä asialle sitten pitäisi tehdä?

Pohjimmiltaan pitäisi pystyä tarkasti määrittämään, mitkä ovat järjestelmän kannalta sallittuja ja odotettuja syötteitä (esim. URL-osoitteita, parametrien nimiä ja syötteiden arvoja). Kaikki muu pitäisi olla kiellettyä. Käytännössä tällaisen teknisen määrityksen muodostaminen, ylläpitäminen ja tekninen käyttö on hyvin hankalaa. Yhtenä vaihtoehtona on varmistaa, että käyttäjältä hyväksytään vain toimintoja ja syötteitä, jotka järjestelmä itse tarjoaa käyttäjälle. Parhaimmillaan tähän soveltuu käytetyn UI-frameworkin omat suojaukset (esim. linkkien kryptaus à la Wicket), mutta ulkoisiakin komponentteja voi sovitella paikalleen (esim. HDIV). Voi myös kerätä lokia järjestelmälle tulevista syötteistä ja parametreista ja sitten määrittää sallittu syötejoukko. Tietysti itse syötteiden arvoja harvoin pystyy kiinnittämään.

Jos ongelman onnistuu taklaamaan, samalla tulee usein hoitaneeksi OWASP:in Top 10 -listan ongelmat A4, A5 ja A8. Käänteisesti toimiminen ei kuitenkaan toimi eli Top 10 -listan huomioiminen ei suojaa tällaisilta ongelmilta.

Pahimpaan on kuitenkin syytä varautua ja rakentaa järjestelmän puolustus useamman kerroksen varaan ja hyviä periaatteita noudattaen. Toimiva komponenttihaavoittuvuuksien seuranta on myös keskeinen osa haavoittuvuuskartalla pysymistä.

Vielä lyhyesti alun GitHub/Ruby on Rails -ongelmaan. Hyviä yksirivisiäkin puolustustapoja sitä vastaan löytyy, kunhan niistä ollaan tietoisia ja velvoitetaan koodaajatkin seuraamaan valittua toimintatapaa. Tapa tulee kirjata kehittäjien Secure Coding Guidelinesiin tai vastaavaan käytännön ohjeeseen. Ja jos ohjeistusta ei vielä ole, sellainen on viimeistään nyt hyvä muodostaa ja ottaa käyttöön.

Lisää aiheesta: How Homakov hacked GitHub and the line of code that could have prevented it

Työntekijämme vierailevat säännöllisesti luennoimassa tietoturva-alan tilaisuuksissa. Tässä kuussa nixulaisia oli puhumassa OWASP-järjestön Suomen paikallisjaoksen kevätkauden viimeisessä tilaisuudessa Helsingissä.

Ari Kesäniemen aiheena oli Mobile application threat analysis ja Nixu Open -yksikköä edustanut Juhani Mäkelä taas piti esityksen otsikolla Why Privacy Matters? – Some thoughts about privacy and mobile application security.

Esityksiin voit tutustua PDF-muodossa OWASP Helsinki -jaoksen sivuilla vaikket tilaisuuteen olisi päässytkään osallistumaan.

Esitykset ovat englanninkielisiä.

Mikä OWASP?

Verkkosovelluksien tietoturvaan keskittyneen, kansainvälisen vapaaehtoisjärjestö OWASP:n (Open Web Application Security Project) tarkoituksena on edesauttaa turvallisten sovellusten kehitystä ja ylläpitoa OWASP Helsinki Chapter -alajaos perustettiin Suomeen vuonna 2006.

Ensimmäinen mielikuva esimerkiksi luottokorttiyhtiöiden ja tietoturvatoimijoiden verkkosivustostoista on usein vaatimus korkeasta tietoturvatasosta. Aina tietoturva ei kuitenkaan toteudu käytännössä. Seurasimme lokakuussa maailmalla raportoituja XSS-tyyppisiä turva-aukkoja. Käytännössä siis esimerkiksi sitä minkä toimialan sivustoilta on raportoitu haavoittuvuuksia verkkosivun rakenteen muutoshyökkäykselle. Lähteenä oli XSS-aukkojen raportointiin keskittynyt sivusto XSSed.com ja viime kuukausina aktiisesti XSS:iä raportoineen ryhmän sivusto Team Elite - tosin täysin kattavana ei otosta kuitenkaan voida pitää.

XSS-haavoittuvuuksia on raportoitu viime kuussa mm. tunnettujen virustorjuntayhtiöiden verkkosivuilla, esimerkkinä Symantecin tapaus. Eikä kyseessä ole ainut tietoturvatoimija. Myöhemmin lokakuussa raportoitiin mm. ESETin haavoittuvuudesta.

Myös luottokorttiyhtiö Visan pääsivustolta löydettiin hiljattain cross-site scripting – eli XSS-haavoittuvuus, joka salli skriptikoodin ajamisen sivustolla.

Mutta siis mikä XSS? Cross-site scripting, lyhenteenä XSS, tarkoittaa OWASP-yhteisön suomentamin termein tilannetta, jossa “Verkkosivun rakenne ei säily”. Tällaisessa ns. verkkosivun rakenteen muutoshyökkäyksessä käyttäjän antama syöte välitetään selaimelle tarkistamatta. Lopputuloksena on sivun ulkoasun muuttuminen esim. vieraalta palvelimelta ladatulla sisällöllä.

XSS-aukkoja on olemassa useaa tyyppiä ja osalla aukoista voidaan hankkia esim. kirjautumiseen käytettävä eväste sivustolta.

Kuun viimeisinä päivinä listalle liittyivät vielä tunnettu uutissivusto Zdnet XSS-haavoittuvuuksineen sekä sunnuntaina Yhdysvaltain presidentin my.barackobama.com-sivusto, jolta haavoittuvuuksia löytyi peräti kolme kappaletta.

Visa-tapauksesta on muiden ohella tallessa kopio XSSed-sivun arkistossa. Samalla sivustolla on listattuna myös kolme American Expressiä ja MasterCardia koskevaa XSS-aukkoa.

Luottokorttiyhtiöillä aikaisemminkin samoja aukkoja

Lokakuussa raportoitujen tapausten luonne ja vakavuus vaihtelee, mutta valitettavasti suurin osa tapauksista on edelleenkin korjausta vailla. Mikään uusi asia eivät XSS:t toimijoiden sivuilla ole. Toissa jouluna VISA:n sijoittajasuhteisiin keskittynyt Investor.visa.com-sivusto kärsi myös XSS-haavoittuvuudesta, keväällä 2007 haavoittuvuus oli puolestaan Visa.com-sivuston hakutoiminnossa.

Herääkin kysymys miten XSS-haavoittuvuus on voinut jäädä luottokorttiyhtiöille tietoturva-auditoinnin tehneeltä taholta huomaamatta ja millä aikajänteellä auditoinnit on suoritettu. Sivuston koodin muututtua kun usein tulee ilmi uusia XSS-haavoittuvuuksia.

Virustorjuntatoimijoiden sivuilta aukot löytänyt ja julkistanut ryhmä Team Elite kuuluu ns. valkohattuhakkereihin eli ryhmän toimintaperiatteena on julkaista tieto haavoittuvuuksista vasta kun ne on saatu korjattua. Aina eivät turva-aukkojen löytäjät kuitenkaan toimi vastuullisesti. Joka tapauksessa – raportoitiin aukot vastuullisesti tai ei – ei XSS:n löytyminen maailmanlaajuisen luottokorttiyhtiön sivustolta ainakaan eduksi toimijan maineelle ole.

Vain vuosi siitä kun edellinen versio BSIMM:stä tuli ulos McGraw, Miguel ja Chess ovat päivittäneet BSIMM:n uuteen 2.0-aikaan. BSIMM (Build Security In Maturity Model) on tietoturvallisen ohjelmistokehityksen kypsyysmalli, jonka avulla voidaan arvioida organisaation kyvykkyyttä tuottaa tietoturvallisia ohjelmistoja. Kysymys on siis siitä kuinka hyvin tietoturva otetaan ohjelmistokehityksen aikana huomioon. BSIMM:n tekijöillä on ollut tavoitteena muodostaa sellainen malli, jota oikeasti on käytetty käytännössä, ja tekijät ovat keränneet eri yrityksiltä tietoa siitä, millä keinoilla ja menetelmillä yritykset ovat toteuttaneet tietoturvallista ohjelmistokehitystyötä.

Pienempiä toimijoita mukana otoksessa

Tällä kerralla muutokset mallissa ovat olleet pieniä, mutta haastateltujen yritysten määrä on kasvanut 30:een, ja mukaan on tullut aikaisempaa pienempiä yrityksiä. Tietoahan ei ole julkaistu suoraan, mutta se on pääteltävissä keskiarvojen pienentymisestä.

Yksi merkittävimmistä tunnusluvuista kuitenkin on pysynyt samana – tietoturvallisen ohjelmistokehityksen yksikön koko on vieläkin 1 % ohjelmistokehittäjien lukumäärästä. Tietoturvaa saa siis halvalla? Ehkä ei niinkään. Mallissa on 109 tehtävää tai toimintoa, joista jokaista harrastetaan siis vähintään yhdessä yrityksessä. Parhaimmat yritykset pystyvät kuitenkin tekemään samanaikaisesti 74 näistä, ja huonoimmat yhdeksän keskiluvun ollessa noin viidenkymmenen paikkeilla. Eli prosentilla saa noin puolet tietoturvasta? Onko malli liian kunnianhimoinen, vai onko osa tehtävistä sellaisia, jotka vain soveltuvat erityisen hyvin jollekin organisaatiolle? Ilmeisesti ainakaan mallin tekijöiden mielestä tehtäviä ei ollut liikaa, sillä 2.0-versiopäivityksessä vain niiden tasoja korjailtiin.

Mikä sitten harvojen herkkua?

Kuitenkin mallissa on vielä kuusi tehtävää, joita tekee vain muutama yritys. Automaattiseen koodivirheiden analysointiin ja raportointiin, missä otetaan huomioon havainnot useasta lähteestä, uskoo vain yksi yritys. Tällaisen rakentamiseenkin toki voi jo mennä vuosi jos toinenkin, ja tulevaisuus näyttää, pysyykö tämä mielenkiintoinen mutta epäilemättä harvoin kustannustehokas koodinkatselmointityökalu mallissa mukana.

No mitä useimmat tekevät? 66 % yrityksistä tekevät näitä, mutta kirjoittajatkin myöntävät, että tilastoista ei taida olla mallin tekijäksi, vaan suosittelevat, että tietoturvallista ohjelmistokehitystä kehittävät harkitsisivat seuraavia toimenpiteitä:

• Tietoturvakriteerien asettaminen [SSDL Gates]

• Vaatimuksenmukaisuusvaatimusten [Compliance] ymmärtäminen (PCI, SOX, HIPAA, VARe, VAHTI, tietoturvatasot)

• Yksityisyydensuojan tietoisuuden korostaminen [promote]

• Ohjelmistokehityksen tietoturvapolitiikan luominen asiakastarpeita ja säätelyä vastaavaksi

• Tietoturvatietoisuuskoulutuksen järjestäminen

• Tiedon luokitteluun ja säilytykseen tarkoitetun järjestelmän luominen

• Asiakkaan tarpeita vastaavien tietoturvastandardien luominen

• Tietoturvavaatimuksien katselmointi

• Sekä automaattisten työkalujen että manuaalisen katselmoinnin käyttäminen

• QA:n raja-arvotestauksen tukemisen varmistaminen [edge/boundary value condition testing]

• Ulkoisen hyökkäystestaajan käyttäminen

• Verkon suojauksen varmistaminen

• Poikkeustilaprosessien luominen

• Tuotannossa havaittujen virheiden vieminen tuotekehitykseen

Lista ei vaikuta mitenkään hirvittävän vaativalta, ja voihan olla, että nämä tehtävät toteutetaan suurimmassa osassa yrityksiä, koska ne nyt vain ovat helpoimpia. Mallin kattavuuden arviontia eivät ulkopuoliset tämän tarkemmin pääse arvioimaan, koska kirjoittajat eivät julkista tarkempia tutkimustietoja.

BSIMM sinällään näyttäisi olevan mielenkiintoinen malli tietoturvallisuuden ohjaamiseen, joka korostaisi mallin käytettävyyttä verrattuna ylhäältä annettuun malliin. Tällä hetkellä joko suppeahko otos verottaa johtopäätösten tekemistä tai malli sinällään ei toimi. Se ei kylläkään vie arvoa yhdestäkään mallissa esiteltävästä tehtävästä ja aivan varmasti voidaan todeta, että jos yritys pystyy toteuttamaan puoletkin näistä tehtävistä on tietoturvan taso merkittävästi paremmalla tolalla kuin ilman näitä tehtäviä.

Vertailun vuoksi voidaan mainita, että erilaisia kypsyysmalleja tietoturvalliseen ohjelmistokehitykseen on olemassa useita, joista OWASPin OpenSAMM lienee viimeisin, ja SSE-CMM niitä vanhimpia, ja se on viety ISO-standardiksi ISO/IEC ISO 21827 saakka. Microsoftilla on oma SDL (Security Development Lifecycle) ja OWASPilta löytyy vielä CLASP-prosessinsa – Comprehensive, Lightweight Application Security Process. Nixu tarjoaa Turvaluotsi-palvelua ohjelmistokehityksen tietoturvan parantamiseksi. Palvelu on toteutettu käyttäen hyväksi alan parhaita käytäntöjä.

OWASP-yhteisö on julkaissut hiljattain uuden, vuoden 2010 version merkittävimpiä web-turvariskejä käsittelevästä Top 10 -dokumentistaan.

Merkillepantavaa nyt julkaistussa listassa on se, että OWASP haluaa puhua tietoturvariskeistä – ei enää haavoittuvuuksista ja tietoturvaongelmista.

Listan kolmen kärkeen kuuluvat riskit ovat hyvinkin tuttuja. Ykkösenä ovat injektiohyökkäykset, joilla tarkoitetaan taustajärjestelmäkyselyn, esimerkiksi tietokantakyselyn rakenteen muutoshyökkäystä. Myös Suomessa merkittäviä salasanamurtoja on tehty tällä menetelmällä, jossa esimerkiksi käyttöliittymien tekemiin SQL-kyselyihin liittyvä puutteellinen syötteentarkistus mahdollistaa salasanojen varastamisen tietokannasta. Muutaman kuukauden välein nähtävissä massiivisissa SQL-injektiohyökkäyksissä, joissa haittaohjelmia levitetään verkkosivuille injektoituun koodiin, on aina ollut mukana myös suomalaispalvelimilla toimivia sivustoja.

Listan toista sijaa pitävä cross-site scripting eli XSS oli vielä edellisen, vuoden 2007 Top 10 -listauksen ensimmäisellä sijalla, mutta niiden määrä ei ole tekemissämme tarkastuksissa osoittanut vähenemisen merkkejä.

Isoin sijoitusmuutos on uuden listan kolmonen - Puutteellisesti toteutettu tunnistusmenettely ja istunnonhallinta, joka oli edellisessä dokumentissa vasta sijalla 7. Myös tähän liittyviä havaintoja tehdään lähes jokaisessa Nixun tekemässä tarkastuksessa, ja se onkin ansainnut nykyisen sijansa.

Salasanat selväkielisinä saatavilla

Lopullinen lista muuttui julkaisukandidaattivaiheen sisältäneen Failure to Restrict URL Access -luokan osalta siten, että RC1-listalla vielä sijalla 7. ollut luokka putosi lopullisella listalla kahdeksanneksi. Puutteellinen tietojen salaus (Insecure Cryptographic Storage) puolestaan nousi lopullisella listalla sijalta 9. seitsemänneksi.

Tyypillisin tähän liittyvä havainto on edelleen salasanojen tallentaminen selväkielisenä, vaikka tämä on jo pitkään ollut vastoin kaikkia suosituksia.

Myös kuljetuskerroksen riittämätön suojaus (Insufficient Transport Layer Protection) nousi yhtä pykälää korkeammalle viime marraskuussa alkaneella kommentointikierroksella.

Tässä kirjoituksessa on käytetty luokista suomenkielisiä vastineita, jotka OWASP Helsinki julkaisi viime kesänä.

Mikä OWASP?

Verkkosovelluksien tietoturvaan keskittyneen, kansainvälisen vapaaehtoisjärjestö OWASP:n (Open Web Application Security Project) tarkoituksena on edesauttaa turvallisten sovellusten kehitystä ja ylläpitoa. Järjestö on voittoa tavoittelematon ja se toimii jo lähes sadassa maassa. Suomen OWASP Helsinki Chapter -niminen alajaos perustettiin reilut kolme vuotta sitten.

Sovellustietoturvallisuuden kehittymistä suomalaisissa organisaatiossa läheltä seuranneena huomaan edelleen törmääväni usein siihen, että sovelluksia ostavilla tai sovelluksia kehittävillä henkilöillä on vääriä käsityksiä sovellustietoturvallisuudesta tai jopa perustiedot sovellustietoturvallisuudesta puuttuvat.

Nykyistäkin perustietämystasoa kuvaa hyvin eräs vuoden takainen uutinen, jossa tunnettua suomalaista web-palvelua pyörittävän yrityksen toimitusjohtajalta kyseltiin ovatko palvelun käyttäjätunnukset ja salasanat turvassa, kun juuri aikaisemmin olivat erään toisen web-palvelun käyttäjätunnukset ja salasanat vuotaneet julkisuuteen. Toimitusjohtajan vastaus oli, että käyttäjätunnukset ja salasanat ovat turvassa – ne ovat kahden palomuurin takana.

“Meidän sovelluksemme on suojattu, meillä on palomuurit, virustorjunta ja IDS”, “Mutta kun meidän sovelluskehitys-framework huolehtii näistä tietoturva-asioista”, “Meidän organisaation tietoturva-asiantuntijat hoitavat nämä asiat”. Kuulostaako tutulta?

Näyttää siltä, että kestää vielä tovin kunnes sovelluksen ostaja tai peruskehittäjäkin tiedostaa, että se sovelluksen tietoturvallisuus on omasta työstä kiinni. Ei ole olemassa mitään maagista verkkolaitetta tai tietoturvaohjelmistoa joka huolehtisi siitä, että sovelluksen tiedot olisivat turvassa, jos sovellus itsessään on haavoittuva.

Sovellustietoturvaa läpi koko prosessin

Alan mediakin keskittyy sovellustietoturvasta puhuttaessa vain uusien haavoittuvuuksien uutisointiin. Hyvin harvoin artikkeleissa puhutaan turvallisesta sovelluskehityksestä ja mistä johtuu se, että sovellukset alun alkaenkin ovat niin haavoittuvia.

Onneksi valoa on näkyvissä tunnelin päässä. Useat organisaatiot ovat vihdoin heräämässä ja käynnistäneet hankkeita sovellustietoturvallisuuden tietoisuuden kasvattamiseksi ja oman sovelluskehitys- tai sovellushankintaprosessin uudistamiseksi, niin että tietoturvallisuus tulee huomioitua heti jo uutta sovellusta suunniteltaessa.

Toivottavasti myös alan oppilaitoksetkin pikkuhiljaa alkaisivat ottamaan sovellustietoturvallisuutta opetusohjelmiinsa. Ainakin TKK:lla sovellustietoturvallisuus on melko tuntematon käsite. Lähimpänä tätä aihepiiriä olevat tietoturvallisuuden kurssit keskittyvät vielä verkkoprotokollatasolle.

Sovellustietoturvallisuuteen perehtyminen kannattaa aloittaa OWASPin sivuilta. OWASP (Open Web Application Security Project) on voittoa tavoittelematon organisaatio, jonka tarkoituksena on kasvattaa tietoisuutta ja kehittää sovellusturvallisuutta. Vapaasti kaikkien käytettävissä oleva ASVS (Application Security Verification Standard) on OWASPin ensimmäinen standardi. Standardissa kuvattuja vaatimuksia voidaan käyttää esim. sovelluksen turvallisuusvaatimuksia määriteltäessä, ohjeistuksena sovelluksen turvakontrollien toteutuksessa tai arvioitaessa jo valmiin sovelluksen tietoturvallisuuden tasoa.

Kirjoittajasta:

Inspect-yksikön vetäjä Petteri Arola aloitti vuoden alussa OWASP:n Suomen alajaoksen OWASP Helsinki Chapterin vetäjän tehtävässä.