Insbesondere für Unternehmen, die größere Infrastrukturen betreiben, können aus einem Pentest oft mehr Erkenntnisse gewonnen werden, als typischerweise angenommen wird. Wir zeigen Ihnen, wie Sie Pentest Ergebnisse richtig interpretieren und einen maximalen Nutzen daraus ziehen.
Einer der Hauptgründe ist eine falsche Perspektive auf die Ergebnisse eines Tests. Typische Annahmen sind:
Irrtum 1: Ein Pentest findet sämtliche Schwachstellen die auf dem Target vorhanden sind
Eine erste wichtige Erkenntnis ist, dass Penetrationstests nie alle Schwachstellen auf einem Zielsystem erkennen können. Dies hat folgende Gründe: Zum einen ist der Test zeitlich begrenzt, zum anderen sind bei den meisten Tests nicht alle Konfigurationsparameter über das System bekannt.
Fazit: Ein Pentest kann nicht allein dazu herangezogen werden eine Zielanwendung sicherer zu machen. Ein Pentest Bericht ohne kritische Feststellungen bedeutet nicht, dass die Anwendung absolut keine Schwachstellen enthalten kann.
Konsequenz: Nutzen Sie bei Anwendungs-Audits die volle Bandbreite an Testmöglichkeiten: Code-Reviews, Peer-Reviews, Schulungen zum Secure Software Development. Je früher Schwachstellen entdeckt werden, desto höher ist der Gewinn. So lassen sich durch frühzeitige Code-Reviews mit Fokus auf Schwachstellen, Code-Komplexität und “Bad Smells” Fehler im Design, im Datenmodell oder im Verständnis der Programmierer aufdecken. Ein Pentest erfolgt meist erst zu einem Release-Status der Anwendung, wo größere Änderungen nicht mehr möglich sind.
Wenn Schwachstellen in einem Pentest identifiziert werden, so sollte immer ausgewertet werden, ob diese Fehler womöglich auch in anderen Applikationskomponenten vorhanden sein können. Gerade bei Schwachstellen bei der Eingabevalidierung lassen sich in einem Test oft nicht alle verwundbaren Parameter identifizieren. Ebenfalls sollte analysiert werden, ob das fehlerhafte Design ggf. in anderen Anwendungen zum Einsatz kam.
Irrtum 2: Ein Pentest trifft eine Aussage darüber, wie sicher das System gegenüber (zukünftigen) Angriffen ist
Ein Pentest ist immer nur eine Momentaufnahme aktuell bekannter Schwachstellen und des Zielsystems in seiner Konfiguration und Version zur Testzeit. Nur weil ein aktueller Bericht als Gesamtrisiko “niedrig” ausweist, heißt dies nicht, dass nicht zukünftig eine neue Schwachstelle veröffentlicht wird, die das gesamte System kompromittiert.
Pentests sollten daher nicht als einmalige Maßnahme betrachtet werden, sondern sind vielmehr eine Methode zur regelmäßigen Überprüfung einer Anwendung oder eines IT-Systems auf bekannte Schwachstellen.
Irrtum 3: Risikobewertung ist gleich Priorität
Wir sehen oft, dass Pentestergebnisse ohne eine nähere Diskussion des Risikos weiterverarbeitet werden. Die Risikobewertung der Pentester wird als “in Stein gemeißelt” gesehen. Hier weisen wir drauf hin, dass eine Diskussion der identifizierten Schwachstellen mit Ihrem IT-Sicherheitsteam zu einer sinnvollen Gewichtung oder Priorisierung der Ergebnisse führen kann. Je nachdem, welches Threat Model Sie erarbeitet haben (z.B. in einer Risk/Impact-Analyse als Teil der ISO 27001 Zertifizierung) kann es Schwachstellen geben, deren Behebung anders priorisiert werden sollte, als es der Pentestbericht von außen beurteilt.
Gerne können wir als Pentest Factory diese Diskussion (z.B. in einem gemeinsamen Meeting) unterstützen, um ein Gesamtbild des Zielsystems und Risikos in seiner Umgebung zu kreieren.
Ein weiterer Gesichtspunkt ist das Risikobewertungssystem selbst. Bei der Verwendung des Standard CVSS Systems (ohne Environment-Metriken), wird das Gesamtrisiko aus einer Formel errechnet, die uns als Testern wenig Freiraum zur kontextabhängigen Herauf- oder Herabstufung von Risiken lässt. Beispielsweise lässt sich für die Metrik “Attack Complexity” ausschließlich zwischen “High Attack Complexity” und “Low Attack Complexity” wählen. Dementsprechend lassen sich Angriffe mit einer mittleren Komplexität hier nicht abbilden. Dies ist ähnlich für die weiteren Metriken im CVSS-System. Somit kann es z.B. vorkommen, dass wir eine Feststellung mit mittlerer Kritikalität als “hohes Risiko” einstufen, weil die CVSS-Formel dies errechnet.
Generell macht eine Besprechung der einzelnen Ergebnisse und zugewiesenen Risiken im Team somit Sinn.
Irrtum 4: DIe Behebung von Schwachstellen löst das Problem
Das Ergebnis eines Pentests ist ein Abschlussbericht. Dieser führt identifizierte Schwachstellen auf und gibt konkrete Empfehlungen zur Behebung der Feststellungen.
Es erscheint auf den ersten Blick, dass die Behebung dieser Schwachstellen die Hauptaufgabe nach Abschluss des Tests ist.
Als Pentest Dienstleister sehen wir jedoch häufig, dass die Behebung von Schwachstellen die einzige resultierende Tätigkeit aus einem Testergebnis ist. Aus diesem Grund ist es umso wichtiger zu verstehen, dass der eigentliche Wert des Pentests in der Identifikation von fehlerhaften Prozessen liegt. Bei jeder Schwachstelle lohnt es sich zu fragen “Warum ist es zu dieser Schwachstelle gekommen? Wie können wir den Prozess dahinter korrigieren?“
Nur auf diese Weise kann gewährleistet werden, dass z.B. ein fehlender Patch-Management-Prozess oder ein mangelhaftes Asset-Management korrigiert werden und Software-Deployments nicht nach einem Monat wieder mit fehlenden Updates laufen.
Da wir sehr häufig sehen, dass eine Ursachenanalyse nach Abschluss des Pentests entfällt, möchten wir ein zweites Beispiel zeigen, bei dem ein Verständnis des fehlerhaft abgelaufenen Prozesses einen deutlichen Mehrwehrt in der Sicherheit bringen kann:
- In einem Pentest-Bericht wird festgestellt, dass im Web-Verzeichnis des Anwendungsservers eine Datei mit sensitiven Umgebungsvariablen gespeichert wurde. Die Datei mit dem Namen “.env” wurde bereits während des Pentests an den Kunden kommuniziert und dieser hat die Datei unmittelbar entfernt. Belässt der Kunde seine Behebungsmaßnahmen bei diesem Schritt, so ignoriert er eine komplette Ursachenanalyse und womöglich weitere Schwachstellen, die bestehen.
- Stellen wir uns die Frage: Warum hat es die .env Datei in das Webverzeichnis geschafft? Nach einer Analyse des Entwicklungs-Repository’s (z.B. GIT) stellen wir fest, dass ein Entwickler die Datei 2 Monate vor Release angelegt hat und in ihr sensitive Umgebungsvariablen speichert. Dies beinhaltet den AWS Secret Key, sowie die Kennwörter des Administrator-Accounts. Dabei hat der Entwickler vergessen, die Datei von der Repository-Indizierung zu exkludieren. Dies wird erreicht, indem die Datei in die “.gitignore” Liste aufgenommen wird.
- Wie können wir diesen Fehler in Zukunft beheben?
- Erkenntnis 1: Mögliche Ursache im Missverständnis der Entwickler: “Entwickler verstehen nicht, welches Risiko fest eingespeicherte (“hardcoded”) Passwörter und Schlüssel haben”.
–> Awareness Seminar mit Entwicklern zum Thema Secure Software Development–> Monatliche Session zum Thema “Secrets im Quellcode”
- Erkenntnis 1: Mögliche Ursache im Missverständnis der Entwickler: “Entwickler verstehen nicht, welches Risiko fest eingespeicherte (“hardcoded”) Passwörter und Schlüssel haben”.
- Wie können wir diesen Fehler in Zukunft beheben?
- Erkenntnis 2: Der Fehler wurde 2 Monate lang nicht bemerkt und erst im Pentest festgestellt.
–> Möglichkeiten der automatischen Erkennung von Secrets: “Statische Quellcode Analyse”, “Automatisierte Analyse von Commits”, “Automatisierte Scans des Quellcode-Repositories”–> Anpassung der CI/CD Pipeline um automatisch sensitive Commits zu Stoppen
- Erkenntnis 2: Der Fehler wurde 2 Monate lang nicht bemerkt und erst im Pentest festgestellt.
- Erkenntnis 3: Schlechtes Management von sensitiven Schlüsseln
–> Neues zentrales Tool zum Secrets-Management einführen – Dies verbessert ebenfalls die Durchsetzung von Password-Policies, Passwort-Rotation
- Erkenntnis 3: Schlechtes Management von sensitiven Schlüsseln
- Haben wir diesen Fehler in der Vergangenheit mehrmals begangen?
- Erkenntnis 1: Entwickler haben nicht nur eine Anwendung programmiert. Wir stellen fest, dass derselbe Fehler auch in einer benachbarten Anwendung begangen wurde.
–> Pentest Ergebnis lässt sich auf ähnliche Systeme und Prozesse übertragen
- Erkenntnis 1: Entwickler haben nicht nur eine Anwendung programmiert. Wir stellen fest, dass derselbe Fehler auch in einer benachbarten Anwendung begangen wurde.
- Haben wir diesen Fehler in der Vergangenheit mehrmals begangen?
- Erkenntnis 2: Das Versionsmanagement Tool enthält einen Verlauf aller jemals eingefügten Änderungen
–> Analyse des gesamten Repository’s auf sensitive Commits
- Erkenntnis 2: Das Versionsmanagement Tool enthält einen Verlauf aller jemals eingefügten Änderungen
Irrtum 5: Hohe Risiken im Abschlussbericht = "Das Produkt ist schlecht"
Nur weil eine “kritische” Schwachstelle identifiziert wird, heißt dies nicht, dass die Entwicklung oder das Produkt “schlecht” sind. Gerade Produkte, die besonders viele Funktionen bereitstellen, haben besonders viele mögliche Angriffsflächen. Bestes Beispiel sind bekannte Produkte wie Browser oder Betriebssyteme, die monatliche Sicherheitspatche herausbringen.
Als langjährige Experten im Bereich Cybersecurity sehen wir, dass die größten Probleme durch eine defensive Denkweise und eine unzureichende Beantwortung (=Reaktion) von Risiken auftreten. Konkret kommt es zu den folgenden fatalen Entscheidungen:
- Fehlentscheidung 1: “Je weniger wir über die Schwachstelle bekannt geben, desto weniger negative Aufmerksamkeit erzeugen wir.”
–> Gerade nach Bekanntwerden einer Schwachstelle ist maximale Transparenz die einzig richtige Antwort. Was genau ist die Schwachstelle? Wo tritt diese auf? Was ist das worst-case Szenario? Nur durch maximale Transparenz kann eine genaue Ursachenbestimmung erfolgen und sichergestellt werden, dass alle Beteiligten das Risiko ausreichend verstehen, um Gegenmaßnahmen einzuleiten.
Die Schwachstelle sollte nie als Fehler einer einzelnen Person oder des Unternehmens angesehen werden, sondern als eine Möglichkeit zu Reagieren. Die Antwort auf eine Schwachstelle (nicht die Schwachstelle selbst) bestimmt in großem Rahmen, welcher Schaden tatsächlich angerichtet werden kann.
- Fehlentscheidung 2: Es werden verantwortliche Personen für die Schwachstelle gesucht.
–> Es kommt zu einer fatalen Fehlerkultur im Unternehmen, bei der Fehler nicht mehr offen kommuniziert und korrigiert werden.
–> Fehler werden als Versagen interpretiert. Lerneffekte und gemeinsames Wachstum bleiben aus.
- Fehlentscheidung 3: Um im Vorhinein die Identifikation einer kritischen Schwachstelle unwahrscheinlicher zu machen, wird bewusst ein stark eingeschränkter Scope für den Pentest gewählt. Hier ein paar Beispiele:
- Es wird nur ein bestimmtes Nutzer-Frontend als “in-scope” betrachtet. Administrative Komponenten dürfen nicht getestet werden.
- Für den Pentest wird eine Nutzerumgebung bereitgestellt, die keine oder unzureichend viele Testdaten enthält, wodurch essentielle Anwendungsfunktionen nicht getestet werden können.
- In der produktiven Umgebung “dürfen keine Daten abgesendet werden”. Der Pentest kann somit effektive keine Eingabeverarbeitung testen.
- Der Einsatz von Intrusion Prevention Systemen oder Web Application Firewalls wird nicht angegeben. Der Pentest wird durch diese Systeme behindert. Ein Ergebnis bildet nicht mehr adäquat das Risiko der Anwendung selbst ab.
–> Diese oder weitere Beschränkungen führen zu einem falschen Risiko-Abbild des Zielsystems. Anstelle Schwachstellen so früh wie möglich zu erkennen, wächst die Komplexität und das Risikopotential der Anwendung schrittweise. Wenn eine Schwachstelle verspätet erkannt wird, wird es aufwändiger und damit kostenintensiver diese zu schließen.
Fazit
Als Pentest Dienstleister ist es uns wichtig, dass unsere Kunden den maximalen Nutzen aus einem Pentest ziehen können. Aus diesem Grund führen wir häufig Diskussionen im Team, um Trends zu erkennen und bestmögliche Empfehlungen zu geben. Dieser Artikel ist das Resultat dieser Diskussionen über die letzten Jahre und möchte neue Sichweisen auf die Pentest Ergebnisse eröffnen.
Haben Sie Fragen oder brauchen Sie Unterstützung bei den Themen Pentesting, Secure Software Development oder der Verbesserung von internen Prozessen? Nutzen Sie gerne das Kontaktformular, wir unterstützen Sie gerne.