Best Practices für das Management von Anwendungsschwachstellen
6. August 2024
0 Min. LesezeitSeit Jahren ist das Management von Anwendungsschwachstellen ein wichtiger Bestandteil von DevSecOps, das die gemeinsame Verantwortung für Sicherheit über Teams hinweg betont.
Da sich die Entwicklungspraktiken jedoch weiterentwickelt haben, müssen Sicherheitsteams lernen, sich anzupassen und Entwickler dort abzuholen, wo sie arbeiten. Containerisierung, Infrastructure as Code (IaC), KI-Codierungsassistenten und die zunehmende Nutzung von Code Dritter sind beispielsweise im typischen Entwicklungslebenszyklus heute gang und gäbe. Diese Praktiken gab es vor zehn Jahren noch nicht. Sicherheitsteams mussten sich daher im Laufe der Zeit an diese „neue Normalität“ anpassen.
Um sich anzupassen, mussten Sicherheitsteams eine Balance zwischen alten und neuen Techniken finden. Bewährte Methoden sind in vielen Fällen nach wie vor wirksam, müssen aber durch neuere Praktiken ergänzt werden, die mit den Veränderungen in der heutigen Softwareentwicklung Schritt halten.
Das Schwachstellenmanagement ist ein Beispiel dafür. Es gibt es schon seit vielen Jahren und es hat seinen Platz in modernen Sicherheitspraktiken. Teams müssen es jedoch durch weitere Best Practices ergänzen.
In diesem Blogbeitrag erfahren Sie die Grundlagen des Managements von Anwendungsschwachstellen: was es ist, wo seine Grenzen liegen und welche Best Practices es in den heutigen, sich rasant weiterentwickelnden SDLCs am besten ergänzen.
Das Management von Anwendungsschwachstellen erklärt
Das Management von Anwendungsschwachstellen ist ein umfassender Ansatz, um Schwachstellen in Anwendungen zu identifizieren, zu klassifizieren, zu beheben und ihre Auswirkungen zu mindern. Zu den wichtigsten Komponenten des Schwachstellenmanagements gehören:
Schwachstellen während des gesamten Anwendungslebenszyklus identifizieren.
Identifizierte Schwachstellen klassifizieren und analysieren, um ihre Art, ihren Schweregrad und ihre möglichen Auswirkungen zu verstehen.
Identifizierte Schwachstellen beheben und ihre Auswirkungen mindern, indem Patches angewendet, Konfigurationen geändert oder alternative Schutzmaßnahmen umgesetzt werden.
Alle Prozesse und Ergebnisse des Schwachstellenmanagements dokumentieren und darüber berichten.
Die Anwendungen des Unternehmens kontinuierlich überwachen und überprüfen, um auf neue Bedrohungen reagieren zu können.
Um diese Schritte zu skalieren und zu optimieren, können größere Unternehmen auch Techniken des Schwachstellenmanagements für Unternehmen einsetzen, zum Beispiel:
Mit Tools für das Unternehmensmanagement arbeiten, etwa Configuration Management Databases (CMDBs), Patch-Management-Systemen und Security Information and Event Management (SIEM)-Systemen.
Wichtige Aktivitäten wie Scans, Bedrohungsanalysen, die Bereitstellung von Patches und die Berichterstellung automatisieren.
Aktivitäten regulatorischen Anforderungen zuordnen (z. B. DSGVO, HIPAA oder PCI-DSS).
Fortschrittliche Bedrohungsdatenbanken nutzen.
Schwachstellendaten im gesamten Unternehmen zentral einsehbar machen.
Zwei Best Practices für das Schwachstellenmanagement
Teams können das Schwachstellenmanagement auf verschiedene Weise zur Unterstützung ihrer Anwendungssicherheitsinitiativen einsetzen. Hier sind die zwei wichtigsten Best Practices, um das Schwachstellenmanagement für eine effektivere AppSec erfolgreich zu nutzen:
Wo möglich automatisieren
Angesichts der Anzahl und Häufigkeit neuer Schwachstellen und Updates kann ihre manuelle Verwaltung überwältigend, fehleranfällig und für jedes Unternehmen unpraktisch sein. Automatisierung minimiert menschliche Fehler, beschleunigt Prozesse des Schwachstellenmanagements und entlastet Sicherheitsteams, damit sie sich auf strategischere Aufgaben konzentrieren können.
Folgende Bereiche eignen sich besonders für die Automatisierung:
Schwachstellenscans mit einem Tool wie Snyk, das regelmäßige Scans durchführen kann.
Patch-Management mit Tools wie Microsoft Intune oder SolarWinds Patch Manager.
Berichterstellung und Überwachung, einschließlich des Versands von Echtzeitwarnungen an die zuständigen Teammitglieder.
Automatisierung beschleunigt Prozesse und senkt das Risiko menschlicher Fehler. Dennoch ist eine menschliche Kontrolle erforderlich, damit Sie die Regeln in Ihren Automatisierungstools von Zeit zu Zeit aktualisieren können.
Entwickler in das Schwachstellenmanagement einbinden
Wie bereits erwähnt, ist DevSecOps entscheidend für den Erfolg der Anwendungssicherheit. Mit einigen Maßnahmen können Entwicklungsteams leichter am Schwachstellenmanagement mitwirken, darunter:
Threat-Modeling-Sitzungen durchführen, um eine klare Ausrichtung für Ihr Sicherheitsprogramm festzulegen.
Sichere Codierungsstandards und -praktiken mit Policy as Code (PaC) während des gesamten Softwareentwicklungslebenszyklus durchsetzen.
Entwickler über häufige Sicherheitsfehler beim Programmieren und deren Behebung informieren.
Tools einsetzen, die statische Anwendungssicherheitstests (SAST) und Software Composition Analysis (SCA) durchführen, sobald Entwickler ihren Code committen. Je früher Ihre Tools ein Sicherheitsproblem erkennen, desto leichter kann der Entwickler es beheben.
Die Grenzen des Schwachstellenmanagements
Das Schwachstellenmanagement spielt zwar eine entscheidende Rolle für die Anwendungssicherheit, weist aber in einigen Bereichen nach wie vor Lücken auf. Beim Management von Anwendungsschwachstellen geht man oft von Annahmen aus, die in den komplexen, schnelllebigen Entwicklungsumgebungen von heute nicht mehr zutreffen:
Einschränkung Nr. 1: Beim traditionellen Schwachstellenmanagement wird jede Schwachstelle isoliert betrachtet.
Traditionell konzentriert sich das Schwachstellenmanagement darauf, jede Schwachstelle einzeln zu beheben. Doch was passiert, wenn die Behebung einer Schwachstelle Änderungen an anderen Teilen des Codes erfordert und dadurch eine Kettenreaktion neuer Schwachstellen auslöst? Das kann Teams auf dem Weg zu einer langfristig sichereren Anwendung schaden, statt ihnen zu helfen.
Dem herkömmlichen Management von Anwendungsschwachstellen fehlt der vollständige Anwendungskontext. Dadurch berücksichtigen Korrekturen nicht die gesamte Anwendung und können im Laufe der Zeit weitere Schwachstellen verursachen.
Einschränkung Nr. 2: Beim traditionellen Schwachstellenmanagement wird das Risiko anhand eines Standardwerts wie des Common Vulnerability Scoring System (CVSS) bewertet.
Im Allgemeinen stützt sich das Management von Anwendungsschwachstellen auf Standardwerte wie CVSS, um das mit jeder Schwachstelle verbundene Risiko zu bewerten. Entwickler priorisieren daraufhin die Behebung von Schwachstellen mit hohen CVSS-Kritikalitätswerten. Diese Standardwerte berücksichtigen jedoch keine weiteren wichtigen Faktoren, etwa in welcher Anwendung sich die Schwachstelle befindet. Teams sollten beispielsweise einer Schwachstelle mit mittlerem CVSS-Wert in einer geschäftskritischen Anwendung Vorrang vor einer Schwachstelle mit kritischem CVSS-Wert in einer internen Anwendung geben.
Das herkömmliche Management von Anwendungsschwachstellen stützt sich ausschließlich auf CVSS. Doch dieser Wert bildet das Gesamtbild einer Schwachstelle nicht ab.
Einschränkung Nr. 3: Beim traditionellen Schwachstellenmanagement müssen Entwickler ihre gewohnte Umgebung verlassen, um Scans durchzuführen.
Da es das Schwachstellenmanagement schon so lange gibt, weist es einige veraltete Elemente auf. Dazu zählt die überholte Vorstellung, dass Entwickler für Tests in frühen Phasen des SDLC auf eine separate Sicherheitsplattform wechseln müssen.
Dieser ständige Kontextwechsel funktioniert nicht, da Entwickler bereits für viele weitere Bereiche der Anwendungsentwicklung verantwortlich sind. Stattdessen müssen Teams überlegen, wie sich Tests und andere zentrale Elemente des Schwachstellenmanagements besser in die gewohnten Workflows integrieren lassen – beispielsweise durch Scans sowie direkt in Entwicklungsplattformen verfügbare, umsetzbare Lern- und Behebungsempfehlungen in Echtzeit.
Beim herkömmlichen Management von Anwendungsschwachstellen wird davon ausgegangen, dass Entwickler ihren Code auf einer separaten Sicherheitsplattform scannen und Schwachstellen beheben müssen – ein Kontextwechsel, für den ihnen die Zeit und Kapazität fehlen, um ihn effektiv zu bewältigen.
Einschränkung Nr. 4: Das traditionelle Schwachstellenmanagement zielt darauf ab, alle Schwachstellen in einer einzigen Ansicht zusammenzuführen.
Auch der Versuch, alle Schwachstellen in einer einzigen Ansicht zusammenzuführen, ist eine Schwäche des Schwachstellenmanagements. In einer komplexen Entwicklungsumgebung ist dieses Ziel unrealistisch, da im Laufe der Zeit immer neue Schwachstellen hinzukommen. Stattdessen sollten Teams zuerst den Kontext geschäftskritischer Anwendungen erfassen und darauf aufbauen. In den meisten Fällen ist es nicht nötig, alle Schwachstellen eines Unternehmens lückenlos zu erfassen.
Das herkömmliche Management von Anwendungsschwachstellen versucht, alle Schwachstellen in einer einzigen Ansicht zusammenzuführen – ein unrealistisches Ziel, das den nötigen Risikokontext nicht effektiv sichtbar macht.
So unterstützt Snyk das Schwachstellenmanagement
Snyks Ansatz für Anwendungssicherheit ist kontextbezogen, risikobasiert und entwicklerorientiert. Damit geht er gezielt auf die Grenzen des traditionellen Schwachstellenmanagements ein. Unsere Tools bieten die folgenden Praktiken und Perspektiven:
Sicherheitstests wie SAST und SCA direkt in den gewohnten Entwicklungsumgebungen. Entwicklungsteams können Schwachstellen finden und beheben und erhalten wertvolle Informationen zu jedem erkannten Problem – alles direkt über ihre CLIs.
Application Security Posture Management bietet Unternehmen einen Asset-zentrierten Ansatz, mit dem sie ihre wichtigsten Assets nach geschäftlicher Bedeutung statt anhand allgemeiner CVSS-Werte priorisieren können.
Kontextbezogene Sicherheitskorrekturen, die keine anderen wichtigen Bereiche Ihrer Anwendung beeinträchtigen. Sie basieren auf dem umfassenden Geschäfts- und Anwendungskontext von ASPM.
Erfahren Sie mehr darüber, wie ASPM Ihr Schwachstellenmanagement auf die nächste Stufe heben kann.
