Wie sich Architekturentscheidungen auf Threat Modeling & Enterprise IT-Security auswirken

Bei der Bedrohungsmodellierung (Threat Modeling) können verschiedene Methoden gewählt werden, um ein Gesamtbild der Schwachstellen einer Anwendung und der verschiedenen Abhilfemaßnahmen zu erhalten. Fast alle verfügbaren Methoden basieren darauf, dass ein digitales System zunächst über seine Architektur definiert wird. Diese umfasst in der Regel alle bekannten Komponenten innerhalb einer Anwendung oder eines IT-Systems, wie diese miteinander verbunden sind und wo die Vertrauensgrenzen liegen. Frühe Entscheidungen über die Architektur können daher große Auswirkungen haben.

Kurz gesagt: Die Entscheidung über die zu verwendende Architektur ist von entscheidender Bedeutung für spätere Entscheidungen über Bedrohungen, ihre relativen potenziellen Auswirkungen und die zu ihrer Bekämpfung zu ergreifenden Gegenmaßnahmen. Darüber hinaus spielt die Gesamtarchitektur eines Systems eine Rolle bei der Entscheidung, wer an welcher Stelle im System die Verantwortung für erkannte Bedrohungen oder die Abwehr von Schwachstellen übernimmt.

Aus Sicht der Sicherheitsplanung in einem Unternehmen ist es nicht nur wichtig, Bedrohungen zu modellieren, sondern sie auch innerhalb einer geeigneten Architekturstruktur zu analysieren. Daher sollten bei der Konzeption einer neuen Anwendung Architekturentscheidungungen unter Berücksichtigung ihrer Auswirkungen auf die Bedrohungsmodellierung und -analyse getroffen werden.

Grundsatzfrage Architektur: Zero Trust, Serverlos oder MACH

Wie bereits erwähnt, müssen Unternehmen bei der Wahl der Anwendungsarchitektur eine Entscheidung treffen. Um zu analysieren, welche aus der Perspektive der Bedrohungsmodellierung am besten geeignet ist, muss man verstehen, wie sich eine anfängliche Entscheidung auf die spätere Entwicklung auswirken kann. Im Folgenden werden drei gängige Architekturen daraufhin untersucht, wie sie zu Problemen bei der Bedrohungsmodellierung führen können und wo sie Vorteile bieten.

Zero Trust

Zero Trust ist ein Cybersicherheitskonzept, das für seine strategischen Qualitäten bekannt ist. Es impliziert, dass in praktisch jeder Phase eines digitalen Prozesses eine Validierung erforderlich ist. Obwohl es darauf abzielt, implizites Vertrauen aus Systemen zu eliminieren, kann es auch vom anderen Ende her betrachtet werden: Nämlich dass die Art und Weise, wie explizites Vertrauen in einem System gehandhabt wird, überdacht wird.

Vereinfacht gesagt geht es darum, die gegenseitige Authentifizierung von Entitäten zu betonen. Wann immer ein Teil einer Anwendung mit einem anderen Teil in einer Zero-Trust-Architektur interagiert, wird eine Validierung der Eingaben und des Durchsatzes erwartet. Sie bietet ein insgesamt höheres Sicherheitsniveau, unterscheidet aber nicht zwischen internen vertrauenswürdigen Elementen und externen nicht vertrauenswürdigen Elementen.

Diese Art von Architektur bietet zum einen ein hohes Maß an Unternehmenssicherheit. Zum anderen verhindert sie mögliche seitliche Bewegungen von Angreifern, die versuchen, die Gegenmaßnahmen, auf die sie stoßen, zu umgehen. Es ist auch ein bewährter Ansatz für interne Angriffe, da Mitarbeiter*innen und andere LAN-Nutzer*innen, die nicht von außen kommen, immer noch auf die gleichen Gegenmaßnahmen treffen wie Außenstehende. Darüber hinaus ermöglicht diese Architektur eine relativ einfache Migration von Anwendungen aus der Unternehmensumgebung in die Cloud.

Der Nachteil ist, dass Zero-Trust-Architekturen mehr Aufmerksamkeit für die Sicherheit erfordern. Es kann sogar der Eindruck entstehen, dass sie fast ausschließlich von Sicherheitsprotokollen und Prozessprüfungen bestimmt werden. Dies wiederum kann dazu führen, dass Anwendungen, die auf einer solchen Architektur basieren, langsam laufen, nicht benutzerfreundlich sind und sowohl in der Entwicklung als auch in der Wartung teurer sind.

Serverlos (Serverless)

Der zweite heute weit verbreitete Architekuransatz wird oft als serverlos (serverless) bezeichnet. Tatsächlich handelt es sich dabei um eine Art Schlagwort der Branche, das eigentlich eine Cloud-orientierte Anwendungsarchitektur meint. Natürlich ist auch ein solcher Ansatz auf Server angewiesen, nur eben auf Server von Drittanbietern über die Cloud und nicht auf Server vor Ort im Unternehmen.

Trotz dieser etwas verwirrenden Bezeichnung ermöglichen serverlose Architekturen Unternehmen, Schichten in ihren Anwendungen zu eliminieren. So können beispielsweise Datenbanken, das Betriebssystem, Laufzeitumgebungen und Dateispeicher in einer einzigen Infrastruktur verwaltet werden, was die Zahl potenzielle Zugriffspunkte oder Schwachstellen verringert. Dies ist darauf zurückzuführen, dass der Cloud-Anbieter in der Regel die Verantwortung für die Infrastruktur und die Durchführung von Sicherheitsprozessen übernimmt.

Einer der größten Vorteile einer serverlosen Architektur besteht darin, dass nur die Anwendungsschicht des Systems direkt vom betreffenden Unternehmen verwaltet werden muss. Dies unterstreicht den Fokus auf die Geschäftslogik. Warum? Weil Unternehmen, die nicht über interne technische Fähigkeiten zur Bewältigung von Bedrohungen verfügen, diese effektiv auslagern und so ihre technische Umgebung reduzieren können.

Andererseits müssen bei der Wahl einer serverlosen Architektur Aufgaben an Dritte übertragen werden. Je nach Anwendung kann dies zu Problemen bei der rechtlichen Risikominimierung führen, z. B. durch die Speicherung von Daten auf einem Server, der sich außerhalb der Gerichtsbarkeit oder der Verträge des Unternehmens befindet. Trotz der potenziellen Bindung an einen Anbieter bieten serverlose Architekturen Unternehmen eine gute Möglichkeit, ihre Anforderungen an Sicherheit und Bedrohungsmodellierung mit einem gewissen Maß an abgetretener Kontrolle in Einklang zu bringen.

MACH

Eine Reihe von Technologieprinzipien, die hinter vielen der neuesten heute verfügbaren Technologieplattformen stehen, sind als MACH bekannt. Das Akronym steht für Microservices-based, API-first, Cloud-native (oder SaaS) und Headless. Viele Unternehmen entscheiden sich für diesen Ansatz, weil sie bei der Entwicklung einer Anwendung nicht jedes Mal das Rad neu erfinden müssen.

MACH ist als Best-of-Breed-Technologieplattform bekannt und legt großen Wert auf Skalierbarkeit und Flexibilität. Viele Elemente können von einer Anwendung auf eine andere übertragen werden, wenn sie ähnliche Aufgaben erfüllen. Dieser Architekturansatz legt den Schwerpunkt auf die Multikanal-Kommunikation, die viele Unternehmen benötigen, sowie auf die Wiederverwendbarkeit. Er ist daher eine Überlegung wert, wenn viele Sicherheitsanforderungen berücksichtigt werden müssen, da ein Großteil des Architekturansatzes Wiederholungen zulässt.

Einer der Vorteile von MACH-Architekturen aus Sicht der Bedrohungsmodellierung ist, dass sie ein hohes Maß an Kontrolle ermöglichen. Dies wird vor allem durch einen modularen Ansatz und einen starken Fokus auf Systeme mit sicheren und wiederverwendbaren APIs erreicht.

MACH-Architekturansätze haben auch einige Nachteile, die zu berücksichtigen sind. Beispielsweise kann dieser Ansatz zu einem Konflikt zwischen Agilität und technischen Anforderungen führen. Darüber kann es in MACH-basierten Architekturen eine große Anzahl von Stakeholdern geben, von denen einige die Schwachstellen des Systems unterschiedlich wahrnehmen können. Dies kann dazu führen, dass einige die Backend-Microservices in einer anderen Architekturumgebung behandeln wollen, auch wenn MACH für die Hauptsystemarchitektur verwendet wird. In diesem Fall ist es üblich, dass Zero Trust für solche Services zu implementieren.

Architektur und Modellierung von Bedrohungen

Obwohl Zero-Trust-Architekturen insgesamt ein höheres Sicherheitsniveau bieten, sind sie in der Regel teurer und zeitaufwändiger in der Bedrohungsmodellierung. Insgesamt bietet die serverlose Architektur Unternehmen eine gute Möglichkeit, ihre Anforderungen an Sicherheit und Bedrohungsmodellierung gegen die Abgabe eines Teils der Kontrolle abzuwägen. Zusammenfassend bietet MACH eine Mischung aus Chancen und Risiken. Folglich wird jede der oben beschriebenen Architekturen unterschiedliche Ergebnisse liefern, wenn es darum geht, sie für die Bedrohungsmodellierung zu nutzen.

Hier hilft, dass es viele verschiedene Ansätze für die Bedrohungsmodellierung gibt. So können Bedrohungsmodellierer trotz einiger Vor- und Nachteile jedes Architekturansatzes spezifische Techniken anwenden, um die positiven Aspekte jedes Ansatzes zu verstärken und die negativsten Aspekte abzuschwächen.

Welche Modellierungstechniken von Bedrohungen können für die Anwendungsarchitektur verwendet werden?

Angesichts der großen Auswahl, die für die Modellierung von Sicherheitsbedrohungen für Unternehmen zur Verfügung steht, lohnt es sich, einige der heute gebräuchlichen Methoden kurz zu betrachten.

PASTA

PASTA ist ein Akronym, das für “Process for Attack Simulation and Threat Analysis” steht. Es handelt sich um einen siebenstufigen Prozess, der einen ganzheitlichen Ansatz für die Analyse von Bedrohungen und deren Abschwächung durch Gegenmaßnahmen verfolgt. Er kann mit jedem der oben genannten Architekturansätze arbeiten und liefert oft umfassende Ergebnisse. Die Implementierung von PASTA kann jedoch sehr zeitaufwändig sein.

Weitere Details zu den sieben Prozessschritten findne sich im ersten Fachartikel zu Threat Modeling.

Persona Non Grata

Die Methode der Bedrohungsmodellierung, auch als PnG bekannt, fordert Systementwickler*innen auf, die Bedrohungen aus der Sicht der Angreifer zu betrachten. Die Modellierer*innen haben nicht nur eine Vorstellung davon, wer eine Anwendung angreifen könnte, sondern bauen eine ganze Persona um sie herum auf – ähnlich wie bei bestimmten Marketingaktivitäten, um Kunden besser zu verstehen.

Dieser Ansatz kann dabei helfen, Bedrohungen aus einer menschlichen Perspektive zu identifizieren und ist ein guter Einstieg in die Bedrohungsmodellierung. Ein Nachteil ist, dass er bei weitem nicht so umfassend ist wie andere Methoden und kaum als vollständig angesehen werden kann.

Octave

Die Modellierung der Bewertung von unternehmenskritischen Bedrohungen und Schwachstellen wird im Allgemeinen einfach als bezeichnet. Dieser Ansatz konzentriert sich auf die organisatorische Infrastruktur und die Prozesse. Technischen Bedrohungen stehen daher weniger im Vordergrund. Bei der Modellierung mit Octave werden in der Regel Bedrohungsanalysen erstellt, die auf dem Schaden basieren, der einer Organisation durch den Verlust oder Diebstahl ihrer Vermögenswerte entstehen würde.

Dies kann z. B. bedeuten, dass Schwachstellen in der Infrastruktur identifiziert und Gegenmaßnahmen wie sichere Backups ergriffen werden. Ein Vorteil von Octave ist, dass Entscheidungsträger einen umfassenden Überblick über ihre Systeme erhalten. Ein Nachteil ist jedoch, dass bei dieser Methode einige technische Details innerhalb einer bestimmten Architektur übersehen werden können.

Kartenspiel “Elevation of Privilege”

Das Kartenspiel “Elevation of Privilege” (deutsch: Rechteausweitung) ist ein von Microsoft entwickelter Ansatz zur Modellierung von Bedrohungen. Wie der Name schon sagt, wird dabei ein Spiel – in diesem Fall ein Kartenspiel – verwendet, um Bedrohungen auf Basis eines Worst-Case-Szenarios zu identifizieren. Die Modellierer spielen die Karten aus und sehen, welche Bedrohung am problematischsten ist und welche nicht. Die spielerische Modellierung von Bedrohungen kann die Modellierer von ihrem eigentlichen Ziel ablenken. Sie kann auch zu unvollständigen Ergebnissen führen. Positiv ist jedoch, dass diese Technik der Bedrohungsmodellierung Spaß machen kann. Sie ist auch leicht zu erlernen und bietet einen guten Einstieg in die Bedrohungsmodellierung.

STRIDE

STRIDE wurde ursprünglich von Microsoft erfunden und hat sich zu einem De-facto-Standard entwickelt, der von verschiedenen Tools und Richtlinien übernommen wurde, z. B. von der OWASP (einschließlich ihres Modellierungs-Tools Threat Dragon).

Es ist ein Akronym für die Bedrohungen in diesem Bereich: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege (dt.: Identitätsverschleierung, Manipulation, Verleugnung, Offenlegung von Informationen, Dienstblockade und Rechteausweitung). Die Risiken werden einer oder mehreren dieser Bedrohungen zugeordnet. Für die Bewertung der identifizierten Bedrohungen gibt es das entsprechende DREAD-Modell, das wiederum ein Akronym für die Dimensionen des Schweregrads ist: Damage, Reproducibility, Exploitability, Affected Users und Discoverability (dt.: Schaden, Reproduzierbarkeit, Ausnutzbarkeit, Betroffene Nutzer und Entdeckbarkeit). STRIDE kann aber auch mit anderen Schweregraden arbeiten.

LINDDUN

LINDDUN ist ein Akronym für die Bedrohungskategorien im Anwendungsbereich: Linkability, Identifiability, Non-Repudiation, Detectability, Disclosure of Information, Unawareness, und Non-Compliance (dt.: Verknüpfbarkeit, Identifizierbarkeit, Nichtabstreitbarkeit, Aufdeckbarkeit, Offenlegung von Informationen, Unkenntnis und Nichteinhaltung von Vorschriften). Der Prozess besteht im Wesentlichen aus 3 Schritten:

1. Modellierung des Systems im Anwendungsbereich. Dabei werden der Anwendungsbereich und der Datenfluss transparent gemacht.
2. Identifikation von Bedrohungen mit Hilfe von Bedrohungsbäumen, einer Abwandlung der früher bekannten Angriffsbäume. Die Bedrohungen werden auf den Datenfluss des Systems abgebildet.
3. Schließlich wird eine Priorisierungsfunktion angewendet, um Bedrohungen zu verwalten und zu behandeln und Abhilfemaßnahmen durchzuführen. Die verwendete Taxonomie ist nicht durch LINDDUN vorgegeben.

Auf einen Blick: Threat Modeling, Architektur und Techniken

Zusammenfassend lässt sich sagen, dass über die Architektur eine systematische Denkweise für die Entwicklung von Anwendungen und die Sicherheit von IT-Systemen ermöglicht. Unterschiedliche Architekturansätze beeinflussen jedoch, wie die Bedrohungsmodellierung im weiteren Verlauf durchgeführt wird.

Architektonische Ansätze stellen an sich noch keine Unternehmenslösung dar. Vielmehr sollten sie von Fall zu Fall für unterschiedliche Geschäftsmodelle evaluiert und bewertet werden. Schließlich können Bedrohungsmodellierungstechniken innerhalb verschiedener Architekturen angewandt werden, manchmal sogar mit einem mehrschichtigen Ansatz, um maßgeschneiderte Lösungen zu schaffen, die am besten zu einer Vielzahl von geschäftlichen und betrieblichen Prioritäten passen.

Weitere Informationen:

• Einführung: Sicherheitsbedrohungen und -risiken durch Threat Modeling entschärfen

Experten-Kontakt

Haben Sie Fragen zur Threat Modeling-Expertise von mgm? Nehmen Sie Kontakt per E-Mail auf, rufen Sie uns an oder nutzen Sie unser Kontaktformular.