Das Erstellen von Dokumentationen oder das Verfassen von Berichten ist für die meisten Techniker keine beliebte Aufgabe. Die IT-Sicherheit bildet hier keine Ausnahme. Neben technischem Wissen sollten Penetration Tester auch die Fähigkeit haben, Berichte zu schreiben und klar zu kommunizieren, auch mit Personen, die keine vertieften technische Kenntnisse haben. Der Bericht zeigt dem Kunden, was in einem Test geprüft und festgestellt wurde. Die meisten Kunden bekommen nicht mit, was während eines Tests passiert, daher gilt: Was nicht im Bericht steht, ist auch nicht passiert.

Nicht weniger wichtig ist die Dokumentation von Techniken, Werkzeuge, Erfahrungen und Wissen. Neu gelernte Techniken und gemachte Erfahrungen sollten so festgehalten werden, dass sie auch in der Zukunft nützlich sind, mit anderen geteilt werden können oder erstmals überhaupt nach einem halben Jahr wieder gefunden werden. Manchmal weiss man noch, dass man etwas schon einmal aufgeschrieben hatte, findet aber keine Aufzeichnungen mehr darüber.

Bericht

Nach dem Abschluss einer Sicherheitsprüfung erhält der Kunde einen Bericht. Der Bericht soll Schwachstellen aufzeigen und Empfehlungen zu deren Behebung geben. Es wird festgehalten, was der Scope der Prüfung war, welche Bereiche getestet wurden und wie der Test ausgefallen ist. Schwachstellen sollen so dokumentiert sein, dass sie durch den Kunden nachvollziehbar sind.

Unsere Berichte sind nach dieser Struktur aufgebaut:

• Summary: Management Summary, Resultatgrafiken, Fragen und Antworten
• Administration: Änderungsprotokoll, Verteilerliste, Projektteam
• Einleitung: Beschreibung und Ziele des Projekts, Scope-Definition
• Resultate: Modalitäten, Auflistung Resultate mit Gegenmassnahmen
• Appendix: Liste der eingesetzten Tools, Definierung Schweregrad, Indexierungslisten

Auf die Inhalte Management Summary und Resultate wird weiter im Text eingegangen. Im Kapitel Einleitung des Berichts werden Auftrag und der Scope festgelegt. Es wird beschrieben, welchen Umfang die Sicherheitsprüfung und der Bericht haben und ob bestimmte Bereiche nicht geprüft wurden. Die Modalitäten enthalten technische Informationen, welche Benutzerkonten mit welchen Berechtigungen, welche Systeme und IP-Adressen verwendet wurden und von wann bis wann die Prüfung dauerte. Ebenso wird eine Liste der für die Überprüfung erhaltenen Dokumente erstellt. Es wird dokumentiert, ob Sicherheitskontrollen wie eine Web Application Firewall (WAF) deaktiviert wurden und ob während der Prüfung Änderungen wie die Installation von Updates vorgenommen wurden.

Management Summary

Das Management Summary wird adressatengerecht verfasst. Die Formulierungen sollten klar und einfach verständlich sein. Technische Details gehören in der Regel nicht in ein Management Summary, es sei denn, es handelt sich explizit um einen technischen Leserkreis. Dies kann schwierig sein, da der innere Drang unterdrückt werden muss, die Ausnutzung einer komplexen Schwachstellen in allen Einzelheiten zu demonstrieren. Die Ausnutzung der Schwachstelle kann jedoch im Kapitel Resultate ausführlich beschrieben werden.

Die Erfahrung beim Schreiben von Berichten lehrt, dass das Management Summary nicht allen gefallen wird. Insbesondere Ergebnisse mit kritischen Schwachstellen können zu Diskussionen und Kontroversen führen. Deshalb sollte das Summary faktenbasiert geschrieben sein und auf Politik oder gar Polemik verzichtet werden. Die Ergebnisse müssen nachvollziehbar dokumentiert und die Bewertungen messbar sein, da sie als Grundlage für die Aussagen im Summary dienen.

Zu jeder Bewertung in einem Management Summary respektive im gesamten Dokument gehört eine Metrik. Es muss klar sein, wie eine Bewertung zustande kommt oder wie eine Aussage zu messen ist. Der Satz “Das Resultat ist genügend”, ohne zu definieren, was genügend ist, lässt Interpretationsspielraum und macht es dem Leser unmöglich, das Resultat einzuordnen. Auch die Frage, wie viele der Findings behoben werden müssen, damit das Resultat als gut eingestuft wird, kann so nicht fundiert beantwortet werden. Im Artikel zum HardeningKitty Score habe wir uns mit dem Sinn und Unsinn einer solchen Bewertung für ein komplexes Konstrukt auseinandergesetzt. Wir verzichten daher auf so eine einfache Bewertung und listen stattdessen im Management Summary in einem Absatz kritische und wichtigsten Schwachstellen, die Statistik der gefundenen Schwachstellen sowie in weiteren Abschnitten die Stärken und Schwächen des Prüfobjekts auf.

Resultate

Veit Hailperin hatte sich bereits 2016 im Artikel Checklisten oder Szenarien mit der idealen Art der Dokumentation einer Sicherheitsprüfung beschäftigt. Wir verwenden nach wie vor Checklisten für Konzept-, Konfigurations- und Systemreviews sowie für Penetration Tests von Web- oder Mobile-Applikationen. Bei Assessments, wie der Simulation bestimmter Angriffstechniken oder einem Red Team Assessment, setzten wir auf eine Mischung aus szenario- und checklistenbasierten Dokumentation.

Wir dokumentieren alle Tests in Checklisten, um transparent zu machen, was alles geprüft wurde und um die Vollständigkeit zu gewährleisten. Der Kunde erfährt nicht nur, wo die Schwachstellen seines Zielobjekts liegen, sondern auch, welche Bereiche bereits gesichert sind. Wird eine Schwachstelle gefunden, dokumentieren wir diese so, dass der Kunde sie bei Bedarf selbst reproduzieren kann. Hier können technische Details dargestellt und gezeigt werden, wie eine Schwachstelle ausgenutzt werden konnte. Der innere Drang, den Proof of Concept (PoC) in allen Details nachzuweisen, kann und soll hier ausgelebt werden. Dazu gehört neben der technischen Beschreibung einer Schwachstelle auch die Beweisführung, beispielsweise durch das Hinzufügen von Requests und Responses im Falle einer Web-Schwachstelle. Für jede Schwachstelle wird ein Schweregrad festgelegt. Wir verwenden die Einstufungen Passed, Low, Medium, High und Emergency, welche am Industriestandard CVSS v3.1 angelehnt sind. Zusätzlich wird für jede Schwachstelle auch eine Gegenmassnahme vorgeschlagen.

Neben dem Report als PDF geben wir die Resultate in einem maschinenlesbaren Format ab, entweder in unserem eigenen oder in einem vom Kunden definierten Format. Dies soll die Weiterverarbeitung der Resultate erleichtern, so dass diese in ein Risk-Management- oder Ticket-System importiert werden können, ohne dass ein Kopieren und Einfügen aus einem PDF erforderlich ist.

Dokumentation von Wissen

Neben dem Verfassen eines Berichts ist das Dokumentieren von Wissen eine weitere wichtige Tätigkeit, welche die Fähigkeiten im Schreiben von Texten erfordert. Auch wenn das Wissen nur für sich selbst festgehalten wird. Was zum Zeitpunkt der Anwendung völlig klar erscheint, bedarf zu einem späteren Zeitpunkt, wenn man sich schon länger nicht mehr mit dem Thema beschäftigt hat, einer zusätzliche Erklärung. Deshalb sind Notizen so wichtig und kleinere Details können den Unterschied zwischen Erfolg und Misserfolg ausmachen. Wenn beispielsweise bei einem Tool ein bestimmter Parameter notwendig ist, damit der Angriff erfolgreich ist, dieser Parameter aber nur beiläufig im Aufruf steht, ohne dass darauf hingewiesen wird, dass er korrekt gesetzt werden muss, kann dies leicht untergehen. Insbesondere dann, wenn die eigenen Notizen nun doch mit jemand anderem geteilt werden und diese Person sich der Bedeutung nicht bewusst ist.

Die Projekte The Hacker Recipes von Charlie Bromberg sowie PayloadsAllTheThings und Internal All The Things von Swissky sind vorbildlich und eine tolle Wissensquelle.

Der Informationsfluss im Bereich der IT-Security ist enorm und Veränderungen treten häufig auf. Neue Tools und Angriffstechniken werden veröffentlich, bestehende Techniken werden detektiert und müssen angepasst werden oder es werden neue Schwachstellen entdeckt, die bisher ungeahnte Möglichkeiten bieten. Wissen wird nicht nur durch neue Informationen erworben, sondern auch durch eigene Recherchen, Training, Teilnahme an Weiterbildungen und Konferenzen oder auch durch den Austausch mit Gleichgesinnten. Um all dieses Wissen festhalten zu können, braucht es Schreibfähigkeiten, Disziplin, aber auch die richtigen Werkzeuge.

Werkzeuge

Im Laufe der Zeit habe ich verschiedene Tools ausprobiert. Zu Beginn war das ungeordnete Sammeln von Bookmarks, Textdateien und PDFs, darauf folgte Notepad++ mit Plugins und Tools wie Microsofts OneNote oder später die Open-Source-Alternative CherryTree. Während OneNote ein proprietäres Format zum Speichern der Notizbücher verwendet, unterstützt CherryTree SQLite oder XML-Dateien. Ich wollte weg von Tools, die alles in eine Datei packen, und habe Markdown mit Sublime und ReStructuredText mit Sphinx ausprobiert und je nach Projekt immer noch im Einsatz. Aktuell verwende ich Obsidian und bin daran meine bestehenden Sammlungen zu konvertieren.

Obsidian arbeitet mit dem Markdown-Format, ermöglich das Erstellen von Strukturen und unterstützt das Verbinden von Notizen mit Links, stellt Verknüpfungen in Graphen dar und bietet die Möglichkeit einfache Diagramme oder Workflows zu zeichnen. Zudem kann mit Templates vieles automatisiert und vorgegeben werden. Sam Link von TrustedSec zeigt im Artikel Obsidian, Taming a Collective Consciousness wie dies genutzt werden kann.

Anwendung

Werkzeuge allein nützen nichts, sie müssen auch eingesetzt werden. Meine Vorgehen ist so, dass ich eine Liste mit offenen Aufgaben führe, neue Informationen wie zum Beispiel ein Tool landen in dieser Liste. Nach der Abarbeitung eines Punktes der Liste und der Informationsverarbeitung dokumentiere ich dies entsprechend. Meistens geschieht dies in meinem persönlichen Obsidian Vault. Die Dokumentation ist zunächst knapp gehalten, beispielsweise eine Liste von Befehlen, wie etwas angewendet respektive umgesetzt wird. Mit Obsidian kann ich diese neue Information mit bestehendem Wissen verknüpfen, beispielsweise wenn ich eine neue Angriffstechnik dokumentiere, kann ich diese in die bestehende Struktur einbetten und Links zu ähnlichen Techniken oder der Grundlagendokumentationen setzen. Als nächstes versuche ich die Befehle zu verallgemeinern, unter anderem durch Verwendung von Variablen anstelle festen Werten. Ausserdem beschreibe ich, was mit dem Befehl bezweckt wird und erwähne, warum ein bestimmter Parameter so gesetzt werden muss oder was sonst noch zu beachten ist. Je nach Thema gebe ich die Informationen weiter, indem ich sie in eine bestehende Sammlung einfüge oder anderweitig veröffentliche.

Natürlich ist manchmal das Verlangen, das neues Wissen auszuprobieren und weiter zu experimentieren, grösser ist als die Motivation, das erarbeitete Wissen noch sauber aufzuschreiben, oder die Dokumentation bleibt dann erstmals halbfertig. Aus der Erfahrung heraus, dass mich die unfertige Dokumentation früher oder später einholen wird, stelle ich mir dann eine Aufgabe mit Erinnerung, die Dokumentation später fertig zu stellen. Für mich funktioniert das gut, andere haben andere Tricks und Angewohnheiten um dies zu lösen. Wichtig ist, dass es gelingt, das Gelernte vollständig zu dokumentieren.

Fazit und Ausblick

Das Verfassen von Berichten und Dokumentationen ist nicht jedermanns Sache. In unserer Arbeit ist es jedoch unerlässlich und es sollte entsprechend geübt werden. Übung, Erfahrung und Diskussionen mit Kunden und Kollegen verbessern die eigenen Fähigkeiten, einen guten Bericht zu verfassen. Spätestens wenn man einen Retest mit einem Bericht durchführen muss, den man nicht selbst geschrieben hat, schätzt man eine ausführliche, klare Beschreibung mit technischen Details und reproduzierbaren Beispielen.

Das Dokumentieren von Wissen mag auf den ersten Blick keine glamouröse Tätigkeit sein, aber ohne Dokumentation ist es schwieriger, Wissen zu teilen. Es ist auch schwierig, eine komplexe Angriffstechnik zu reproduzieren, wenn keine Notizen über den Aufbau und die Anwendung vorhanden sind. Zudem wenn etwas vollständig niedergeschrieben ist, bleibt es auch länger erhalten. Ein passendes Werkzeug vereinfacht die Dokumentation. Wir sind dankbar für all die Arbeit, die in die Dokumentation von Protokollen, Angriffstechniken, Tools und vielem mehr gesteckt wird. Das macht es uns leichter neues Wissen zu erwerben. Deshalb leisten wir unseren Beitrag, indem wir Dokumentationen erstellen und teilen.

Es gibt noch einen Elefant im Raum und zwar die Nutzung von Large Language Models (LLM) zur Erstellung von Berichten. Eine Liste von Findings wird einem LLM zur Verfügung gestellt und heraus kommt ein Bericht inklusive Management Summary. Das ein Wunschtraum, der auch in einigen Jahren noch nicht Realität sein wird. LLM-Tools können unterstützend für die Generierung der Beschreibung einzelner Findings oder Gegenmassnahme, zur Übersetzung von Texten oder zur Verbesserung des Stils eingesetzt werden. Das ein LLM ein akkurates Management Summary verfassen wird oder gar einen vollständigen Bericht erstellen kann, daran glaube ich im Moment nicht (Januar 2024). Ich lasse mich gerne eines Besseren belehren.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master
• https://notepad-plus-plus.org/
• https://obsidian.md/
• https://onenote.com/
• https://swisskyrepo.github.io/InternalAllTheThings/
• https://swisskyrepo.github.io/about/
• https://twitter.com/_nwodtuhs
• https://www.first.org/cvss/calculator/3.1
• https://www.giuspen.net/cherrytree/
• https://www.hailperin.ch/
• https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html
• https://www.sublimetext.com/
• https://www.thehacker.recipes/
• https://www.trustedsec.com/
• https://www.trustedsec.com/blog/obsidian-taming-a-collective-consciousness