Aufzeichnungen und Berichte zum Bedrohungsmodell
Sytance · Aktualisiert
Ein Bedrohungsmodell erfasst Produktarchitektur, Angriffsszenarien, Sicherheitskontrollen und Verifizierungsergebnisse. Durch die Verknüpfung dieser Aufzeichnungen kann eine prüfende Person die Begründung vom Angriff bis zur gewählten Maßnahme nachvollziehen. Das Gateway-Beispiel zeigt, wie diese Aufzeichnungen zusammenhängen; die folgenden Abschnitte erläutern, was zu dokumentieren und wie es zu überprüfen ist.
Aufbau des Modells
Halten Sie Diagramm und Analyse zusammen oder verknüpfen Sie sie über stabile Kennungen. Für eine kleine Überprüfung genügt ein Dokument; strukturierte Aufzeichnungen sind nützlich, wenn dieselbe Kontrolle mehrere Bedrohungen abdeckt oder das Team Versionen vergleichen muss.
In Sytance bearbeitet das Team Architektur- und Bedrohungsaufzeichnungen im Arbeitsbereich und verknüpft anschließend relevante Sicherheitsanforderungen, Entwürfe und Verifizierungsaufzeichnungen. Das Dokumentationsmodul verwendet die Informationen aus dem Arbeitsbereich zur Erstellung von Berichten.
Produktinformationen und Annahmen
Geben Sie Produktversion, Bereitstellung, Zweck und Nutzer an. Legen Sie die in der Analyse enthaltenen Teile, externe Abhängigkeiten und Ausschlüsse fest, die einen Angriffspfad beeinflussen.
OWASP-Leitlinien zur Zerlegung unterscheiden Einstiegspunkte, Assets und Vertrauensstufen. Verwenden Sie diese Unterscheidungen, um die Architektur zu erläutern, statt jedes Asset als separaten Prozess im Diagramm darzustellen.
- Kontext: Produkt, Version, Umgebung, Zweck und verantwortliche Person für die Überprüfung.
- Architektur: Diagrammrevision, Prozesse, Datenspeicher, externe Entitäten und Datenflüsse.
- Schutzziele: Daten und Funktionen, die Vertraulichkeit, Integrität oder Verfügbarkeit erfordern.
- Annahmen: jede ungewisse Bedingung, ihre verantwortliche Person und eine Möglichkeit zu ihrer Bestätigung.
Ein Angriffsszenario je Aufzeichnung formulieren
Geben Sie jeder Bedrohung eine stabile Kennung und verknüpfen Sie sie mit dem relevanten Diagrammelement oder Datenfluss. Beschreiben Sie, wer angreifen könnte, welchen Zugriff die Person benötigt, die Handlung, die Schwachstelle und die Folgen. Geben Sie auch alle Bedingungen an, von denen das Szenario abhängt.
Beispiel TM-01: Ein Gateway-Nutzer mit Leserechten ruft die API zum Schreiben der Konfiguration auf. Prüft die API die Authentifizierung, nicht aber die Schreibberechtigung, kann der Nutzer das Telemetrieziel ändern. Der betroffene Datenfluss verläuft vom Browser zur Verwaltungs-API; der Angriff bedroht die Integrität der gespeicherten Konfiguration.
Ein Eintrag wie „Rechteausweitung, hohes Risiko“ erklärt dieses Szenario nicht. Ergänzen Sie die Risikobegründung: benötigtes Konto, Erreichbarkeit des Endpunkts, realistische Auswirkungen und berücksichtigte bestehende Kontrollen.
Kontrollen, Implementierung und Verifizierung
Für TM-01 verlangt die vorgeschlagene Kontrolle AC-01, dass die Verwaltungs-API bei jedem Schreibvorgang der Konfiguration Aktions- und Ressourcenberechtigungen prüft. Die Implementierungsaufzeichnung sollte die relevante Änderung benennen. Die Verifizierungsaufzeichnung sollte das tatsächliche Testergebnis für die angegebene Version enthalten.
- Entscheidung: Risiko mindern, beseitigen oder akzeptieren, mit Begründung und verantwortlicher Person.
- Kontrolle: erforderliches Verhalten und die damit adressierten Angriffsschritte.
- Implementierung: Komponente, Änderungsreferenz und Produktversion.
- Verifizierung: Testaufbau, Handlung, erwartetes und beobachtetes Ergebnis sowie Link zum Nachweis.
- Restrisiko: ungelöste Bedingungen und die autorisierte Überprüfungsentscheidung.
Erwartete und beobachtete Ergebnisse
Beim fiktiven Gateway wird erwartet, dass eine Schreibanfrage eines Nutzers mit Leserechten abgelehnt wird und die gespeicherte Konfiguration unverändert bleibt. Das beobachtete Ergebnis hält fest, was während des Tests geschehen ist. Bis der Test durchgeführt wird, bleibt dieses Feld ausstehend.
Dieselbe Unterscheidung gilt für Kontrollen. „Signaturprüfung geplant“ und „Signaturprüfung implementiert und getestet“ vermitteln unterschiedliche Vertrauensniveaus. Bewahren Sie diesen Unterschied, wenn die Aufzeichnung in einen Bericht oder ein anderes Werkzeug übertragen wird.
Abgeschlossenes Modell überprüfen
Bitten Sie eine prüfende Person, einem Angriff vom Diagramm bis zur ausgewählten Kontrolle und zum Testergebnis zu folgen. Lassen sich die Verknüpfungen nicht nachvollziehen, ermitteln Sie, ob eine Aufzeichnung fehlt oder der Angriff klarer erläutert werden muss.
Prüfen Sie, ob die genannte Version mit dem Diagramm übereinstimmt, jedes Szenario eine Behandlungsentscheidung hat und akzeptierte Risiken die Person nennen, die sie akzeptiert hat. Nicht geklärte Annahmen bleiben mit verantwortlicher Person und einer Möglichkeit zu ihrer Bestätigung aufgeführt.
Öffnen Sie nach der Aktualisierung der Arbeitsbereichsaufzeichnungen die Dokumentation und wählen Sie den passenden Bericht aus. Sytance stellt je nach Arbeitsbereichskonfiguration und Tarif HTML-Vorschauen sowie PDF- oder DOCX-Ausgaben bereit. Prüfen Sie den gerenderten Bericht vor einer Überprüfung anhand der aktuellen Produktversion, Analyse und Verifizierungsnachweise.