Föreställ dig ett kök i en snabbmatsrestaurang. Alla som jobbar där vet att handhygien är avgörande för restaurangens kundsäkerhet och kommersiella framgång (ingen vill äta någonstans där man riskerar matförgiftning). Men det enda handfatet är placerat vid omklädningsrummet utanför restaurangköket. Under lunchrusningen blir tempot i köket avgörande för att kollegorna vid kassadisken ska kunna sköta sitt jobb och för att undvika arga kunder. Här hamnar restaurangens säkerhetsrutiner i konflikt med lojaliteten med kollegorna och med restaurangens affärsmål. Är det då ett kunskapsproblem om medarbetare väljer att tumma på rutinerna? Eller är det en brist i kökets design? De flesta skulle svara det senare.

På samma sätt är det med säkerhetsarkitektur. Den behöver konstrueras så att det är så lätt som möjligt att göra rätt. Vi behöver vara secure by design. Och där finns det ett antal väl etablerade principer att följa.

Redan 1975 beskrev Saltzer och Schroeder åtta principer som fortfarande är centrala för säker systemdesign: minsta privilegium (Least Privilege), nekad åtkomst som utgångsläge (Fail-safe defaults), enkla och begripliga säkerhetsmekanismer (Economy of mechanism), kontroll av varje åtkomstförsök (Complete mediation), öppen design (Open design), uppdelning av särskilt känsliga privilegier (Separation of privilege), minimering av delade mekanismer (Least common mechanism) och – inte minst – att säkerheten måste vara psykologiskt acceptabel (Psychological acceptability), alltså fungera ihop med hur människor faktiskt arbetar. Det sista är särskilt viktigt här. Om säkerheten upplevs som ett hinder kommer den förr eller senare att rundas.

Låt oss gå igenom vad principerna innebär en och en:

Least Privilege

I korthet: Ingen ska ha tillgång till något de inte behöver. Det är en enkel princip som innebär att om du vill undvika att fel person får tillgång till system eller information så ska du heller inte ge dem rättigheter de inte behöver. Att undvika onödigt generösa behörigheter skyddar mot misstag, mot angrepp och mot att någon misstänks för att agera på ett otillbörligt sätt. Dessutom blir det mycket lättare att utreda eventuella säkerhetsbrister eller attacker.

Fail-safe Defaults

Det är svårt att förutse allt som kan gå fel, men det är desto lättare att lista vad som ska vara tillåtet. Därför ska vi också bygga våra system efter principen att vi listar vad som är tillåtet, inte vad som ska vara förbjudet. I säkerhetsvärlden pratar vi om vitlistning – det vill säga att bara det som finns på listan är tillåtet – och svartlistning – bara det som ingår i listan är förbjudet. Svartlistning innebär i praktiken att vi tillåter allt vi glömt eller inte förutsätt. Så vill vi inte ha det.

Economy of Mechanism

Här handlar det helt enkelt om att se till att funktioner byggs på ett sätt som är så enkelt att följa som möjligt. Det finns rent empiriskt en direkt korrelation mellan antalet rader kod och förekomsten av buggar, och vi vet att komplexitet öppnar för sårbarhet.  Genom att undvika krångliga processer och vara ekonomiska i vår användning av kod skapar vi förutsättningar för säkra system. Och rent praktiskt: Hur många kodrader vill du egentligen granska?

Complete Mediation 

Detta innebär att varje försök till access till varje objekt ska kontrolleras utifrån behörighet. Detta är särskilt viktigt när vi integrerar olika system med varandra eller i den värld vi lever i idag där stora delar av (eller all) våra skyddsvärda data ligger i olika molntjänster. Om kontroller kan rundas eller om jag kan få saker gjorda i någon annans namn skapar vi potentiella problem.

Open Design

En bra systemdesign behöver inte vara hemlig. Den är säker ändå. Vi ska helt enkelt inte behöva förlita oss på att hackers okunskap för att skydda oss. I stället är det nycklar och lösenord som vi ska skydda. Att ha en öppen design med kända algoritmer innebär också att vi kan ha högre tilltro till systemen när vi vet att det inte bara är upp till oss att testa systemen, eftersom utvecklare och tillverkare kan dela information med varandra om eventuella brister. 

Separation of Privilege 

Alla som sett nog med Hollywoodthrillers har sett hur känsliga processer, som avfyrandet av kärnvapen, kräver två separata nycklar för att initieras. Detsamma gäller särskilt känsliga operationer i våra system. För att öka robustheten bör vi därför se till att ingen kan utföra sådana operationer på egen hand. Här ska vi dock vara noggranna med vilket slags åtgärder som vi bedömer vara så känsliga och skyddsvärda eftersom det här är något som av naturliga skäl kommer i konflikt med tillgängligheten. Om vi placerat handfatet i vårt restaurangexempel ovan bakom dubbla lås hade båda nycklarna snart hängt på en krok utanför dörren.

Least Common Mechanism

Principen om minsta gemensamma funktion  säger att vi ska begränsa antalet funktioner eller resurser i ett system som delas av flera användare. Vi ska alltså i så hög grad som möjligt isolera användare och processer från varandra för att förhindra oavsiktliga interaktioner och säkerhetsläckor. Det gör också att vi kan minska risken för dominoeffekter om en användare utsätts för en attack eller skadlig kod.

Psychological Acceptability

Här har vi vårt restaurangexempel igen, som är den princip vi måste väga alla de andra principerna emot. Om vi bygger system som är idiotsäkra men som i praktiken hindrar användare från att göra sitt jobb så kommer de snart att leta efter genvägar för att komma runt det. Det är då vi riskerar att göra lojala medarbetare till säkerhetsrisker, och eftersom dina användare som regel är din svagaste länk så kan detta vara den faktor som stjälper hela bygget. Ytterst handlar det om UX, användarupplevelsen. Om du förstår hur dina användare vill använda systemet, så kan du också bygga upplevelsen, UX:et, så att den inte fäller krokben för dem.