TigerTeam - suomalainen tietoturvablogi

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ä.

Tämä blogikirjoitus on tiivistelmä OWASP Helsingin alajaoksen 17.11. järjestetyssä tilaisuudessa pitämästäni esityksestä Manuaalinen ja automaattinen koodianalyysi (Manual vs. Automated Code Analysis). Englanninkielinen esitys on ladattavissa myös jaoksen verkkosivuilla.

Sovellustietoturvan tarkistus voidaan jakaa neljään osa-alueeseen, sen mukaan onko tarkastus dynaamista vai staattista ja tehdäänkö tarkastus automaattisesti vai käsin. Tässä tarkastellaan vain staattisen eli koodiin perustuvan tarkastuksen eroja, ulkopuolelle jäävät siis pentestit yms.

Automaattinen koodin skannaus voi perustua monenlaiseen lähestymistapaan, yksinkertaisimmillaan pelkkään tekstimatchaukseen ja monimutkaisimmillaan koko koodin jäsentämiseen ja analysointiin tai jopa tilastollisiin menetelmiin. Ääripäiden väliin jää token matching, syntaksipuuhun perustuva haku (jolloin analysaattori ymmärtää erottaa esim. funktiokutsut ja muuttujat toisistaan), ja data flow analyysi.

Käsin koodin läpikäynti voi tapahtua hyvin monella tavalla, mutta tyypillisiä lähestymistapoja ovat mm. tiettyjen merkkijonojen etsiminen (työkalulla), hyökkäyspinnan selvittäminen ja tarkastelu, input/output-polkujen ja komponenttikirjastojen konfiguraation tarkastelu, autorisointilogiikan ja esimerkiksi hyväksymissääntöjen validointi ja ennen kaikkea arkkitehtuurin analysointi mm. sisäisten rajapintojen osalta. Luonnollisesti käytössä ovat myös erilaiset tarkistuslistat.

Automaattisen analysoinnin etu on kiistatta se, että se on huomattavasti nopeampaa, laaja-alaisempaa (ainakin katetun koodin mielessä) ja toistettavaa. Automaattisesta analysoinnista saatavat tulokset on kuitenkin jonkun aina tulkittava ja arvioitava löydöksistä:

• mitkä ovat todellisia löydöksiä eli oikeita haavoittuvuuksia?
• mitkä ovat vääriä hälytyksiä?
• miten paljon haavoittuvuuksia jäi löytymättä?

Lisäksi todellisten löydösten korjaukset täytyy suunnitella, mihin työkalu joko antaa tai ei anna hyvää suositusta.

Application Security Verification Standard (ASVS)

OWASP:n Application Security Verification Standard eli ASVS määrittää vaatimukset eritasoisille sovellustietoturvan tarkistuksille. Se koostuu neljästä tasosta, joista ensimmäinen kattaa pintapuolisen tarkistuksen ja neljäs taso edellyttää jo hyvinkin perusteellista tarkastusta.

Karkeasti ottaen ASVS:n ensimmäinen taso voidaan toteuttaa automaattisilla (staattisilla ja dynaamisilla) työkaluilla, joskin niiden antamat tulokset täytyy käydä käsin läpi. Toiselle tasolle päästäkseen sovellus tulee käydä manuaalisesti läpi, dynaamisesti (käsin testaamalla) ja/tai staattisesti (käsin katselmoimalla). Kolmas ja neljäs taso syventävät käsin tehdyn katselmoinnin vaatimuksia. Työkalujen käyttö on sallittu muillakin kuin ensimmäisellä tasolla, mutta silloin ne toimivat vain käsin tehtävän tarkastuksen apuna.

ASVS:ssä on 14 vaatimusosa-aluetta, mm. autentikaatioon, syötteen validointiin, tiedon suojaamiseen ja lokitukseen liittyen. Näille vaatimuksille on tarkemmat sisältömääritykset, joista kunkin kohdalta on mainittu, miltä osin tarkastusvaatimus sisältyy millekin ASVS:n tasolle, ts. käytännössä onko sen katsottu voitavan tehdä automaattisesti vai käsin ja dynaamisesti vai staattisesti.

Semitieteellisesti tarkasteltuna, kun verrataan ASVS:n tasoille 1B (eli automaattinen koodin skannaus) ja 2B (eli käsin tehtävä koodin läpikäynti) asetettuja vaatimuksia, havaitaan että taso 2B sisältää huomattavasti enemmän tarkastuskohteita. Nämä ovat käytännössä sellaisia, joihin ei automaattinen työkalu edes pure, esimerkkinä:

• V2.5 Verify that all authentication controls (including libraries that call external authentication services) have a centralized implementation.

• V2.13 Verify that account passwords are salted using a salt that is unique to that account (e.g., internal user ID, account creation) and hashed before storing.

• V14.2 Verify that security control interfaces are simple enough to use that developers are likely to use them correctly.

Toisaalta taas, automaattinen työkalu kelpuutetaan tarkastamaan seuraavat asiat lähdekoodista:

• V5.2 Verify that a positive validation pattern is defined and applied to all input.

• V6.1 Verify that all untrusted data that are output to HTML (including HTML elements, HTML attributes, JavaScript data values, CSS blocks, and URI attributes) are properly escaped for the applicable context. (Saattaa onnistua ns. tekstimatchingiin perustuvilta työkaluilta.)

• V11.2 Verify that the application accepts only a defined set of HTTP request methods, such as GET and POST. (Vaatii työkalulta ymmärrystä konfiguraatiosta, esim. Struts tai Spring MVC.)

Automaattisen koodin skannauksen ongelmakohtia

Yleisesti ottaen automaattiselle koodiskannerille ongelmia tuottavat mm. big picturen katsominen ja arkkitehtuurin selkeyden ja turvallisuuden arviointi, ei-toiminnalliset vaatimukset (esim. kuinka hyvin järjestelmä sietää kuormitusta ja DoS-hyökkäyksiä), loogiset virheet esimerkiksi autorisoinnissa, tai puuttuvat tietoturvavaatimukset tai niiden toteutus.

Skannausta hankaloittaa tietysti myös koodi, joka on osa järjestelmää jollain epätavallisella tavalla, esim. plugin, sekä järjestelmän konfiguraation tulkinta, erityisesti kun käytössä on jokin framework kuten Hibernate, Spring, Wicket yms.

Johtopäätökset

Loppupäätelmänä ei voi tietysti sanoa, että jompi kumpi koodin analysointitapa olisi ainoa oikea, mutta ne tukevat toisiaan ja sopivat eri tilanteisiin. Tapojen painotuksessa on syytä pohjata päätös järjestelmän luonteeseen ja riskianalyysiin. Esimerkiksi web-portaalin ohjelmakoodi voidaan saada melko hyvinkin skannattua automaattisesti, mutta monimutkaisen extranet-sovelluksen logiikan monimutkaisuus ja riskit saattavat olla liian suuria automaattiselle työkalulle jätettäväksi.

On siis hyvä tiedostaa, että automaattinen analyysi ei useinkaan anna kovin täydellistä raporttia tietyntyyppisistä ongelmia, ja lisäksi ihmistyötä tarvitaan aina tulosten analysointiin. Toisaalta taas käsin tehtävä läpikäynti voi hyötyä suuresti automaattisten työkalujen kaivamista alustavista tuloksista.

Web-sovellusten tietoturvaa seuraava Web Application Security Consortium on julkaissut päivitetyn version yleisesti käytössä olevien sovellusten tietoturvatilannetta kuvaavasta Web Application Security Statistics -raportistaan. Raportin perustana olevat tiedot on kerätty yli 12 000 web-sovelluksesta sekä testaamalla niitä automaattityökaluilla että analysoimalla sovelluskoodia yksityiskohtaisesti.

Sovelluksista löytyi lähes 100 000 erilaista haavoittuvuutta ja muuta tietoturvaongelmaa. Yleisimmät ongelmatyypit ovat alttius erityyppisille cross-site scripting -hyökkäyksille, jota havaittiin 39 prosentissa analysoiduista sovelluksista, sekä taipumus vuotaa käyttäjälle kuulumatonta tietoa, mihin syyllistyi 32 prosenttia sovelluksista.

Haavoittuvuuksia aiheuttavat sekä ohjelmointi- että järjestelmänhallinta- ja asennusvirheet tasapuolisesti. 57 prosentissa sovelluksista löytyi huolimattomasta toteutuksesta johtuvia haavoittuvuuksia, ja www-osoitteiden perusteella peräti 85 % toimivista järjestelmistä osoittautui tavalla tai toisella puutteellisesti asennetuksi tai konfiguroiduiksi. Vain yksi prosentti tarkastetuista sovelluksista oli täysin PCI DSS -standardin tietoturvamääritykset täyttäviä.

Automaattinen hyödyntäminen helppoa

Huolestumiseen antaa aihetta tieto, että 13% sovelluksista oli sellaisia, joiden tietoturva-aukkoja on mahdollista hyödyntää täysin ohjelmallisesti. Niitä vastaan voi siten hyökätä automaattisesti osoiteavaruutta läpikäyvällä ohjelmalla, joka tunnistaa haavoittuvuudet ja murtautuu niiden avulla sovelluksiin.

Vaikka yleisimmät haavoittuvuudet voidaan myös havaita automaattisesti noin puolessa tapauksista, valtaosa vakavimmista, PCI DSS -luokituksen mukaan Urgent- tai Critical-tyyppisistä ongelmista paljastui vasta käsin testaamalla ja ohjelmakoodia analysoimalla.

Raportin julkaisseeseen konsortioon kuuluu useita johtavia tietoturvayrityksiä, muun muassa HP Application Security Center, Positive Technologies, Whitehat Security ja Veracode. Raportti on luettavissa tässä osoitteessa.

PCI-tietoturvastandardin vaatimus 6.6, joka tähän asti on ollut ainoastaan suositus, muuttuu pakolliseksi tänään 30.6. Vaatimus 6.6 käsittelee web-sovellusten suojausta, joka voidaan toteuttaa kahdella pääasiallisella tavalla: koodikatselmoinnilla tai web-sovelluspalomuurilla.

Koodikatselmointi ei välttämättä tarkoita manuaalista työtä, vaan sen voi toteuttaa myös automaattisilla siihen tarkoitetuilla työkaluilla. Katselmoinnin voi suorittaa kuka tahansa riittävät taidot omaava henkilö yrityksen sisältä tai ulkoa. Mikäli yritys tekee katselmoinnin sisäisesti, tulisi katselmoijan kuitenkin olla organisatorisesti eriytetty web-sovelluksen omistajista/tekijöistä.

Web-sovelluspalomuuri (Web Application Firewall, WAF) on vaihtoehtoinen tapa täyttää tämä PCI-vaatimus. WAF tulee asettaa web-sovelluksen ja asiakkaan (client) väliin niin, että se muodostaa yhden suojauskerroksen lisää perinteisten palomuurien lisäksi sovelluskerrokselle. WAF:n tulisi pystyä reagoimaan tunnettuihin web-hyökkäyksiin kuten niihin, jotka on kuvattu OWASP Top 10:ssä ja PCI-vaatimus 6.5:ssä.

Kannattaa huomioida, että vaikka yritys auditoitaisiin seuraavan kerran esimerkiksi vasta puolen vuoden päästä, on vaatimus 6.6 kuitenkin pakollinen jo tänään.

PCI Council:in hyvä tietopaketti aiheesta löytyy täältä (pdf).