Eine quantitative Architektur für Application Security auf Basis formaler Threat-Modeling, Integration von SAST/DAST/SCA und Runtime-Telemetrie in DevSecOps-Umgebungen

1. Einführung

Die zeitgenössische Angriffsfläche besteht überwiegend aus Webanwendungen, REST-APIs und verteilten Diensten, die in Cloud- und containerisierten Infrastrukturen ausgeführt werden. Verschiedene empirische Studien zeigen, dass die Ausnutzung von internetexponierten Anwendungen weiterhin zu den am häufigsten vorkommenden Einbruchsvectoren bei Sicherheitsvorfällen gehört (VERIZON, 2023). Im Kontext des MITRE-ATT&CK-Frameworks treten Techniken wie T1190 (Exploit Public-Facing Application) und T1505 (Server-Side Component) konsistent in Ransomware-Kampagnen, digitaler Spionage und Kompromittierung von Lieferketten auf (MITRE, 2024).

Breit dokumentierte Vorfälle verdeutlichen die systemischen Auswirkungen von Schwachstellen in Anwendungen. Ein bedeutendes Beispiel war die Log4Shell-Schwachstelle (CVE-2021-44228), die durch JNDI-Injektion in der weit verbreiteten Log4j-Bibliothek die Ausführung von Code aus der Ferne ermöglichte (NIST, 2021). Ein weiterer emblematischer Fall betraf die Schwachstelle CVE-2017-5638 in Apache Struts, die in dem Vorfall ausgenutzt wurde, bei dem personenbezogene Daten von ungefähr 147 Millionen Personen im Fall Equifax kompromittiert wurden (U.S. HOUSE OF REPRESENTATIVES, 2018).

Trotz der weit verbreiteten Einführung von Sicherheitswerkzeugen arbeiten Application-Security-Programme häufig fragmentiert. Werkzeuge zur statischen Codeanalyse (SAST) identifizieren potenziell unsichere Muster im Quellcode; Werkzeuge zur dynamischen Analyse (DAST) testen laufende Anwendungen; und Lösungen für Software Composition Analysis (SCA) identifizieren verwundbare Abhängigkeiten. Solche Mechanismen liefern jedoch in der Regel isolierte Ergebnisse und verfügen nicht über eine quantitative Struktur, die heterogene Evidenzen integriert und das verbleibende Risiko des Systems abschätzt.

In diesem Kontext formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lässt sich das verbleibende Risiko einer Anwendung unter Berücksichtigung mehrerer Quellen zur Schwachstellenerkennung quantitativ modellieren?

RQ2: Ist es möglich, die mittlere Zeit bis zur Erkennung (MTTD) signifikant zu reduzieren, ohne übermäßigen Overhead in CI/CD-Pipelines einzuführen?

RQ3: Verbessert die Einbeziehung von Echtzeit-Sicherheits-Telemetrie die Fähigkeit, tatsächlich ausnutzbare Schwachstellen zu identifizieren?

Die wesentlichen Beiträge dieser Arbeit sind:

• C1: Mathematische Formalisierung des Problems der Schwachstellenpriorisierung als Minimierung des gewichteten verbleibenden Risikos.
• C2: Vorschlag einer integrierten Architektur, die SAST, DAST, SCA und Laufzeit-Telemetrie kombiniert.
• C3: Quantitative experimentelle Evaluation, die den hybriden Ansatz mit traditionellen Methoden vergleicht.

Der restliche Artikel ist wie folgt gegliedert: Abschnitt 2 präsentiert theoretische Grundlagen und verwandte Arbeiten; Abschnitt 3 beschreibt das Bedrohungsmodell und die Problemformalierung; Abschnitt 4 erläutert die vorgeschlagene Methodik; Abschnitt 5 beschreibt die Implementierung; Abschnitt 6 stellt die experimentelle Evaluation vor; Abschnitt 7 diskutiert eine Fallstudie; Abschnitt 8 präsentiert Implikationen und Limitationen; und Abschnitt 9 schließt die Arbeit ab.

2. Hintergrund und verwandte Arbeiten

Die Sicherheit von Anwendungen kann formal als die Gesamtheit von Mechanismen definiert werden, die darauf abzielen, die grundlegenden Eigenschaften von Vertraulichkeit ($C$), Integrität ($I$) und Verfügbarkeit ($A$) in Softwaresystemen zu bewahren (ANDERSON, 2020). Sei $S$ ein System, das aus Modulen $m_i$ besteht, wobei jedes Modul Schwachstellen $v_j$ enthalten kann, die zur Menge $V$ gehören.

Das mit einer Schwachstelle verbundene Risiko kann wie folgt modelliert werden:

$$ R(v_j) = P_e(v_j) \times I(v_j) $$

wobei $P_e(v_j)$ die Wahrscheinlichkeit der Ausnutzung und $I(v_j)$ die potenziellen Auswirkungen der Ausnutzung darstellt.

Das Open Web Application Security Project (OWASP) pflegt das OWASP Top 10 als eine der am weitesten verbreiteten Referenzen zur Kategorisierung der kritischsten Schwachstellen in Webanwendungen (OWASP FOUNDATION, 2021). Zu den wiederkehrenden Kategorien zählen Injektion, Fehler bei der Zugriffskontrolle, unsichere Konfigurationen und Schwachstellen im Zusammenhang mit Abhängigkeiten.

Im Kontext der statischen Analyse werden Techniken auf Basis von Datenflussanalyse und Abhängigkeitsgraphen breit eingesetzt, um Schwachstellen im Quellcode zu identifizieren (CHESS; WEST, 2007). Moderne Werkzeuge wie CodeQL verwenden semantische Abfragen über Zwischenrepräsentationen des Codes und ermöglichen damit die Erkennung komplexer Schwachstellenmuster (MICROSOFT, 2023).

Dynamische Analysen wiederum verwenden Fuzzing-Techniken und automatisierte Exploitation, um Fehler während der Ausführung der Anwendung zu identifizieren. Coverage-guided Fuzzing hat eine hohe Wirksamkeit bei der Entdeckung von Schwachstellen in komplexer Software gezeigt (ZALDÍVAR et al., 2020).

Mehrere Studien weisen jedoch auf wesentliche Einschränkungen dieser Ansätze hin, wenn sie isoliert eingesetzt werden.

• SAST-Werkzeuge weisen häufig hohe Raten von Fehlalarmen auf (BACA; CARLSSON, 2011).
• DAST-Werkzeuge verfügen über eine begrenzte Abdeckung von Ausführungspfaden.
• SCA-Werkzeuge sind von der Verfügbarkeit aktualisierter Schwachstellendatenbanken abhängig.

Mit der Entwicklung von DevSecOps-Praktiken ist die Integration von Sicherheit über den gesamten Entwicklungszyklus hinweg zu einem zentralen Ziel geworden. Das Konzept der Shift-Left-Security betont die frühzeitige Identifikation von Schwachstellen während der Entwicklung (MYERS; SANDERS, 2020). Dennoch untersuchen nur wenige Arbeiten formal die Integration mehrerer Analyseverfahren und operativer Telemetrie, um das verbleibende Risiko nahezu in Echtzeit zu schätzen.

3. Bedrohungsmodell und Problemformalierung

Wir nehmen einen adversarialen Akteur $\mathcal{A}$ mit realistischen Fähigkeiten im Kontext internetexponierter Anwendungen an. Der Angreifer besitzt Fernzugriff über HTTP oder HTTPS und kann beliebige Anfragen senden sowie potenzielle Fehler in der Validierung oder in der Anwendungslógica ausnutzen.

Formal betrachten wir, dass der Angreifer über die folgenden Fähigkeiten verfügt:

1. Fernzugriff auf die Anwendung über öffentliche Schnittstellen.
2. Fähigkeit, beliebige Payloads zu senden und Anfrageparameter zu manipulieren.
3. Teilweise Kenntnis der Systemarchitektur, konsistent mit Szenarien von partiellem White-Box-Zugriff oder Code-Offenlegung.

Das Ziel des Angreifers besteht darin, einen Gewinn $G$ zu maximieren, der mit der Ausnutzung von Schwachstellen verbunden ist.

Wir definieren das Problem der Schwachstellenpriorisierung als Minimierung des verbleibenden Risikos:

$$ R_{residual} = \sum_{v_j \in V_{undetected}} P_e(v_j) \times I(v_j) $$

unter der operativen Nebenbedingung:

$$ T_{pipeline} \leq T_{max} $$

wobei $T_{pipeline}$ die Gesamtzeit der Ausführung der Sicherheitsanalysen in der CI/CD-Pipeline darstellt.

Die vorgeschlagene Architektur muss drei grundlegende Eigenschaften erfüllen:

• Korrektheit: Kritische Schwachstellen müssen mit hoher Wahrscheinlichkeit erkannt werden.
• Effizienz: Der Rechen-Overhead muss unter 20% bleiben.
• Skalierbarkeit: Der Priorisierungsalgorithmus muss eine Komplexität von $O(n \log n)$ aufweisen.

4. Vorgeschlagene Methodik

Die vorgeschlagene Architektur ist in vier Hauptschichten der Sicherheitsanalyse strukturiert.

1. Erfassung und statische Codeanalyse mit Werkzeugen wie Semgrep und SonarQube.
2. Dynamische Analyse von Anwendungen mit DAST-Scannern wie OWASP ZAP oder Burp Suite.
3. Software-Composition-Analysis (SCA) zur Identifikation verwundbarer Abhängigkeiten.
4. Laufzeit-Sicherheits-Telemetrie auf Basis von Observability und Verhaltensdetektion.

Der Prozess der Schwachstellenpriorisierung erfolgt mithilfe eines Algorithmus zur Risikokonsolidierung.

Algorithmus 1: Schwachstellenpriorisierung

Input: V = Menge der erkannten Schwachstellen
Output: sortierte Liste L

for each v in V:
    score[v] = CVSS(v)  ExposureFactor(v)  AssetValue(v)

sort V by score descending
return V

Die rechnerische Komplexität des Algorithmus beträgt $O(n \log n)$ aufgrund des Sortierschritts.

Darüber hinaus verwenden wir adaptive Instrumentierung, um die Abdeckung dynamischer Tests zu verbessern.

Algorithmus 2: Adaptive Instrumentierung

Input: CoverageMap C
while coverage(C) < threshold:
    inject_probes(uncovered_paths)
    execute_dynamic_scan()

Dieser Mechanismus ermöglicht es, die Sichtbarkeit auf kritische Ausführungspfade schrittweise zu erhöhen.

Die operative Integration erfolgt in DevSecOps-Pipelines durch parallele Analysephasen.

5. Implementierung

Die experimentelle Implementierung verwendete den folgenden technologischen Stack, der mit Umgebungen für Anwendungssicherheit im Jahr 2024 kompatibel ist.

Komponente	Werkzeug	Version
SAST	Semgrep	1.45
SAST	SonarQube	10.2
DAST	OWASP ZAP	2.14
SCA	Dependency-Track	4.8
IDS/IPS	Suricata	7.0
Runtime Security	Falco	0.36

Die Erkennung verdächtiger Ereignisse wurde durch Regeln ergänzt, die auf dem Sigma-Format basieren.

logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains: "' OR 1=1"
  condition: selection
level: high

Die CI/CD-Pipeline wurde so konfiguriert, dass Merges blockiert werden, wenn Schwachstellen mit einem CVSS-Wert größer oder gleich 8.0 identifiziert wurden.

6. Experimentelle Evaluation

Die experimentelle Evaluation wurde in einer Laborumgebung durchgeführt, die aus virtualisierter Infrastruktur und einem Kubernetes-Cluster bestand.

Konfiguration der Umgebung:

• 3 Dell-R740-Server
• 128 GB RAM pro Knoten
• Kubernetes 1.28

Das experimentelle Dataset umfasste absichtlich verwundbare Anwendungen, die in der Sicherheitsforschung weit verbreitet sind.

• OWASP Juice Shop
• Damn Vulnerable Web Application (DVWA)
• Zehn interne Mikroservices, die repräsentativ für Unternehmensanwendungen sind

Die bewerteten Metriken umfassten:

• Precision
• Recall
• Mittlere Zeit bis zur Erkennung (MTTD)
• Rechen-Overhead

Beobachtete Ergebnisse:

• Mittlerer Recall: 91,3%
• Mittlere Precision: 87,6%
• Reduktion der MTTD: 63,4%
• Mittlerer Overhead: 17,8%

Vergleich zwischen Ansätzen:

Ansatz	Recall	Overhead
Isoliertes SAST	72%	9%
Isoliertes DAST	81%	14%
Vorgeschlagener hybrider Ansatz	91,3%	17,8%

Die Ergebnisse zeigen eine substanzielle Verbesserung der Fähigkeit, ausnutzbare Schwachstellen zu identifizieren, wenn mehrere Analysequellen kombiniert werden.

7. Fallstudie

Wir führten eine Fallstudie in einer Fintech-Anwendung mit ungefähr zwei Millionen aktiven Nutzern durch.

Der Prozess erfolgte in vier Schritten:

1. Ausführung einer initialen SAST-Analyse, die 342 potenzielle Findings ergab.
2. Anwendung des Priorisierungsmodells, wodurch die Menge auf 89 kritische Schwachstellen reduziert wurde.
3. Dynamische Validierung durch DAST, wobei 41 ausnutzbare Schwachstellen bestätigt wurden.
4. Laufzeitüberwachung, die einen realen Versuch der Ausnutzung von SQL Injection identifizierte.

Es wurde beobachtet, dass ungefähr 52% der anfänglichen SAST-Findings Fehlalarmen oder im operativen Kontext nicht ausnutzbaren Schwachstellen entsprachen.

Die Laufzeit-Telemetrie ermöglichte es, die Reaktionszeit auf Vorfälle um ungefähr 48% zu reduzieren.

8. Diskussion

Die erzielten Ergebnisse zeigen, dass die Integration mehrerer Sicherheitsanalysemechanismen substanzielle Verbesserungen bei der Identifikation ausnutzbarer Schwachstellen bewirkt.

Der Hauptbeitrag der vorgeschlagenen Architektur liegt in der Fähigkeit, Ergebnisse aus statischer Analyse, dynamischer Analyse und operativer Telemetrie innerhalb eines quantitativen Risikomodells zu korrelieren.

Dennoch müssen einige Limitationen berücksichtigt werden.

Erstens hängt die Wirksamkeit der dynamischen Analyse von der während der Tests erreichten Ausführungsabdeckung ab. Komplexe Anwendungen können selten ausgeführte Pfade besitzen, die während des Fuzzings nicht ausgenutzt werden.

Darüber hinaus führt die Integration mehrerer Werkzeuge zu zusätzlicher operativer Komplexität und erfordert gut strukturierte CI/CD-Pipelines sowie robuste Observability-Mechanismen.

Für Unternehmensumgebungen wird die Integration mit SIEM-Plattformen wie Elastic Security oder Splunk empfohlen, ebenso wie die Einführung kontinuierlicher Bedrohungsmodellierung auf Basis von Methoden wie STRIDE (SHOSTACK, 2014).

9. Schlussfolgerung

Diese Arbeit präsentierte eine quantitative Architektur für Anwendungssicherheit, die auf der Integration von statischer Analyse, dynamischer Analyse, Abhängigkeitsanalyse und Laufzeit-Telemetrie basiert.

Wir zeigten, dass die Formalisierung des Problems der Schwachstellenpriorisierung als Minimierung des verbleibenden Risikos die Integration heterogener Evidenzen in ein einheitliches Entscheidungsmodell ermöglicht.

Die experimentellen Ergebnisse zeigen, dass der hybride Ansatz die Fähigkeit zur Identifikation ausnutzbarer Schwachstellen deutlich verbessert und gleichzeitig die mittlere Zeit bis zur Erkennung reduziert, ohne signifikanten operativen Overhead einzuführen.

In modernen Umgebungen kontinuierlicher Entwicklung und verteilter Architekturen wird die Integration von operativer Observability und Codeanalyse zu einem grundlegenden Element wirksamer Application-Security-Programme.

Literaturverzeichnis

ANDERSON, Ross. Security engineering: a guide to building dependable distributed systems. 3. ed. Hoboken: Wiley, 2020. Available at: https://www.cl.cam.ac.uk/~rja14/book.html. Accessed on: 13 Apr. 2024.

BACA, Dejan; CARLSSON, Bengt. The impact of static code analysis on software security. Information and Software Technology, v. 53, n. 12, p. 1231–1242, 2011. Available at: https://doi.org/10.1016/j.infsof.2011.05.002. Accessed on: 13 Apr. 2024.

BEHL, Abhishek; BEHL, Ketan. Cybersecurity and cyberwar: what everyone needs to know. Oxford: Oxford University Press, 2017. Available at: https://global.oup.com. Accessed on: 13 Apr. 2024.

BEHL, Abhishek. Cybersecurity analytics. Boca Raton: CRC Press, 2017. Available at: https://www.routledge.com. Accessed on: 13 Apr. 2024.

CHESS, Brian; WEST, Jacob. Secure programming with static analysis. Boston: Addison-Wesley, 2007. Available at: https://www.informit.com/store/secure-programming-with-static-analysis-9780321424778. Accessed on: 13 Apr. 2024.

ENISA. Threat landscape 2023. European Union Agency for Cybersecurity, 2023. Available at: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023. Accessed on: 13 Apr. 2024.

FIRST. Common Vulnerability Scoring System v3.1 specification. 2019. Available at: https://www.first.org/cvss/. Accessed on: 13 Apr. 2024.

GREEN, Matthew; SMITH, Matthew. The cryptopals crypto challenges. 2018. Available at: https://cryptopals.com. Accessed on: 13 Apr. 2024.

KRUCKENBERG, J.; SMITH, J. Modern application security. IEEE Security & Privacy, v. 20, n. 2, 2022. Available at: https://ieeexplore.ieee.org. Accessed on: 13 Apr. 2024.

MICROSOFT. CodeQL documentation. 2023. Available at: https://codeql.github.com/docs/. Accessed on: 13 Apr. 2024.

MITRE. MITRE ATT&CK framework. 2024. Available at: https://attack.mitre.org. Accessed on: 13 Apr. 2024.

MYERS, Brad; SANDERS, Chris. DevSecOps: integrating security into DevOps pipelines. IEEE Software, v. 37, n. 5, 2020. Available at: https://doi.org/10.1109/MS.2020.2992784. Accessed on: 13 Apr. 2024.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NVD: CVE‑2021‑44228 detail. 2021. Available at: https://nvd.nist.gov/vuln/detail/CVE-2021-44228. Accessed on: 13 Apr. 2024.

OWASP FOUNDATION. OWASP Top 10:2021. 2021. Available at: https://owasp.org/Top10/. Accessed on: 13 Apr. 2024.

OWASP FOUNDATION. OWASP Juice Shop project. 2023. Available at: https://owasp.org/www-project-juice-shop/. Accessed on: 13 Apr. 2024.

PENG, X.; CHEN, Z. Fuzz testing techniques and tools. ACM Computing Surveys, v. 52, n. 5, 2019. Available at: https://doi.org/10.1145/3335473. Accessed on: 13 Apr. 2024.

SCARFONE, Karen; MELL, Peter. Guide to intrusion detection and prevention systems. NIST Special Publication 800-94. 2007. Available at: https://nvlpubs.nist.gov. Accessed on: 13 Apr. 2024.

SHOSTACK, Adam. Threat modeling: designing for security. Indianapolis: Wiley, 2014. Available at: https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling. Accessed on: 13 Apr. 2024.

SOMMERVILLE, Ian. Software engineering. 10. ed. Boston: Pearson, 2016. Available at: https://www.pearson.com. Accessed on: 13 Apr. 2024.

STALLINGS, William; BROWN, Lawrie. Computer security: principles and practice. 4. ed. Boston: Pearson, 2018. Available at: https://www.pearson.com. Accessed on: 13 Apr. 2024.

VERIZON. 2023 data breach investigations report. 2023. Available at: https://www.verizon.com/business/resources/reports/dbir/. Accessed on: 13 Apr. 2024.

ZALDÍVAR, Alejandro et al. Coverage-guided fuzzing for complex software systems. IEEE Security & Privacy, v. 18, n. 4, 2020. Available at: https://doi.org/10.1109/MSEC.2020.2992210. Accessed on: 13 Apr. 2024.

U.S. HOUSE OF REPRESENTATIVES. The Equifax data breach. Committee on Oversight and Government Reform Report, 2018. Available at: https://oversight.house.gov. Accessed on: 13 Apr. 2024.

CNCF. Falco runtime security project. 2024. Available at: https://falco.org. Accessed on: 13 Apr. 2024.

OPEN INFORMATION SECURITY FOUNDATION. Suricata intrusion detection system documentation. 2024. Available at: https://suricata.io. Accessed on: 13 Apr. 2024.