Dreigingsmodellering: architectuur, aanvalsscenario’s en maatregelen
Sytance · Bijgewerkt
Dreigingsmodellering is een gestructureerde manier om vast te stellen hoe een product kan worden aangevallen en maatregelen te kiezen om het risico te verminderen. De analyse begint bij de productarchitectuur en beschrijft hoe een aanval kan slagen, wat daardoor wordt beïnvloed en hoe de voorgestelde bescherming wordt gecontroleerd.
Productversie en implementatie
Een dreigingsmodel geldt voor een specifieke productversie en implementatie. Een gateway die met internet is verbonden en dezelfde gateway op een geïsoleerd onderhoudsnetwerk kunnen verschillende toegangspunten en bedrijfsomstandigheden hebben.
Betrek mensen met kennis van de architectuur, ontwikkeling, het productgebruik en beveiliging. Verzamel vóór de sessie voldoende materiaal om de normale werking van begin tot eind uit te leggen.
- De release, ondersteunde implementatie en beoogde gebruikers.
- De architectuur, externe interfaces en uitgewisselde gegevens.
- De bevoegdheden van elke gebruiker, dienst en lokaal proces.
- De gevoelige gegevens, inloggegevens en productfuncties die moeten worden beschermd.
- De bestaande maatregelen en aannames die nog moeten worden bevestigd.
Gegevensstromen en vertrouwensgrenzen
Een gegevensstroomdiagram (DFD) toont externe entiteiten, processen, gegevensopslag en gegevensverplaatsing. Een vertrouwensgrens markeert een verandering in vertrouwen of bevoegdheid. Die kan liggen tussen een browser en een API, tussen twee besturingssysteemaccounts of tussen een apparaat en een externe dienst.
Geef elke stroom een richting, een beschrijving van de gegevens en een beschermingsmechanisme. Een vak met het label “cloud” verbergt te veel als verschillende diensten andere identiteiten en machtigingen hebben. Splits het vak wanneer dat verschil de analyse verandert.
Begin voor het voorbeeld van de industriële gateway met de browser van de operator, de gatewaybeheer-API, de lokale configuratieopslag, de lokale controller, de telemetriedienst en de updatedienst. Toon beheer en telemetrie als TLS-verbindingen. Behandel verificatie van de updatesignatuur als een voorgestelde maatregel totdat is vastgesteld dat deze is geïmplementeerd.
Van STRIDE-categorieën naar aanvalsscenario’s
STRIDE groepeert dreigingen in spoofing, manipulatie, ontkenning, openbaarmaking van informatie, denial of service en verhoging van bevoegdheden. Gebruik deze categorieën om vragen te stellen over elk relevant proces en elke relevante stroom. Alleen de categorienaam beschrijft geen aanval.
Bijvoorbeeld: een gebruiker met alleen-lezen-toegang stuurt rechtstreeks een verzoek tot configuratiewijziging naar de beheer-API. Als de API de aanmelding controleert maar niet de bevoegdheid voor de actie, kan de gebruiker de gatewayconfiguratie wijzigen. Hiermee zijn de actor, het toegangspunt, de ontbrekende maatregel en de impact vastgesteld.
Koppel elk scenario aan de relevante interface, het proces of de stroom in het diagram. Scenario’s met verschillende aanvalsvoorwaarden of maatregelen vereisen een afzonderlijke analyse. Als een voorwaarde onbekend is, zoals authenticatie op de controllerinterface, leg dan vast wat moet worden bevestigd.
Risicoprioriteiten en beveiligingsmaatregelen
Risicoprioriteiten hangen af van de toegang en capaciteit die een aanvaller nodig heeft, de kans op succes en de gevolgen voor het product. Een overeengekomen risicomethode maakt deze beoordelingen consistent. De onderbouwing van een score maakt controle door anderen mogelijk.
Kies een reactie die het team kan uitvoeren. Voor het scenario van configuratiewijziging moet de API bij elke schrijfbewerking de machtigingen van de aanroeper afdwingen. Wijs een verantwoordelijke, een doelrelease en een controle toe waarmee de werking van de maatregel wordt aangetoond.
Bestaande TLS beschermt een transportverbinding; deze bewijst niet dat een aangemelde gebruiker de configuratie mag wijzigen. Beoordeel de maatregel aan de hand van de specifieke aanvalsstap die deze moet tegenhouden. Als het team een restrisico accepteert, leg dan de reden en de bevoegde besluitnemer vast.
Verificatie en bijwerken van het model
Een voorgestelde maatregel en een geverifieerde maatregel zijn verschillende statussen. Koppel een geïmplementeerde maatregel aan de relevante wijziging en het verificatieresultaat. Stuur voor het API-voorbeeld als gebruiker met alleen-lezen-rechten een schrijfverzoek en bevestig zowel de afwijzing als het uitblijven van een configuratiewijziging.
Beoordeel het model opnieuw wanneer een interface, machtiging, component, implementatie of updatemechanisme verandert. Nieuwe informatie over kwetsbaarheden kan ook een eerdere aanname ongeldig maken. Bewaar het vorige model zodat het team kan uitleggen op welke releases een besluit van toepassing was.