Threat modelling voor een klein platform

Dreigingsmodellering staat bekend als een bedrijfsritueel met diagrammen die niemand leest. Dat hoeft niet zo te zijn. Voor een klein platform duurt de nuttige versie een uur, levert een gerangschikte lijst op, en het belangrijkste resultaat is weten welke risico's uw infrastructuurkeuzes überhaupt raken — want bij de meeste luidt het eerlijke antwoord: geen enkel.

Volgorde telt meer dan volledigheid

De klassieke fout is een lange lijst van alles wat mis kan gaan, waarbij elk punt als even urgent wordt behandeld. Dat leidt tot verlamming, en uiteindelijk toch tot een beslissing op gevoel. Een gerangschikte lijst van zeven punten is meer waard dan een uitputtende lijst van veertig, want u zult toch alleen naar de eerste drie handelen en de rest nooit bereiken.

Rangschik naar waarschijnlijkheid × kosten voor u, niet naar hoe alarmerend het scenario klinkt. Een statelijke tegenstander is het meest angstaanjagende punt op elke lijst en, voor bijna elk klein platform, het minst waarschijnlijke — terwijl een lek van inloggegevens door een voormalige opdrachtnemer saai, extreem vaak voorkomend en meestal catastrofaal is.

Zeven tegenstanders, gerangschikt naar waarschijnlijkheid

Tegenstanders naar waarschijnlijkheid en wat daartegen helpt

Tegenstander	Waarschijnlijkheid	Hosting helpt	Wat er daadwerkelijk tegen helpt
U, op een slechte dag	Zeker	Nee	Back-ups waaruit u daadwerkelijk hebt hersteld, en een wijzigingsproces voor alles wat authenticatie of DNS raakt. De meest waarschijnlijke oorzaak van uw ergste storing bent uzelf.
Geautomatiseerd scannen	Constant	Nee	Patchen, geen wachtwoordauthenticatie, geen standaard inloggegevens. Dit is achtergrondruis; het is niet specifiek op u gericht en het stopt nooit.
Compromittering van inloggegevens	Hoog	Nee	Een hardwarematige tweede factor, API-tokens met beperkte scope, en toegang intrekken op de dag dat iemand vertrekt in plaats van het kwartaal erna.
Een klager met een formulier	Hoog	Ja	Dit is het enige geval waarvoor de jurisdictie van uw hosting daadwerkelijk uitmaakt: of correspondentie alleen uw dienst kan platleggen.
Volumetrische aanval	Gemiddeld	Deels	Filtering upstream, en specifiek een aanbieder die filtert in plaats van u via null-routing af te sluiten om zichzelf te beschermen.
Een gerichte indringer	Laag	Nee	Segmentatie, minimale rechten, versleutelde gegevens in rust, en logs op een plek waar de indringer ze niet kan wijzigen.
Een statelijke actor	Zeer laag	Deels	Jurisdictie bepaalt de juridische route, niet de technische. Als dit daadwerkelijk in uw model past, zoek dan juridisch advies in plaats van een hostingpakket.

Welke daarvan een hostingkeuze raakt

Twee van de zeven, en deels een derde. Die verhouding is op zichzelf al het nuttigste resultaat van de oefening, en daarom bespaart u door dit te doen vóór het kiezen van een aanbieder meer geld dan met welke vergelijkingstabel dan ook.

De eenurige versie

1. Lijst op wat u daadwerkelijk in bezit hebt (10 min.). Geen systemen — gegevens. E-mailadressen van gebruikers, betalingsgegevens, privéberichten, geüploade bestanden, inloggegevens voor andere diensten. Noteer wat het ergste zou zijn om kwijt te raken en wat het ergste zou zijn om te lekken; dat is zelden hetzelfde.
2. Lijst op wie elk daarvan zou willen (10 min.). Wees specifiek. “Hackers” is geen tegenstander; “iemand die dumps van inloggegevens koopt om accounts door te verkopen” wel, en dat vraagt om andere verdediging.
3. Rangschik naar waarschijnlijkheid × kosten (10 min.). Negeer hoe dramatisch elk punt klinkt. De saaie punten domineren.
4. Schrijf voor de top drie het eerste uur uit (20 min.). Wat u zou doen in de eerste zestig minuten van elk. Als u dat niet kunt beantwoorden, is dat de bevinding — en die is waardevoller dan de rangschikking zelf.
5. Markeer welke worden beïnvloed door infrastructuurkeuzes (10 min.). Meestal twee van de top vijf. Nu weet u wat uw hostingkeuze daadwerkelijk oplevert.

Herhaal de oefening wanneer er iets structureels verandert — een nieuw type gegevens, een nieuwe integratie, iemand die vertrekt — in plaats van volgens een vast schema. Op de kalender gebaseerde herzieningen worden overgeslagen; gebeurtenisgedreven herzieningen worden wél uitgevoerd, omdat er een concrete aanleiding voor u ligt.

Drie fouten die de hele oefening zinloos maken

De tegenstander modelleren die u interessant vindt. Nadenken over de mogelijkheden van een natiestaat is leuker dan over een gelekt API-token in een openbare repository. Het een is bijna iedereen die u kent al overkomen. Rangschik eerlijk en de saaie punten winnen — dat is precies de bedoeling.

Een maatregel verwarren met een resultaat. “We gebruiken versleuteling” is geen mitigatie zolang u niet kunt zeggen wat het tegenhoudt en wat niet. Volledige schijfversleuteling op een draaiende server beschermt tegen een schijf die het gebouw verlaat; het doet niets tegen een indringer met een shell op de actieve machine, omdat het volume dan al is ontgrendeld.

Een document opleveren in plaats van een beslissing. Als er na de oefening niets is veranderd — geen rechten ingetrokken, geen back-up getest, geen vraag aan de aanbieder gesteld — was het geen dreigingsmodel, maar een middag. Het resultaat moet drie acties zijn, elk met een naam eraan gekoppeld.

Als de rij met de klager degene is die uw tabel domineert, is de volgende vraag welke jurisdictie geschikt is en hoe u kunt verifiëren wat een aanbieder daarover beweert — zes vragen, in een middag te beantwoorden. Staat hij helemaal niet in uw top vijf, dan hebt u ons waarschijnlijk niet nodig, en dat is een prima resultaat voor een uur werk.

Geschreven door de engineers die het platform beheren, en herzien op 1 maand geleden. Als hier iets onjuist is of verouderd is geraakt, meld dat via het klantenpaneel — dat is waar ongeveer de helft hiervan vandaan komt.