Risiko er noe vi må leve med, men dessverre er det også noe de fleste av oss er veldig dårlige til å vurdere. En vanlig måte å beregne risiko på er å multiplisere konsekvensen av en hendelse med sannsynligheten for at den sal oppstå. Man illustrerer dette gjerne i en risikomatrise, der sannsynlighet er en akse, og konsekvens er den andre. I World Economic Forums risikorapport for 2019 finner vi cyberangrep langt opp til høyre i matrisen, kun slått av klimaendringer, ekstremvær og naturkatastrofer (som for meg egentlig høres ut til å være det samme).

Etikk

Før vi snakker mer om risiko, tar vi en liten omvei om etikk – og da spesielt etikk for autonome kjøretøy. Science Fiction-forfatteren Isaac Asimov formulerte i novellen “Runaround” tre lover for robotikk som begynner å få stadig mer relevans. Lovene er som følger (fritt oversatt):

En robot må ikke skade et menneske, eller la et menneske komme til skade
En robot må adlyde ordre fra et menneske, unntatt hvis det kommer i konflikt med den første loven
En robot må beskytte seg selv, unntatt hvis det kommer i konflikt med de to første lovene

Hvis vi spoler framover til i dag, kan vi tenke oss en situasjon hvor en autonom bil havner i en situasjon hvor den ikke er i stand til å stoppe, og uansett hvor den svinger vil den skade noen. Hvis valget er å kjøre over noen mennesker eller et antall kattunger, er det kanskje enkelt; etter Asimovs lover får menneskene alltid prioritet. Men hav om bilen må velge mellom en gammel dame og en ung mann? Eller en gruppe småbarn og en viktig politiker? Forsking har funnet en global preferanse for å redde mesker framfor dyr, flere mennesker fremfor færre, og unge fremfor gamle. Men det blir enda vanskeligere når man skal veie passasjerer opp mot fotgjengere, og det er forskjeller rundt i verden når det gjelder hva som teller mest.

Kunnskap

For å vurdere risiko, må man ha kunnskap. Skal man beskytte seg mot dataangrep, må man kunne tenke som en angriper. Deretter er det en rekke aktiviteter man kan gjøre for å forbedre programvaresikkerhet, men hvor skal man starte? Gary McGraw lanserte for over 10 år siden en samling med god praksis for programvaresikkerhet som kanskje kan være et godt utgangspunkt.

Trykkpunktene er illustrert i figuren over, fra venstre mot høyre, fordelt på fasene i en tradisjonell vannfallsmetodikk. McGraw har senere laget dette om til en liste prioritert etter grad av effektivitet:

Kodegjennomgang
Arkitekturanalyse
Penetreringtesting
Risikobasert sikkerhetstesting
Misbrukstilfeller
Sikkerhetskrav
Sikkerhetsdrift

Vi kommer tilbake til de enkelte punktene senere i kurset!

Hvorfor skal vi bry oss om sikkerhet?

Mange har lett for å gå i fellen “jeg har ingenting å skjule, så hvorfor trenger jeg sikkerhet?” Senere års hendelser har imidlertid vist at det finnes plenty med krefter som er “ute etter oss”, alt fra statlige aktører til private selskaper som ønsker å benytte seg av våre personopplysninger til egen vinning. Amerikanske myndigheter hadde f.eks. kjennskap til Heartbleed-sårbarheten lenge før den ble kjent for allmenheten, og vi kan bare gjette hva de brukte denne kunnskapen til. I 2014 ble store deler av Europa, inkludert Norge, utsatt for den såkalte Dragonfly-kampanjen, hvor det ble forsøkt hentet ut informasjon om kritisk infrastruktur hos mange forskjellige aktører i energibransjen. Mange ser dette som et forvarsel på hendelsene som skjedde i Ukraina i 2015 og 2016, der store deler av strømnettet ble satt ut av spill i en periode.

Programvaresikkerhet

Gary McGraw definerer programvaresikkerhet som det å bygge programvare som er sikker og fortsetter å fungere som forventet også når den utsettes for ondsinnet angrep.

I følge McGraw bygger programvaresikkerhet på tre pilarer:

Risikohåndtering
Trykkpunkter
Kunnskap

I mange år lot bransjen til å drive programvaresikkerhet etter “penetrer og lapp”-prinsippet, dvs. rull ut ny funksjonalitet først, gjør så forsøk på å finne sikkerhetshull (eller la andre gjøre det), og deretter lappe hullene med oppdateringer etter hvert som de oppdages. McGraw var blant de som argumenterte heftig for å forkaste denne strategien, og heller satse på å bygge sikkerhet inn fra starten av.

Informasjonsverdier og aktiva

Vi trenger informasjonssikkerhet fordi vi har noe å beskytte. Disse verdiene kan være konkrete, fysiske ting som datamaskiner, penger, eller hus; men i økende grad dreier det seg om informasjon – et estimat sier at innen 2020 vil hver forbruker ha et “digitalt fotavtrykk” på 2,5 GB med personopplysninger.

Noen eksempler på de forskjellige typer aktiva:

Informasjonsaktiva
- Kundedata
- Ansattdata
- CRM-data
- …
Programvareaktiva
- Epostsystem
- Elektronisk bestillingssystem
- Felles autentiseringssystem
- …
Fysiske aktiva
- Bygninger
- Tjenermaskiner
- Nettverksutstyr
- …

Security Engineering

(Sliter med å finne en god oversettelse av Security Engineering….)

Security Engineering handler om å bygge systemer slik at de er pålitelige til tross for ond vilje, feil og uhell. Som et fagfelt, fokuserer det på verktøy, prosesser og metoder som trenges for å designe, utvikle og teste komplette systemer, samt å tilpasse eksisterende systemer etter hvert som omgivelsene endrer seg.

Designhierarkiet starter med politikk og retningslinjer (policy), hvor vi definerer hva vi ønsker å gjøre, på neste nivå har vi protokoller osv. som definerer hvordan vi gjør det, og til slutt må vi bestemme med hva, dvs. velge maskinvare, kryptokomponenter etc.

De to ordene Dependability og Reliability oversettes begge med “pålitelighet” på norsk, så da blir det vanskelig å oversette utrykket dependability = reliability + security. Imidlertid er poenget at det er forskjellig å tilby pålitelighet i en situasjon der man kun ser på uhell og tilfeldige feil, og der man må anta at noen med onde hensikter aktivt prøver å påvirke påliteligheten. I noen tilfeller dreier det seg om motsatte egenskaper, dvs. pålitelighet kunne være at “Bob er i stand til å lese denne filen”, men sikkerhet kan være “Kinesiske myndigheter er ikke i stand til lese denne filen”. Generelt er det mye vanskeligere (for ikke å si umulig) å bevise negative utsagn av denne typen.

Den trøblete treenighet

Det er tre faktorer som spesielt gjør livet vanskeligere for oss som vil lage sikker programvare:

Konnektivitet: Hvis programvare kjører i et miljø som har forbindelser til omverdenen, øker angrepsflaten, og det blir lettere å angripe.

Kompleksitet: Jo mer kompleks programvare er, jo vanskeligere blir den å analysere, og dess lettere skjer det at sikkerhetshull og sårbarheter slipper gjennom maskene.

Utvidbarhet: Akkurat når du trodde du hadde kontroll på programmet ditt, kommer det en utvidelse, en ny komponent kommer til, og ingenting er sikkert lenger. Enda verre kan det være når slike utvidelser kan komme fra ukjente kilder.

Passord

Passord var den første mekanismen som ble introdusert for å begrense tilgang til datamaskiner, og til tross for mange nye autentiseringsmekanismer er det ingen grunn til å tro at de kommer til å forsvinne med det første (det er til og med en egen konferanse for passord: https://passwordscon.org/) . Det finnes lister med ofte valgte passord (i tidligere tider var “pils” et populært valg på norske universiteter), og dette har medført behov for å begrense hvilke passord et system vil akseptere. Ofte har dette resultert i komplekse passord med høy entropi som er vanskelige å gjette, men også vanskelig for brukerne å huske. I senere tid har derfor bl.a. NIST gått bort fra slike kompleksitetskrav til fordel for krav til lengre passord – dette gir bedre sikkerhet totalt sett, og lar det også være mulig å unngå hyppige passordbytter.

Litt terminologi til slutt

Et system kan være et produkt eller en komponent (PC, smartkort, …); noen produkter pluss et operativsystem, kommunikasjon og infrastruktur; det foregående pluss applikasjoner; det foregående pluss interne ansatte; det foregående pluss kunder/eksterne brukere. En feil som ofte gjøres, er at politikk og retningslinjer defineres for smalt, og glemmer å ta det store bildet i betraktning.

Et subjekt er en fysisk person. En person kan også være en juridisk person (f.eks. et firma). En hovedaktør (principal) kan være en person, utstyr (PC, smartkort), en rolle (vaktkommandør), eller en kompleks rolle (Alice eller Bob, Bob som representerer Alice).

Presisjonsnivået kan variere – noen ganger trenger du å skille “Bobs smartkort som representerer Bob som vikarierer for Alice” fra “Bob som bruker Alices kort mens hun er borte”, men andre ganger trenger du ikke.

Hemmelighold er et teknisk begrep – mekanismer som begrenser hvilke hovedaktører som kan få tilgang til informasjonen. Personvern betyr kontroll med dine egne personopplysninger. Konfidensialitet er en forpliktelse til beskytte noen andres hemmeligheter. Følgelig blir ditt (medisinske) personvern bl.a. beskyttet av fastlegens konfidensialitetsforpliktelse (taushetsplikt).

Anonymitet handler om å begrense tilgang til metadata. Det finnes i forskjellige varianter, fra ikke å kunne identifisere subjekter, til ikke å kunne knytte sammen deres handlinger. Et objekts integritet innebærer at det ikke har blitt endret etter den siste autoriserte endringen. Autentisitet har to vanlige betydninger: Et objekt har integritet og friskhet (freshness), og/eller at du snakker med den rette hovedaktøren.

Tillit er en utfordring! Det kan ha flere betydninger:

En varm, ullen følelse
Et system du har tillit til (et tiltrodd system) er i stand til å bryte dine sikkerhetsretningslinjer
Et system du har tillit til kan du kjøpe forsikring til
Et system du (eler firmaet) har tillit til får deg ikke oppsagt når

USAs nasjonale sikkerhetsmyndighet (NSA) holder en knapp på den andre definisjonen over, og det samme gjør Ross Anderson i sin bok. En NSA-mann som selger nøkkelmateriale til kineserne har tillit, men er ikke tillitverdig (hvis vi antar at handlingen ikke er autorisert).

En sikkerhetspolitikk (security policy) er en kortfattet oppsummering av sikkerhetsmål – typisk mindre enn en side med tekst i normalt språk (men bemerk at det er en glidende overgang til sikkerhetsretningslinjer, som kan være betydelig lengre).

En beskyttelsesprofil (Protection Profile i Common Criteria) er en detaljert spesifikasjon av beskyttelsesmål, gjerne dusinvis av sider i semiformelt språk. En sikkerhetsblink (Security Target i Common Criteria – ikke helt fornøyd med den oversettelsen) er en implementasjon/spesifikasjon av en beskyttelsesprofil for et spesifikt system, inkludert hvordan det skal testes for å verifisere at det tilfredsstiller kravene.

Hyppige uheldige forsøk på sikkerhetspolitikk/retningslinjer

Disse retningslinjene er godkjent av ledelsen
Alle ansatte skal adlyde disse retningslinjene
Data skal kun være tilgjengelige til de med tjenstlig behov
Alle brudd på disse retningslinjene skal rapporteres straks til sikkerhetsavdelingen

Er det noe feil med dette?

Et eksempel på formell sikkerhetspolitikk – MLS

Flernivå-sikkerhet (MLS) brukes primært i militære systemer. Grunntanken er at en funksjonær med “Hemmelig” klarering kan lese dokumenter gradert Konfidensielt og Hemmelig, men ikke Strengt Hemmelig. Dette viste seg å være et problem på stormaskiner på 60- og 70-tallet, og MLS sprang ut av en rapport for det amerikanske luftforsvaret i 1973 som anbefalte å holde både politikken og gjennomføringen av samme enkel.

Graderingsnivåer omfatter iht. sikkerhetsloven:

STRENGT HEMMELIG dersom kompromittering kan få helt avgjørende skadefølger for rikets sikkerhet
HEMMELIG dersom kompromittering kan få alvorlige skadefølger
KONFIDENSIELT dersom kompromittering kan få skadefølger
BEGRENSET dersom kompromittering i noen grad kan få skadefølger.

Ressurser har gradering, mens mennesker (hovedaktører har klarering). Informasjon flyter kun oppover (med mindre den blir nedgradert).

Det første forsøket på å lage MLS hadde en regel om at ingen prosess kunne lese en ressurs på et høyere nivå – men dette var ikke nok. Forskerne David E Bell og Leonard J. La Padula foreslo i 1973 Bell-LaPadula-modellen med følgende egenskaper:

Enkel sikkerhetsegenskap: Ikke les oppover
*-egenskapen: Ikke skriv nedover

Ut fra denne formelle spesifikasjonen kan man bevise teoremer osv. Idealet er å minimalisere den Tiltrodde Beregningsbasen (Trusted Computing Base) (dvs. koden man er avhengig av, og som hvis den feiler kan bryte sikkerhetspolitikken) til en referansemonitor.

Photo by Artem Beliaikin from Pexels

Risiko og programvaresikkerhet