Trusselmodellering for team som aldri har gjort det

Avmystifiseringen

Trusselmodellering er ikke et rammeverk du må sertifiseres i. Det er ikke et dokument på førti sider. Det er ikke noe du trenger en innleid spesialist for å komme i gang med.

Det er en strukturert måte å stille et spørsmål på – et spørsmål teamet ditt allerede burde stille:

«Hvordan kan dette gå galt – med vilje?»

Vanlig designtenkning spør hvordan ting kan feile. Trusselmodellering spør hvordan ting kan angripes. Forskjellen er en motpart med intensjon, og den forskjellen endrer hva man ser.

Øvelsen: Fire spørsmål, én tavle, én time

De fire spørsmålene under er ikke mine. De er rammeverket Adam Shostack formulerte – først i Threat Modeling: Designing for Security (2014), her gjengitt i dagens ordlyd, med manifestets «nok» i det fjerde – og Threat Modeling Manifesto bygger på dem. Jeg gjengir dem fordi de er de beste som finnes, og fordi det å vite at de har en kilde gjør dem lettere å forsvare i et møte enn «noe tech leaden fant på».

Samle teamet foran en tavle. Tegn systemet; bokser og piler holder. Still så de fire spørsmålene, i rekkefølge:

1. Hva jobber vi med? Tegn dataflyten: hvor kommer data inn, hvor lagres de, hvor går de ut, hvem snakker med hva. Allerede her kommer ofte de første funnene: en pil ingen visste om, eller en integrasjon halve teamet hadde glemt. Kartet alene er verdt timen.

2. Hva kan gå galt? Nå tenker dere som angriper, langs hver pil og boks: Hva om input her er fiendtlig? Hva om noen utgir seg for å være denne tjenesten? Hva om denne loggen leses av feil person? Hva om dette API-et kalles en million ganger? Ingen fasit kreves, bare den systematiske vandringen langs kartet. Skriv alt ned; vurder ingenting ennå.

Går teamet tomt for ideer etter ti minutter – og det gjør de fleste første gang – finnes det en huskeliste: STRIDE, laget av Loren Kohnfelder og Praerit Garg hos Microsoft i 1999 og i bruk siden; originalnotatet ligger fortsatt ute. Seks kategorier å holde opp mot hver boks og hver pil: Spoofing (utgi seg for noen), Tampering (endre data), Repudiation (nekte for å ha gjort noe, uten at sporene motsier det), Information disclosure (lekkasje), Denial of service og Elevation of privilege. Seks ord på en lapp på tavla er hele verktøyet, og de tar dere fra «vi kommer ikke på mer» til en halvtime til med funn.

3. Hva gjør vi med det? Sortér funnene i fire hauger: fiks (tett hullet), reduser (gjør skaden mindre: minste tilgang, rate-limiting), aksepter (bevisst, dokumentert; noen risikoer er levelige), undersøk (vi vet ikke nok ennå). Hver haug får eiere og havner der arbeid faktisk skjer – i backloggen, ikke i et arkiv.

4. Gjorde vi en god nok jobb? Sett en dato for neste runde. Systemet endrer seg; modellen må følge. En trusselmodell fra i fjor beskriver et system som ikke lenger finnes, og den følger samme forfallslov som all annen dokumentasjon.

Hvorfor teamet selv – ikke en ekspert

En innleid spesialist finner sannsynligvis mer, og finner det raskere. Og likevel er teamets egen time mer verdt, av tre grunner:

Teamet kjenner systemet – snarveiene, unntakene, «den rare integrasjonen» ingen rapport fanger. Teamet skal leve med funnene, og eierskap til risiko bygges som alt annet eierskap: gjennom deltakelse, ikke leveranse. Og viktigst: øvelsen trener et blikk. Målet er at spørsmålene etter noen runder dukker opp av seg selv, i designdiskusjoner og PR-er – manifestet kaller det en reise i forståelse fremfor et øyeblikksbilde. Det blikket er den egentlige leveransen, og det kan ikke leies inn.

Eksperten har sin plass: som forsterkning når blikket er etablert, og for systemene der det står mest på spill. Men rekkefølgen er teamet først.

Begynn stygt

Ikke vent på modenhet, verktøy eller noen med riktig tittel.

Book en time. Tegn systemet. Still de fire spørsmålene.

Den første modellen blir ufullstendig – det skal den være. Den er likevel uendelig mye bedre enn den perfekte modellen dere aldri lagde.

Pilen ingen visste om? Ofte dukker den opp i det første kvarteret.