Als Penetration Test bezeichnet man eine umfassende technische Sicherheitsüberprüfung einzelner Systeme, Anwendungen oder IT-Netzwerke. Dieser Artikel beschreibt, wo Penetration Tests sinnvoll eingesetzt werden können und wie man sie durchführen kann.

Unternehmen sind täglich diversen IT-Sicherheitsrisiken ausgesetzt. Gängige Beispiele dafür sind Angriffe auf öffentliche Webseiten, Erpresser-Software im internen Netzwerk oder das Entwenden von sensitiven Firmendaten mittels eingeschleustem Trojaner. Bei solchen Attacken können verschiedene Arten von Schäden entstehen. Wenn die Verfügbarkeit eines Webshops nicht mehr gewährleistet werden kann, kommt es schnell zu grossen finanziellen Verlusten. Andererseits könnten entwendete Daten zum Verlust des Vertrauens aufseiten der Kunden führen. Je nach Branche kann eine solche Rufschädigung schwerwiegende Folgen haben.

Um sich vor solchen Risiken zu schützen, gibt es mehrere Strategien und Optionen, welche optimal ineinandergreifen sollten. Schauen wir uns zum Beispiel das Netzwerk einer Firma an. Sicherheit beginnt bereits bei der Planung der Netzwerkarchitektur. Dabei stellen sich Fragen wie: Gibt es eine Zonierung, welche dafür sorgt, dass Arbeitsgeräte von Endanwendern keinen direkten Zugriff auf Serversysteme mit sensitiven Daten haben? Existiert ein Berechtigungskonzept, welches dafür sorgt, dass nur berechtigte Benutzer Zugriff auf entsprechende Netzwerklaufwerke haben? Sind die Rechner auf einem aktuellen Patch-Stand, damit bekannte Schwachstellen nicht ausgenutzt werden können? Gibt es Massnahmen zur Detektion, falls es dennoch zu einem Vorfall kommt? Aus all diesen Fragen ergeben sich wichtige Massnahmen, um sich vor bekannten und noch unbekannten Risiken zu schützen.

Andererseits ist IT-Sicherheit auch beim Entwickeln von Software von grosser Bedeutung. Software und IT-Systeme sind allgegenwärtig. Egal ob Webshop, Haustechnik, Auto oder Überwachungskamera: Immer ist irgendwo auch Software für den Betrieb notwendig. Mit der zusätzlichen Vernetzung steigt auch das Risiko von Angriffen auf Software oder Infrastrukturen, da ein Angreifer im schlimmsten Fall ein System aus der Ferne übernehmen kann. Aus diesem Grund gibt es Software-Entwicklungsprozesse, welche die Sicherheit von Anfang an miteinbeziehen und ihr einen hohen Stellenwert beimessen. Einer dieser Prozesse ist der «Security Development Lifecycle» (SDL). Dieser gibt beispielsweise vor, dass zu Beginn der Software-Entwicklung bereits ein Bedrohungsmodell erarbeitet wird, damit die Sicherheit in der Software-Architektur berücksichtigt wird und sichere Programmierpraktiken angewendet werden.

Beide Beispiele, IT-Infrastruktur und Software-Entwicklung, profitieren stark davon, wenn Sicherheit bereits zu Beginn der Planung und Entwicklung berücksichtigt wird. In der Praxis ist es jedoch oft so, dass dies nicht der Fall ist. Doch auch wenn der Sicherheit ein hoher Stellenwert beigemessen wird, kann es immer noch vorkommen, dass etwas schiefgeht. Ein Entwickler kann zum Beispiel unzureichend geschult sein und so unbeabsichtigt Sicherheitslücken in den Code einer Applikation einbauen. Eine Firewall kann unzureichend konfiguriert sein, was es Angreifern erlaubt, diese zu umgehen. Das Patch-Management kann Mängel aufweisen und nicht auf allen Systemen konsequent angewendet werden. Wenn ein Standardpasswort nicht geändert wurde, kann ein Angreifer auf ein Zutrittssystem zugreifen. Die Beispiele sind unzählig. Sie reichen von fehlerhafter Konfiguration bis zu tiefgehenden, komplexen Problemen in der Programmlogik von Software.

Und genau an dieser Stelle kommt ein Penetration Test ins Spiel. Schauen wir uns den oben erwähnten «Security Development Lifecycle» (SDL) etwas genauer an. Neben diversen anderen Prozessschritten, welche die Sicherheit proaktiv erhöhen, gibt es auch die Security-Testing-Phase. Ziel dieser Phase ist es, die konkrete Implementierung auf Schwachstellen zu überprüfen. Eine solche technische Sicherheitsüberprüfung wird im Allgemeinen als Penetration Test bezeichnet, welcher von entsprechenden Sicherheitsspezialisten durchgeführt wird. Die Security-Testing-Phase dient somit als eine Art «Quality Gate», um allfällige Schwachstellen frühzeitig zu entdecken und zu beheben und so grösseren Schaden nach dem Release zu vermeiden.

Gehen wir wieder zurück zu einem vergleichbaren IT-Infrastruktur-Beispiel. Nehmen wir an, eine Firma kauft eine neue netzbasierte Videoüberwachungsanlage. Diese besteht aus einem zentralen Server, den Kameras und einer neuen Zone im lokalen Netzwerk, welche nur für dieses System zuständig ist. Bei der Planung wird natürlich darauf geachtet, dass entsprechende Sicherheitskriterien eingehalten werden. Nur berechtigte Benutzer sollen Zugang zum Server haben, das Netzwerksegment durch eine Firewall von anderen Bereichen getrennt sein und die Software in den Kameras auf dem neusten Stand. So weit die Planung, aber ob die Umsetzung dann auch wirklich alle Vorgaben der Planung realisiert hat, bleibt oft unklar. Auch hier kann nach der Umsetzung der Installation ein Penetration Test Klarheit schaffen. Sind wirklich alle Kameras auf einem aktuellen Patch-Stand? Gibt es Lücken in den Firewall-Regeln? Ist das Berechtigungskonzept korrekt implementiert worden? Ein Penetration Test liefert effizient klare Antworten darauf.

Der Penetration Test ist somit ein wichtiges Werkzeug, um eine Anwendung oder ein System auf das Vorhandensein von Schwachstellen zu untersuchen. Diesbezüglich unterscheidet sich ein Penetration Test auch von einem sogenannten Vulnerability Scan. Ein Penetration Test wird zum grössten Teil manuell durch Security Tester mit deren spezifischer Erfahrung durchgeführt, was auch das Auffinden noch unbekannter, neuartiger oder umgebungsspezifischer Schwachstellen erlaubt. Ein Vulnerability Scan ist dagegen eine vollautomatische Überprüfung auf bereits bekannte Schwachstellen, womit zumindest ein Grundniveau an Sicherheit einfach geprüft werden kann.

Die verschiedenen Phasen des Penetration Testing Execution Standard (PTES)

1. Vorbereitung

In der ersten Phase geht es vor allem darum, den Penetration Test zu definieren und, wo notwendig, abzugrenzen. Ein Penetration Test wird dabei meist auf eine Anwendung oder ein IT-System angewendet. Dazu ist es notwendig, einen sogenannten Scope zu definieren. Bei einem Webshop kann dies zum Beispiel bedeuten, dass der Anwendungs-Server und der dazugehörige Datenbank-Server getestet werden, eine vorgelagerte Web-Application-Firewall oder ein mit dem Webshop verbundenes Drittsystem hingegen vom Test ausgenommen wird. Die Gründe für den Ausschluss von Systemen sind vielfältig. Dies kann sinnvoll oder gar notwendig sein, wenn ein System beispielsweise durch einen externen Partner bereitgestellt und betrieben wird.

In dieser ersten Phase werden zudem notwendige Zugänge bereitgestellt. Idealerweise wird in einer Test-Umgebung getestet, welche der Konfiguration in der Produktion möglichst nahe kommt. So können zum Beispiel auch Denial-of-Service-Angriffe getestet werden oder Angriffe, die potenziell Daten verändern, ohne dass es zu einem Produktionsausfall kommen kann.

Nur wenn der Scope und die grundlegenden Spielregeln des Penetration Tests klar definiert wurden, kann effizient und sauber getestet werden. Diese Phase ist deshalb mindestens so essenziell für die Qualität des Penetration Tests wie der Einsatz erfahrener und unabhängiger Security-Tester.

2. & 3. Informationsfindungsphase und Erarbeiten von Bedrohungsszenarien

Die Security-Tester erhalten nach der Definition des Scopes den Zugang zu den darin befindlichen Systemen, damit sie sich ein gesamteinheitliches Bild davon machen können. Bei einer Anwendung heisst dies meistens, sich einen Überblick über die Funktionalitäten und ein Verständnis für die dahinterliegenden Business Cases zu verschaffen. Was für Schnittstellen gibt es? Welche Ports sind offen bei einem Server? Gibt es eine Dokumentation der verschiedenen Schnittstellen? Welche Protokolle und Protokollversionen werden eingesetzt? Durch diese Fragen wird die Anwendung «kartografiert». Dieser Vorgang wird auch «Footprinting» genannt. Meist macht es Sinn, dass die Security-Tester hierbei aktiv durch kundenseitige Fachpersonen unterstützt werden. Dies hilft dabei, dass die Security-Tester den Scope und potenzielle Risiken noch besser verstehen. Dies verschafft ihnen im Vergleich zu einem echten Angreifer einen grossen zeitlichen Vorteil, womit Penetration Tests wesentlich effizienter sind, als wenn ein Angreifer die gleichen Analysen durchführen würde.

Nach dieser Phase kennen die Security Tester die Anwendung sehr gut. Im Anschluss können somit Schwachstellen gesucht und analysiert werden. Basierend auf den Informationen werden verschiedene Bedrohungsszenarien entwickelt. Diese sind die Basis für das weitere Vorgehen: Den Angriff selber.

4. Schwachstellenanalyse

In dieser Phase werden nun Schwachstellen gesucht. Dies kann passiv oder aktiv erfolgen. Die Security-Tester können zum Beispiel passiv den Netzwerkverkehr mitlesen. Wird dieser nicht verschlüsselt, so kann bereits eine erste Schwachstelle identifiziert werden, ohne dass ein aktiver Angriff dafür notwendig war. Aktive Angriffe sind intrusiver. Die Security-Tester versuchen nun aktiv, Schwachstellen zu identifizieren. Dazu wird auf ein breites Arsenal an Techniken zurückgegriffen, welches sich je nach Scope stark unterscheiden kann. Die Security-Tester versuchen üblicherweise einen oder mehrere der folgenden Angriffe:

• Authentifizierung umgehen
• Zugriffskontrolle umgehen
• Verschlüsselung aufbrechen oder umgehen
• Injizieren von bösartigem Code
• Passwörter erraten
• Die Verfügbarkeit beeinträchtigen

Oft ist ein Worst Case erreicht, wenn die Security-Tester aus der Ferne den kompletten Zugriff auf ein System haben. Diese sogenannte Remote Code Execution führt dazu, dass ein Angreifer das System übernehmen und so zum Beispiel Zugriff auf sensitive Daten erhalten kann. Auch wenn ein Teil der angewendeten Techniken automatisiert ausgeführt werden kann, ist hier oft die Erfahrung und das clevere Vorgehen der Security-Tester entscheidend. Schwerwiegende Sicherheitslücken verbergen sich oft tief in der Programm- oder Business-Logik. Diese sind meist nicht durch vollautomatisierte Tests erkennbar.

5. & 6. Ausnutzen und Verwenden der Schwachstelle

Wenn eine Schwachstelle entdeckt wurde, bedeutet das nicht, dass diese auch ausgenutzt werden kann. Es kann zum Beispiel vorkommen, dass eine Webseite eine Schwachstelle beinhaltet, diese jedoch nur so verwendet werden kann, dass sich ein Benutzer selbst angreifen könnte. In diesem Falle kann die Schwachstelle nicht für einen praktikablen Angriff ausgenutzt werden. Diese Beurteilung ist für die Behebung der Schwachstelle äusserst relevant, damit vorhandene Ressourcen ideal eingesetzt werden können, und einmal mehr abhängig davon, dass erfahrene Security-Tester den Penetration Test durchführen.

Kann eine Schwachstelle jedoch aktiv ausgenutzt werden, stellen sich die Security-Tester als nächstes die Frage, welchen Schaden ein Angreifer damit genau anrichten kann. Es kann zum Beispiel sein, dass die Security-Tester damit Zugriff auf sensitive Personen- oder Unternehmensdaten erhalten. Oder es ist nun möglich, das Konto eines anderen Benutzers, eventuell sogar eines Administrators, zu übernehmen. Wenn eine Schwachstelle ausgenutzt werden kann, um die Kontrolle eines Rechners zu übernehmen, werden die Security-Tester sicher versuchen, darüber weitere Systeme innerhalb des Scopes anzugreifen. Diese Phase ist somit je nach Projekt, Organisation und Scope sehr unterschiedlich.

7. Reporting

Zuletzt erstellen die Security-Tester einen Report. Dieser sollte so geschrieben und gestaltet sein, dass die Risiken für den Kunden klar ersichtlich und nachvollziehbar sind. Dies soll jedoch nicht auf Kosten von technischen Details erfolgen. Jedes Risiko kann innerhalb eines Reports daher zum Beispiel wie folgt aufgeteilt werden:

• Bewertung des (mindestens) möglichen Schadensausmasses sowie der Eintrittswahrscheinlichkeit
• Kurzbeschreibung
• Übergeordnete Risikoklasse (zum Beispiel «unzureichende Zugriffskontrolle»), im Idealfall mit Referenz auf anerkannte Standards
• Problembeschreibung
• Wie wurde das Risiko Schritt für Schritt verifiziert?
• Mögliche Auswirkung (technisch wie aber auch aus Business-Sicht)
• Vorschlag, wie das Risiko adressiert werden kann

Insbesondere die Gewichtung jedes Risikos ist entscheidend, um dessen Dringlichkeit für eine Behebung zu beurteilen. Wir verwenden dazu die Wahrscheinlichkeit, mit welcher ein Vorfall eintritt, zusammen mit dem möglichen Schadensausmass. Eine sogenannte SQL Injection-Schwachstelle im öffentlichen Teil einer Webseite wird beispielsweise mit hoher Wahrscheinlichkeit früher oder später entdeckt und ausgenutzt. Wenn ein Angreifer so Zugriff auf sensitive Daten in der Datenbank erhält, ist zudem das Schadensausmass gross. Dies wäre somit ein kritisch einzustufendes Risiko, welches eine schnellstmögliche Adressierung erfordert.

Ein guter Report kommuniziert die Risiken bezogen auf die Anforderungen des Auftraggebers, aber er enthält auch alle technischen Details, damit beispielsweise Systemadministratoren und Software-Entwickler die Risiken später selbstständig Schritt für Schritt nachvollziehen und dadurch effizient beheben können. Wenn diese Phasen angewendet werden, erhält der Kunde einen klaren Überblick über offensichtliche sowie verborgene Risiken und Schwachstellen. Penetration Tests sind daher ein gutes Mittel, um Anwendungen oder IT-Systeme effizient und zuverlässig zu überprüfen. Da sie im Vergleich zu einfachen Vulnerability Scans genauer sind und die Business Cases mitberücksichtigen, können sie als eine Art «Quality Gate» vor dem produktiven Einsatz einer neuen Software-Lösung oder IT-Infrastruktur angewendet werden. So können potenziell kostspielige Sicherheitsvorfälle durch die frühzeitige Erkennung und Behebung von Sicherheitsproblemen vermieden werden. Daher wird generell empfohlen, Anwendungen und Infrastrukturen vor grösseren Änderungen einem Penetration Test durch Fachspezialisten zu unterziehen. Dies trifft vor allem dann zu, wenn schützenswerte Daten, die Sicherheit von Gegenständen oder sogar Personen betroffen sind.