Penetrationstests sind ein Standardelement jedes ernsthaften Sicherheitsprogramms. In kommerziellen Umgebungen ist es eine relativ gut verstandene Übung: Ein externes Team erhält einen Geltungsbereich, ein Regeln-des-Engagements-Dokument und ein Zeitfenster, um ausnutzbare Schwachstellen zu finden, bevor echte Angreifer es tun. Das Ergebnis ist ein Bericht; der Behebungspfad ist ein Projektmanagementproblem.
In Verteidigungsumgebungen gilt dieses Rahmensystem nicht vollständig. Die rechtliche Befugnisstruktur ist anders, das Bedrohungsmodell ist anders, die Einschränkungen hinsichtlich dem, was Tester berühren dürfen, sind anders, und der Weg vom Befund zur Behebung führt durch einen formalen Akkreditierungsprozess, der kein kommerzielles Äquivalent hat. Organisationen, die kommerzielle Pen-Testing-Konventionen auf Verteidigungssysteme anwenden – oder die kommerzielle Pen-Testing-Firmen ohne Verteidigungserfahrung engagieren – erstellen routinemäßig Bewertungen, die die relevantesten Risiken übersehen, außerhalb rechtlich vertretbarer Grenzen operieren oder Befunde generieren, auf die das Programmbüro nicht reagieren kann.
Dieser Artikel untersucht, was Verteidigungspen-Tests tatsächlich von anderen unterscheidet, was das operativ bedeutet und wie man eine Bewertung strukturiert, die Ergebnisse liefert, die ein Militärprogramm nutzen kann.
Rechtliche Befugnis: das Fundament ohne kommerzielles Äquivalent
In kommerziellen Aufträgen ist die rechtliche Grundlage für einen Pen-Test ein Vertrag und ein Regeln-des-Engagements-Dokument, das von jemandem mit der Befugnis zur Genehmigung von Tests der Zielsysteme unterzeichnet wurde. Diese Befugnis ist in der Regel unkompliziert – das Unternehmen besitzt die Systeme, und der CISO oder CTO kann die Erlaubnis erteilen.
In Verteidigungsumgebungen ist die Befugniskette komplexer, und die Einsätze bei Fehlern sind deutlich höher. Staatliche Informationssysteme operieren unter einer Authorization to Operate (ATO), die von einem Authorizing Official (AO) erteilt wurde. Die ATO definiert die Sicherheitslage, zu deren Aufrechterhaltung das System autorisiert ist. Penetrationstests verändern diese Lage, zumindest vorübergehend, und müssen ausdrücklich vom AO genehmigt werden – nicht nur vom Programmmanager oder dem ISSO des Systems.
Für US-DoD-Systeme gelten der Computer Fraud and Abuse Act (CFAA) und das UCMJ. Eine Person, die ohne ordnungsgemäße Genehmigung auf ein staatliches Informationssystem zugreift – selbst mit guten Absichten, selbst als Teil eines scheinbar autorisierten Tests – hat ein Bundesverbrechen begangen. Das Genehmigungsdokument ist keine Formalität: Es ist das Instrument, das das, was sonst unbefugter Zugriff wäre, in legales Testen umwandelt. Jeder im Genehmigungsdokument genannte Tester muss individuell identifiziert werden. Der Umfang des genehmigten Tests muss spezifisch sein. Aktivitäten außerhalb dieses Umfangs sind nicht geschützt.
Anforderung an die rechtliche Befugnis: Beginnen Sie niemals einen Verteidigungspen-Test ohne ein unterzeichnetes, spezifisches Genehmigungsdokument vom Authorizing Official des Systems. Allgemeine Genehmigungen für „Sicherheitsbewertungen" von Programmmanagern oder Hauptauftragnehmern bieten keinen CFAA-Schutz. Die Genehmigung muss die Tester namentlich nennen, die im Geltungsbereich befindlichen Systeme angeben, das Testfenster definieren und die zulässigen Methoden aufzählen.
Freigabeanforderungen fügen eine weitere Schicht hinzu. Das Testen eines klassifizierten Systems setzt voraus, dass Tester gültige Freigaben auf dem entsprechenden Klassifizierungsniveau besitzen. Die Testorganisation muss eine Facility Clearance (FCL) auf diesem Niveau besitzen. Die Einführung von nicht freigegebenen Personen – selbst in unterstützenden Rollen – in eine klassifizierte Testumgebung ist eine Sicherheitsverletzung, unabhängig davon, was sie tatsächlich sehen oder berühren.
ITAR (International Traffic in Arms Regulations) führt weitere Einschränkungen für Programme ein, die kontrollierte Verteidigungsartikel beinhalten. Informationen über Schwachstellen in ITAR-kontrollierten Systemen können selbst Exportkontrollbeschränkungen unterliegen und einschränken, was über internationale Grenzen hinweg dokumentiert, übertragen oder geteilt werden darf – auch innerhalb multinationaler alliierter Programme. Testfirmen, die unter internationalen Subunternehmervereinbarungen tätig sind, müssen dies ausdrücklich berücksichtigen.
Bedrohungsakteur-Emulation: TTPs von Nationalstaaten, keine generischen Exploits
Kommerzielle Pen-Tests konzentrieren sich oft darauf, irgendwelche ausnutzbaren Schwachstellen zu finden – die häufigsten, leichtest verfügbaren, am höchsten CVSS-bewerteten Probleme auf der Angriffsfläche des Ziels. Für ein Unternehmensnetzwerk ist dies ein vernünftiger Ansatz: Ein opportunistischer Angreifer wird den einfachsten verfügbaren Pfad ausnutzen.
Verteidigungssysteme sehen sich einer grundlegend anderen Bedrohungspopulation gegenüber. Die primären Gegner für hochwertige Verteidigungsziele sind Nationalstaatenakteure mit erheblichen Ressourcen, fortgeschrittenen Fähigkeiten und langen Zeithorizonten. Sie werden nicht durch das Patchen des CVSS-10-OpenSSL-Problems aufgehalten, wenn sie über einen vertrauenswürdigen Lieferketten-Partner, eine veraltete eingebettete Komponente oder eine Cross-Domain-Solution-Fehlkonfiguration wechseln können.
Effektive Verteidigungspen-Tests verwenden Gegner-Emulation: Das Testteam repliziert die Taktiken, Techniken und Verfahren (TTPs) spezifischer Bedrohungsakteurgruppen, die für das Bedrohungsmodell des Programms relevant sind. Das MITRE ATT&CK-Framework bietet eine strukturierte Taxonomie dafür, mit Enterprise- und ICS-Matrizen, die die von Advanced-Persistent-Threat-Gruppen am häufigsten eingesetzten Techniken abdecken.
Für Verteidigungssysteme umfassen die relevanten Bedrohungsakteure in der Regel:
- APT28 (Fancy Bear / GRU-Einheit 26165) — Russischer Militärgeheimdienst, bekannt für Spearphishing, Credential Harvesting und Persistenz durch Missbrauch legitimer Tools. Zu den Taktiken, die für Verteidigungssoftware relevant sind, gehört die Ausrichtung auf Entwicklerworkstations und Build-Pipelines, um bösartigen Code stromaufwärts der Bereitstellung einzuschleusen.
- Lazarus Group (DVRK) — Nordkoreanischer Staatsakteur mit einer Erfolgsbilanz beim Angriff auf Verteidigungsauftragnehmer und Raumfahrtunternehmen, insbesondere durch Watering-Hole-Angriffe und mit Waffen ausgestattete Stellenbewerbungs-Köder, die auf freigegebenes Personal abzielen.
- Volt Typhoon (PRC) — Chinesischer Staatsakteur, der sich auf Living-off-the-Land-Techniken konzentriert, um persistenten, geräuscharmen Zugang zu kritischer Infrastruktur und Verteidigungsnetzwerken zu erlangen. Bekannt dafür, benutzerdefinierte Malware zu vermeiden und stattdessen integrierte Systemtools zu nutzen, um der Erkennung zu entgehen.
Der Testplan sollte angeben, welches Angreiferprofil emuliert wird und warum, basierend auf der Bedrohungsbewertung des Programms. Ein Test, der den Living-off-the-Land-Ansatz von Volt Typhoon emuliert, wird sehr anders aussehen als einer, der die credential-fokussierten Operationen von APT28 emuliert – und beide werden sich von einem Test unterscheiden, der sich auf Insider-Bedrohungsszenarien oder die Integrität der Lieferkette konzentriert.
Hinweis zur Gegnerauswahl: Das Bedrohungsakteurprofil sollte durch die nachrichtendienstlich informierte Bedrohungsbewertung des Programms bestimmt werden, nicht durch die Präferenz des Testers oder generische „fortgeschrittene" Bezeichnungen. Bei Programmen mit spezifischen geografischen Bedrohungsprofilen oder bekannter Zielhistorie sollte der ISSO das Testteam vor Beginn des Auftrags über aktuelle Bedrohungsberichte informieren.
Umfangsmanagement: Keine-Ausfallzeit-Einschränkungen und isolierte Testumgebungen
Kommerzielle Pen-Test-Umfangseinschränkungen dienen in erster Linie der Haftungsbegrenzung und der Fokussierung der Bemühungen. Verteidigungsumfangseinschränkungen tragen zusätzliche Dimensionen, die grundlegend beeinflussen, wie ein Test durchgeführt werden kann.
Viele Verteidigungssysteme können während des Testens keine Ausfallzeiten akzeptieren. Befehls- und Kontrollsysteme, Kommunikationsinfrastruktur und Echtzeit-Sensorfusionsplattformen können während eines Testfensters operativ aktiv sein. Ein Ausnutzungsversuch, der eine Dienstunterbrechung verursacht – selbst eine kurze – kann operative Konsequenzen haben, die keine vertragliche Haftungsfreistellung beheben kann. Die übliche kommerzielle Vorgehensweise, gegen Produktionssysteme mit einer „Stopp bei instabilem Verhalten"-Regel zu testen, ist für diese Umgebungen nicht akzeptabel.
Die praktische Konsequenz ist, dass viele Verteidigungspen-Tests in dedizierten Testumgebungen durchgeführt werden: isolierten Netzwerksegmenten, Staging-Umgebungen oder Lab-Replikaten, die die Produktion so genau wie möglich widerspiegeln. Die Treue der Testumgebung ist enorm wichtig. Eine Testumgebung, die andere Firmware-Versionen verwendet, keine Produktionsintegrationen besitzt oder mit entspannteren Zugriffskontrollen im Vergleich zur Produktion arbeitet, wird Befunde produzieren, die nicht die tatsächliche Risikohaltung des operativen Systems widerspiegeln. Die Treue der Testumgebung ist eine Investition, zu der sich das Programmbüro verpflichten muss – es ist nicht das Problem des Testteams zu lösen.
Umfangsverletzungen werden in Verteidigungsumgebungen schwerwiegender behandelt als in kommerziellen. Das versehentliche Berühren eines Systems außerhalb des genehmigten Umfangs ist kein geringfügiges Verfahrensproblem – es kann einen unbefugten Zugriff auf ein staatliches Informationssystem darstellen. Tester müssen während des gesamten Auftrags ein detailliertes Aktivitätsprotokoll führen und wesentliche Aktionen nahezu in Echtzeit dokumentieren, sodass etwaige Umfangsfragen, die während oder nach dem Test auftreten, mit Beweisen statt Erinnerungen geklärt werden können.
Verteidigungsspezifische Schwachstellenklassen
Über die Verfahrensunterschiede hinaus weisen Verteidigungssysteme Schwachstellenklassen auf, die in kommerziellen Pen-Testing-Methoden unterrepräsentiert sind.
Veraltete eingebettete Systeme. Verteidigungsplattformen betreiben routinemäßig Software auf Hardware, die 10–20 Jahre alt ist, mit eingebetteter Firmware, die nicht durch normale Software-Update-Mechanismen gepatcht werden kann. Schwachstellen in diesen Komponenten können bekannt, aber im Lebenszyklus des Systems nicht behebbar sein – der Pen-Test-Befund wird zu einem dauerhaften POAM-Eintrag mit einer Abweichungsanforderung statt zu einem Behebungsticket. Tester müssen verstehen, was „Befund" in diesem Kontext bedeutet: Der Wert liegt in der Dokumentation und Quantifizierung des Risikos, nicht unbedingt darin, eine sofortige Behebung voranzutreiben.
Cross-Domain-Solutions. Systeme, die Daten auf mehreren Klassifizierungsebenen verarbeiten, verwenden Cross-Domain-Solutions (CDS), um Daten zwischen Sicherheitsdomänen zu verschieben. Dies sind hochwertige Ziele: Eine CDS, die manipuliert werden kann, um Informationen in die falsche Richtung weiterzuleiten, besiegt die gesamte Datenverarbeitungsarchitektur. CDS-Tests erfordern spezialisiertes Fachwissen und eine spezifische Genehmigung – diese Komponenten werden oft als separate Geltungsbereiche innerhalb einer umfassenderen Programmbewertung behandelt.
Lieferkettenintegrität. Die bedeutendsten Software-Lieferkettenangriffe der letzten Jahre (SolarWinds, XZ Utils) richteten sich gegen Build-Pipelines und Dependency-Injection statt gegen laufende Systeme. Verteidigungsprogramme sind hochwertige Ziele für diese Angriffskategorie. Pen-Tests sollten eine Bewertung der Build-Umgebung umfassen: Kann ein Angreifer mit Zugang zu einem Entwicklerworkstation bösartigen Code einschleusen, der in einem Produktions-Build überlebt? Kann eine kompromittierte Abhängigkeit eingeführt werden, ohne bestehende Kontrollen auszulösen?
Zertifikat- und Schlüsselmanagement. Verteidigungssysteme sind stark auf PKI-Infrastruktur für Authentifizierung und Kommunikationssicherheit angewiesen. Fehlkonfigurierte Zertifikatvalidierung, zu breite Trust-Anchor-Konfigurationen und schlechtes Schlüssel-Lifecycle-Management sind konsistent hochschwere Befunde. Im Gegensatz zu Anwendungsschwachstellen sind diese für automatisches Scanning oft unsichtbar und erfordern eine manuelle Überprüfung der PKI-Architektur gegen das Sicherheitsdesign des Systems.
Der Befund-Lebenszyklus: POAM, ATO-Auswirkungen und Abweichungsanforderungen
In kommerziellen Aufträgen geht der Pen-Test-Bericht an den CISO, Befunde werden triagiert, ein Teil wird behoben, und der Rest altert in einem Tracker bis zur nächsten Bewertung. Der Prozess wird durch Risikobereitschaft und Engineering-Kapazität gesteuert.
In Verteidigungsumgebungen fließen Befunde in einen formalen Akkreditierungslebenszyklus mit rechtlichen und vertraglichen Auswirkungen ein. Das Schlüsselkonzept ist der Plan of Action and Milestones (POAM): ein Dokument, das jede bekannte Schwachstelle im System verfolgt, gegen das eine ATO erteilt wurde oder angestrebt wird. Jeder Befund aus einem Pen-Test, der nicht sofort behoben wird, muss mit einem geplanten Behebungsdatum, verantwortlichem Eigentümer und einer vorläufigen Minderungsmaßnahme in den POAM eingetragen werden.
Der POAM wird vom Authorizing Official als Bedingung der ATO-Wartung überprüft. Offene hochschwere Elemente ohne angemessene vorläufige Minderungen oder realistische Behebungszeitpläne können eine ATO-Aussetzung auslösen – was das System effektiv offline stellt, bis die Risikohaltung angesprochen wird. Für ein Programmbüro ist dieses Ergebnis so ernst, dass einige Programme den Pen-Testing-Umfang verzögern oder begrenzen, um zu vermeiden, Befunde zu generieren, die eine ATO-Überprüfung auslösen könnten. Dies ist ein Risikomanagementfehler: Die Schwachstellen existieren, ob sie dokumentiert sind oder nicht.
Für Befunde, die nicht behoben werden können – veraltete Komponenten ohne verfügbare Patches, architektonische Einschränkungen, die eine vollständige Systemneuentwicklung erfordern würden – kann das Programmbüro eine Abweichungsanforderung oder eine Risikoakzeptanz beim AO einreichen. Dies ist kein Eingeständnis des Scheiterns; es ist der formale Mechanismus für den Betrieb mit bekanntem Restrisiko unter ausdrücklicher Genehmigung. Tester sollten diesen Prozess verstehen und Befunde so formulieren, dass sie dem ISSO helfen, vertretbare POAM-Einträge und Abweichungsanforderungen zu konstruieren, nicht nur in einer Weise, die CVSS-Werte maximiert.
Berichtsformatierung für Verteidigungsprogramme: Verteidigungspen-Test-Berichte sollten für jeden Befund enthalten: eine Klassifizierungsmarkierung, eine Schweregradbewertung, die auf die Risikoakzeptanzkriterien des Programms abgestimmt ist, eine Bewertung der Ausnutzbarkeit angesichts der tatsächlichen Bedrohungsakteure des Programms und eine empfohlene POAM-Disposition. Berichte, die im kommerziellen Format verfasst sind – CVSS-Werte, allgemeine Behebungsempfehlungen, Zusammenfassungen für nicht-technische Führungskräfte – erfordern erhebliche Überarbeitung, bevor der ISSO sie verwenden kann.
So planen und genehmigen Sie einen Verteidigungspen-Test
Die folgenden Schritte spiegeln die Anforderungen für einen verteidigungsfähigen, rechtlich genehmigten Penetrationstest an einem Verteidigungssoftwaresystem wider.
Schritt 1: Rechtliche Befugnis und schriftliche Genehmigung einholen. Holen Sie ein unterzeichnetes Testgenehmigungsdokument vom AO des Systems ein. Das Dokument muss die Tester namentlich nennen, die im Geltungsbereich befindlichen Systeme angeben, das Testfenster definieren und die zulässigen Methoden aufzählen. Dies ist keine Formalität – es ist das Instrument, das das Testen rechtmäßig macht.
Schritt 2: Freigabe- und Einrichtungsnachweise überprüfen. Bestätigen Sie, dass alle Tester gültige Freigaben auf dem Klassifizierungsniveau des Zielsystems besitzen und dass die Testorganisation eine FCL des erforderlichen Niveaus besitzt. Weisen Sie alle Tester vor dem Zugang zu klassifizierten Umgebungen in den Sicherheitsklassifizierungsleitfaden des Programms ein.
Schritt 3: Umfang und Testumgebungsgrenzen definieren. Identifizieren Sie, welche Systeme, Netzwerke und Schnittstellen im Geltungsbereich liegen. Wo operative Systeme keine Ausfallzeiten akzeptieren können, richten Sie eine dedizierte Testumgebung ein. Dokumentieren Sie explizite Ausschlüsse und weisen Sie Tester auf die rechtlichen Konsequenzen von Umfangsverletzungen hin.
Schritt 4: Testtools auswählen und prüfen. Überprüfen Sie ITAR-Verpflichtungen und Programmakkreditierungsanforderungen, um festzustellen, welche Tools zulässig sind. Schließen Sie Tools mit Komponenten ausländischer Herkunft, cloudbasierter Lizenzierung oder ausgehender Telemetrie aus. Dokumentieren Sie den Toolsatz im Testplan und reichen Sie ihn vor Beginn des Auftrags beim Programmbüro zur Überprüfung ein.
Schritt 5: Bedrohungsakteur-Emulation basierend auf dem Bedrohungsmodell des Programms durchführen. Wählen Sie das für das System relevanteste Angreiferprofil aus. Verwenden Sie MITRE ATT&CK für ICS oder Enterprise je nach Bedarf, angepasst an die spezifische Systemarchitektur und das Missionsprofil. Ersetzen Sie keine generischen „fortgeschrittenen" Tests durch tatsächliche Gegner-Emulation.
Schritt 6: Aktivitäten und Befunde mit Klassifizierungsmarkierungen dokumentieren. Führen Sie während des gesamten Auftrags ein detailliertes Aktivitätsprotokoll. Alle Befunde müssen angemessene Klassifizierungsmarkierungen und Schweregradbewertungen tragen, die auf die Risikoakzeptanzkriterien des Programms abgestimmt sind.
Schritt 7: Befunde in den POAM eintragen und Behebung verfolgen. Arbeiten Sie mit dem ISSO zusammen, um alle offenen Befunde in den POAM einzutragen. Weisen Sie Behebungsverantwortliche, geplante Termine und vorläufige Minderungsmaßnahmen zu. Schwere Befunde sollten direkt dem AO vorgetragen werden – lassen Sie kritische Schwachstellen nicht ohne ausdrückliche Risikoakzeptanz oder aktive Behebung in einer Warteschlange verweilen.