Ketterä ohjelmistokehitys unohtuiko tietoturva?

Transkriptio

1 Ketterä ohjelmistokehitys unohtuiko tietoturva? Kimmo Toro Protecting the irreplaceable f-secure.com

2 F-Secure Yritys Perustettu vuonna 1988, listautui NASDAQ OMX Helsinki Oy:ön vuonna 1999 Pääkonttori Helsingissä, 18 maatoimistoa, läsnä yli sadassa maassa 812 työntekijää, yli 300 tuotekehityksessä, viisi tuotekehityskeskusta neljässä eri maassa, ketterät ohjelmistokehitysmenetelmät käytössä vuodesta 2003 Tuotteet ja palvelut Internet tietoturva: haittaohjelmasuojaus, roskaposti- ja verkkohuijaussuodattimet, palomuuri, selauksen suojaus, lapsilukko Sisällön suojaus: varmuuskopiointi, kadonneen/varastetun puhelimen paikannus Reaaliaikainen tiedon varastointi ja palvelut: tallennusalusta, jakaminen, sosiaalisen median käyttö Useita eri käyttöjärjestelmäalustoja: Windows, Mac, Linux, mobiili, yli 20 kieliversiota Asiakkaat Kuluttajat (vähittäis- ja jälleenmyynti, internet-kauppa), miljoonia koteja Verkko-operaattorit (Internet palveluntarjoajat, mobiilioperaattorit), maailmanlaajuisesti markkinajohtaja tällä osa-alueella yli 200 operaattorilla Yritykset F-Secure Public

3 Suomalaisen ohjelmistoteollisuuden kilpailukyvyn tekijät vuonna 2015 Pilviliiketoiminta Kilpailukyvyn tekijät: - Oikea business - Oikeat teknologiat - Oikea organisaatio - Oikea ajoitus Pilviteknologiat Lean&Agile ohjelmistoyritys 3

4 Cloud Software ohjelma pähkinänkuoressa Laaja, 70+MEUR ( ), teollisuusvetoinen tutkimushanke (ICT-SHOK Tivit -salkussa) Vuonna 2009 tehdyn laajan kartoitustyön perusteella merkittävimmät tekijät kilpailukyvyn parantamisessa ovat operatiivinen tehokkuus, käyttäjäkokemus, web-ohjelmistot, avoimet järjestelmät, tietoturva sekä kestävä kehitys. Cloud Software haluaa olla edelläkävijä erityisesti pilviteknologiaan liittyvien liiketoimintamallien ja ohjelmistoinfrastruktuurin kehittämisessä. Lisäksi tavoitteena on synnyttää uusia, nopeasti kasvavia yrityksiä pilviteknologian ja palvelujen saralla. F-Secure on Cloud Software ohjelman veturiyritys Janne Järvinen on ohjelman vetäjä ja yhteyshenkilö Yritysosapuolet: CSC, Digia, ECE, Elektrobit, Ericsson, F-Secure, Gearshift, IPSS, IT Mill, Ixonos, NetHawk, Nokia, NSN, Packet Video Finland, Reaktor, RM5,TeliaSonera, Tieto, Vincit, VividWorks Tutkimuspartnerit: Aalto, HY, JyAMK, JyU, OY, TTY, VTT, ÅA Suomalaisen ohjelmistoteollisuuden kilpailukykyä vahvistamassa tavoitteita: Ylivertaisen käyttäjäkokemuksen kautta parantunut globaali kilpailukyky Merkittävästi nopeutuneisiin jaksoaikoihin (cycle-time) perustuva parantunut toiminnan kokonaistehokkuus Tulevaisuuden pilviliiketoimintaan valmistautuminen Uusien pilviekosysteemien luominen ja käytännön hyödyntäminen 4

5 Perinteinen ohjelmistokehitys (vesiputousmalli) Tuotepäällikkö Vaatimusten määrittely Tietoturva-analyysi Toiminnallisuus Käytettävyys Luotettavuus Suorituskyky Tuettavuus Tietoturva Arkkitehtuurin suunnittelu Tietoturvaarkkitehtuuri Projektisuunnitelma Resursointi Liiketoiminta-analyysi jne. Osien suunnittelu Tietoturvasuunnittelu Tekninen toteutus Projektin ohjausryhmä Arkkitehtuurisuunnitelma Tekninen analyysi Käyttöliittymäsuunnitelma Tietoturvatavoite Tietoturvallinen koodaus Testaus Tietoturva testaus Mahdollinen auditointi Käyttöönotto 5

6 Ketterä ohjelmistokehitys (scrum) Tuoteominaisuus Toteutusvaiheen työlista 24h Päiväpalaveri á 15min Tuoteomistajan priorisoima tuotteen työlista Esim. Kaksi viikkoa Toteutusvaihe Tiimeillä vapaus suorittaa työnsä parhaaksi katsomillaan tavoilla OK? Kyllä Ei Julkaisuvalmis tuotteen osa Mukaellen kirjasta Agile software development with Scrum (kirjoittanut: Ken Schwaber & Mike Beedle) 6

7 Ongelma? 7

8 Ketterä ohjelmistokehitys (scrum) Tuoteominaisuus Toteutusvaiheen Oletus 2: työlista Tiimi sisällyttää tietoturvan toteuttamiinsa 24h tuoteominaisuuksiin. Esim. Kaksi Oletus 1: viikkoa Tuoteomistaja osaa Tuoteomistajan pyytää tietoturvaominaisuuksia. priorisoima tuotteen työlista Toteutusvaihe Lopputulos: Tuoteomistaja saattaa Päiväpalaveri á 15min OK? Kyllä Ei Julkaisuvalmis hyväksyä kartoittamattomia tuotteen osa tietoturvariskejä. Mukaellen kirjasta Agile software development with Scrum (kirjoittanut: Ken Schwaber & Mike Beedle) 8

9 Oletus 1: Tuoteomistaja osaa pyytää tietoturvaa Tuoteomistaja tekee korkean tason uhka-analyysin (riskianalyysi, uhkamallinnus) tunnistaakseen mahdolliset liiketoimintariskit Tuoteomistaja priorisoi löydetyt riskit sekä määrittelee niille arvon liiketoiminnan kannalta Tuoteomistaja kirjoittaa tuotteen ominaisuuksille turvallisuuskertomukset sekä väärinkäyttökertomukset Tuoteomistaja teettää tarvittaessa teknisen uhka-analyysin tiimillä. Scrumissa tämänkaltaista selvitystehtävää kutsutaan nimellä research spike. Tuoteomistaja pyytää kehitystiimejä esittämään tuotteen ominaisuuksiin liittyvän jäännösriskin jokaisen toteutusvaiheen lopussa 9

10 Oletus 2: Tiimi sisällyttää tietoturvan tekemisiinsä Tiimi tunnistaa uhka-analyysin tarpeen toteutusvaiheen suunnittelun aikana Tiimi tekee tarvittaessa uhka-analyysin tuotteen ominaisuuksille ja toteuttaa tarvittavat kontrollit riskien pienentämiseksi Tiimillä on käytössään tarvittava osaaminen sekä työkalut tietoturvariskien tunnistamiseksi Tiimi testaa tuotteen ominaisuudet perusteellisesti myös tietoturvan kannalta Tiimi kommunikoi tuoteomistajalle löydetyt tietoturvariskit sekä näiden minimoimiseksi tarvittavat kontrollit, joista tehdään uusia vaatimuksia tuotteelle Tiimi arvioi toteutusvaiheen lopussa tuotteen ominaisuuksiin liittyvän jäännösriskin ja kommunikoi tämän tuoteomistajalle 10

11 Miten tämä ennen toimi? Vesiputousmallissa aina vaiheesta toiseen siirtyessä käydään läpi pääsykriteerit seuraavalle vaiheelle Mikäli kriteerit eivät täyty, ei seuraavaan vaiheeseen voida siirtyä (esim. Tuotekehityksestä testaukseen) Kriteeristön täyttymistä valvoo projektin ohjausryhmä, ei ainoastaan yksi ihminen Prosessiin on yleensä kirjattu dokumentaatio (esimerkiksi tietoturvatavoite tai tietoturva-analyysin tulokset), joka tuotekehittäjien pitää toimittaa projektin ohjausryhmälle päätöksen tekemistä varten Jokaisessa prosessin osassa on määritelty tietoturvan varmistavat tehtävät, analyysi, arkkitehtuuri, suunnittelu, koodaus, testaus Selkeää ja yksiselitteistä ainakin teoriassa 11

12 Miten tämä saadaan (taas) toimimaan? Prosessi (esim. Scrum) on harvoin itsessään ongelma Tietoturva voidaan sisällyttää tuotekehitysprosessien olemassaoleviin osiin ilman isompia muutoksia Ketterät tuotekehitysmenetelmät antavat tiimeille vapauden ja vallan tehdä tai olla tekemättä tiettyjä asioita Mikäli asioita ei koeta tarpeeksi tärkeiksi tai arvoa lisääviksi, jäävät ne helposti tekemättä Tietoturva tulee sisällyttää myös osaksi laadunvarmistusta 12

13 Tietoturva eri roolien kannalta Tietoturva ei ole helppoa tarvitaan koulutusta sekä tietoisuuden lisäämistä Tuoteomistajat ovat erittäin tärkeässä roolissa! Olisi hyvä, jos jokaisessa tiimissä olisi ainakin yksi aidosti tietoturvasta kiinnostunut henkilö Tiimien tulisi sisällyttää tietoturvaan liittyvät kontrollit osaksi valmiuden määritelmäänsä (definition of done) 13

14 Tietoturvavaatimukset Tietoturvavaatimusten tunnistaminen ja priorisointi on erittäin tärkeää sisällyttää vaatimustenhallintaprosessiin Tuoteomistajien pitää tunnistaa tuotteiden ominaisuuksiin liittyvät liiketoimintariskit Tuoteomistajien pitää tarvittaessa teettää uhkaanalyysejä tiimeillä Tiimeillä pitää olla mahdollisuus suorittaa uhka-analyysi tuotteen ominaisuudelle myös ilman tuoteomistajan erillistä päätöstä 14

15 Jäännösriskin hyväksyminen Jäännösriskin hyväksyminen pitää olla tietoinen päätös Tiimi voi hyväksyä teknisen jäännösriskin Tuoteomistaja voi hyväksyä tuoteriskin Tunnistettujen tietoturvariskien käsittelyn tulee olla tietoista ja nopeaa Aika tietoturvariskin havaitsemisesta sen käsittelemiseen pitää olla mahdollisimman lyhyt Tietoturvariskin käsitteleminen voi tarkoittaa myös sitä, ettei asialle tehdä mitään. Mutta tämän pitää olla tietoinen päätös. 15

16 Feature Feature Feature Feature Feature Product Feature Feature Feature Backlo Feature Feature g Feature Feature Feature Threat Analysi s Security Features Backlog Grooming Feature Risk Acceptance External Vulnerability Testing? Release Decision Abuse Stories User Stories Acceptance Tests Development Iteration Architecture Threat Analysis Iteration Review Residual Risk Acceptance Escalate Residual Risk (to PdO) Security Review of Critical Components Automated Code Analysis Security Engineering Security Testing Secure Design & Coding Technical Risk Acceptance

17 Lisää aiheesta Pidempi ja yksityskohtaisempi esitys ohjelmistoturvallisuudesta ketterässä tuotteenhallinnassa (Antti Vähä-Sipilä / Nokia): gmt_by_vaha-sipila.pdf Hoikkaa ja ketterää ohjelmistoturvallisuutta (Antti Vähä-Sipilä / Nokia): Agile security: The Devil's Advocate (Camillo Särs / F-Secure): sadvocate_ pdf?version=2

18