Rules of Engagement: Was einen Red-Team-Einsatz sicher macht

Ein Red Teaming ist ein kontrollierter Angriff auf Produktivsysteme, auf Menschen und manchmal auf Gebäude, verdeckt und über Wochen. Dass dabei nichts kaputtgeht, niemand zu Schaden kommt und der Einsatz rechtlich sauber bleibt, ist kein Zufall und keine Frage des Vertrauens in den Dienstleister. Es ist das Ergebnis eines Dokuments, das vor dem ersten Schritt steht: der Rules of Engagement, kurz RoE.

In unseren Erstgesprächen fragen Entscheider selten nach der Technik des Angriffs, aber fast immer nach drei Dingen: Was passiert, wenn etwas ausfällt? Wer weiß Bescheid? Und ist das überhaupt legal? Alle drei Fragen beantworten die Rules of Engagement – und wie sorgfältig ein Anbieter sie ausarbeitet, sagt mehr über seine Professionalität als jede Referenzliste.

Dieser Beitrag beschreibt, was in ein vollständiges RoE-Dokument gehört, erklärt die Rechtsgrundlage nach deutschem Recht und schließt mit einer Checkliste, die Sie vor Unterschrift Punkt für Punkt abhaken können.

Wozu Rules of Engagement dienen

Die Rules of Engagement sind der Vertrag über das Wie des Einsatzes. Der Dienstleistungsvertrag regelt Leistung, Vergütung und Haftung; die RoE regeln, was das Red Team tun darf, was nicht, wann, mit wem es spricht und was im Ernstfall geschieht. Sie werden gemeinsam im Scoping erarbeitet und von beiden Seiten unterschrieben, bevor eine einzige Aktion gegen Ihre Systeme stattfindet.

Drei Zwecke erfüllt das Dokument gleichzeitig. Es schützt Ihren Betrieb, indem es Grenzen setzt. Es schützt das Red Team, indem es die Autorisierung dokumentiert, ohne die jeder Zugriff strafbar wäre. Und es schützt die Aussagekraft des Tests, indem es regelt, wer eingeweiht ist – denn ein Red Teaming, von dem das SOC weiß, misst nichts.

Inhalte eines vollständigen RoE-Dokuments

Scope und Ziele

Der Scope benennt, was angegriffen werden darf: Domänen, IP-Bereiche, Cloud-Mandanten, Standorte, Mitarbeitendengruppen. Beim Full-Scope Red Teaming ist das die gesamte Organisation, beim Assumed Breach ein definierter Startpunkt. Die Ziele werden als Flags formuliert – etwa „Nachweis des Zugriffs auf das Zahlungsfreigabesystem“ – und zusammen mit der Art des Nachweises festgelegt: Screenshot der Oberfläche, nicht Auslösung einer Zahlung.

Ausschlüsse

Ebenso wichtig ist, was nicht angegriffen wird: Systeme, deren Störung Menschen gefährden könnte (Produktionssteuerung, Medizintechnik, Gebäudetechnik), Systeme Dritter, auf die Sie keine Rechte haben (Cloud-Plattformen des Anbieters, Systeme von Kunden), und Personengruppen, die ausgenommen bleiben – etwa Mitarbeitende in Elternzeit oder der Betriebsrat, sofern das mit ihm vereinbart ist. Auch bestimmte Techniken können ausgeschlossen werden, etwa Denial-of-Service oder physischer Zutritt in Bereiche mit Zutrittskontrollen durch Dritte.

Zeitfenster

Das Dokument nennt Start- und Enddatum des Einsatzes sowie Tageszeiten, in denen aktive Schritte erlaubt sind. Üblich ist, risikoreichere Aktionen auf Bürozeiten zu beschränken, damit das Control Team erreichbar ist – oder im Gegenteil bewusst Nachtstunden einzubeziehen, um die Reaktionsfähigkeit außerhalb der Kernzeit zu prüfen. Sperrzeiten wie Monatsabschluss, Produkteinführungen oder Wartungsfenster werden ausdrücklich benannt.

Control Team und Kommunikationswege

Das Control Team – im TIBER-Rahmenwerk früher White Team genannt – besteht aus den zwei bis vier Personen im Unternehmen, die eingeweiht sind: typischerweise CISO oder IT-Leitung, ein Mitglied der Geschäftsführung, bei Bedarf Datenschutz oder Recht. Das Dokument listet Namen, Rollen, Telefonnummern und Vertretungen. Es legt fest, über welche Kanäle kommuniziert wird – in der Regel verschlüsselt per PGP oder S/MIME und über ein Messaging-Werkzeug außerhalb der Unternehmensinfrastruktur, damit ein mitlesendes SOC den Test nicht zufällig entdeckt – und in welchem Rhythmus das Red Team berichtet. Für DORA-TLPT schreibt die RTS 2025/1190 ein wöchentliches Reporting an das Control Team vor; außerhalb der Regulierung hat sich derselbe Takt bewährt.

Deconfliction

Wenn das SOC während des Einsatzes verdächtige Aktivität meldet, muss das Control Team innerhalb von Minuten klären können, ob sie vom Red Team stammt oder von einem echten Angreifer. Dafür hinterlegt das Red Team vorab die Quell-IP-Adressen seiner Infrastruktur, die Namen angelegter Konten und Hosts sowie einen Rückfragekanal, der rund um die Uhr erreichbar ist. Deconfliction verhindert zwei Fehler: dass ein echter Angriff für den Test gehalten und ignoriert wird – und dass der Test eine vollständige Incident-Response-Eskalation mit externen Forensikern auslöst, die niemand wollte.

Abbruchkriterien

Das Dokument definiert, unter welchen Umständen der Einsatz sofort pausiert oder beendet wird: Entdeckung eines echten Angreifers oder von Spuren einer früheren Kompromittierung, unbeabsichtigte Störung eines Systems, Zugriff auf Daten einer besonders geschützten Kategorie, Gefährdung von Personen bei physischen Tests, oder auf Anweisung des Control Teams ohne Begründung. Ebenso wird geregelt, wie der Einsatz nach einem Abbruch wieder aufgenommen wird und wer das entscheidet.

Notfallkontakte

Beidseitig und rund um die Uhr: Auf Unternehmensseite das Control Team mit Vertretung, auf Dienstleisterseite die Einsatzleitung mit Vertretung. Die Nummern stehen im Dokument, nicht in einer E-Mail, die niemand wiederfindet.

Umgang mit Zufallsfunden und Daten

Ein Red Team stößt auf Dinge, die nicht sein Ziel sind: Klartext-Passwörter in Skripten, personenbezogene Daten in offenen Freigaben, Hinweise auf Fehlverhalten einzelner Mitarbeitender. Die RoE regeln, was damit geschieht – in der Regel: dokumentieren, nicht weiterverwenden, dem Control Team melden, in den Bericht aufnehmen, sofern sicherheitsrelevant. Für Daten gilt: Das Red Team greift auf so wenig zu wie für den Nachweis nötig, speichert Nachweise verschlüsselt und löscht alle Projektdaten nach einer vereinbarten Frist nach Projektende. Ein NDA ergänzt diese Regelungen auf Vertragsebene.

Rückbau

Alle Änderungen, die das Red Team vornimmt, werden am Ende rückgängig gemacht: angelegte Konten gelöscht, hinterlegte Werkzeuge und Persistenzmechanismen entfernt, geänderte Konfigurationen zurückgesetzt. Das Red Team übergibt dem Control Team eine vollständige Liste aller Indicators of Compromise (IOCs) – Hashes, Dateinamen, IP-Adressen, Kontonamen –, damit Ihr Team prüfen kann, dass nichts zurückbleibt, und damit diese Artefakte in der Erkennung künftig nicht mit echten Angriffen verwechselt werden.

Rechtsgrundlage: § 202a ff. StGB und die schriftliche Autorisierung

Nach deutschem Recht ist das Ausspähen von Daten (§ 202a StGB), das Abfangen von Daten (§ 202b StGB) und das Vorbereiten solcher Taten durch Beschaffen oder Herstellen von Werkzeugen (§ 202c StGB, der sogenannte Hackerparagraf) strafbar. Hinzu kommen Datenveränderung (§ 303a StGB) und Computersabotage (§ 303b StGB). Ein Red Team tut im Verlauf eines Einsatzes vieles, was diese Tatbestände objektiv erfüllt.

Straflos ist das nur, weil der Berechtigte einwilligt. Diese Einwilligung muss von einer Person kommen, die über die betroffenen Systeme und Daten tatsächlich verfügen darf – in der Regel die Geschäftsführung oder ein Vorstandsmitglied, nicht ein IT-Leiter allein. Sie muss vor dem Einsatz vorliegen, schriftlich sein und den Umfang präzise beschreiben: Systeme, die dem Unternehmen nicht gehören, können nicht freigegeben werden. Deshalb stehen Cloud-Plattformen fremder Anbieter, Systeme von Dienstleistern und Privatgeräte von Mitarbeitenden regelmäßig in den Ausschlüssen, sofern nicht deren Eigentümer gesondert zustimmt.

Für Social-Engineering-Komponenten kommen weitere Rechtsgebiete hinzu: Datenschutz bei der Verarbeitung personenbezogener Daten von Mitarbeitenden, Mitbestimmung des Betriebsrats bei Maßnahmen, die das Verhalten von Beschäftigten erfassen, und Persönlichkeitsrechte bei Vishing-Anrufen. Ein seriöser Anbieter spricht diese Punkte im Scoping aktiv an und schlägt vor, den Betriebsrat über das Format – nicht über den Zeitpunkt – zu informieren. Wir erteilen keine Rechtsberatung; für Ihr Unternehmen sollte die Rechtsabteilung oder ein externer Anwalt die RoE gegenlesen.

Praxis-Tipp: Verlangen Sie vom Anbieter den Entwurf der Rules of Engagement vor Vertragsabschluss, nicht danach. Ein Dienstleister, der die Abbruchkriterien, die Deconfliction und den Umgang mit Zufallsfunden erst auf Nachfrage ausformuliert, hat diese Situationen nicht oft genug erlebt. Achten Sie besonders auf eine Formulierung: Störende Schritte – etwa ein Neustart, eine Kontosperrung oder eine simulierte Verschlüsselung – dürfen nur nach ausdrücklicher Freigabe des Control Teams im Einzelfall erfolgen, nie pauschal.

Checkliste: Rules of Engagement vor Unterschrift prüfen

Scope vollständig benannt: Domänen, Netzbereiche, Cloud-Mandanten, Standorte, Personengruppen.
Flags konkret formuliert, inklusive Art des Nachweises ohne destruktive Aktion.
Ausschlüsse explizit gelistet: kritische Systeme, Systeme Dritter, geschützte Personengruppen, ausgeschlossene Techniken.
Startpunkt festgelegt (Full Scope oder Assumed Breach mit Beschreibung des bereitgestellten Zugangs).
Zeitfenster mit Start, Ende, Tageszeiten und Sperrzeiten.
Control Team namentlich benannt mit Rollen, Vertretungen und Erreichbarkeit rund um die Uhr.
Kommunikationswege definiert: verschlüsselter Kanal außerhalb der Unternehmensinfrastruktur, Berichtsrhythmus.
Deconfliction-Verfahren beschrieben: hinterlegte IP-Adressen, Konto- und Hostnamen, Rückfragekanal.
Abbruchkriterien aufgezählt, inklusive Verfahren zur Wiederaufnahme.
Notfallkontakte beidseitig mit Vertretung.
Regelung für störende Schritte: Einzelfreigabe durch das Control Team.
Umgang mit Zufallsfunden und Daten: Minimalprinzip, Verschlüsselung, Meldung, Löschfrist.
Rückbau und IOC-Übergabe als Pflichtleistung vor Projektende.
Schriftliche Autorisierung durch eine vertretungsberechtigte Person; NDA unterzeichnet.
Rechtliche Prüfung durch Rechtsabteilung oder externen Anwalt, Datenschutz und gegebenenfalls Betriebsrat einbezogen.
Verfahren für Änderungen während des Einsatzes: schriftlich, von beiden Seiten bestätigt.

Die RoE während des Einsatzes

Das Dokument ist nicht nach Unterschrift erledigt. Im Verlauf eines mehrwöchigen Einsatzes entstehen Situationen, die niemand vorhergesehen hat: Das Red Team entdeckt einen Weg zu einem System, das im Scope steht, dessen Betreiber aber gerade eine kritische Migration durchführt. Oder ein Mitarbeitender meldet eine Phishing-Mail, und das SOC will den Absender blockieren. In diesen Fällen wird das Control Team konsultiert, die Entscheidung dokumentiert und bei Bedarf das RoE-Dokument ergänzt.

Besonders bewährt hat sich die Regel, dass das Red Team vor jedem Schritt mit erhöhtem Störungsrisiko – Ausnutzung einer Schwachstelle auf einem Produktivserver, Übernahme eines privilegierten Kontos, Zugriff auf Backup-Infrastruktur – das Control Team informiert und eine Freigabe einholt. Das kostet wenige Stunden Verzögerung und verhindert die Situation, die kein Entscheider erleben will: ein Ausfall, bei dem nachher unklar ist, ob der Test oder etwas anderes ihn verursacht hat.

Fazit

Die Rules of Engagement sind kein Formular, sondern das Sicherheitskonzept des Red Teamings. Sie legen fest, was angegriffen wird und was nicht, wer eingeweiht ist, wie kommuniziert wird, wann abgebrochen wird und wie der Einsatz rechtlich abgesichert ist. Ein vollständiges Dokument schützt Ihren Betrieb, das Red Team und die Aussagekraft des Tests gleichermaßen. Wie unsere Rules of Engagement aufgebaut sind und wie wir sie im Scoping mit Ihnen erarbeiten, zeigen wir Ihnen gern vor Vertragsabschluss – Details zu unserem Vorgehen finden Sie unter Red Teaming und Ablauf, oder Sie nehmen direkt Kontakt auf.

Quellen

Strafgesetzbuch (StGB), §§ 202a, 202b, 202c, 303a, 303b
Delegierte Verordnung (EU) 2025/1190 (RTS zu TLPT nach DORA) – Anforderungen an Control Team, Reporting und Abschlussphase, eur-lex.europa.eu
Europäische Zentralbank, TIBER-EU Framework, Fassung Februar 2025, ecb.europa.eu
BSI, Praxis-Leitfaden IS-Penetrationstest, bsi.bund.de

Häufige Fragen zum Thema

Wer unterschreibt die Rules of Engagement?

Auf Unternehmensseite eine vertretungsberechtigte Person, in der Regel die Geschäftsführung oder ein Vorstandsmitglied, auf Dienstleisterseite die Projektleitung. Die Unterschrift ist zugleich die schriftliche Autorisierung, die den Einsatz rechtlich absichert.

Was passiert, wenn das Red Team einen echten Angreifer entdeckt?

Das ist ein definiertes Abbruchkriterium. Das Red Team stoppt seine Aktivität, informiert sofort das Control Team über den vereinbarten Notfallkanal und übergibt die Beobachtungen. Die Vorfallbehandlung hat Vorrang vor dem Test.

Darf das Red Team Produktionssysteme angreifen?

Nur im vereinbarten Rahmen. Systeme, deren Störung nicht verantwortbar ist, stehen als Ausschlüsse in den Rules of Engagement. Für alle anderen gilt: nicht-destruktive Methoden, störende Schritte nur nach ausdrücklicher Freigabe durch das Control Team.

Was ist Deconfliction?

Ein Verfahren, mit dem das Control Team jederzeit prüfen kann, ob eine verdächtige Aktivität vom Red Team stammt oder von einem echten Angreifer. Dazu dienen bekannte Quell-IP-Adressen, Konto-Namen und ein Kanal für Rückfragen.

Wie lange sind Rules of Engagement gültig?

Für die Dauer des Einsatzes inklusive Rückbau. Das Dokument nennt ein Start- und ein Enddatum; außerhalb dieses Fensters findet keine Aktivität statt. Änderungen während des Einsatzes werden schriftlich nachgetragen.

Begriffe aus diesem Beitrag

Rules of Engagement Control Team (White Team)Scoping Red Teaming Hackerparagraf (§ 202a ff. StGB)IOC (Indicator of Compromise)Flags (Missionsziele)C2-Framework

Redaktion Gruppe RotDieser Beitrag wurde vom Red-Team von Gruppe Rot verfasst und fachlich geprüft. Er ersetzt keine Rechtsberatung. Zahlen und Quellen sind im Text genannt; bei Fragen oder Korrekturhinweisen freuen wir uns über eine Nachricht.