Eine quantitative Application-Security-Architektur auf Basis formaler Bedrohungsmodellierung, Integration von SAST/DAST/SCA und Runtime-Telemetrie in DevSecOps-Umgebungen

1. Einleitung

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

Weitreichend dokumentierte Vorfälle verdeutlichen die systemischen Auswirkungen von Anwendungsschwachstellen. Ein bedeutendes Beispiel war die Log4Shell-Schwachstelle (CVE-2021-44228), die durch JNDI-Injektion in der weit verbreiteten Log4j-Bibliothek Remote Code Execution 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 etwa 147 Millionen Personen im Equifax-Fall kompromittiert wurden (U.S. HOUSE OF REPRESENTATIVES, 2018).

Trotz der weiten Verbreitung 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 liefern jedoch typischerweise isolierte Ergebnisse und verfügen nicht über eine quantitative Struktur, die heterogene Evidenzen integrieren und das Restrisiko des Systems abschätzen kann.

In diesem Kontext formulieren wir die folgenden Forschungsfragen:

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

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

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

Die wichtigsten Beiträge dieser Arbeit sind:

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

Der Rest des Artikels ist wie folgt aufgebaut: 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 stellt die Implementierung vor; Abschnitt 6 beschreibt die experimentelle Evaluation; Abschnitt 7 präsentiert eine Fallstudie; Abschnitt 8 erörtert Implikationen und Einschränkungen; und Abschnitt 9 schließt die Arbeit ab.

2. Hintergrund und verwandte Arbeiten

Anwendungssicherheit kann formal als die Menge von Mechanismen definiert werden, die darauf abzielen, die grundlegenden Eigenschaften 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 modelliert werden als:

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

wobei $P_e(v_j)$ die Wahrscheinlichkeit einer Ausnutzung und $I(v_j)$ die potenziellen Auswirkungen der Ausnutzung repräsentiert.

Das Open Web Application Security Project (OWASP) pflegt das OWASP Top 10 als eine der am häufigsten verwendeten Referenzen zur Kategorisierung der kritischsten Fehler in Webanwendungen (OWASP FOUNDATION, 2021). Zu den wiederkehrenden Kategorien gehören insbesondere Injection, Fehler bei der Zugriffskontrolle, unsichere Konfigurationen und abhängigkeitsbezogene Schwachstellen.

Im Kontext der statischen Analyse wurden auf Datenflussanalyse und Abhängigkeitsgraphen basierende Techniken umfassend eingesetzt, um Schwachstellen im Quellcode zu identifizieren (CHESS; WEST, 2007). Moderne Werkzeuge wie CodeQL verwenden semantische Abfragen auf intermediären Repräsentationen des Codes und ermöglichen dadurch die Erkennung komplexer Schwachstellenmuster (MICROSOFT, 2023).

Dynamische Analysen wiederum setzen Fuzzing-Techniken und automatisierte Exploration ein, um Fehler während der Ausführung der Anwendung zu identifizieren. Coverage-guided Fuzzing hat sich als äußerst wirksam bei der Entdeckung von Schwachstellen in komplexer Software erwiesen (ZALDÍVAR et al., 2020).

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

• SAST-Werkzeuge weisen häufig hohe Raten an False Positives auf (BACA; CARLSSON, 2011).
• DAST-Werkzeuge verfügen über eine begrenzte Abdeckung von Ausführungspfaden.
• SCA-Werkzeuge hängen von der Verfügbarkeit aktueller Schwachstellendatenbanken ab.

Mit der Weiterentwicklung von DevSecOps-Praktiken wurde die Integration von Sicherheit über den gesamten Entwicklungszyklus hinweg zu einem zentralen Ziel. Das Konzept der Shift-Left-Security betont die frühzeitige Identifikation von Schwachstellen während der Entwicklung (MYERS; SANDERS, 2020). Allerdings untersuchen nur wenige Arbeiten formal die Integration mehrerer Analyseverfahren und operativer Telemetrie zur Schätzung des Restrisikos in nahezu Echtzeit.

3. Bedrohungsmodell und Problemformalisierung

Wir nehmen einen Gegner $\mathcal{A}$ mit realistischen Fähigkeiten im Kontext internetexponierter Anwendungen an. Der Gegner verfügt über Remote-Zugriff via HTTP oder HTTPS und kann beliebige Anfragen senden sowie potenzielle Fehler in der Validierung oder Anwendungslogik ausnutzen.

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

1. Remote-Zugriff auf die Anwendung über öffentliche Schnittstellen.
2. Fähigkeit, beliebige Payloads zu senden und Anfrageparameter zu manipulieren.
3. Partielles Wissen über die Systemarchitektur, konsistent mit Szenarien von teilweisem White-Box-Zugriff oder Code-Offenlegung.

Das 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 Minimierung des Restrisikos:

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

unter der operativen Restriktion:

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

wobei $T_{pipeline}$ die Gesamtausführungszeit 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)$ aufweisen.

4. Vorgeschlagene Methodik

Die vorgeschlagene Architektur ist in vier Hauptschichten der Sicherheitsanalyse strukturiert.

1. Erfassung und statische Analyse von Code 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. Laufzeit-Sicherheits-Telemetrie auf Basis von Observability und Verhaltensdetektion.

Der Schwachstellenpriorisierungsprozess wird mithilfe eines Risiko-Aggregationsalgorithmus durchgeführt.

Algorithmus 1: Schwachstellenpriorisierung

Input: V = conjunto de vulnerabilidades detectadas
Output: lista ordenada L

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

sort V by score descending
return V

Die Rechenkomplexitä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 kritischer Ausführungspfade schrittweise zu erhöhen.

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

5. Implementierung

Die experimentelle Implementierung verwendete den folgenden, mit Sicherheitsumgebungen für Anwendungen im Jahr 2024 kompatiblen Technologiestack.

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-Standard 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, 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.

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

Die bewerteten Metriken umfassten:

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

Beobachtete Ergebnisse:

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

Vergleich der Ansätze:

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 etwa zwei Millionen aktiven Nutzern durch.

Der Prozess erfolgte in vier Schritten:

1. Ausfü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 einer SQL-Injection identifizierte.

Es zeigte sich, dass etwa 52% der anfänglichen SAST-Befunde False Positives oder im operativen Kontext nicht ausnutzbare Schwachstellen darstellten.

Die Laufzeit-Telemetrie ermöglichte eine Reduktion der Reaktionszeit auf Vorfälle um etwa 48%.

8. Diskussion

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

Der wesentliche Beitrag 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 besitzen, die während des Fuzzings unentdeckt bleiben.

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 Restrisikos 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 signifikant verbessert und gleichzeitig die mittlere Erkennungszeit reduziert, ohne einen 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 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.