Ohjelmiston kehityksen menettelyjä (2-A)

Yleisemmässä tekstissä? on todettu, että ohjelmistojen turvallisuutta voi edistää hyvillä ohjelmoinnin periaatteilla, testauksella ja jossain määrin myös todistamisella. Tässä on hieman laajempi tiivistelmä ohjelmistojen kehittämiseen liittyvistä hyvistä menettelyistä Pfleegerien kirjaa [ PflP02? ] ja FIPS-ohjeistoa? mukaillen.

  1. Ohjelmiston hyvä suunnittelu ja rakenne
    • johdonmukainen virheiden käsittely: esim. jokin seuraavista, kun virheen jälkeen on ensin palattu aiempaan tilaan: uusi yritys eri tavalla -- jokin korjaus ja uusi yritys samalla tavalla -- raportointi ja yrityksestä luopuminen.
    • vikaantumisen vaikutusten rajoittaminen (fault tolerance)
    • hyväksi havaittujen käytäntöjen soveltaminen (kaikkea yleisistä periaatteista, kuten modulaarisuus, pieniin käytäntöihin, kuten muuttujien määrittelyn yhteydessä ilmaistu käyttöön tuleva vaihteluväli tai liukulukuvertailujen välttäminen)
    • modulaarisuus, ohjelmapalasten ominaisuuksia:
      • yksi tehtävä, joka on dokumentoitu myös koodiin
      • pieni koko, ihmisen ymmärrettävissä
      • yksinkertaisuus, esim. ohjelmointirakenteina vain peräkkäisyys, if-then-else, case sekä rakenteiset silmukat.
      • riippumattomuus, tehtävän irrallisuus useimmista muista: löyhäkytkentäisyys moduulien välillä ('loose coupling')
      • kapselointi, erityisesti vain yksi sisäänmenokohta, enintään kaksi ulostulokohtaa (normaali ja virhetilanne)
      • tiedon kätkentä, paikalliset muuttujat ja kommunikointi parametrien ja return-arvojen kautta, joiden "laillisuuden" vastaanottaja tarkastaa jos mahdollista.
    • hierarkkisuus: useista moduuleista kootaan isompi moduuli, joka niinikään toteuttaa em. ominaisuudet. Tätä toteuttaa myös kommunikoinnin ja palvelujen tarjoamisen kerroksellinen rakenne, joka on tyypillinen käyttöjärjestelmissä ja tietoliikenneprotokollissa. Ei tarkoita moninkertaista sisäkkäisyyttä kontrollirakenteissa.
  2. Ohjelmistoprosessi
    • suunnittelussa käytettyjen valintaperusteiden (myös valitsematta jättämisten) ja muiden periaatteiden taltiointi. Aiempien ratkaisujen seurauksien tarkastelu ja silloin tehtyjen virheiden välttäminen.
    • staattinen analyysi, katselmointi omin voimin ja osittain automaattistenkin metriikkojen avulla: kontrollivuo, tietovuo, tietorakenteet. Esim. jokaiseen ohjelmasilmukkaan pitäisi liittyä (myös koodin kommenttina) vakuuttava perustelu sille, että suoritus joskus päättyy.
    • vertaisarvioinnit ('peer reviews'), katselmoinnit, joissa tarkastelija on muu kuin tekijä, kallista mutta tehokasta.
    • haavoittuvuuksien analyysi, systemaattisia tekniikoita kahteen suuntaan:
      • millä tavoin voisi syntyä kuviteltu tilanne x (´'fault tree analysis')
      • jos y menee pieleen, mitä laajempaa siitä seuraa ('failure modes and effects analysis'); myös riskianalyysin piirre: jos riski on tarpeeksi pieni, voidaan keskittyä muuhun.
    • testaus; yksi vaihejaottelu: moduulit. -- integraatiot. -- toiminnallisuust. -- suorituskykyt. (tässä ja edellisessä tulevat esiin turvavaatimukset) -- hyväksymist. (asiakkaan näkökulma) -- asennuksen t. -- regressiot. (kun on tehty uudistuksia). Testauksen ja muiden arviointien vaiheistus ja menetelmien monipuolisuus erilaisuus tärkeää; samoin henkilöiden erilaisuus, jotta kukaan ei pääsisi ujuttamaan ohjelmaan takaportteja yms. Tähän auttaa myös seuraava.
    • konfiguraation hallinta: kuka tekee mitä muutoksia mihin ja milloin (ja onko siihen oikeudet ja onko muutos turvallinen). Ohjelmiston suoraviivaisen kehityksen lisäksi voi olla rinnakkaisia versioita esim. eri alustoille.
    • ohjelman formaali verifiointi. Tällainen vaatimus esiintyy mm. TCSEC-standardissa? .

TTY:llä on runsaasti kursseja ohjelmistotuotannon alueelta. Esimerkiksi testauskurssin? materiaalista voi saada käsityksen, miten monia asioita voidaan ja pitää ottaa huomioon. Käytännön ohjelmistotuotannossa ja varsinkin -liiketoiminnassa esiintyy yhä monia sellaisia käytäntöjä, jotka heikentävät tietoturvan mahdollisuuksia. "Löydä ja paikkaa" -sykli on yksi tällainen. Siitäkin on yritetty löytää hyviä puolia motivoimalla reikien löytämistä ja raportointia palkkioilla. Näiden struktuuria kehittelee (edelleen) Andy Ozment artikkelissaan Bug Auctions: Vulnerability Markets Reconsidered (2004)?. Tällä alalla käydään kyllä myös pimeää kauppaa, mutta sen tavoite on toinen. Turvallisen ohjelmoinnin piirteitä käsitellään erikseen? . Aiheesta on TTY:llä vuodesta 2008 alkaen ollut myös kurssi ohjelmistotekniikan seminaarisarjassa. Aihe on yhä enemmän esillä myös julkisuudessa, esimerkkinä Tietotekniikan liiton ja Tietoturva ry:n järjestämä turvallisen ohjelmistokehityksen seminaari? syksyllä 2008.

-- JukkaKoskinen?

SivuTiedotLaajennettu edit

Vaativuus Perus
Valmius Valmisteilla
Tyyppi Ydin
Luokitus Uhkat
Mitä Luottamuksellisuus
Miltä Ihmisetön uhka
Missä Organisaatio
Kuka Tite-ammattilainen
Milloin Ennakolta
Miksi Hyvä tapa
Print version |  PDF  | History: r2 < r1 | 
Topic revision: r2 - 26 Sep 2010 - 11:10:30 - MarkoHelenius
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback