Wie passt Threat Modeling in die schnelle DevSecOps-Welt?

Bei DevSecOps geht es darum, schneller hochwertige Software bereitzustellen. Dem Threat-Modeling-Prozess haftet jedoch der Ruf an, zeitaufwendig und komplex zu sein – viele Unternehmen glauben, dass er den Softwareentwicklungslebenszyklus (SDLC) verlangsamt. Wie lassen sich beide Ansätze verbinden, um die Sicherheitsvorteile von Threat Modeling zu nutzen, ohne den Softwareentwicklungsprozess auszubremsen?

In diesem Blogbeitrag erfahren Sie mehr über Threat Modeling und wie es sich ganz natürlich in den DevSecOps-Prozess einfügt.

Was ist Threat Modeling?

Beim Threat Modeling werden der Entwurf von Systemabläufen und der Datenfluss über Subsystemgrenzen hinweg untersucht. Anschließend werden alle Angriffspunkte identifiziert, die Hacker ausnutzen könnten, und es wird untersucht, wie sie dabei vorgehen könnten. Abschließend werden Lösungen entwickelt, die das System und seine Daten schützen.

Laut dem führenden Experten Adam Shostack wirft der Threat-Modeling-Prozess folgende Fragen auf:

• Was entwickeln wir? Untersuchen Sie, wie Daten durch ein System fließen, welche Grenzen sie überschreiten und welche Technologie bei jeder Übergabe zum Einsatz kommt.

• Was kann schiefgehen? Hinterfragen Sie alle möglichen Wege, die Übergaben auszunutzen.

• Was unternehmen wir dagegen? Entwickeln Sie Abwehrmaßnahmen gegen jeden Exploit.

• Haben wir gute Arbeit geleistet? Die letzte und wichtigste Frage regt dazu an, den Prozess zu reflektieren und zu überprüfen. Sie erinnert uns daran, dass die Arbeit nie wirklich abgeschlossen ist: Es gibt immer Raum für Verbesserungen.

Das Team priorisiert anschließend die Bedrohungsrisiken und berücksichtigt sie bei der Entwicklung.

Wann sollten Sie Threat Modeling durchführen?

Der ideale Zeitpunkt für Threat Modeling sind die frühesten Phasen des SDLC, während der Architekturphase der Anwendungsentwicklung. Je früher Sie Bedrohungen identifizieren, desto effizienter können Sie Lösungen entwickeln, um Angriffsvektoren abzuwehren.

Am besten wird Sicherheit von Anfang an in die Anwendung integriert. Doch es ist nie zu spät, von Threat Modeling zu profitieren – auch bei Legacy-Anwendungen. Eine solche Übung kann für alle Beteiligten wertvoll sein, unabhängig davon, wann sie im SDLC stattfindet.

Die Geschichte des Threat Modeling

Die ersten Ansätze für Threat Modeling entstanden in den 1990er-Jahren mit dem Konzept der Angriffsbäume. Daraufhin verbreiteten Loren Kohnfelder und Prerit Garg von Microsoft ein Dokument mit dem Titel „The Threats to Our Products“, das weithin als erste formelle Beschreibung eines Threat-Modeling-Prozesses gilt.

Seitdem orientiert sich die Branche an Organisationen wie dem Open Web Application Security Project (OWASP), das die wichtigsten Bedrohungen bewertet, beschreibt und Empfehlungen zu Gegenmaßnahmen gibt. OWASP hat außerdem eine ähnliche Bedrohungsanalyse für die digitale API-Sicherheit veröffentlicht, um APIs von Software-as-a-Service-Anbietern (SaaS) abzudecken.

Und heute, da bei Unternehmen wie Yahoo, Uber und First American Financial Millionen von Nutzerdatensätzen von Hackern gestohlen wurden, muss sich jedes Unternehmen der digitalen Bedrohungen bewusst sein. Die Sicherheitsberichte von 2020 zeichnen ein alarmierendes Bild:

• Im Jahr 2020 wurden weit über 18.000 Schwachstellen erfasst. Fast ein Viertel davon war als schwerwiegend eingestuft.

• Unternehmen zahlten durchschnittlich 3,86 Millionen US-Dollar für die Behebung einer Datenschutzverletzung.

• Malware- und Ransomware-Angriffe nahmen um 358 % bzw. 435 % zu.

Tipps zum Threat Modeling

Der Threat-Modeling-Prozess kann sehr komplex sein. Ein bewährter Ansatz, die STRIDE-Methodik, empfiehlt für jeden wichtigen Angriffstyp eine separate technische Analyse:

• Spoofing: Umgehen der Authentifizierung durch eine Form der Identitätstäuschung.

• Tampering: Manipulation des Systems, die weitere Exploits ermöglicht.

• Repudiation: Umgehen der Erkennung, indem Angriffsspuren verborgen oder Protokolle so gefälscht werden, dass sie während eines Angriffs normal wirken. So wird die Absicht verschleiert und der Angriff kann fortgesetzt werden.

• Information Disclosure: Verletzung der Vertraulichkeit durch Wege, sensible Daten aus beliebigen Bereichen des Systems auszulesen.

• Denial of Service (DoS): Einschränkung des Systemzugriffs für Benutzer, indem die für den ordnungsgemäßen Betrieb benötigten Ressourcen gezielt erschöpft werden.

• Elevation of Privilege: Umgehen der Autorisierung, indem das System dazu gebracht wird, einem Konto mehr Berechtigungen zu erteilen und so einen tieferen Zugriff auf das System zu ermöglichen.

Datenflussdiagramme (DFDs), STRIDE und neuere vergleichbare Methoden bieten einen Rahmen, um Fragen wie diese zu beantworten:

• „Was entwickeln wir?“ DFDs bieten eine Möglichkeit, das System und seine verschiedenen Vertrauensgrenzen darzustellen – als ersten Schritt zum Verständnis von Sicherheitsbedrohungen.

• „Was kann schiefgehen?“ STRIDE konzentriert sich auf diese Frage und untersucht anhand des Systemaufbaus jeden Angriffstyp.

So nutzte beispielsweise ein Denial-of-Service-Angriff auf den Kubernetes-API-Server im Jahr 2019 eine Schwachstelle aus, über die riesige Datenmengen in die API-„Payload“ eingespeist werden konnten, was das System überlastete.

Zu den Maßnahmen zur Eindämmung der Bedrohung gehörten:

• Begrenzung der Payload-Größe für jeden Aufruf

• Begrenzung der API-Aufrufe pro Benutzer oder IP-Adresse

Damit ließen sich künftige DoS-Angriffe auf den API-Server abwehren.

Solche Maßnahmen erfordern eine gründliche Untersuchung der Systemfunktionen und müssen für jeden Angriffstyp durchgeführt werden. Lösungen sind möglich, benötigen aber Zeit für Recherche, Entwurf, Entwicklung, Tests und Bereitstellung.

Warum traditionelles Threat Modeling DevSecOps vor Herausforderungen stellt

Traditionelles Threat Modeling erfordert Analysesitzungen mit allen Beteiligten, darunter IT-Fachleute und Cybersicherheitsexperten. Bei diesen Sitzungen werden umfangreiches Wissen und Erkenntnisse über Bedrohungen und Gegenmaßnahmen ausgetauscht, was alle Beteiligten wertvoll finden.

Die Sitzungen selbst sind jedoch zeitaufwendig und können viele Personen tagelang binden. Deshalb lassen sie sich nicht vor jedem Sprint ansetzen. Solche Sitzungen stehen im Widerspruch zur DevSecOps-Kultur, bei der es darum geht, den Softwareentwicklungslebenszyklus zu beschleunigen.

Beliebte DevOps-Trends zur Beschleunigung der Entwicklung:

• Automatisierung und Tests im Build-Pipeline-Prozess so früh wie möglich vorantreiben („Shift Left“).

• Automatisierung betrifft nicht nur Anwendungscode, sondern auch die Systeminfrastruktur. Neue Technologien ermöglichen es, Infrastruktur als Code zu definieren und dadurch testbar zu machen.

• Diese Automatisierung beschleunigt Continuous Integration/Continuous Delivery (CI/CD). So lassen sich Funktionen und Fehlerbehebungen häufiger und mit größerer Zuversicht bereitstellen.

Das Ergebnis: Die Softwareentwicklung wird immer schneller. Manche Teams stellen alle zwei bis vier Wochen neuen Code in der Produktionsumgebung bereit. Wie bleibt bei diesem Tempo Zeit für lange Sicherheitssitzungen?

Team-Schulungen zu Threat Modeling als Grundlage für DevOps-Prozesse

Schulungen sind entscheidend, um ein Threat-Modeling-Mindset in den sicheren SDLC einzubringen, wie der Sicherheitsexperte von IBM Brandon Jeanmarie betont. Umfangreiche, lange Sitzungen können jedoch nicht häufig stattfinden. Deshalb empfiehlt er einen „Just-in-time“-Ansatz, um Mitglieder des Entwicklungsteams bei der Arbeit mit Kunden zu schulen:

• Threat Modeling ist leicht verständlich: Nutzen Sie Gelegenheiten, das Thema für Entwickler und Manager aufzuschlüsseln. So verstehen sie, was möglich ist, und können dort, wo sie gerade stehen, „jetzt“ mit der Systementwicklung beginnen.

• Alle Beteiligten am System profitieren von Schulungen: Vermitteln Sie Threat Modeling so, dass es zur jeweiligen Rolle im Team passt. Mit diesem Wissen können alle an der Lösungsfindung bei der Sprint-Planung mitwirken und entsprechend priorisieren.

• Auch Schulungen lassen sich „nach links verschieben“: Sorgen Sie dafür, dass das Bewusstsein für Threat Modeling so früh wie möglich in die Pipeline gelangt. Das fördert gute DevSecOps-Praktiken und ermöglicht, Bedrohungen so früh wie möglich zu identifizieren und einzudämmen.

• Threat-Modeling-Tools können den Prozess „nach rechts erweitern“: Tools von Drittanbietern ermöglichen eine automatische Erkennung von Bedrohungen und die Automatisierung von Gegenmaßnahmen in späteren SDLC-Phasen – auch in der Produktionsumgebung, wo sie das System weiterhin schützen können.

Jeanmarie kommt zu dem Schluss, dass situations- und rollenbezogene Schulungen zu einem „Secure-by-Design“-Mindset führen, das die DevSecOps-Kultur eines Unternehmens stärkt. Dafür sind keine häufigen, umfangreichen Sitzungen nötig. Sobald dieses Wissen Teil der Unternehmenskultur ist, kann jeder mithelfen, wenn es darum geht, Bedrohungen einzudämmen.

4 Schritte, um Threat Modeling in die Gestaltung agiler User Stories einzubinden

Die Security-Expertin Alyssa Miller denkt Threat Modeling noch einen Schritt weiter „nach links“. Sie untersuchte, wie sich Threat Modeling besser in DevSecOps integrieren lässt. Ihr Vorschlag:

Beschränken Sie den Umfang des Threat Modeling auf die Anforderungen jeder User Story. Weiter „nach links“ lässt sich DevSecOps kaum verschieben.

Dazu wird der Business-Anwender in das Gespräch zur Analyse der Story einbezogen. Das funktioniert, weil die Anforderungen der Story den technischen Details vorgelagert sind. Stellen Sie dem Business-Anwender folgende Fragen:

• Welche wichtigen Assets sind an der neuen Funktion beteiligt?

• Was ist das Schlimmste, das jedem wichtigen Asset passieren könnte?

Aus dem Gespräch ergeben sich ganz natürlich Sicherheitsanforderungen, die in die Story aufgenommen werden. Sie werden in einfacher Sprache formuliert, die jeder versteht, zum Beispiel:

• Die kritischen Funktionen F1 und F2 müssen vor unbefugter Nutzung geschützt werden.

• Private Daten XYZ müssen vor Offenlegung geschützt werden.

• Die Geldtransaktion für den Kauf P muss während der Übertragung vor Diebstahl geschützt werden.

Diese in einfacher Sprache formulierten Aussagen werden in die Story aufgenommen und lösen anschließend eine Kaskade von Aktivitäten in der nachgelagerten Entwicklungspipeline aus.

Durch diese Umgestaltung des Threat-Modeling-Prozesses konnte sie ihn prägnanter definieren: „Die wahrscheinlichen Bedrohungen eines Systems identifizieren, um die Entwicklung von Sicherheitsmaßnahmen zu unterstützen.“

Miller ist überzeugt, dass dadurch die DevSecOps-Kultur in die früheste Phase des SDLC verlagert wird und das gesamte Entwicklungsteam dazu befähigt, situationsbezogenes Threat Modeling in das übergeordnete Ziel der kontinuierlichen Verbesserung einzubinden. Möglich wird dies, weil alle ein Sicherheitsbewusstsein entwickeln und dieses in Sprint-Planungssitzungen und alle nachgelagerten Aktivitäten einbringen:

1. Planen: Sicherheitsanforderungen in die Story aufnehmen.

2. Entwickeln: Maßnahmen zur Bedrohungseindämmung (Sicherheitskontrollen) in den SDLC integrieren.

3. Testen: Stories mit Anwendungsfällen zur Bedrohungseindämmung schreiben und daraus Testfälle erstellen.

4. Bereitstellen: Überwachungsmechanismen erstellen, die die Testfälle umsetzen, und Alarme dafür einrichten.

Miller kommt zu dem Schluss, dass sich Threat Modeling durch diesen Prozess integrieren lässt, ohne das Tempo von DevSecOps zu bremsen.

Fazit

In der DevSecOps-Kultur geht es darum, den SDLC in Abschnitte zu unterteilen, die automatisiert werden können, um die Qualität früh im Zyklus „nach links zu verschieben“ und mit Tools den gesamten Softwarebereitstellungsprozess „nach rechts zu erweitern“. Wenn das gesamte Team über Threat Modeling und dessen Integration in den SDLC – beginnend bei den Anforderungen – geschult wird, kann das Bewusstsein für Bedrohungen jeden Schritt von DevSecOps durchdringen und prägen.