Sichere Software
Vorteilhaft für den Profit
Fortsetzung des Artikels von Teil 1
Werkzeugkasten für Sicherheitsprüfungen
Es gibt mehrere Techniken, um Sicherheitslücken in Systemen aufzudecken – wie die statische Analyse, die dynamische Analyse, die Source-Composition-Analyse, Schwachstellen-Scanner und Penetration-Tests. Kluge Unternehmen werden stets eine Kombination dieser Verfahren anwenden.
Weil das Refaktorieren des Codes umso komplizierter wird, je näher sich die Applikation der Freigabe nähert – siehe Bild 3 – steigen die Kosten zur Beseitigung von Sicherheitslücken drastisch an, je weiter der Software Development Lifecycle (SDLC) voranschreitet. Das Ziel von Sicherheitstests sollte es also sein, die Identifikation und Beseitigung von Schwachstellen auf der Zeitachse nach links zu verschieben, also in eine möglichst frühe Phase des SDLC zu verlagern.
Statische Analyse
SAST-Tools (Static Application Security Testing) setzen keine funktionsfähige Applikation voraus und können daher schon in einer frühen Phase des Entwicklungszyklus zum Einsatz kommen, wenn die Fehlerbeseitigung noch zu niedrigen Kosten möglich ist. Auf der ganz elementaren Ebene funktioniert SAST, indem der Quellcode analysiert und anhand bestimmter Regeln geprüft wird. Werden SAST-Tools meist mit dem Aufdecken von Sicherheitslücken in Verbindung gebracht, so weisen sie die Entwickler doch auch frühzeitig auf mangelhafte Programmiermuster, Verletzungen der Regeln für sicheres Codieren oder eine unzureichende Einhaltung technischer Standards hin, die zu instabiler oder unzuverlässiger Funktion führen können.
Zum Aufdecken von Sicherheitsproblemen kommen in erster Linie zwei Arten von Analysen zum Einsatz.
Flussanalyse
Hierbei wird der Quellcode von den Tools analysiert, um ein Verständnis für den Kontroll- und Datenfluss des Codes zu gewinnen. Das Ergebnis ist eine Zwischendarstellung bzw. ein Modell der Anwendung, das die Tools anschließend prüfen, um Programmierfehler zu erkennen, die zu Sicherheitslücken führen. In einer in C oder C++ geschriebenen Applikation kann eine Regel beispielsweise String-Kopien identifizieren und das Modell daraufhin untersuchen, ob der Quell-Puffer jemals größer als der Ziel-Puffer sein kann. Falls dies so ist, kann es zu einer Pufferüberlauf-Sicherheitslücke kommen.
Musteranalyse
Moderne Softwareentwicklungs-Standards wie AUTOSAR C++14, MISRA C 2012 und Joint Strike Fighter (JSF) beruhen auf dem Grundgedanken, dass in sicherheitskritischem Code auf bestimmte Konstrukte verzichten werden sollte, die dazu führen können, dass der Code falsch interpretiert, missverstanden oder unrichtig implementiert wird und deshalb unzuverlässig ist.
Die Musteranalyse hilft den Entwicklern, sich im Kontext von Safety und Security auf eine sicherere Teilmenge der jeweiligen Programmiersprache zu beschränken. Dies untersagt die Verwendung von Konstrukten, die zum Entstehen von Sicherheitslücken führen können. Ähnlich wie die Rechtschreibprüfung in einem Textverarbeitungsprogramm, können einige Regeln die Syntax prüfen und auf diese Weise Fehler aufdecken. Andere wiederum können subtilere Muster im Zusammenhang mit mangelhaften Programmiermustern feststellen.
Dynamische Analyse
DAST-Tools (Dynamic Application Security Testing) analysieren laufende Anwendungen, um Sicherheitslücken zu identifizieren. Kommerzielle DAST-Tools arbeiten in der Regel automatisch. Sie identifizieren die an eine Applikation gerichteten Eingaben, z.B. ein Login oder ein Bestellformular, und wenden verschiedene vorkonfigurierte Daten (Fuzzing Data) an, um eine Fehlfunktion oder einen Absturz der Applikation zu provozieren. Ein Beispiel hierfür wäre das Einschleusen eines SQL-Befehls in ein Formular (SQL Injection Attack) mit dem Ziel, die Authentifizierung zu umgehen oder an sensible Informationen zu gelangen.
Die von DAST-Tools gelieferten Ergebnisse sind nicht mit einer bestimmten Codezeile verknüpft. Stattdessen werden Schwachstellen als URL/Aktion/Ergebnis gemeldet, z.B. »auf https://app.mycompany.com/order habe ich als Kundennummer »99 ‘ OR 1=1« eingegeben, woraufhin die Namen aller Kunden ausgegeben wurden«. Anschließend muss das Entwicklerteam ermitteln, an welcher Stelle des Quellcodes der Fehler aufgetreten ist. Dies wiederum gestaltet sich kompliziert, wenn der Fehler aus nicht validierten Benutzereingaben resultiert, denn der Fehler manifestiert sich überall dort, wo diese nicht vertrauenswürdigen Daten benutzt werden.
Penetrationstests
Für die meisten Unternehmen wird das Beauftragen externer Penetrationstester (»Pen-Tester«) der erste Vorstoß in das Security-Testing sein. Anstatt automatisierte DAST-Scans ablaufen zu lassen, sind Penetrationstester darauf trainiert, gängige Fehler in der Softwareentwicklung zu verstehen und zu identifizieren, die zum Entstehen von Sicherheitslücken führen können.
Pen-Tester nutzen eine Kombination aus kommerziellen, quelloffenen und kundenspezifischen Tools, um im Zielsystem Aufklärungsmaßnahmen durchzuführen, potenzielle Einstiegspunkte zu identifizieren und Zugang zu einem System zu erlangen und diesen zu behalten. Ebenso wie DAST-Tools, geben auch Penetrationstestreports die Schwachstellen im Format URL/Aktion/Ergebnisse aus.
So hilfreich sie auch sein mögen, sind Penetrationstests unter Umständen auch teuer. Da sie außerdem ein laufendes System in einer arbeitsfähigen Umgebung voraussetzen, kommen sie erst in einer späten Entwicklungsphase zum Einsatz.
Source-Composition-Analyse
Anwendungen setzen sich meist aus kundenspezifischem Code und Third-Party-Komponenten zusammen, wobei letztere vorwiegend Open Source sind. Wie bei jeder Software, können diese Open-Source-Komponenten Sicherheitslücken enthalten – alljährlich werden Tausende solcher Schwachstellen in der National Vulnerability Database (NVD) des NIST (National Institute of Standards and Technology) veröffentlicht.
Source-Composition-Analysetools parsen den Package Manager der Applikation oder inspizieren »Fingerabdrücke« der verwendeten Komponenten, um so etwas wie eine Software-Stückliste (Software Bill of Materials, SBoM) zu erstellen. Anschließend werden bekannte Schwachstellen aus der NVD oder anderen Quellen auf diese Komponenten abgebildet.
Angreifbare Komponenten (oder solche mit restriktiven Lizenzen) werden markiert. Es ist jedoch wichtig darauf hinzuweisen, dass eine Komponente nicht in jedem Fall anfällig für Exploits ist. Sondern entscheidend ist, wie sie verwendet wurde und in welchem Teil der Komponente sich der angreifbare Code befindet.
Schwachstellen-Scanner
Schwachstellen-Scanner analysieren laufende IT-Systeme mit dem Ziel, nicht gepatchte oder falsch konfigurierte Applikationen oder Systeme zu identifizieren. Meist verfügen sie über Hunderte von »Plug-ins« oder »Rule Packs«, die jeweils für das Erkennen eines bestimmten Problems auf einer bestimmten Plattform ausgelegt sind. Schwachstellen-Scanner können nicht-aktuelle Betriebssysteme, die Verwendung voreingestellter Passwörter und bereits offengelegte Sicherheitslücken in Applikationen und Komponenten entdecken. Diese Lösungen sind auf kommerzielle Software und Betriebssysteme fokussiert, aber für eigen-entwickelte Anwendungen – abgesehen von einem kleinen Teil der Schwachstellen in Open-Source-Komponenten – sind sie blind.
- Vorteilhaft für den Profit
- Werkzeugkasten für Sicherheitsprüfungen
- Vorteile von SAST gegenüber DAST
