Sitter i möte med ett utvecklingsprojekt. En av utvecklarna ritar upp den övergripande arkitekturen på en whiteboard och där ser jag det… programvaran hämtar uppdateringar av sig själv från en file share i nätverket och kör dem utan vidare kontroller. Hela systemets säkerhet har i princip reducerats till skrivåtkomst till en katalog som sköts av en helt annan avdelning.

Systemet kan inte upptäcka att den nya uppdateringen bara är en kopia av den föregående, fast med en bakdörr, och kommer glatt att skriva över sig själv. Allt som krävs är skrivåtkomst till ett visst filsystem.

Jag har upptäckt ett säkerhetshål. Systemet är sårbart. Alltså måste det åtgärdas.

Eller kanske inte.

Sårbarheter måste inte åtgärdas

De bästa säkerhetshålen är ju de som kan lämnas utan åtgärd. Security is a cost of doing business. Keep it low. Det här känns initialt främmande för oss men är inte alls ovanligt. System av alla möjliga sorter har alla möjliga sorters sårbarheter som ingen har en tanke på att försöka åtgärda:

  • Du kan gå rakt in i en reception och slänga en tegelsten på receptionisten.
  • Som bilist kan du köra över fotgängare.
  • Som fotgängare kan du tända eld på parkerade bilar.
  • Du kan fälla ett stort träd och släpa upp på E4 norrut innan rusningstrafik.
  • På biblioteket kan du lätt förstöra de böcker du ogillar.
  • Under knivhot kan du ta andras pengar.
  • Du kan ljuga på Facebook om hur snabbt du springer milen.

De är alla exempel på sårbarheter som kan utnyttjas. Vi skyddar oss inte nämnvärt mot dem och det känns inte främmande. Varför då?

Det finns flera anledningar.

Det finns inte något att vinna på att kasta tegelstenar på receptionister, samma sak gäller sabotage av böcker. Det är svårt att släpa upp ett träd på E4:an. Det finns inget bra sätt att skydda sig mot knivrån. Dessutom är antalet potentiella rånare väldigt få, de flesta av oss kommer att gå igenom hela livet utan att bli knivrånade. Samma sak gäller mordiska bilister och pyromaniska fotgängare. Det gör inget att någon ljuger om sina löptider.

Vad de alla har gemensamt är att de inte innebär stora problem för oss. Jag vill absolut inte förringa konsekvenserna av att bli knivhotad eller påkörd eller effekterna av förseningar i trafiken. De är enorma. Faktum kvarstår dock: åtgärder för att förhindra utnyttjande av våra sårbarheter är ibland oproportionerligt dyra.

När du ställs inför en sårbarhet bör du ställa dig massor av frågor:

  • Vad vinner en angripare på att utnyttja sårbarheten?
  • Kan det vara så att någon gör det bara for the lulz?
  • Innebär det risker för angriparen att utnyttja den?
  • Är det svårt att utnyttja sårbarheten?
  • Finns det några tänkbara angripare? Är de många?
  • Är det ens möjligt att skydda sig?

Listan är knappast uttömmande, jag kan tänka mig fler frågor, exempelvis hur ofta sårbarheten finns, hur många som har möjlighet att utnyttja den och så vidare. Många skriver under på att det här är självklarheter och det är inte meningen att förolämpa dig.  Jag upplever dock ofta att den enda frågan som ställs är konsekvensfokuserad: ”Vad kan vi förlora?” när det vi egentligen vill veta är om åtgärden innebär mer besvär än nytta.

Det är det här som gör säkerhet svårt i praktiken. Att skapa säkra system är bara svårt i teorin, i praktiken är det enkelt. Det räcker med att överdriva: lägg på för många säkerhetskrav, begär alltid mer dokumentation, gå ner på för små detaljer, driv dem för hårt, lita inte på någon, granska för länge och för ofta. Baksidan är att du blir fattig och impopulär.

Till skillnad från vad du kanske har hört så är säkerhetsarbete på företag faktiskt en populäritetstävling. Impopulära säkerhetsgrupper är livsfarliga.

Avvägningar, avvägningar, avvägningar

Det är alltid fråga om avvägningar. Tänk dig en amerikansk diplomat, hon kan lugnt slappna av framför teven på hotellrummet i Washington trots att hon är väldigt viktig och i allra högsta grad sårbar mot knivhugg. Däremot borde hon ha en skyddsväst och ett rejält närskydd när hon ska rumla hem full genom en favela i Rio på natten.

Precis som knivhugg är SQL injection en mycket allvarlig attack. På samma sätt är det också en avgörande skillnad mellan att ha sårbarheten i sökfunktionen på DN.se och i tidningens fakturasystem på deras interna nätverk, efter inloggning, som bara tolv personer har åtkomst till. Informationens känslighet är givetvis en viktig faktor, men det är inte den enda. Är ditt system berusad och ensam i en favela eller i tryggt förvar på ett hotellrum?

I nästa del tänker jag gå in på särfall och när sårbarheter omedvetet lämnas utan åtgärd. Det  är lite av ett minfält så jag tar det separat.


Hur gick det med sårbarheten i uppdateringsfunktionen då? Jo, systemet är väldigt känsligt men den lämnades faktiskt utan åtgärd.

Det är nog inte svårt att få åtkomst till lagringsytan men att föra in en meningsfull bakdörr i en uppdatering är inte något för vem som helst. Även om bakdörren inte behöver vara särskilt sofistikerad. Vidare är uppdateringar sällsynta, sannolikt skulle det upptäckas och rapporteras ganska snart utan särskilda förberedelser. Dessutom, ett starkt skydd innebär signering av koden och validering av signaturer. En sådan funktion är en enorm uppgift att införa som kommer att kräva inblandning från flera grupper i organisationen, inte bara under utvecklingen utan under fortsatt drift. Det finns förstås åtgärder som är enklare men inte innebär samma skydd, exempelvis att (regelbundet) revidera behörighetslistor till katalogen eller att jämföra med en enkel hash som hämtas från en annan plats. Kanske kan vi upprätta file integrity monitoring på servern för att upptäcka nya uppdateringar.

Det finns många sätt. Inget sätt är gratis.