Säkerhet behandlas i de flesta organisationer som en kontrollfunktion. Något som granskar, godkänner och ibland stoppar. Den modellen har en inbyggd svaghet: den placerar säkerhet i slutet av arbetet, där ändringar är dyrast och där den som ska genomföra dem har minst tid kvar.
Vi har haft bättre resultat av att behandla säkerhet som en kvalitetsegenskap i produkten, jämförbar med prestanda eller tillgänglighet. Det är inte en omformulering utan en organisatorisk skillnad: kvalitetsegenskaper ägs av teamet som bygger, mäts löpande och prioriteras mot annat arbete i samma backlogg.
Varför granskning i slutet inte räcker
En säkerhetsgranskning två veckor före driftsättning kan hitta problem men sällan åtgärda dem. Det som upptäcks är ofta arkitektoniskt: en förtroendegräns på fel ställe, en behörighetsmodell som inte går att uttrycka i det som byggts, en logg som innehåller sådant den inte borde. Det är veckors arbete, och besked om det kommer när tidplanen redan är spänd.
Vad som händer då är förutsägbart. Fyndet får en riskklassificering, en åtgärdsplan och ett datum som ligger efter lansering. Sedan lanseras produkten, teamet går vidare till nästa sak, och åtgärdsplanen ligger kvar i ett dokument. Vi har läst många sådana dokument. De är alltid välskrivna och sällan genomförda.
Det här är inte säkerhetsfunktionens fel. Det är en konsekvens av var i flödet den placerats. Samma personer som skriver rapporter ingen läser blir ovärderliga när de sitter med i designdiskussionen fyra månader tidigare, eftersom då kostar samma synpunkt en eftermiddag i stället för tre veckor.
Hotmodellering på en timme
Den enskilt mest kostnadseffektiva säkerhetsaktivitet vi känner till är en strukturerad genomgång på en timme när en ny funktion designas. Inte en formell metod med mallar, utan fyra frågor ställda till teamet av någon som inte byggt lösningen.
Vad hanterar den här funktionen som någon skulle vilja komma åt? Vem får göra vad, och var kontrolleras det? Vad händer om ett anrop kommer utan att gå genom gränssnittet vi tänkt oss? Vad skulle vi behöva veta för att upptäcka att någon missbrukat funktionen?
Den fjärde frågan är den som oftast saknas helt. De flesta team kan svara på de tre första efter en stunds tänkande. På den fjärde blir det tyst, och tystnaden avslöjar att lösningen inte har någon spårbarhet alls. Att inse det medan koden skrivs kostar nästan ingenting. Att inse det under en incident kostar allt.
Bygg in det som går att automatisera
Allt som kan kontrolleras maskinellt ska kontrolleras maskinellt, varje gång, utan att någon behöver komma ihåg det. Beroenden med kända sårbarheter. Hemligheter som råkat hamna i kod. Behörigheter i infrastrukturen som är vidare än de behöver vara. Standardinställningar som lämnats orörda.
Poängen med automatiken är inte främst att den hittar problem, utan att den frigör människorna till det maskiner inte klarar: affärslogikens behörighetsfrågor. Nästan alla allvarliga incidenter vi har sett i moderna system har handlat om att någon kunde komma åt en annan användares data genom ett giltigt anrop med ett ändrat id. Det finns inget verktyg som hittar det åt dig, för det kräver att man vet vem som borde få se vad.
En varning: automatiska kontroller som ger många falska varningar blir ignorerade inom en månad, och sedan ignoreras även de äkta. Det är bättre att ha tre kontroller som alla tas på allvar än trettio som scrollas förbi. Vi lägger hellre en dag på att tysta bruset än en vecka på att lägga till fler regler.
Det obekväma måttet
Om säkerhet ska vara en kvalitetsegenskap måste den mätas som en. Måttet vi föredrar är enkelt och obekvämt: hur lång tid tar det från att en sårbarhet blir känd till att den är åtgärdad i produktion?
Det måttet går inte att förbättra med policy. Det förbättras bara av att organisationen kan driftsätta ofta och tryggt, vilket betyder att det egentligen mäter leveransförmåga. Det är dess styrka. Ett team som kan gå från upptäckt till åtgärd på en dag är säkrare än ett team med dubbelt så många kontrollsteg och en månads ledtid, oavsett hur de två ser ut i en revisionsrapport.
Det förklarar också varför säkerhetsarbete och arbete med snabbare leveranser inte är motsatser, vilket de ofta framställs som. De är samma arbete sett från två håll. Den organisation som kan ändra sitt system snabbt och med förtroende är den som har råd att åtgärda saker när de upptäcks, och det är i praktiken vad säkerhet handlar om.
Var man börjar
Om ingenting av det här finns på plats i dag skulle vi börja med två saker och inget mer. Inför timmen med de fyra frågorna för varje ny funktion av betydelse. Mät tiden från känd sårbarhet till åtgärdad i produktion, och visa siffran för samma personer som ser andra kvalitetsmått.
Båda är billiga, båda ger effekt inom ett kvartal, och båda flyttar säkerhet från något som händer efter arbetet till något som händer under. Resten, verktygen och processerna och rapporterna, är enklare att införa när den flytten redan är gjord.