Integration der Bedrohungsmodellierung mit DevOps
Dieser Beitrag wurde von Simone Curzi, Anthony Nevico, Jonathan Davis, Rafael Pazos Rodriguez und Ben Hanson verfasst
Einführung
Die Bedrohungsmodellierung ist eine wichtige Sicherheitsmethode, die dabei hilft, die wichtigsten Risikominderungsmaßnahmen für eine Anwendung oder ein System zu identifizieren und zu priorisieren. Dieses Papier enthält einige Überlegungen dazu, wie es möglich ist, die Bedrohungsmodellierung effektiver und effizienter zu übernehmen, sie in moderne DevOps-Methoden und -Tools zu integrieren und sich auf den Mehrwert zu konzentrieren, der allen verschiedenen am Softwareentwicklungslebenszyklus beteiligten Akteuren geboten wird.
Ist dieses Papier etwas für Sie?
Dieses Papier ist das Ergebnis der Arbeit eines kleinen Teams von Sicherheits- und Bedrohungsmodellierungsexperten von Microsoft und berücksichtigt Eingaben und Ideen einiger der bekanntesten Experten außerhalb von Microsoft. Es versucht, eine einfache, aber dringende Frage zu beantworten: Was sollten wir tun, um sicherzustellen, dass der von uns verwendete Bedrohungsmodellierungsprozess an die modernen Anforderungen von Agile-Methoden und DevOps angepasst wird, sodass wir den erforderlichen Wert zu den niedrigsten Kosten bereitstellen?
Wenn Sie Produktbesitzer, Mitglied eines Sicherheitsteams oder einfach ein Entwickler sind und die Einführung von Bedrohungsmodellen als Teil Ihres Entwicklungslebenszyklus in Betracht ziehen, ist dieses Dokument genau das Richtige für Sie.
Wenn Sie die Bedrohungsmodellierung bereits eingeführt haben, finden Sie möglicherweise noch praktische Ideen zur Verbesserung Ihres Prozesses.
Nichtsdestotrotz ist das Papier darauf ausgelegt, Ideen zur Verbesserung aktueller Prozesse oder zur erfolgreichen Einführung der Bedrohungsmodellierung als Teil Ihres DevOps-Prozesses vorzustellen. Es werden keine spezifischen Tools oder Produkte vorgestellt, auch wenn wir hoffen, dass diese Ideen in Zukunft durch einige Tools oder Produkte umgesetzt werden. Daher finden Sie hier keine Ankündigungen neuer Tools oder Vorschauen auf kommende Funktionen.
Warum ist Bedrohungsmodellierung wichtig?
Bedrohungsmodellierung ist einer der wichtigsten Ansätze für die sichere Gestaltung von Softwarelösungen. Mithilfe der Bedrohungsmodellierung analysieren Sie ein System, identifizieren Angriffsvektoren und entwickeln Maßnahmen zur Minderung der durch diese Angriffe verursachten Risiken. Bei entsprechender Durchführung ist die Bedrohungsmodellierung ein hervorragender Bestandteil jedes Risikomanagementprozesses. Es kann auch dazu beitragen, Kosten zu senken, indem Designprobleme frühzeitig erkannt und behoben werden. Eine alte Studie des NIST schätzte, dass die Kosten für die Behebung eines Designproblems im Produktionscode etwa 40-mal höher sind als für die Reparatur während der Designphase. Es erspart außerdem Kosten aufgrund von Sicherheitsvorfällen für eventuelle Designprobleme. Bedenken Sie, dass der 2022 Bericht zu den Kosten von Datenschutzverletzungen von IBM Security und dem Ponemon Institute die durchschnittlichen Kosten einer Datenschutzverletzung auf 4,35 Millionen US-Dollar schätzt. Für die sogenannten Mega-Verstöße, bei denen über 50 Millionen Datensätze kompromittiert werden, belaufen sich die durchschnittlichen Kosten auf 387 Millionen US-Dollar!
Die Bedrohungsmodellierung ist die erste Aktivität, die Sie zum Schutz Ihrer Lösung durchführen können, da sie sich auf den Lösungsentwurf auswirkt. Diese Eigenschaft macht es zur effektivsten Sicherheitspraxis, die Sie auf Ihren SDLC anwenden können.
Microsoft blickt auf eine lange Geschichte der Bedrohungsmodellierung zurück. Im Jahr 1999 verfassten zwei (damals) Microsoft-Mitarbeiter, Loren Kohnfelder und Praerit Garg, ein Dokument mit dem Titel Die Bedrohungen für unsere Produkte. In diesem Dokument wurde der STRIDE-Ansatz vorgestellt, ein Synonym für den Bedrohungsmodellierungsprozess von Microsoft.
Die Bedrohungsmodellierung ist ein evolutionärer Prozess
Die Bedrohungsmodellierung ist kein statischer Prozess; Sie entwickelt sich, wenn sich Bedürfnisse und Technologien ändern.
Supply-Chain-Angriffe wie der jüngste, der auf SolarWinds abzielte, zeigen, dass mit der Bedrohungsmodellierung mehr Szenarien als die Lösung selbst, einschließlich Entwicklung und Bereitstellung, abgedeckt werden müssen.
Open-Source-Schwachstellen wie die jüngste für Log4j haben die Notwendigkeit gezeigt, den aktuellen Ansatz zu ergänzen, der auf der Einführung von Tools zur Software-Kompositionsanalyse basiert, um nach anfälligen Komponenten zu suchen, indem die Lösung defensiv gestaltet wird, um ihre Gefährdung zu begrenzen.
Der Einsatz neuer Technologien wie maschinelles Lernen führt zu neuen Angriffsvektoren, die verstanden und kontrolliert werden müssen. fDenken Sie beispielsweise an die Möglichkeit, böswillig erzeugte Geräusche abzuspielen, die für das menschliche Ohr nicht hörbar sind, um die Ausführung von Befehlen durch KI-Dienste zu veranlassen, wie erläutert in https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlini.
Bei Microsoft praktizieren verschiedene Produktgruppen unterschiedliche Varianten der Bedrohungsmodellierung basierend auf ihren spezifischen Sicherheitsanforderungen. Ziel jeder Variante ist es, ein angemessenes Maß an Sicherheit für die Szenarien zu gewährleisten, auf die sie angewendet wird. Was „angemessen“ bedeutet, ändert sich jedoch je nach spezifischem Kontext.
Beispielsweise unterscheidet sich die Sicherung von Windows von der Sicherung von Azure Cognitive Services, da diese Systeme sehr unterschiedliche Größen und Eigenschaften aufweisen. Ein wichtiger Aspekt der Bedrohungsmodellierung besteht darin, die Kosten gegen die Risikotoleranz einer Anwendung abzuwägen. Während dies in einigen Szenarien zu der Entscheidung führen kann, auf die Bedrohungsmodellierung ganz zu verzichten, ist sie bei richtiger Durchführung so effektiv, dass wir nur empfehlen können, sie für jede IT-Initiative, einschließlich Softwareentwicklungs- und Infrastrukturbereitstellungsprojekten, zu übernehmen.
Wie wichtig es ist, sich auf den ROI zu konzentrieren
In den letzten Jahren ist das Interesse an der Bedrohungsmodellierung als wichtigem Softwareentwicklungsprozess stetig gestiegen. Dieses Interesse ist auf die exponentielle Zunahme von Angriffen auf Infrastrukturen und Lösungen zurückzuführen. Initiativen wie der Von NIST empfohlener Mindeststandard für die Codeüberprüfung durch Anbieter oder Entwickler und das Manifest zur Bedrohungsmodellierung haben die Nachfrage so weit erhöht, dass die aktuellen Ansätze an ihre Grenzen gestoßen sind. Beispielsweise hängen die Ergebnisse der Bedrohungsmodellierung stark vom angewandten Prozess und davon ab, wer das Bedrohungsmodell durchführt. Daher besteht die Sorge, dass das Erlebnis eine gleichbleibend höhere Qualität bietet.
Aber was bedeutet Qualität für die Bedrohungsmodellierung? Für uns muss ein Qualitätsbedrohungsmodell die folgenden Merkmale aufweisen:
Es muss umsetzbare Abhilfemaßnahmen identifizieren, also Aktivitäten, die Sie ergreifen können, um die potenziellen Verluste durch Angriffe zu reduzieren. Umsetzbar bedeutet, dass diese Abhilfemaßnahmen klar definiert sein müssen, was bedeutet, dass Sie genügend Informationen erhalten, um sie umzusetzen und die Implementierung dann zu testen. Das bedeutet auch, dass sie bereitgestellt werden müssen, um eine einfache Nutzung durch das Entwicklungsteam zu ermöglichen. Bei DevOps und Agile bedeutet dies, dass es einen einfachen Weg gibt, die Abhilfemaßnahmen in das Backlog zu importieren.
Für jede Schadensbegrenzung muss deren Status angegeben werden. Einige Schutzmaßnahmen sind neu, während andere bereits vorhanden sind. Das Bedrohungsmodell muss erkennen, was bereits vorhanden ist, und sich auf das aktuelle Risiko konzentrieren, um Möglichkeiten zur Verbesserung der Situation zu ermitteln.
Es muss klar dargelegt werden, warum jede Schadensbegrenzung erforderlich ist, indem es mit den jeweiligen Bedrohungen verknüpft wird.
Darüber hinaus haben Schutzmaßnahmen für jede Bedrohung eine relative Stärke. Beispielsweise kann die TLS-Verschlüsselung das Risiko, dass Daten während der Übertragung offengelegt werden, erheblich mindern und gleichzeitig das Risiko, dass der Server gefälscht wird, nahezu vollständig mindern.
Die Bedrohungen müssen glaubwürdig, klar definiert und lösungsspezifisch sein.
Den Bedrohungen muss ein Schweregrad zugeordnet sein, der sowohl ihre Wahrscheinlichkeit als auch die Auswirkungen berücksichtigen sollte. Der Schweregrad muss angemessen und idealerweise unvoreingenommen sein.
Es sollte möglich sein, einen umfassenden Überblick über die Risiken und deren Bewältigung zu erhalten. Diese Sichtweise würde dazu beitragen, sinnvolle Gespräche mit dem Sicherheitsteam und den Entscheidungsträgern im Unternehmen zu führen, und sie würde es uns ermöglichen, unnötige Komplexitäten zu verbergen.
Diese Liste zeigt bereits ein wichtiges Konzept: Die Bedrohungsmodellierung kann für viele am Softwarelebenszyklus beteiligte Rollen einen Mehrwert bieten, aber jede Rolle hat unterschiedliche Bedürfnisse und Anforderungen. Entwickler müssen beispielsweise klare Informationen darüber erhalten, was sie implementieren müssen, und wie sie überprüfen können, ob sich das, was sie implementiert haben, wie erwartet verhält. Andererseits kümmert sich das Sicherheitsteam in der Regel um die Gesamtsicherheit des Ökosystems aus Infrastruktur und Anwendungen, die der Organisation gehören. Daher müssen sie Informationen erhalten, anhand derer sie entscheiden können, ob das betroffene System sicher genug ist und seine Compliance-Anforderungen erfüllt. Schließlich müssen Produktbesitzer und Entscheidungsträger im Unternehmen verstehen, was notwendig ist, um das Risiko für das Unternehmen akzeptabel zu machen.
Solche unterschiedlichen Anforderungen erfordern die Bereitstellung unterschiedlicher Ansichten des Bedrohungsmodells, die sich jeweils auf ein bestimmtes Nutzungsszenario konzentrieren.
Ein typisches Problem bei der Bedrohungsmodellierung besteht darin, dass es für die wenigen verfügbaren Experten umso schwieriger wird, den Bedarf zu decken und gleichzeitig die von dieser Erfahrung erwartete hohe Qualität zu bieten, je erfolgreicher sie ist. Dadurch kann es in manchen Fällen zu einer Beeinträchtigung der Qualität kommen. Alles ist gut, bis die Bedrohungsmodellierung im Vergleich zur Investition keinen signifikanten Mehrwert mehr bietet. Nicht wenige Organisationen sind von diesem Problem betroffen. Es gab bereits einige Berichte darüber, dass Entscheidungsträger in Unternehmen begonnen haben, die Bedrohungsmodellierung in Frage zu stellen, weil sie angesichts der Kosten keinen nennenswerten Mehrwert bieten würde.
Unter „Wert“ verstehen wir den Geschäftswert, der die Fähigkeit darstellt, die Informationen bereitzustellen, die erforderlich sind, um die Risiken zu verstehen, die das System in seinem Umfang darstellt, und einen sinnvollen Entscheidungsprozess zur Auswahl der geeigneten zu implementierenden Abhilfemaßnahmen voranzutreiben. Darüber hinaus hängt der Wert auch davon ab, den Entwicklern und Testern die richtigen Informationen bereitzustellen. Schließlich liegt der Wert in der Kommunikation des Restrisikos mit allen Beteiligten. Wir können den Wert beispielsweise messen, indem wir die Auswirkungen des Bedrohungsmodellierungsprozesses messen. Angenommen, wir messen das Gesamtrisiko für die Lösung, indem wir dem für jede Bedrohung identifizierten Schweregrad eine Zahl zuweisen. In diesem Fall gehen wir davon aus, dass das Gesamtrisiko pro Auswirkung des Bedrohungsmodells im Laufe der Zeit abnimmt. Wenn das Gesamtrisiko konstant bleibt oder zunimmt, liegt möglicherweise ein Problem vor. Je steiler der Rückgang, desto größer ist die Auswirkung des Bedrohungsmodells. Natürlich würde das Bedrohungsmodell die implementierten Schutzmaßnahmen nicht kontrollieren. Es liegt in der Verantwortung des Produktbesitzers zu entscheiden, was implementiert werden muss. Der Vorteil der Verknüpfung der Wirksamkeit des Bedrohungsmodells mit der tatsächlichen Umsetzung der Schutzmaßnahmen besteht jedoch darin, dass die Auswirkungen auf die tatsächliche Sicherheit der Lösung erhöht werden und das Risiko verringert wird, dass das Bedrohungsmodell eine theoretische Übung bleibt.
Stattdessen hängen die Kosten mit den Aktivitäten zusammen, die zur Erstellung des Bedrohungsmodells selbst erforderlich sind, d. h. der Zeit, die alle Beteiligten benötigen, um das Bedrohungsmodell zu erstellen und zu diskutieren.
Dies wirft die Frage auf: Können wir einen Bedrohungsmodellierungsprozess definieren, der auf die Maximierung des Geschäftswerts und die Minimierung der Kosten ausgerichtet ist?
Die Bedeutung von DevOps
Wir haben bereits hervorgehoben, wie wichtig es ist, sicherzustellen, dass die Bedrohungsmodellierung eine wertvolle Praxis ist, die in den DevOps-Prozess integriert ist. Das bedeutet, dass der Prozess allen Teammitgliedern zur Verfügung stehen muss, typischerweise durch Vereinfachung und Automatisierung. Vor allem bedeutet die Konzentration auf die Bedrohungsmodellierung für DevOps, dass wir sicherstellen müssen, dass die Erfahrung tief in die bestehenden DevOps-Prozesse integriert ist.
Die Bedrohungsmodellierung sollte nicht noch zu einer weiteren Belastung werden, sondernes sollte eine Ressource sein, um die Sicherheitsanforderungen zu vereinfachen, das Design sicherer Lösungen, die Einbeziehung von Aktivitäten im Aufgaben- und Bug-Tracking-Tool der Wahl und die Bewertung des Restrisikos angesichts des aktuellen und zukünftigen Zustands der Lösung.
Abstimmung mit den DevOps
Wir können verschiedene Techniken einsetzen, um die Bedrohungsmodellierung an die aktuelle DevOps-Praxis auszurichten.
Bedrohungen und Schutzmaßnahmen
Erstens müssen wir den Bedrohungsmodellierungsprozess auf das konzentrieren, was getan werden muss. Bedrohungen, also die Angriffsmuster und wie sie auftreten können, sind notwendig, um zu erklären, warum das Team eine Sicherheitskontrolle implementieren muss. Sie sind auch ein Faktor bei der Entscheidung, wann Schutzmaßnahmen umgesetzt werden sollten. Dennoch besteht das eigentliche Ziel darin, festzustellen, was getan werden muss: die Schutzmaßnahmen. Daher muss der Ansatz zu einer schnellen Identifizierung erforderlicher Schutzmaßnahmen führen und den Entscheidungsprozess beeinflussen, damit leichter bestimmt werden kann, was wann zu tun ist. Das wichtigste Ergebnis dieses Entscheidungsprozesses besteht darin, die ausgewählten Schutzmaßnahmen im Backlog zu haben, um sie zu einem Teil des Standardprozesses zu machen. Idealerweise sollte das Tool zur Bedrohungsmodellierung und das Tool zur Aufgaben- und Fehlerverfolgung synchronisiert werden, um die Aktualisierungen des Risikominderungsstatus im Bedrohungsmodell widerzuspiegeln. Dies würde eine dynamische und automatische Überarbeitung des Restrisikos ermöglichen, was für die Unterstützung fundierter Entscheidungen im Rahmen der üblichen Choreografien der übernommenen agilen Methodik, wie dem Sprint-Planungstreffen, von entscheidender Bedeutung ist.
Was können Sie tun?
Als Experte für die Bedrohungsmodellierung sollten Sie sicherstellen, dass Sie einen Prozess zur Bedrohungsmodellierung implementieren, der Aktionen eindeutig identifizieren und in Ihre Aufgaben- und Fehlerverfolgung einbeziehen kann. Eine Möglichkeit könnte darin bestehen, eines der vielen Tools zur Bedrohungsmodellierung einzusetzen, mit denen sich dieser Prozess automatisieren lässt.
Als Entwickler sollten Sie sich auf die Sicherheitskontrollen konzentrieren, die als notwendig identifiziert werden. Der Prozess sollte so gestaltet sein, dass er Ihnen diese auf die gleiche Weise zur Verfügung stellt, wie Sie es von jeder anderen Aktivität erwarten.
Features, Benutzerstories und Aufgaben
Wir haben bereits festgestellt, dass die Schutzmaßnahmen das wichtigste Artefakt darstellen, das das Bedrohungsmodell in Bezug auf die DevOps-Integration hervorbringt. Daher ist es wichtig, den Typ der Objekte, die aus diesen Entschärfungen auf dem Tool zur Aufgaben- und Fehlerverfolgung erstellt wurden, eindeutig zu definieren. Einige Schutzmaßnahmen können länger als einen Sprint dauern. Daher ist es möglicherweise am besten, sie als Features zu erstellen. Aber viele sind einfacher und könnten in einem einzigen Sprint implementiert werden; Somit wäre es möglich, sie als Benutzerstories oder Aufgaben darzustellen. Zwar ist die Generierung verschiedener Arbeitselementtypen möglich, dies kann jedoch zu einem komplizierten Prozess führen, der zu Fehlern und Verwirrung führen kann. Aus diesem Grund erscheint es praktischer, bei einem einzigen Arbeitselementtyp zu bleiben. Angesichts der Tatsache, dass Schutzmaßnahmen als untergeordnete Elemente von Benutzerstories betrachtet werden können, können Sie erwägen, sie als Aufgaben darzustellen, was bedeutet, dass die Anforderung, den besagten Arbeitselementtyp in einem einzigen Sprint ausführen zu müssen, gelockert wird.
Was können Sie tun?
Stellen Sie sicher, dass die durch das Bedrohungsmodell identifizierten Schutzmaßnahmen im Backlog dargestellt werden. Identifizieren Sie eine Möglichkeit, sie klar darzustellen.
User Storys
Die Entschärfungen sind nicht die einzigen Artefakte eines Bedrohungsmodells, das mit dem, was Sie in Ihrem Tool zur Aufgaben- und Fehlerverfolgung haben, abgestimmt werden kann und sollte. Beispielsweise möchten Sie möglicherweise auch Bedrohungen darstellen. Dieses Ziel könnte erreicht werden, indem die Benutzerstories durch das Hinzufügen einer OHNE-Klausel zum üblichen „Als [wer bin ich] möchte ich [was ich will], damit ich [etwas tun kann]“ erweitert werden. Zum Beispiel: „Als Benutzer möchte ich mit meiner Kreditkarte bezahlen, damit ich einige Waren kaufen kann, OHNE dass meine Kreditkartendaten gestohlen werden.“ Die OHNE-Klausel kann einer oder mehreren Bedrohungen zugeordnet werden und manchmal auch Sicherheitsanforderungen zum Ausdruck bringen. Indem wir sicherstellen, dass diese Ausrichtung zwischen Bedrohungen und OHNE-Klauseln im Bedrohungsmodell explizit gemacht wird, können wir sicherstellen, dass mögliche Risiken vom Team berücksichtigt und berücksichtigt werden, da sie als Teil der Benutzerstories enthalten sind. Sie können diese Beziehung auch verwenden, um jede als Teil der Benutzerstories identifizierte Sicherheitsanforderung mindestens einer Bedrohung zuzuordnen.
Gut zu wissen
Die OHNE-Klausel ist keine Originalidee des Teams, das diese Seite erstellt hat. Wir sind uns nicht sicher, wer es zuerst eingeführt hat, aber wir sind jedem dankbar, der auf diese Idee gekommen ist.
Abbildung 1: Angleichungsanforderungen
Das vorherige Bild zeigt beispielsweise die folgenden Situationen:
Bedrohung A ist über die Klausel OHNE 1 mit Benutzerstory 1 verknüpft.
Bedrohung B ist über die Klausel OHNE 2 mit Benutzerstory 2 verknüpft.
Bedrohung B ist auch mit Benutzerstory 3 verknüpft. Benutzerstory 3 ist jedoch keiner OHNE-Klausel zugewiesen. Warum? Es handelt sich um eine potenzielle Anomalie, die Sie untersuchen sollten.
Bedrohung B ist auch mit Benutzerstory 1 verknüpft. Es ist noch nicht klar, ob wir zulassen sollen, dass Benutzerstories mit mehr als einer Bedrohung verknüpft werden.
Bedrohung C ist mit User Story 4 verknüpft, die mit OHNE 3 und 4 verknüpft ist. Es ist noch nicht klar, ob wir mehr als eine OHNE-Klausel zulassen sollen.
Bedrohung D ist mit keiner Benutzerstory verknüpft. Fehlt uns eine Benutzerstory oder eine OHNE-Klausel?
Benutzerstory 5 ist mit einer OHNE-Klausel verknüpft, es ist jedoch keine Bedrohung damit verbunden. Übersehen wir eine Bedrohung oder einfach nur eine Verbindung zwischen einer Benutzerstory und einer Bedrohung?
Wir identifizieren Sicherheitsanforderungen selten als Teil des Bedrohungsmodells. Daher bietet die OHNE-Klausel die Möglichkeit, die Erfahrung weiter zu integrieren, indem die Bedrohungsmodelle um Sicherheitsanforderungen erweitert und mit den zugehörigen Benutzerstories verknüpft werden. Dieser Ansatz würde eine wichtige Rolle bei der Weiterentwicklung der Bedrohungsmodellierung von einer über einen längeren Zeitraum wiederholten Bewertung zum Sicherheitsdesign-Tool für DevOps spielen.
Was können Sie tun?
Beginnen Sie mit der Verwendung der OHNE-Klausel in Ihren Benutzerstories.
Ordnen Sie die von Ihnen identifizierten Bedrohungen Benutzerstories mit OHNE-Klauseln zu und umgekehrt.
Ein integriertes Erlebnis
Sie können die gleiche Idee auf andere Szenarien anwenden. Beispielsweise könnte das Bedrohungsmodell die Sicherheitsanforderungen mit Artefakten innerhalb des Bedrohungsmodells selbst – wie Bedrohungen und Entschärfungen – und solche im Tool "Track & Bug Tracking" verknüpfen. Beispielsweise sollte die Anforderung zur Implementierung der Überwachung zur Identifizierung von laufenden Angriffen allen maßnahmen im Zusammenhang mit der Überwachung und dann den entsprechenden Artefakten im Tool "Task & Bug Tracking" zugeordnet werden. Dadurch wäre es leicht, Situationen zu identifizieren, in denen eine Sicherheitsanforderung nicht erfüllt ist: Tatsächlich wäre sie mit nichts verknüpft.
Sie können dieselben Verknüpfungen zwischen den Artefakten im Tool "Aufgaben- und Fehlerverfolgung" und den Bedrohungen und Gegenmaßnahmen verwenden, die durch das Bedrohungsmodell identifiziert werden, um die Priorisierung der Sicherheitsaktivitäten zu erleichtern. Sicherheit wird normalerweise zuletzt implementiert, manchmal um reaktiv Schwachstellen zu beheben, die durch ein Tool oder einen Penetrationstest identifiziert wurden. Im Gegenteil wäre es am effektivsten, die Schutzmaßnahmen zusammen mit den zugehörigen User Stories oder Funktionen zu implementieren. Warum sollten Sie mit der Implementierung der Kontrollen zum Schutz der Kreditkartendaten warten, wenn Sie sie zusammen mit den zugehörigen Zahlungsfunktionen implementieren sollten? Das Bedrohungsmodell sollte diese Beziehungen hervorheben und eine einfache Möglichkeit bieten, festzustellen, wann die Implementierung einer Funktion während eines Sprints die Implementierung einer zugehörigen Sicherheitsfunktion erfordert. Diese Informationen könnten beispielsweise während des Sprint-Planungsmeetings genutzt werden, um eine sinnvolle Diskussion zu führen und eine fundierte Priorisierung voranzutreiben. Der Mechanismus ist einfach. Nehmen wir an, dass der Produktbesitzer eines Projekts, an dem wir arbeiten, beschließt, eine Benutzerstory für den nächsten Sprint zu planen. Die besagte Benutzersory enthält eine OHNE-Klausel, die mit einer Bedrohung verknüpft ist. Das Bedrohungsmodell identifiziert mehrere Schutzmaßnahmen für dieselbe Bedrohung. Daraus können wir sofort ableiten, dass wir einer oder mehreren der identifizierten Schutzmaßnahmen Priorität einräumen sollten.
Abbildung 2: Priorisierung der Sicherheit
Im Bild oben sehen wir beispielsweise, dass Benutzerstory 1 mit Bedrohung 1 verknüpft ist, die wiederum mit den Schutzmaßnahmen A und B verknüpft ist. Daher sollten wir auch die Implementierung einer oder beider dieser Schutzmaßnahmen in Betracht ziehen.
Was können Sie tun?
Verknüpfen Sie Benutzerstories mit OHNE-Klauseln mit den Arbeitselementen, die den ausgewählten Schutzmaßnahmen entsprechen, und verwenden Sie dabei das Bedrohungsmodell als Referenz. Achten Sie bei der Planung des nächsten Sprints darauf, die verknüpften Sicherheitsaktivitäten zu priorisieren, wenn Sie eine dieser Benutzerstories mit OHNE-Klauseln implementieren.
Integration zum Aufzeigen von Fehlstellungen
Sobald wir uns überlegen, wie wir die Artefakte verknüpfen könnten, die das Bedrohungsmodell mit denen im Tool "Task & Bug Tracking" erstellen, wird es einfacher, Möglichkeiten zur Verbesserung der Qualität beider Zu erkennen. Der Schlüssel besteht darin, ihre Beziehungen zu nutzen, um Diskrepanzen hervorzuheben und die in der einen vorhandenen Informationen zu nutzen, um die in der anderen vorhandenen Informationen zu ergänzen, zu integrieren und zu interpretieren. Wie oben erläutert, können Sie dies tun, ohne die Arbeitsweise des Teams erheblich zu beeinträchtigen. Denn der Ansatz greift auf vorhandene Informationen zurück und stellt Beziehungen zwischen den verschiedenen Objekten in den verschiedenen Welten her. Daher würde das Bedrohungsmodell zur Quelle der Wahrheit für die Sicherheit der Lösung werden. Gleichzeitig wird das Backlog kontinuierlich mit dem Stand der Lösung abgeglichen.
Was können Sie tun?
Überprüfen Sie regelmäßig, dass keine nicht zugeordneten Bedrohungen oder Benutzerstories mit OHNE-Klauseln vorhanden sind.
Bedrohungsmodellierung und die Operationen
Alle diese Ideen konzentrieren sich hauptsächlich auf die Entwicklungsseite von DevOps. Können wir auch etwas tun, um Operationen zu verbessern? Wir denken, ja. Beispielsweise wäre es möglich, die Bedrohungsmodellierung als Tool zur Erleichterung der Ursachenanalyse zu verwenden, da sie einen umfassenden Überblick über das System aus Sicherheitsperspektive bietet und somit ein besseres Verständnis der Auswirkungen einiger Angriffe ermöglichen kann. Um dies zu erreichen, wäre es notwendig, das Bedrohungsmodell mit den vorhandenen Feeds der ausgewählten Überwachungstools zu integrieren. Dieser Ansatz kann eine Ergänzung zum gewählten SIEM darstellen.
Eine weitere Idee für die Integration der Bedrohungsmodellierung in Operations besteht darin, Ersteres zu nutzen, um das Design voranzutreiben, wie Letzteres passieren könnte. Ein Beispiel hierfür ist die Gestaltung von Events zur Lösung. Die Bedrohungsmodellierung identifiziert mögliche Angriffe, und wir können dieses Wissen nutzen, um Ereignisse zu identifizieren, die die Lösung im Umfang auslösen kann, wenn diese Angriffe fehlschlagen. Wenn Sie eine strikte Eingabevalidierung durchführen, benötigt ein böswilliger Angreifer einige Versuche, bevor er erfolgreich ist. Die Versuche scheitern zunächst, einer von ihnen gelingt schließlich. Indem Sie für jeden Fehler Ereignisse auslösen und bei Erreichen eines Schwellenwerts Warnungen auslösen, können Sie möglicherweise Angriffe erkennen und Maßnahmen zu deren Behebung ergreifen. Solche Situationen werden selten erkannt, wenn Sie sich auf die Überwachung der Infrastruktur beschränken. Daher ist es notwendig, benutzerdefinierte Ereignisse einzubeziehen, die das Team entwerfen und implementieren muss, bevor das SOC sie nutzen kann.
Darüber hinaus weiß dieses möglicherweise nicht viel über die Lösung. Daher kann das SOC möglicherweise nicht bestimmen, wie es reagieren soll, wenn die Eingabevalidierung fehlschlägt. Wenn es zu einer Datenschutzverletzung kommt, ist es leider unerlässlich, schnell zu reagieren, um den direkten Schaden sowie die Wahrscheinlichkeit und Höhe eventueller Bußgelder zu verringern.
Daher müssen wir im Voraus planen, was überwacht werden muss, unter welchen Bedingungen möglicherweise ein Problem auftritt und was zu tun ist, wenn dies geschieht. Der beste Weg, diese Ereignisse zu identifizieren, besteht darin, sich auf ein Bedrohungsmodell zu verlassen. Daher wäre es hilfreich, es zur Generierung standardisierter Artefakte zu nutzen, um die Implementierung der erforderlichen Konfigurationen zu steuern und zu beschleunigen, um die Überwachung und Prüfung voranzutreiben und die Reaktion auf Vorfälle zu erleichtern.
Was können Sie tun?
Nutzen Sie das Bedrohungsmodell aktiv, um Ereignisse zu identifizieren, die Sie für jede Bedrohung auslösen können. Diese Ereignisse können von der Infrastruktur bereitgestellt werden oder von etwas, das die Anwendung auslösen muss. Nehmen Sie Arbeitselemente in Ihren Backlog auf, um sicherzustellen, dass diese Ereignisse implementiert werden.
Arbeiten Sie aktiv mit Ihren Betriebs- und Sicherheitsteams, einschließlich des SOC-Teams, zusammen, um sicherzustellen, dass die Ereignisse genutzt werden, um Warnungen auszulösen und Sicherheitsvorfälle zu identifizieren.
Die Auswirkungen auf den ROI
Sie fragen sich vielleicht, warum sich diese Techniken positiv auf den ROI der Bedrohungsmodellierung auswirken können. Aus unserer Sicht sind sie entscheidend für die Wertsteigerung der Bedrohungsmodellierung für die DevOps-Teams. Das Problem, das wir wiederholt gesehen haben, besteht darin, dass diese Teams Sicherheit als einen Kostenfaktor wahrnehmen, der einen begrenzten Wert bietet und viel unvorhergesehene Arbeit erfordert. Manchmal ist unklar, warum sie so viel Zeit in die Verbesserung der Sicherheit investieren sollten. Dadurch wird Sicherheit zum Problem statt zur Chance. Die Bedrohungsmodellierung hat das Potenzial, diese Probleme zu überwinden, da sie die Gründe für die Implementierung von Sicherheit liefert. Darüber hinaus kann damit frühzeitig im Entwicklungsprozess begonnen werden und Konstruktionsfehler vermieden werden, die teuer werden können, wenn sie nicht bald erkannt werden. The techniques above aim to better integrate threat modeling with DevOps. Dadurch wird sichergestellt, dass Geschäftsentscheider und Entwickler die Bedrohungsmodellierung als natürliche Ergänzung zum Entwicklungs- und Betriebsprozess wahrnehmen. Daher steigt der Wert, den die Einführung der Bedrohungsmodellierung mit sich bringt, und die Kosten sinken aufgrund der Integration mit den verschiedenen bereits verwendeten Tools.
Vereinfachung der Arbeit für Bedrohungsmodellierer
Ein weiterer wichtiger Aspekt, der zur Verbesserung des ROI der Bedrohungsmodellierung erforderlich ist, hängt mit der Reduzierung der Kosten und der Erhöhung der Anzahl der Personen zusammen, die in der Lage sind, sie bereitzustellen, während gleichzeitig homogenere Qualitätsniveaus aufrechterhalten werden.
Es gibt viele Versuche, dem Mangel an kompetenten Fachkräften entgegenzuwirken. Einige davon basieren auf der aktiven Beteiligung des gesamten DevOps-Teams an der Bedrohungsmodellierung. Die Idee besteht darin, eine Leiterin der Initiative zu identifizieren, also jemanden mit mittlerem Wissen über den Prozess, der aber nicht unbedingt ein Experte ist, und sie die Diskussion unter den anderen Teammitgliedern leiten zu lassen. Dieser Ansatz wird von den Unterzeichnern des Manifest zur Bedrohungsmodellierung aktiv unterstützt.
Wir stimmen darin überein, dass dieser Ansatz ein gutes Preis-Leistungs-Verhältnis ermöglicht und eine Verbesserung gegenüber der aktuellen Situation darstellt. Darüber hinaus bietet es gute Einblicke und ermöglicht es dem Team, seine Sicherheitskultur weiterzuentwickeln. Dennoch ist es nicht ohne Nachteile, da es nur wenige Themen abdeckt und vieles außen vor lässt. Dadurch entsteht ein Konsistenzproblem, da es zu einfach wäre, in den Kaninchenbau zu verfallen und wertvolle Zeit mit zweitrangigen Themen zu verschwenden und dabei wichtige zu übersehen. Die Erfahrung der Führungskraft würde eine wichtige Rolle dabei spielen, das Eintreten solcher Situationen zu verhindern. Darüber hinaus erfordert dieser Ansatz von allen Teammitgliedern viel Zeit, um jedes Problem zu besprechen.
Aus diesem Grund kann es eine erhebliche Investition darstellen, nur ein paar Stunden pro Sprint für diese Übung aufzuwenden. Jeder weiß, dass die meisten Teams dazu neigen, Zeit mit großen Meetings zu verschwenden, an denen alle beteiligt sind, und diese Sitzungen zur Bedrohungsmodellierung bilden da keine Ausnahme. Dennoch eignet sich dieser Ansatz hervorragend für kleine Produkte, bei denen das Team aus einer Handvoll erfahrener Mitglieder besteht.
Ein anderer Ansatz
Angesichts der Einschränkungen des vorherigen Ansatzes ziehen wir es vor, die Anzahl der Treffen, ihre Länge und die Anzahl der Teilnehmer zu begrenzen. Daher wäre die Verantwortung des Bedrohungsmodellierers wichtiger: nicht nur die Befragungen zu leiten, sondern auch das Bedrohungsmodell selbst zu erstellen und zu pflegen. Dieser Ansatz erfordert umfangreichere Kompetenzen und Fachkenntnisse. Bedrohungsmodellierer können durch Security Champions oder Mitglieder des internen Sicherheitsteams vertreten sein. Die meisten Organisationen würden sich für Ersteres entscheiden, da das Sicherheitsteam in der Regel ausgebucht ist.
Security Champions sind Mitglieder der DevOps-Teams mit besonderem Interesse an Sicherheit. Sie sind keineswegs Experten, verfügen aber über Grundkenntnisse und die Bereitschaft, die Sicherheitslage ihres Teams zu verbessern. Die Idee besteht darin, eine privilegierte Verbindung zwischen den Security Champions und dem internen Sicherheitsteam herzustellen, sodass die Ersten in die Lage versetzt werden, ihre Teams dabei zu unterstützen, das Richtige zu tun, während das Sicherheitsteam seine Arbeitsbelastung reduzieren kann. Bei der Bedrohungsmodellierung würden die Security Champions als Bedrohungsmodellierer fungieren, und das interne Sicherheitsteam hätte die Verantwortung, sie anzuleiten und ihre Arbeit zu überprüfen.
Was können Sie tun?
Prüfen Sie die Möglichkeit, ein Security Champions-Programm einzuführen und es zu nutzen, um Ihren sicheren Softwareentwicklungslebenszyklus weiter zu stärken.
Die Rolle von Wissensdatenbanken
Ein wesentliches Problem bei der Bedrohungsmodellierung besteht darin, sicherzustellen, dass die Qualität der Erfahrung und der Wert für das DevOps-Team hoch sind, unabhängig davon, wer das Bedrohungsmodell durchführt. Mit Security Champions wird dieses Problem noch dringlicher. Eine Idee, dieses Problem anzugehen, besteht darin, Wissensdatenbanken bereitzustellen, um die Erstellung des Bedrohungsmodells voranzutreiben. Wissensdatenbanken für die Bedrohungsmodellierung sind Informationspakete über einen bestimmten Kontext: Sie enthalten eine Definition der mit diesem Kontext verbundenen Entitäten, die möglichen Angriffsmuster auf diese Entitäten und die standardmäßigen Abhilfemaßnahmen, die angewendet werden können. Wissensdatenbanken ermöglichen es der Organisation, bessere und konsistentere Ergebnisse zu erzielen, da sie Referenzmaterial darstellen, das den Bedrohungsmodellierern eine präskriptive Anleitung gibt. Wissensdatenbanken sollten über Regeln verfügen, die es uns ermöglichen, Bedrohungen und Schadensbegrenzungen automatisch auf ein System anzuwenden. Diese Automatisierung würde es uns ermöglichen, die Tatsache zu überwinden, dass einige Bedrohungsmodellierer möglicherweise nicht über die erforderliche Erfahrung verfügen, um festzustellen, ob eine Bedrohung angewendet werden sollte oder ob eine Abschwächung wirksam ist.
Wissensdatenbanken sind keine neue Idee: Viele aktuelle Tools zur Bedrohungsmodellierung unterstützen sie bereits in irgendeiner Form. Viele aktuelle Implementierungen weisen jedoch erhebliche Nachteile auf. Beispielsweise sollten Sie in der Lage sein, Wissensdatenbanken einfach zu pflegen. Ihre Wartbarkeit ist ein noch ungelöstes Problem. Beispielsweise ist es nicht einfach, die besten Informationsquellen für deren Erstellung zu ermitteln. Darüber hinaus erfolgt die Wartung in der Regel manuell. Die Erstellung und Pflege der Wissensdatenbanken sollte in der Verantwortung des internen Sicherheitsteams der Organisation liegen. Wir hoffen, dass Unternehmen damit beginnen, Wissensdatenbanken für die gängigsten Bedrohungsmodellierungstools bereitzustellen, um ihren Kunden in Zukunft einen Teil der Belastung zu nehmen. Diese Wissensdatenbanken sollten flexibel sein, um ihre Einführung selbst durch die ausgereiftesten Organisationen zu unterstützen und zu erleichtern, die die besagten Wissensdatenbanken an ihre Praktiken, Richtlinien und Vorschriften anpassen müssen.
Was können Sie tun?
Erwägen Sie die Möglichkeit, einen Teil der Arbeit des zentralen Sicherheitsteams für die Entwicklung von Wissensdatenbanken aufzuwenden, die von den verschiedenen Entwicklungsteams zur Beschleunigung der Bedrohungsmodellierung genutzt werden können.
Wissensdatenbanken nutzen
Ein weiteres Problem bei Wissensdatenbanken besteht darin, dass sie manchmal zu komplex sind, um sie zu nutzen. Viele von ihnen versuchen, umfassend zu sein, indem sie wesentliche und weniger kritische Themen einbeziehen. Leider werden nicht alle davon von allen Systemen benötigt. Wenn das von Ihnen analysierte System klein ist und keine sensiblen Daten verarbeitet, sollten Sie einen einfacheren Ansatz wählen. Im Gegenteil: Wenn das System komplex ist und personenbezogene Daten sowie Daten mit hohem Geschäftswert verarbeitet, sollten Sie tiefer in die Materie einsteigen. Daher sollte es möglich sein, je nach Kontext unterschiedliche Versionen des Wissens anzuwenden oder einige Angriffsmuster und damit verbundene Abhilfemaßnahmen als „TOP“ zu kennzeichnen. Dadurch könnten die Bedrohungsmodellierer entscheiden, ob sie ein umfassendes Erlebnis wünschen oder es einfach angehen und den Arbeitsaufwand minimieren möchten.
Apropos Effizienz: Es muss unbedingt sichergestellt werden, dass die Aktivitäten so weit wie möglich rationalisiert und automatisiert werden, um den Arbeitsaufwand zu reduzieren. Wir sind der Meinung, dass der optimale Zeitpunkt für die Erstellung eines Bedrohungsmodells für eine durchschnittlich große Lösung ein Arbeitstag für den Bedrohungsmodellierer sein sollte. Solche Ergebnisse sind nur möglich, wenn das gewählte Tool Beschleuniger bietet, die eine Verkürzung der benötigten Zeit ermöglichen. Wenn das Tool beispielsweise 20 verschiedene Arten von Abhilfemaßnahmen an 100 verschiedenen Orten anwendet und Sie aufgefordert werden, für jede davon ihren Status anzugeben, wären Sie fünfmal effizienter, wenn Sie sich auf die erste statt auf die letztere konzentrieren würden. Das gewählte Tool sollte diese Fähigkeit bieten und gleichzeitig die Möglichkeit bieten, bei Bedarf eine gründlichere Arbeit zu leisten.
Was können Sie tun?
Wenn die Wissensdatenbanken, die Sie heute verwenden, das Konzept der „TOP“-Bedrohungen und -Maßnahmen nicht unterstützen, sollten Sie die Möglichkeit in Betracht ziehen, das zu entfernen, was selten notwendig oder nützlich ist, damit Sie sich nur auf das konzentrieren können, was wirklich wichtig ist.
Manchmal besteht das Problem darin, dass die übernommenen Wissensdatenbanken generisch sein und mehrere Szenarien abdecken. Sie können die Situation verbessern, indem Sie sie spezialisieren.
Die richtigen Fragen stellen
Während unserer Analyse haben wir die Möglichkeit in Betracht gezogen, ein Tool zur Unterstützung eines Fragen-Frameworks zu verwenden, um die ersten Phasen der Analyse voranzutreiben. Wir haben festgestellt, dass die meisten unerfahrenen Bedrohungsmodellierer nicht die richtigen Fragen stellen können, um die für ihre Analyse erforderlichen Informationen zu erhalten. Einige unserer Experten haben gezeigt, dass es möglich ist, einige entscheidende Fragen anhand eines Systemdiagramms im Umfang zu bestimmen. Mit einigen Generierungsregeln können diese Fragen sogar automatisch angewendet werden. Das Problem besteht darin, dass dieser Ansatz möglicherweise nicht den Wert bietet, den er verspricht. Das liegt daran, dass Sie die Beweggründe hinter jeder Frage verstehen müssen. Andernfalls könnten Sie die Antwort nicht bewerten und feststellen, ob sie zufriedenstellend ist. Dennoch kann die automatische Generierung von Fragen für weniger erfahrene Bedrohungsmodellierer einen erheblichen Mehrwert bieten und ihr Verständnis der betreffenden Systeme verbessern.
Was können Sie tun?
Gehen Sie beim Stellen von Fragen strukturiert vor. Unser Team hat beispielsweise gute Ergebnisse erzielt, indem es Microsoft STRIDE als Referenz übernommen hat. Sie können dies tun, indem Sie für jede Komponente der Lösung Fragen stellen wie:
Spoofing: Wie authentifiziert sich die Komponente gegenüber den von ihr verwendeten Diensten und Ressourcen?
Manipulation: Validiert die Komponente die empfangenen Nachrichten? Ist die Validierung locker oder streng?
Ablehnung: Protokolliert die Komponente die Interaktionen in einem Audit-Protokoll?
>Informationsoffenlegung: Ist der ein- und ausgehende Datenverkehr der Komponente verschlüsselt? Welche Protokolle und Algorithmen sind erlaubt?
Denial of Service: Ist die Komponente in Hochverfügbarkeit konfiguriert? Ist sie vor DDoS-Angriffen geschützt?
Berechtigungserhöhung: Werden Benutzern die geringsten erforderlichen Berechtigungen zugewiesen? Vermischt die Lösung Code für normale Benutzer mit Code für Benutzer mit hohen Berechtigungen?
Techniken wie diese können erlernt und mit Erfahrung verbessert werden. Daher ist es wichtig, einen kontinuierlichen Lernansatz zu implementieren, der darauf abzielt, Erkenntnisse zu sammeln und sie innerhalb der Organisation zu verbreiten.
Die Auswirkungen auf den ROI
Unterm Strich lassen sich viele Ideen identifizieren, um die Effizienz der Bedrohungsmodellierung und ihre Qualität zu verbessern und letztendlich den ROI zu steigern. Diese Bemühungen sollten jedoch als fortlaufender Prozess betrachtet werden, der auf die kontinuierliche Verbesserung der Praxis ausgerichtet sein sollte.
Zusammenfassung
Die Bedrohungsmodellierung ist eine hervorragende Methode zur Verbesserung der Sicherheit Ihrer Organisation. Wenn es richtig gemacht wird, kann es einen Mehrwert zu sehr vernünftigen Kosten bieten. Wir haben bereits verschiedene Techniken identifiziert, die sich als wesentlich erweisen können, um den Wert der Bedrohungsmodellierung für die Absicherung moderner Lösungen zu verbessern, darunter:
Richten Sie das Bedrohungsmodell an Ihrer DevOps-Praxis aus, indem Sie
Sich auf die Abhilfemaßnahmen konzentrieren
Abhilfemaßnahmen mit Benutzerstories verknüpfen
Diskrepanzen zwischen dem Bedrohungsmodell und dem Rückstand hervorheben
Das Bedrohungsmodell nutzen, um eine umfassendere Überwachung und Prüfung der Sicherheit voranzutreiben
Die Erstellung von Bedrohungsmodellen und erhöhen Sie die Konsistenz der Ergebnisse vereinfachen
Sich auf Security Champions verlassen
Wissensdatenbanken nutzen, um die Identifizierung von Bedrohungen und Gegenmaßnahmen zu automatisieren
Bessere Wissensdatenbanken schaffen
Ein Fragen-Framework bereitstellen, das durch Automatisierung unterstützt wird
Hoffentlich sind einige davon bereits in dem Bedrohungsmodellierungstool Ihrer Wahl zu finden. Weitere werden in Zukunft hinzukommen. Wir wissen, dass die Maximierung des ROI für die Bedrohungsmodellierung eine langfristige Aufgabe ist, die Antworten erfordert, die wir noch nicht haben. Wir wissen auch, dass einige Fragen noch unbekannt sind. Dieses Dokument soll einige Denkanstöße geben und Ihnen hoffentlich dabei helfen, die Art und Weise, wie Sie Bedrohungsmodelle erstellen, zu verbessern. Wir hoffen, dass es ein Leuchtturm für Sie und uns sein kann und dass es uns bei der Ausrichtung unserer Bemühungen in den kommenden Jahren nützlich sein wird.