Die vielleicht wichtigste Phase innerhalb eines Penetration-Testing-Projekts ist das Reporting. Aus Sicht eines Security Testers mag die Reporting-Phase im Vergleich zum eigentlichen Penetration Test nicht sehr aufregend erscheinen, allerdings ist der Report das primäre Lieferobjekt des Projekts und dessen Inhalt somit für den Kunden essentiell. Gleichzeitig ist es im Interesse des Kunden wie auch der Security Tester, möglichst viel der verfügbaren Projektzeit für das Testing zu verwenden. Um dies zu erreichen, sind wir bei Redguard überzeugt, dass effizientes und qualitativ hochwertiges Reporting neben der eigentlichen Testqualität der Schlüssel ist, um professionelle Penetration-Testing-Dienstleistungen anbieten zu können.

Bereits bei der Gründung von Redguard im Jahr 2012 wurden basierend auf den bestehenden Erfahrungen festgelegt, dass Redguard keine Penetration Testing Reports in der Form von Word-Dokumenten erstellen wird, sondern geeignete Reporting-Werkzeuge zu verwenden sind. Nicht, das Microsoft Word kein grossartiges Werkzeug wäre, um Texte zu schreiben, aber ein Penetration Testing Report ist weit mehr als ein einfacher Text und bedarf deshalb zur Erstellung eines adäquaten Werkzeugs.

• In einem Penetration Testing Report geht es um Daten, nicht Text.
• Ein Penetration Test sollte immer von mindestens zwei Security Testern durchgeführt werden. Alle involvierten Security Tester tragen zum finalen Report bei, Kollaboration ist dabei essentiell.
• Speziell bei umfangreichen Projekten gibt es oft sehr viele Findings. Diese aufeinander abzugleichen und den Überblick zu behalten ist schwierig und bedarf einer stetigen Navigation quer durch das gesamte Dokument.
• Jedes Projekt und somit auch jeder Report ist individuell, allerdings gibt es oft sich wiederholende Findings wie beispielsweise Cross-Site Scripting oder SQL Injection Schwachstellen. Diese Inhalte müssen wiederverwendbar sein, und zwar über verschiedene Projekte hinweg.
• Ein Penetration Test ist nie komplett losgelöst, sondern spätestens die gefundenen Risiken und Schwachstellen müssen oft in bestehende Applikationen wie beispielsweise ein Risiko-Register übertragen werden können. Ein professioneller Penetration Testing Service bringt deshalb die Möglichkeit mit sich, Resultate in verschiedenen Formaten bereitzustellen. Dies können beispielsweise einfache PDF-Dokumente aber auch CSV, JSON, klassische Excel-Listen oder durch den Kunden definierte Formate sein.
• Formatierungen helfen, Inhalte klarer darzustellen, aber die verwendeten Formatierungen sollten konsistent eingesetzt werden.

Um diese Defizite eines Word-Dokuments zu adressieren, hat Redguard bereits 2012 mit ein paar Ruby-Skripten damit begonnen, Penetration Testing Reports basierend auf Findings der Security Tester zu generieren. Um ehrlich zu sein, hat dies initial eher schlecht als recht funktioniert; wir hatten XML-basierte Vorlagen, in denen wir mit Text-Editoren unsere Findings einfüllten, um dann ein paar Skripte darüber laufen zu lassen, die erst ein HTML- und dann daraus zusammen mit ein wenig JavaScript und CSS ein PDF-Dokument generierten. Funktioniert hat dies zwar, allerdings war insbesondere der Aufwand manuell in XML-Dateien zu arbeiten höher als wenn jeder Security Tester ein Word-Dokument geschrieben hätte und am Ende alles irgendwie zusammengefügt worden wäre.

Ein Finding aus einem unserer ersten Reports im Jahr 2012

Schnell wurde uns klar, dass die grundlegende Idee zwar gut war, die Implementation allerdings gelinde gesagt noch nicht dort war, wo wir uns dies wünschten. Zu diesem Zeitpunkt wurde innerhalb von Redguard ein Grundsatzentscheid getroffen; Penetration Testing Reports sind ein so essentieller Bestandteil unserer Dienstleistungen, dass wir die Erstellung dieser in einer eigens dafür zu schaffenden Applikation abbilden wollten. Wir sprachen dann über diese Idee mit unserem heutigen Head of Operations Dominique Meier, welcher zu diesem Zeitpunk auf der Suche nach einem Thema für seine Bachelor Thesis war. Dies war auch der Zeitpunkt, zu dem erstmals der Begriff Reporting Engine aufkam - kein sehr kreativer Name, aber genau das, was wir wollten. Dominique nahm sich die bestehenden Ruby-Skripte und Vorlagen und verwandelte alles in eine intuitive, web-basierte Ruby-on-Rails-Applikation. Nicht nur erlaubte diese Applikation nun das Plugin-basierte Importieren von Resultaten aus verschiedenen automatisierten Security-Testing-Werkzeugen und das Zusammenführen von ähnlichen Findings, sondern erstmals eine echte Echtzeit-Kollaboration zwischen den involvierten Security Testern innerhalb eines Penetration Tests.

Erste Version der Reporting Engine (links) im Vergleich zu heute (rechts)

Nach dem Abschluss von Dominiques Bachelor Thesis ging die Reporting Engine direkt in Produktion. Seit damals wurde jeder Penetration Testing Report, welcher durch Security Tester der Redguard erstellt wurde, in der Reporting Engine geschrieben und daraus exportiert. Die erste Version der Reporting Engine war selbstredend noch nicht perfekt und neben verschieden Bugs fehlte eine Vielzahl von Features, die man sich als Security Tester wünscht. Um das Tool noch besser zu machen, hat Redguard explizit für die Weiterentwicklung der Reporting Engine einen Software Engineer eingestellt und dieser entwickelt dieses für die Redguard essentielle Werkzeug auch heute noch stetig weiter. Immer wieder hören wir, dies sei doch extrem teuer nur um das Penetration-Test-Reporting-Werkzeug zu verbessern. Ja, allerdings ist es das - insbesondere basierend auf den vielen positiven Kundenrückmeldungen zu unserem Report - absolut wert.

Nicht abschliessend nachfolgend einige Features der Reporting Engine:

• Wir haben Datenmodelle für alles, was in einen Penetration Testing Report gehört, beispielsweise sogar automatisierte Referenzen auf CVEs oder OWASP cheat sheets. So können wir Reporting-Aufgaben automatisieren und Daten so verarbeiten, dass sie für unsere Kunden bestmöglich interpretiert und weiterverwendet werden können. Auch die tiefgehende Analyse von Risiken, beispielsweise wie wahrscheinlich es ist, eine gewisse Risikoklasse in einem definierten Test-Scope zu identifizieren, wird dadurch ermöglicht, was eine Bewertung von Business-Risiken zulässt.
• Alles ist zentral an einem Ort und alle Security Tester arbeiten mit derselben web-basierten Applikation gleichzeitig. Sobald ein Security Tester ein neues Risiko erfasst, ist dieses auch umgehend für alle Security Tester verfügbar. Dies erlaubt es, Workflows wie Review-Prozesse effizient in der Reporting Engine umzusetzen.
• Sich lange durch alte Reports zu wühlen, um bereits einmal rapportierte Risiken wieder zu finden und diese in einem aktuellen Report wieder zu verwenden ist mit der Reporting Engine nicht notwendig. Durch unser auf Elasticsearch basierendes Backend haben wir die Möglichkeit einer Volltextsuche über alle Findings, die jemals erfasst wurden.
• Sensitive Informationen wie Kundennamen oder IP-Adressen werden als solche markiert und automatisch entfernt, wenn beispielsweise ein Risiko als Template in einem anderen Projekt wiederverwendet wird. So können wir sicherstellen, dass Kundeninformationen immer getrennt voneinander bleiben und sich nie vermischen.
• Das UI ist dafür optimiert, um auch riesige Scopes zu navigieren. Insbesondere bei Schwachstellen-Scans können gut einmal ein paar hundert komplett unterschiedliche Risiken auftauchen.
• Ähnliche Risiken werden voll-automatisiert zusammengefasst oder können auch einfach manuell zusammengeführt werden.
• Wir verwalten eine zentrale Sammlung von Risiko-Klassen innerhalb der Reporting Engine, die als Templates für neue Risiken verwendet werden können und so die benötigte Bearbeitungszeit minimieren.
• Die Reporting Engine beinhaltet eine Vielzahl von Import-Plugins für gängige Security Tools. So können Exports aus Werkzeugen wie Nessus und burp oder auch Docker Image Security Scanner wie Clair einfach eingelesen werden. Neue Tools? Kein Problem. Im Schnitt können neue Import Module innert 30 Minuten implementiert werden.
• Durch die Verwendung von plugin-basierten Exports, können wir unseren Kunden die Reports in einer Vielzahl, insbesondere auch auf Kundenwünsche zugeschnittenen, Formate anbieten.
• Alles wird in Markdown geschrieben, womit wir Probleme und Inkonsistenzen mit der Formatierung wie etwa unterschiedliche Schriftgrössen verhindern können.
• Die Reporting Engine unterstützt verschiedene Sprachen und erlaubt es uns so, unseren Kunden Reports in der von ihnen präferierten Sprache abgeben zu können.

Die Reporting Engine hat sich zu einem unverzichtbaren Werkzeug für unsere Security Tester entwickelt und im direkten Vergleich zu den Anfangszeiten, bevor wir sie hatten, konnten wir die Reporting-Zeit um 50-60% reduzieren. Dies bedeutet, dass wir mit demselben Projektaufwand mehr testen können und unsere Kunden somit ebenfalls direkt von unserer Reporting Engine profitieren.

Du bist ein Security Tester, der seine Reports noch immer in Word schreiben muss? Wir sind immer auf der Suche nach weiteren Security Testern für unser Team und die Reporting Engine erwartet dich 😉

Cet article de blog est également disponible en français :

Un reporting efficace des tests d’intrusion