Feb 25, 2020 von Sven Vetsch, Dominique Meier
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.
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:
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 :