Innebygget sikkerhet

I en artikkel i IEEE S&P for mange år siden diskuterte Bruce Schneier hva som gjør at vi “kjøper” sikkerhet. Hvorfor får sikkerhetsoppgaver alltid lavere prioritet enn andre oppgaver? Hvorfor er utviklere generelt så lite interesserte i sikkerhet? Eksperter forteller stadig vekk utviklere at de må tenke er på sikkerhet, så hvorfor gjør ikke alle det? Hvorfor innser ikke ledere at de må sørge for å ha sikkerhetseksperter i utviklingsgruppen, på samme måte som de gjør med testere?

Hvorfor programvaresikkerhet?

Som tidligere nevnt, dreier programvaresikkerhet om å lage programvare som gjør det den skal, også når den utsettes for angrep. En sikkerhetshendelse forutsetter at det har vært et angrep, og et vellykket angrep forutsetter at det fantes en sårbarhet å utnytte. Vi får dermed rekken:

Sårbarhet -> Angrep -> Hendelse

La oss lage færre av førstnevnte!

Løgner, forbannede løgner, og statistikk

Hvis man ser på antallet sårbarheter som rapporteres årlig, er kurven bratt oppadgående. Det er dermed ingen tvil om at programvaresikkerhet er et like hett tema i dag som i 2006, men det er litt vanskeligere å si noe om vi faktisk gjør det bedre eller verre enn vi gjorde det for 10 år siden. Årsaken er at antallet programmer også har økt, så vi måtte hatt informasjon om antall sårbarheter per (f.eks.) 1000 kodelinjer for å si noe om utviklingen er positiv eller ei.

Trykkpunkter reprise

Vi er åpenbart ikke i mål med å integrere sikkerhet i utviklingsprosessen. Det har vært flere forsøk på å lage sikre utviklingsmetodikker (SSDL), men mye tyder på at prosess-agnostiske tilnærminger har størst mulighet for å lykkes. Enhver programvareutviklingsvirksomhet har sin mer eller mindre veldefinerte programvareutviklingssyklus, og det er ytterst sjelden at vi vil være i stand til å introdusere en helt ny måte å jobbe på, bare pga. sikkerhet. 

Microsoft sin Security Development Lifecycle (MS SDL) var en av de første eksemplene av en programvaresikkerhetsmetodikk (SSDL), og ble utviklet etter malen av en klassisk vannfalls-metodikk.

NIST 800-64: Tilbyr sikkerhetsbetraktninger innen utviklingsmetodikken. Standarder utviklet av US National Institute of Standards and Technology som skulle gjelde for føderale amerikanske virksomheter.

OWASP CLASP (Comprehensive, Lightweight Application Security Process): Skulle være enkel å implementere; basert på MS SDL. Gjør også en avbildning av sikkerhetsaktiviteter til roller I en virksomhet. CLASP ble imidlertid ingen stor suksess.

Cigital’s Security Touchpoints: Foreslått av Gary McGraw i Software Security. Disse trykkpunktene, som angitt under, presenterer en artefakt-sentrisk tilnærming (laget for å fungere med dokumenter, digrammer, kode, etc.) snarere enn en prosess-sentrisk tilnærming. Dette gjør på sin side sikkerhetsanalysen utviklingsmetodikk-agnostisk.

  1. Kodegjennomgang
  2. Arkitekturanalyse
  3. Penetreringstesting
  4. Risikobasert sikkerhetstesting
  5. Misbrukstilfeller
  6. Sikkerhetskrav
  7. Sikkerhetsdrift

Historien til Microsoft SDL

I begynnelsen av dette århundret ble Windows-brukere utsatt for en rekke eksemplarer av skadevare; navn som Iloveyou, CodeRed og Nimda vekker sikkert kjære minner hos mange. Dette ble etter hvert så belastende for Microsoft at Bill Gates i 2002 skrev en epost til alle ansatte hvor han annonserte innføringen av Trustworthy Computing Initiative. Dette medførte en 2 måneders stopp i utvikling av ny funksjonalitet, og mer enn 9000 utviklere ble sendt på sikkerhetsopplæring.

Problemene kunne selvsagt ikke løses umiddelbart, og i 2002 og 2003 fikk vi smake på Beast, Slammer og Blaster, som medførte minst like store problemer.

I 2004 presenterte Michael Howard og Steve Lipner Microsoft Security Development Lifecycle. I “The Trustworthy Computing Security Development Lifecycle” fra 2005 beskriver Michael Howard de grunnleggende prinsippene for første versjon av Microsoft SDL. Den er bygget opp etter en tradisjonell vannfallsmetodikk (Krav – Design – implementering – verifikasjon – utgivelse – støtte og vedlikehold), med sikkerhetsaktiviteter i hver fase:

  • Krav
    • Sikkerhetsopplæring
    • Sikkerhetsavspark, registrering av utviklingsgruppen med SWI
  • Design
    • (Mer) Sikkerhetsopplæring
    • God praksis i sikker design
    • Sikkerhetsarkitektur og gjennomgang av angrepsflate
    • Trusselmodellering
  • Implementering
    • Bruk verktøy for sikker implementering, og god praksis for sikker utvikling og test
    • Lag sikkerhets dokumentasjon og verktøy for produkt
  • Verifikasjon
    • Lag sikkerhetsresponsplan
    • Sikkerhetsdytt
    • Penetreringstesting
    • Endelig sikkerhetsgjennomgang
  • Støtte & vedlikehold
    • Sikkerhetsvedlikehold
    • Utføring av sikkerhetsrespons

Etter noen år med polering, har Microsoft SDL funnet følgende form:

  1. Opplæring
    • (1) Grunnleggende sikkerhetsopplæring
  2. Krav
    • (2) Etabler sikkerhetskrav
    • (3) Lag kvalitetsporter, feilhindrere (bug bars)
    • (4) Utfør sikkerhets- og personvern-vurderinger
  3. Design
    • (5) Etabler designkrav
    • (6) Utfør angrepsflate-analyse/-reduksjon
    • (7) Bruk trusselmodellering
  4. Implementering
    • (8) Bruk godkjente verktøy
    • (9) Unngå usikre funksjoner
    • (9) Utfør statisk kodeanalyse
  5. Verifikasjon
    • (10) Utfør dynamisk kodeanalyse
    • (11) Utfør fuzzing
    • (12) Utfør gjennomgang av angrepsflate
  6. Utgivelse
    • (13) Lag en hendelseshåndteringsplan
    • (14) Utfør endelig sikkerhetsgjennomgang
    • (15) Sertifiser utgivelsen og arkiver
  7. Responder
    • (16) Utfør hendelseshåndteringsplanen

SDL slik den er definert passer ikke med en smidig utviklingsmetodikk, så for noen år siden laget Microsoft en smidigere variant kalt SDL Agile. Endringen består primært i at de forskjellige aktivitetene i SDL er kategorisert i tre grupper:

  • Gjøres i hver sprint (7,8,9,10,15,16)
  • Gjøres en gang
  • Bøtte-aktiviteter; gjør et utvalg i hver sprint

Sikkert design

Feil i sikkerhetsdesign kan være vanskelig å oppdage, og IEEE Cybersecurity Initiative ga derfor ut en liste med de ti viktigste sikkerhetsdesignfeil, og hvordan man kan unngå dem.

  1. Opptjen eller gi, men aldri anta tillit.
    • Anta at data er kompromittert.
  2. Bruk en autentiseringsmekanisme som ikke kan omgås eller bli tuklet med
    • Forhindre brukeren fra å endre identitet uten re-autentisering, når autentisert.
    • Ta styrken i autentiseringen brukeren har foretatt i betraktning før det tas aksjon
    • La ting gå ut på tid, og krev re-autentisering når tiden er løpt ut
  3. Autoriser etter at du autentiserer
    • Autorisasjon avhenger av et gitt sett av privilegier, og på konteksten til forespørselen
    • Hvis man unnlater å tilbakekalle autorisasjon, risikerer man at autentiserte brukere kan benytte seg av foreldede autorisasjoner
  4. Skill data og kontrollinstruksjoner, og aldri prosesser kontrollinstruksjoner mottatt fra ikke-tiltrodde kilder
    • Det er dårlig praksis å blande sammen data og kontrollinstruksjoner i en entitet
  5. Definer en tilnærming som sikrer at alle data er eksplisitt validert
    • Bruk en sentralisert valideringsmekanisme
    • Se opp for antagelser om data
    • Unngå svartelisting; bruk hvitlisting
  6. Bruk kryptografi på riktig måte
    • Bruk standard algoritmer og biblioteker
    • Sentralisering og gjenbruk
    • Søk hjelp hos virkelige eksperter
    • Se opp for nøkkelhåndteringsutfordringer
    • Unngå ikke-tilfeldig “tilfeldighet”
  7. Identifiser sensitive data og hvordan de skal behandles
    • Klassifiser dine data i kategorier
    • Se opp for tillitsgrenser
  8. Alltid ta hensyn til brukeren
    • Ikke anta at brukeren bryr seg som sikkerhet
  9. Forstå hvordan integrasjon av eksterne komponenter endrer angrepsflaten din
    • Åpen kildekode, f.eks. OpenSSL-biblioteket
  10. Vær fleksibel når du vurderer fremtidige endringer til objekter og aktører
    • Konstruer for endring

10 grunnleggende prinsipper for programvaresikkerhet

Viega & McGraw presenterte 10 grunnleggende prinsipper for programvaresikkerhet som fremdeles er gyldige i dag.

Prinsipp 1: Sikre det svakeste leddet

Ingen kjede er sterkere enn det svakeste ledd, så det er logisk å analysere hele kjeden, identifisere det svakeste leddet, og begynne her.

Prinsipp 2: Praktisér dybdeforsvar

Før 2. verdenskrig hadde Frankrike klokketro på sine forsvarsverker mot grensen til Tyskland, den såkalte Maginot-linjen. De så derfor liten grunn til å ha ytterligere forsvarsverker lenger inne i landet. Tyskerne brydde seg imidlertid ikke så mye om dette, og kjørte sitt lynangrep gjennom Belgia og Nederland, og brukte dette som innfallsporten til Frankrike – og her var det ingen forsvarsverker å snakke om. Dybdeforsvar betyr å ha flere redundante lag med beskyttelsmekanismer, det ene utenpå det andre, slik hvis en enkelt mekanisme feiler vil likevel ikke hele systemet rakne.

Prinsipp 3: Feil sikkert

Hvis ting går galt og sikkerhetsmekansimer feiler, sørg for at det skjer på den sikreste måten – heller for lite tilgang enn for mye.

Prinsipp 4: Minste privilegium

Gi kun det minste utvalg av aksessrettigheter som trengs for å få gjort jobben, og kun for det minste tidsrommet som trengs. Unngå å gi “kjekt å ha” rettigheter som noen “kanskje kommer til å trenge en gang i framtiden”. Tilsvarende, ikke be om  mer rettigheter enn du trenger, og gi dem fra deg igjen så snart som mulig.

Prinsipp 5: Del inn i skott

Minimaliser skaden som kan skje hvis et sikkerhetsbrudd skulle skje (se i sammenheng med dybdeforsvar), men gjør inndeling med måte; blir det for mange skott blir det umulig å administrere systemet.

Prinsipp 6: Gjør det enkelt

Kompleksitet gjør det vanskeligere å analysere programvare, og øker risikoen for feil.

Prinsipp 7: Framsnakk personvern

Innebygget personvern er et krav fra GDPR.

Prinsipp 8: Husk at det er vanskelig å skjule hemmeligheter

Du kan ikke skjule hemmeligheter i binærkode; den som har fysisk tilgang vil alltid kunne få tak i informasjonen. Det er generelt vanskelig å skjule hemmeligheter fra innsidere.

Prinsipp 9: Ha sunn skepsis til tillit

Har dine programvareleverandører sikkerhetsekspertise? Vær også skeptisk til sikkerhetsleverandører. Tillit er transitiv – vet du hvem dine leverandører stoler på?

Prinsipp 10: Bruk ressursene som bransjen (eller samfunnet) tilbyr

Kryptografiske algoritmer studeres grundig av fagfeller som er eksperter. Imidlertid betyr det ikke alltid at selv om alle kan studere koden, så kommer de til å lete etter sikkerhetsfeil for deg (åpen kildekode).