Bedrohungsmodellierung ohne Diagramm

Die meisten Bedrohungsmodellansätze (wie z.B. STRIDE) gehen davon aus, dass Sie eine technische Übersicht wie ein Datenflussdiagramm haben. Eine interessante Frage ist daher, ob Sie ein Bedrohungsmodell erstellen können, wenn kein solches vorhanden ist. Eine gängige Situation ist die Bildung eines Epos. Aber nehmen wir als Übung einen juristischen Vertrag oder eine Dienstleistungsvereinbarung: Können Sie ein solches Bedrohungsmodell erstellen? Lassen Sie es uns herausfinden....

Auf den ersten Blick mag das vielleicht etwas weit hergeholt oder seltsam erscheinen, da es keine Vermögenswerte zu schützen oder technische Risiken zu identifizieren gibt, aber ich werde Ihnen zeigen, dass Sie dennoch interessante Ergebnisse erzielen können, wenn Sie den Prozess optimieren und zunächst eine Übersetzung anfertigen.

Erkennen Sie falsche Versprechen

ISO 15408 spezifiziert 'die Bewertungskriterien für IT-Sicherheit' und bietet einen guten Überblick über die Beziehungen zwischen Eigentümern, Bedrohungen und Vermögenswerten innerhalb des sogenannten 'Risikokontextes'.

Wenn Sie sich dieses Konzept ansehen, wird klar, welche Teile wir in der Übung zum Bedrohungsmodell zuerst identifizieren müssen:

• Vermögenswerte - die Dinge, die uns wichtig sind
• Risiken - Dinge, die den Wert des Vermögenswerts gefährden könnten
• Schwachstellen - Dinge, die dazu führen könnten, dass die Risiken Wirklichkeit werden
• Bedrohungen - Dinge, die die Schwachstelle hervorrufen

Wie würden wir dies also zum Beispiel auf einen rechtlichen Vertrag oder eine Dienstleistungsvereinbarung übertragen? Ein rechtlicher Vertrag ist im Wesentlichen eine lange Liste mit

1. Versprechen (wie in der Versprechenstheorie) an Ihren Kunden
2. die Konsequenzen, wenn Sie diese Versprechen nicht einhalten können

Mit anderen Worten: Sie stellen eine rechtliche Beschreibung des Wertes dar. In dieser Übung betrachten wir daher diese Versprechen als Vermögenswerte.

Nebenbei bemerkt: Die Betrachtung von Verträgen als eine Reihe von Versprechen ist kein neuer Ansatz, wie dieses Dokument aus dem Jahr 1856 zeigt, und wird auch in der heutigen Zeit noch erforscht.

Wenn Sie ein Versprechen geben, ohne zu überprüfen, ob Sie es tatsächlich einhalten können, ist das ein Risiko. Es ist nicht gesagt, dass es jemals zu einem Problem wird, aber im Allgemeinen sollten Sie vermeiden, Versprechungen zu machen, die Sie nicht halten können.

Eine Schwachstelle sind Versprechen, von denen Sie wissen, dass Sie sie nicht oder nicht dauerhaft einhalten können. Diese Teile haben das tatsächliche Potenzial, Ihrer Organisation zu schaden.

Eine Bedrohung wäre, wenn ein Kunde Ansprüche auf die Teile Ihres Vertrags erhebt, die die Versprechen enthalten, die Sie nicht einhalten können. Diese Dinge haben das Potenzial, Sie in Schwierigkeiten zu bringen.

Mit diesem Mapping wird es einfacher, einen Vertrag zu modellieren:

• Zuerst listen Sie die Versprechen im Vertrag auf
• Zweitens beginnen Sie damit, zu überprüfen, ob die Versprechen tatsächlich erfüllt werden können oder nicht. Eine gute Übungsform hierfür ist TRIZ. TRIZ ist eine Brainstorming-Übungsform, mit der Sie Antworten auf Fragen wie "Unter welchen Bedingungen könnten wir dieses Versprechen nicht erfüllen?" finden können, indem Sie über Möglichkeiten nachdenken, die Erfüllung von Versprechen aktiv zu verhindern. (Probieren Sie es aus; es macht Spaß und ist sehr aufschlussreich!)
• Der dritte Schritt besteht darin, zu ermitteln, wann diese Bedingungen auftreten können und ob sie in irgendeiner Weise gemildert werden

STRIDE Übersetzung

Eine interessante Frage ist nun: Unterscheiden sich die Arten von Bedrohungen, die Sie bei dieser Übung identifizieren, von denen, die Sie bei der Bedrohungsmodellierung eines technischen Diagramms identifizieren? Lassen Sie uns einen Blick auf STRIDE werfen.

STRIDE ist ein sehr beliebter Ansatz zur Modellierung von Bedrohungen, der zur Identifizierung von Bedrohungen in einem (technischen) Design verwendet wird. STRIDE ist eine Abkürzung für 6 Bedrohungskategorien, die typischerweise in technischen Umgebungen auftreten: Spoofing, Manipulation, Ablehnung, Offenlegung von Informationen, Denialof Service, Erhöhung vonPrivilegien (Elevationof Privilege).

Lassen Sie uns herausfinden, wie wir die in einer Modellierung der Bedrohungslage für juristische Verträge identifizierten Probleme übersetzen können:

Spoofing ist im Grunde die Möglichkeit, sich als jemand anderes auszugeben. In diesem juristischen Beispiel können wir das so übersetzen, dass nicht überprüft wird, ob die Person, die eine Forderung stellt, tatsächlich der Inhaber des Vertrags ist. Dieser Angriff kann wichtig sein, wenn sich die Forderung auf bestimmte Umstände bezieht, unter denen ein Versprechen aktiv wird. In diesen Fällen möchten Sie sicherstellen, dass die Person, die die Forderung stellt, dazu berechtigt ist.

Manipulation bedeutet, dass Sie Daten ändern können, obwohl Sie dazu nicht in der Lage sein sollten. In unserem Beispiel mag dies als nicht relevant erscheinen, da Sie einen Vertrag nicht einfach ändern können, aber es gibt einen Haken. Verträge basieren auf Sprache, und Sprache ist anfällig für Interpretationen. Ein Manipulationsangriff kann als Versprechen übersetzt werden, das in einer Weise interpretiert werden kann, die nicht mehr der ursprünglichen Absicht entspricht. Dies kann zu schwierigen Diskussionen und unerwünschten Ergebnissen führen.

Ablehnungsangriffe bedeuten normalerweise, dass Sie nicht beweisen können, wann jemand etwas getan hat. In einem eher juristischen Kontext ist dies immer noch ein gültiger Angriff. Besonders wenn Sie in eine Diskussion geraten, ist es wichtig, dass Sie eine Möglichkeit haben, einen Nachweis zu führen. Auch wenn bestimmte Versprechen nur bis zu einer bestimmten Grenze in Anspruch genommen werden können, ist es wichtig, dass Sie frühere Ansprüche nachweisen können.

Bei der Offenlegung von Informationen geht es darum, mehr Informationen als nötig preiszugeben. Dies lässt sich auch leicht in einen eher rechtlichen Kontext übersetzen, wenn Versprechungen über die Weitergabe von Informationen gemacht werden. Ein schönes Beispiel wäre die Weitergabe von Informationen über bestehende Schwachstellen in einem Dienst. Oft können Kunden diese Informationen anfordern, um ihre eigenen Risikobewertungen zu aktualisieren. Wenn Sie nicht angeben, was ein Kunde erhalten darf, geben Sie möglicherweise mehr sensible Informationen weiter, als Sie beabsichtigt haben.

Denial of Service sind normalerweise Angriffe, die den Dienst für andere Kunden unbrauchbar machen würden. In einem rechtlichen Kontext können wir das mit Forderungen übersetzen, die mehr Zeit in Anspruch nehmen, als Sie als Unternehmen bewältigen können. Ein Beispiel wäre ein Versprechen, das Informationsanfragen zulässt, ohne festzulegen, wie oft ein Kunde dies tun kann. Wenn ein Kunde beschließt, Sie täglich auf dieses Versprechen zu verpflichten, wird Ihnen schnell die Zeit für andere Dinge fehlen (und Sie müssen möglicherweise mit rechtlichen Konsequenzen rechnen, wenn Sie Fristen nicht einhalten).

Die Erhöhung von Privilegien ist normalerweise ein Angriff, bei dem ein Benutzer Privilegien erhält, die für seine Rolle nicht vorgesehen sind. Dies ist möglicherweise die am schwersten zu übersetzende Bedrohung. In einem Vertrag können manchmal nur bestimmte Rollen einen bestimmten Anspruch aktivieren (z.B. der CFO oder der Datenschutzbeauftragte). Wenn Sie nicht feststellen, ob der Antragsteller diese spezielle Rolle hat, kann dies zu einer Situation führen, die in diese Kategorie fällt.

Fazit

Diese einfache Übung hat gezeigt, dass die Modellierung von Bedrohungen nicht auf technische Entwürfe beschränkt ist und nur etwas Kreativität erfordert, um sie auf jede Situation anzuwenden. Selbst wenn es keine technischen Spezifikationen gibt, ist es dennoch möglich, Assets und damit Risiken, Schwachstellen und Bedrohungen zu identifizieren.