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