Hotmodellering för en liten plattform

Hotmodellering har ryktet om sig att vara ett företagsritual med diagram som ingen läser. Det behöver inte vara så. För en liten plattform tar den användbara versionen en timme, ger en rangordnad lista, och det viktigaste resultatet är att veta vilka risker dina infrastrukturval faktiskt påverkar — för de flesta av dem är det ärliga svaret: inga.

Ordning väger tyngre än fullständighet

Det klassiska misstaget är en lång lista över allt som kan gå fel, där allt behandlas som lika akut. Det leder till handlingsförlamning, och sedan ändå till ett beslut som fattas på magkänsla. En rangordnad lista med sju punkter är mer värd än en uttömmande lista med fyrtio, eftersom du kommer att agera på de tre första och ändå aldrig når resten.

Rangordna efter sannolikhet × kostnad för dig, inte efter hur skrämmande scenariot låter. En statlig motståndare är den mest skrämmande punkten på vilken lista som helst och, för nästan varje liten plattform, den minst sannolika — medan ett läckage av inloggningsuppgifter från en tidigare konsult är tråkigt, extremt vanligt och oftast katastrofalt.

Sju motståndare, rangordnade efter sannolikhet

Motståndare efter sannolikhet och vad som motverkar dem

Motståndare	Sannolikhet	Hosting hjälper	Vad som faktiskt hjälper
Du, på en dålig dag	Säkert	Nej	Säkerhetskopior som du faktiskt har återställt från, och en ändringsprocess för allt som rör autentisering eller DNS. Den troligaste orsaken till ditt värsta driftstopp är du själv.
Automatiserad skanning	Konstant	Nej	Patchning, ingen lösenordsautentisering, inga standardinloggningsuppgifter. Det här är bakgrundsstrålning; det riktar sig inte specifikt mot dig, och det upphör aldrig.
Kompromettering av inloggningsuppgifter	Hög	Nej	En hårdvarubaserad andra faktor, avgränsade API-token, och att återkalla åtkomst samma dag som någon slutar i stället för kvartalet efter.
En anmälare med ett formulär	Hög	Ja	Det här är det enda fall som leverantörens jurisdiktion faktiskt påverkar: om enbart korrespondens kan stänga ner din tjänst.
Volymetrisk attack	Medel	Delvis	Filtrering uppströms, och specifikt en leverantör som filtrerar i stället för att null-routa dig för att skydda sig själv.
En riktad inkräktare	Låg	Nej	Segmentering, minsta möjliga behörighet, krypterad lagrad data, och loggar på en plats där inkräktaren inte kan ändra dem.
En statlig aktör	Mycket låg	Delvis	Jurisdiktionen formar den juridiska vägen, inte den tekniska. Om det här verkligen ingår i din modell, skaffa juridisk rådgivning i stället för en hostingplan.

Vilka som påverkas av ett hostingbeslut

Två av sju, och delvis en tredje. Det förhållandet är ensamt det mest användbara resultatet av övningen. Att göra den innan du väljer leverantör sparar därför mer pengar än vilken jämförelsetabell som helst.

Entimmesversionen

1. Lista vad du faktiskt har (10 min). Inte system — data. Användares e-postadresser, betalningsuppgifter, privata meddelanden, uppladdade filer, inloggningsuppgifter till andra tjänster. Skriv ner vad som vore värst att förlora och vad som vore värst att läcka; det är sällan samma sak.
2. Lista vem som skulle vilja åt vardera (10 min). Var konkret. ”Hackare” är ingen motståndare; ”någon som köper läckta inloggningsuppgifter för att sälja vidare konton” är det, och det innebär andra försvarsåtgärder.
3. Rangordna efter sannolikhet × kostnad (10 min). Bortse från hur dramatiskt varje punkt låter. De tråkiga punkterna dominerar.
4. Skriv ner den första timmen för de tre översta (20 min). Vad du skulle göra under de första sextio minuterna av var och en. Om du inte kan svara på det är just det resultatet — och det är mer värdefullt än själva rangordningen.
5. Markera vilka som påverkas av infrastrukturval (10 min). Vanligtvis två av de fem översta. Nu vet du vad ditt hostingbeslut faktiskt köper.

Gör om övningen när något grundläggande förändras — en ny datatyp, en ny integration, någon som slutar — i stället för enligt ett fast schema. Kalenderstyrda genomgångar hoppas över; händelsestyrda genomförs, eftersom det finns en konkret anledning framför dig.

Tre misstag som gör hela övningen meningslös

Att modellera den motståndare du tycker är intressant. Det är roligare att fundera på vad en nationalstat kan åstadkomma än på ett läckt API-token i ett publikt repository. En av dem har hänt nästan alla du känner. Rangordna ärligt, så vinner de tråkiga punkterna — och det är just poängen.

Att blanda ihop en åtgärd med ett resultat. ”Vi använder kryptering” är ingen begränsande åtgärd förrän du kan säga vad den stoppar och vad den inte stoppar. Fullständig diskkryptering på en körande server skyddar mot att en disk lämnar byggnaden; den gör ingenting mot en inkräktare med ett skal på den levande maskinen, eftersom volymen redan är upplåst.

Att producera ett dokument i stället för ett beslut. Om ingenting förändrades efter övningen — ingen behörighet återkallad, ingen säkerhetskopia testad, ingen fråga ställd till leverantören — var det ingen hotmodellering, det var en eftermiddag. Resultatet bör vara tre åtgärder med namn kopplade till sig.

Om raden om anmälaren är den som dominerar din tabell, är nästa fråga vilken jurisdiktion som gäller och hur du kan verifiera vad en leverantör påstår om den — sex frågor, möjliga att besvara på en eftermiddag. Förekommer den inte alls bland dina fem översta, behöver du förmodligen inte oss, och det är ett fullt godtagbart resultat för en timmes arbete.

Skrivet av de ingenjörer som driver plattformen, och omläst för 1 månad sedan. Om något här är fel eller har blivit inaktuellt, säg till via panelen – det är därifrån ungefär hälften av dessa kommer.