Security by Design: bygg in cybersäkerhet från början

När gamla IT-beslut blir säkerhetsrisker

Oftast får jag en läsbehörighet, en länk till ett repo och ungefär en halvdag. Arkitekturbilden som skickas med stämde när den ritades. Det som faktiskt ligger i prenumerationen har sedan dess fått ett par undantag, en peering som behövdes för en migrering, en regel som öppnades för en leverantör och ett servicekonto som skapades en fredag. Avståndet mellan bilden och miljön är sällan dramatiskt. Det är bara aldrig noll, och det är i mellanrummet man hittar det som är värt att prata om.

För det man hittar där är nästan aldrig slarv. Det är kompetenta människor som fattat rimliga beslut vid en tidpunkt då konsekvenserna inte gick att se. Nätverkstopologin valdes för att den var enkel att förvalta, vilket den var, för det fanns två arbetsbelastningar och ett team på tre personer som skulle hålla ihop den. Behörighetsmodellen byggdes efter hur ansvaret såg ut just då, vilket var den enda struktur som fanns att utgå ifrån. Ett servicekonto fick de rättigheter det behövde för att integrationen skulle bli klar innan sprinten tog slut. Det fungerade. Därför tittade ingen på det igen, och fyra år senare har det fortfarande skrivrättigheter på en prenumeration där det läser från ett konto.

Inget av det var fel när det hände. Det blev fel när allt annat byggdes ovanpå.

Det är också därför vägen in i ett test så sällan är en sårbarhet. Den är tre saker som var för sig är fullt försvarbara. En tjänst som får nå en annan därför att de ligger i samma segment, en identitet som bär mer rättigheter än den använder, och en gammal komponent som ingen längre äger. Ingen av dem hade stoppat en revision. Tillsammans utgör de en kedja, och kedjan är oftast byggd av beslut, inte av buggar.

Det är där bilden av säkerhet som ett lager börjar svikta. Vi säger att vi ska lägga till säkerhet, höja säkerheten, säkra upp. Alla de formuleringarna antyder att säkerhet är något man applicerar på ett system som redan finns, ungefär som färg. Och det som går att applicera går också att skrapa av, prioritera bort eller skjuta till nästa kvartal. Ett lager är per definition skilt från det som ligger under. Om säkerhet är ett lager är det också valfritt, och det är precis så det behandlas när tiden tar slut.

Varför säkerhetsgranskning i efterhand inte räcker

Vi som arbetar med säkerhet har varit med och byggt den bilden. Vi kommer in i slutet, levererar en rapport med fynd sorterade efter allvarlighetsgrad och går vidare till nästa uppdrag. Jag har skrivit många av de rapporterna och jag tänker fortsätta skriva dem, för de gör verklig nytta. Men formatet har en bieffekt som är värd att säga högt.

En poängsatt lista uppmuntrar till att arbeta uppifrån och ned, och det som hamnar överst är det som går att poängsätta. Ett fynd med hög siffra beskriver en komponent. Det som i praktiken fäller en miljö beskriver ofta ett förhållande mellan komponenter, och förhållanden får sällan höga siffror eftersom de inte är en produkt med en version. Jag har lämnat rapporter där det allvarligaste jag hade att säga stod som en medelallvarlig anmärkning i mitten, för att det handlade om hur två system fick prata med varandra och inte om vad något av dem hade för brist. Den punkten åtgärdas sist, om den åtgärdas.

Och om det enda mötet någon i organisationen har med säkerhetsarbete är en rapportgenomgång två veckor före driftsättning, är det inte konstigt att säkerhet upplevs som en broms. Det är ju bokstavligen den funktion vi gett den.

Så blir Security by Design en del av vardagen

Frasen security in everything är lätt att avfärda som ännu en formulering som ska betyda allt och därför slutar betyda något. Den kritiken är rättvis så länge man inte säger vad den förändrar. Och den handlar inte om mängd. Den föreslår inte fler kontroller, fler verktyg eller fler säkerhetsmänniskor i varje möte. Den handlar om när ett beslut fattas, och om vem som förstår vad det innebär medan det fortfarande går att välja annorlunda.

Skillnaden är mindre dramatisk än den låter. När någon väljer hur en miljö ska segmenteras är det ett säkerhetsbeslut, oavsett om ordet nämns på mötet. När ett team bestämmer att en tjänst ska anropa en annan med en identitet som redan finns, för att slippa skapa en till, är det ett säkerhetsbeslut. När någon pekar ut ett pipeline-steg mot en tagg istället för en version, så att det alltid hämtar det senaste, är det ett säkerhetsbeslut fattat på trettio sekunder, i god tro, av en person som inte hade någon anledning att se det som något annat än ett praktiskt val.

Besluten fattas alltså redan. De fattas bara utan att kallas det, och därför utan den eftertanke som ordet hade dragit med sig.

Det finns ett enkelt sätt att märka dem i stunden. Om valet avgör vem som kan nå vad, vilka rättigheter en identitet bär, vad allt som byggs härnäst kommer att ärva, eller om någon om arton månader kommer att kunna förstå varför det blev så, då är det ett säkerhetsbeslut. Inte ett viktigt beslut nödvändigtvis, och inte ett som behöver eskaleras. Bara ett som förtjänar två meningar någonstans innan ni går vidare.

Säkerhetsverktyg kan inte ersätta genomtänkta beslut

Det är den delen som är obekväm, för den går inte att köpa sig ur. Man kan skanna beroenden, granska infrastruktur som kod och stoppa en deployment med en policy innan den når produktion. Det är bra saker och jag rekommenderar dem ofta. Men även en kontroll som körs före driftsättning körs långt efter beslutet. En regel som nekar publika adresser är utmärkt, och den skrevs ändå efter att någon redan bestämt att arkitekturen behöver dem. Verktyget hittar konsekvensen. Beslutet fattades i mars, på ett möte där ingen antecknade att det var ett beslut.

Invändningen här är att vi faktiskt har metoder för det. Vi har i tjugo år kunnat sätta oss ned med en ritning och systematiskt gå igenom vad som kan gå fel, vem som kan utge sig för att vara någon annan, vad som kan ändras utan att någon märker det och vad som kan sluta gå att härleda i efterhand. Metoderna fungerar. Problemet är att vi gör dem till händelser. En halvdag i ett rum, ett resultat som dokumenteras, och sedan tolv månader av vardag däremellan. Besluten fattas inte på halvdagen. De fattas på tisdagarna, i ett kort samtal mellan två personer som behöver komma vidare, och där finns metoden inte med.

Fyra typer av säkerhetsbeslut som påverkar cybersäkerheten

Det senaste året har jag börjat se ett mönster i vilka av de här valen som faktiskt biter oss. De är inte slumpmässigt fördelade. De hamnar i fyra fickor, och vilken ficka de hamnar i avgör hur svårt problemet blir att upptäcka.

En del beslut fattas så tidigt att de hinner bli förutsättningar innan någon kommer på tanken att ifrågasätta dem. Andra har vi delegerat utan att märka det, till människor vi aldrig träffat och inte kan namnge. En tredje sort går inte att läsa i efterhand, eftersom kedjan visserligen finns men inte låter sig förklaras. Och så finns den sista sorten, beslutet som fattades en gång och sedan aldrig fattades igen, det som fortsätter gälla av den enkla anledningen att ingenting ännu tvingat oss att titta på det.

Det är de fyra delar som följer i den här serien. Ingen av dem handlar om ett verktyg, och ingen kräver att man bygger om något stort. De handlar om att göra beslut synliga medan de fortfarande är beslut, vilket är en betydligt billigare övning än den vi annars gör på tisdagseftermiddagen tre dagar före driftsättning.

För det som slår mig när jag går igenom det som gått fel, hos kunder, i vår egen miljö och i mina egna projekt, är hur sällan det började med att någon valde dumt.

De flesta säkerhetsproblem börjar inte i ett dåligt beslut. De börjar i ett beslut som ingen märkte att de fattade.