To typer programvaresikkerhet

Programvaresikkerhet kan deles opp i to typer:

  • Kode-, og designsikkerhet. Hvor fokuset er på å designe sikker programvare samt unngå lus når man foretar implementeringen. Her gjør man hva man kan (f.eks. statisk analyse) for å unngå dårlig design og kode.
  • Applikasjonssikkerhet. Her prøver man å sikre seg i ettertid, ved å bestemme hva som skal kjøres, av hvem, og hvor. Dette kan f.eks. gjøres med en sandboks («sandbox» på engelsk) for sikker kjøring eller policier.

Begge typer er viktige om man ønsker best mulig sikkerhet.

Statisk analyse

Når man analyserer kode for å finne svakheter, uten å kjøre programmet, foretar man det som kalles for statisk analyse.

Det er da flere ting man som regel ønsker å sjekke:

  • Typer – f.eks. forsøk på å lagre tekst i en variabel for tall. Dette blir først og fremst nødvendig hvis brukte verktøy (f.eks. IDE og kompilator) ikke undersøker selv.
  • Stil. Dette er simpelthen kodestil, altså kodeformatering. Dvs. tomrom, navning, kommentarskriving, o.s.v. Noen undersøker også programstruktur og kan si ifra hvis det mangler noe. Denne type sjekking bør man helst ha med fra starten av i et prosjekt, før man begynner å skrive masse kode og tillegge seg (u)vaner.
  • Lus – dvs. «bugs» på engelsk. Her sjekkes det for uønsket og ikke tiltenkt funksjonalitet, fordi dette kan åpne for sikkerhetshull.

For sistnevnte vil man som regel oppleve å få falske positiver og falske negativer, selv om analyseprogrammene er lagd av veldig proffe folk. Og man avdekker først og fremst kun generelle kodefeil som åpner for sikkerhetshull uansett hvilke omstendigheter som er gjeldende.

Å oppdage kodefeil som gir situasjonsbestemte sikkerhetshull er vanskeligere.

TBC

De syv farlige kongeriker

Innenfor temaet kodesikkerhet finnes det syv forskjellige felt:

  1. Inndatabehandling – alle innmatede data må sjekkes grundig. Buffer-overflyt og SQL-injeksjon er to eksempler på angrep som kan utføres når ting ikke er på stell.
  2. API-misbruk, her tukler man med et API ved å ikke bruke det slik det er ment.
  3. Sikkerhetsfunksjonalitet – når autentisering, tilgangskontroll, konfidensialitet, kryptografi, o.s.v. implementeres må det gjøres tilfredsstillende.
  4. Tidspunkt og tilstander. Programmer som ikke kjører fra start til slutt uavbrutt, f.eks. spill med masse spillere samtidig, må gis ekstra sikkerhet, for å hindre manipulering.
  5. Feilhåndtering – når det oppstår feil må dette håndteres riktig. Og uten at man avslører mye data eller hvordan programmet fungerer internt.
  6. Kodekvalitet. Hvis et program har dårlig kodekvalitet er som regel sikkerheten også fraværende. Et tegn på dette er at programmet er lite brukervennlig.
  7. Innkapsulering – å ha tydelige skiller, f.eks. mellom validerte og uvaliderte data.

Rekkefølgen gjenspeiler hvor viktig hver kategori er. Sammen utgjør de det som kalles for de syv farlige kongeriker. Man bør også ta med ett åttende ledd, som er omgivelsene.

Switch-sikkerhet

Med en smart switch kan man velge hvem som skal få koble til et lokalt kablet nettverk, omtrent slik greia også er for vanlige trådløse aksesspunkt.

Det finnes to muligheter:

  • Portsikkerhet – her velger man hvilke MAC-adresser som skal tillates på nettverket.
  • 802.1x – hvor man kobler til ved å autentisere seg. I virksomheter flest blir dette da med samme brukernavn og passord som når man logger på brukerprofilen sin, hvis ting er satt opp riktig.

Alternativ nr. 1 er ikke sikker da MAC-adresser kan forfalskes. Ønsker man uautorisert tilgang med alternativ nr. 2 må man derimot finne et gyldig brukernavn og passord.

Sikkerhetspolicy

En sikkerhetspolicy kommuniserer på høyt nivå hvilke krav som stilles når virksomhetens datasystemer installeres, vedlikeholdes og brukes. Altså gjør man det klart hvor policyen gjelder og for hvem. Man bør også redegjøre for hva som er meningen med den.

Sikkerhetspolicier er viktige fordi de styrer arbeidet med å utvikle sikkerhetsstandarder, sikkerhetsprosedyrer og sikkerhetsguider.

Å lage en sikkerhetspolicy bør gjøres i faser:

  1. Kartlegging av alle krav – forretningsmessige, lovregulerte, beste praksis og muligens noen som er virksomhetsspesifikke.
  2. Definere behovet og basert på dette lage et grovt forslag til policy.
  3. Skrive en komplett policy med utgangspunkt i forslaget.
  4. Kritisk vurdering av policyen også eventuelt vedtakelse av den.
  5. Publisering og distribusjon av policyen for hele virksomheten.
  6. Evigvarende vedlikehold og fornyelse når policyen trenger det, dvs. at man påbegynner kravinnsamling igjen.

En sikkerhetspolicy skal ikke lages i et vakuum, man må involvere alle avdelinger og ansatte som vil bli berørt av den.

TBC

Konfidensialitet vs. privat

Mens private data som regel bare er tilgjengelig for èn part er konfidensielle data den type data som andre har innsyn i – fordi de har saklig grunn.

Passord, PIN-kode, BankID-kodebrikke o.s.v., er privat. Pasienters sykejournaler derimot er konfidensielle fordi leger trenger tilgang for å få gjort jobben sin.

CIA-triaden

En kjent konseptuell modell for datasikkerhet, som består av tre sider:

  • Confidentiality – altså konfidensialitet.
  • Integrity – integritet.
  • Availability – tilgjengelighet.

Denne modellen gjør at man tenker mer helhetlig rundt datasikkerhet fordi det er fort gjort å f.eks. fokusere bare på tilgjengelighet.