TITEL: Eine quantitative Application-Security-Architektur auf Basis formaler Bedrohungsmodellierung, 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. Mehrere empirische Studien zeigen, dass die Ausnutzung internetexponierter Anwendungen weiterhin zu den häufigsten Eindringvektoren 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 Angriffen auf Lieferketten auf (MITRE, 2024).

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

Trotz der breiten 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 zur Software Composition Analysis (SCA) identifizieren verwundbare Abhängigkeiten. Solche Mechanismen erzeugen jedoch in der Regel isolierte Ergebnisse und verfügen über keine quantitative Struktur, die heterogene Evidenzen integrieren und das verbleibende Risiko des Systems abschätzen könnte.

In diesem Kontext formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lässt sich das verbleibende Risiko einer Anwendung quantitativ modellieren, wenn mehrere Quellen zur Schwachstellenerkennung berücksichtigt werden?

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

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

Die Hauptbeiträ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 Rest des Artikels ist wie folgt gegliedert: Abschnitt 2 präsentiert theoretische Grundlagen und verwandte Arbeiten; Abschnitt 3 beschreibt das Bedrohungsmodell und die Problemformalisierung; 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 Einschränkungen; und Abschnitt 9 schließt die Arbeit ab.

2. Hintergrund und verwandte Arbeiten

Anwendungssicherheit kann formal als die Gesamtheit der 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 aus Modulen $m_i$ zusammengesetztes System, wobei jedes Modul Schwachstellen $v_j$ enthalten kann, die der Menge $V$ angehören.

Das mit einer Schwachstelle verbundene Risiko kann modelliert werden als:

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

wobei $P_e(v_j)$ die Exploit-Wahrscheinlichkeit und $I(v_j)$ die potenzielle Auswirkung der Ausnutzung darstellt.

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

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

Dynamische Analysen wiederum verwenden Fuzzing-Techniken und automatisierte Ausnutzung, um Fehler während der Ausführung der Anwendung zu identifizieren. Coverage-gesteuertes 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 an False Positives auf (BACA; CARLSSON, 2011).
• DAST-Werkzeuge besitzen eine begrenzte Abdeckung von Ausführungspfaden.
• SCA-Werkzeuge sind von der Verfügbarkeit aktueller 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 zur Schätzung des verbleibenden Risikos in nahezu Echtzeit.

3. Bedrohungsmodell und Problemformalisierung

Wir nehmen einen Gegner $\mathcal{A}$ mit realistischen Fähigkeiten im Kontext internetexponierter Anwendungen an. Der Gegner besitzt entfernten Zugriff über HTTP oder HTTPS und kann beliebige Anfragen senden sowie potenzielle Validierungs- oder Anwendungslogikfehler ausnutzen.

Formal betrachten wir, dass der Gegner die folgenden Fähigkeiten besitzt:

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 Quellcode-Offenlegung.

Ziel des Gegners ist es, einen Gewinn $G$ zu maximieren, der mit der Ausnutzung von Schwachstellen verbunden ist.

Wir definieren das Problem der Schwachstellenpriorisierung als die 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 die Komplexität $O(n \log n)$ besitzen.

4. Vorgeschlagene Methodik

Die vorgeschlagene Architektur ist in vier Hauptschichten der Sicherheitsanalyse strukturiert.

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

Der Priorisierungsprozess von Schwachstellen erfolgt mittels eines Risikoaggregationsalgorithmus.

Algorithmus 1: Schwachstellenpriorisierung

Input: V = Menge der erkannten Schwachstellen
Output: geordnete 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 Application-Security-Umgebungen 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 auf Basis des Sigma-Standards ergänzt.

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, falls Schwachstellen mit einem CVSS-Score größer oder gleich 8.0 identifiziert werden.

6. Experimentelle Evaluation

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

Umgebungskonfiguration:

• 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 Microservices, die für Unternehmensanwendungen repräsentativ sind

Die evaluierten Metriken umfassten:

• Precision
• Recall
• Mittlere Erkennungszeit (MTTD)
• Rechen-Overhead

Beobachtete Ergebnisse:

• Mittlerer Recall: 91,3%
• Mittlere Precision: 87,6%
• MTTD-Reduktion: 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 weisen auf eine deutliche Verbesserung der Fähigkeit hin, 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. Durchführung einer initialen SAST-Analyse, die 342 potenzielle Befunde ergab.
2. Anwendung des Priorisierungsmodells, wodurch die Menge auf 89 kritische Schwachstellen reduziert wurde.
3. Dynamische Validierung mittels DAST, wodurch 41 ausnutzbare Schwachstellen bestätigt wurden.
4. Laufzeitüberwachung, die einen realen Versuch zur Ausnutzung von SQL Injection identifizierte.

Es wurde beobachtet, dass ungefähr 52% der anfänglichen SAST-Befunde False Positives oder im operativen Kontext nicht ausnutzbare Schwachstellen darstellten.

Die Laufzeit-Telemetrie ermöglichte eine Reduzierung der Reaktionszeit auf Vorfälle um ungefähr 48%.

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 Einschränkungen 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 aufweisen, 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 Grundlage von Methoden wie STRIDE (SHOSTACK, 2014).

9. Schlussfolgerung

Diese Arbeit präsentierte eine quantitative Architektur für Anwendungssicherheit, die auf der Integration 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 vereinheitlichtes Entscheidungsmodell ermöglicht.

Die experimentellen Ergebnisse zeigen, dass der hybride Ansatz die Fähigkeit, ausnutzbare Schwachstellen zu identifizieren, signifikant verbessert und gleichzeitig die mittlere Erkennungszeit 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 für wirksame Application-Security-Programme.

References

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 abr. 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 abr. 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 abr. 2024.

BEHL, Abhishek. Cybersecurity analytics. Boca Raton: CRC Press, 2017. Available at: https://www.routledge.com. Accessed on: 13 abr. 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 abr. 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 abr. 2024.

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

GREEN, Matthew; SMITH, Matthew. The cryptopals crypto challenges. 2018. Available at: https://cryptopals.com. Accessed on: 13 abr. 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 abr. 2024.

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

MITRE. MITRE ATT&CK framework. 2024. Available at: https://attack.mitre.org. Accessed on: 13 abr. 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 abr. 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 abr. 2024.

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

OWASP FOUNDATION. OWASP Juice Shop project. 2023. Available at: https://owasp.org/www-project-juice-shop/. Accessed on: 13 abr. 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 abr. 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 abr. 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 abr. 2024.

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

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

VERIZON. 2023 data breach investigations report. 2023. Available at: https://www.verizon.com/business/resources/reports/dbir/. Accessed on: 13 abr. 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 abr. 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 abr. 2024.

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

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