HKHiago Kin Levi
← Zurück zu den Papers

Paper Files / AppSec

TITEL: Eine formale und operative Architektur für bedrohungsorientiertes AppSec: Integration von SAST, DAST, SCA, Runtime-Telemetrie und ATT&CK-Intelligenz zur risikobasierten Priorisierung ausnutzbarer Risiken

AppSecDE

TITEL: Eine formale und operative Architektur für bedrohungsorientiertes AppSec: Integration von SAST, DAST, SCA, Runtime-Telemetrie und ATT&CK-Intelligenz zur risikobasierten Priorisierung ausnutzbarer Risiken ABSTRAKT: Die Angriffsfläche moderner Anwendungen hat sich mit der Einführung von Architekturen auf Basis von Microservices, APIs, Containern und Continuous-Integration- und Continuous-Delivery-Pipelines erheblich erweitert. Obwohl Anwendungssicherheitswerkzeuge wie Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST) und Software Composition Analysis (SCA) weit verbreitet eingesetzt werden, arbeiten diese Mechanismen häufig isoliert und erzeugen große Mengen an Warnmeldungen, denen die operative Kontextualisierung fehlt. Infolgedessen stehen Sicherheitsteams vor Schwierigkeiten, Schwachstellen auf Grundlage der tatsächlichen Wahrscheinlichkeit einer Ausnutzung zu priorisieren. In dieser Arbeit प्रस्तुत/ präsentieren wir eine formale und operative Architektur für bedrohungsorientierte Anwendungssicherheit, die Ergebnisse aus SAST, DAST und SCA mit Laufzeittelemetrie integriert, die zur Ausführungszeit mittels Netzwerksensoren und eBPF-basierter Überwachung erfasst wird. Die vorgeschlagene Architektur nutzt eine von bayesschen Modellen inspirierte probabilistische Korrelation, um das ausnutzbare Risiko identifizierter Schwachstellen zu schätzen, indem empirische Evidenzen aus beobachteten Ereignissen im Runtime-Betrieb einbezogen und diese Evidenzen auf das MITRE ATT&CK-Framework abgebildet werden. Wir formalisieren mathematisch den Begriff des ausnutzbaren Risikos und zeigen, wie mehrere Evidenzquellen kombiniert werden können, um Fehlalarme zu reduzieren und die Priorisierung von Abhilfemaßnahmen zu verbessern. Die experimentelle Implementierung wurde in einer Kubernetes-Umgebung mit Integration in eine CI/CD-Pipeline durchgeführt und verwendete in der Industrie weit verbreitete Werkzeuge, darunter Semgrep, OWASP ZAP, OWASP Dependency-Check, Falco und Suricata. Wir bewerteten den Ansatz anhand einer Menge verwundbarer Anwendungen und beobachteten signifikante Verbesserungen bei der Genauigkeit der Identifizierung ausnutzbarer Schwachstellen. Die experimentellen Ergebnisse zeigen eine Erhöhung des F1-Scores von 0,67–0,63 bei isolierten Ansätzen auf 0,85 im integrierten Modell sowie eine Reduktion der False Positives um 37,4 % und eine Verringerung der durchschnittlichen Triagierungszeit für Schwachstellen. Wir diskutieren die Grenzen des probabilistischen Modells, operative Implikationen für DevSecOps-Praktiken und mögliche Erweiterungen, einschließlich der Integration mit Ausnutzungsmetriken wie EPSS und maschinengestützter Analyse zur adaptiven Priorisierung. Die vorgeschlagene Architektur zeigt, dass die Korrelation zwischen statischer Analyse, dynamischen Tests, Abhängigkeitsanalyse und operativer Telemetrie einen vielversprechenden Weg darstellt, um die Lücke zwischen der Erkennung von Schwachstellen und der Erkennung tatsächlicher Ausnutzung zu verringern.

  1. Einführung

Die Angriffsfläche moderner Anwendungen hat sich mit der Verbreitung verteilter Architekturen auf Basis von Microservices, REST-APIs, Containern und automatisierten Continuous-Integration- und Continuous-Delivery-(CI/CD)-Pipelines erheblich erweitert. In diesem Szenario werden Anwendungen zu hochdynamischen Systemen, die aus mehreren voneinander abhängigen Komponenten bestehen und häufig in Cloud-Umgebungen bereitgestellt sowie durch Plattformen wie Kubernetes orchestriert werden. Dieser architektonische Wandel hat die Komplexität des Anwendungs-Sicherheitsmanagements erhöht und neue Ausnutzungspfade eingeführt (BEHL; BEHL, 2017).

Aktuelle Berichte zeigen, dass Webanwendungen weiterhin zu den wichtigsten Kompromittierungsvektoren bei Sicherheitsvorfällen zählen. Der Verizon Data Breach Investigations Report weist darauf hin, dass die Ausnutzung von Schwachstellen in öffentlichen Anwendungen eine wiederkehrende Technik in Angriffskampagnen bleibt (VERIZON, 2023). Darüber hinaus haben weithin bekannte Vorfälle — wie Log4Shell (CVE-2021-44228) — gezeigt, dass Schwachstellen in weit verbreiteten Bibliotheken systemische Auswirkungen in globalem Maßstab verursachen können (CHEN et al., 2022).

Im Kontext des MITRE-ATT&CK-Frameworks stehen mehrere Techniken in direktem Zusammenhang mit der Ausnutzung von Anwendungen. Hervorzuheben sind T1190 (Exploit Public-Facing Application), T1059 (Command and Scripting Interpreter) und T1195 (Supply Chain Compromise), die häufig in den frühen Phasen von Angriffsketten beobachtet werden (MITRE, 2024). Dennoch arbeiten traditionelle Werkzeuge der Anwendungssicherheit überwiegend isoliert.

Werkzeuge der statischen Analyse (SAST) untersuchen den Quellcode auf Schwachstellenmuster. Werkzeuge für dynamische Tests (DAST) führen simulierte Angriffe gegen laufende Anwendungen aus. Werkzeuge zur Software-Kompositionsanalyse (SCA) identifizieren verwundbare Abhängigkeiten in Bibliotheken von Drittanbietern. Obwohl jeder Ansatz relevante Hinweise liefert, führt das Fehlen einer systematischen Korrelation zwischen diesen Quellen zu einer großen Menge an Warnungen und erschwert die Priorisierung von Gegenmaßnahmen.

Das zentrale Problem, das in dieser Arbeit untersucht wird, ist die strukturelle Fragmentierung zwischen Mechanismen zur Erkennung von Schwachstellen und Mechanismen zur Beobachtung tatsächlicher Ausnutzung. In Unternehmensumgebungen ist es üblich, dass wöchentlich Tausende von Warnungen durch SAST- und SCA-Werkzeuge erzeugt werden, während DAST-Tests zusätzliche Ergebnisse liefern, die nicht immer mit in der Produktion beobachteten Ereignissen korreliert werden.

Ausgehend von dieser Lücke formulieren wir die folgenden Forschungsfragen:

RQ1: Wie lassen sich mehrere Quellen von Evidenz zur Anwendungssicherheit formal konsistent und quantitativ messbar integrieren?

RQ2: Ist es möglich, Fehlalarme zu reduzieren und potenziell ausnutzbare Schwachstellen durch Korrelation mit in Runtime beobachteter Telemetrie zu priorisieren?

RQ3: Welchen betrieblichen Einfluss hat diese Integration auf die Effizienz von Triage und Mitigation von Schwachstellen?

Die Hauptbeiträge dieser Arbeit sind:

  1. Hintergrund und verwandte Arbeiten

2.1 Statische Anwendungssicherheitstests

Die statische Sicherheitsanalyse basiert auf der Inspektion von Code ohne Ausführung des Programms. Formal stellen wir den Ausführungsfluss durch einen gerichteten Graphen $G = (V, E)$ dar, wobei $V$ Instruktionen oder Basikblöcke und $E$ Kontrollübergänge repräsentiert.

Injection-Schwachstellen können als Datenflusswege zwischen nicht vertrauenswürdigen Quellen $S$ und sensiblen Senken $K$ modelliert werden:

$$ \exists ; path(S_i \rightarrow K_j) \land \neg sanitized(S_i) $$

Moderne Werkzeuge wie Semgrep und SonarQube verwenden semantische, musterbasierte Analyse und deklarative Regeln, um solche Pfade zu erkennen (OWASP, 2023).

2.2 Dynamische Anwendungssicherheitstests

DAST führt aktive Tests gegen laufende Anwendungen aus, um zur Laufzeit verwundbares Verhalten zu identifizieren. Werkzeuge wie OWASP ZAP und Burp Suite führen Fuzzing von HTTP-Parametern, Manipulation von Payloads und Analyse der Serverantworten durch.

Studien zeigen, dass DAST besonders wirksam bei der Identifikation von Schwachstellen im Zusammenhang mit Konfiguration, Authentifizierung und Eingabevalidierung ist (SCANDARIATO et al., 2013).

2.3 Software Composition Analysis

Ein großer Teil moderner Software hängt von externen Bibliotheken ab. Folglich können Schwachstellen in Abhängigkeiten Anwendungen beeinträchtigen, selbst wenn der eigene Code keine direkten Fehler enthält.

Die Erstellung eines Software Bill of Materials (SBOM) ist nach staatlichen Initiativen zur Verbesserung der Sicherheit der Lieferkette zu einer empfohlenen Praxis geworden (NIST, 2021). SCA-Werkzeuge analysieren Abhängigkeiten und korrelieren Versionen mit Schwachstellendatenbanken wie NVD.

2.4 Runtime-Telemetrie und eBPF

In den letzten Jahren sind eBPF-basierte Sensoren in Linux-Umgebungen weit verbreitet für Observability und Sicherheit geworden. Werkzeuge wie Falco verwenden eBPF, um Systemaufrufe zu überwachen und anomales Verhalten zu erkennen (FALCO, 2024).

Gleichzeitig ermöglichen Netzwerkintrusionserkennungssysteme wie Suricata die Identifikation von Ausnutzungsmustern im Netzwerkverkehr (OISF, 2023).

2.5 Grenzen aktueller Ansätze

Mehrere Studien weisen auf Grenzen bei der Priorisierung von Schwachstellen hin, wenn diese ausschließlich auf der CVSS-Schwere basieren (BOHANNON; HOLMES, 2022). Probabilistische Metriken wie EPSS wurden vorgeschlagen, um die Exploit-Wahrscheinlichkeit zu schätzen, integrieren jedoch bislang keine beobachtenden Runtime-Evidenzen.

Unser Ansatz zielt darauf ab, diese Lücke durch probabilistische Korrelation zwischen mehreren Evidenzquellen zu schließen.

  1. Bedrohungsmodell und Problemformalisierung

Wir nehmen einen externen Angreifer mit der Fähigkeit an, Folgendes zu tun:

Wir definieren das ausnutzbare Risiko $R_e$ als:

$$ R_e = P(E \mid V, T, C) \cdot I $$

wobei:

Die Exploit-Wahrscheinlichkeit wird mittels Bayes’scher Inferenz geschätzt:

$$ P(E|V,T) = \frac{P(T|E,V)P(E|V)}{P(T|V)} $$

Die Sicherheitsrichtlinie legt einen Schwellenwert $\theta$ fest, sodass Schwachstellen mit $R_e > \theta$ für eine sofortige Behebung priorisiert werden müssen.

  1. Vorgeschlagene Methodik

Die vorgeschlagene Architektur besteht aus vier Hauptschichten.

Schicht Funktion Beispiele für Werkzeuge
Erfassung Ausführung von Scannern und Sammlung von Ereignissen Semgrep, ZAP, Dependency-Check, Falco
Normalisierung Standardisierung von Daten JSON Schema, SBOM CycloneDX
Korrelation Probabilistische Inferenz Bayes’sche Engine
Priorisierung Erstellung einer Risikorangliste SIEM-Integration

Korrelationsalgorithmus:

Input: SAST-, DAST-, SCA-Ergebnisse und Runtime-Ereignisse
Output: priorisierte Liste von Schwachstellen

for each vulnerability v:
    s1 = score_sast(v)
    s2 = score_dast(v)
    s3 = score_sca(v)
    t  = evidencias_runtime(v)

    p_exploit = modelo_bayesiano(s1, s2, s3, t)
    risiko = impacto(v)  p_exploit

    add(v, risiko)

sort_list_by_risk()
return_list()

Die dominierende Komplexität liegt in der Sortierphase und ergibt $O(n \log n)$.

  1. Implementierung

Die Architektur wurde in einer Kubernetes-Umgebung mit direkter Integration in die CI/CD-Pipeline implementiert.

Verwendete Pipeline:

Beispiel einer Falco-Regel:

- rule: Reverse Shell Detection
  desc: Detecta execução de shell com conexão externa
  condition: spawned_process and proc.name=bash and outbound
  output: Possível reverse shell detectado
  priority: CRITICAL

Ereignisse werden zur Korrelation und Indexierung an den Elastic Stack gesendet.

  1. Experimentelle Bewertung

Die experimentelle Bewertung wurde auf einer Infrastruktur durchgeführt, die aus drei Dell PowerEdge R740-Servern bestand, auf denen Kubernetes 1.27 lief.

Parameter Wert
Speicher pro Knoten 128 GB
Gesamt-CPU 96 vCPUs
Getestete Anwendungen 32
Bekannte Schwachstellen 187

Die verwendeten Metriken waren Precision, Recall und F1-Score.

Methode Precision Recall F1-Score
Isoliertes SAST 0.61 0.74 0.67
Isoliertes DAST 0.68 0.59 0.63
Vorgeschlagene Architektur 0.84 0.86 0.85

Wir beobachteten eine Reduktion der Fehlalarme um 37,4 % und eine Verringerung der durchschnittlichen Triage-Zeit von 4,2 Stunden auf 3,0 Stunden.

  1. Fallstudie

Wir verwendeten die verwundbare Anwendung OWASP Juice Shop, um das Modell zu validieren.

Beobachteter Ablauf:

  1. SAST erkannte einen nicht bereinigten Datenfluss.
  2. DAST bestätigte die Ausnutzung mittels SQL-Injection-Payload.
  3. Suricata identifizierte die Signatur eines SQLi-Angriffs.
  4. Falco erkannte eine anomale Ausführung nach simulierter Ausnutzung.

Das Modell ordnete eine Exploit-Wahrscheinlichkeit von 0,87 zu und stufte die Schwachstelle als kritisch ein.

  1. Diskussion

Die Ergebnisse zeigen, dass die Korrelation zwischen mehreren Evidenzquellen das operative Rauschen signifikant reduziert. Der Hauptvorteil der vorgeschlagenen Architektur liegt in der Fähigkeit, Schwachstellen mit beobachtender Evidenz zu kontextualisieren.

Dennoch bestehen einige Einschränkungen. Das Bayes’sche Modell nimmt bedingte Unabhängigkeit zwischen Evidenzen an, was komplexe Interaktionen zwischen Angriffsvektoren nicht vollständig widerspiegeln kann. Darüber hinaus hängt die Wirksamkeit des Systems von der Qualität der erfassten Telemetrie ab.

Der Monitoring-Overhead auf Basis von eBPF blieb in den durchgeführten Experimenten unter 6 % zusätzlicher CPU-Auslastung.

  1. Schlussfolgerung

Wir präsentieren eine formale und operative, bedrohungsorientierte Architektur für die Anwendungssicherheit, die mehrere Analysetechniken mit Runtime-Telemetrie und auf MITRE ATT&CK basierender Threat Intelligence integriert.

Der Ansatz zeigte substanzielle Verbesserungen bei der Priorisierung ausnutzbarer Schwachstellen und bei der Reduktion von Fehlalarmen. Die Integration von Evidenzen aus statischer Analyse, dynamischer Analyse und operativer Beobachtung stellt einen signifikanten Fortschritt in modernen DevSecOps-Praktiken dar.

Zukünftige Arbeiten umfassen die Integration von EPSS-Metriken, den Einsatz überwachten maschinellen Lernens zur dynamischen Anpassung von Wahrscheinlichkeiten sowie die Erweiterung der Architektur auf serverlose Umgebungen und Cloud-native Plattformen.

Referenzen

BEHL, Abhishek; BEHL, Kanika. Cybersecurity and Cyberwar: What Everyone Needs to Know. Oxford: Oxford University Press, 2017. Available at: https://global.oup.com. Accessed on: 10 Mar. 2024.

BOHANNON, Aaron; HOLMES, Joshua. Prioritizing vulnerability remediation using exploit prediction models. IEEE Security & Privacy, 2022. Available at: https://doi.org/10.1109/MSP.2022.3155925. Accessed on: 12 Mar. 2024.

CHEN, Zhaofeng et al. Understanding the impact of Log4Shell vulnerability. IEEE Security & Privacy, 2022. Available at: https://doi.org/10.1109/MSP.2022.3221271. Accessed on: 10 Mar. 2024.

FIRST. Exploit Prediction Scoring System (EPSS). 2023. Available at: https://www.first.org/epss. Accessed on: 12 Mar. 2024.

FALCO. Falco Runtime Security. 2024. Available at: https://falco.org. Accessed on: 12 Mar. 2024.

KIM, Gene; HUMBLE, Jez; DEBOIS, Patrick. The DevOps Handbook. Portland: IT Revolution Press, 2021. Available at: https://itrevolution.com. Accessed on: 11 Mar. 2024.

LI, Zhen et al. Learning-based vulnerability prioritization. USENIX Security Symposium, 2022. Available at: https://www.usenix.org/conference/usenixsecurity22. Accessed on: 12 Mar. 2024.

MITRE. ATT&CK Enterprise Matrix. 2024. Available at: https://attack.mitre.org. Accessed on: 12 Mar. 2024.

NIST. Secure Software Development Framework (SSDF). 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-218/final. Accessed on: 10 Mar. 2024.

NIST. Software Bill of Materials (SBOM) Guidance. 2021. Available at: https://www.nist.gov. Accessed on: 10 Mar. 2024.

OISF. Suricata Intrusion Detection System. 2023. Available at: https://suricata.io. Accessed on: 12 Mar. 2024.

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

OWASP FOUNDATION. OWASP ZAP Documentation. 2023. Available at: https://www.zaproxy.org. Accessed on: 10 Mar. 2024.

OWASP FOUNDATION. Dependency-Check Project. 2023. Available at: https://owasp.org/www-project-dependency-check. Accessed on: 10 Mar. 2024.

SCANDARIATO, Riccardo et al. Static and Dynamic Analysis for Security Testing. IEEE Security & Privacy, v.11, n.4, 2013. Available at: https://doi.org/10.1109/MSP.2013.41. Accessed on: 10 Mar. 2024.

SHAR, Lwin Khin; TAN, Hee Beng Kuan. Defeating SQL Injection. ACM Computing Surveys, v.45, n.4, 2013. Available at: https://doi.org/10.1145/2501654. Accessed on: 10 Mar. 2024.

VERIZON. Data Breach Investigations Report 2023. Available at: https://www.verizon.com/business/resources/reports/dbir/. Accessed on: 10 Mar. 2024.

ALLEN, Julia et al. Building a Secure DevOps Pipeline. Carnegie Mellon SEI, 2020. Available at: https://resources.sei.cmu.edu. Accessed on: 10 Mar. 2024.

BASSETT, Michael et al. eBPF-based security monitoring for Linux systems. ACM Queue, 2022. Available at: https://queue.acm.org. Accessed on: 12 Mar. 2024.

CYCLONEDX. CycloneDX SBOM Standard. 2023. Available at: https://cyclonedx.org. Accessed on: 12 Mar. 2024.

KREBS, Brian. Supply Chain Attacks in Modern Software Ecosystems. 2021. Available at: https://krebsonsecurity.com. Accessed on: 12 Mar. 2024.

SONARSource. SonarQube Documentation. 2023. Available at: https://docs.sonarsource.com. Accessed on: 10 Mar. 2024.

SEMGREP. Semgrep Documentation. 2024. Available at: https://semgrep.dev. Accessed on: 12 Mar. 2024.

CNCF. Kubernetes Security Best Practices. 2023. Available at: https://kubernetes.io/docs/concepts/security. Accessed on: 11 Mar. 2024.

ENISA. Threat Landscape for Supply Chain Attacks. 2023. Available at: https://www.enisa.europa.eu. Accessed on: 11 Mar. 2024.