NIST SP 800-115 im Jahr 2026: der Technical Guide to Information Security Testing and Assessment

Was NIST SP 800-115 ist

Die Veröffentlichung stammt vom Computer Security Resource Center am National Institute of Standards and Technology und erschien im September 2008. Verfasst haben sie Karen Scarfone, Murugiah Souppaya, Amanda Cody und Angela Orebaugh; sie umfasst 80 Seiten und hat den Status Final, ist also die geltende Ausgabe. Sie löste die frühere SP 800-42 zu Netzsicherheitstests ab.

Der Leitfaden richtet sich an zwei Zielgruppen zugleich, was seinen Ton erklärt. Zum einen wurde er für Testende und Auditierende geschrieben, denen er einen Prozessrahmen und einen Katalog von Techniken gibt. Zum anderen für jene, die einen Test beauftragen und daraus erfahren, was sie vertraglich verlangen können und woran sich saubere Arbeit erkennen lässt. Für die Teams, die Systeme betreiben, ist er schließlich eine Quelle des Wissens darüber, was während eines Tests mit ihrer Infrastruktur geschieht.

Das Dokument leistet vier Dinge: Es gliedert den Prozess in wiederholbare Phasen, katalogisiert Techniken unabhängig von Werkzeugen, beschreibt gute Praxis bei der Durchführung und benennt die häufigsten Fallstricke. Der letzte Punkt wird oft unterschätzt, doch gerade er unterscheidet einen Leitfaden von einer Sammlung von Werkzeuganleitungen.

Aufbau des Dokuments

Acht Kapitel folgen der natürlichen Arbeitsreihenfolge. Nach Einleitung und Erörterung des Testansatzes kommt die Einteilung der Techniken in drei Kategorien, danach drei Kapitel zu Durchsichten, zur Identifizierung und Analyse der Ziele und zur Validierung von Schwachstellen. Die beiden letzten Kapitel behandeln Planung und Durchführung der Bewertung. Hinzu kommen Anhänge, darunter eine Vorlage für Rules of Engagement in Anhang B.

Diese Struktur hat eine praktische Folge: Kapitelnummern werden in Verträgen und Berichten häufig zitiert, es lohnt sich also, sie zu kennen. Der Schwachstellenscan ist Abschnitt 4.3, der Penetrationstest samt seinen vier Phasen Abschnitt 5.2, Social Engineering Abschnitt 5.3, Planung und Rules of Engagement Kapitel 6, und der Bericht Abschnitt 8.2.

Ist ein Dokument von 2008 noch aktuell

Die Veröffentlichung ist achtzehn Jahre alt und wurde nie überarbeitet, was beim Tempo des technischen Wandels wie ein Ausschlusskriterium klingt. In der Praxis wirkt sie dennoch, und zwar aus zwei Gründen.

Erstens beschreiben die vier Phasen - Planung, Aufklärung, Angriff und Bericht - eine Denkweise und keinen Stand der Technik. Die Reihenfolge, zuerst den Umfang festzulegen, dann die Umgebung zu erkunden, danach die Ausnutzbarkeit zu prüfen und am Ende das Ergebnis zu beschreiben, ist für einen Server von 2008 genauso sinnvoll wie für einen Containercluster.

Zweitens spricht der Leitfaden durchgängig von Kategorien der Techniken und nicht von Werkzeugen. Ein Portscan bleibt ein Portscan, ob dafür nmap, masscan oder etwas anderes zum Einsatz kommt. Ein Dokument, das keine Softwareversionen nennt, kann in dieser Schicht nicht veralten.

Was darin fehlt

Die Grenzen sind ebenso real. Seit 2008 sind ganze Testfelder entstanden, die der Leitfaden nicht behandelt: Cloud-Sicherheit samt Prüfung von Konfiguration und Rechten, Container und Orchestrierung, Programmierschnittstellen in den Varianten REST, GraphQL und gRPC, mobile Anwendungen, Industrieanlagen und - als jüngstes Feld - die Sicherheit lernender Systeme. In all diesen Fällen gelten die Phasen aus SP 800-115 weiterhin, doch die Techniken sind anderswo herzuholen. Die Richtung des Wandels zeigt die jährliche Bedrohungslage der ENISA gut ^[14].

Die Lücke füllen andere NIST-Veröffentlichungen, die man parallel heranziehen sollte: SP 800-53 mit dem Maßnahmenkatalog ^[9], SP 800-53A mit den Bewertungsverfahren dazu, SP 800-30 mit einer Methodik der Risikoeinschätzung ^[10] sowie SP 800-218 zum sicheren Softwareentwicklungszyklus. Auf strategischer Ebene hält das Cybersecurity Framework 2.0 ^[12] das Ganze zusammen.

NIST hat keinen Zeitplan für eine Überarbeitung von SP 800-115 angekündigt. Die Historie des Dokuments im NIST-Katalog enthält einen einzigen Eintrag - die Veröffentlichung vom 30. September 2008 - und keine Ankündigung einer weiteren Ausgabe.

Die vier Phasen eines Tests

Der Leitfaden beschreibt einen Penetrationstest als Folge von vier Phasen (Abschnitt 5.2.1), wobei der Bericht keine gesonderte Etappe am Ende ist, sondern parallel zu den übrigen läuft. Die unten angegebenen Zeitanteile stammen nicht aus dem Dokument - es sind unsere Mittelwerte aus Projekten üblichen Umfangs, und im Einzelfall können die Verhältnisse ganz anders aussehen.

Planung

Die Phase, in der alle Entscheidungen fallen, die den Wert des Tests bestimmen, und zugleich die, die am häufigsten gekürzt wird. Zu klären ist das Ziel - Konformitätsnachweis, Lückenanalyse oder Simulation eines realen Gegners -, denn davon hängt die Wahl der Techniken ab. Danach wird der Umfang bestimmt, ausdrücklich mit dem, was ausgeschlossen ist, eine Methodik gewählt, die Rules of Engagement niedergeschrieben und die schriftliche Genehmigung eingeholt. Zuletzt werden Zeitplan, Ressourcen und Kommunikationswege samt Eskalationspfad festgelegt.

Wird diese Phase vernachlässigt, zeigt sich das später im Bericht: Ohne klares Ziel lassen sich Feststellungen schwer ordnen, und ohne vereinbarte Kommunikationswege wartet eine kritische Schwachstelle bis Montag in einer Mail-Warteschlange.

Aufklärung

Der umfangreichste technische Teil. Er beginnt mit passiver Aufklärung aus öffentlichen Quellen und geht dann in aktive über: Identifizierung von Adressbereichen, Portscans, Erkennung von Diensten samt Versionen und der Betriebssysteme. Bei Webanwendungen kommen die Kartierung von Einstiegspunkten, Parametern und eingesetzten Technologien sowie die Erkennung der Authentisierungsmechanismen hinzu.

Ergebnis der Phase ist die Gegenüberstellung der gefundenen Dienste mit bekannten Schwachstellen. Das ist noch kein Nachweis - erst eine Hypothese, die im nächsten Schritt zu prüfen ist.

Angriff

Die spektakulärste und meist kürzeste Phase. Sie umfasst das Ausnutzen von Schwächen zur Erlangung von Zugriff, die Rechteerhöhung, die Erkundung des Systeminhalts, das Aufrechterhalten des Zugriffs und die Bewegung zu weiteren Systemen. In Active-Directory-Umgebungen ist der typische Zielpunkt der Weg vom gewöhnlichen Konto zu Domänenadministratorrechten. Ein Datenabfluss wird simuliert durchgeführt - es geht darum, die Möglichkeit zu zeigen, nicht darum, den Datenbestand tatsächlich zu verschieben.

Die Phase endet mit dem Aufräumen: Entfernen der angelegten Konten, Werkzeuge und Persistenzmechanismen. Wird dieser Schritt übergangen, bleiben in der Umgebung Hintertüren, an die sich niemand erinnert.

Bericht

Die Dokumentation läuft während des gesamten Tests und beginnt nicht erst nach seinem Ende. Der Grund ist nüchtern: Ein Nachweis in Form eines Bildschirmfotos oder eines mitgeschnittenen Anfrage-Antwort-Paares lässt sich nur erheben, solange die Schwachstelle noch besteht. Außerdem werden kritische Feststellungen sofort gemeldet und nicht bis zum Abschlussbericht zurückgehalten.

Die drei Kategorien der Techniken

Der Leitfaden teilt die Techniken in drei Gruppen danach ein, wie tief sie in die geprüfte Umgebung eingreifen. Die Einteilung hilft beim Aushandeln des Umfangs, weil sie ein Gespräch über das Risiko des Tests erlaubt statt über Werkzeugnamen.

Durchsichtstechniken (Kapitel 3) greifen nicht in das System ein. Dazu zählen die Durchsicht von Dokumentation und Protokollen, die Analyse von Regelwerken, die Konfigurationsdurchsicht, das Mitlesen des Netzverkehrs und die Integritätsprüfung von Dateien. Sie sind für Produktivumgebungen sicher und liefern oft mehr als ein Scan, weil sie den Sollzustand neben den Istzustand stellen.

Techniken der Zielidentifizierung und -analyse (Kapitel 4) erzeugen Verkehr, versuchen aber nichts auszunutzen: Netzerkundung, Identifizierung von Ports und Diensten, Schwachstellenscans und Scans von Funknetzen. Das Risiko ist hier mäßig und rührt vor allem von der Last auf den Geräten her.

Techniken der Schwachstellenvalidierung (Kapitel 5) prüfen, ob sich eine Schwäche ausnutzen lässt - Kennwortknacken, Penetrationstests und Social Engineering. Sie tragen das reale Risiko für die Umgebung, und auf sie beziehen sich die Ausschlüsse in den Rules of Engagement.

Die Unterscheidung wirkt unmittelbar auf Kosten und Zeit. Ein auf die ersten beiden Kategorien begrenzter Test ist günstiger und sicherer, beantwortet aber nicht die Frage, ob eine gefundene Schwachstelle tatsächlich ausnutzbar ist.

Rules of Engagement und Genehmigung

Die Rules of Engagement sind ein vor Testbeginn abgestimmtes Dokument, in dem alles festgehalten wird, was außer Streit stehen soll. SP 800-115 behandelt Bewertungsplan und Rules of Engagement in Kapitel 6 und liefert eine Vorlage in Anhang B; Kapitel 7 setzt ihr Bestehen voraus und verlangt für Abweichungen eine gesonderte, in der Regel schriftliche Zustimmung.

Gut geschriebene Regeln beantworten mehrere Fragen. Was zum Umfang gehört und was ausdrücklich ausgeschlossen ist - und die Ausschlüsse wiegen schwerer, denn sie schützen beide Seiten. Von welchen Adressen aus getestet wird und auf welche. In welchen Stunden gearbeitet werden darf. Wer bei einem kritischen Fund in welcher Form zu benachrichtigen ist, über welche Kanäle und unter welchen Nummern. Ob das Überwachungsteam vom Test weiss oder ihn wie einen echten Vorfall behandeln soll.

Verbotene Techniken werden gesondert aufgezählt. Meist sind das Angriffe zur Dienstverweigerung, zerstörende Tests, Aktivitäten in bestimmten Zeitfenstern und Social Engineering gegenüber benannten Personen. Vorab zu klären ist auch, was beim Antreffen personenbezogener oder finanzieller Daten zu tun ist: ob sie als Nachweis gespeichert werden dürfen, in welcher Form und wie lange. Schließlich die Abbruchbedingungen - wann die Testerin die Arbeit einzustellen und anzurufen hat.

Schriftliche Genehmigung

Ein eigenes Dokument, das die Rules of Engagement nicht ersetzen, ist die schriftliche Genehmigung. Ohne sie können die Handlungen der Testerin Straftatbestände des polnischen Strafgesetzbuchs erfüllen: unbefugte Erlangung von Informationen (Artikel 267), Zerstörung oder Veränderung einer Informationsaufzeichnung (Artikel 268 und 268a), Störung eines Systems oder Netzes (Artikel 269 und 269a) sowie Herstellung oder Bereitstellung von Werkzeugen für diese Taten (Artikel 269b).

Die Genehmigung sollte die zur Vertretung berechtigte Person, den konkreten Auftragnehmer, den Umfang, die Geltungsdauer und die Grenzen nennen, mit Unterschrift und Datum. Sie sollte in einer Form vorliegen, die sich sofort vorzeigen lässt - daher der Branchenname Get-out-of-jail-free Letter. Ein praktischer Hinweis: Eine von der IT-Leitung unterzeichnete Genehmigung reicht oft nicht, wenn der Test Systeme anderer Organisationseinheiten umfasst.

Black Box, White Box und die Zwischenvariante

Wie viel die Testerin vor dem Start erfährt, ist eine eigene Entscheidung und wirkt stärker auf das Ergebnis, als gemeinhin angenommen.

In der Variante Black Box erhält sie ein Minimum an Informationen und bildet die Lage eines Angreifers von aussen ab. Der Vorteil ist der Realismus, der Nachteil die Zeit. Die Aufklärung verschlingt den größten Teil des Budgets, für die eigentlichen Tests bleibt weniger, und der Bericht fällt mitunter kürzer aus - nicht, weil das System sicher wäre.

In der Variante White Box erhält sie Dokumentation, Zugangsdaten, Netzpläne und bisweilen Quellcode. Die Erkundung schrumpft auf ein Minimum, fast die ganze Zeit fließt ins Testen. Das ist der effizienteste Weg, möglichst viele Schwachstellen zu finden, sagt aber nichts darüber, wie viele davon ein blind arbeitender Angreifer fände.

Die Zwischenvariante Grey Box gibt Teilwissen - meist ein gewöhnliches Benutzerkonto und eine grobe Architekturbeschreibung. Sie entspricht der Lage eines Angreifers, der bereits Fuß gefasst hat, oder einer Person, die ihre Rechte missbraucht. In der Praxis wird sie am häufigsten gewählt, weil sie ein vernünftiges Verhältnis von Realismus zu Fundzahl bietet.

Die Wahl sollte sich aus der Frage ergeben, die der Test beantworten soll. Für einen Konformitätsnachweis genügt meist die Zwischenvariante. Eine Durchsicht vor der Inbetriebnahme eines neuen Systems macht man besser mit vollem Wissen. Eine auf einen bestimmten Gegner gerichtete Simulation, darunter Tests im bedrohungsgeleiteten Regime, verlangt die Variante ohne Vorwissen.

Schwachstellenscan und Penetrationstest

Das sind zwei verschiedene Leistungen, die in Angeboten mitunter verwechselt werden und sich nicht im Detaillierungsgrad unterscheiden, sondern in der Frage, die sie beantworten.

Der Schwachstellenscan ist automatisiert und vergleicht erkannte Softwareversionen mit einer Datenbank bekannter Schwachstellen. Er dauert Stunden, lässt sich vierteljährlich oder häufiger wiederholen und liefert eine Liste von Positionen mit CVE-Kennungen. Der Scanner prüft jedoch nicht, ob sich eine Schwachstelle in dieser Umgebung ausnutzen ließe oder welche Bedeutung das hätte. Der Schwachstellenscan ist Abschnitt 4.3 des Leitfadens. Ausführlicher im Artikel zum Schwachstellenscan.

Der Penetrationstest ist zu einem großen Teil Handarbeit und besteht im Versuch, gefundene Schwächen auszunutzen. Er dauert Tage oder Wochen, wird seltener durchgeführt und liefert die Beschreibung realer Angriffsszenarien samt Nachweisen. Penetrationstests sind Abschnitt 5.2, ihre vier Phasen Abschnitt 5.2.1. Ausführlicher im Artikel zu Penetrationstests.

Beide Leistungen ergänzen einander. Der Scan hält das Bild des Zustands aktuell, der Penetrationstest prüft, ob die getroffenen Schutzmaßnahmen tatsächlich wirken. Den Test durch einen Scan zu ersetzen liefert eine Liste, die niemand geprüft hat; den Scan durch einen Test zu ersetzen liefert eine Momentaufnahme einer Umgebung, die sich wöchentlich ändert.

Der Testbericht

SP 800-115 behandelt den Bericht in Abschnitt 8.2, im Kapitel zu den Tätigkeiten nach Abschluss der Tests. Der Bericht ist das einzige bleibende Produkt der ganzen Arbeit, und er entscheidet, ob der Test etwas verändert.

Die eingespielte Struktur beginnt mit einer Zusammenfassung für die Leitung - ein bis zwei Seiten ohne Fachjargon, mit Umfang, den wichtigsten Feststellungen, einer Gesamteinschätzung und Empfehlungen. Danach folgt die Beschreibung der Methodik: angewandter Leitfaden, Umfang, Zeitrahmen, Zusammensetzung des Teams und Werkzeuge. Kern sind die Einzelheiten der Feststellungen, wo jede Position eine Kennung, einen Titel, eine Schwereeinstufung samt CVSS-Punktzahl, eine Liste der Systeme, eine Beschreibung, Nachweise, die Auswirkung auf die Tätigkeit der Organisation und eine Behebungsempfehlung mit Verweisen auf CVE, CWE oder OWASP trägt.

Nach den Feststellungen folgt meist ihre Aufstellung nach Schwere und eine vorgeschlagene Reihenfolge der Behebung. Die den einzelnen Stufen zugeordneten Fristen - etwa sieben Tage bei kritischen und dreissig bei hohen Schwachstellen - stammen nicht aus dem Leitfaden; es ist eine Branchenkonvention, die man mit der Kundschaft abstimmen und nicht automatisch eintragen sollte. Abschließend Anhänge mit Rohergebnissen und weiteren Nachweisen.

Der Umfang des Berichts hängt vom Prüfumfang ab und reicht in unserer Praxis von einigen Dutzend Seiten für eine einzelne Anwendung bis zu mehreren hundert bei einem Test über die ganze Organisation. Die Seitenzahl ist jedoch kein Maß der Qualität - ein guter Bericht zu einer Anwendung ist mitunter kürzer als eine Ausgabe des Scanners.

Auch die Art der Übergabe zählt, denn der Bericht ist ein Dokument, dessen Abfluss mehr schadet als die meisten darin beschriebenen Schwachstellen. Standard ist eine verschlüsselte Datei oder ein gesicherter Kanal samt Prüfsumme. Hinzu kommt üblicherweise eine kurze Besprechung für die Leitung und eine längere, technische für die Teams, die die Behebung verantworten.

Verhältnis zu OWASP, OSSTMM, PTES und MITRE ATT&CK

SP 800-115 wird selten allein angewandt. In der Praxis dient es als Prozessrahmen, den man mit detaillierteren, zum Prüfgegenstand passenden Methodiken ergänzt.

Der OWASP Web Security Testing Guide ^[2] in der Version 4.2 vom Dezember 2020 enthält ausführliche Szenarien zum Testen von Webanwendungen. Wo NIST sagt "prüfe die Authentisierung", nennt der WSTG konkrete Testfälle. Das ist die häufigste Ergänzung bei Anwendungstests. Ein eigenes OWASP-Dokument ist die Top-10-Liste ^[3], die Schwachstellenkategorien ordnet, aber keine Testmethodik ist und den WSTG nicht ersetzt.

OSSTMM ^[4] in der dritten Fassung geht einen anderen Weg: Es schlägt ein eigenes Modell zur Messung operativer Sicherheit vor. Es ist formaler und weniger verbreitet, aber dort nützlich, wo ein wiederholbares Maß gebraucht wird und nicht eine Liste von Funden.

PTES ^[5] gliedert einen Test in sieben Etappen, von der Vorabstimmung über Informationssammlung, Bedrohungsmodellierung, Schwachstellenanalyse, Ausnutzung und Nacharbeit bis zum Bericht. Eigene technische Leitlinien steigen bis zu konkreten Werkzeugen und Befehlen hinab, was SP 800-115 bewusst vermeidet.

MITRE ATT&CK ^[11] ist keine Testmethodik, sondern eine geordnete Beschreibung von Taktiken und Techniken, die bei realen Angreifern beobachtet wurden. In Tests dient es dazu, genau zu beschreiben, was simuliert wurde, sodass das Verteidigungsteam prüfen kann, welche dieser Verhaltensweisen es überhaupt erkannt hat.

TIBER-EU ^[6] wiederum ist der Rahmen der Europäischen Zentralbank für Tests auf Grundlage von Bedrohungsanalysen im Finanzsektor. Seit dem Wirksamwerden von DORA ist es der Bezugspunkt für bedrohungsgeleitete Penetrationstests bei den größten Finanzunternehmen.

Ein typischer Stapel sieht also so aus: SP 800-115 als Prozess, WSTG oder PTES als technische Schicht, ATT&CK als Beschreibungssprache für simuliertes Verhalten und, bei regulierten Tests, TIBER-EU als übergeordneter organisatorischer Rahmen. Auf der Schutzseite entspricht dieser praktischen Schicht die CIS Controls ^[13], auf die Empfehlungen aus dem Bericht oft abgebildet werden.

Rechtliche Aspekte im polnischen Kontext

Ein Penetrationstest ohne Genehmigung ist technisch von einem Angriff nicht zu unterscheiden, und die Strafvorschriften kennen keine Ausnahme für gute Absichten. Die schriftliche Zustimmung ist deshalb keine Formalität, sondern Bedingung der Rechtmäßigkeit des ganzen Vorhabens.

Bedeutung haben vor allem die Vorschriften des Kapitels XXXIII des polnischen Strafgesetzbuchs. Artikel 267 betrifft die unbefugte Erlangung von Informationen einschließlich des Überwindens oder Umgehens einer Schutzvorkehrung. Die Artikel 268 und 268a erfassen das Zerstören, Beschädigen oder Verändern der Aufzeichnung wesentlicher Informationen. Die Artikel 269 und 269a beziehen sich auf die Störung eines IT-Systems oder -Netzes. Artikel 269b stellt das Herstellen, Beschaffen und Bereitstellen von Werkzeugen unter Strafe, die zur Begehung dieser Taten angepasst sind.

In der Praxis verlangen drei Lagen besondere Aufmerksamkeit. Die erste ist ein Test, der Systeme eines externen Dienstleisters umfasst - die Zustimmung des Auftraggebers erstreckt sich dann nicht auf Infrastruktur, die ihm nicht gehört. Die zweite sind geteilte Umgebungen, in denen die Folgen eines Tests Dritte treffen können. Die dritte ist das Antreffen personenbezogener Daten: Das Vorgehen sollte vorab in den Rules of Engagement geregelt sein, denn während des Tests bleibt dafür keine Zeit, und ein zufälliges Festhalten solcher Daten begründet eigene Pflichten aus der DSGVO.

Eine Selbstverständlichkeit ist bei externen Tests leicht zu vergessen: Die Zustimmung der Anwendungsinhaberin erstreckt sich nicht auf den Hosting-Anbieter oder den Netzbetreiber, über den getestet wird.

Typische Fehler in Tests

Die folgenden Probleme wiederholen sich unabhängig davon, wer testet und wie groß die Organisation ist.

1. Zu eng gefasster Umfang. Ein auf eine Anwendung begrenzter Test lässt den Weg aus, den ein Angreifer tatsächlich nimmt - meist über einen ins Internet gestellten Dienst oder gestohlene Zugangsdaten.
2. Keine Ausschlüsse in den Rules of Engagement. Solange nicht festgehalten ist, was nicht getan werden darf, bricht der Streit darüber im schlechtesten Moment aus: nach dem Ausfall eines Produktivdienstes.
3. Genehmigung von einer nicht befugten Person unterzeichnet. Die Zustimmung einer Abteilungsleitung schützt die Testerin nicht, wenn der Umfang Systeme anderer Einheiten erfasst.
4. Bericht ohne Nachweise. Eine Feststellung ohne Bildschirmfoto, Mitschnitt oder Protokolleintrag ist für das behebende Team eine Behauptung und kein Fakt - und wird als Erstes bestritten.
5. Schwere ohne Kontext. Eine CVSS-Punktzahl allein berücksichtigt nicht, ob das verwundbare System kritische Daten verarbeitet oder in einem isolierten Testsegment steht.
6. Kein Aufräumen nach der Angriffsphase. Zurückgelassene Konten, Werkzeuge und Persistenzmechanismen werden zu einer realen, vom Test selbst eingeführten Schwachstelle.
7. Ein einmaliger Test als Dauerzustand. Das Ergebnis beschreibt die Umgebung einer bestimmten Woche. Nach Änderungen ist es erneut zu prüfen, mindestens für die behobenen Feststellungen.
8. Kein Nachtest. Ohne Prüfung, ob die Behebung gewirkt hat, hat die Organisation nur die Zusage des Betriebsteams.