Programvare blir stadig viktigere for alle deler av samfunnet, og det er økende bevissthet om at det er viktig med kvalitet og sikkerhet også i programvare. Sikkerhetsfeil i programvare er roten til mange av sikkerhetsutfordringene man opplever. Det har skjedd mye på programvaresikkerhetsområdet de siste årene, og det har dukket opp mange nye rammeverk og metoder man kan benytte for ulike deler av utviklingsprosessen. Det er bra. Samtidig kan det være nyttig også å se tilbake, for å gjenoppdage noe av det som har formet dette arbeidet og som har stått seg over flere år. I anledning av at vi i disse dager starter opp et nytt forskningsprosjekt innen programvaresikkerhet, gir vi en kort oversikt over 10 prinsipper for programvaresikkerhet, hentet fra en bok som har betydd mye for området, nemlig Viega og McGraws bok “Building Secure Software” fra 2001.
Målet med disse prinsippene er å identifisere og fremheve de viktigste målene utviklere bør ha med seg når de designer og utvikler programvare med tanke på sikkerhet. En engelsk gjennomgang av prinsippene finnes på den nyopprettede bloggen for det nye prosjektet SoS-Agile – følg gjerne med på det som skjer der fremover om du er interessert i temaet programvaresikkerhet.
Så, her kommer 10 prinsipper som fortsatt har mye for seg!
- Sikre det svakeste ledd: Et system er aldri sikrere enn det svakeste ledd. Derfor er det lurt å adressere de største risikoene først, og ikke bare det som det er enklest å gjøre noe med. En risikoanalyse kan hjelpe til med å identifisere hva som har stor risiko. Samtidig må man huske på at et 100 % sikkert system ikke er et realistisk mål, og det er helt ok å akseptere risiko som er innenfor det som virksomheten anser som akseptabelt.
- Praktiser dybdeforsvar: Med dybdeforsvar vil man ha flere ulike beskyttelsesmekanismer på plass i systemet, slik at om en av disse skulle svikte vil forhåpentligvis andre mekanismer slå inn og hindre et større sikkerhetsbrudd.
- Feil sikkert: Feil vil skje, og det bør det planlegges for. Utfordringen er at mange systemer oppfører seg usikkert når de feiler, og dette kan utnyttes av angripere. Utviklere bør derfor ha et bevisst forhold til hvordan programvaren oppfører seg når den feiler, og hvordan de kan sikre at feil ikke har konsekvenser for sikkerheten til systemet.
- Følg prinsippet om minimale rettigheter (least privilege): Dette prinsippet innebærer at man kun skal gi de rettigheter i systemet som er nødvendige for å utføre en operasjon, og da kun for den tiden det er nødvendig. Det er alltid en risiko for at rettigheter i systemet kan misbrukes. Det å gi større rettigheter enn nødvendig kan gjøre programvareutviklingen lettere, men har en negativ konsekvens for sikkerheten. Ofte vil man ha utfordringer knyttet til eldre systemer som er laget for å fungere i mer beskyttede og begrensede miljøer.
- Del opp systemet: Om systemet er delt opp i ulike enheter, vil ikke nødvendigvis en angriper som får tilgang til en del av systemet få tilgang til alt. Et eksempel på mangelfull oppdeling av systemet er den klassiske UNIX-måten der man med rot-tilgang kan gjøre hva man vil på hele systemet.
- Gjør det enkelt – kompleksitet øker risiko for problemer: Som et eksempel, så må prinsippet om å dele opp systemet i ulike enheter brukes med moderasjon. Om man isolerer hver minste bit av funksjonalitet vil man få et system som er umulig å håndtere. Komplekse design er vanskelige å forstå, og det vil dermed være vanskeligere å oppdage sikkerhetsproblemer gjennom analyse og test. Om man kan gjenbruke komponenter som har god kvalitet, vil det oftest være en god strategi for å redusere risiko.
- Ivareta personvern: Manglende personvern kan gi manglende tillit fra brukerne. Derfor bør utviklere være opptatt av å beskytte personlig informasjon i systemet. Dette kan innebære avveininger mellom brukervennlighet og personvern.
- Husk at det er vanskelig å skjule hemmeligheter: Innsidere utgjør en stor trussel mot virksomheter. Selv de sikreste systemer vil kunne utsettes for angrep fra innsidere.
- Vær skeptisk til tillit: Utviklere bør være skeptiske til å utvide tillit, og til å stole på antagelser om andre. Som et eksempel, så har mange sikkerhetsprodukter store sikkerhetshull.
- Bruk fellesressurser: Det finnes en mengde nettsider og andre kilder med informasjon om kjente trusler og sårbarheter i programvarekomponenter og –systemer. Og selv om det kan ta lang tid å oppdage sikkerhetsfeil i programvare, også den som brukes mye, så vil det i det ofte gi mening å stole mer på sikkerhetsbiblioteker som er mye brukt.