Oktober har av en eller annen grunn har blitt valgt som sikkerhetsmåneden. Dette kommer fra USA, nærmere bestemt fra Department of Homeland Security sin National Cyber Security Division. Målet er å synliggjøre informasjonssikkerhet og bygge bevissthet rundt dagens utfordringer og hva vi kan gjøre for å sikre oss bedre. Dette er et stort og viktig tema i dagens samfunn og derfor falt det logisk at dette ble lagt til samme måned som Halloween. I den forbindelse tenkte jeg det var på sin plass å gi de kjente, men ofte glemte, sikkerhetsdesignprinsippene et lite gjenbesøk.
Enten vi driver utvikling av applikasjoner eller infrastruktur, om det er i skyen eller kjelleren, forvaltning eller avvikling – noe skal kobles sammen slik at data skal sendes, bearbeides og lagres. Det er systemer og brukere som skal utføre forskjellige automatiske og manuelle oppgaver. Kort oppsummert; data, tjenester og brukere. Så uansett hvilket nivå eller fase vi befinner oss i så finnes det et knippe prinsipper som kan guide oss på rett vei.
1. Least-Privilege
Prinsippet sier at en enhet (tjeneste, system, service-bruker, menneskelig bruker) skal bare ha de rettighetene (tilgangene) den trenger for å utføre sitt arbeid. Hvis en enhet ikke trenger tilgang til noe, så skal man heller ikke ha tilgang til det.
Dette høres lett ut, men kan by på utfordringer. For å komme i mål med prinsippet må man ha tydelige roller med veldefinerte ansvarsområder, klassifiserte data, oversikt over tjenester og hva de har tilgang til, samt hvilken kontekst de kjører i. Har man hoppet bukk over dette prinsippet for ti år siden vil man nå sitte med en IT portefølje med mye gammel moro og manglende oversikt. Oppgaven blir fort lagt på personer som er mindre tekniske, for hvis du legger ansvaret på utviklerne tar det ti minutter, så er alle administratorer (er det et DevOps team snakker vi sekunder).
2. Fail-Safe Defaults
Prinsippet sier at med mindre en enhet eksplisitt har gitt tilgang til en ressurs, så skal den bli nektet adgang. Når noen oppretter en ny ressurs (en database, en tjeneste, et filsystem, etc.) så skal ingen få tilgang til den før det er behov for å ha tilgang til den. Standarden for tilgang til en ressurs er at ingen har tilgang. Tilgang gis ved behov når et sett med kriterier er møtt. Er kriteriene ikke møtt (ikke medlem av riktig gruppe eller ikke tilfredsstiller alle attributtsjekker ved forsøk på aksess) så nektes adgang.
Last ned guide: Alt du bør vite om informasjonssikkerhet
Vi gjennomgår hva informasjonssikkerhet er, de vanligste metodene og hvordan man kan beskytte seg mot angrep.
3. Economy of Mechanism
Prinsippet sier at sikkerhetskontrollere skal være så små og enkle som mulig. Derfor kjøper vi massive enterprisesystemer som koster millioner av kroner og krever en bachelor i klinisk psykologi for å forstå interface-logikken. Jeg mener ikke å si at alle store komplekse systemer er dårlige, tvert imot, men man skal vite at de kommer med et forvaltningsansvar og krever ofte en del kompetanse. Prinsippet adresserer at jo mer komplekst noe er jo større sannsynlighet er det for at vi gjør feil. Dette gjelder både på drift og utviklingssiden. KISS (Keep It Simple, Stupid) er følgeregelen. Jo enklere sikkerhetsdesignet er jo lettere er det å vedlikeholde, oppdatere og endre.
4. Complete Mediation
Prinsippet sier at all tilgang til ressurser skal godkjennes. Hver gang en enhet forsøker å få tilgang til en ressurs skal en mekanisme verifisere om enheten har nødvendige rettigheter til å lese ressursen. Hvis enheten er i riktig rolle eller innehar de nødvendige attributtverdiene skal tilgang gis. Hvis enheten prøver å få tilgang til ressursen igjen skal de samme kontrollsjekkene utføres på nytt. Zero-Trust nettverk er et godt eksempel på denne, hvor man tar som utgangspunkt i at alle noder er kompromittert.
Les mer: 5 sikkerhetstips til applikasjonslogger
5. Åpent Design
Prinsippet sier at kvaliteten på sikkerhetskontrollen ikke skal være avhengig av hemmelighold. Innen kryptografiske løsninger er dette nærmest et must. Bare med åpenhet vil man kunne ha godt testede løsninger. Kerchoff’s prinsipp sier om kryptografi at kvaliteten på den kryptografiske løsningen skal ikke ligge i hemmelighold av algoritmen eller implementasjonen, men i nøkkelen man benytter.
6. Separation of Privilege
Prinsippet sier at når en enhet forsøker å få tilgang til et system skal ikke tilgang gis på bakgrunn av bare ett attributt eller én tilstand. For eksempel kan en tjeneste kreve at en bruker er med i rett gruppe, men også at brukeren utfører handlingen fra en gitt IP adresse eller innen et gitt tidsrom, og kanskje i tillegg kreve at de kan et passord.
7. Least Common Mechanism
Prinsippet sier at mekanismer for tilgang til ressurser ikke skal deles eller at det skal være felleskontoer. Har man en felles bruker som en rekke personer benytter til å utføre spørringer mot sensitive data har man ingen mulighet til å spore hvem som gjorde hva.
8. Psychological Acceptability
Prinsippet sier at en sikkerhetskontroller skal ikke øke kompleksiteten av bruk på en ressurs. Hvis en sikkerhetskontroller føles som et stort hinder og irritasjonsmoment i hverdagen for menneskelige brukere vil de gjøre alt de kan for å komme seg rundt mekanismen som hindrer de. Eksempel: En bruker må koble seg opp mot en database flere ganger om dagen for å gjøre målrettede søk blir bedt om å skrive inn passord hver gang. Brukeren vil da gjøre et gigantisk søk på morgenen, lagre alle dataene et annet sted og søke der resten av dagen. Nå er sensitive data duplisert og flyttet til et nytt område som bare den ene personen vet om, og det er ingen automatiske rutiner for å slette dataene når de ikke trengs lenger.
Les mer: Sikkerhetsekspert: 8 risikoer med å benytte Github eller andre kodehus
9. Defence in Depth
Prinsippet sier at ingen ressurs sin sikkerhet skal være avhengig av en sikkerhetskontroller alene. Det anbefales at man benytter flere kontrollere stegvis nedover i løsningen. Et klassisk eksempel her er brannmuren før den «sikre» (sovepute) sonen. Ingenting har gjort applikasjoner mer sårbare enn den sikre sonen (som blir en sveitserost med tiden uansett). Den har ført til at applikasjoner ikke får prioritert inn egne sikkerhetsmekanismer fordi det antas at lokasjonen den kjører i er trygg. Men prinsippet gjelder over hele fjøla.
I en applikasjon hvor en registrert bruker skal kunne laste opp filer skal applikasjonen først sjekke om dette er fra en bruker som får lov til å laste opp fil. Deretter skal det input valideres om dette er en fil av riktig type, akseptabel størrelse og godkjent format. Deretter skannes for malware og så leses for innholdsvalidering og syntaks i en egen sandbox. Så kan den prosesseres som en del av systemet som forventet, men kanskje noe må enkodes om, osv.
10. Security Bug Fixing
Prinsippet sier at enhver sikkerhetsbug må analyseres, forstås, fikses, testes og monitoreres. Det er også viktig at det dokumenteres og kommuniseres. Er feilen dypt i arkitekturen slik at det kan gjelde flere systemer, eller er det en feil som nylig er oppdaget som krever et paradigmeskifte i hvordan man designer eller utvikler.
Guide: Slik utfører du sikkerhetstesting gjennom utviklingsløpet
Vil du lære mer om sikkerhet og sikkerhetstesting? I denne guiden gjennomgår sikkerhetsekspert Even Lysen hvordan du kan utføre sikkerhetstesting gjennom hele utviklingsløpet.