Einen Pentest-Bericht lesen und umsetzen

Der Pentest-Bericht liegt im Postfach, die Geschäftsführung fragt nach den wichtigsten Ergebnissen, und dein IT-Team möchte wissen, was nun konkret zu tun ist. Genau hier entscheidet sich, ob ein Penetrationstest echte Verbesserungen bringt oder als PDF in einer Ablage verschwindet. Ein guter Bericht ist kein reines Technikdokument. Er verbindet beobachtete Schwachstellen mit realistischen Risiken und liefert die Grundlage für priorisierte Maßnahmen.

Was ein Pentest-Bericht leisten soll

Ein Penetrationstest bewertet nicht, ob ein Unternehmen grundsätzlich „sicher“ oder „unsicher“ ist. Er dokumentiert den Sicherheitszustand innerhalb eines klar vereinbarten Prüfauftrags. Dazu gehören Systeme, Anwendungen, Zeiträume, Methoden und Grenzen des Tests.

Der Bericht beantwortet idealerweise vier Fragen:

1. Was wurde im vereinbarten Scope geprüft?
2. Welche Schwachstellen oder Fehlkonfigurationen wurden festgestellt?
3. Welche Auswirkungen könnten diese Findings unter realistischen Bedingungen haben?
4. Welche Maßnahmen reduzieren das Risiko wirksam?

Lies den Bericht deshalb nicht nur als Liste technischer Mängel. Betrachte ihn als Arbeitsgrundlage für Risikomanagement, Betrieb, Entwicklung und Management. Einzelne Findings können zwar technisch ähnlich sein, aber je nach betroffenem System völlig unterschiedliche Folgen haben. Eine fehlende Sicherheitskonfiguration auf einem isolierten Testsystem ist anders zu bewerten als dieselbe Schwachstelle an einem öffentlich erreichbaren System mit Kundendaten.

Den Aufbau eines Berichts richtig einordnen

Die genaue Struktur unterscheidet sich je nach Test-Team und Auftrag. Professionelle Pentest-Berichte enthalten jedoch meist vergleichbare Bestandteile.

Abschnitt	Bedeutung für dich
Management Summary	Fasst Risiken, wesentliche Ergebnisse und Handlungsbedarf für Führungskräfte zusammen
Scope und Methodik	Dokumentiert, welche Ziele, Systeme und Testarten vereinbart waren
Annahmen und Einschränkungen	Zeigt, was nicht geprüft wurde oder welche Bedingungen das Ergebnis beeinflussen
Findings	Beschreibt einzelne Schwachstellen, ihre Auswirkungen und Empfehlungen
Risikobewertung	Ordnet Findings nach Schweregrad und geschäftlichem Kontext ein
Anhang und Evidenzen	Enthält technische Details, Nachweise und gegebenenfalls betroffene Komponenten

Beginne mit der Management Summary, aber bleibe nicht dort stehen. Sie hilft dir bei der Kommunikation mit Entscheiderinnen und Entscheidern, ersetzt jedoch nicht die fachliche Analyse der Einzelbefunde. Für die operative Umsetzung sind insbesondere Scope, Einschränkungen und Findings wichtig.

Prüfe zuerst, ob der Scope deiner Erwartung entspricht. Wurde nur eine Webanwendung untersucht, sagt der Bericht nichts über die Sicherheit interner Netzwerke, Endgeräte oder Cloud-Konfigurationen aus. Wurde ein Test ohne Zugangsdaten durchgeführt, lassen sich daraus nur begrenzte Aussagen über Berechtigungen, interne Rollen oder administrative Funktionen ableiten.

Ein Pentest liefert immer eine Momentaufnahme. Neue Releases, Konfigurationsänderungen, zusätzliche Schnittstellen oder geänderte Berechtigungen können die Lage danach verändern.

Findings verstehen: Schweregrad ist nicht gleich Priorität

Jedes Finding sollte klar benennen, was betroffen ist, worin das Risiko besteht und wie es behoben werden kann. Häufig findest du Angaben wie CVSS, Kritikalität, betroffene Assets, Nachweise und Handlungsempfehlungen.

CVSS, das Common Vulnerability Scoring System, hilft bei der technischen Einordnung einer Schwachstelle. Ein hoher CVSS-Wert kann auf eine erhebliche technische Ausnutzbarkeit oder potenzielle Auswirkung hinweisen. Für deine Priorisierung reicht der Wert allein aber nicht aus.

Berücksichtige zusätzlich den Kontext:

• Ist das betroffene System aus dem Internet erreichbar?
• Welche Daten verarbeitet oder speichert es?
• Welche Geschäftsprozesse hängen daran?
• Gibt es bereits Schutzmaßnahmen wie MFA, Netzwerksegmentierung, Monitoring oder eingeschränkte Berechtigungen?
• Wie realistisch ist eine Ausnutzung in deiner Umgebung?
• Kann ein Angriff Folgeschäden in anderen Systemen verursachen?
• Gibt es regulatorische, vertragliche oder datenschutzrechtliche Anforderungen?

Ein Finding mit mittlerem technischen Schweregrad kann höchste Priorität haben, wenn es eine kritische Anwendung betrifft und sensible Daten offenlegt. Umgekehrt kann ein hoher CVSS-Wert zunächst geringer priorisiert werden, wenn das System abgeschottet ist und wirksame kompensierende Kontrollen bestehen. Diese Entscheidung muss nachvollziehbar dokumentiert werden. Sie ist keine Einladung, Risiken kleinzureden.

Achte zudem auf Angriffsketten. Mehrere einzeln moderat bewertete Schwachstellen können zusammen ein hohes Risiko bilden. Typische Beispiele sind zu weit gefasste Berechtigungen, unzureichende Protokollierung und fehlende MFA für einen administrativen Zugang. Der Bericht sollte solche Zusammenhänge erläutern. Falls nicht, frage gezielt nach.

Aus Findings konkrete Maßnahmen ableiten

Überführe jedes relevante Finding in einen nachverfolgbaren Maßnahmenprozess. Ein bloßer Vermerk wie „Patch einspielen“ ist selten ausreichend. Gute Maßnahmen beschreiben Verantwortlichkeit, Zielzustand, Frist, Abhängigkeiten und Prüfkriterien.

Eine praxistaugliche Maßnahmenübersicht kann so aussehen:

Feld	Beispielhafte Inhalte
Finding-ID	Eindeutige Referenz aus dem Pentest-Bericht
Betroffenes Asset	Anwendung, Server, Cloud-Ressource oder Prozess
Risiko	Technischer Schweregrad plus geschäftliche Auswirkung
Maßnahme	Patch, Konfigurationsänderung, Berechtigungsanpassung oder Prozessverbesserung
Verantwortlichkeit	Fachteam oder benannte Person mit Umsetzungsverantwortung
Zieltermin	Risikobasiert und realistisch festgelegt
Übergangskontrolle	Temporäre Schutzmaßnahme bis zur endgültigen Behebung
Validierung	Nachweis, wie die Wirksamkeit geprüft wird
Status	Offen, in Umsetzung, umgesetzt, akzeptiert oder erneut zu prüfen

Unterscheide zwischen Sofortmaßnahmen und nachhaltiger Behebung. Wenn eine kritische Schwachstelle nicht unmittelbar vollständig beseitigt werden kann, brauchst du eine dokumentierte Übergangskontrolle. Das kann etwa eine restriktivere Firewall-Regel, die Deaktivierung einer nicht benötigten Funktion, zusätzliche Überwachung im SIEM oder eine kurzfristige Einschränkung von Berechtigungen sein.

Eine Übergangskontrolle ist kein Ersatz für die eigentliche Behebung. Lege deshalb immer einen Termin und eine verantwortliche Stelle für die dauerhafte Maßnahme fest.

Bei Softwareproblemen reicht es oft nicht, nur eine einzelne Stelle zu korrigieren. Prüfe auch, warum die Schwachstelle entstanden ist. Fehlen sichere Entwicklungsstandards, Code Reviews, Abhängigkeitsprüfungen oder Tests für Berechtigungslogik? Dann gehört eine Verbesserung des Entwicklungsprozesses zur Maßnahme. Das gilt besonders für wiederkehrende Schwachstellen aus den Bereichen OWASP, Zugriffskontrolle, Eingabevalidierung und Sicherheitskonfiguration.

Zusammenarbeit mit dem Test-Team organisieren

Ein guter Pentest endet nicht mit der Übergabe des Berichts. Plane ein fachliches Abschlussgespräch ein, an dem neben dem Test-Team auch die zuständigen Personen aus Betrieb, Entwicklung, Architektur und Informationssicherheit teilnehmen.

Bereite konkrete Fragen vor:

• Welche Findings sind aus Sicht des Test-Teams besonders zeitkritisch?
• Welche Angriffsketten oder Abhängigkeiten sind entscheidend?
• Welche Annahmen lagen der Risikobewertung zugrunde?
• Welche Maßnahmen beheben die Ursache statt nur das Symptom?
• Welche Empfehlungen sind zwingend, welche verbessern das Sicherheitsniveau zusätzlich?
• Wie kann eine spätere Validierung sinnvoll erfolgen?

Das Test-Team sollte technische Sachverhalte verständlich erklären können, ohne unnötige Details zu verschweigen. Umgekehrt braucht es von dir Informationen über Architektur, Datenklassifikation, Schutzbedarf und Betriebsgrenzen. Erst diese Zusammenarbeit ermöglicht eine belastbare Risikobewertung.

Wichtig ist auch eine klare Fehlerkultur. Ein Finding ist kein persönliches Versagen einzelner Administratorinnen, Administratoren oder Entwicklerinnen und Entwickler. Es zeigt eine Verbesserungschance im System aus Technik, Prozessen und Verantwortlichkeiten. Wenn Teams befürchten müssen, für jedes Finding verantwortlich gemacht zu werden, werden Risiken eher verdeckt als gelöst.

Sicherheitstests dürfen ausschliesslich mit ausdrücklicher schriftlicher Beauftragung, definiertem Scope und klaren Regeln erfolgen. Ohne Auftrag kann das Prüfen fremder Systeme strafbar sein. Diese allgemeine Einordnung ersetzt keine Rechtsberatung.

Umsetzung nachhalten und Wirksamkeit prüfen

Ein geschlossenes Ticket beweist noch nicht, dass eine Schwachstelle wirklich behoben ist. Prüfe daher nach der Umsetzung, ob die Maßnahme wirksam ist und keine neuen Risiken erzeugt hat.

Die Validierung kann je nach Finding unterschiedlich aussehen:

• Konfigurationsänderungen werden anhand eines Sollzustands und geeigneter Kontrollmechanismen geprüft.
• Patches werden auf den betroffenen Systemen nachvollziehbar verifiziert.
• Berechtigungsänderungen werden mit dem Least-Privilege-Prinzip abgeglichen.
• Neue MFA-Vorgaben werden für alle vorgesehenen Konten und Zugangswege kontrolliert.
• Verbesserte Protokollierung wird durch prüfbare Ereignisse im SIEM bestätigt.
• Änderungen an Anwendungen werden durch Sicherheitsprüfungen im Entwicklungsprozess abgesichert.

Für besonders kritische Findings kann ein gezielter Retest sinnvoll sein. Dabei prüft das beauftragte Test-Team innerhalb eines klaren Scopes, ob die festgestellte Schwachstelle nicht mehr besteht. Ein Retest ist keine vollständige Wiederholung des Pentests, sondern eine fokussierte Wirksamkeitskontrolle.

Dokumentiere auch akzeptierte Restrisiken. Manchmal ist eine vollständige Behebung kurzfristig nicht möglich, etwa wegen Altanwendungen oder unvermeidbarer Betriebsabhängigkeiten. Dann braucht es eine nachvollziehbare Risikoentscheidung durch die zuständige Stelle, wirksame Kompensationsmaßnahmen und einen überprüfbaren Plan für die weitere Behandlung. „Nicht umsetzbar“ ist keine ausreichende Risikobewertung.

Aus dem Bericht einen dauerhaften Verbesserungsprozess machen

Werte nach Abschluss der Maßnahmen aus, welche Muster sich zeigen. Wiederkehrende Probleme sind besonders wertvoll, weil sie auf strukturelle Ursachen hinweisen können. Beispiele sind fehlende Asset-Transparenz, unklare Verantwortlichkeiten, zu breite Berechtigungen, unzureichendes Patch-Management oder fehlende Security-Anforderungen in Projekten.

Leite daraus Verbesserungen für deinen Sicherheitsprozess ab:

• Pflege ein vollständiges und verantwortetes Asset-Inventar.
• Verankere Sicherheitsanforderungen früh in Architektur und Entwicklung.
• Überprüfe privilegierte Konten regelmässig und setze Least Privilege konsequent um.
• Etabliere klare Prozesse für Schwachstellenmanagement und Eskalation.
• Verbinde technische Logs mit nachvollziehbaren Alarmierungs- und Reaktionsprozessen.
• Wiederhole Tests risikobasiert, besonders nach grösseren Änderungen.

Für den Aufbau von Know-how zur Bewertung von Findings, zu sicheren Konfigurationen und zum Schwachstellenmanagement findest du passende IT-Security-Seminare und Termine bei uns auf cmt.de.

Ein Pentest-Bericht ist dann erfolgreich umgesetzt, wenn du nicht nur einzelne Lücken schliesst, sondern erkennbare Ursachen reduzierst, Verantwortlichkeiten klärst und die Wirksamkeit jeder wichtigen Maßnahme überprüfst.