Een nuttig dreigingsmodel legt uit wat u beschermt, wie of wat er invloed op kan hebben, waar vertrouwen verandert en hoe u de belangrijkste risico's vermindert en test. Begin met het werkelijke project in plaats van een algemene lijst met hulpmiddelen.
Definieer een scope die klein genoeg is om te beredeneren
Begin met één werkende service: een klantenportaal, publicatiesite of interne applicatie. Noteer de componenten die u beheert en de externe systemen waarop u vertrouwt. Een dreigingsmodel moet aannames zichtbaar maken, niet suggereren dat elke mogelijke aanval is opgelost. Houd de eerste versie klein genoeg dat de mensen die de applicatie implementeren deze kunnen uitleggen zonder een aparte consultant die het diagram interpreteert.
Som de waardevolle uitkomsten en assets op. Deze kunnen klantgegevens, beheerderstoegang, betaalstatus, gepubliceerde inhoud en het vermogen om de service te herstellen omvatten. Beschikbaarheid kan een asset zijn, zelfs wanneer de informatie openbaar is. Bepaal welke storingen ongemakkelijk zouden zijn en welke mensen of de organisatie zouden schaden. Dat onderscheid helpt u maatregelen te prioriteren in plaats van elke waarschuwing gelijk te behandelen.
Teken de plaatsen waar vertrouwen verandert
De threat-model-richtlijnen van OWASP gebruiken gegevensstromen en vertrouwensgrenzen om een ontwerp begrijpelijk te maken. Teken voor een kleine gehoste applicatie de browser, het webproces, de database, de beheerder, de back-upbestemming en externe integraties. Markeer de informatie die ertussen beweegt. Een verzoek dat van een niet-vertrouwde client naar een geprivilegieerde serverbewerking gaat, verdient expliciete validatie en autorisatie.
Ga er niet van uit dat elke component even vertrouwd is omdat deze zich op dezelfde machine bevindt. Een openbaar uploadproces mag niet dezelfde rechten hebben als databasebeheer. Een back-uptaak heeft mogelijk leestoegang nodig zonder de mogelijkheid om live applicatierecords te wijzigen. Het scheiden van die rollen maakt het effect van een gecompromitteerde component gemakkelijker in te dammen en de vereiste rechten gemakkelijker te controleren.
Kies concrete faalscenario's
Gebruik een handvol plausibele gebeurtenissen om het ontwerp uit te dagen. Een aanvaller steelt een beheerderswachtwoord; een gebruiker vraagt het record van een andere gebruiker op; een upload vult de schijf; een deployment stelt een configuratiebestand bloot; een herstelkopie kan niet worden hersteld. Beschrijf de uitgangssituatie, de getroffen component en het gevolg. Een specifiek scenario is gemakkelijker te testen dan een brede instructie om de beveiliging te verbeteren.
Neem naast externe indringing ook fouten en misbruik van legitieme workflows op. Een nieuwe poging kan twee waardevolle bewerkingen creëren, of twee verzoeken kunnen racen om hetzelfde object te wijzigen. De richtlijnen van OWASP voor bedrijfslogica benadrukken deze procesaannames. Controleer wie een workflow naar de volgende status mag verplaatsen en of het herhalen of herordenen van een verzoek het resultaat onverwacht verandert.
| Scenario | Te onderzoeken maatregel | Te verzamelen bewijs |
|---|---|---|
| Gestolen beheerdersreferentie | Beperkte toegang en een tweede factor waar ondersteund | Een ongeoorloofde login kan niet worden voltooid |
| Object van een andere gebruiker opgevraagd | Objectautorisatie aan de serverzijde | Een geïsoleerde test geeft een geweigerd resultaat |
| Schijf vol door uploads | Grootte-, quota- en retentiemaatregelen | Een limiet wordt afgedwongen voordat de service uitvalt |
| Dubbel workflowverzoek | Idempotentie en transactiegrenzen | Een herhaald verzoek levert één uitkomst op |
Prioriteer op basis van impact en een geloofwaardig pad
Noteer voor elk scenario de mogelijke impact en de voorwaarden waaronder het kan optreden. Doe niet alsof een geraden numerieke score een precieze waarschijnlijkheid is. U kunt nog steeds een zwak wachtwoord dat aan internet is blootgesteld onderscheiden van een zeer voorwaardelijke lokale gebeurtenis. Wijs een eigenaar en een praktische volgende stap toe aan de belangrijke risico's, zodat het model werk oplevert dat iemand daadwerkelijk kan voltooien.
Overweeg naast applicatiecompromittering ook de levenscyclus van informatie. Een diagnostische export kan onnodige gegevens onthullen tijdens verder normale bedrijfsvoering. Een bewaard accountveld kan blootstelling creëren lang nadat het doel ervan is vervallen. Privacybeoordeling kan daarom informatie verwijderen of retentie verkorten, terwijl beveiligingsbeoordeling de toegang tot wat overblijft beperkt. Beide wijzigingen horen in het model wanneer ze het project beschermen.
Test de maatregelen in een geautoriseerde omgeving
Maak een stagingomgeving met representatieve rechten en fictieve records. Test geweigerde toegang, aanvraaglimieten, workflowpogingen en herstel. Gebruik geen echte klantgegevens wanneer synthetische gegevens het gedrag kunnen aantonen. Het doel is de beheersmaatregel te verifiëren, niet om indrukwekkend aanvalsverkeer te genereren. Blijf binnen systemen die u bezit of waarvoor u expliciet toestemming hebt om ze te beoordelen.
Leg vast wat is geslaagd, wat is mislukt en wat onbekend blijft. Een scannerresultaat kan bewijs leveren, maar vervangt geen test van de bedrijfsregels van de applicatie. Evenzo verifieert een netwerkbeveiligingsoptie niet de objectautorisatie of het omgaan met geheime bestanden. Voeg de nuttige resultaten toe aan het scenario, zodat toekomstige beheerders begrijpen waarom een bepaalde beheersmaatregel bestaat.
Houd het model verbonden met verandering
Beoordeel de relevante onderdelen wanneer u een integratie toevoegt, een nieuw eindpunt beschikbaar stelt, een privilege wijzigt of gegevens naar een andere bestemming verplaatst. U hoeft niet de hele architectuur opnieuw te tekenen voor een kleine tekstwijziging. De aanleiding is een gewijzigde aanname over toegang, informatie of systeemgedrag. Bewaar het model naast de implementatie- en hersteldocumentatie in plaats van het als een eenmalige workshopuitkomst te laten liggen.
SwissOctet biedt een catalogus van infrastructuurkeuzes, geen voltooid dreigingsmodel voor een applicatie. Kies de configuratie en opties die uw beheersmaatregelen ondersteunen en verifieer vervolgens de implementatie die u bouwt. Een klein, onderhouden model met geteste acties is nuttiger dan een grote verzameling beveiligingsproducten zonder duidelijke uitleg van de risico's die ze aanpakken.
Uw praktische checklist.
- Inventariseer assets en gevolgen van falen.
- Teken gegevensstromen en vertrouwensgrenzen.
- Kies specifieke scenario's voor indringing, fouten en workflows.
- Wijs beheersmaatregelen en eigenaren toe aan de belangrijke risico's.
- Test met synthetische gegevens in een geautoriseerde omgeving.
- Herzie het model wanneer een relevante aanname verandert.
De details die ertoe doen.
Heb ik een formeel framework nodig om te beginnen?+
Nee. Een klein diagram en een gedocumenteerde set scenario's kunnen nuttig zijn. Een framework helpt u risico's consistent te beoordelen.
Vervangt een kwetsbaarheidsscanner dreigingsmodellering?+
Nee. Scanners kunnen technische zwakheden vinden, terwijl een dreigingsmodel ook ontwerpaannames, machtigingen en bedrijfsworkflows onderzoekt.
Hoe vaak moet ik het model bijwerken?+
Werk de betrokken onderdelen bij wanneer gegevensstromen, integraties, privileges of blootgestelde functionaliteit veranderen, en beoordeel onopgeloste risico's regelmatig.
Ga naar de bron.
Deze referenties ondersteunen de technische concepten in deze gids. Volg de actuele documentatie voordat u een productiesysteem wijzigt.
- OWASP: Threat Modeling Cheat Sheet cheatsheetseries.owasp.org
- OWASP: Threat modelling in practice devguide.owasp.org
- OWASP: Business Logic Security cheatsheetseries.owasp.org
Redactionele begeleiding door SwissOctet. Voorbeelden zijn illustratief. Dienstspecificaties, beschikbare opties en contractuele voorwaarden moeten afzonderlijk worden geverifieerd.