Tietoturvallisuuden varmistamiseksi eivät riitä pelkästään tehokkaat kryptografia-algoritmit ja suurimmat uhat muodostuvatkin ohjelmistojen heikkouksista: saatavien syötteiden kelvollisuutta ei tarkasteta, epäluotettavien kirjastofunktioiden käyttö ja niin edelleen. Haavoittuvuuksiin voidaan suhtautua kolmella tavalla:
Ensimmäisestä vaihtoehdosta esimerkkinä voidaan pitää Javan käyttöä toteutuskielenä C/C++:n sijasta. Kahden viimeksimainitun kielen ongelmana ovat juuri puskurien ylivuodot ja virheelliset muistiviittaukset. Javassa tällaisia ongelmia ei ole, vaan virtuaalikone huolehtii kaiken muistin käsittelyn. Ongelmana ovat kuitenkin itse virtuaalikoneen mahdolliset haavoittuvuudet.
Haavoittuvuuksien eliminoinnissa on ongelmana haavoittuvuuksien löytäminen: koodin monimutkaisuus ja koko ovat suhteessa sen sisältämään mahdolliseen virhemäärään.
Haavoittuvuuksien sietämisestä esimerkkinä palomuurit (firewall), joka rajoittaa kommunikointia järjestelmän ulkopuolen kanssa ja tunkeilijoiden havaitseminen/torjunta (intrusion detection).
Seminaariesitelmä keskittyy tapaan kaksi
Edes virheetön suunnittelu ei pelasta toteutustason uhilta, joihin mm. edellä mainitut uhat kuuluvat. Toteutustason haavoittuvuuksia on kuitenkin helpompi havaita niiden yksiselitteisyyden takia kuin suunnittelutason. Työvälineitä haavoittuvuuksien automaattisen havaitsemiseen toteutustasolla on useita ja ne voidaan jaotella useiden ominaisuuksien ominaisuuksien mukaan: onko lähdekoodi tarpeellinen, onko testaus funktionaalista, analysoidaanko rakennetta staattisesti vaiko dynaamisesti ja niin edelleen.
Esitelmä seuraavaksi esitettävään menetelmään. Jokaisesta tullaan esittämään toimintaperiaate/logiikka sekä menetelmälle pohjautuva työkalu. Ainakin kahdesta ensimmäisestä esitetään myös käytännön sovellusesimerkki.
Eliminointia varten tarvitaan haavoittuvuusanalyysia, jota voidaan soveltaa sekä koko järjestelmään että yksittäisiin komponentteihin. Se voidaan tehdä lähdekoodille (staattinen) tai tarkkailemalle systeemin/komponentin käytöstä (dynaaminen). Lähdekoodien ja yksittäisten komponenttien analysoinnissa ongelmana ovat nk. väärät positiiviset (false positives): lauseesta annetaan varoitus, vaikka se ei sisällä mitään todellista vaaraa. Virheiden syöttöä voidaan tehdä sekä staattisesti (muunnetaan lähdekoodia) että dynaamisesti syötetiedoille. Näin saadaan tietoa ohjelmiston robustiudesta eli kyvystä reagoida poikkeuksillisiin tilanteisiin.
Ominaisuustestauksessa testataan että tietyt ominaisuudet pysyvät aina voimassa. Menetelmässä koodi viipaloidaan (slicing) tietyn ominaisuuden suhteen mikä tarkoittaa ominaisuuden kannalta epäoleellisten lohkojen hylkäämistä. Olettamuksena on että viipaloitu ohjelma on nyt testauksen kannalta ekvivalentti alkuperäisen ohjelman kanssa. Viipaloitua ohjelman käyttäytymistä tarkastellaan oraakkelia (oracle) vasten.
Menetelmässä nimensä mukaisesti käytetään hyväksi useita pieniä simulointimalleja yhden suuren sijasta. Sekä syötetiedot että käyttäytyminen mallinnetaan attribuuttikieliopilla (attribute grammar).Minisimulaatiomalli muodostuu isäntäspesifikaatiosta (master specification) ja konfiguraatiosta (configuration). Konfiguraatio lukee isäntäspesifikaation ja muuntaa sen kieliopin (grammar) interaktiomallin kieliopin mukaiseksi ja evaluoi (evaluate) syötekieliopin tuloskieliopin mukaiseksi. Menetelmä sopii laajojen testiaineistojen luomiseen.
Ghosh et al, "An automated approach for Identifying Potential vulnerabilities in software". Proceedings of the IEEE Symposium on Security and Privacy, May 3-6, 1998. Oakland, CA USA.IEEE. pp.104-114
MinisimulaatioKaksonen, Rauli, "A Functional Method for Assessing Protocol Implementation Security" (Licentiate thesis). Espoo. Technical Research Centre of Finland, VTT Publications
OminaisuustestausG. Fink and M. Bishop, "Property Based Testing: A New Approach to Testing for Assurance," ACM SIGSOFT Software Engineering Notes, 22(4) (July 1997).
Taneli Rantala