NIST SP 800-115: die vier Phasen, Kategorien von Techniken und Rules of Engagement

Was NIST SP 800-115 ist

NIST veröffentlichte den Leitfaden im September 2008 über das Computer Security Resource Center. Autoren sind Karen Scarfone, Murugiah Souppaya, Amanda Cody und Angela Orebaugh. Das Dokument ersetzte SP 800-42 zu Netzsicherheitstests. Am 29. August 2026 führt NIST SP 800-115 weiterhin als finale veröffentlichte Version; ein verbindlicher Nachfolgeplan wurde nicht bekanntgegeben.^[1]

Der Leitfaden richtet sich sowohl an Tester als auch an Auftraggeber. Tester erhalten einen wiederholbaren Prozess und einen Katalog von Techniken. Auftraggeber erhalten eine Grundlage für Scoping, Autorisierung, Kommunikation und Abnahmekriterien. Betriebsteams können besser nachvollziehen, welche Eingriffe während der Prüfung zu erwarten sind und welche Nachweise danach vorhanden sein sollten.

Sein Wert liegt weniger in bestimmten Werkzeugen als in Prozessdisziplin. Ein Portscan bleibt ein Portscan, unabhängig vom eingesetzten Produkt. Planung, Discovery, kontrollierter Angriff und Reporting sind auch dann relevant, wenn das Ziel heute eine Cloud- oder Containerumgebung ist.

Was der Leitfaden nicht ausreichend abdeckt

Seit 2008 sind ganze Technologiebereiche hinzugekommen, die der Leitfaden nicht im Detail beschreibt: moderne Cloud-Control-Planes, Container und Orchestrierung, GraphQL- und gRPC-APIs, aktuelle mobile Ökosysteme, OT/ICS sowie Systeme des maschinellen Lernens. Die Phasen bleiben nutzbar, die konkreten Techniken müssen jedoch aus aktuelleren Spezialquellen stammen. Die jährliche ENISA-Bedrohungsanalyse zeigt die Richtung.^[14]

Sinnvolle Ergänzungen sind NIST SP 800-53 für Sicherheitsmaßnahmen^[9], SP 800-53A für Bewertungsverfahren, SP 800-30 für Risikobewertung^[10], SP 800-218 für sichere Softwareentwicklung, NIST CSF 2.0^[12], OWASP WSTG^[2], MITRE ATT&CK^[11] und technologiespezifische Leitlinien.

Die vier Phasen eines Penetrationstests

SP 800-115 beschreibt Penetrationstests als Abfolge von Planning, Discovery, Attack und Reporting. Reporting ist nicht ausschließlich der letzte Schritt: Nachweise und wesentliche Feststellungen sollten während des gesamten Tests dokumentiert und kommuniziert werden.^[1]

Planning

In der Planungsphase werden Wert und Sicherheit des Tests bestimmt. Ziel, Geltungsbereich und Ausschlüsse müssen definiert, geeignete Techniken ausgewählt, Rules of Engagement (ROE) erstellt, Autorisierung eingeholt sowie Kommunikations- und Eskalationswege festgelegt werden.

Eine schwache Planungsphase führt zu typischen Problemen: Feststellungen lassen sich nicht priorisieren, Systeme außerhalb des beabsichtigten Umfangs werden berührt oder eine kritische Schwachstelle wartet in einer Mailbox, weil niemand den Eskalationsweg festgelegt hat.

Discovery

Discovery beginnt mit passiver Aufklärung und kann in aktive Identifikation von Hosts, Diensten, Versionen, Betriebssystemen und Anwendungseinstiegspunkten übergehen. Bei Webanwendungen gehören Authentisierungsmechanismen, Rollen, Parameter, Schnittstellen und Technologien dazu.

Das Ergebnis ist eine Menge von Hypothesen über mögliche Schwachstellen. Ein Scanner-Fund ist noch kein Beweis dafür, dass die Schwachstelle in der geprüften Umgebung ausnutzbar ist.

Attack

Die Angriffsphase prüft, ob identifizierte Schwächen innerhalb des autorisierten Umfangs tatsächlich nutzbar sind. Dazu können Zugriff, Rechteausweitung, begrenzte laterale Bewegung und der Nachweis von Auswirkungen gehören. Datenexfiltration sollte normalerweise simuliert oder minimiert werden, wenn der Zweck lediglich darin besteht, die Möglichkeit zu belegen.

Der Test muss mit Cleanup enden: Konten, Werkzeuge, Implantate und Persistenzmechanismen, die das Testteam eingeführt hat, sind zu entfernen oder kontrolliert an den Auftraggeber zu übergeben.

Reporting

Nachweise werden bereits während des Tests gesammelt. Screenshots, Requests und Responses, Kommandoausgaben, Zeitstempel und Logs sind am zuverlässigsten, wenn sie zum Zeitpunkt der Verifikation erfasst werden. Kritische Feststellungen sollten nicht bis zum Abschlussbericht warten.

Der Bericht muss Scope, Methodik, Einschränkungen, Angriffspfade, Nachweise, geschäftliche Relevanz und Abhilfemaßnahmen verständlich machen. Seitenzahl ist kein Qualitätsmaß. Eine kurze reproduzierbare Feststellung ist wertvoller als viele Seiten ungefilterter Scanner-Ausgaben.

Drei Kategorien von Techniken

SP 800-115 ordnet Techniken nach ihrer Eingriffstiefe in das Zielsystem.^[1]

Review-Techniken vergleichen Soll- mit Ist-Zustand und liefern häufig mehr als ein Scan. Validierungstechniken haben höhere operative und rechtliche Risiken und brauchen besonders klare Autorisierung und ROE.

Rules of Engagement und Autorisierung

ROE hält vor Testbeginn die Regeln des Auftrags fest. Ein guter ROE definiert mindestens:^[1]

• Systeme und Adressen im Scope sowie explizite Ausschlüsse;
• Quellinfrastruktur des Testteams;
• Zeitfenster und Wartungsrestriktionen;
• erlaubte und verbotene Techniken;
• Abbruch- und Aussetzungsbedingungen;
• Kontakte und Eskalationswege;
• Umgang mit sensiblen und personenbezogenen Daten;
• Aufbewahrung und Löschung von Nachweisen;
• Cleanup-Verantwortung;
• Kommunikation kritischer Feststellungen.

Die schriftliche Autorisierung sollte von einer Person stammen, die tatsächlich über die betroffenen Systeme und Handlungen verfügen darf. Eine Unterschrift ohne entsprechende Zuständigkeit schafft nicht automatisch die Berechtigung, Dritt- oder Shared-Infrastrukturen zu testen.

Die Autorisierung ist technisch und rechtlich bedeutsam. Sie definiert die Grenzen erlaubter Handlungen und reduziert das Risiko einer Überschreitung. Strafrechtliche Fragen in Polen hängen vom konkreten Verhalten, Umfang der Einwilligung und den Umständen ab; sie sollten nicht auf die Behauptung reduziert werden, jeder Test ohne bestimmtes ROE-Formular sei automatisch eine Straftat.

Black Box, Gray Box und White Box

Beim Black-Box-Test erhält das Testteam nur minimale Vorinformationen und bildet damit besser die Ausgangslage eines externen Angreifers ab. Dafür kann ein größerer Teil des Aufwands in Discovery fließen.

Beim White-Box-Test erhält das Team Architektur, Zugangsdaten, Dokumentation und gegebenenfalls Quellcode. Dies erhöht Abdeckung und Effizienz, wenn möglichst viele Schwächen gefunden werden sollen, bildet jedoch die Informationsbeschränkung eines externen Angreifers nicht ab.

Gray Box liefert Teilwissen, etwa ein normales Benutzerkonto und einen groben Architekturüberblick. Dies kann ein kompromittiertes Benutzerkonto oder Insider-Szenario abbilden und zugleich den Test effizient halten.

Das Modell muss aus dem Testziel folgen. Vollständigkeitsprüfungen können White oder Gray Box rechtfertigen; Gegnersimulationen können Wissen bewusst begrenzen. Eine universelle Regel wie "Compliance = Gray Box" existiert nicht.

Schwachstellenscanning und Penetrationstest

Das sind unterschiedliche Leistungen mit unterschiedlichen Fragestellungen. In Ausschreibungen werden sie häufig vermischt, weil teilweise dieselben Werkzeuge zum Einsatz kommen können; Zweck, Nachweis und sinnvoller Zyklus unterscheiden sich jedoch deutlich.

Schwachstellenscanning ist weitgehend automatisiert. Es erkennt Hosts, Dienste, Versionen und Konfigurationsmerkmale und vergleicht sie mit Datenbanken bekannter Schwachstellen. SP 800-115 behandelt Vulnerability Scanning in Abschnitt 4.3. Ein Scan kann häufig wiederholt werden und hält den Überblick über bekannte Exposition aktuell. Er beweist aber normalerweise nicht, ob eine gemeldete Schwachstelle in der konkreten Zielkonfiguration tatsächlich ausnutzbar ist oder welche geschäftliche Auswirkung eine erfolgreiche Ausnutzung hätte.

Ein Penetrationstest ergänzt kontrollierte Ausnutzung und menschliche Analyse. Der Tester validiert Schwachstellen, kombiniert sie gegebenenfalls und weist unter vereinbarten Rules of Engagement einen Angriffspfad nach. SP 800-115 behandelt Penetration Testing in Abschnitt 5.2. Das Ergebnis sollte deshalb mehr sein als eine CVE-Liste: reproduzierbare Nachweise, Auswirkung, Grenzen und Empfehlungen gehören dazu.

Beide Tätigkeiten ergänzen sich. Scanning ohne vertiefte Validierung kann eine große, ungeprüfte Befundliste erzeugen. Ein Penetrationstest ohne laufendes oder periodisches Vulnerability Management liefert dagegen nur eine Momentaufnahme einer Umgebung, die sich ständig verändert. Die Häufigkeit sollte sich nach Exposition, Änderungsrate, Kritikalität und anwendbaren Anforderungen richten, nicht nach einer universellen Kalenderregel.

Berichterstattung als dauerhaftes Ergebnis

SP 800-115 behandelt Reporting als Teil der Tätigkeiten nach dem Test.^[1] Der Bericht ist das dauerhafte Produkt des Projekts und entscheidet darüber, ob der Test nach Ende der offensiven Arbeit tatsächlich etwas verändert.

Eine brauchbare Struktur beginnt mit einer Management-Zusammenfassung ohne unnötigen Fachjargon. Sie sollte Scope, Ziel, die wichtigsten Angriffspfade, wesentliche Einschränkungen und zentrale Remediation-Prioritäten nennen. Der technische Teil beschreibt anschließend Methodik, Testzeitraum, Wissensmodell, gegebenenfalls Werkzeuge und die Nachweise zu jedem Befund.

Jeder technische Befund sollte reproduzierbar sein. Ein guter Eintrag benennt betroffene Systeme, beschreibt die Schwachstelle, enthält Belege und Reproduktionsschritte, erläutert technische und organisatorische Auswirkungen und schlägt Abhilfemaßnahmen vor. CVE und CWE können die Klassifikation unterstützen; CVSS hilft bei der technischen Schwere, ersetzt aber nicht den Geschäftskontext der Organisation.

SP 800-115 schreibt keine Remediation-Fristen vor. Eine Regel wie "kritisch in sieben Tagen, hoch in dreißig Tagen" ist Organisations- oder Vertragspolitik, keine NIST-Vorgabe. Im Bericht sollten daher technische Schwere, kundenseitige SLA und formale Risikoakzeptanz getrennt werden.

Auch der Bericht selbst ist sensibel. Er kann Zugangsdaten, interne Adressen, Angriffspfade und Nachweise enthalten, die einen realen Angreifer stark unterstützen würden. Die Übermittlung sollte über einen angemessen geschützten Kanal erfolgen und der Zugriff auf die vorgesehenen Empfänger beschränkt sein. Integritätsprüfung sowie vereinbarte Aufbewahrungs- und Löschregeln sind sinnvolle Zusatzkontrollen.

Ein Management-Debrief und ein technischer Remediation-Workshop liefern häufig mehr Nutzen als das bloße Versenden einer Datei. Der erste übersetzt Befunde in Entscheidungen und Verantwortlichkeiten, der zweite hilft Systemverantwortlichen bei Reproduktion, Ursachenanalyse und sicherer Behebung.

Rechtliche und autorisierungsbezogene Fragen im polnischen Kontext

Technisch kann ein nicht autorisierter Penetrationstest genauso aussehen wie ein Angriff. Gute Absicht ersetzt keine Berechtigung. Schriftliche Autorisierung und Rules of Engagement sind deshalb zentrale Kontrollen. Ihre Wirkung hängt jedoch davon ab, ob die autorisierende Person tatsächlich über die getesteten Systeme und Tätigkeiten verfügen darf.

In Polen können Straftatbestände des Strafgesetzbuchs zu unbefugtem Zugriff, Daten- oder Systembeeinträchtigung und bestimmten Sicherheitswerkzeugen relevant werden, wenn Handlungen die erteilte Berechtigung überschreiten. Die rechtliche Bewertung hängt vom konkreten Verhalten und den Umständen ab. Ein professionelles Projekt definiert daher Systeme, Techniken, Zeitfenster, verbotene Handlungen und Notfallkontakte vor Beginn des Tests.

Infrastruktur Dritter ist eine wiederkehrende Grenze. Der Kunde kann eine Anwendung besitzen, aber nicht Hosting-Plattform, Netz, SaaS-Dienst oder gemeinsam genutzte Cloud-Infrastruktur. Die Zustimmung des Anwendungsinhabers berechtigt nicht automatisch zu disruptiven Tests von Systemen eines anderen Anbieters. Provider-Regeln und gegebenenfalls erforderliche Freigaben müssen vor der Durchführung geprüft werden.

Personenbezogene Daten können während eines Tests unerwartet auftauchen. Zugangsdaten, Postfachinhalte, Logs und Anwendungsdaten können personenbezogene oder vertrauliche Informationen enthalten. ROE sollte deshalb Datenminimierung, Nachweisbehandlung, Zugriff, Aufbewahrung und Cleanup vorab regeln. Ein Sicherheitstest setzt DSGVO- oder Vertraulichkeitspflichten nicht außer Kraft.

Retest und Cleanup

Ein Projekt sollte nicht mit dem Versand des Berichts enden. Testkonten, Werkzeuge, Payloads, hochgeladene Dateien, Persistence-Mechanismen und temporäre Ausnahmen in Firewall oder Anwendung müssen entfernt oder ausdrücklich an den Kunden übergeben werden. Bei Post-Exploitation- oder Red-Team-Techniken ist ein Cleanup-Nachweis besonders wichtig.

Ein Retest prüft die Behebung und ist nicht automatisch eine Wiederholung des gesamten Projekts. Bei einem korrigierten Befund sollte bestätigt werden, dass der ursprüngliche Angriffspfad nicht mehr funktioniert und die Änderung nicht nur ein Symptom verdeckt. Ein Befund sollte nicht allein deshalb als geschlossen gelten, weil der Systemverantwortliche die Installation eines Patches oder eine Konfigurationsänderung bestätigt.

Der Retest liefert zugleich Nachweise für Audit und Risikomanagement. Er trennt behobene, akzeptierte, durch kompensierende Kontrollen mitigierte und weiterhin offene Befunde. Dieser Status ist für das Management wertvoller als eine statische Liste aus dem ursprünglichen Bericht.

Methodiken neben SP 800-115

OWASP WSTG^[2] liefert detaillierte Techniken für Webanwendungen. PTES^[5] beschreibt einen umfangreichen Penetration-Testing-Prozess. OSSTMM^[4] bietet eine alternative Methodik und ein Messmodell. MITRE ATT&CK^[11] hilft, Angreiferverhalten und Detektionsabdeckung zu beschreiben. Für regulierte Threat-Led-Tests im Finanzsektor sind der aktuelle TIBER-EU-Rahmen^[6] und die DORA-TLPT-Vorgaben spezifischer als SP 800-115.

OWASP Top 10^[3] eignet sich zur Sensibilisierung und Risikokommunikation, ist aber keine Penetrationstest-Methodik. Die CIS Controls v8.1^[13] helfen, Befunde in ein breiteres Verteidigungsprogramm einzuordnen, während die ENISA Threat Landscape 2025^[14] Bedrohungsszenarien für europäische Organisationen unterstützen kann.

Ein professioneller Test muss sich nicht exklusiv an ein einziges Dokument binden. Methodik und Quellen werden nach Ziel, Technologie, Rechtsregime und benötigten Nachweisen ausgewählt.

Verhältnis zu ISO/IEC 27001, DORA und anderen Rahmenwerken

ISO/IEC 27001:2022^[7] verlangt das Management von Informationssicherheitsrisiken und enthält Schutzmaßnahmen mit Bezug zu Sicherheitstests. NIST SP 800-115 kann technische Tests strukturieren, ist jedoch keine ISO-Anforderung.

DORA^[8] und die dazugehörigen delegierten Rechtsakte schaffen einen eigenen Rechtsrahmen für Resilienztests und TLPT. SP 800-115 kann ergänzend verwendet werden, wird von DORA jedoch nicht als vorgeschriebener TLPT-Standard festgelegt.

NIST CSF 2.0^[12] arbeitet auf höherer Ebene und strukturiert Cybersecurity-Ergebnisse in Govern, Identify, Protect, Detect, Respond und Recover. SP 800-115 unterstützt nur einen Ausschnitt dieses umfassenderen Risikomanagements.

Häufige Fehler

• Einen Scanner laufen lassen und das Ergebnis Penetrationstest nennen.
• Ohne schriftlichen Scope und klare Ausschlüsse starten.
• Autorisierung durch eine Person ohne Zuständigkeit für die geprüften Systeme.
• Provider- oder Shared-Infrastruktur ohne Prüfung von Regeln und Zustimmung testen.
• Feststellungen ohne reproduzierbare Nachweise berichten.
• CVSS allein als Business-Risikobewertung verwenden.
• Testkonten, Werkzeuge oder Persistenzmechanismen im System zurücklassen.
• Ein einmaliges Testergebnis als dauerhafte Sicherheit behandeln.
• Nach Behebung wichtiger Findings keinen Retest durchführen.

Zehn Fragen vor der Beauftragung

1. Was ist das Ziel: Compliance-Nachweis, Gap-Analyse oder Gegnersimulation?
2. Was ist exakt im Scope und was ausgeschlossen?
3. Welches Wissensmodell wird verwendet und warum?
4. Welche Methodiken strukturieren die Arbeit?
5. Sind ROE vor Beginn vereinbart?
6. Ist die Autorisierung von einer befugten Person unterschrieben?
7. Welche Erfahrung haben die tatsächlich eingesetzten Tester mit den Zieltechnologien?
8. Wie werden personenbezogene und vertrauliche Daten behandelt?
9. Welche Struktur hat der Bericht und wie wird er sicher übertragen?
10. Werden wichtige Findings nach der Behebung erneut geprüft?