Lisää ketterää turvallisuutta
Aiemmin pitämieni ketterien menetelmien ohjelmistoturvallisuusesitysten jatkoksi on nyt tullut vähemmän tietoturvakeskeiselle yleisölle suunnattu, suomenkielinen esitys ketterästä ohjelmistoturvallisuudesta. Tämä on pidetty AKVAn seminaarissa 29. syyskuuta.
Takarivistä kuuluu usein haukotus, joka on ansaittua palautetta. Prosessimalleja on helppo heitellä sivusta, mutta paholainen onkin todella pesiytynyt yksityiskohtiin, eikä yksi prosessi kesää tee. Nämäkin ehdotukset tulisi aina ymmärtää turvallisuutta edistävinä menetelminä. Ne eivät missään tapauksessa ratkaise ohjelmiston tietoturvaongelmia. Samaten on pidettävä mielessä, että prosessien käytännön seuraaminen on joka tapauksessa vaillinaista, vaikka ketteriä koutseja olisi palkattu firmaan läjäpäin.
"Ideologisesti puhtaasta" ketterästä tai hoikasta mallista lähteminen on kuitenkin tärkeää prosessimäärittelyssä sen vuoksi, että puhdasta mallia on aina helpompi sovittaa eri tavoin saastuneisiin käytäntöihin kuin ottaa jo jollakin toisella tavalla saastunut malli käyttöön omassa organisaatiossa. Puhtaat mallit kun saastuvat yleensä yrityksen vallitsevien käytäntöjen vuoksi ja nämä käytännöt vaihtelevat yrityksestä toiseen. Esimerkiksi tuotteen omistaja, product owner, on oikeastaan jonkinlainen antropomorfinen kuvaus kaikille niille asioille, jotka kunnollisessa softakehityksessä pitäisi tehdä. Koska tällaisia superhenkilöitä on vaikea löytää (ainakaan halvalla), eri firmat toteuttavat tuotteen omistajan roolin eri tavoin - esimerkiksi hajauttamalla vastuita usean henkilön kesken. Tämä tuotteen omistajan roolin tulkinta on sidoksissa yrityksen muuhun organisaatiorakenteeseen, poliittiseen peliin, lasikattojen korkeuteen ja selkäänpuukotuksen asteeseen, HR:n kykyyn rekrytoida ja firman kiinnostavuuteen työpaikkana. Tiettyä tuotteen omistajan roolin toteutusta ei siis voida välttämättä suoraan kopioida firmasta toiseen sellaisenaan.
Yllä mainitussa suomenkielisessä esityksessäni tärkeä havainto on myös se, että ketterissä menetelmissäkin voidaan sortua helposti siihen, että niihin lisätään osia, jotka näyttävät pinnallisesti ketteriltä, mutta eivät olekaan pinnan alla hoikkien periaatteiden mukaisia. Hyvä esimerkki on nk. hardening-sprintti, joka sinänsä kuulostaa ketterältä ("sprintti") ja jonka joku voisi vielä ehkä perustella release train -metodin yhteydessä, mutta todellisuudessa se luo laatuvelkaa.
Oli prosessikehys mikä hyvänsä, yhtä vaatimusta ei tietoturvallisuuden saamiseksi voida ohittaa ja se on koulutus. Sekä tuotteen omistajat että suunnittelijat ja toteuttajat tarvitsevat riittävästi tietoa turvallisuudesta. Suurin osa tästä tiedosta ei kuitenkaan ole sitä kuuluisaa rakettitiedettä, vaan pikemminkin oikeaa, ilkeää mielenlaatua. Koulutuksessa hyvä menetelmä onkin vanha kunnon nuotiopiiri: vanhempi tieteenharjoittaja painaa päänsä hieman alaspäin, varjo peittää otsan ja kuulijat saavat taas kuulla yhden tarinan tietoturvallisuuden juoksuhaudoista.
Other articles in category /Tietsikat/Tietoturva --
Share link





