Wie schreibt man einen guten Sicherheitsaudit-Bericht?
Selbst das beste Sicherheitsaudit einer Website oder Anwendung wird wenig nützen, wenn wir die erkannten Bedrohungen, Reproduktionsschritte, potenzielle Bedrohungen durch deren Nutzung und Empfehlungen zur Behebung des Fehlers nicht dokumentieren. Wir zeigen Ihnen, wie Sie Schritt für Schritt einen detaillierten Bericht erstellen.
Was sollte ein guter Sicherheitsaudit-Bericht enthalten?
Sowohl der visuelle als auch der inhaltliche Aspekt ist wichtig. Der Bericht sollte ästhetisch sein, aber sein visueller Teil sollte nicht dominieren und die Aufnahme seines Inhalts nicht beeinträchtigen. Schließlich ist der Inhalt des Berichts von entscheidender Bedeutung. In diesem Artikel konzentrieren wir uns auf den inhaltlichen Teil. Anhand konkreter Beispiele präsentieren wir die einzelnen Bestandteile eines Dokuments, das ein Sicherheitsaudit zusammenfasst, nämlich:
- Gegenstand der Arbeit,
- Zusammenfassung der durchgeführten Aktivitäten und deren Ergebnisse,
- detaillierte Beschreibung der erkannten Bedrohungen.
Erster Abschnitt – ein Titelblatt mit dem Gegenstand des Audits
In diesem Teil sollten wir Informationen über den Inhalt des Dokuments einfügen und angeben, dass es sich um einen Sicherheitsaudit-Bericht handelt. Zusätzlich sollten wir den Gegenstand der Arbeit spezifizieren, das heißt die Elemente, für die die Sicherheitsprüfungen durchgeführt wurden. Das Datum der Durchführung der Arbeit, der Standort und die für das Audit verantwortlichen Personen sollten ebenfalls angegeben werden. Das Titelblatt sollte nur den wesentlichen und allgemeinen Gegenstand der Arbeit enthalten.
Wenn die Foo-Anwendung, ihre API, der Quellcode und die Infrastruktur, auf der sie betrieben wird, getestet wurden, sollten diese Elemente auf der ersten Seite des Berichts stehen. Wenn hingegen die gesamte Anwendung geprüft wurde, sollte sie nicht in einzelne Teile unterteilt werden, wenn der Gegenstand des Audits angegeben wird, sondern als Ganzes beschrieben werden. Die Zeit für die Unterteilung des Audits in kleinere und detailliertere Teile wird später kommen.
Sicherheitstests-Bericht – ein Beispiel
Gegenstand der Arbeit:
- Penetrationstests der Foo-Anwendung
- Sicherheitstests der API der Foo-Anwendung
- Analyse des Quellcodes der Anwendung
- Penetrationstests der Infrastruktur der Anwendung
Datum der Durchführung:
01/10/2021 - 10/10/2021
Ort der Durchführung:
Wrocław
Auditoren:
Jan Kowalski
Zweiter Abschnitt – die Zusammenfassung des Inhalts des Berichts
Die folgenden Seiten sollten die Zusammenfassung der Arbeit enthalten. Sie können verwendet werden, um den Gegenstand der Arbeit detaillierter zu beschreiben als auf dem Titelblatt. Die Zusammenfassung ist auch der Ort, um die gesammelten Ergebnisse des durchgeführten Sicherheitsaudits zu teilen und über die kritischsten während des Audits gefundenen Schwachstellen zu informieren. Die kritischen Schwachstellen sollten kurz beschrieben werden. Alle Schwachstellen werden später im Bericht ausführlicher beschrieben.
In der Zusammenfassung können sich die Leser auch mit der angenommenen Klassifizierung der Schwachstellen vertraut machen. Daher sollten wir alle Ebenen auflisten und eine detaillierte Beschreibung zu jeder von ihnen hinzufügen.
Unten finden Sie ein Beispiel für die Beschreibung der Schwachstellenklassifikationsstufen.
Information
Die Information-Stufe wird nicht als sicherheitsgefährdende Schwachstelle angesehen. Es ist eine Mitteilung, die auf gute Praktiken hinweist, die, wenn sie implementiert werden, das allgemeine Sicherheitsniveau Ihrer Anwendung erhöhen. Auf dieser Ebene sehen wir auch Architektur-Empfehlungen, deren Umsetzung die Sicherheit der Anwendung erhöhen wird.
Niedrig
Die Schwachstelle ist unbedeutend, ihre Nutzung hat einen vernachlässigbaren Einfluss auf die Sicherheit der Anwendung oder die Ausnutzung erfordert Bedingungen, die schwer zu erfüllen sind.
Mittel
Die Schwachstelle ist mäßig signifikant, was bedeutet, dass ihre Ausnutzung bestimmte Bedingungen erfordern kann, die nicht extrem schwer zu erreichen sind. Sie kann Zugang zu einer begrenzten Menge an Daten oder Daten gewähren, die als unbedeutend eingestuft sind.
Hoch
Eine signifikante Schwachstelle, deren Ausnutzung den Zugang zu sensiblen Daten der Anwendung ermöglicht, deren Nutzung jedoch bestimmte Bedingungen erfordert, wie beispielsweise ein Konto mit bestimmten Berechtigungen. Wir definieren als hoch auch die Schwachstellen, die auf einfache Weise ausgenutzt werden können, deren Auswirkungen jedoch nicht kritisch sind.
Kritisch
Die Ausnutzung einer kritischen Schwachstelle ermöglicht die vollständige Kontrolle über den Server oder den Zugang zu wichtigen und vertraulichen Informationen. In der Regel ist sie einfach auszunutzen und erfordert keine bestimmten Bedingungen. Kritische Schwachstellen erfordern sofortige Maßnahmen.
Dritter Abschnitt – die Schwachstellen
Jede Schwachstelle sollte einen kurzen Titel zur Beschreibung der Bedrohung enthalten. Der Titel sollte auch das Kritikalitätsniveau der Schwachstelle enthalten. Dann erstellen wir eine Beschreibung, in der wir die erkannte Bedrohung im Detail präsentieren. Wenn bestimmte Bedingungen erfüllt sein müssen, um die Schwachstelle auszunutzen, sollten sie beschrieben werden. Danach folgt die Beschreibung der technischen Details des Fehlers, in der wir zeigen, wie der Fehler ausgenutzt wird. Am Ende dieses Teils des Sicherheitsaudit-Berichts sollten wir die Empfehlungen aufnehmen, die die Bedrohung nach der Einführung eliminieren.
Beispiel einer Schwachstellenbeschreibung
Einstufung der Schwachstelle: Kritisch
Identifikator der Schwachstelle: FOO_BAR-API-000
Titel der Schwachstelle: Administrator-Modus verfügbar durch manuelles Hinzufügen eines Cookies
Beschreibung
Die Administrator-Autorisierungsanwendung verwendet ein Cookie, das von einem Angreifer erlangt werden kann. Das Konto, auf das auf diese Weise zugegriffen werden kann, wird von der Anwendung als God-Mode-Konto bezeichnet.
Bedingungen, die notwendig sind, um die Schwachstelle auszunutzen: Keine
Technische Details
Der Angreifer muss in der Anwendung ein Cookie mit folgenden Eigenschaften hinzufügen:
Name: code
Wert: iddqd
Empfehlung
Implementierung der Login-Autorisierung und Zwei-Faktor-Authentifizierung beim Zugriff auf ein God-Mode-Konto. Entfernung der Autorisierung über Cookie.
Sicherheitsaudit-Bericht – Zusammenfassung
Die Befolgung einiger einfacher Regeln ermöglicht es, einen Sicherheitsaudit-Bericht effizient zu erstellen, der klar und voller relevanter Informationen ist. Wie wir in der Einleitung angedeutet haben, könnte das Audit selbst in vorbildlicher Weise durchgeführt werden. Wenn jedoch der Bericht (die Zusammenfassung der Arbeit) nicht auf demselben hohen Niveau ist, könnten die Ergebnisse des Audits – alle während seines Verlaufs gezogenen Schlussfolgerungen, alle Kommentare und Empfehlungen – möglicherweise nicht korrekt umgesetzt oder sogar völlig übersehen werden. Der Bericht sollte sowohl auf die angenehmste als auch die sachlichste Weise verfasst werden. Wir sollten auch den visuellen Aspekt eines solchen Dokuments in Betracht ziehen, der das Ganze ästhetisch ansprechend machen sollte, ohne von den Inhalten abzulenken.
Die in diesem Artikel vorgestellten Tipps werden nützlich sein, wenn man Dokumente nach der Durchführung von Audits verschiedener Arten von Anwendungen und Websites einschließlich derer, die auf Drupal basieren, vorbereitet. Wenn Sie zusätzliche Ratschläge zu Sicherheitsberichten von Anwendungen in diesem Framework oder zur Durchführung eines vollständigen Audits benötigen, erfahren Sie mehr über unser Support-Team für Drupal.
