Eine umfassende Strategie für mehr Anwendungssicherheit 3 wichtige Schritte für AppSec-Teams

Anbieter zum Thema

CrowdStrike GmbH c/o Citco Deutschland GmbH

Windhoff Group

Nicht nur die Softwareentwicklung verändert sich rasant, sondern auch die Vorgehensweise von Angreifern, die es auf kundenspezifische Applikationen abgesehen haben. Daher ist es wichtig, auf die Probleme von Application-Security- oder kurz AppSec-Teams einzugehen.

Die zunehmende Verbreitung von lose gekoppelten Anwendungen und die wesentlich schnellere Codebereitstellung führen zu einer immer größeren Angriffsfläche mit mehr Softwarearchitektur und importierte Abhängigkeiten. Die Teams für Applikationssicherheit (AppSec) sind den Softwareentwicklern oft zahlenmäßig unterlegen und können mit den häufigen Codeänderungen kaum Schritt halten.

All diese Faktoren schaffen neue Möglichkeiten für Angreifer, die sich die Nebeneffekte der schnellen Softwareentwicklung zunutze machen, um unternehmensspezifische Anwendungen auszunutzen. Höchste Zeit, sich sowohl mit den Herausforderungen von AppSec-Teams auseinanderzusetzen als auch mit den Schritten, die erforderlich sind, um sich mit den Kollegen aus der Softwareentwicklung abzustimmen und unternehmensspezifische Anwendungen zu schützen.

Codeänderungen, Datenflüsse und APIs analysieren

Es ist wahrscheinlich, dass sich die Angriffsvektoren über Anmeldeformulare und nicht bereinigte Dateneingaben hinaus ausweiten werden. Programmierschnittstellen (Application Programming Interfaces, APIs) sind die wichtigste Methode für den Datentransport in einer Microservices-Architektur.

Mit der raschen Umstellung von Unternehmen auf Cloud-Dienste hat sich die Angriffsfläche im Internet durch die Fülle an APIs vergrößert. Teams für Anwendungssicherheit müssen die Parameter und die Sicherheitslage für alle APIs in ihrem Ökosystem kennen und verstehen.

Bei der Übertragung von Daten durch Softwareanwendungen über API werden die Daten in mehrere Parameter aufgeteilt. Im Falle eines Eingabeformulars können dies beispielsweise typische Parameter wie „Vorname“, „Nachname“ und „E-Mail“ sein. Es ist schwierig, alle Parameter zu katalogisieren und zu verfolgen, die über die API in einem Microservices-Backend übergeben werden.

APIs dokumentieren und regelmäßig testen

Entwickler dokumentieren ihre APIs in der Regel manuell mit OpenAPI. Aber jeder manuelle Ansatz ist fehleranfällig, insbesondere wenn sich APIs im Laufe der Zeit weiterentwickeln. Eine automatische API-Dokumentation, einschließlich der Erkennung sensibler Parameter, ist unerlässlich.

Eine weitere Herausforderung ist die Entwicklung selbst. Viele Entwicklungsteams erstellen APIs zu Testzwecken, und manchmal gelangen diese Prototyp-APIs versehentlich in die Produktion und werden der Welt zugänglich gemacht. Ohne automatisierte Erkennung von Produktions-APIs existieren diese nicht erkannten Schnittstellen als „Schatten-APIs“, d.h. APIs, die dem größeren Unternehmen unbekannt sind.

Eine direkte Folge des Wildwuchses von APIs sind weitreichende Sicherheitsverletzungen, die auf einfache Fehler wie fehlende Authentifizierung und fehlerhafte Autorisierung in APIs zurückzuführen sind. Einige dieser Fehler sind bereits bei der ersten Implementierung vorhanden, viele werden jedoch erst in späteren Versionen eingeführt.

Um dieses Problem zu lösen, müssen die für die Anwendungssicherheit zuständigen Teams stets wissen, welche APIs unternehmenskritische Funktionen ausführen oder sensible Daten enthalten. Da sich Software im Laufe der Zeit ändert, müssen AppSec-Teams sicherstellen, dass wichtige APIs regelmäßig getestet und analysiert werden.

Alle Software-Komponenten inventarisieren

Die Software Bill of Materials (SBOM), die in der modernen Softwareindustrie viel diskutiert wird, ist eine vollständige Liste der Software-Frameworks und Bibliotheken, die in eine Softwareanwendung importiert werden. Diese Bibliotheken und Frameworks sind Codeprojekte, die von Entwicklern importiert werden, um Teile der Geschäftslogik zu „abstrahieren“. Die Verwendung von bereits vorhandenem Code ermöglicht es den Entwicklern, sich auf neue Probleme zu konzentrieren, anstatt etwas bereits Bestehendes neu zu erfinden.

Wichtig für das Verständnis der SBOM ist das Konzept der „transitiven Abhängigkeiten“. Dabei handelt es sich um Softwarekomponenten, die indirekt importiert werden, weil sie von einem anderen Framework oder einer Bibliothek abhängig sind. Wenn ein einzelnes Softwarepaket in eine Anwendung importiert wird, kann es eine große Anzahl anderer Softwarepakete nach sich ziehen.

Dieses Konzept der transitiven Abhängigkeit kann zu einer langen Liste von Softwarebibliotheken führen, die im Speicher ausgeführt werden, von denen viele dem Softwareentwickler und dem größeren Unternehmen nicht bekannt sind. Die Verwendung dieser bekannten und unbekannten Softwarepakete kann schnell gefährlich werden, wenn neu entdeckte und ausgenutzte Schwachstellen Risiken mit sich bringen, derer sich Unternehmen nicht bewusst sind.

Unternehmen müssen deshalb eine genaue SBOM führen, damit sie leicht erkennen können, wann Zero-Day-Schwachstellen ein unmittelbares Risiko darstellen. Dies ist besonders wichtig, da die Softwarearchitektur der Unternehmen wächst und die importierten Abhängigkeiten zunehmen, wodurch eine größere Angriffsfläche entsteht, die überwacht werden muss.

Angegriffene Schwachstellen entschärfen und patchen

Für Sicherheitsteams ist es entscheidend zu wissen, wann bekannte Schwachstellen und Gefährdungen (Common Vulnerabilities and Exposures, CVEs) in der realen Welt ausgenutzt werden. Sie können damit das jeweilige Risiko besser einschätzen und entsprechend patchen.

In der Vergangenheit haben viele Unternehmen die Prioritäten für das Patchen von Schwachstellen anhand des Common Vulnerability Scoring System (CVSS) festgelegt, das den Schaden abschätzt, den ein Angreifer mit der Schwachstelle anrichten kann. Es ist zu erwarten, dass sich der Trend in der Anwendungssicherheitsbranche fortsetzen wird, sich nicht mehr auf rohe CVSS-Scores zu verlassen, sondern Alternativen zu nutzen, die die Wahrscheinlichkeit eines Angriffs berücksichtigen.

Beispielsweise gibt es das Exploit Prediction Scoring System (EPSS), das maschinelles Lernen verwendet, um vorherzusagen, ob eine bestimmte Sicherheitslücke ausgenutzt wird. Die US-Regierung unterhält einen KEV-Katalog (Known Exploited Vulnerability), der Schwachstellen auflistet, von denen bekannt ist, dass sie in der realen Welt ausgenutzt werden.

Cybersecurity-Unternehmen nutzen außerdem die Daten ihrer internen Threat Intelligence Teams, um weitere, reale Schwachstellen zu identifizieren. Die Cloud-Sicherheitsplattform von CrowdStrike beispielsweise verwendet die ExPRT.AI-Bewertung, um den Schweregrad von Schwachstellen zu klassifizieren, einschließlich der Wahrscheinlichkeit, dass eine Schwachstelle von bestimmten Angreifergruppen ausgenutzt oder angegriffen wird.

AppSec-Teams können eine Kombination aus EPSS, KEV und Herstellerinformationen über Bedrohungen verwenden, um aktiv ausgenutzte Schwachstellen in ihrer Umgebung zu isolieren. Angesichts der großen Anzahl von Schwachstellen im Umlauf, einschließlich der Schwachstellen in Bibliotheken, ist es wichtig, dass AppSec-Teams geeignete Maßnahmen ergreifen, um die Schwachstellen zu priorisieren, die Aufmerksamkeit erfordern.

Eine moderne Strategie für Anwendungssicherheits-Tools

Die meisten Tools für die Anwendungssicherheit – einschließlich statischer Anwendungssicherheitstests (SAST), dynamischer Anwendungssicherheitstests (DAST) und Softwarekompositionsanalyse (SCA) – sind für die Suche nach einzelnen Schwachstellen konzipiert. Diese Tools erfüllen ihren Zweck, Schwachstellen zu finden, sehr gut. Sie sind jedoch nicht darauf ausgelegt, die Softwarearchitektur zu verstehen, und können Schwachstellen nicht auf der Grundlage des Geschäftsrisikos priorisieren.

Hier setzt das Application Security Posture Management (ASPM) an. ASPM-Tools verstehen die Softwarearchitektur. Durch die Analyse aller Datenflüsse und APIs können ASPM-Tools Erkenntnisse über jedes erkannte Risiko gewinnen. Dank dieses Architekturverständnisses können ASPM-Tools Schwachstellen auf intelligente Weise anhand von drei Kriterien priorisieren:

• 1. Schweregrad der Auswirkungen einer Schwachstelle (z. B. CVSS-Einstufung)

• 2. Wahrscheinlichkeit der Ausnutzung (z.B. Internet-basierter Microservice)

• 3. Auswirkungen auf die Geschäftstätigkeit (z.B. Offenlegung personenbezogener Daten)

Darüber hinaus identifizieren ASPM-Tools die in Produktion befindlichen Softwarepakete, so dass die Anwendungssicherheitsteams eine vollständige SBOM für ihre individuell entwickelten Anwendungen sehen können.

Durch die Kombination der Schwachstellenanalyse bewährter Tools wie SAST, DAST und SCA mit den Priorisierungsfunktionen von ASPM können Anwendungssicherheitsteams jeden der hier aufgeführten Schritte zur Verbesserung der Anwendungssicherheit effizient durchführen. Durch die Implementierung dieser Tools und das Hinzufügen von Laufzeitschutz, um Angriffe in Echtzeit zu stoppen, können AppSec-Teams ihre robuste AppSec-Strategie umsetzen.

(ID:50004871)