Bedrohungsmodellierung

Einführung

Ich will wissen, wie du das herausfindest.

Richard Feynman, amerikanischer Physiker

In dieser Einführung werden wir die Grundlagen der Bedrohungsmodellierung erklären. Außerdem behandeln wir die wichtigsten Sicherheitsprinzipien, die du als Grundlage für die Bewertung der Sicherheit der Systeme, die du analysierst, kennen musst.

Die Grundlagen der Bedrohungsmodellierung

Beginnen wir damit, aus der Vogelperspektive zu betrachten, was Bedrohungsmodellierung ist, warum sie nützlich ist und wie sie in den Entwicklungslebenszyklus und den allgemeinen Sicherheitsplan passt.

Was ist Threat Modeling?

Bei der Bedrohungsmodellierung wird ein System analysiert, um nach Schwachstellen zu suchen, die auf weniger wünschenswerte Designentscheidungen zurückzuführen sind. Ziel dieser Aktivität ist es, diese Schwachstellen zu erkennen, bevor sie in das System eingebaut werden (als Folge der Implementierung oder des Einsatzes), damit du so früh wie möglich Korrekturmaßnahmen ergreifen kannst. Bei der Bedrohungsmodellierung handelt es sich um eine konzeptionelle Übung, die dir dabei helfen soll, zu verstehen, welche Merkmale des Systemdesigns geändert werden sollten, um das Risiko des Systems auf ein für die Eigentümer, Benutzer und Betreiber akzeptables Niveau zu reduzieren.

Bei der Bedrohungsmodellierung betrachtest du ein System als eine Sammlung seiner Komponenten und ihrer Interaktionen mit der Welt außerhalb des Systems (z. B. andere Systeme, mit denen es interagiert) und den Akteuren, die auf diese Systeme einwirken können. Dann versuchst du dir vorzustellen, wie diese Komponenten und Interaktionen fehlschlagen oder zum Fehlschlagen gebracht werden können. Auf diese Weise identifizierst du Bedrohungen für das System, die wiederum zu Veränderungen und Anpassungen des Systems führen. Das Ergebnis ist ein System, das den Bedrohungen widerstehen kann, die du dir vorgestellt hast.

Aber stellen wir gleich zu Beginn klar: Bedrohungsmodellierung ist eine zyklische Aktivität. Sie beginnt mit einem klaren Ziel, geht weiter mit Analysen und Maßnahmen und wiederholt sich dann. Es ist kein Patentrezept - es löst nicht alle Sicherheitsprobleme. Es ist auch kein Tool, das auf Knopfdruck funktioniert, wie ein Scanner, den du auf deine Website oder dein Code-Repository richtest und der eine Liste von Punkten erstellt, die du abhaken kannst. Die Modellierung von Bedrohungen ist ein logischer, intellektueller Prozess, der am effektivsten ist, wenn du die meisten, wenn nicht alle Mitglieder deines Teams einbeziehst. Das regt zu Diskussionen an und schafft Klarheit über deinen Entwurf und deine Ausführung. All das erfordert Arbeit und ein gewisses Maß an Fachwissen.

Die erste Regel der Bedrohungsmodellierung könnte die alte Maxime garbage in, garbage out (GIGO) sein.¹ Wenn du die Bedrohungsmodellierung in den Werkzeugkasten deines Teams aufnimmst und alle Beteiligten dazu bringst, sich positiv daran zu beteiligen, wirst du ihre vielen Vorteile ernten. Wenn du sie jedoch nur halbherzig angehst, ohne ein vollständiges Verständnis ihrer Stärken und Schwächen oder als "Check-the-Box"-Element zur Einhaltung der Vorschriften, wirst du sie nur als Zeitfresser betrachten. Wenn du eine Methode gefunden hast, die für dich und dein Team geeignet ist, und die nötigen Anstrengungen unternimmst, um sie umzusetzen, wird sich deine allgemeine Sicherheitslage erheblich verbessern.

Warum du Threat Modeling brauchst

Du brauchst die Bedrohungsmodellierung, weil sie deine Arbeit auf lange Sicht einfacher und besser machen wird. Sie führt zu saubereren Architekturen, klar definierten Vertrauensgrenzen (du weißt noch nicht, was das ist und warum sie wichtig sind, aber bald wirst du es wissen!), gezielten Sicherheitstests und einer besseren Dokumentation. Und vor allem wird es dir und deinem Team die Superkraft des Sicherheitsdenkens in einer organisierten, orchestrierten Art und Weise vermitteln, die zu besseren Sicherheitsstandards und -richtlinien in deiner gesamten Entwicklungsarbeit führt.

So wichtig all diese Nebeneffekte auch sind, sie sind nicht das Wichtigste. Wenn du verstehst, was in deinem System schiefgehen könnte und was du dagegen tun kannst, steigt das Vertrauen in das, was du lieferst, und du kannst dich auf andere Aspekte des Systems konzentrieren. Und das ist der eigentliche Grund für die Notwendigkeit derBedrohungsmodellierung.

Es ist auch wichtig, darauf hinzuweisen, warum du die Bedrohungsmodellierung nicht brauchst. Es wird nicht alle deine Sicherheitsprobleme von alleine lösen; es wird dein Team auch nicht sofort in Sicherheitsexperten verwandeln. Vor allem aber brauchst du sie nicht für die Einhaltung von Vorschriften. Eine leere Übung, die nur darauf abzielt, das Häkchen in der Compliance-Liste zu setzen, führt zu mehr Frustration, als wenn du weißt, dass du diese spezielle Anforderung nicht erfüllt hast.

Hindernisse

Das Problem mit Programmierern ist, dass man nie weiß, was ein Programmierer tut, bis es zu spät ist.

Seymour R. Cray, Erfinder der Cray-Reihe von Supercomputern

Diese Maxime gilt auch heute noch. Gib einem Entwickler eine Spezifikation oder einen einigermaßen gut dokumentierten Satz von Anforderungen, und lehne dich zurück, und viele interessante Dinge können passieren.

Ehrlich gesagt, wissen wir, dass Entwicklungsteams gestresste Überflieger sein können, die unter hohen Anforderungen und großer Verantwortung arbeiten. Sie müssen sich mit einer sich fast ständig verändernden Landschaft auseinandersetzen, in der sie lernen, sich fortbilden und dann wieder ganze Teildisziplinen vergessen. Es ist unfair, dich unter Druck zu setzen, weil du "etwas nicht weißt, was wirklich grundlegend und wichtig ist". Bedenke, dass sich die gesamte Branche für Schulungsinhalte hauptsächlich darauf konzentriert, geschäftsorientierte Ziele wie die Einhaltung von Vorschriften, das Erreichen von Schulungszielen und andere verschiedene Kennzahlen zu erreichen. Es gibt noch viel Raum für Verbesserungen, wenn es darum geht, effektive, nützliche Inhalte zu vermitteln, die von den Entwicklungsteams in Wissen und praktische Anwendung umgesetzt werden können.

Eine der Aufgaben von Sicherheitsexperten ist es, die Sicherheitsausbildung der Entwicklergemeinschaften zu fördern. Dazu gehört auch, wie man sichere Systeme implementiert und wie man die Sicherheit von Code und Systemen im Nachhinein bewertet. Es mag einfacher erscheinen, sich auf teure Tools zu verlassen, um die Sicherheitsexpertise des Unternehmens zu ergänzen (und weitgehend zu verbergen). Die Herausforderung besteht darin, dass das in den Tools enthaltene Fachwissen dem Benutzer oft verborgen bleibt; die Entwicklungsteams würden sehr davon profitieren, wenn die Erkennungsmethoden für sie transparent wären. Hier sind einige Beispiele:

• Computergestütztes Training (CBT) ist die Geißel jedes neuen Arbeitnehmers. 45 Minuten langweilige Stimmen, die müde aussehende Folien vorlesen, in den üblichen Standardschriften, mit denselben Standardbildern und -abbildungen? Und was noch schlimmer ist, die harmlosen Multiple-Choice-Fragen, die man durch Ausschluss lösen kann?

• Übermäßiges Vertrauen in Scanner und statische Code-Analysatoren, die künstliche Intelligenz, maschinelles Lernen, Taint-Analysen, Angriffsbäume und die Mächte von Grayskull versprechen, aber immer wieder zu den gleichen Ergebnissen fehlschlagen oder mehr falsch-positive als wirklich nützliche Antworten liefern. Oder die Analysewerkzeuge erwarten, dass das gesamte System existiert, bevor sie einen Scan durchführen können, ganz zu schweigen davon, dass sie lange Zeiten in den Build-Prozess einfügen, die mit den Werten der kontinuierlichen Integration/kontinuierlichen Entwicklung (CI/CD) nicht vereinbar sind.

• Beratungsdienste, bei denen auf Anfrage ein Sicherheitsexperte auftaucht, Abhilfemaßnahmen (oder "gezielte Schulungen") durchführt und wieder verschwindet (wir nennen das Möwenberatung; sie tauchen auf, kacken auf dich und fliegen dann weg), während das Team mit den Folgen fertig werden muss. Sich auf einen Sicherheitsberater zu verlassen, der gerade zur rechten Zeit kommt, hat viele Nachteile: Er hat kein Interesse am Ergebnis seines Handelns, er ist ein Außenstehender des Teams (wenn nicht sogar des Unternehmens), er ist persönlich voreingenommen und er "zaubert", so dass das Team das Gefühl hat, dass etwas passiert ist, aber nicht weiß, was passiert ist. Frachtkult² Die Folge ist ein Cargo-Kult, da das Team ständig versucht, die Teilergebnisse, die der Berater hinterlassen hat, zu wiederholen.

Wir Sicherheitsexperten haben auch ein falsches Gefühl für die Erwartungen der Entwickler in den Unternehmen geschaffen:

• Ein Unternehmen kann sich eine starke Sicherheitsposition erkaufen. Wenn sie genug Geld in Tools investiert, wird sie alle ihre Sicherheitsprobleme lösen.

• Dreißig Minuten Pflichtschulung pro Quartal reichen aus, damit die Organisation das Audit bestehen kann. Diese 30 Minuten sollten für die Entwicklungsteams ausreichend sein, um zu lernen, was von ihnen erwartet wird. Da die Entwicklungsteams Zugang zu erstklassigen Schulungsinhalten haben, werden ihnen die teuren Tools, die sie verwenden, nur noch "über die Schulter schauen" und bestätigen, dass sie ihre Arbeit tatsächlich auf sichere Art und Weise erledigt haben.

In letzter Zeit (seit Mitte 2019) wird die Sicherheitsbranche von der Idee der Linksverschiebung beherrscht. Stell dir einen Arbeitsablauf vor, den du von links nach rechts liest. Der Beginn des Arbeitsablaufs ist links. Wenn wir von "Linksverschiebung" sprechen, meinen wir damit, dass wir wollen, dass die Sicherheitsprozesse so weit "links" wie möglich an den Anfang des Entwicklungsworkflows (der jeweiligen Entwicklungsmethodik) rücken. So können Sicherheitsereignisse so früh wie möglich auftreten und behandelt werden. Eine Aktivität wie die Bedrohungsmodellierung, die eng mit dem Entwurf verbunden ist, sollte so früh wie möglich in der Lebenszeit eines Systems stattfinden. Und wenn es damals noch nicht geschehen ist, sollte es jetzt geschehen.

Hinweis

Wir glauben nicht an das Phänomen der "Linksverschiebung", sondern bevorzugen es, links anzufangen, indem wir Methoden verwenden, die mit dem Entwurf oder noch früher mit den Anforderungen als Grundlage für die Sicherheit eines Systems beginnen.

Da die Änderungen des Prozesses zu einem weniger linearen "Links-nach-Rechts"-Entwicklungszyklus führen, kann es sein, dass der Linksruck nicht ausreicht, um alle Sicherheitsanforderungen in einem System zu erfüllen. Stattdessen muss die Sicherheitsgemeinschaft noch weiter nach links in das Leben der Entwickler und Designer vordringen, bevor ein System in Betracht gezogen wird. Dort müssen wir uns darauf konzentrieren, Entwicklungsteams darin zu schulen, sichere Entscheidungen zu treffen und Fähigkeiten mitzubringen, um Bedrohungen auf einer viel grundlegenderen Ebene zu vermeiden.

Dann gibt es noch die Umsetzung, bei der die Sicherheit angeblich durch die kollektiven Schulungsbemühungen der Branche nach links verschoben wird und semantisch und logisch durch sicheren Code ausgedrückt wird. Aber wenn die Ausbildung nicht die versprochenen Erwartungen erfüllt hat, welche möglichen Korrekturmaßnahmen gibt es dann, um die fehlgeschlagenen Annahmen zu korrigieren?

Betrachten wir das Problem aus einem anderen Blickwinkel und fügen wir die Teile zu einer kohärenten Antwort auf diese Tirade zusammen (eine Einladung zum Kreuzzug!). Manche sprechen von "einem Platz am Tisch", wenn es um die Sicherheitsstrategie geht. Sicherheitsteams und Führungskräfte wollen, dass die "Stakeholder" einen "Platz" für die Sicherheit in der "laufenden Diskussion" einnehmen. So können sie rechtfertigen, dass sie ein Stück vom Ressourcenkuchen abhaben wollen. Aber es gibt noch eine andere wichtige Ressource, die nicht so anerkannt wird, weil sie durch "umfangreiche Schulungen" und "Allheilmittel" verschleiert wird. Und diese Ressource ist die Zeit und der Fokus des Entwicklers.

Nehmen wir mal einen Webentwickler. Unendlich viele Memes spiegeln die Tatsache wider, dass ein Webentwickler, der heute alles über den LAMP-Stack lernt³ lernt, ist dieses Wissen nach dem Mittagessen nutzlos, weil die ganze Branche auf den MEAN-Stack umgestiegen sein wird.⁴ Und der MEAN-Stack wird zwei Grande Lattes später von einer anderen glänzenden neuen Sache abgelöst, bis wir wieder bei der neuen, verbesserten (und absolut nicht abwärtskompatiblen!) Version von dem sind, mit dem wir gerade angefangen haben. Jeder dieser neuen Stacks bringt eine Reihe neuer Sicherheitsherausforderungen und sicherheitsrelevanter Idiome und Mechanismen mit sich, die verstanden und integriert werden müssen, um das zu entwickelnde System effektiv zu schützen. Und natürlich erfordert jeder Stack einen eigenen Sicherheitsvertrag, den der Webentwickler schnell lernen und beherrschen muss.

Aber die Website darf nicht ausfallen, und ihre Verwaltung soll zur gleichen Zeit stattfinden , in der der Entwickler sein neuesSpielzeug-Tool lernt. Wie kann der Sicherheitsdienst erwarten, dass er denselben Kuchen (d.h. die Zeit und Aufmerksamkeit des Entwicklers) teilen kann und nur ein kleines Stückchen davon abbekommt?

Und hier beginnt der Kreuzzug - wie Richard Feynman uns sagt: "Lehre Prinzipien, nicht Formeln." In diesem Buch konzentrieren wir uns auf Prinzipien, die dir helfen zu verstehen und zu durchdenken, was Threat Modeling für dich bedeutet, wie es in deinem speziellen Fall helfen kann und wie du es am besten für dein Projekt und dein Team anwendest.

Bedrohungsmodellierung im Lebenszyklus der Systementwicklung

Die Modellierung von Bedrohungen ist eine Aktivität, die während des Lebenszyklus der Systementwicklung durchgeführt wird und für die Sicherheit des Systems entscheidend ist. Wenn die Bedrohungsmodellierung nicht in irgendeiner Form durchgeführt wird, werden wahrscheinlich Sicherheitsmängel durch Designentscheidungen eingeführt, die möglicherweise leicht ausgenutzt werden können und mit Sicherheit schwer (und kostspielig) zu⁵) später zu beheben. Gemäß dem Sicherheitsprinzip "einbauen, nicht aufschrauben" sollte die Bedrohungsmodellierung nicht als Meilenstein bei der Einhaltung von Vorschriften betrachtet werden. Wenn diese Maßnahme nicht durchgeführt wird, wenn es darauf ankommt, hat das in der Praxis Konsequenzen.

Die meisten erfolgreichen Unternehmen führen ihre Projekte heute nicht mehr so durch wie noch vor ein paar Jahren. Entwicklungsparadigmen wie Serverless Computing zum Beispiel,⁶ oder einige der neuesten Trends und Tools im Bereich CI/CD,⁷ haben die Art und Weise, wie Entwicklungsteams die heutigen Systeme entwerfen, implementieren und einsetzen, stark beeinflusst.

Aufgrund der Marktnachfrage und des Wettlaufs um den ersten Platz hast du heutzutage nur noch selten die Möglichkeit, dir vor der Entwicklung eines Systems ein vollständiges Design anzuschauen. Produktteams verlassen sich auf "Minimum Viable Product"-Versionen, um ihre neuen Ideen der Öffentlichkeit vorzustellen und sich eine Marke und eine Fangemeinde aufzubauen. Anschließend fügen sie inkrementelle Versionen hinzu und nehmen Änderungen vor, wenn Probleme auftreten. Diese Praxis führt dazu, dass wesentliche Änderungen am Design erst später im Entwicklungszyklus vorgenommen werden.

Moderne Systeme sind so komplex wie nie zuvor. Du kannst viele Komponenten, Bibliotheken und Frameworks von Drittanbietern (mit offenem oder geschlossenem Quellcode) verwenden, um deine neue Software zu erstellen, aber die Komponenten sind oft schlecht dokumentiert, schlecht verstanden und schlecht gesichert. Um "einfache" Systeme zu erstellen, bist du auf komplizierte Schichten von Software, Diensten und Funktionen angewiesen. Um es noch einmal am Beispiel von Serverless Deployments zu verdeutlichen: "Die Umgebung, die Bibliotheken, die Maschinen oder das Netzwerk sind mir egal, ich kümmere mich nur um meine Funktionen", ist kurzsichtig. Wie viele Maschinen sind hinter dem Vorhang versteckt? Wie viel Kontrolle hast du darüber, was "unter" deinen Funktionen passiert? Wie wirken sich diese Dinge auf die allgemeine Sicherheit deines Systems aus? Wie stellst du sicher, dass du die am besten geeigneten Rollen und Zugriffsregeln verwendest?

Um diese Fragen zuverlässig zu beantworten und sofortige Ergebnisse zu erhalten, könntest du versucht sein, einen externen Sicherheitsexperten hinzuzuziehen. Aber das Fachwissen im Bereich Sicherheit ist sehr unterschiedlich und die Einstellung von Experten kann teuer sein. Manche Experten konzentrieren sich auf bestimmte Technologien oder Bereiche, andere wiederum haben einen breiten, aber oberflächlichen Fokus. Das trifft natürlich nicht auf jeden Berater zu, und wir sind die ersten, die bestätigen können, dass wir gute Erfahrungen mit Beratern für Bedrohungsmodelle gemacht haben. Du siehst jedoch, dass es einen großen Anreiz gibt, sich internes Wissen über Bedrohungsmodellierung anzueignen und zu versuchen, es so weit wie möglich an die Entwicklungsmethodik deines Teams anzupassen.

Entwicklung von sicheren Systemen

Unabhängig von der Entwicklungsmethodik, die du verwendest, muss die Entwicklung deines Systems einige ganz bestimmte Phasen durchlaufen (siehe Abbildung I-1).

• Beginn der Idee

• Entwurf

• Umsetzung

• Testen

• Einsatz

Abbildung I-1. Entwicklungskreislauf und damit verbundene Sicherheitsaktivitäten

Bei der Wasserfallmethode zum Beispiel folgen diese Phasen natürlich aufeinander. Beachte, dass die Dokumentation eine fortlaufende Rolle spielt - sie muss parallel zu den anderen Phasen erfolgen, um wirklich effizient zu sein. Wenn du diese Methode anwendest, ist es leicht zu erkennen, dass ein Bedrohungsmodell zur Entwurfszeit den größten Nutzen bringt.

Diese Behauptung wirst du in diesem Buch noch oft hören. Wir verknüpfen die Bedrohungsmodellierung sorgfältig mit dem Design. Warum ist das so?

Ein vielzitiertes⁸ Konzept besagt, dass die Kosten für die Lösung eines Problems umso höher sind, je näher es vor oder nach der Einführung auftritt. Für Menschen, die mit der Herstellung und Vermarktung von Software vertraut sind, ist das ziemlich offensichtlich: Es ist viel billiger, Lösungen auf ein System anzuwenden, das sich noch in der Entwicklung befindet, als auf ein System, das bereits an Tausenden oder in einigen Extremfällen an Millionen von Orten eingesetzt wird.⁹ Du musst dich nicht damit auseinandersetzen, dass einige Nutzer/innen einen Patch nicht anwenden oder dass die Abwärtskompatibilität eines Systems durch einen Patch beeinträchtigt werden könnte. Du musst dich nicht mit Nutzern auseinandersetzen, die aus dem einen oder anderen Grund nicht mit dem Patch weitermachen können. Und du musst dich nicht mit den Kosten für einen langwierigen und manchmal instabilen Upgrade-Prozess auseinandersetzen.

Bei der Bedrohungsmodellierung wird also ein Design untersucht und versucht, Sicherheitslücken zu identifizieren. Wenn deine Analyse zum Beispiel zeigt, dass für eine bestimmte Zugriffsart ein fest codiertes Passwort verwendet wird, wird dies als zu behebende Schwachstelle identifiziert. Wenn ein Befund nicht behoben wird, handelt es sich wahrscheinlich um ein Problem, das später im System ausgenutzt werden kann. Dies wird auch als Schwachstelle bezeichnet, die mit einer bestimmten Wahrscheinlichkeit ausgenutzt werden kann und mit entsprechenden Kosten verbunden ist, wenn sie ausgenutzt wird. Es kann auch sein, dass dir die Identifizierung eines Problems misslingt oder dass du etwas, das ausgenutzt werden kann, nicht richtig feststellst. Perfektion und Vollständigkeit sind nicht das Ziel dieser Übung.

Hinweis

Das Hauptziel der Bedrohungsmodellierung ist es, Schwachstellen zu identifizieren, damit sie zu Erkenntnissen werden (Probleme, die du beheben kannst) und nicht zu Schwachstellen (Probleme, die ausgenutzt werden können). Dann kannst du Maßnahmen ergreifen, die sowohl die Wahrscheinlichkeit eines Angriffs als auch die Kosten eines Angriffs (d.h. den Schaden oder die Auswirkungen) verringern.

Sobald du eine Schwachstelle identifiziert hast, musst du sie entschärfen oder beheben. Dazu wendest du geeignete Kontrollen an. Du könntest zum Beispiel ein dynamisches, benutzerdefiniertes Passwort anstelle eines fest programmierten erstellen. Oder du führst mehrere Tests mit diesem Passwort durch, um seine Stärke zu überprüfen. Oder du überlässt die Entscheidung über eine Passwortrichtlinie dem Benutzer. Oder du änderst deine Herangehensweise komplett und entfernst die Schwachstelle, indem du die Verwendung von Passwörtern abschaffst und stattdessen Unterstützung für WebAuthn¹⁰ an. In manchen Fällen gehst du das Risiko einfach ein - du entscheidest, dass es für dieArt und Weise, wie das System eingesetzt wird, in Ordnung sein könnte, ein fest codiertes Passwort zu verwenden. (Tipp: Ist es nicht. Wirklich. Denk darüber nach.) Manchmal musst du entscheiden, dass ein Risiko akzeptabel ist. In diesen Fällen musst du das Ergebnis dokumentieren, die Gründe für die Ablehnung des Risikos nennen und beschreiben und dies in dein Bedrohungsmodell einbauen.

Es ist wichtig zu betonen (und wir werden im Laufe des Buches immer wieder darauf zurückkommen), dass die Modellierung von Bedrohungen ein evolutionärer Prozess ist. Es kann sein, dass du bei der ersten Analyse nicht alle Schwachstellen in deinem System findest. Vielleicht hattest du zum Beispiel nicht die richtigen Ressourcen oder die richtigen Interessengruppen, die das System untersucht haben. Aber ein anfängliches Bedrohungsmodell ist viel besser als gar kein Bedrohungsmodell zu haben. Und die nächste Iteration, wenn das Bedrohungsmodell aktualisiert wird, wird besser sein, andere Schwachstellen aufdecken und ein höheres Maß an Sicherheit bieten, dass keine Schwachstellen gefunden wurden. Du und dein Team werden die Erfahrung und das Vertrauen gewinnen, die euch dazu bringen, neue und komplexere oder subtilere Angriffe und Vektoren in Betracht zu ziehen, und euer System wird sich ständig verbessern.

Kein Wasserfall mehr

Kommen wir nun zu den moderneren Agile- und CI/CD-Ansätzen.

Da die Entwicklung und der Einsatz von Software auf diese Weise schneller vonstatten gehen, kann es sein, dass es unmöglich ist, alles anzuhalten, eine richtige Entwurfssitzung einzuberufen und sich darüber zu einigen, was geschehen soll. Manchmal entwickelt sich dein Design aus den Anforderungen der Kunden, und manchmal ergibt sich dein Design aus der laufenden Entwicklung deines Systems. In diesen Situationen kann es schwierig sein, das Gesamtdesign des Systems vorherzusagen (oder überhaupt zu wissen, was das komplette System ist), und du kannst vielleicht keine weitreichenden Designänderungen im Voraus vornehmen.

In vielen Designvorschlägen wird beschrieben, wie die Bedrohungsmodellierung unter diesen Umständen durchgeführt werden kann - von Microsofts Vorschlag der "Sicherheitssprints" bis hin zur Anwendung der Bedrohungsmodellierung auf kleinere Systemeinheiten, iterativ, bei jedem Sprint. Und leider wird auch behauptet, dass die Bedrohungsmodellierung die Geschwindigkeit eines agilen Teams "reduziert". Ist es besser, die Geschwindigkeit eines agilen Teams zu verringern oder die eines Teams von Hackern, die versuchen, auf deine Daten zuzugreifen? Im Moment ist es wichtig, das Problem zu erkennen; wir werden später auf mögliche Lösungen eingehen.

Sobald du die Sicherheit im Entwurfsprozess berücksichtigst, wirst du sehen, wie sich die Sicherheit auf alle anderen Phasen der Entwicklung auswirkt. So kannst du erkennen, wie die Modellierung von Bedrohungen einen noch größeren Einfluss auf die Gesamtsicherheit des Systems haben kann, die ein kollektives Maß für die Sicherheit ist:

• Der aktuelle Stand der Sicherheit innerhalb des Systems

• Angriffsvektoren, Eindringpunkte oder Möglichkeiten zur Veränderung des Systemverhaltens, die ein Akteur erkunden und ausnutzen kann (auch bekannt als dieAngriffsfläche)

• Die bestehenden Schwachstellen und Schwächen innerhalb des Systems (auch als Sicherheitsschuld bekannt) und das kombinierte Risiko für das System und/oder das Unternehmen, das sich aus diesen Faktoren ergibt

Umsetzung und Prüfung

Es ist schwer, die Implementierung und das Testen nicht als den wichtigsten Aspekt der Sicherheit in der Entwicklung zu betrachten. Schließlich entstehen Sicherheitsprobleme (meistens!) durch Probleme oder Fehler, die bei der Implementierung von Codezeilen gemacht werden. Einige der berüchtigtsten Sicherheitsprobleme - Heartbleed - und die meisten Pufferüberläufe sind nicht auf schlechtes Design zurückzuführen, sondern auf Codezeilen, die nicht das taten, was sie sollten, oder es auf unerwartete Weise taten.

Wenn du dir Klassen von Schwachstellen ansiehst (z. B. Pufferüberläufe und Injektionsprobleme), ist es leicht zu erkennen, wie ein Entwickler sie versehentlich einführen kann. Es ist leicht, eine bereits verwendete Strophe auszuschneiden und einzufügen oder in den Glauben zu verfallen: "Wer würde das schon tun?", wenn man eine falsche Eingabe in Betracht zieht. Oder der Entwickler fügt einfach aus Unwissenheit, Zeitmangel oder anderen Gründen Fehler ein, ohne an die Sicherheit zu denken.

Viele Tools finden Schwachstellen in geschriebenem Code, indem sie eine statische Analyse durchführen. Einige Tools tun dies, indem sie den Quellcode analysieren, andere, indem sie den Code durch Simulationen von Eingaben laufen lassen und schlechte Ergebnisse identifizieren (diese Technik ist als Fuzzing bekannt). Das maschinelle Lernen hat sich in letzter Zeit als eine weitere Alternative zur Identifizierung von "schlechtem Code" erwiesen.

Aber hat die Bedrohungsmodellierung einen Einfluss auf diese codebezogenen Fragen? Das kommt darauf an. Wenn du ein System als Ganzes betrachtest und zu dem Schluss kommst, dass du eine ganze Klasse von Schwachstellen vollständig beseitigen kannst, indem du den grundlegenden Fehler behebst, dann hast du die Möglichkeit, bei der Entwicklung codebezogene Probleme zu lösen. Google hat dies beim Cross-Site-Scripting (und anderen Schwachstellen) getan, indem es Bibliotheken und Muster eingeführt hat, die in allen Produkten verwendet werden, die mit diesem Problem zu tun haben.¹¹ Leider können Entscheidungen, die getroffen werden, um bestimmte Arten von Problemen zu lösen, andere Probleme ausschließen. Nehmen wir zum Beispiel an, du arbeitest an einem System, bei dem es in erster Linie auf hohe Leistung und hohe Zuverlässigkeit ankommt. Vielleicht entscheidest du dich für eine Sprache, die eine direkte Speichersteuerung und einen geringeren Ausführungsaufwand bietet, wie z. B. C, und nicht für Sprachen wie Go oder Java, die eine bessere Speicherverwaltung bieten. In diesem Fall hast du möglicherweise nur begrenzte Möglichkeiten, das Ausmaß der potenziellen Sicherheitsbedenken zu beeinflussen, die durch eine Änderung des Technologiestacks behoben werden müssen. Das bedeutet, dass du während der Entwicklungs- und Testphase Werkzeuge einsetzen musst, um das Ergebnis zu kontrollieren.

Dokumentation und Einsatz

Wenn Systeme entwickelt werden, können die dafür verantwortlichen Teams einen Selbstentwicklungsprozess durchlaufen. Stammeswissen, oder institutionelles Wissen, entsteht, wenn eine Gruppe von Personen etwas lernt oder versteht und dieses Wissen beibehält, ohne es zu dokumentieren. Wenn sich die Teammitglieder jedoch im Laufe der Zeit verändern, wenn Personen das Team verlassen und neue hinzukommen, kann dieses Stammeswissen verloren gehen.

Zum Glück ist ein gut dokumentiertes Bedrohungsmodell ein hervorragendes Mittel, um neuen Teammitgliedern dieses formale und geschützte Wissen zu vermitteln. Viele unklare Datenpunkte, Begründungen und allgemeine Gedankengänge (z. B. "Warum habt ihr das hier so gemacht?!") eignen sich gut für die Dokumentation in einem Bedrohungsmodell. Alle Entscheidungen, die getroffen werden, um Einschränkungen zu überwinden, und die daraus resultierenden Auswirkungen auf die Sicherheit sind ebenfalls gute Kandidaten für eine Dokumentation. Das Gleiche gilt für den Einsatz - ein Bedrohungsmodell ist ein guter Ort, um eine Bestandsaufnahme der Komponenten von Drittanbietern zu machen, wie sie auf dem neuesten Stand gehalten werden, welche Anstrengungen erforderlich sind, um sie zu schützen, und welche Annahmen bei ihrer Konfiguration getroffen wurden. So etwas Einfaches wie eine Bestandsaufnahme der Netzwerkports und ihrer Protokolle erklärt nicht nur den Datenfluss im System, sondern auch die Einsatzentscheidungen bezüglich der Authentifizierung von Hosts, der Konfiguration von Firewalls usw. All diese Informationen passen gut in ein Bedrohungsmodell, und wenn du auf Compliance-Audits und Prüfungen durch Dritte reagieren musst, wird es viel einfacher, relevante Details zu finden und bereitzustellen.

Grundlegende Sicherheitsprinzipien

Hinweis

Der Rest dieser Einführung gibt einen kurzen Überblick über die grundlegenden Sicherheitskonzepte und die Terminologie, die sowohl für Entwicklungsteams als auch für Sicherheitsexperten von entscheidender Bedeutung sind und mit denen sie zumindest einigermaßen vertraut sein sollten. Wenn du mehr über eines dieser Prinzipien erfahren möchtest, findest du in diesem Kapitel und im Buch viele ausgezeichnete Referenzen.

Die Vertrautheit mit diesen Grundsätzen und der Terminologie ist eine wichtige Grundlage für weiteres Lernen - als Einzelperson oder als Team, das auf seinen Sicherheitsreisen lernt.

Grundlegende Konzepte und Terminologie

Abbildung I-2 zeigt die wichtigsten Konzepte der Systemsicherheit. Das Verständnis dieser Zusammenhänge und der Nomenklatur der Sicherheit ist der Schlüssel zum Verständnis, warum die Modellierung von Bedrohungen für den Entwurf eines sicheren Systems von entscheidender Bedeutung ist.

Abbildung I-2. Zusammenhänge der Sicherheitsterminologie

Ein System enthält Werte - Funktionen, auf die sich die Benutzer verlassen, und Daten, die vom System angenommen, gespeichert, bearbeitet oder übertragen werden. Die Funktionalität des Systems kann Fehler enthalten, die auch als Schwachstellen bezeichnet werden. Wenn diese Schwachstellen ausnutzbar sind, d.h. wenn sie von außen beeinflusst werden können, werden sie als Schwachstellen bezeichnet, und ihre Ausnutzung kann den Betrieb und die Daten des Systems gefährden. Ein Akteur (eine Person oder ein Prozess außerhalb des Systems) kann böswillige Absichten haben und versuchen, eine Schwachstelle auszunutzen, wenn die Bedingungen dafür gegeben sind; einige erfahrene Angreifer sind in der Lage, die Bedingungen so zu verändern, dass sie Gelegenheiten zum Ausnutzen schaffen. In diesem Fall erzeugt ein Akteur ein Bedrohungsereignis und bedroht das System durch dieses Ereignis mit einer bestimmten Auswirkung (z. B. Diebstahl von Daten oder Fehlverhalten von Funktionen).

Die Kombination aus Funktionalität und Daten schafft einen Wert im System, und ein Angreifer, der eine Bedrohung verursacht, macht diesen Wert zunichte, was die Grundlage für Risiko bildet. Das Risiko wird durch Kontrollen ausgeglichen, die sowohl die funktionalen Fähigkeiten eines Systems als auch das betriebliche und organisatorische Verhalten der Teams, die das System entwerfen und aufbauen, abdecken, und wird durch Wahrscheinlichkeiten verändert - die Erwartungen eines Angreifers, der Schaden anrichten will, und die Wahrscheinlichkeit, dass er erfolgreich sein wird, wenn er dies versucht.

Jedes Konzept und jeder Begriff bedarf einer zusätzlichen Erklärung, um sinnvoll zu sein:

Schwäche

Eine Schwäche ist ein zugrundeliegender Fehler, der das Verhalten oder die Funktionalität verändert (was zu einem falschen Verhalten führt) oder einen ungeprüften oder falschen Zugriff auf Daten ermöglicht. Schwachstellen im Systemdesign entstehen, wenn bewährte Methoden, Standards oder Konventionen nicht eingehalten werden, und führen zu unerwünschten Auswirkungen auf das System. Zum Glück für Bedrohungsmodellierer (und Entwicklungsteams) hat eine Gemeinschaftsinitiative - die CommonWeakness Enumeration (CWE)- eine offene Taxonomie von Sicherheitsschwachstellen erstellt, auf die bei der Untersuchung des Systemdesigns auf Bedenken verwiesen werden kann.

Ausnutzbarkeit

Die Ausnutzbarkeit ist ein Maß dafür, wie leicht ein Angreifer eine Schwachstelle ausnutzen kann, um Schaden anzurichten. Anders ausgedrückt: Die Ausnutzbarkeit ist das Ausmaß, in dem die Schwachstelle von außen beeinflusst werden kann.¹²

Schwachstelle

Wenn eine Schwachstelle ausnutzbar ist (die Ausnutzbarkeit außerhalb des lokalen Berechtigungskontextes ist ungleich Null), wird sie als Sicherheitslücke bezeichnet. Schwachstellen bieten einem Angreifer mit böswilligen Absichten die Möglichkeit, einem System in irgendeiner Form Schaden zuzufügen. Schwachstellen, die in einem System existieren, aber bisher unentdeckt sind, werden als Zero-Day-Schwachstellen bezeichnet. Zero-Day-Schwachstellen sind nicht mehr oder weniger gefährlich als andere Schwachstellen ähnlicher Art, aber sie sind etwas Besonderes, weil sie wahrscheinlich noch nicht behoben wurden und daher ein größeres Potenzial für ihre Ausnutzung haben. Wie bei den Schwachstellen hat die Community eine Taxonomie der Schwachstellen erstellt, die in der CVE-Datenbank verschlüsselt ist.

Schweregrad

Schwachstellen führen zu einer Beeinträchtigung eines Systems und seiner Werte (Funktionalität und/oder Daten); das Schadenspotenzial und der "Explosionsradius" eines solchen Problems wird als Schweregrad des Fehlers bezeichnet. Denjenigen, die hauptberuflich in einem technischen Bereich tätig sind oder waren, ist der Begriff Schweregrad vielleicht ein Begriff. Schwachstellen - ausnutzbare Schwachstellen - sind per Definition mindestens so schwerwiegend wie der zugrundeliegende Fehler, und häufiger wird der Schweregrad eines Fehlers erhöht, weil er ausgenutzt werden kann. Methoden zur Berechnung des Schweregrads werden in "Berechnung des Schweregrads oder Risikos" beschrieben .

Hinweis

Leider ist die Bestimmung des Schweregrads einer Schwachstelle nicht immer so eindeutig. Wenn zum Zeitpunkt der Entdeckung einer Schwachstelle noch nicht bekannt ist, dass der Fehler eine Auswirkung haben kann, wie schwerwiegend ist das Problem dann? Was passiert, wenn der Fehler später aufgedeckt wird oder, schlimmer noch, wenn er durch eine Änderung des Systemdesigns oder der Implementierung aufgedeckt wird? Diese Fragen sind schwer zu beantworten. Wir werden später darauf eingehen, wenn wir Risikokonzepte vorstellen.

Aufschlag

Wenn eine Schwachstelle oder ein Sicherheitsrisiko ausgenutzt wird, hat das Auswirkungen auf das System,wie z. B. den Verlust von Funktionen oder die Preisgabe von Daten. Wenn du den Schweregrad einer Schwachstelle bewertest, solltest du den Grad der Auswirkung als Maß für den potenziellen Verlust von Funktionen und/oder Daten bei erfolgreicher Ausnutzung einschätzen.

Schauspieler

Bei der Beschreibung eines Systems ist ein Akteur jede Person, die mit dem System in Verbindung steht, z. B. ein Benutzer oder ein Angreifer. Ein Akteur mit böswilligen Absichten, entweder innerhalb oder außerhalb der Organisation, der das System erstellt oder nutzt, wird manchmal auch als Angreifer bezeichnet.

Bedrohung

Eine Bedrohung ist das Ergebnis einer von Null abweichenden Wahrscheinlichkeit, dass ein Angreifer eine Schwachstelle ausnutzt, um das System auf eine bestimmte Art und Weise negativ zu beeinflussen (üblicherweise als "Bedrohung für..." oder "Bedrohung von..." formuliert).

Bedrohungsereignis

Wenn ein Angreifer einen (erfolgreichen oder nicht erfolgreichen) Versuch unternimmt, eine Schwachstelle mit einem bestimmten Ziel oder Ergebnis auszunutzen, wird dies als Bedrohungsereignis bezeichnet.

Verlust

Für die Zwecke dieses Buches und des Themas der Bedrohungsmodellierung tritt ein Verlust ein, wenn eine (oder mehrere) Auswirkungen auf die Funktionalität und/oder Daten haben, weil ein Angreifer ein Bedrohungsereignis verursacht:

• Der Akteur ist in der Lage, die Vertraulichkeit der Daten eines Systems zu untergraben, um sensible oder private Informationen preiszugeben.

• Der Akteur kann die Schnittstelle zur Funktionalität, das Verhalten der Funktionalität oder den Inhalt oder die Herkunft der Daten ändern.

• Der Akteur kann berechtigte Personen vorübergehend oder dauerhaft am Zugriff auf Funktionen oder Daten hindern.

  Der Verlust wird in Form eines Vermögenswerts oder eines Wertbetrags beschrieben.

Risiko

Das Risiko kombiniert den Wert des potenziell auszunutzenden Ziels mit der Wahrscheinlichkeit, dass ein Schaden eintritt. Der Wert ist sowohl für den Eigentümer des Systems oder der Informationen als auch für den Angreifer relativ. Du solltest das Risiko nutzen, um die Priorität eines Problems zu bestimmen und zu entscheiden, ob das Problem angegangen werden soll. Schwere Schwachstellen, die leicht auszunutzen sind, und solche, die zu erheblichen Schäden führen, sollten mit hoher Priorität beseitigt werden.

Berechnung der Schwere oder des Risikos

Der Schweregrad (die Höhe des Schadens, der durch die erfolgreiche Ausnutzung einer Schwachstelle verursacht werden kann), und das Risiko (die Kombination aus der Wahrscheinlichkeit, dass ein Bedrohungsereignis ausgelöst wird, und der Wahrscheinlichkeit, dass die Ausnutzung zu negativen Auswirkungen führt) können formelhaft bestimmt werden. Die Formeln sind nicht perfekt, aber ihre Verwendung sorgt für Konsistenz. Heutzutage gibt es viele Methoden, um den Schweregrad oder das Risiko zu bestimmen, und einige Methoden zur Modellierung von Bedrohungen verwenden alternative Risikobewertungsmethoden (die in diesem Buch nicht beschrieben werden). Im Folgenden werden drei gängige Methoden vorgestellt (eine für die Messung der Schwere, zwei für das Risiko).

CVSS (Schweregrad)

Das Common Vulnerability Scoring System (CVSS) ist jetzt in Version 3.1, und ist ein Produkt des Forum of Incident Response and Security Teams (FIRST).

CVSS ist eine Methode zur Ermittlung eines Wertes von 0,0 bis 10,0, mit der du die Komponenten des Schweregrades identifizieren kannst. Die Berechnung von basiert auf der Wahrscheinlichkeit, dass eine Schwachstelle erfolgreich ausgenutzt werden kann, und einer Messung der potenziellen Auswirkungen (oder des Schadens). Acht Kennzahlen oder Werte werden in den Rechner eingegeben, um den Schweregrad zu ermitteln, wie in Abbildung I-3 dargestellt.

Abbildung I-3. Common Vulnerability Scoring System Metriken, Vektor und Punktzahl

Die Erfolgswahrscheinlichkeit wird anhand bestimmter Kennzahlen gemessen, die mit einer numerischen Bewertung versehen werden. Daraus ergibt sich ein Wert, der unter als Exploitability Subscore bekannt ist. Die Auswirkung wird auf ähnliche Weise gemessen (mit anderen Kennzahlen) und wird als Teilbewertung Auswirkung bezeichnet. Werden die beiden Teilbewertungen addiert, ergibt sich eine Gesamtgrundbewertung.

Tipp

Erinnere dich: CVSS misst nicht das Risiko, sondern den Schweregrad. CVSS kann dir sagen, wie wahrscheinlich es ist, dass es einem Angreifer gelingt, die Schwachstelle eines betroffenen Systems auszunutzen, und wie groß der Schaden ist, den er anrichten kann. Er kann aber nicht sagen, wann oder ob ein Angreifer versuchen wird, die Schwachstelle auszunutzen. Sie kann auch nicht sagen, wie viel die betroffene Ressource wert ist oder wie teuer es sein wird, die Schwachstelle zu beheben. Die Risikoberechnung richtet sich nach der Wahrscheinlichkeit eines Angriffs, dem Wert des Systems oder der Funktionalität und den Kosten für die Behebung der Schwachstelle. Sich auf den bloßen Schweregrad zu verlassen, ist ein guter Weg, um Informationen über einen Fehler zu vermitteln, aber ein sehr unvollkommener Weg, um Risiken zu managen.

DREAD (Risiko)

DREAD ist eine ältere,¹³ aber grundlegend wichtige Methode zum Verständnis des Risikos von Sicherheitsbedenken. DREAD ist der Partner der STRIDE-Bedrohungsmodellierungsmethode; STRIDE wird in Kapitel 3 ausführlich behandelt.

DREAD ist ein Akronym für:

Schaden

Wenn ein Gegner einen Angriff durchführt, wie viel Zerstörung könnte er anrichten?

Reproduzierbarkeit

Ist ein potenzieller Angriff leicht zu reproduzieren (in Methode und Wirkung)?

Ausnutzbarkeit

Wie einfach ist es, einen erfolgreichen Angriff durchzuführen?

Betroffene Nutzer

Welcher Prozentsatz der Nutzer/innen könnte davon betroffen sein?

Entdeckbarkeit

Wenn der Gegner nicht bereits von der Möglichkeit eines Angriffs weiß, wie hoch ist dann die Wahrscheinlichkeit, dass er ihn entdeckt?

DREAD ist ein Verfahren zur Dokumentation von Merkmalen eines potenziellen Angriffs auf ein System (über einen Vektor durch einen Angreifer) und zur Ermittlung eines Wertes, der mit anderen solchen Werten für andere Angriffsszenarien und/oder Bedrohungsvektoren verglichen werden kann. Der Risikowert für ein bestimmtes Angriffsszenario (Kombination aus Sicherheitslücke und Angreifer) wird berechnet, indem die Merkmale der Ausnutzung einer Sicherheitslücke durch einen Angreifer berücksichtigt werden und ihnen eine Punktzahl in jeder Dimension (d.h. D, R, E, A, D) für Probleme mit geringer, mittlerer bzw. hoher Auswirkung zugewiesen wird.

Die Summe der Punktzahlen für jede Dimension bestimmt den Gesamtrisikowert. Ein beliebiges Sicherheitsproblem in einem bestimmten System kann zum Beispiel folgende Werte haben: [D = 3, R = 1, E = 1, A = 3, D = 2], was einem Gesamtrisikowert von 10 entspricht. Um sinnvoll zu sein, kann dieser Risikowert mit anderen Risiken verglichen werden, die für dieses bestimmte System ermittelt wurden; es ist jedoch weniger sinnvoll, diesen Wert mit Werten anderer Systeme zu vergleichen.

FAIR Methode zur Risikoquantifizierung (Risiko)

Die Factor Analysis of Information Risk (FAIR) -Methode wird immer beliebter unter Führungskräften, weil sie die richtige Granularität mit mehr Spezifität bietet, um eine effektivere Entscheidungsfindung zu ermöglichen. FAIR wird von der Open Group veröffentlicht und ist in der ISO/IEC 27005:2018 enthalten.

DREAD ist ein Beispiel für eine qualitative Risikoberechnung. FAIR ist ein internationaler Standard zur quantitativen Risikomodellierung und zum Verständnis der Auswirkungen von Bedrohungen auf Vermögenswerte, indem der Wert (Kosten in harter und weicher Währung) und die Wahrscheinlichkeit der Realisierung einer Bedrohung durch einen Akteur gemessen werden. Nutze diese quantitativen Werte, um deinem Management und deinen Führungskräften die finanziellen Auswirkungen der in deinen Systemen identifizierten Risiken auf das Unternehmen zu beschreiben und sie mit den Kosten für die Abwehr von Bedrohungsereignissen zu vergleichen. Ein gutes Risikomanagement legt nahe, dass die Kosten für die Abwehr nicht höher sein sollten als der Wert des Vermögenswertes oder der potenzielle Verlust eines Vermögenswertes. Dies ist auch bekannt als das Paradigma des 50-Dollar-Schlosses für einen 5-Dollar-Stift.

Warnung

FAIR ist gründlich und genau, aber auch komplex und erfordert spezielle Kenntnisse, um die Berechnungen und Simulationen korrekt durchzuführen. Das ist nichts, was du live in einer Sitzung zur Überprüfung von Bedrohungsmodellen machen willst, und auch nichts, was du deinen Sicherheitsexperten (SMEs) aufbürden willst, falls du welche hast. Sicherheitsexperten sind Experten im Aufspüren von Schwachstellen und Bedrohungen, nicht in der Modellierung von finanziellen Auswirkungen. Wenn du FAIR einführen willst, ist es besser, Personen mit Kenntnissen in Berechnungsmethoden und finanzieller Modellierung einzustellen oder ein Tool zu finden, das die schwierigen Berechnungen für dich übernimmt.

Kern-Eigenschaften

Drei Kerneigenschaften - Vertraulichkeit, Integrität und Verfügbarkeit - bilden die Grundlage, auf der alle anderen Dinge in der Sicherheit aufgebaut sind. Wenn jemand wissen will, ob etwas sicher ist, bestimmen diese Eigenschaften und ob sie intakt sind, die Antwort. Diese Eigenschaften unterstützen ein wichtiges Ziel: Vertrauenswürdigkeit. Die vierte und fünfte Eigenschaft (Privatsphäre und Sicherheit) hängen mit den ersten drei zusammen, haben aber einen etwas anderen Schwerpunkt.

Vertraulichkeit

Ein System hat nur dann die Eigenschaft der Vertraulichkeit, wenn es den Zugang zu den ihm anvertrauten Daten ausschließlich denjenigen garantiert, die aufgrund ihrer Notwendigkeit, die geschützten Informationen zu kennen, über die entsprechenden Rechte verfügen. Ein System, das keinen Schutz vor unbefugtem Zugriff bietet, schlägt fehl.¹⁴

Integrität

Integrität ist gegeben, wenn die Authentizität von Daten oder Vorgängen überprüft werden kann und die Daten oder Funktionen nicht durch unautorisierte Aktivitäten verändert oder unauthentisch gemacht wurden.¹⁵

Verfügbarkeit

Verfügbarkeit bedeutet, dass autorisierte Akteure in der Lage sind, auf Systemfunktionen und/oder Daten zuzugreifen, wann immer sie dies benötigen oder wünschen. Unter bestimmten Umständen kann es vorkommen, dass die Daten oder der Betrieb eines Systems aufgrund eines Vertrags oder einer Vereinbarung zwischen Nutzern und Systembetreibern nicht verfügbar sind (z. B. wenn eine Website wegen regelmäßiger Wartungsarbeiten nicht erreichbar ist); wenn das System aufgrund einer böswilligen Aktion eines Gegners nicht verfügbar ist, ist die Verfügbarkeit gefährdet.¹⁶

Datenschutz

Während sich Vertraulichkeit auf den kontrollierten Zugang zu privaten Informationen bezieht, die mit anderen geteilt werden, bezieht sich die Privatsphäre auf das Recht, dass diese Informationen nicht an unbefugte Dritte weitergegeben werden. Wenn Menschen von Vertraulichkeit sprechen, erwarten sie oft eigentlich Privatsphäre, aber obwohl die Begriffe oft austauschbar verwendet werden, sind sie nicht dasselbe Konzept. Man könnte argumentieren, dass Vertraulichkeit eine Voraussetzung für Datenschutz ist. Wenn ein System zum Beispiel die Vertraulichkeit der gespeicherten Daten nicht garantieren kann, kann es seinen Nutzern auch keine Privatsphäre bieten.

Sicherheit

Sicherheit ist "das Fehlen eines unannehmbaren Risikos von Körperverletzungen oder Gesundheitsschäden für Menschen, entweder direkt oder indirekt als Folge von Sachschäden oder Umweltschäden."¹⁷ Damit etwas den Sicherheitsanforderungen entspricht, muss es natürlich auf vorhersehbare Weise funktionieren. Das bedeutet, dass es zumindest die Sicherheitseigenschaften Integrität und Verfügbarkeit aufrechterhalten muss.

Grundlegende Kontrollen

Die folgenden Kontrollen bzw. funktionalen Verhaltensweisen und Fähigkeiten unterstützen die Entwicklung von hochsicheren Systemen.

Identifizierung

Den Akteuren in einem System muss ein eindeutiger Identifikator zugewiesen werden, der für das System von Bedeutung ist. Die Identifikatoren sollten auch für die Personen oder Prozesse, die die Identität verwenden, aussagekräftig sein (z. B. das Authentifizierungssubsystem; die Authentifizierung wird im Folgenden beschrieben).

Ein Akteur ist alles in einem System (einschließlich menschlicher Benutzer, Systemkonten und Prozesse), das Einfluss auf das System und seine Funktionen hat oder auf die Daten des Systems zugreifen möchte. Um viele Sicherheitsziele zu erreichen, muss einem Akteur eine Identität zugewiesen werden, bevor er in dem System agieren kann. Diese Identität muss mit Informationen versehen sein, die es dem System ermöglichen, den Akteur eindeutig zu identifizieren - oder mit anderen Worten, dem System einen Identitätsnachweis zu liefern. In einigen öffentlichen Systemen werden auch namenlose Akteure oder Nutzer identifiziert, was darauf hinweist, dass ihre spezifische Identität nicht wichtig ist, aber dennoch im System vertreten ist.

Tipp

Gast ist auf vielen Systemen eine akzeptable Identität für ein gemeinsames Konto. Es gibt auch andere gemeinsame Konten, deren Nutzung jedoch sorgfältig abgewogen werden sollte, da sie nicht in der Lage sind, das Verhalten der Akteure auf individueller Basis zu verfolgen und zu kontrollieren.

Authentifizierung

Akteure mit Identitäten müssen ihre Identität gegenüber dem System nachweisen. Der Identitätsnachweis erfolgt in der Regel durch einen Berechtigungsnachweis (z. B. ein Passwort oder ein Sicherheits-Token).

Alle Akteure, die das System nutzen wollen, müssen einen zufriedenstellenden Nachweis ihrer Identität erbringen können, damit das Zielsystem überprüfen kann, ob es mit dem richtigen Akteur kommuniziert. Die Authentifizierung ist eine Voraussetzung für zusätzliche Sicherheitsfunktionen.

Autorisierung

Sobald ein Akteur authentifiziert wurde, d.h. seine Identität zufriedenstellend nachgewiesen wurde, kann der Akteur innerhalb des Systems Privilegien erhalten, um Operationen durchzuführen oder auf Funktionen oder Daten zuzugreifen. Die Autorisierung ist kontextabhängig und kann, muss aber nicht, transitiv, bidirektional oder reziprok sein.

Mit der Authentifizierung kann ein System auf der Grundlage des angebotenen Identifikationsnachweises eines Akteurs dessen Rechte festlegen. Wenn sich ein Nutzer beispielsweise in einem System authentifiziert hat und Operationen in einer Datenbank durchführen darf, wird der Zugriff auf diese Datenbank nur auf der Grundlage der Rechte des Akteurs gewährt. Der Zugriff wird in der Regel in Form von primitiven Operationen wie read, write oder execute gewährt. Zu den Zugriffskontrollsystemen, die das Verhalten eines Akteurs innerhalb eines Systems regeln, gehören die folgenden:

Obligatorische Zugriffskontrolle (MAC)

Das System schränkt die Berechtigungen für Akteure ein.

Ermessensabhängige Zugriffskontrolle (DAC)

Die Akteure können Privilegien für Vorgänge festlegen.

Rollenbasierte Zugriffskontrolle (RBAC)

Die Akteure werden nach sinnvollen "Rollen" gruppiert, wobei die Rollen die Zuweisung von Privilegien festlegen.

Fähigkeitsorientierte Zugriffskontrolle

Ein Autorisierungssubsystem vergibt Rechte in Form von Token, die die Akteure beantragen (und erhalten) müssen, um Operationen durchführen zu können.

Tipp

Gastkonten werden in der Regel nicht authentifiziert (es muss keine Identität nachgewiesen werden), aber diese Konten können explizit mit einem minimalen Fähigkeitsniveau autorisiert werden.

Loggen

Wenn ein Akteur (Mensch oder Prozess) eine Systemoperation durchführt, z. B. ein Feature ausführt oder auf Datenspeicher zugreift, sollte ein Datensatz dieses Ereignisses aufgezeichnet werden. Dies unterstützt die Rückverfolgbarkeit. Wenn die aufgezeichneten Ereignisse als sicherheitsrelevant eingestuft werden, unterstützt die Rückverfolgbarkeit auch kritische Aufgaben wie die Erkennung und Verhinderung von Eindringlingen, die Forensik und die Sammlung von Beweisen (falls ein böswilliger Akteur in ein System eingedrungen ist).

Rechnungsprüfung

Durch die Protokollierung werden Aufzeichnungen erstellt; Audit-Aufzeichnungen sind klar definiert (in Format und Inhalt), zeitlich geordnet, und in der Regel manipulationssicher (oder zumindest fälschungssicher). Die Möglichkeit, "in der Zeit zurückzublicken" und zu verstehen, in welcher Reihenfolge Ereignisse aufgetreten sind, wer welche Vorgänge wann durchgeführt hat und ob die Vorgänge korrekt und autorisiert waren, ist für Sicherheitsvorgänge und die Reaktion auf Vorfälle entscheidend.

Grundlegende Entwurfsmuster für sichere Systeme

Wenn du ein System entwirfst, solltest du bestimmte Sicherheitsprinzipien und -methoden im Hinterkopf behalten. Nicht alle Grundsätze müssen auf dein System zutreffen. Aber es ist wichtig, dass du sie berücksichtigst, um sicherzustellen, dass sie auf dich zutreffen.

1975 wurde ein bahnbrechender Artikel von Jerome Saltzer und Michael Schroeder, "The Protection of Information in Computer Systems", veröffentlicht.¹⁸ veröffentlicht. Obwohl sich seit der Veröffentlichung viel geändert hat, sind die Grundprinzipien immer noch gültig. Einige der Grundlagen, die wir in diesem Buch besprechen, basieren auf den von Saltzer und Schroeder aufgestellten Prinzipien. Wir wollen dir auch zeigen, wie einige dieser Grundsätze auf andere Weise relevant geworden sind, als ursprünglich beabsichtigt.

Null Vertrauen

Ein gängiger Ansatz für die Systementwicklung und die Einhaltung von Sicherheitsvorschriften ist "Vertrauen, aber Überprüfung" oder Null-Vertrauen ( ). Dabei wird das beste Ergebnis für eine Operation angenommen (z. B. ein Gerät, das einem Netzwerk beitritt, oder ein Client, der eine API aufruft) und dann eine Überprüfung der Vertrauensbeziehung in zweiter Linie durchgeführt. In einer Zero-Trust-Umgebung ignoriert das System alle vorherigen Vertrauensbeziehungen (oder baut sie gar nicht erst auf) und überprüft stattdessen alles, bevor es sich entscheidet, eine Vertrauensbeziehung aufzubauen (die dann möglicherweise nur vorübergehend ist).¹⁹

Dieses Konzept, das auch als vollständige Mediation bezeichnet wird, sieht auf dem Papier verblüffend einfach aus: Stelle sicher, dass die Rechte für den Zugriff auf eine Operation bei jedem Zugriff auf ein Objekt überprüft werden und dass die Rechte für diese Zugriffsoperation vorher überprüft werden. Mit anderen Worten: Jedes Mal, wenn ein Akteur auf ein Objekt zugreift, muss überprüft werden, ob er die richtigen Rechte dafür hat.

Hinweis

John Kindervag hat das Konzept des Zero Trust im Jahr 2010 entwickelt,²⁰ und wurde es häufig in Diskussionen über die Netzwerkarchitektur verwendet. Die Autoren haben beschlossen, das Konzept in die Sicherheitsgrundsätze zu übernehmen, und sind der Meinung, dass es ohne Änderungen auch für die Sicherheitsentscheidungen gilt, die auf der Anwendungsebene getroffen werden müssen.

Design per Vertrag

Design by contract ist mit Zero Trust verwandt und geht davon aus, dass, wenn ein Client einen Server anruft, die Eingabe, die von diesem Client kommt, ein bestimmtes festes Format hat und nicht von diesem Vertrag abweicht.

Es ist vergleichbar mit einem Schloss-Schlüssel-Paradigma. Dein Schloss akzeptiert nur den richtigen Schlüssel und traut nichts anderem. In "Securing the Tangled Web,"²¹ Christoph Kern erklärt, wie Google die Anzahl der Cross-Site-Scripting (XSS)-Fehler in Anwendungen deutlich reduziert hat, indem es eine Bibliothek mit inhärent sicheren API-Aufrufen verwendet - per Design. Design by contract verhindert Nullvertrauen, indem es sicherstellt, dass jede Interaktion einem festen Protokoll folgt.

Das geringste Privileg

Dieses Prinzip bedeutet, dass eine Operation nur mit der restriktivsten Berechtigungsstufeausgeführt werden sollte, die es noch ermöglicht, die Operation erfolgreich durchzuführen. Mit anderen Worten: Achte in allen Schichten und bei allen Mechanismen darauf, dass dein Entwurf den Operator auf die minimale Zugriffsstufe beschränkt, die für die Durchführung einer einzelnen Operation erforderlich ist, und nicht mehr.

Wenn das Prinzip der geringsten Privilegien nicht befolgt wird, kann eine Schwachstelle in einer Anwendung den vollständigen Zugriff auf das zugrunde liegende Betriebssystem ermöglichen und damit alle Folgen eines privilegierten Benutzers, der ungehinderten Zugang zu deinem System und deinen Werten hat. Dieser Grundsatz gilt für jedes System, das einen Berechtigungskontext unterhält (z. B. ein Betriebssystem, eine Anwendung, Datenbanken usw.).

Defense in depth

Defense in depth verwendet einen vielschichtigen und mehrschichtigen Ansatz, um ein System und seine Ressourcen zu schützen.

Wenn du über die Verteidigung deines Systems nachdenkst, denke an die Dinge, die du schützen willst - die Vermögenswerte - und wie ein Angreifer versuchen könnte, auf sie zuzugreifen. Überlege dir, welche Kontrollen du einrichten könntest, um den Zugriff durch einen Angreifer einzuschränken oder zu verhindern (aber einem ordnungsgemäß autorisierten Akteur den Zugriff zu ermöglichen). Du könntest parallele oder sich überschneidende Kontrollschichten in Betracht ziehen, um den Angreifer zu verlangsamen, oder du könntest Funktionen implementieren, die einen Angreifer verwirren oder aktiv abschrecken.

Beispiele für die Anwendung von Defense in Depth auf Computersysteme sind folgende:

• Verteidigung eines bestimmten Arbeitsplatzes mit Schlössern, Wachen, Kameras und Luftschleusen

• Einführung eines Bastion-Hosts (oder einer Firewall) zwischen dem System und dem öffentlichen Internet, dann ein Endpunkt-Agent im System selbst

• Multifaktor-Authentifizierung als Ergänzung zu einem Passwortsystem für die Authentifizierung, mit einer Zeitverzögerung, die exponentiell zwischen erfolglosen Versuchen ansteigt

• Einsatz eines Honeypots und einer gefälschten Datenbankschicht mit absichtlich prioritätsbeschränkten Authentifizierungsfunktionen

Jeder zusätzliche Faktor, der als "Stolperstein" fungiert und einen Angriff in Bezug auf Komplexität, Geld und/oder Zeit teurer macht, ist eine erfolgreiche Schicht in deiner Defense-in-Depth. Diese Art der Bewertung von Defense-in-Depth-Maßnahmen hängt mit dem Risikomanagement zusammen - Defense-in-Depth bedeutet nicht immer Verteidigung um jeden Preis. Es ist ein Balanceakt zwischen der Entscheidung, wie viel man für die Sicherung von Vermögenswerten ausgibt, und dem wahrgenommenen Wert dieser Vermögenswerte, was in den Bereich des Risikomanagements fällt.

Die Dinge einfach halten

Wenn du die Dinge einfach halten willst, musst du vermeiden, dein System zu kompliziert zu gestalten. Mit der Komplexität kommt das erhöhte Potenzial für Instabilität, Herausforderungen bei der Wartung und anderen Aspekten des Systembetriebs sowie ein Potenzial für unwirksame Sicherheitskontrollen.²²

Es muss auch darauf geachtet werden, dass wir nicht zu sehr vereinfachen (indem wir wichtige Details weglassen oder übersehen). Das passiert oft bei der Eingabevalidierung, da wir (zu Recht oder zu Unrecht) davon ausgehen, dass ein vorgeschalteter Datengenerator immer gültige und sichere Daten liefert, und unsere eigene Eingabevalidierung (zu Unrecht) vermeiden, um die Dinge zu vereinfachen. Eine ausführlichere Diskussion über diese Erwartungen findest du unter Brook S. E. Schoenfields Arbeit über Sicherheitsverträge.²³ Letztendlich bietet ein sauberes, einfaches Design im Laufe der Zeit oft einen Sicherheitsvorteil gegenüber einem übertechnisierten und sollte daher bevorzugt werden.

Keine geheime Sauce

Verlasse dich nicht auf die Unsichtbarkeit als Mittel zur Sicherheit. Dein Systemdesign sollte auch dann noch angreifbar sein, wenn jedes einzelne Detail der Implementierung bekannt und veröffentlicht ist. Das heißt aber nicht, dass du es veröffentlichen musst,²⁴ Es bedeutet nur, dass du davon ausgehen solltest, dass jedes Detail bekannt ist, und dass du dich nicht darauf verlassen solltest, dass irgendetwas davon geheim gehalten wird, um dein Vermögen zu schützen. Wenn du einen Vermögenswert schützen willst, verwende die richtige Kontrolle - Verschlüsselung oder Hashing - und hoffe nicht, dass ein Akteur fehlschlägt oder deine Geheimnisse entdeckt!

Trennung der Privilegien

Dieses Prinzip wird auch als Aufgabentrennung bezeichnet und bedeutet, dass der Zugriff auf Funktionen oder Daten innerhalb deines Systems getrennt wird, damit nicht ein Akteur alle Rechte besitzt. Zu den verwandten Konzepten gehören "maker/checker", bei denen ein Nutzer (oder Prozess) eine Operation anfordert und die Parameter festlegt, während ein anderer Nutzer oder Prozess die Transaktion autorisieren muss. Das bedeutet, dass ein einzelner Akteur nicht ungehindert und ohne die Möglichkeit der Kontrolle bösartige Aktivitäten durchführen kann.

Berücksichtige den menschlichen Faktor

Menschliche Nutzer werden als das schwächste Glied in jedem System bezeichnet,²⁵ Daher muss das Konzept der psychologischen Akzeptanz eine grundlegende Designvorgabe sein. Nutzer, die von starken Sicherheitsmaßnahmen frustriert sind, werden unweigerlich versuchen, diese zu umgehen.

Bei der Entwicklung eines sicheren Systems ist es wichtig zu entscheiden, wie viel Sicherheit für den Nutzer akzeptabel ist. Es gibt einen Grund, warum wir eine Zwei-Faktor-Authentifizierung und keine Sechzehn-Faktor-Authentifizierung haben. Wenn du zu viele Hürden zwischen einem Nutzer und dem System aufstellst, wird eine dieser Situationen eintreten:

• Der Nutzer hört auf, das System zu benutzen.

• Der Nutzer findet Umgehungsmöglichkeiten, um die Sicherheitsmaßnahmen zu umgehen.

• Die Machthaber unterstützen die Entscheidung für die Sicherheit nicht mehr, weil sie die Produktivität beeinträchtigt.

Effektives Loggen

Bei der Sicherheit geht es nicht nur darum, zu verhindern, dass etwas Schlimmes passiert, sondern auch darum, zu wissen, dass etwas passiert ist und - soweit möglich - was passiert ist. Um zu wissen, was passiert ist, muss man Ereignisse effektiv protokollieren können.

Aber was macht eine effektive Protokollierung aus? Aus der Sicht der Sicherheit muss ein Sicherheitsanalytiker drei Fragen beantworten können:

• Wer hat eine bestimmte Aktion durchgeführt, damit ein Ereignis aufgezeichnet wird?

• Wann wurde die Aktion durchgeführt oder das Ereignis aufgezeichnet?

• Auf welche Funktionen oder Daten hat der Prozess oder Benutzer zugegriffen?

Unleugbarkeit, die eng mit Integrität zusammenhängt, bedeutet, dass es eine Reihe von Transaktionen gibt, die angeben, wer was getan hat, wobei die Aufzeichnung jeder Transaktion die Integrität als Eigenschaft beibehält. Bei diesem Konzept ist es für einen Akteur unmöglich zu behaupten, dass er eine bestimmte Aktion nicht durchgeführt hat.

Warnung

So wichtig es ist, zu wissen, was man protokolliert und wie man es schützt, so wichtig ist es auch zu wissen, was man nicht protokolliert. Im Besonderen:

• Persönlich identifizierbare Informationen (PII) sollten nie im Klartext protokolliert werden, um die Privatsphäre der Nutzerdaten zu schützen.

• Sensible Inhalte, die Teil von API- oder Funktionsaufrufen sind, sollten niemals protokolliert werden.

• Klartextversionen von verschlüsselten Inhalten sollten ebenfalls nicht protokolliert werden.

• Kryptografische Geheimnisse, wie z. B. ein Passwort für ein System oder ein Schlüssel zur Entschlüsselung von Daten, sollten nicht protokolliert werden.

Hier ist es wichtig, den gesunden Menschenverstand walten zu lassen, aber beachte, dass die Integration dieser Logs in den Code ein ständiger Kampf gegen die Bedürfnisse der Entwicklung (vor allem der Fehlersuche) ist. Es ist wichtig, den Entwicklungsteams klarzumachen, dass es inakzeptabel ist, Schalter im Code zu haben, die steuern, ob sensible Inhalte zu Debugging-Zwecken protokolliert werden sollen. Einsetzbarer, produktionsreifer Code sollte keine Protokollierungsfunktionen für sensible Informationen enthalten.

Sicher fehlschlagen

Wenn ein System auf einen Fehlerzustand stößt, bedeutet dieses Prinzip , dass einem potenziellen Angreifer nicht zu viele Informationen preisgegeben werden (z. B. in Protokollen oder Benutzerfehlermeldungen) und dass nicht einfach fälschlicherweise Zugang gewährt wird, z. B. wenn der Fehler im Authentifizierungssubsystem liegt.

Es ist jedoch wichtig zu verstehen, dass es einen großen Unterschied zwischen fehlschlagsicher und ausfallsicher gibt. Das Fehlschlagen unter Beibehaltung der Sicherheit kann der Bedingung des sicheren Fehlschlagens widersprechen und muss in der Systemkonzeption unter einen Hut gebracht werden. Welche der beiden Varianten in einer bestimmten Situation angemessen ist, hängt natürlich von den Besonderheiten der Situation ab. Wenn eine Komponente oder die Logik des Systems fehlschlägt, bedeutet das, dass das System trotzdem sicher ist.

Einbauen, nicht anschrauben

Sicherheit, Datenschutz und Sicherheit sollten grundlegende Eigenschaften des Systems sein, und alle Sicherheitsfunktionen sollten von Anfang an in das System integriert werden .²⁶

Wie der Datenschutz oder die Sicherheit sollte auch die Sicherheit nicht als nachträglicher Gedanke betrachtet werden und nicht ausschließlich oder hauptsächlich von externen Systemkomponenten abhängen, um vorhanden zu sein. Ein gutes Beispiel für dieses Muster ist die Implementierung einer sicheren Kommunikation; das System muss dies von Haus aus unterstützen, d. h. es sollte so konzipiert sein, dass es Transport Layer Security (TLS) oder eine ähnliche Methode zur Wahrung der Vertraulichkeit von Daten während der Übertragung unterstützt. Wenn du dich darauf verlässt, dass der/die Nutzer/in spezielle Hardwaresysteme installiert, um die End-to-End-Kommunikation zu sichern, bedeutet das, dass die Kommunikation ungeschützt und potenziell für böswillige Akteure zugänglich ist, wenn der/die Nutzer/in dies nicht tut. Gehe nicht davon aus, dass die Nutzer/innen in deinem Namen Maßnahmen ergreifen, wenn es um die Sicherheit deines Systems geht.

Zusammenfassung

Nach der Lektüre dieser Einführung solltest du über das nötige Grundlagenwissen verfügen, um das meiste aus den folgenden Kapiteln herauszuholen: die Grundlagen der Bedrohungsmodellierung und wie sie sich in den Lebenszyklus der Systementwicklung einfügt, sowie die wichtigsten Sicherheitskonzepte, Terminologie und Prinzipien, die für das Verständnis der Sicherheit deines Systems grundlegend sind. Wenn du eine Bedrohungsmodellierung durchführst, wirst du nach diesen Sicherheitsprinzipien im Entwurf deines Systems suchen, um sicherzustellen, dass dein System angemessen vor Eindringlingen oder Kompromittierung geschützt ist.

In Kapitel 1 erläutern wir, wie man abstrakte Darstellungen eines Systementwurfs erstellt, um Sicherheits- oder Datenschutzprobleme zu identifizieren. In späteren Kapiteln werden wir spezifische Methoden zur Bedrohungsmodellierung vorstellen, die auf den Konzepten in dieser Einführung und den Modellierungstechniken in Kapitel 1 aufbauen, um mithilfe der Bedrohungsmodellierung vollständige Bewertungen der Sicherheitsbedrohungen durchzuführen.

Willkommen an Bord des Sicherheitszuges!

¹ Dieser Satz wird Wilf Hey und dem Army Specialist William D. Mellin zugeschrieben.

² "Ein Cargo-Kult ist ein millenarisches Glaubenssystem, in dem die Anhänger Rituale praktizieren, von denen sie glauben, dass sie eine technologisch fortschrittlichere Gesellschaft dazu bringen werden, Waren zu liefern." Wikipedia, abgerufen am 24.10.2020.

³ Der LAMP-Stack besteht aus dem Linux-Betriebssystem, dem Apache-Webserver, der MySQL-Datenbank und der Skriptsprache PHP.

⁴ Der MEAN-Stack besteht aus MongoDB, Express.js, Angular.js und Node.js.

⁵ Arvinder Saini, "How Much Do Bugs Cost to Fix During Each Phase of the SDLC?," Software Integrity Blog, Synopsis, Januar 2017, https://oreil.ly/NVuSf; Sanket, "Exponential Cost of Fixing Bugs," DeepSource, Januar 2019, https://oreil.ly/ZrLvg.

⁶ "Was ist Serverless Computing?", Cloudflare, Zugriff im November 2020, https://oreil.ly/7L4AJ.

⁷ Isaac Sacolick, "Was ist CI/CD? Continuous Integration and Continuous Delivery Explained", InfoWorld, Januar 2020, https://oreil.ly/tDc-X.

⁸ Barry Boehm, Softwareentwicklung Economics (Prentice Hall, 1981).

⁹ Kayla Matthews, "What Do IoT Hacks Cost the Economy?", IoT For All, Oktober 2018, https://oreil.ly/EyT6e.

¹⁰ "Was ist WebAuthn?", Yubico, https://oreil.ly/xmmL9.

¹¹ Christoph Kern, "Preventing Security Bugs through Software Design", USENIX, August 2015, https://oreil.ly/rcKL_.

¹² "Extern" ist hier relativ und bezieht sich auf den so genannten Berechtigungskontext, z. B. das Betriebssystem, die Anwendung, Datenbanken usw.

¹³ Manche sagen, DREAD habe seinen Nutzen überlebt; siehe Irene Michlin, "Threat Prioritisation: DREAD Is Dead, Baby?", NCC Group, März 2016, https://oreil.ly/SJnsR.

¹⁴ NIST 800-53 Revision 4, "Security and Privacy Controls for Federal Information Systems and Organizations": B-5.

¹⁵ NIST 800-53 Revision 4, "Security and Privacy Controls for Federal Information Systems and Organizations": B-12.

¹⁶ NIST 800-160, Band 1, "Systems Security Engineering: Überlegungen für einen multidisziplinären Ansatz bei der Entwicklung vertrauenswürdiger sicherer Systeme": 166.

¹⁷ "Funktionale Sicherheit und IEC 61508", Internationale Elektrotechnische Kommission, https://oreil.ly/SUC-E.

¹⁸ J. Saltzer und M. Schroeder, "The Protection of Information in Computer Systems", University of Virginia Department of Computer Science, https://oreil.ly/MSJim.

¹⁹ "Zero Trust Architecture", National Cybersecurity Center of Excellence, https://oreil.ly/P4EJs.

²⁰ Brook S. E. Schoenfield, Experte für Bedrohungsmodellierung und vielseitiger Autor, erinnert uns daran, dass die Idee des "gegenseitigen Misstrauens" bereits 2003/04 von Microsoft geäußert wurde, aber leider konnten wir keinen Hinweis darauf finden. Wir vertrauen Brook!

²¹ Christoph Kern, "Securing the Tangled Web", acmqueue, August 2014, https://oreil.ly/ZHVrI.

²² Eric Bonabeau, "Understanding and Managing Complexity Risk", MIT Sloan Management Review, Juli 2007, https://oreil.ly/CfHAc.

²³ Brook S. E. Schoenfield, Secrets of a Cyber Security Architect (Boca Raton, FL: CRC Press, 2019).

²⁴ Außer bei Copyleft-Lizenzen und Open-Source-Projekten, versteht sich.

²⁵ "Humans Are the Weakest Link in the Information Security Chain", Kratikal Tech Pvt Ltd, Februar 2018, https://oreil.ly/INf8d.

²⁶ Einige Sicherheitsmerkmale oder -funktionen können sich negativ auf die Benutzerfreundlichkeit auswirken. Daher kann es akzeptabel sein, einige Sicherheitsfunktionen standardmäßig zu deaktivieren, wenn die Benutzer sie bei der Bereitstellung des Systems aktivieren können.