Diskussion:Security/Bausteine

Zero Trust

Zero Trust

Passwörter, Assets und Zugriffe

Ist das Vertrauen erst mal ruiniert, lebt’s sich nicht mehr ungeniert – so könnte man den ersten Teil dieser Serie, "Zero-Day und Zero Trust", zusammenfassen

• Wir haben uns also aus dem Paradies eines freundlichen Internets vertreiben lassen und wittern nun überall Gefahren
• Aber Gefahren für wen eigentlich?

Was wollen wir schützen und vor wem?

Viele Handreichungen für die Informationssicherheit und insbesondere diverse Standards beginnen mit der Aufforderung, sich der eigenen Werte bewusst zu werden

• Nicht der persönlichen (wobei auch das häufig hilfreich wäre), sondern derjenigen der Organisation, die zu verteidigen ich mich verpflichtet habe
• Ein Wert (englisch "Asset") ist alles, was etwas wert ist
• Aber wem? Das können nur die "Stakeholder" beantworten – diejenigen, die nicht einzubinden Nachteile oder Risiken birgt
• Erst nach diesem "Asset-Management", so wird uns gesagt, wüssten wir, was wir schützen müssen und, wenn ja, wie viel(e)

Bestandsaufnahme

Der Luxus der Bestandsaufnahme

Diese Luxuslogik lässt sich maximal in absoluten Friedenszeiten vertreten

• In der Ära von "Assume Breach" – gehe davon aus, dass du schon gehackt wurdest – ist es Arroganz und Zeitverschwendung, so lange mit dem Excel-Sheet herumzulaufen, bis auch der allerletzte verstaubte Client aus dem Magazin dort eingetragen ist, um erst dann mit den ersten Sicherheitsmaßnahmen zu beginnen
• Im Krieg und in Krisen würde niemand auf die Idee kommen, zunächst eine detaillierte Bestandsaufnahme zu machen, sondern ganz schnell eine Lagefeststellung vornehmen, um daraus dann die Reaktion zu planen

Was ist der schnellste Entschluss, den ich nahezu ohne Beurteilung der Lage treffen kann? (Fast) Keiner rührt sich! Damit möglichst niemand etwas unerlaubt wegnimmt oder sabotiert

• Das Prinzip dahinter nennt sich "Least Privilege" (Prinzip der geringsten Rechte) und ist neben Defense in Depth (mehrere Verteidigungsebenen, folgen in Teil 4) fast das einzige Securityprinzip, das in quasi allen Einsatzbereichen zur Anwendung kommt

Berechtigung per Passwort

Wie stelle ich nun aber sicher, dass nur Berechtigte(s) "passieren" dürfen/darf, wenn ich gar nicht alle meine Pappenheimer, sprich Assets, kenne? Schon vor Jahrtausenden wies man sich durch Parolen oder Losungen als militärischer Bote aus, um nicht als Spion abgefangen zu werden

• Oder heute, um als VIP in den Club gelassen zu werden

Ein Passwort ist also etwas, das ich weiß

• Und eventuell auch noch andere – aber Unberechtigte hoffentlich nicht
• Aus Sicht des zu schützenden Systems zeichnet die Kenntnis des Passworts als zum Kreis der Berechtigten gehörig aus beziehungsweise definiert diesen Kreis erst
• Wir wissen zwar nicht, wer das ist, aber jemand hat dieser Person das geheime Passwort verraten, also wird sie wohl dazugehören, ähnlich wie ein sozialer Code
• Das muss reichen in diesem groben System der Regelung des Zutritts, der Zugriff heißt, wenn es sich um digitale Boten(-gänge) handelt

Nun gibt es eine ganze Wissenschaft und eine noch größere Folklore rund um die Frage, was gute Passwörter sind und was ein guter Umgang mit ihnen

• Dabei steckt alles bereits in der Definition: Etwas, das wirklich (nur) ich weiß, lässt sich nicht verlässlich durch Kürze (admin), Wörterbücher (iloveyou), Hochzählen (hunter2) oder ständige Passwortwechsel (johnny2023) produzieren
• Zufall hilft wahrscheinlich
• Und dieser letzte Satz ist an und für sich so schön, dass man ihn hätte schreiben sollen, selbst wenn er nicht korrekt gewesen wäre
• Ein weiterer Teil der Kunst beschäftigt sich mit der Frage, wie Passwörter vor dem Gestohlenwerden geschützt werden können (salzen, pfeffern, verdauen, hashen …) – dazu an anderer Stelle mehr

Einfach alles schützen

Wenn diese Passierscheine flächendeckend vorliegen, kann ich ein System von Checkpoints einrichten, die diese möglichst engmaschig abfragen, und muss dann im Prinzip gar nicht mehr alle Assets kennen

• Die Kenntnis des Passworts oder eines anderen Geheimnisses hat das Verteidigungsproblem von einem militärisch-physischen (Hast du alle Straßen im Blick? Auch im Dunkeln? Erkennst du eine Spionin?) in ein linguistisches transformiert (Kannst du mir das Wort nennen?)
• Und darin sind Computer unschlagbar

Zwei Faktoren – Authentifizierung und Backup

Die Miniserie für ein schlankes und schlagkräftiges Securityprogramm zeigt, warum zwei Faktoren besser sind als einer, und was das Ganze mit Backups zu tun hat

U2, 2Pac, 2pperware – wir Menschen lieben die Zwei als Konzept, kann sie doch Gegensatz bedeuten wie bei Red Team gegen Blue Team, Komplementarität (Blau und Orange in Goethes Farbmodell) oder Dualität wie bei den sprichwörtlichen zwei Seiten einer Medaille

• Nicht zuletzt leitet sich die Macht der Quantencomputer daraus ab, dass sie die binäre Grenze auflösen
• Und so braucht natürlich auch die Security ihre B-Seite, ihren Vize, ihr "+ 1"
• Verkörpert wird diese am offensichtlichsten (ein unnötigerweise binäres, angeblich nicht steigerbares Adjektiv …) im Fachbegriff 2FA – Zwei-Faktor-Authentifizierung, zu Deutsch: Bitte noch einen Beweis, dass du es bist, sonst glaube ich dir nicht!

MFA, mit freundlichen Grüßen

Eigentlich lautet das Konzept MFA, also Mehr-Faktor-Authentifizierung

• Heißt: Wenn ich meine Identität (siehe "Teil 2: Ein Passwort" dieser Artikelserie) beweisen will, muss ich Nachweise aus mehreren verschiedenen Klassen von Beweismöglichkeiten anführen, etwa etwas, das ich weiß (zum Beispiel ein Passwort), etwas, das ich habe (zum Beispiel ein Hardwaretoken), und/oder etwas, das ich "bin" (zum Beispiel mein Fingerabdruck)
• Faktor heißt: Wenn ich einen der Nachweise nicht erfolgreich bringe, ist das ganze Produkt 0 und ich werde abgewiesen

In aller Regel kommt MFA heute in der Dosierung 2FA daher: Passwort und SIM-Karte (SMS), Passwort und Hardwaretoken, Passwort und Handy (Authenticator-App) sind hier die Klassiker

• Und dieses "+1" erhöht die Stärke der Authentifizierung – ein mathematischer Effekt der Produktbildung aus Faktoren – so sehr, dass 2FA heute zu Recht als eine der stärksten Standardsecuritymaßnahmen gilt und sich, ebenfalls zu Recht, sehr schnell zum Stand der Technik entwickelt
• In einigen Bereichen wie Zahlungsdienstleistungen ist 2FA seit einigen Jahren sogar vorgeschrieben

Alles hat ein Ende – nur die Zwei ist nicht wurst

Dabei ist Authentifizierung keineswegs die einzige Stelle in der Security, an der ein zweiter Faktor zum Einsatz kommt

• Nur wird es anderswo weniger explizit gemacht: Statt 2FAAA (Zwei-Faktor-Authentifizierung, -Autorisierung und -Accounting), 2PF (Doppelfirewall) oder 2Zonen (DMZ) sagen wir schlicht "Defense in Depth", gestaffelte Verteidigung
• Und während dieses Jahrtausende alte militärische Konzept als Leitprinzip für Sicherheitsarchitekturen grundsätzlich nützlich ist, verschleiert es doch, welche Maßnahme ein zweiter (oder dritter) Faktor für welches andere Sicherheitsziel ist

Klar wird das Ganze sehr schön am Thema Backup

• Im Prinzip versteckt sich die Zwei hier schon im ersten Teil des Begriffs: Wenn ich nie "zurück" (back) muss, weil ich immer "up" (am Laufen und dran) bin, brauche ich mein Backup nie! Es handelt sich also hierbei um einen zweiten Faktor der Verfügbarkeit

Moment, möchte man sagen: Ich brauche doch nur entweder meine Produktivdaten oder mein Backup, um arbeitsfähig zu bleiben, also ist es gerade kein Faktor im Sinn von UND, also ich brauche beide! Stimmt, aber aus Angreifersicht stellt es sich so dar: Wenn ich nur die Produktivdaten oder nur das Backup vernichte oder verschlüssele, habe ich mein Ziel nicht erreicht

• Ich muss beide Faktoren überwinden, analog der 2FA

2FDaten

Dieser Blick ermöglicht uns, Beziehungen zwischen verschiedenen Sicherheitsmaßnahmen zu verstehen, die mit dem Begriff Defense in Depth nur globalgalaktoschwammig ausgedrückt werden

• Wer es fancy mag, kann in die MITRE-ATT&CK-Matrix hineinschauen, die versucht, alle möglichen Arten von Angriffsvektoren als Graph beziehungsweise Netz darzustellen
• Aber schon die unschuldige Frage "Habe ich einen zweiten Faktor für meine Daten/Prozesse/Vertraulichkeit/Integrität/Verfügbarkeit/Datensparsamkeit/Anonymität?" oder was immer meine Sicherheitsziele sind, kann helfen, mein Securityprogramm zweckgerichtet nachzusteuern

Drei Werte – CIA oder DIE

Die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit sind der Heilige Gral der Informationssicherheit

• Was, wenn das Konzept gar nicht zielführend ist?

Jede abgespaltene Gemeinschaft, jede Religion, jede Ingroup basiert auf einer Urlüge, deren Akzeptanz als Wahrheit es bedarf, um dazuzugehören oder aufgenommen zu werden

• Im Christentum ist es die Idee, dass alle Menschen in Sünde geboren sind
• Die Longevity-Bewegung glaubt an die prinzipielle Unendlichkeit unseres biologischen Lebens
• Und in der Security ist es CIA – Vertraulichkeit, Integrität, Verfügbarkeit (Confidentiality, Integrity, and Availability)

Besonders sektenhafte Gruppen zeichnen sich dadurch aus, dass sie ihre Urlüge "Definition" nennen

• Das macht es noch schwieriger, sie infrage zu stellen, denn damit oute ich mich nicht nur als Ungläubiger, sondern außerdem noch als unwissend, renitent und dumm

Häretiker:innen!

Dabei ist einiges fragwürdig an der Idee, die Grundlagen unseres Felds, der Informationssicherheit, an diesem zwar historisch gewachsenen und somit nicht ganz willkürlichen, andererseits aber auch nicht unveränderbaren Dreieck aufzuhängen

• So ist längst den meisten klar, dass die eine gewisse Priorisierung implizierende Reihenfolge der Werte der Informationssicherheit vielleicht häufig in der Enterprise IT, selten jedoch in der OT gilt

Hier gilt eher AIC oder sogar – auch wenn das Nachdenken über wirklich geschickte, gezielte Manipulationen an Kraft- oder Stellwerken sowie sonstigen KRITIS schnell gruselig wird – IAC

Auch hat sich vielerorts herumgesprochen, dass die drei "Dimensionen" C, I und A nicht unabhängig voneinander sind

• In der klassischen Darstellung als Dreieck ist das zwar bereits angedeutet
• Trotzdem lohnt es, sich einmal klarzumachen, auf wie viele Arten und Weisen sich unsere drei Parameter gegenseitig beeinflussen können, positiv wie negativ
• Drei Beispiele: Komplett korrupte Daten sind nicht so schnell wieder verfügbar zu bekommen
• Verschlüsselung hilft der Vertraulichkeit, kann aber meine Integrität (Schlüssel verloren) oder meine Verfügbarkeit (Zertifikat abgelaufen) ruinieren

Schlimmer noch: Die Werte haben indirekten Einfluss aufeinander

• So sichert das Schützen der Vertraulichkeit eines Schlüssels offensichtlich die Vertraulichkeit (des Schlüssels und potenziell aller mit ihm verschlüsselter Dinge), aber häufig auch die Integrität und Verfügbarkeit ganzer Systeme und Infrastrukturen, deren Eingang der Schlüssel bewacht

CIA ist tot

Auch Zehntausende hohle, weil redundante oder sinnlose Begründungsfelder in Schutzbedarfsfeststellungen deuten darauf hin, dass unsere Urlüge der methodischen Weiterentwicklung des Felds nicht unbedingt hilft

• Sinnvolle Skalierung unmöglich beziehungsweise extreme Arbeitsbeschaffungsmaßnahme
• Was muss stattdessen her?

Das neuere DIE-Sicherheitsmodell (Distributed, Immutable, Ephemeral) ist ein Konzept in der Informationssicherheit, das auf die drei Aspekte Verteilung, Unveränderlichkeit und Vergänglichkeit von Daten abzielt

Der erste Aspekt bezieht sich auf die Verteilung von Daten auf verschiedene Orte, um das Risiko eines Verlusts oder einer unerkannten Manipulation zu verkleinern

• Bei Unveränderlichkeit geht es darum, dass bestimmte Daten nicht unerkannt manipuliert werden können
• Vergänglichkeit zielt darauf ab, dass viele Daten nur für einen begrenzten Zeitraum existieren sollten, um das Risiko von unbefugtem Zugriff und Datenmissbrauch zu minimieren
• Nach dem Ablauf der Lebensdauer sollten sie automatisch gelöscht werden, um sicherzustellen, dass keine veralteten oder unnötigen Informationen verfügbar bleiben

Verschiedene Betrachtungswinkel

Anstatt also wie bei CIA jedes Datum einzeln auf sein Schadenspotenzial zu bewerten, wird bei DIE versucht, alle Daten grundsätzlich "richtig" zu behandeln: Sind die Daten verteilt, um Skalierbarkeit zu ermöglichen und Abhängigkeit von einer einzelnen Zone zu vermeiden? Können veränderte Kopien von unveränderlichen Daten oder Komponenten bei einem Problem entsorgt und ersetzt werden, zum Beispiel durch Infrastructure as Code (IaC)? Wie lange dauert die Neubereitstellung des Systems, und werden flüchtige Assets ausreichend schnell entwertet?

Das DIE-Modell hat gegenüber CIA viele Vorteile: Es kann die Vertraulichkeit der Daten verbessern, indem es sie von einer flüchtigen und austauschbaren Architektur trennt

• Es kann die Integrität der Daten gewährleisten, indem es Methoden zur Überprüfung und Wiederherstellung bereitstellt
• Und es kann die Verfügbarkeit der Daten erhöhen, indem es eine verteilte und skalierbare Infrastruktur einfordert, die Ausfälle vermeidet oder verkürzt

Wird mit DIE alles besser? Nein

• Sollten wir es endlich großflächig anwenden? Ja! Allein schon, um zu schauen, was es uns an Ideen, Gedankenstürzen und Strategien bringen kann, um die Security voranzubringen

Vier Stufen – Risiko und Security Levels

Das Einrichten des IT-Schutzes bedeutet häufig langwierige Prozesse

• Abhilfe schaffen die Security Levels zum Absichern gegen potenzielle Angreiferklassen

Es soll also etwas für die Security getan werden

• Aber: wie viel? Immerhin kostet das Zeit, Geld und oft auch Bequemlichkeit ("Usability")
• Hundertprozentige Security ist bekanntermaßen nicht erreichbar
• Da aber der zusätzliche Nutzen höherer Investitionen immer weiter abnimmt, muss man sich über das richtige Maß Gedanken machen

Viele handelsübliche Vorgehensweisen versuchen, einen Schutzbedarf für Werte wie Daten, Anwendungen oder Systeme zu bestimmen

• Dafür zieht man häufig qualitative Kategorien heran
• Im IT-Grundschutz etwa heißen diese normal (begrenzte Auswirkung bei (Zer-)Störung des Werts), sehr hoch (im Fall der Fälle existenziell bedrohlich) und hoch (alles dazwischen)
• Schäden können dabei auf verschiedene Weise entstehen, etwa Verstöße gegen Gesetze oder Verträge, negative Innen- oder Außenwirkung oder finanzielle Verluste
• Die Auswirkung muss man dabei in allen relevanten Dimensionen von Schützenswertem betrachten, etwa Vertraulichkeit, Integrität und Verfügbarkeit

Was als normal, hoch oder sehr hoch gilt, muss jede Organisation selbst definieren, sofern es von außen keine Vorgaben dazu gibt

• Letzteres ist teilweise bei kritischen Infrastrukturen der Fall, wo der Gesetzgeber vermeiden will, dass Betreiber ihr Ziel-Sicherheitsniveau herunterrechnen, um Aufwände zu sparen
• Erst wenn die Schadensszenarien, die Stufen und Schwellenwerte klar sind, kann man beginnen, jedes einzelne Asset nach diesem Maßstab zu bewerten
• Dabei kommen Prinzipien wie Maximum, Vererbung und Verteilung zum Einsatz, um etwa den Verfügbarkeitsbedarf eines Servers von dem der Daten oder gar Geschäftsprozesse abzuleiten, die mithilfe dieses Servers erbracht werden
• Dann lassen sich im nächsten, nicht weniger aufwendigen Schritt die Risiken bestimmen
• Risiken drückt man dabei häufig als Produkt von Eintrittswahrscheinlichkeiten und Schutzbedarf oder Schadenspotenzial aus

Anforderung rein, Aktion raus

Anstelle dieses aufwendigen Wegs gibt es zwei andere Ansätze, die versprechen, einen Teil der anstrengenden Denk- und Dokumentationsarbeit zu sparen

• Der Erste nennt sich Mindeststandards: Anstatt zu versuchen, die Menge, Stärke und Tiefe der IT-Sicherheitsmaßnahmen genau auf den Anwendungsfall zuzuschneiden, nutzt man eine One-Size-fits-all-Liste von Anforderungen
• So funktionieren etwa die meisten rein technischen Standards, die sich mit Security beschäftigen
• TLS 1.3 etwa fragt nicht, welchen Schutzbedarf die zu übertragenden Daten haben, SSH gibt es nicht in Normal-, Hoch- und Sehr-hoch-Geschmack
• Der Mindeststandard ist entweder umgesetzt oder nicht

Einen nuancierteren Ansatz versuchen Normen wie die aus der Industrial Security stammende IEC 62443 umzusetzen

• Die IEC 62443 definiert vier Security Levels, die die Anzahl der umzusetzenden Maßnahmen steuern
• Der Prozess ist somit zweischrittig: Sage mir, welches Security Level (SL) du bist/hast/willst, und ich sage dir, wie viel du tun musst
• Höhere SLs führen neue Maßnahmen ein oder verschärfen die bereits umgesetzten

Interessanterweise definiert die IEC 62443 das SL nicht über den Wert der Assets, sondern über die im Worst Case zu erwartende Angreiferkompetenz

• Wer würde meine Umgebung schlimmstenfalls attackieren wollen? SL 1 meint den Nicht-Angreifer, nämlich das technische Versagen, das uns auch dann treffen kann, wenn niemand uns Böses will
• SL 2 beschreibt im Wesentlichen Script Kiddies, SL 3 Cybercrime und SL 4 Advanced Persistant Threats, also ressourcenreiche staatlich gesteuerte Akteure
• Das Konzept erlaubt es, die Risikoanalyse kurzzuhalten: Man muss nur bewerten, welches SL zu erreichen ist, und entscheidet das entweder einmal für die Infrastruktur oder je Zone
• Sinnvollerweise unterscheidet die Norm auch nach Schutzzielen, in der IEC 62443 Foundational Requirements genannt
• Beispiel: Integrität SL 3, Authentizität SL 2 und so weiter
• Am Ende stehen unterm Strich automatisch die umzusetzenden Maßnahmen, wodurch dieser Ansatz einem den Großteil der Risikoanalyse abnimmt

Letztendlich geht es darum, wie viel Gehirnschmalz und Expertise man auf welchen Teil der Analyse ver(sch)wenden möchte

• Kann ich mir den Luxus leisten, für jede Komponente einzeln den Schutzbedarf zu bestimmen? Habe ich genug Fachwissen im Zugriff, um alle Risiken zu bewerten? Dort, wo die Antwort kein hundertprozentiges Ja ist, können sowohl Mindeststandards als auch Security Levels helfen, ein einigermaßen angemessenes Set an Maßnahmen für das jeweilige Risikoprofil zu ermitteln
• Umsetzen muss man sie so oder so noch

Fünf Bedrohungen – Threats und Models

Nicht nur von außen drohen Gefahren, auch von innen muss ein System abgesichert sein

• Hier zählt der richtige Zeitpunkt

Nachdem sich diese Serie von soziopolitischen Kategorien wie Vertrauen über philosophische wie Werte bis zu ökonomischen wie Risiko vorgearbeitet hat, scheint es nun einen Schritt zurückzugehen

• Bedrohungsmodellierung – wäre das nicht an der Reihe, bevor man sich über das Risiko Gedanken macht?

Risiko offenbart sich eher beim Blick auf eigene Belange: Was (und wie viel) bei einem selbst passieren könnte (maximale Schadenshöhe bei uns im Unternehmen multipliziert mit der Eintrittswahrscheinlichkeit des Ereignisses bei uns)

• Dagegen schaut Threat Modeling nach außen: Was droht in der Welt grundsätzlich für die eigenen Assets? Beide Perspektiven haben Vorteile
• Es ist nämlich keine gute Idee, wenn Menschen in der IT, und insbesondere in der Softwareentwicklung, darauf warten, dass sich "das Business" auf eine maximale Schadenshöhe in diversen Worst Cases und "die Security" auf eine Eintrittswahrscheinlichkeit derselben verständigt haben
• Derweil sind schon sieben neue Features implementiert worden

Eine Bedrohung ist eine grundsätzliche Möglichkeit des Eintretens eines Schadens, unabhängig von seiner Wahrscheinlichkeit, und häufig auch in der Schadenshöhe nicht exakt quantifiziert

• Sie ist also schneller beschrieben und dokumentiert als ein Risiko, zu dem immer auch statistische Parameter gehören
• Ein Modell ist ein vereinfachtes Abbild der Wirklichkeit, das damit nur zu einem gewissen Maß übereinstimmt
• Threat Modeling ist folglich ein strukturierter Prozess, der versucht, mit möglichst wenig Aufwand eine Liste der Bedrohungen zu liefern, die für einen Betrachtungsgegenstand (Software, Rechenzentrum, Cloud-Tenant …) relevant sind
• Meist liefert das Threat Modeling auch schon Anhaltspunkte, wie mit den Bedrohungen umzugehen ist

Bedrohungsmodelle

Bedrohungsmodellierung in vier Schritten

Grundsätzlich arbeitet Bedrohungsmodellierung in folgenden vier Schritten, auch wenn diese nicht immer explizit gemacht werden: Was ist der Betrachtungsgegenstand, was kann schiefgehen, was soll dagegen getan werden (Strategien zur Abschwächung der Bedrohungen) und haben wir gute Arbeit geleistet (Überprüfung der Wirksamkeit des Modells und der implementierten Maßnahmen)? Zu den am häufigsten verwendeten Techniken gehören:* Angriffsbäume: Sie waren früher sehr beliebt, um potenzielle Bedrohungen zu strukturieren, gelten aber inzwischen als veraltet, da sie ein hohes Maß an Sicherheitsexpertise erfordern und schnell sehr komplex werden können

• Kill Chains: Diese Technik wird vor allem bei der Reaktion beziehungsweise bei der Planung der Reaktion auf Vorfälle eingesetzt und hilft, die Schritte zu verstehen, die Angreifer unternehmen, um ein System zu kompromittieren
• Datenflussdiagramme: Diese sind einfach, aber effektiv, um zu visualisieren, wie sich die entscheidenden Assets (häufig die Daten) durch ein System bewegen
• Rein grafisch lässt sich so gut erkennen und dokumentieren, wo welche Bedrohungen wirken können
• STRIDE: Diese ursprünglich bei Microsoft entwickelte Methodik kategorisiert verschiedene Typen von Bedrohungen wie Spoofing (Bruch der Authentizität), Manipulation (Bruch der Integrität), Abstreiten (Bruch der Nichtabstreitbarkeit beziehungsweise Nachvollziehbarkeit), Offenlegung von Informationen (Bruch der Vertraulichkeit), Denial of Service (Bruch der Verfügbarkeit) und Elevation of Privilege (Bruch der Autorisierung)
• Damit, so die Idee, sollten Entwicklerinnen und Entwickler es schaffen, an alle relevanten Bedrohungen zu denken

Tool-Unterstützung

Heute kommen für das Threat Modeling komplexer Anwendungen oder Infrastrukturen – mit Infrastructure as Code (IaC) verschwimmen diese beiden Kategorien ja immer mehr – Tools zum Einsatz, die das Modell inklusive Bedrohungen und Abhilfe zumindest halb automatisch erzeugen

• Das Modellieren von Bedrohungen hilft nicht nur, potenzielle Bedrohungen zu erkennen und zu verstehen, sondern erhöht auch die Wahrscheinlichkeit, dass fundierte Entscheidungen über den Umgang mit ihnen getroffen werden

Links

1. https://www.heise.de/hintergrund/Security/Bausteine-Teil-6-Fuenf-Bedrohungen-Threats-und-Models-9327082.html