Registraties en rapporten voor dreigingsmodellen
Sytance · Bijgewerkt
Een dreigingsmodel legt de productarchitectuur, aanvalsscenario’s, beveiligingsmaatregelen en verificatieresultaten vast. Door deze registraties te koppelen, kan een beoordelaar de onderbouwing volgen van een aanval tot de gekozen maatregel. Het gatewayvoorbeeld laat zien hoe deze registraties samenhangen; de onderstaande onderdelen leggen uit wat moet worden vastgelegd en hoe dit moet worden beoordeeld.
Het model organiseren
Houd het diagram en de analyse bij elkaar of verbind ze met stabiele identificaties. Een document is geschikt voor een kleine beoordeling; gestructureerde registraties zijn nuttig wanneer dezelfde maatregel meerdere dreigingen bestrijkt of het team releases moet vergelijken.
In Sytance bewerkt het team de architectuur en dreigingsregistraties in de werkruimte en koppelt het vervolgens relevante beveiligingsvereisten, ontwerpen en verificatieregistraties. De documentatiemodule gebruikt informatie uit de werkruimte om rapporten op te stellen.
Productinformatie en aannames
Identificeer de productversie, implementatie, het doel en de gebruikers. Vermeld de onderdelen die in de analyse zijn opgenomen, externe afhankelijkheden en uitsluitingen die een aanvalspad beïnvloeden.
De decompositierichtlijnen van OWASP maken onderscheid tussen toegangspunten, bedrijfsmiddelen en vertrouwensniveaus. Gebruik dat onderscheid om de architectuur toe te lichten in plaats van elk bedrijfsmiddel als afzonderlijk proces in het diagram op te nemen.
- Context: product, release, omgeving, doel en verantwoordelijke voor de beoordeling.
- Architectuur: diagramrevisie, processen, gegevensopslag, externe entiteiten en stromen.
- Beschermingsdoelen: gegevens en functies die vertrouwelijkheid, integriteit of beschikbaarheid vereisen.
- Aannames: elke onzekere voorwaarde, de eigenaar ervan en een manier om deze te bevestigen.
Eén aanvalsscenario per registratie schrijven
Geef elke dreiging een stabiele identificatie en koppel deze aan het relevante diagramelement of de relevante stroom. Beschrijf wie kan aanvallen, welke toegang nodig is, de handeling, de zwakte en het gevolg. Vermeld de voorwaarden waarvan het scenario afhankelijk is.
Voorbeeld TM-01: een gatewaygebruiker met alleen-lezen-rechten roept de API voor het schrijven van configuratie aan. Als de API de authenticatie controleert maar niet de schrijfrechten, kan de gebruiker de telemetriebestemming wijzigen. De getroffen stroom loopt van de browser naar de beheer-API; de aanval bedreigt de integriteit van de opgeslagen configuratie.
Een vermelding met alleen “verhoging van bevoegdheden, hoog risico” licht dit scenario niet toe. Voeg de onderbouwing van het risico toe: het benodigde account, de blootstelling van het eindpunt, een realistische impact en de beoordeelde bestaande maatregelen.
Maatregelen, implementatie en verificatie
Voor TM-01 vereist de voorgestelde maatregel AC-01 dat de beheer-API bij elke configuratieschrijfactie de machtigingen voor de handeling en de bron controleert. De implementatieregistratie moet de relevante wijziging identificeren. De verificatieregistratie moet het werkelijke testresultaat voor de genoemde release bevatten.
- Besluit: risico verminderen, wegnemen of accepteren, met motivering en verantwoordelijke.
- Maatregel: vereist gedrag en de aanvalsstappen waarop deze van toepassing is.
- Implementatie: component, wijzigingsreferentie en productversie.
- Verificatie: testopstelling, handeling, verwacht en waargenomen resultaat en link naar bewijs.
- Restrisico: onopgeloste voorwaarden en het bevoegde beoordelingsbesluit.
Verwachte en waargenomen resultaten
Voor de fictieve gateway is het verwachte resultaat dat een schrijfverzoek van een gebruiker met alleen-lezen-rechten wordt geweigerd en de opgeslagen configuratie ongewijzigd blijft. Het waargenomen resultaat legt vast wat tijdens de test is gebeurd. Zolang de test niet is uitgevoerd, blijft dit veld in afwachting.
Hetzelfde onderscheid geldt voor maatregelen. “Signatuurverificatie gepland” en “signatuurverificatie geïmplementeerd en getest” geven verschillende betrouwbaarheidsniveaus aan. Behoud dat verschil wanneer de registratie naar een rapport of ander hulpmiddel wordt overgezet.
Het voltooide model beoordelen
Vraag een beoordelaar één aanval te volgen van het diagram tot de gekozen maatregel en het testresultaat. Als de koppelingen niet te volgen zijn, bepaal dan of een registratie ontbreekt of dat de aanval duidelijker moet worden uitgelegd.
Controleer of de genoemde release overeenkomt met het diagram, elk scenario een behandelbesluit heeft en bij geaccepteerde risico’s is vermeld wie deze heeft geaccepteerd. Onopgeloste aannames blijven vermeld met een eigenaar en een manier om ze te bevestigen.
Open na het bijwerken van de werkruimteregistraties de documentatie en selecteer het relevante rapport. Afhankelijk van de configuratie en het plan van de werkruimte biedt Sytance HTML-voorbeelden en PDF- of DOCX-uitvoer. Controleer het weergegeven rapport aan de hand van de huidige productversie, analyse en verificatiebewijzen voordat u het bij een beoordeling gebruikt.