Remediation ist nicht das Patchen eines Symptoms, und ein Retest ist nicht das Wiederholen eines Payloads. Eine Maßnahme muss die technische Ursache oder den Angriffspfad wirksam adressieren, und "wurde behoben" ist so lange ein gemeldeter, kein verifizierter Zustand, bis ein Retest unabhängig bestätigt hat, dass der ursprüngliche Befund nicht mehr reproduzierbar ist, die relevante Ursache im vereinbarten Scope beseitigt wurde und naheliegende Varianten derselben Ursache geprüft sind - Regressionen werden daneben separat dokumentiert. Dieser Artikel beschreibt den Weg vom bewerteten Finding zur verifizierten Behebung: Priorisierung nach Risiko und Pfadwirkung statt nur nach Severity, Ursache statt Symptom, Kompensation gegen dauerhafte Behebung, Risk Acceptance beim Risk Owner, Retest-Scope, Root-Cause-orientierter Retest, Rest-Risiko und der Abschluss. Er schließt direkt an Pentest Reporting und Risikobewertung und CVSS an.
Von der Bewertung zur Behebung
Mit der Abgabe des Berichts beginnt der Teil des Pentests, der über seine Wirkung entscheidet. Die Findings sind bewertet, die Angriffspfade benannt - jetzt müssen daraus Entscheidungen werden: was zuerst, womit, durch wen, und wann gilt es als erledigt. Der Lebenszyklus eines Findings nach dem Bericht hat sieben Stationen, und jede davon ist ein eigener Zustand mit eigener Verantwortung:
Die finale Risikoeinstufung aus der Risikobewertung ist der wichtigste Eingang in diesen Prozess - aber sie bestimmt die Reihenfolge nicht mechanisch. Wer die Findings einfach nach Risikostufe absteigend abarbeitet, übersieht, dass eine Maßnahme mehrere Findings gleichzeitig erledigen kann, dass manche Behebung von einer anderen abhängt, dass der Aufwand zwischen einer Konfigurationsänderung und einem Architekturumbau um Größenordnungen schwankt, und dass eine kurzfristige Kompensation ein hohes Risiko in Tagen senken kann, während die nachhaltige Behebung Monate braucht. In die Priorisierung gehen deshalb zusätzlich die Pfadwirkung einer Maßnahme, Abhängigkeiten zwischen Maßnahmen, der Umsetzungsaufwand, verfügbare Kompensationsmaßnahmen, die Reichweite der Maßnahme über ein einzelnes Finding hinaus und die betroffenen Schutzziele ein. Der Abschnitt zur Priorisierung macht daraus ein Modell.
Ursache statt Symptom beheben
Die häufigste Form unwirksamer Remediation ist die, die den gemeldeten Einzelfall beseitigt und die Ursache stehen lässt. Ein verwundbarer Endpunkt wird korrigiert, die fehlende Autorisierungsprüfung, die ihn verwundbar gemacht hat, existiert in zwanzig anderen Endpunkten weiter. Ein Klartext-Credential wird aus einem Skript gelöscht, das Fehlen eines Secret-Management-Prozesses sorgt dafür, dass das nächste Skript wieder eines enthält. Die Unterscheidung ist einfach zu formulieren und schwer durchzuhalten: Das Symptom ist das, was der Tester gefunden hat. Die Ursache ist das, was es ermöglicht hat. Eine nachhaltige Remediation adressiert die Ursache. Wird nur das Symptom oder der konkrete Angriffsweg blockiert, handelt es sich um eine Teilbehebung oder Kompensation, solange die Ursache fortbesteht.
| Symptom | Technische Ursache | Kurzfristige Maßnahme | Nachhaltige Maßnahme |
|---|---|---|---|
| Ein Endpunkt liefert fremde Objekte über die ID | Autorisierung wird pro Endpunkt und damit inkonsistent geprüft - zentraler Mechanismus fehlt | Prüfung in diesem Endpunkt ergänzen; Inventar aller ID-basierten Endpunkte anlegen | Objektberechtigung zentral in der Zugriffsschicht erzwingen, sodass kein Endpunkt sie umgehen kann |
| Dienstkonto im Klartext in einem Deployment-Skript | Kein Secret-Management; Zugangsdaten werden händisch in Skripte geschrieben | Konto rotieren, Skript bereinigen, Freigabe absichern | Secrets aus Skripten in einen Secret Store verlagern; Ablagen regelmäßig auf Zugangsdaten prüfen |
| Client-VLAN erreicht Server-VLAN auf Port 445 | Kein Segmentierungsmodell mit Default-Deny; Regeln werden fallweise geöffnet | Die konkrete Regel schließen | Segmentierungsdesign mit erlaubten Verbindungen je Zone; Default-Deny zwischen Zonen |
| Ein Service Account ist lokaler Administrator auf mehreren Servern | Keine Governance für technische Konten; Rechte werden bei Einrichtung großzügig vergeben und nie reduziert | Rechte dieses Kontos auf das Nötige reduzieren | Service-Account-Governance: Inventar, Rechtemodell, Review-Zyklus, Rotation |
| Eine Gruppe darf ein verknüpftes GPO bearbeiten | Delegation in Active Directory historisch gewachsen; kein dokumentiertes Rechtekonzept | Diese eine Berechtigung entfernen | Delegiertes Rechtekonzept für AD-Objekte mit regelmäßiger Prüfung effektiver Rechte |
Die kurzfristige Maßnahme ist nicht falsch - sie ist oft der einzige Weg, ein akutes Risiko schnell zu senken. Falsch ist, sie als Behebung zu melden. Im Statusmodell ist ein Finding, dessen Symptom beseitigt und dessen Ursache geblieben ist, bestenfalls "Partially Remediated".
Priorisierung der Remediation
Die naive Reihenfolge - Critical, dann High, dann Medium - ist nicht falsch, aber unvollständig. Sie behandelt jedes Finding als isolierte Aufgabe und ignoriert, dass Maßnahmen verschieden weit reichen. Ein praktisches Priorisierungsmodell betrachtet deshalb nicht nur das Finding, sondern die Maßnahme und ihre Wirkung:
| Kriterium | Leitfrage | Wirkung auf die Reihenfolge |
|---|---|---|
| Finales Risk Rating | Wie hoch ist das Finding im Kundenkontext eingestuft? | Ausgangspunkt - höher zuerst, aber nicht allein entscheidend |
| Attack-Path-Risk | Liegt das Finding in einem kritischen Pfad, und wie ist der Pfad bewertet? | Pfadrisiko kann ein mittleres Finding weit nach vorn ziehen |
| Pfadbrecher / Choke Points | Unterbricht die Maßnahme einen Pfad vollständig - oder mehrere? | Maßnahmen, die Pfade brechen, vor Maßnahmen, die Glieder nur erschweren |
| Reichweite der Behebung | Erledigt die Maßnahme ein Finding oder eine ganze Klasse? | Eine zentrale Behebung mit Breitenwirkung vor fünf Einzelfixes |
| Exposure | Wer kann das Finding erreichen - Internet, jeder Arbeitsplatz, ein Segment? | Breite Exposition erhöht die Dringlichkeit |
| Business Impact | Welches Schutzziel und welcher Prozess sind betroffen? | Kernprozesse und kritische Datenklassen zuerst |
| Umsetzungsaufwand | Konfigurationsänderung, Codefix, Architekturumbau? | Geringer Aufwand bei hoher Wirkung zuerst; hoher Aufwand wird geplant, nicht aufgeschoben |
| Vorhandene Kompensation | Senkt eine belegte Kontrolle das Risiko bereits? | Kann die nachhaltige Behebung zeitlich entlasten, nicht ersetzen |
| Zeitliche Dringlichkeit | Aktive Ausnutzung bekannt, Meldepflicht, Audit-Termin, Go-Live? | Externe Fristen überlagern die technische Reihenfolge |
Das wichtigste Ergebnis dieses Modells widerspricht der Intuition: Eine Maßnahme zu einem mittleren Finding, die drei kritische Angriffspfade unterbricht, steht vor einem isolierten hohen Finding auf einem System ohne weiterführenden Pfad. Die Priorität folgt der Wirkung der Maßnahme auf das Gesamtrisiko, nicht dem Severity-Etikett des Findings. Genau dafür hat der Bericht die Spalte "Wirkung einer Behebung" an jedem Pfad - sie ist der Eingang in diese Entscheidung.
Attack-Path-orientierte Remediation
Der Angriffspfad AP-1 aus Reporting und Risikobewertung - offenes Share, Dienstkonto im Skript, fehlende Segmentgrenze, lokaler Administrator, Kundendatenbank - zeigt, wie Remediation auf Pfadebene gedacht wird. Für jedes Glied gibt es eine Maßnahme, aber nicht jede Maßnahme wirkt gleich: Manche unterbrechen den Pfad vollständig, manche erschweren ihn nur, manche begrenzen den Impact am Ende, und manche treffen mehrere Pfade gleichzeitig.
| Finding / Pfadglied | Maßnahme | Wirkung | Pfad unterbrochen? | Weitere Pfade betroffen? | Priorität |
|---|---|---|---|---|---|
| F-03 Offene Freigabe | Gastzugriff auf die Freigabe deaktivieren | Einstieg in AP-1 entfällt; Share bleibt für berechtigte Nutzer lesbar | Ja - für anonyme Angreifer; nicht für jeden mit Standardkonto, falls die Berechtigung breit bleibt | Nein | Hoch, kurzfristig |
| F-04 Dienstkonto im Skript | Konto rotieren und aus dem Skript entfernen; Secret Store einführen | Das Credential ist wertlos; der Pfad bricht am zweiten Glied | Ja - AP-1 vollständig | Ja - jeder Pfad, der dieses Konto nutzt | Hoch, kurzfristig (Rotation) und nachhaltig (Secret Store) |
| F-09 Fehlende Segmentierung | Default-Deny zwischen Client- und Server-VLAN mit dokumentierten Ausnahmen | Zugriff vom Client-Netz auf Server-Dienste entfällt generell | Ja - AP-1 am dritten Glied | Ja - AP-2 und AP-4 als weitere Pfade desselben Engagements sowie jeder künftige Pfad aus dem Client-Netz | Höchste Pfadwirkung; nachhaltig, mit Vorlauf |
| F-11 Überprivilegiertes Dienstkonto | Lokale Adminrechte auf das für das Deployment Nötige reduzieren | Impact am Ende von AP-1 sinkt von Systemkontrolle auf Dienstzugriff | Nein - der Pfad führt weiter zum Server, mit kleinerem Impact | Begrenzt den Impact jedes Pfads über dieses Konto | Mittel; nach Rotation und Segmentierung |
| Ziel: Kundendatenbank | Zugriffsmonitoring und Alarmierung auf dem Datenbankserver | Erkennung eines erfolgreichen Zugriffs - keine Prevention | Nein | Detection für alle Pfade zum Ziel | Ergänzend; senkt das Risiko nur mit belegter Reaktionskette |
Aus der Matrix folgt die Reihenfolge, die ein reines Severity-Ranking nicht liefern würde: Die Rotation des Dienstkontos ist in Stunden erledigt und bricht AP-1 sofort. Die Segmentierung dauert länger, trifft aber drei Pfade und jeden künftigen aus dem Client-Netz - sie ist der Choke Point. Das Deaktivieren des Gastzugriffs ist schnell, wirkt aber nur gegen anonyme Angreifer. Die Rechtereduktion begrenzt den Schaden, bricht aber nichts. Das Monitoring ist wertvoll und ersetzt nichts davon.
Kurzfristige Kompensation gegen nachhaltige Behebung
Zwischen "Finding gemeldet" und "Ursache beseitigt" liegen oft Wochen oder Monate - ein Architekturumbau, ein Secret-Management-Projekt, ein Segmentierungsdesign. In dieser Zeit darf ein hohes Risiko nicht einfach offen bleiben. Kompensationsmaßnahmen senken es vorübergehend, während die Ursache bestehen bleibt. Das ist legitim und oft die richtige erste Reaktion - solange beide Seiten wissen, dass es Kompensation ist.
| Kompensationsmaßnahme | Dauerhafte Remediation | |
|---|---|---|
| Was sie bewirkt | Reduziert das Risiko vorübergehend; die Ursache bleibt bestehen | Beseitigt die Ursache oder die relevante Exposition |
| Typische Beispiele | Firewall-Regel als Abschottung; Feature deaktivieren; Konto sperren oder rotieren; WAF-Regel; EDR- oder Detection-Regel; temporäre Rollenbeschränkung | Codefix; Architekturänderung; Berechtigungsmodell; Segmentierungsdesign; Secret-Management; Patch oder Upgrade |
| Zeitrahmen | Stunden bis Tage | Wochen bis Monate |
| Wirkung im Retest | Ursprünglicher Weg scheitert, Ursache meist noch nachweisbar; Varianten oft offen | Ursache nicht mehr nachweisbar; Varianten geschlossen |
| Status nach Retest | Partially Remediated (Mitigated), mit dokumentiertem Rest-Risiko; ein Termin für die Behebung wird zusätzlich festgehalten | Verified Remediated, wenn die Kriterien erfüllt sind |
| Typischer Fehler | Als vollständige Behebung gemeldet; die Ursache wird vergessen, sobald der Alarm aus ist | Als "zu aufwendig" aufgeschoben, ohne dass eine Kompensation das Risiko überbrückt |
Die Regel für den Retest ist eindeutig: Eine Kompensation darf nicht als vollständige Behebung bezeichnet werden, wenn die Ursache weiter besteht. Eine WAF-Regel kann einen Angriff wirksam blockieren, beseitigt aber keine fehlende serverseitige Validierung; eine Firewall-Regel kann einen konkreten Pfad blockieren, beseitigt aber nicht zwangsläufig das zugrunde liegende Segmentierungsproblem. Der Retest bestätigt dann, was die Kompensation leistet, und dokumentiert, was offen bleibt.
Eine Detection-Regel ist eine Kompensation besonderer Art: Sie verhindert nichts, sondern verkürzt die Zeit bis zur Reaktion. Als risikosenkend zählt sie nur, wenn im Retest die gesamte Reaktionskette - Erkennung, Alarmierung, wirksame Reaktion im relevanten Zeitfenster - belegt wurde. Welche Signale die hier beschriebenen Pfade auf der Verteidigungsseite erzeugen, behandelt das Schwesterportal blue-team.net.
Wer entscheidet über Risk Acceptance?
Nicht jedes Finding wird behoben. Manche Behebung ist unverhältnismäßig teuer, manche bricht einen Prozess, manche betrifft ein System, das ohnehin abgelöst wird. Dann wird das Risiko bewusst getragen - und die Frage ist, von wem. Die Antwort ist eindeutig: Der Pentester bewertet, dokumentiert und verifiziert. Der Auftraggeber beziehungsweise der zuständige Risk Owner akzeptiert. Ein Tester akzeptiert kein Unternehmensrisiko, und er bestätigt auch keine Akzeptanz - er hält sie fest.
Eine belastbar dokumentierte Risk Acceptance im Pentest-Bericht enthält den zuständigen Risk Owner mit Rolle, die Entscheidung, die Begründung, das Datum, das verbleibende Rest-Risiko in der Sprache der Risikobewertung, einen Review- oder Ablaufzeitpunkt, soweit vorgesehen, und die relevanten kompensierenden Kontrollen - mit Beleg, nicht als Annahme. Fehlen diese Informationen, ist die Akzeptanz aus Sicht des Pentest-Reportings nicht ausreichend dokumentiert, und das Finding wird bis zur Nachreichung als offen geführt. Die Governance des Engagements sollte klären, wer auf Auftraggeberseite für Risikoentscheidungen verantwortlich ist; Scope und Rules of Engagement halten dafür Ansprechpartner und Eskalationswege fest, definieren aber nicht die unternehmensweite Risk-Acceptance-Governance.
Retest-Scope
Ein Retest ist kein zweiter Pentest. Er prüft gezielt, ob gemeldete Maßnahmen die gemeldeten Findings wirksam adressiert haben - und zwar entlang einer klaren Liste: das ursprüngliche Finding, seine Ursache, die betroffenen Systeme und Objekte, die gemeldete Maßnahme, die relevanten Varianten, die Pfadwirkung und mögliche Regressionen. Was nicht auf dieser Liste steht, wird nicht geprüft - und das wird im Retest-Bericht ebenso klar gesagt wie im Erstbericht.
Die Liste kann aber wachsen. Wenn die Behebung Architektur oder Berechtigungen breit verändert hat - eine neue Zugriffsschicht, ein neues Segmentierungsmodell, ein überarbeitetes Rechtekonzept in Active Directory -, dann ist der Retest-Scope nicht mehr das einzelne Finding, sondern die Änderung. Eine zentrale Autorisierungsschicht, die zwanzig Endpunkte schützt, wird nicht an dem einen Endpunkt geprüft, an dem das Finding entstand, sondern repräsentativ über die Endpunkte, die sie jetzt trägt. Wo die Grenze zwischen erweitertem Retest und neuem Pentest liegt, behandelt der letzte Abschnitt.
Ein Retest belegt, ob ein Befund noch reproduzierbar ist - nicht mehr. Keine aktive Ausnutzung über den Nachweis hinaus, keine Datenmengen als Beleg, keine Tests außerhalb des vereinbarten Retest-Scopes. Welche Techniken und Zeitfenster gelten, regeln die Rules of Engagement, die für den Retest fortgeschrieben oder neu vereinbart werden. Dieser Beitrag ist keine Rechtsberatung.
Retest-Vorbereitung
Ein Retest ohne Vorbereitung ist ein Pentest mit Zeitdruck. Bevor der Tester die erste Prüfung durchführt, braucht er den vollständigen Zustand des Findings vor und nach der Maßnahme - sonst kann er weder die Ausgangslage rekonstruieren noch beurteilen, ob die Maßnahme die Ursache trifft.
| Retest-Input | Warum er nötig ist |
|---|---|
| Finding-ID | Eindeutiger Bezug zum Erstbericht; alle neuen Evidenzen hängen daran |
| Ursprüngliche Evidenz | Der Vergleichsmaßstab - derselbe Request, dieselbe Abfrage, derselbe Objektzustand, damit der Vergleich exakt ist |
| Ursprüngliche Reproduktionsschritte | Der Testweg, der wiederholt wird, bevor Varianten geprüft werden |
| Betroffene Assets | Hosts, Endpunkte, Objekte, Konten - und ihre Nachbarn, für die Variantenprüfung |
| Gemeldete Remediation | Was genau geändert wurde - technisch, nicht "wurde behoben"; daraus ergibt sich, ob Ursache oder Symptom adressiert wurde |
| Änderungsdatum | Trennt Retest-Beobachtungen von Zuständen vor der Maßnahme; Abgleich mit Logs |
| Neue Version / Konfiguration | Was der Tester vorfinden sollte - Versionsstand, Regelwerk, Rechtekonfiguration |
| Bekannte Einschränkungen | Was bewusst nicht umgesetzt wurde, welche Kompensation stattdessen gilt, welche Systeme ausgenommen sind |
| Ansprechpartner | Für Rückfragen zur Maßnahme, für Deconfliction und für den Fall, dass der Retest Nebenwirkungen auslöst |
| Testkonten und Zugänge | Dieselben Rollen wie im Erstbericht - sonst ist "nicht mehr reproduzierbar" eine Aussage über das Konto, nicht über die Maßnahme |
Fehlt die ursprüngliche Evidenz, ist ein belastbarer Retest nicht möglich: Der Tester könnte dann nur prüfen, ob irgendein Angriff scheitert - nicht, ob der dokumentierte Befund beseitigt ist. Das ist einer der Gründe, warum der Erstbericht ein Evidenz-Register mit IDs führt, wie es der Reporting-Deep-Dive beschreibt.
Den originalen Befund reproduzieren
Der Retest beginnt nicht mit der Remediation-Beschreibung, sondern mit dem Befund. Die Beschreibung sagt, was jemand getan zu haben glaubt; der Befund sagt, was ein Angreifer konnte. Deshalb rekonstruiert der Tester zuerst die ursprüngliche Ausgangslage - dieselbe Rolle, dasselbe Segment, dieselbe Vorbedingung -, wiederholt den ursprünglichen Testweg Schritt für Schritt und prüft, ob der Befund weiterhin reproduzierbar ist. Erst danach wendet er sich der Ursache und den Varianten zu.
Der Satz, der diesen Abschnitt trägt: "Exploit funktioniert nicht mehr" bedeutet nicht automatisch "Ursache beseitigt". Ein Request kann scheitern, weil eine WAF ihn erkennt, weil ein Parameter umbenannt wurde, weil das Testkonto andere Rechte hat oder weil der Dienst gerade nicht läuft. Keiner dieser Gründe ist eine Behebung. Der Retest unterscheidet, warum der Weg scheitert - und das geht nur über die Ursache.
Die Ursache verifizieren
Was es heißt, die Ursache statt den Weg zu prüfen, unterscheidet sich je nach Befundklasse. Die Beispiele greifen die Methodik der technischen Deep-Dives auf:
| Befundklasse | Symptomprüfung (nicht ausreichend) | Ursachenprüfung im Retest |
|---|---|---|
| Web / API: fehlende Autorisierung | Die eine gemeldete Objekt-ID erneut abrufen | Prüfen, ob die Autorisierung systematisch korrekt ist: andere IDs, andere Objekttypen, andere Rollen, andere Methoden desselben Endpunkts, verwandte Endpunkte - siehe API-Deep-Dive und Web-Deep-Dive |
| Netzwerk: fehlende Segmentierung | Port 445 vom ursprünglichen Client testen | Die Segmentierungsregel und die relevanten Pfade prüfen: weitere Ports, weitere Quellsegmente, Rückrichtung, Ausnahmen - entlang der Segmentierungs-Matrix aus dem Netzwerk-Deep-Dive |
| Active Directory: ACL-Missbrauch | Die eine gemeldete ACL-Kante prüfen | Effektive Berechtigungen und den resultierenden Pfad prüfen: Vererbung, Gruppenmitgliedschaften, andere Kanten zum selben Ziel - entlang des Berechtigungsgraphen aus dem AD-Deep-Dive |
| Credentials | Das alte Passwort testen | Prüfen, ob das Credential entfernt wurde, ob es rotiert wurde, ob es anderswo wiederverwendet wird und ob andere Ablagen - Skripte, Konfigurationen, Shares, Repositories - dasselbe oder ähnliche Credentials enthalten |
| Software-Schwachstelle | Versionsnummer abfragen | Den verwundbaren Codepfad prüfen: Ist er noch erreichbar? Wurde ein Backport eingespielt, dessen Versionsstring nicht aussagekräftig ist? Entspricht die Konfiguration dem Herstellerfix? Verhalten statt Version |
Allen Beispielen gemeinsam ist das Prinzip: Der Retest fragt nicht "Scheitert mein Weg?", sondern "Existiert die Eigenschaft noch, die den Weg möglich gemacht hat?". Die Antwort darauf lässt sich nicht aus einer Versionsnummer, einem grünen Scanner-Ergebnis oder einer Admin-Aussage ablesen.
Regressionen und Nebenwirkungen
Remediation verändert Systeme, und jede Änderung kann neue Probleme erzeugen. Ein Retest, der nur prüft, ob das alte Problem weg ist, übersieht das neue. Die typischen Nebenwirkungen sind bekannt genug, um sie gezielt zu prüfen:
- Neue Berechtigungsfehler: Eine zentrale Autorisierungsschicht, die zu restriktiv oder zu permissiv konfiguriert ist; eine Rolle, die nach der Reduktion mehr Rechte hat als vorher, weil eine Gruppe falsch zugeordnet wurde.
- Gebrochene Funktionen: Ein Feature, das deaktiviert wurde, hatte eine sicherheitsrelevante Aufgabe - etwa das Löschen alter Sessions.
- Neue Exposition: Ein Dienst wurde beim Umbau auf eine andere Schnittstelle gebunden und ist jetzt aus einem Segment erreichbar, aus dem er es vorher nicht war.
- Alternative Pfade: Der gemeldete Pfad ist unterbrochen, aber die Maßnahme hat einen anderen Weg sichtbar oder nutzbar gemacht - ein Wartungszugang, eine Ausnahme in der neuen Regel.
- Verschobene Schwachstelle: Das Problem wurde nicht beseitigt, sondern in eine andere Komponente verlagert - etwa von einem Endpunkt in einen Proxy davor.
- Unsichere Workarounds: Um die Behebung schnell zu schaffen, wurde ein Umweg eingebaut - ein Hilfsskript mit eigenem Credential, eine Ausnahme "nur für das Deployment".
- Neue Default-Konfiguration: Ein Upgrade bringt neue Standardwerte mit, die weniger sicher sind als die alten, bewusst gesetzten.
Der Retest prüft angemessen, nicht erschöpfend: Er sucht gezielt in der Umgebung der Maßnahme nach diesen Effekten und meldet, was er findet, als neues Finding oder als Regression - mit eigener Evidenz, eigener Bewertung und eigenem Status. Der Status des ursprünglichen Findings bleibt davon getrennt: Eine Regression verhindert Verified Remediated nur, wenn sie zeigt, dass dieselbe Ursache oder derselbe Befund weiterhin besteht; ein neues Problem an anderer Stelle wird separat geführt, während das ursprüngliche Finding verifiziert behoben sein kann. Ein Retest, der eine Regression findet, hat seinen Zweck erfüllt, nicht verfehlt.
Variantenprüfung
Ein Fix für den gemeldeten Einzelfall ist fast immer zu eng, wenn die Ursache nicht adressiert wurde. Der Tester hat im Erstbericht ein Beispiel belegt - nicht die einzige Stelle. Der Root-Cause-orientierte Retest prüft deshalb die naheliegenden Varianten des Befunds, bevor er einen Status setzt:
- Endpunkt A ist korrigiert, Endpunkt B identisch verwundbar - weil die Prüfung pro Endpunkt ergänzt wurde statt zentral.
- Objekt-ID 123 ist geschützt, andere Ressourcentypen nicht - weil nur der Objekttyp aus dem Beispiel behandelt wurde.
- Ein Host ist segmentiert, das Nachbarsegment weiterhin offen - weil die Regel für den einen Host geschrieben wurde statt für die Zone.
- Ein Konto ist korrigiert, dieselbe Fehlberechtigung bei anderen Service Accounts - weil das Inventar fehlt, das alle technischen Konten zeigt.
Die Variantenprüfung bleibt innerhalb des Retest-Scopes: Sie prüft Varianten des gemeldeten Befunds, keine neuen Befundklassen. Was sie findet, ist entweder ein Beleg, dass die Ursache nicht beseitigt wurde - dann ist der Status Partially Remediated -, oder ein neues Finding, das nach den Regeln des Erstberichts dokumentiert wird. Als Arbeitshilfe gilt: Dieselbe Ursache an einem nahe verwandten Objekt kann als Variante beziehungsweise Erweiterung des bestehenden Findings geführt werden - so wie der Objekttyp "orders" im Abschlussbeispiel unter F-07 bleibt. Ob daraus ein eigenes Finding wird, hängt unter anderem von Scope, betroffenen Assets, Verantwortlichkeiten und der Berichtssystematik ab. Eine andere technische Ursache sollte grundsätzlich separat bewertet werden.
Statusmodell
Das Statusmodell ist im Reporting-Deep-Dive angelegt; hier wird es mit den Kriterien gefüllt, nach denen ein Status im Retest gesetzt wird. Jeder Status ist eine Aussage über einen belegten Zustand - nicht über eine Absicht oder eine Meldung.
| Status | Bedeutung | Wer setzt ihn | Voraussetzung |
|---|---|---|---|
| Open | Befund bestätigt, keine Maßnahme gemeldet oder gemeldete Maßnahme im Retest unwirksam | Tester | Erstbericht oder Retest ohne Wirkungsnachweis |
| Remediation Reported / Ready for Retest | Die Empfängerseite meldet die Umsetzung einer Maßnahme; nichts davon ist verifiziert | Empfängerseite | Technische Beschreibung der Maßnahme, Änderungsdatum, betroffene Assets |
| Partially Remediated | Maßnahme teilweise wirksam (Mitigated): der ursprüngliche Angriffsweg oder Impact ist durch eine Kompensation wirksam reduziert oder blockiert, oder das Symptom ist beseitigt - die zugrunde liegende Ursache oder der Scope aber nicht vollständig behoben | Tester im Retest | Teilwirkung im Retest belegt; verbleibende Ursache, verbleibender Scope und Rest-Risiko dokumentiert. Ein Zieltermin für die vollständige Behebung kann zusätzlich festgehalten werden, ist aber keine Voraussetzung für den Status |
| Verified Remediated | Im Retest unabhängig bestätigt: Befund nicht reproduzierbar, relevante Ursache im vereinbarten Scope beseitigt, naheliegende Varianten derselben Ursache im Retest-Scope geprüft, Evidenz vorhanden. Eine Kompensation, die den Angriffsweg blockiert, während die Ursache fortbesteht, führt zu Partially Remediated, nicht hierher | Tester im Retest - nie die behebende Stelle | Alle Kriterien aus dem nächsten Abschnitt, mit neuer Evidenz |
| Risk Accepted | Befund bleibt bestehen; das Risiko wird vom Risk Owner bewusst getragen | Risk Owner auf Empfängerseite; Tester dokumentiert | Dokumentiert: Risk Owner, Entscheidung, Begründung, Datum, Rest-Risiko, Review- oder Ablaufzeitpunkt soweit vorgesehen, relevante kompensierende Kontrollen |
| Not Reproducible | Im Retest nicht nachstellbar, ohne dass eine Maßnahme belegt ist. Kein "behoben": Bei belastbarer ursprünglicher Evidenz bleibt der Befund valide, mit dokumentierter Unsicherheit | Tester im Retest | Ausgangslage rekonstruiert, Testweg wiederholt, Ursache gesucht; mögliche Gründe benannt |
| Regression / Reopened | Ein zuvor als Verified Remediated geführter Befund tritt erneut auf | Tester im Retest oder in einer späteren Prüfung | Neue Evidenz; Bezug auf den früheren Verified-Stand |
Die beiden Zustände, die am häufigsten verwechselt werden, sind Remediation Reported und Verified Remediated. Der erste ist eine Meldung der Empfängerseite und der Auslöser für den Retest. Der zweite ist das Ergebnis des Retests. Dazwischen liegt die gesamte Arbeit dieses Artikels, und kein Statuswechsel überspringt sie. Führt eine Organisation für dauerhaft akzeptierte Mitigations einen eigenen Status, lässt sich das ergänzen; das Modell dieses Artikels bleibt bei den sieben Zuständen, damit Kompensation und Beseitigung der Ursache nie denselben Status tragen.
Wann ist etwas wirklich "Verified Remediated"?
Der Status ist nur dann gerechtfertigt, wenn alle Kriterien erfüllt sind - nicht die meisten:
- Der ursprüngliche Befund ist nicht mehr reproduzierbar - mit derselben Ausgangslage und demselben Testweg wie im Erstbericht.
- Die relevante technische Ursache ist im vereinbarten Scope beseitigt - und der Tester kann sagen, warum der Weg jetzt scheitert. Ist nur der Angriffsweg durch eine Kompensation blockiert, während die Ursache fortbesteht, ist der Status Partially Remediated.
- Der relevante Scope ist geprüft - die betroffenen Systeme, Objekte und Rollen, nicht nur das Beispiel.
- Keine naheliegende Variante derselben Ursache im vereinbarten Retest-Scope - Nachbar-Endpunkte, andere Objekttypen, andere Hosts, andere Konten derselben Klasse sind geprüft. Der Retest belegt die Abwesenheit von Varianten im geprüften Scope, nicht universell.
- Regressionen separat behandelt - durch die Remediation entstandene neue Sicherheitsprobleme werden als eigene Findings dokumentiert und bewertet. Sie verhindern den Status nur, wenn sie zeigen, dass dieselbe Ursache oder derselbe Befund weiterhin besteht.
- Evidenz vorhanden - der neue Zustand ist mit eigener Evidenz-ID belegt, vergleichbar mit der ursprünglichen.
Was nicht zwangsläufig genügt: "Softwareversion geändert". Eine neue Version ist ein Hinweis, kein Nachweis. Der verwundbare Codepfad kann in der neuen Version noch erreichbar sein, der Fix kann eine Konfiguration voraussetzen, die nicht gesetzt wurde, oder die Version kann ein Backport sein, dessen Versionsstring nichts über den Patchstand sagt. Verified Remediated wird am Verhalten festgemacht, nicht am Etikett.
Retest-Evidenz
Die Evidenz des Retests folgt denselben Regeln wie die des Erstberichts: reproduzierbar, redigiert, mit Zeitbezug und Rolle, mit eigener ID. Sie belegt den neuen Zustand so, dass er mit dem alten vergleichbar ist - derselbe Request mit anderer Antwort, dieselbe Abfrage mit anderem Ergebnis, derselbe Objektzustand mit anderen Rechten.
Das Template ist bewusst kompakt. Es zwingt zu den vier Testschritten, zur neuen Evidenz-ID und zum Rest-Risiko - den drei Dingen, die in Retest-Dokumentation am häufigsten fehlen.
Rest-Risiko
Ein Finding kann auf Finding-Ebene vollständig behoben sein, während auf Ebene des Gesamtrisikos etwas verbleibt. Das ist kein Widerspruch, sondern die Konsequenz daraus, dass Findings Beispiele sind und Risiken Zusammenhänge. Typische Konstellationen:
- Ursache behoben, vergleichbare Systeme noch offen: Der gemeldete Fileserver ist abgesichert; drei weitere mit derselben Konfiguration lagen außerhalb des Retest-Scopes.
- Kompensationsmaßnahme statt Root-Cause-Fix: Die Firewall-Regel hält; das Segmentierungsmodell, das sie dauerhaft machen würde, ist nicht umgesetzt.
- Pfad unterbrochen, alternativer Pfad vorhanden: AP-1 ist gebrochen; ein zweiter Weg zum selben Ziel über ein anderes Dienstkonto wurde im Retest sichtbar.
- Detection verbessert, Prevention weiterhin nicht vorhanden: Der Zugriff würde jetzt erkannt; er wäre weiterhin möglich.
- Legacy-System bleibt bestehen: Die Schwachstelle ist bekannt, nicht patchbar und wird bis zur Ablösung mit Risk Acceptance getragen.
Die Regel: "Verified Remediated" auf Finding-Ebene bedeutet nicht automatisch, dass kein Gesamtrisiko mehr besteht. Der Retest-Bericht hält deshalb je Finding das Rest-Risiko fest und bewertet auf Pfadebene erneut - mit derselben Methodik wie im Erstbericht, nach der Risikobewertung. Was der Retest an Rest-Risiko dokumentiert, ist der Eingang in den nächsten Zyklus: in die nächste Priorisierung, in eine Risk Acceptance oder in den nächsten Pentest.
Retest eines Angriffspfads
Ein Angriffspfad wird nicht dadurch retestet, dass jedes seiner Glieder einzeln geprüft wird. Nach den Einzelprüfungen kommt die Pfadfrage: Existiert AP-1 noch? Ist der Pfad vollständig gebrochen oder nur erschwert? Gibt es einen alternativen Weg zum selben Ziel? Welche Restwirkung verbleibt? Die Tabelle zeigt AP-1 vor und nach einer typischen ersten Remediation-Runde:
| Pfadglied | Vorher | Maßnahme | Nachher (Retest) | Wirkung auf den Pfad |
|---|---|---|---|---|
| F-03 Offene Freigabe | Anonym lesbar aus dem Client-VLAN | Gastzugriff deaktiviert | Anonym nicht lesbar; mit Standardkonto weiterhin lesbar - Berechtigung "Authentifizierte Benutzer: Lesen" unverändert | Einstieg für Angreifer mit Standardkonto bleibt - Partially Remediated |
| F-04 Dienstkonto im Skript | Klartext in deploy.ps1 | Konto rotiert, Skript bereinigt | Altes Credential ungültig; Skript ohne Credential; Secret Store noch nicht eingeführt | Glied gebrochen - Verified Remediated mit Rest-Risiko (Prozess) |
| F-09 Fehlende Segmentierung | Client-VLAN erreicht Server-VLAN direkt | Default-Deny mit Ausnahmen | Port 445 blockiert; Ausnahme für Port 443 zum Monitoring-Server aktiv | Glied gebrochen für AP-1; Ausnahme ist ein neuer Prüfpunkt |
| F-11 Überprivilegiertes Dienstkonto | Lokaler Admin auf DB01 und APP02 | Noch nicht umgesetzt | Unverändert | Impact-Begrenzung offen - Open |
| AP-1 gesamt | Pfadrisiko: Kritisch - Arbeitsplatz bis Kundendatenbank ohne Voraussetzungen | Pfad an zwei Gliedern gebrochen. Alternativer Weg geprüft: über die Port-443-Ausnahme erreicht ein Standardkonto den Monitoring-Server, dessen Dienstkonto Rechte auf DB01 hat - neuer Pfad AP-5 | AP-1 unterbrochen; Pfadrisiko AP-5: Hoch - neue Bewertung, neue Priorisierung |
Das Beispiel zeigt, warum die Pfadfrage eigenständig ist: Jedes Einzelergebnis wäre für sich ein Fortschritt. Erst die Pfadbetrachtung macht sichtbar, dass die Segmentierungsausnahme einen neuen Weg zum selben Ziel geöffnet hat - mit geringerem Risiko als AP-1, aber weit entfernt von "erledigt". Der Retest-Bericht führt AP-1 als unterbrochen und AP-5 als neues Pfadrisiko, bewertet nach derselben Methodik.
Technische Behebung und organisatorische Maßnahme
Viele Ursachen haben zwei Ebenen: die technische Eigenschaft, die der Tester gefunden hat, und den Prozess, der sie hat entstehen lassen. Beide brauchen eine Maßnahme - aber sie sind nicht austauschbar.
| Technische Behebung | Organisatorische Maßnahme | |
|---|---|---|
| Beispiele | Patch; Codefix; ACL-Korrektur; Segmentierung; Secret Rotation | Review-Prozess; Rollenmodell; Change Control; Credential-Governance; Secure Development Practice |
| Wirkt auf | Den konkreten Befund und seine Varianten | Die Entstehung künftiger Befunde derselben Klasse |
| Im Retest prüfbar | Ja - am Verhalten des Systems | Nur indirekt - an Artefakten (Inventar, Review-Protokolle) und daran, ob neue Varianten auftauchen |
| Reicht allein? | Für den Status des Findings ja; für die Klasse nein | Nein - ein Prozess beseitigt kein bestehendes Credential und schließt keine offene Regel |
Organisatorische Maßnahmen können notwendig sein, damit ein Befund nicht wiederkehrt - aber sie ersetzen den technischen Fix nicht. Ein neu eingeführter Review-Prozess für Zugangsdaten in Skripten ändert nichts an dem Credential, das heute in deploy.ps1 steht. Umgekehrt löst der technische Fix das Problem nur für heute: Ohne Prozess steht morgen das nächste Credential im nächsten Skript. Im Retest wird die technische Behebung verifiziert; die organisatorische Maßnahme wird dokumentiert und im nächsten Pentest an ihren Ergebnissen gemessen.
Typische Remediation-Fehler
- Nur das Symptom patchen: Der gemeldete Fall ist weg, die Ursache bleibt - und mit ihr alle Varianten.
- Nur einen betroffenen Host fixen: Das Beispiel wird korrigiert, die baugleichen Systeme nicht.
- Credentials löschen, aber nicht rotieren: Das Credential ist aus dem Skript entfernt und weiterhin gültig - und möglicherweise längst kopiert.
- Scanner zeigt grün gleich behoben: Der Scanner prüft Signaturen und Versionen, nicht Verhalten und nicht Ursachen.
- Version prüfen statt Verhalten: Eine neue Versionsnummer ist kein Nachweis, dass der verwundbare Codepfad unerreichbar ist.
- WAF-Regel als vollständige Behebung deklarieren: Die Regel blockiert den bekannten Request; die fehlende Validierung dahinter bleibt.
- Detection als Prevention behandeln: Ein Alarm verhindert nichts; ohne belegte Reaktionskette senkt er das Risiko nicht.
- Attack Path nicht erneut prüfen: Jedes Glied einzeln erledigt, der Pfad nie wieder als Ganzes betrachtet.
- Gleiche Fehlkonfiguration auf anderen Assets übersehen: Kein Inventar, keine Variantenprüfung, keine Breitenwirkung.
- Retest ohne ursprüngliche Evidenz: Es wird geprüft, ob irgendetwas scheitert - nicht, ob der dokumentierte Befund beseitigt ist.
- "Nicht reproduzierbar" gleich "behoben": Ein verschwundener Befund ohne belegte Maßnahme hat möglicherweise eine intakte Ursache.
- Risk Acceptance ohne Risk Owner: Eine Akzeptanz ohne dokumentierten Entscheider ist aus Sicht des Berichts nicht ausreichend dokumentiert - und wird bis zur Nachreichung als offen geführt.
Typische Retest-Fehler
- Nur den ursprünglichen Payload wiederholen: Der Retest wird zur Wiederholung eines Requests; die Ursache bleibt ungeprüft.
- Keine Varianten testen: Nachbar-Endpunkte, andere Objekttypen, andere Hosts bleiben außen vor.
- Scope zu eng: Eine breite Architekturänderung wird an einem einzelnen Punkt geprüft.
- Keine Ursache prüfen: "Scheitert" wird als "behoben" gelesen, ohne zu wissen, warum es scheitert.
- Regressionen ignorieren: Die Umgebung der Maßnahme wird nicht auf Nebenwirkungen angesehen.
- Andere Rollen und Objekte nicht prüfen: Der Retest läuft mit einem Konto; die Ausgangslage des Erstberichts war eine andere.
- Nur Hersteller- oder Admin-Aussage übernehmen: "Ist gepatcht" ersetzt die eigene Prüfung.
- Kein neuer Evidenzstand: Der Status wird ohne Beleg gesetzt; im nächsten Zyklus fehlt der Vergleichspunkt.
- Status ohne Begründung setzen: "Verified Remediated" ohne die Kriterien, die ihn tragen.
Abschluss eines Retests
Der Retest endet mit einem Abschnitt im Bericht, der je Finding denselben Aufbau hat und für sich allein lesbar ist: Finding-ID, ursprüngliche technische Severity und finales Risk Rating, gemeldete Maßnahme, Retest-Ergebnis, Evidenz, Rest-Risiko, Status, Datum - und, wo der Retest etwas Neues gefunden hat, die neuen Findings oder Regressionen mit Verweis.
Das Beispiel ist bewusst kein Erfolgsfall: Der Originalweg scheitert, die Ursache ist für den gemeldeten Objekttyp beseitigt - und trotzdem ist der Status nicht Verified Remediated, weil die Variantenprüfung eine Lücke in derselben Ursache gefunden hat. Genau das ist der Unterschied zwischen einem Retest, der einen Request wiederholt, und einem, der die Ursache prüft.
Wann braucht es einen vollständigen neuen Pentest?
Der Retest hat Grenzen, und sie sind dieselben wie die des Erstberichts: Er trifft Aussagen über das, was geprüft wurde. Sind die Änderungen seit dem Test so weitreichend, dass der ursprüngliche Scope das System nicht mehr repräsentiert, liefert ein Retest ein falsches Gefühl von Sicherheit.
| Retest reicht, wenn | Neuer Pentest sinnvoll, wenn |
|---|---|
| Die Findings klar begrenzt sind und die Maßnahmen gezielt darauf wirken | Die Architektur stark verändert wurde - neue Komponenten, neue Schnittstellen, neue Vertrauensgrenzen |
| Die Änderungen auf die gemeldeten Ursachen beschränkt sind | Eine große Migration stattgefunden hat - Cloud, neue Plattform, neuer Identity Provider |
| Der Scope stabil ist - dieselben Systeme, dieselben Rollen, dieselben Netze | Viele neue Systeme hinzugekommen sind, die nie geprüft wurden |
| Die Zeit seit dem Test kurz ist und keine größeren Releases dazwischen liegen | Das Berechtigungsmodell neu aufgebaut wurde - in der Anwendung oder in Active Directory |
| Keine neuen Befundklassen im Retest sichtbar wurden | Die Sicherheitsarchitektur grundlegend verändert wurde - Segmentierung, Zugriffsschicht, Authentisierung |
| Lange Zeit vergangen ist oder der ursprüngliche Scope nicht mehr repräsentativ ist |
Die Entscheidung ist keine Frage des Budgets allein, sondern der Aussagekraft: Ein Retest nach einem Architekturumbau bestätigt, dass die alten Wege zu sind - und sagt nichts über die neuen. Wie oft und wann ein vollständiger Test sinnvoll ist, ordnet der Grundlagenartikel ein; die Grenzen jeder Prüfung gelten für den Retest genauso.
Häufige Fragen
Reicht es, wenn der Auftraggeber die Behebung bestätigt?
Nein. Die Meldung der Empfängerseite ist der Status Remediation Reported und der Auslöser für den Retest - nicht sein Ergebnis. Verified Remediated setzt nur der Tester, nach eigener Prüfung mit neuer Evidenz. Das ist keine Frage des Vertrauens, sondern der Unabhängigkeit: Wer die Maßnahme umgesetzt hat, prüft sie mit denselben Annahmen, die den Befund ermöglicht haben.
Ist ein Finding behoben, wenn der ursprüngliche Exploit nicht mehr funktioniert?
Nicht automatisch. Ein Weg kann scheitern, weil eine WAF ihn blockiert, ein Parameter umbenannt wurde oder das Testkonto andere Rechte hat - keiner dieser Gründe beseitigt die Ursache. Verified Remediated verlangt, dass der Tester sagen kann, warum der Weg scheitert, dass die Ursache im vereinbarten Scope beseitigt ist und keine naheliegende Variante derselben Ursache im Retest-Scope offen bleibt. Regressionen werden separat dokumentiert und verhindern den Status nur, wenn sie dieselbe Ursache betreffen.
Darf der Pentester ein Rest-Risiko akzeptieren?
Nein. Der Tester bewertet das Rest-Risiko, dokumentiert es und hält eine Risk Acceptance fest - mit Verantwortlichem, Begründung, Datum, Review-Zeitpunkt und belegter Kompensation. Akzeptieren kann nur der zuständige Risk Owner auf Auftraggeberseite. Eine Akzeptanz ohne dokumentierten Risk Owner ist aus Sicht des Berichts nicht ausreichend dokumentiert und wird als offen geführt.
Wie wird ein Angriffspfad im Retest behandelt?
Zusätzlich zu den Einzelfindings als eigenes Element: Existiert der Pfad noch, ist er vollständig gebrochen oder nur erschwert, gibt es einen alternativen Weg zum selben Ziel, und welche Restwirkung verbleibt? Ein unterbrochener Pfad kann im Retest einen neuen Pfad sichtbar machen - der wird nach derselben Methodik bewertet und priorisiert.