Welche Bedrohungen entstehen aus Ihrer konkreten Architektur? Wir analysieren Datenflüsse, Trust Boundaries und Angriffsszenarien und leiten daraus konkrete Security Requirements ab.
Viele Sicherheitsmaßnahmen werden eingeführt, weil sie als Best Practice gelten, ein Framework sie nennt oder ein Tool sie empfiehlt. Threat Modeling beginnt stattdessen bei der tatsächlichen Architektur.
Das Ziel ist keine möglichst lange Liste theoretischer Angriffe. Relevante Bedrohungen sollen verstanden, Schwächen in Architektur und Design erkannt und belastbare Anforderungen für Entwicklung, Betrieb und Management abgeleitet werden.
relevante Bedrohungen nachvollziehbar beschreiben
Architekturrisiken früh erkennen
Security Requirements begründet ableiten
Maßnahmen nach Risiko priorisieren
Pakete & Preise
Analysetiefe passend zur Architektur
Compact hat einen Festpreis innerhalb des klar beschriebenen Scopes. Threat Model System: ab 2.900 € netto. Threat Model Architecture: ab 4.900 € netto.
vorhandene und ausreichend aktuelle Architekturinformationen
ein Hauptworkshop
eine Ergebnisrunde
keine umfangreiche Neuerstellung fehlender Architekturunterlagen
überschaubare Zahl relevanter Komponenten und Schnittstellen
Vor Beauftragung prüfen wir kurz, ob Ihr System in den Compact-Scope fällt. Bei höherer Komplexität empfehlen wir das System- oder Architecture-Paket.
Für Eigenentwicklungen und SaaS
Threat Model
System
ab 2.900 € netto
Geeignet für
Eigenentwicklungen und SaaS-Anwendungen
mehrere relevante Schnittstellen
externe Services und Cloud-Komponenten
mehrere Trust Boundaries
Enthalten
Scope, Architekturreview und Datenflussanalyse
Trust Boundaries, Assets und Schutzbedarfe
strukturierte Bedrohungsanalyse
STRIDE oder passende alternative Methodik
Bewertung relevanter Bedrohungen
Security Requirements und priorisierte Maßnahmen
dokumentiertes Threat Model und Ergebnisworkshop
Threat Model
Architecture
ab 4.900 € netto
Geeignet für
komplexe oder geschäftskritische Architekturen
mehrere Anwendungen oder Systemgrenzen
Microservices und umfangreiche API-Landschaften
hybride Architekturen, hohe Schutzbedarfe und mehrere Stakeholder
Möglicher Umfang
vertieftes Architecture Review und mehrere Datenflüsse
Trust-Boundary-Analyse und mehrere Angriffspfade
vertieftes Threat Modeling
STRIDE oder geeignete Methodenkombination
Security Requirements und priorisierter Maßnahmenplan
technische Ergebnispräsentation und Management Summary
Welches Paket passt?
Ein klarer Einzelscope kann als Compact bearbeitet werden. Mehrere Schnittstellen, externe Dienste oder mehrere Trust Boundaries sprechen für System. Mehrere Systeme, komplexe API-Landschaften oder hohe Schutzbedarfe erfordern meist Architecture.
STRIDE ist in keinem Paket Selbstzweck. Methodik und Analysetiefe richten sich nach System, Architektur, Scope und Fragestellung.
Vorgehen
Was passiert im Threat Modeling?
ScopeWas analysieren wir – und was ausdrücklich nicht?
ArchitekturKomponenten, Nutzer, Systeme, Schnittstellen und externe Dienste verstehen.
DatenflüsseVerstehen, welche Informationen sich zwischen Komponenten bewegen.
Trust BoundariesWechsel von Vertrauensbereichen, Identitäten und Verantwortlichkeiten erkennen.
AssetsBestimmen, welche Informationen und Funktionen geschützt werden müssen.
BedrohungenRealistische Angriffsszenarien aus der Architektur ableiten.
STRIDE / MethodikBedrohungen passend zum System strukturiert prüfen.
Security RequirementsAnforderungen für Architektur und Entwicklung formulieren.
PriorisierungNotwendige Änderungen nach Risiko und Wirkung ordnen.
DokumentationErgebnisse für Entwicklung, Architektur, Security und Management nutzbar machen.
Mögliche Methodik
Was ist STRIDE?
STRIDE ist ein Modell zur systematischen Einordnung möglicher Bedrohungen. Es unterstützt die Analyse, ersetzt aber weder Architekturverständnis noch Risikobewertung.
STRIDE ist kein Ergebnis. Es ist ein Werkzeug, um Bedrohungen strukturiert zu identifizieren.
Spoofing
Identitäten vortäuschen
Tampering
Daten oder Systeme manipulieren
Repudiation
Handlungen können nicht ausreichend nachvollzogen werden
Kann eine Identität manipuliert oder übernommen werden?
Welche Daten überschreiten Trust Boundaries?
Kann eine API manipuliert oder missbraucht werden?
Welche Berechtigungseskalationen sind denkbar?
Welche Komponenten beeinflussen die Verfügbarkeit des Gesamtsystems?
Sind sicherheitsrelevante Aktionen ausreichend nachvollziehbar?
Threat→Risiko→Security Requirement
Arbeitsergebnis
Was Sie erhalten
Der konkrete Lieferumfang richtet sich nach dem gewählten Paket. Nicht jedes Deliverable ist in jedem Paket enthalten.
Scope-Dokumentation
Architekturübersicht
Datenflussdarstellung
Trust Boundaries
Asset-Übersicht
dokumentierte Bedrohungen
STRIDE-Mapping, sofern eingesetzt
Risikopriorisierung
Security Requirements
Maßnahmenliste
dokumentiertes Threat Model
Management Summary
Abgrenzung
Threat Modeling oder Penetrationstest?
Threat Modeling
Fragt: „Welche Bedrohungen ergeben sich aus Architektur und Design?“
Die Analyse kann bereits vor Fertigstellung eines Systems erfolgen und unterstützt Architektur- und Entwicklungsentscheidungen.
Penetrationstest
Fragt vereinfacht: „Welche Schwachstellen können wir am implementierten System praktisch nachweisen?“
Beide Leistungen ergänzen sich. Threat Modeling ersetzt einen erforderlichen Penetrationstest nicht.
Weiterführendes Produkt
Sie benötigen mehr als ein Threat Model?
Wenn neben der Bedrohungsanalyse ein vollständiges Sicherheitskonzept mit Schutzbedarf, Risiken, Security Requirements, Maßnahmen und Dokumentation benötigt wird, ist das IT-Sicherheitskonzept das passendere Produkt.
unbekanntes System ohne verfügbare relevante Stakeholder
fertiges Threat Model ohne Architekturinformationen
Threat Modeling benötigt einen belastbaren Scope, Informationen zur Architektur und Gesprächspartner, die System und Entscheidungen erklären können.
FAQ
Kaufrelevante Fragen zu Threat Modeling
Was kostet Threat Modeling?
Threat Model Compact kostet im klar beschriebenen Compact-Scope 1.900 € netto als Festpreis. Threat Model System: ab 2.900 € netto. Threat Model Architecture: ab 4.900 € netto. Bei System und Architecture können Zahl der Systeme, Datenflüsse, Schnittstellen, Stakeholder und notwendige Analysetiefe den endgültigen Preis beeinflussen.
Wie lange dauert ein Threat-Modeling-Workshop?
Dauer und Zahl der Termine richten sich nach Paket, Scope und verfügbarer Dokumentation. Compact konzentriert sich auf einen überschaubaren Einzelscope; komplexere Systeme benötigen zusätzliche Analyse- und Abstimmungszeit. Der konkrete Ablauf wird vor Beauftragung festgelegt.
Welche Unterlagen benötigen Sie?
Hilfreich sind Architekturübersichten, Schnittstellenbeschreibungen, Betriebsmodelle, vorhandene Datenflussdiagramme sowie Informationen zu Identitäten und externen Diensten. Fehlende Darstellungen können im Workshop erarbeitet werden, erhöhen aber gegebenenfalls den Aufwand.
Müssen wir bereits ein Datenflussdiagramm haben?
Nein. Ein vorhandenes Data Flow Diagram erleichtert die Vorbereitung. Entscheidend ist, dass geeignete Stakeholder Komponenten, Datenflüsse, Schnittstellen und Vertrauensgrenzen belastbar erklären können.
Ist STRIDE immer die richtige Methode?
Nein. STRIDE ist häufig geeignet, aber kein Automatismus. Die Methodik wird passend zu System, Architektur, Scope und Fragestellung gewählt.
Kann Threat Modeling vor der Entwicklung durchgeführt werden?
Ja. Gerade in Planung und Architekturphase lassen sich Bedrohungen und Security Requirements berücksichtigen, bevor Änderungen am implementierten System aufwendig werden. Die Analyse kann später bei wesentlichen Architekturänderungen aktualisiert werden.
Können bestehende Anwendungen analysiert werden?
Ja. Auch produktive Anwendungen können anhand ihrer aktuellen Architektur, Datenflüsse und Abhängigkeiten analysiert werden. Dafür müssen aktuelle Informationen und relevante Ansprechpartner verfügbar sein.
Ist ein Penetrationstest enthalten?
Nein. Ein Penetrationstest ist eine eigenständige aktive Prüfung. Das Threat Model kann helfen, relevante Testziele und Angriffspfade für einen späteren Penetrationstest zu bestimmen.
Können unsere Entwickler am Workshop teilnehmen?
Ja. Die Beteiligung von Entwicklung, Softwarearchitektur, Product Ownern und Betrieb ist regelmäßig sinnvoll, weil diese Rollen Systementscheidungen und reale Datenflüsse erklären und Security Requirements auf Umsetzbarkeit prüfen können.
Erhalten wir eine dokumentierte Risikoliste?
In den Paketen System und Architecture werden relevante Bedrohungen bewertet und priorisiert dokumentiert. Compact enthält priorisierte Findings in einer kompakten Ergebnisdokumentation.
Können aus dem Threat Model Security Requirements abgeleitet werden?
Ja. Im Paket Compact erfolgt dies in grundlegender Form; System und Architecture enthalten explizite Security Requirements. Sie verbinden identifizierte Bedrohungen mit konkreten Anforderungen für Architektur, Entwicklung oder Betrieb.
Arbeiten Sie deutschlandweit?
Ja. Die Leistung wird deutschlandweit remote und bei Bedarf vor Ort erbracht. Niedung Advisory hat seinen Standort in Magdeburg, ist aber nicht auf einen regionalen Markt beschränkt.
Kann anschließend ein vollständiges IT-Sicherheitskonzept erstellt werden?
Ja. Wenn zusätzlich Schutzbedarf, umfassende Risikobewertung, organisatorische und technische Maßnahmen sowie eine vollständige Konzeptdokumentation benötigt werden, kann das Threat Model in ein passendes IT-Sicherheitskonzept einfließen.