Tietoturvallinen ohjelmistojen kehitys. Käytäntöjä tietoturvallisuuden huomioimiseen ohjelmistokehitysprosessin eri vaiheissa

Transkriptio

1 Tietoturvallinen ohjelmistojen kehitys Käytäntöjä tietoturvallisuuden huomioimiseen ohjelmistokehitysprosessin eri vaiheissa

2 Johdanto "Meillä on ohjelmistoversion julkistus kahden päivän päästä, voisitko tarkistaan onko tietoturvaseikat kunnossa?" Tietoturvallisuutta ei voi lisätä ohjelmistoon ominaisuutena jälkikäteen, vaan se on määriteltävä ja suunniteltava ohjelmistoon alusta alkaen > Tietoturvallisuuden huomioiminen koko ohjelmistokehitysprosessissa. Tietoturvallisella ohjelmistonkehityksellä tarkoitetaan ohjelmiston suunnittelemista siten, että se toimii oikein pahantahtoisen hyökkäyksen sattuessa suunnitellaan ohjelmisto turvalliseksi varmistetaan että ohjelmisto on turvallinen koulutetaan ohjelmistosuunnittelijat, arkkitehdit ja käyttäjät rakentamaan turvallisuutta

3 Sisällysluettelo Tietoturvallisuuden avainkäsitteitä Erilaisia ohjelmistokehityksen prosessimalleja Tietoturvallisen ohjelmistokehityksen periaatteita Vaatimusmäärittely- ja analyysi Suunnitteluvaiheen dokumentaatio ja tietoturvallisuus Toteutusvaihe tietoturvamielessä Erillinen tietoturvatestausvaihe vai testausta tietoturva huomioiden Käyttöönotto ja ylläpito Lisätietoja

4 Tietoturvallisuuden avainkäsitteitä Käytettävyys Määritelmä: Ominaisuus, että tieto, tietojärjestelmä tai palvelu on siihen oikeutetuille saatavilla ja hyödynnettävissä haluttuna aikana ja vaaditulla tavalla Hyökkäyksiä: palvelun esto hyökkäys palveluun tai palvelimeen esimerkiksi lähettämällä palvelimeen enemmän viestejä kuin se kykenee käsittelemään Eheys Määritelmä: (tietojen tai tietojärjestelmän) aitous, väärentämättömyys, sisäinen ristiriidattomuus, kattavuus, ajantasaisuus, oikeellisuus ja käyttökelpoisuus Hyökkäyksiä: Tietojen väärentäminen muuttamalla, poistamalla ja lisäämällä Luottamuksellisuus Määritelmä: Tietojen säilyminen luottamuksellisina ja tietoihin, tietojenkäsittelyyn ja tietoliiikenteeseen kohdistuvien oikeuksien säilyminen vaarantumiselta ja loukkaukselta Hyökkäyksiä: Tiedon paljastuminen salakuuntelemalla tietoliikennettä tai murtautumalla tietojärjestelmään Todennus Määritelmä: Varmistuminen kohteen todenmukaisuusta, oikeellisuudesta tai alkuperästä Hyökkäyksiä: Huijaaminen, tekeytyminen Kiistämättömyys Määritelmä: tietoverkossa eri menetelmin saatava varmuus siitä, että tietty henkilö on lähettänyt tietyn viestin (alkuperän kiistämättömyys), vastaanottanut tietyn viestin (luovutuksen kiistämättämyys, tai että tietty viesti tai tapahtuma on jätetty käsiteltäväksi Hyökkäyksiä: Kieltäminen

5 Erilaisia ohjelmistokehityksen prosessimalleja Vesiputousmalli Spiraalimalli inkrementaalisen kehityksen malli Extreme programming Mikään tähän päivään mennessä esitetty prosessimalli tai käytäntö ei ole yhtäpitävästi osoittanut tuottavansa tietoturvallista ohjelmistoa Kuitenkin käyttämällä parhaita kehityskäytäntöjä, pystytään merkittävästi parantamaa ohjelmiston turvallisuutta mukaan lukien poikkeuksellisen matalat virheasteet Koska parhaiden kehityskäytäntöjen käyttöönotto vaatii merkittävää koulutusta ja kehityskuria, ei niitä oteta laajaan käyttöön ilman huomiota yrityksen johdolta, asiakkailta, tai lainsaadannöstä.

6 Tietoturvallisen ohjelmistokehityksen periaatteita Mekanismin taloudellisuus: Pidä suunnittelu niin yksinkertaisena kuin mahdollista Turvaa virhetilanteet: Perusta käyttöoikeuspäätökset lupaan ennemmin kuin poissulkemiseen Täydellinen välitys: Jokaisen käyttöoikeuden valtuutus jokaiseen objektiin pitää tarkistaa Avoin suunnittelu: Ei salaista suunnittelua Oikeuksien erottaminen: Aina kun on toteutettavissa, niin suojamekanismi, joka vaatii avaamiseen kaksi avainta, on joustavampi kuin sellainen, joka vaatii käyttöoikeuteen vain yhden avaimen Pienimmät oikeudet: Jokaisen järjestelmän ohjelman ja käyttäjän täytyy toimia pienimmillä mahdollisilla oikeuksilla työnsä tekemiseen. Vähimmät yhteiset mekanismit: Minimoi yhteisen mekanismien määrä enempään kuin yhteen ja kaikista käyttäjistä riippuvaan. Psykologinen hyväksyttävyys: On olennaista että käyttöliittymä suunnitellaan helppokäyttöiseksi niin että käyttäjät rutiininomaisesti ja automaattisesti käyttävät suojamekanismejä oikein. Lähde: Saltzer ja Schroeder, 1974

7 Tietoturvaperiaatteita Suojaa heikoin kohta ensin Rakenna useita puolustuslinjoja Turvaa virhetilanteet Anna sovellukselle vain välttämättömät oikeudet Erottele toiminnallisuudet eri tasoisiin turvatiloihin Yksinkertainen on kaunista ja turvallisempaa (KISS) Huolehdi yksityisyyden suojasta Muista, että salaisuuksien pitäminen on vaikeaa Luota säästeliäästi Käytä testattuja välineitä ja komponentteja Lähde: Viega, McGraw: Building Secure Software, 2002

8 Parhaita käytäntöjä kehityksen eri vaiheisiin Ulkopuolinen katselmus Riski analyysi Riskipohjaiset tietoturvatestit Staattinen analyysi (työkalut) Riski analyysi Penetraatio testaus Väärinkäyttötapaukset Tietoturvavaatimukset Tietoturvamurrot Vaatimukset ja käyttötapaukset Suunnittelu Testaustulokset Testaussuunnitelmat Toteutus Palaute kentältä

9 Vaatimusmäärittely ja -analyysi Uhka-analyysi ja tietoturvatavoitteiden määrittely Riskien hallinta Arkkitehtuurinsuunnittelu kysymyksiä Tietoturvamekanismit ja kerroksittainen arkkitehtuuri Tietoturva sisäänrakennettuna vai tietoturvakerroksen lisääminen Tietoturvapolitiikan määrittely ja vaatimusmäärittely

10 Uhka-analyysi ja tietoturvatavoitteiden määrittely Uhka on mahdollinen tapahtuma, jolla voi olla merkittävä vaikutus systeemin suojattaviin asioihin tai resursseihin. Se on vaara, joka voi johtaa ei haluttuihin seurauksiin. Haavoittuvuus on heikkous, joka mahdollistaa uhan toteutumisen Jokaiselle tunnistetulle uhalle täytyy tehdä jokin vastatoimenpide uhkaa pienentämään Tietoturvatavoitteet ovat korkean tason vaatimuksia uhkien pienentämiseksi Tietoturvatavoitteista saadaan kehitettyä yksityiskohtaisempia tietoturvavaatimuksia Tietoturvatavoitteilla ei välttämättä saada katettua kaikkia uhkia Olettamuksia toimintaympäristön, fyysisen turvallisuuden jne. osalta

11 Uhkien mallittaminen Microsoftin menetelmällä Tunnista suojattavat asiat (varallisuus, tieto, jne.) Luo yleiskuva arkkitehtuurista Pura sovellus paloiksi Identifioi uhat Luokittele uhat STRIDE mallia käyttäen Spoofing = huijaaminen Tampering = peukalointi Repudiation = kieltäminen Information disclosure = tiedon paljastuminen Denial of service = Palvelun esto Elevation of privilige = Käyttöoikeuksien nostaminen Laita uhat järjestykseen käyttämällä DREAD kategorioita: Damage potential: vahinko potentiaali Reproducibility = toistettavuus Exploitability = hyödynnettävyys Affected users = vaikutuksen alaiset käyttäjät Discoverability = havaittavuus Kehitä uhkien lieventamisstrategia vakavimmille uhille

12 Riskien hallinta Turvallisin tietokone on irroitettu verkosta, sitä säilytetään lukitussa huoneessa ja siitä on irroitettu näppäimistö Ei kovin käyttökelponen Täydellistä tietoturvaa ei voida saavuttaa -> tarve riskien hallinnalle Riskien hallinta koostuu: Uhkien identifiointi Suojattavien asioiden identifiointi Riskien priorisointi (todennäköisyys ja vakavuus arvioiden) Riskien pienentäminen vastatoimenpiteiden määrittely, varmentaminen, suunnittelu ja kelpuuttaminen riskien siirtäminen -> vakuutukset Vaatimusmäärittely- ja suunnitteluvaiheessa täytyy dokumentoida tehdyt kompromissit riskien hallinnan näkökulmasta: Toiminnallisuus vaaditut ja jäljelle jäävät resurssit tietoturvallisuuden tarpeisiin Käytettävyys tietoturvallisuus sitä vaikeuttamassa Tehokkuus tietoturvallisuus voi olla hidastava ja kallis tekijä time to market vaikeaa saavuttaa jos halutaan hyvä tietoturvan taso yksinkertaisuus jokainen haluaa sitä, mutta tietoturva voi monimutkaistaa järjestelmää Laadusta pidetään huolta laatu on välttämättömyys tietoturvallisuuden saavuttamiseksi

13 Arkkitehtuurisuunnittelun kysymyksiä Pääasiallinen kontrolloinnin painopiste tietoturvan toteuttamismekanismeiksi Esim. käyttäjän identifiointi tai operaatioiden oikeudet Käyttöjärjestelmissä kontrolloidaan dataa käyttöoikeuksien avulla Sovelluksissa voidaan kontrolloida operaatioida, joita käyttäjällä on oikeus suorittaa Keskitetäänkö tietoturvafunktiot vai hajautetaan ympäri systeemiä tai systeemin komponenttejä Hajautetussa järjestelmässä funktio voi olla levitetty komponentteihin tai keskitetty yhteen komponenttiin Yhden koneen järjestelmässä funktio voi olla hajautettu moduuleihin tai keskitetty yhteen moduuliin Keskitetty mekanismi on helpompi analysoida ja toteuttaa virheettömästi Keskitetty mekanismi voi kuitenkin olla pullonkaula suorituskyvylle

14 Tietoturvamekanismit ja kerroksittainen arkkitehtuuri Tietokoneiden arkkitehtuurit ovat kerroksittaisia, esimerkiksi: Sovelluskerros palvelu/middleware kerros Käyttöjärjestelmä kerros Laitteisto kerros Tietoturvan toteuttavat mekanismit voivat sijaita millä tahansa arkkitehtuurin kerroksella kriteerinä mekanismin tehokkuus, esim. käyttäjien toiminteiden kontrollointi tehokkainta sovelluskerroksella datan pyyhkiminen käyttämättömiltä levylohkoilta tehokkainta käyttöjärjestelmä Kun kerros on valittu, täytyy varmistua kuinka alempia kerroksia suojataan Esim. tietoturvallinen käyttöjärjestelmä vaatii tietoturvamekanismejä niin laitteisto- kuin käyttäjärjestelmäkerrokseltakin Tietoturvallinen sovellus vaatii tietoturvamekanismeja kaikkiin kerroksiin

15 Tietoturva sisäänrakennettuna vai tietoturvakerroksen lisääminen Suorituskyvyn tapaan tietoturva on järjestelmän kiinteä osa ja se pitäisi integroida osaksi järjestelmää alusta lähtien mieluummin kuin lisätä myöhemmin. Peruskäsite tietoturvallisen järjestelmän suunnittelussa ja kehityksessä on referenssimonitori ja sen kelpuuttamismekanismi Referenssimonitori on pääsynvalvontamekanismin kuvaaminen abstraktina koneena, joka valvoo kaikkien subjektien pääsyä kaikkiin objekteihin. Referenssimonitorin kelpuuttamismekanismi on referenssimonotorin toteutus Tietoturvallinen ydin on laitteiston ja ohjelmiston yhdistelmä jolla referenssimonitori toteutetaan Luotettu ydintoiminnallisuus koostuu kaikista järjestelmän tietoturvamekanismeistä (laitteisto, ohjelmisto, valmisohjelmistot), joiden avulla tietoturvapolitiikka toimeenpannaan. Pyritään pitämään luotettu ydintoiminnallisuus mahdollisimman pienenä Helpompi analysoida ja testata. Saadaan suurempi varmuus toiminnallisuudesta Jos tietoturvaominaisuudet lisätään järjestelmään jälkeenpäin, on analysointi ja varmuuden saaminen vaikeampaa Toiminnallisuus hajautettuna eri puolille järjestelmää Suuri ja monimutkainen design Nykytuotteista harvoja on tehty tietoturvallisuuden kannalta oikein. Yleensä turvaominaisuudet on lisätty jälkeenpäin.

16 Tietoturvapolitiikan määrittely ja vaatimusmäärittely Toiminnallisuuden määrittelyssä käytetään hyväksi käyttöskenaarioita Tietoturvallisuuden määrittelyssä kannattaa ottaa avuksi väärinkäyttötapaukset Miten hyökkääjä tietoisesti koettaa käyttää järjestelmää väärin tietoturvapolitiikan rikkomiseksi Menetelmiä politiikan ja vaatimusten määrittelyyn Käytetään soveltuvin osin hyödynnettäviä vaatimuksia tietoturva standardeista kuten Common Criteria Luodaan uusi politiikka uhka-analyysin ja olemassaolevien politiikkojen pohjalta Kuvataan systeemi olemassa olevaan malliin. Jos malli vastaa järjestelmän päämääriin, tämä voi olla toimivampi kuin muiden menelmien käyttö. Tietoturvapolitiikan ja -vaatimusten täydellisyys ja yhtäpitävyys Epäformaali todistus, että järjestelmä kattaa siihen kohdistuvat uhat ITSEC ja Common Criteriasta löytyy metodiikkaa tähän

17 Suunnitteluvaiheen käytäntöjä Suunnitteluvaiheen vikoja löydetään usein testaamalla Suunnitteluvaiheen vikoja on löydettävissä Vaatimusten jäljittämisen ja vastaavuksien hakemisen, analyysin, katselmusten, formaalien todistustekniikoiden, ja epämuodollisten argumenttien avulla (kuten Common Criterian suojausprofiilit ja tietoturvatavoitteet määrittelevät) Kaikki suunnitteluvaiheen suunnittelu- ja virheidenlöytämiskäytännöt edellyttävät hyvää dokumentaation laatutasoa

18 Suunnitteluvaiheen dokumentaatio ja tietoturvallisuus (1/2) Dokumentaation täytyy sisältää kolmen tyyppistä tietoa tietoturvallisuutta varten: 1. Tietoturvafunktiot Yhteenvetomäärittely korkean tason tietoturvafunktioista Kuvaus yksittäisistä tietoturvafunktioista Yhteenveto siitä, miten funktiot toimivat yhdessä Miten vaatimukset katetaan 2. Ulkoisten rajapintojen kuvaus Korkean tason kuvaus ulkoisista rajapinnoista järjestelmälle, komponentitlle, alikomponentille, tai moduulille Komponentin yhteenveto Datan kuvaukset (tietotyypit, tietorakenteet, jne.) Rajapintojen kuvaukset (komennot, systeemikutsut, kirjastofunktiot, API:t, jne.) 3. Sisäinen arkkitehtuuri (komponentit) Järjestelmän sisäisten komponenttien rakenteet ja funktiot Yhteenveto ylätason komponentista Komponentin yksityiskohtainen kuvaus Komponentin merkitys tietoturvallisuuden kannalta

19 Suunnitteluvaiheen dokumentaatio ja tietoturvallisuus (2/2) Matalimman tason suunnitteludokumentaatiossa keskitytään moduulien rakenteen, tietorakenteiden, rajapintojen ja logiikan kuvaamiseen Yhteenveto moduulista Moduulin merkitys tietoturvallisuuden kannalta Moduulin yksittäiset rajapinnat Seuraavan kehitysversion dokumentaatio Muutosspesifikaatio määrittää muutokset olemassa oleviin moduuleihin, funktioihin ja komponentteihin uudet moduulit, funktiot ja komponentit Poistetut moduulit, funktiot ja komponentit Useiden muutosspesifikaatioiden olemassaolo vaikuttaa tietoturvaanalyysiä

20 Toteutus Tietoturvaohjelmointi on oma alansa, eikä sitä huomioida alan koulutuksessa. Ohjelmoidessa täytyy jatkuvasti pitää mielessä mikä voi mennä väärin varsinaisen toiminnallisuuden lisäksi Käytettävä ohjelmointikieli vaikuttaa tietoturvallisuuteen Javassa tietoturva huomioitu, muistinhallinta systeemissa, ei ohjelmoijan harteilla C ja C++ mahdollistavat puskurin ylivuodot ja monen muun tietoturvahaavoittuvuuden Syötteen tarkistaminen puskurin ylivuotojen ja muiden vikaantumisten estämiseksi Valmiiden luotettujen komponenttien käyttö tietoturvaseikat huomioitu valmis kehys ja malli sovelluskehitykseen Testattu ja hyväksi havaittu Katselmusten käyttö ja tietoturvallisuuden huomioiminen niissä erityisesti Tietoturvatarkistuslistojen käyttäminen katselmuksissa Staattisten analysointityökalujen käyttäminen

21 Testaus Lähtökohta: Käyttäjä on pahantahtoinen, sovelluksen väärinkäyttöön kaikkia sääntöjä rikkomaan pyrkivä (R. Anderson ja Roger Needham: Satan s Computer) Kaksi strategiaa Testataan tietoturvatoiminnallisuutta käyttäen hyväksi standardeja testaustekniikoita Riskipohjainen tietoturvatestaus, joka perustuu hyökkäysmalleihin ja uhka-analyysiin Hyvä tietoturvan testaussuunnitelma hyödyntää molempia Penetraatiotestaus on myös hyödyllistä, varsinkin jos testejä johdetaan arkkitehtuurin riskianalyyseistä Jos pelkkää mustalaatikkotestausta ilman ohjelmistoarkkitehtuurin huomioimista, niin ei välttämättä löydetä mitään mielenkiintoista Testauksessa on tärkeää huomoida tietoturvavaatimusten kattaminen Testitapausten johtaminen uhka-analyysi tietoturvavaatimusten testaus hyökkäysmallit tietoturvavaatimusten testaus väärinkäyttötapaukset tietoturvavaatimusten testaus määrittely dokumentaatio toiminnallinen tietoturvatestaus suunnittelu dokumentaatio strukturaalinen tietoturvatestaus Robustisuustestaus: Syntaksitestauksen, vikojen injektoinnin ja penetraatiotestauksen yhdistelmä Kohinatestaus: Satunnaisen syötteen käyttö

22 Käyttöönotto ja ylläpito Käyttöönotossa tietoturvalliset, kovennetut ja dokumentoidut asetukset Käyttöjärjestelmistä, sovelluspalvelimista ja tietokannoista turhatoiminnallisuus ja oletusarvoiset käyttäjätunnukset pois jo asennusvaiheessa Tietoturvalliset asennukset edellyttävät suunnittelua ja hyviä ohjeita Hyvä dokumentaatio ja suunnitellut käytännöt ylläpitoon ja tietoturvakorjausten asentamiseen

23 Lisätietoja Matt Bishop: Computer Security, Art and Science, 2003 Chapter 19: Building Systems with Assurance John Viega, Gary McGraw: Building Secure Software, 2002 Gary McGraw: Software Security, IEEE Security & Privacy, 2004 Improving Security Across the Software Development Life Cycle, 2004 Task force report, US National Cyber Security Partnership Ross Andersson: Security Engineering, 2001

24