Planung und RoE — Geführte Demonstration
Ein Szenario. Ein KMU. Ein Projektleiter, der sich damit nicht auskennt. Wir werden Zeile für Zeile ein vollständiges Rules of Engagement verfassen und dabei zeigen, wo der Kunde Ihnen ungewollt eine Falle stellen würde.
Das Szenario
Der Kunde: Boutique Éclair, québécisches E-Commerce-Unternehmen, 45 Mitarbeiter, Online-Shop + mobile Anwendung + internes Backoffice.
Die Anfrage: „Wir hätten gern einen Pentest unseres gesamten Parks. Ein Mitbewerber wurde letztes Jahr gehackt, wir wollen prüfen, ob bei uns alles in Ordnung ist.“
Das Budget: 15 Personentage.
Sie: Freelancer oder Dienstleister, kurz vor der Unterschrift.
Genau in diesem Moment sagen 90 % der Anfänger Ja und beginnen zu scannen. Wir machen das Gegenteil: Fragen stellen, bevor wir schreiben.
Schritt 1 — Der Abgrenzungsfragebogen
Vor jedem RoE steht ein Abgrenzungsgespräch. Mindestens zwölf Fragen. Hier sind die genauen Fragen an Boutique Éclair, mit ihren wahrscheinlichen Antworten und was das im RoE ändert.
F1 — „Wo hosten Sie jede Komponente?“
Antwort des Kunden: „Unsere Website liegt bei Shopify. Die mobile Anwendung greift auf eine API zu, die wir bei AWS Montréal hosten. Das Backoffice läuft in unseren Büros, auf einem alten Server.“
Was das ändert:
- Shopify: im klassischen Sinn nicht pentestbar. Sie können nur testen, was vom Kunden bereitgestellt wird (individuelle Themes, private Apps). Der Rest gehört Shopify.
- AWS Montréal: Test ohne vorherige Benachrichtigung für die meisten Dienste erlaubt, aber prüfen Sie die AWS-Richtlinie am Tag des Auftrags.
- Server in den Büros: Test erlaubt, mit Zustimmung des Kunden zu den Zeitfenstern, um den Betrieb nicht zu stören.
Im RoE haben wir also drei getrennte Geltungsbereiche, mit drei unterschiedlichen Regelungen.
F2 — „Wer ist Eigentümer der Domain boutique-eclair.ca?“
Antwort: „Die liegt bei unserem Webmaster, er hat den Namen auf seinen eigenen Namen gekauft.“
Was das ändert: Der Webmaster muss ebenfalls unterschreiben. Sonst ist Ihr Angriff auf boutique-eclair.ca nicht durch eine Genehmigung des Namensinhabers gedeckt.
Im RoE fügen Sie eine Garantieklausel hinzu, dass der Kunde die Rechte an allen gelisteten Assets besitzt.
F3 — „Welche sensiblen Daten laufen über diese Systeme?“
Antwort: „Kreditkarten auf der Website, E-Mails und Adressen der Kunden im Backoffice, und medizinische Daten einiger Mitarbeiter (Gruppenversicherung).“
Was das ändert:
- Kreditkarten: PCI-DSS-Umgebung. Strenge Vorgaben.
- E-Mail-Adressen der Kunden: personenbezogene Daten. Loi 25 (Québec) + DSGVO, falls Sie europäische Kunden berühren.
- Medizinische Daten: RSS. Sie fassen sie nicht an.
Im RoE: vollständiger rechtlicher Abschnitt und expliziter Ausschluss der Systeme, die medizinische Daten speichern.
Definition — PCI-DSS, was sich ändert, sobald Bankkarten ins Spiel kommen
PCI-DSS — Payment Card Industry Data Security Standard — ist das Regelwerk, das die großen Kartennetzwerke (Visa, Mastercard, American Express, Discover, JCB) jedem Händler auferlegen, der ihre Zahlungen akzeptiert. Die zum Zeitpunkt dieser Zeilen aktuelle Version ist 4.0, mit verschärften Anforderungen an Protokollierung, Authentifizierung und Zugriffsverwaltung.
Zwei Anforderungen betreffen den Pentester direkt. Die erste: mindestens ein externer und interner Penetrationstest pro Jahr, oder nach jeder wesentlichen Änderung des Kartenbereichs. Das gibt Ihnen ein wiederkehrendes Mandat, sofern Sie qualifiziert sind, es durchzuführen. Die zweite: eine klare Trennung zwischen der Kartendaten-Umgebung (CDE) und dem Rest des Netzwerks. Der Pentester muss überprüfen, dass diese Trennung hält — das ist ein eigenständiger Test, genannt Segmentation Testing.
Drei Vorsichtsmaßnahmen im RoE. Sie testen niemals in Produktion mit echten Kartendaten: die Karten sind tokenisiert, oder die Umgebung ist mit Testdaten geklont. Sie listen die anwendbare PCI-DSS-Version in der Präambel auf — die Anforderungen haben sich zwischen 3.2 und 4.0 verändert. Und Sie bestätigen, dass der Dienstleister — Sie — über eine der anerkannten Qualifikationen verfügt: ASV für externe Scans, PCI Professional für die Compliance-Bewertung, ein zertifizierter Pentester (OSCP, CREST, CPTS) für den Test selbst. Ohne angemessene Qualifikation ist der Bericht bei einem Audit nicht verwertbar.
F4 — „Ist der Pentest Grey-Box, Black-Box, White-Box?“
Antwort des Kunden: „Was ist das?“
Sie erklären:
| Ansatz | Was der Pentester vom Kunden erhält |
|---|---|
| Black-Box | Nichts. Er startet wie ein externer Angreifer, der nichts weiß. |
| Grey-Box | Ein normales Benutzerkonto. Er simuliert einen böswilligen Mitarbeiter oder einen kompromittierten Kunden. |
| White-Box | Alles: Quellcode, Admin-Konten, Architekturdokumentation. Am effizientesten, oft am nützlichsten. |
Ein vernünftiger Kunde wählt für sein Geld Grey-Box oder White-Box. Black-Box kostet viel Aufklärungszeit, ohne notwendigerweise mehr zu liefern. Für Boutique Éclair schlagen Sie Grey-Box für die Website und die API vor, White-Box für das Backoffice.
F5 — „Kann ich Phishing bei Ihren Mitarbeitern versuchen?“
Antwort: „Ja, außer beim Geschäftsführer, der hasst das.“
Was das ändert: eine Ausschlussliste im RoE, und ein Nach-Phishing-Verfahren — wird ein Mitarbeiter, der klickt, geschult, sanktioniert, ignoriert? Das wird im Voraus festgelegt.
F6 — „Wie hoch ist die Toleranzschwelle für einen Zwischenfall?“
Antwort: „Die Website darf tagsüber nicht ausfallen. Das Backoffice können wir am Wochenende abschalten.“
Was das ändert: aggressive Scans und Lasttests sind tagsüber verboten, am Wochenende abends/nachts erlaubt.
F7 — F12 (die übrigen)
- „Wen benachrichtigen Sie, wenn ein laufender Einbruch entdeckt wird?“
- „Wie viele Stunden haben Sie, um auf einen nächtlichen Anruf zu reagieren?“
- „Darf ich ein dauerhaftes Testkonto anlegen?“
- „Darf ich Demo-Daten exfiltrieren?“
- „Wo werden die Beweise während des Auftrags gespeichert?“
- „Muss der Bericht verschlüsselt übergeben werden?“
Jede Antwort erzeugt eine Zeile im RoE.
Schritt 2 — Das RoE, vor Ihren Augen verfasst
Hier ist das fertige RoE, Abschnitt für Abschnitt, mit den Kommentaren, die ein erfahrener Pentester daneben schreiben würde.
2.1. Kopfzeile
Rules of Engagement — Penetrationstest Boutique Éclair
Version 1.2 — Datum: 2026-04-08
Dienstleister: Cursor Sécurité inc., NEQ 1234567890
Kunde: Boutique Éclair inc., NEQ 0987654321
Dauer: 15 Werktage, zwischen dem 2026-04-15 und dem 2026-05-06
Eine Versionsnummer, ein Datum. Jede Änderung erhöht die Nummer. Die unterschriebene Version ist die einzig gültige.
2.2. Technischer Geltungsbereich
Geltungsbereich — drei getrennte Zonen
Zone A — E-Commerce-Website
- Typ: SaaS Shopify + individuelles Theme + 2 private Apps
- Erlaubte Techniken: Test der privaten Apps (Grey-Box, bereitgestelltes Konto),
Überprüfung des Themes (White-Box), Konfigurationstest von Shopify (Dokumentation).
- Verbotene Techniken: jeder aktive Scan gegen die Shopify-IPs.
Jede Ausnutzung außerhalb der individuellen Komponenten.
Zone B — Mobile Anwendungs-API
- Domain: api.boutique-eclair.ca
- IPs: siehe Anhang A (5 elastische AWS-IPs ca-central-1)
- Erlaubte Techniken: aktiver Scan, Ausnutzung, Authentifizierungstests.
- Verbotene Techniken: DoS, destruktive Injektion in die Datenbank.
- Regelung: Grey-Box mit 2 vom Kunden bereitgestellten Benutzerkonten.
Zone C — Internes Backoffice
- Domain: intranet.boutique-eclair.local (Zugriff über bereitgestelltes VPN)
- IPs: 10.20.30.0/24
- Erlaubte Techniken: aktiver Scan, Ausnutzung, Rechteausweitung,
Zugriff auf Demonstrationsdateien.
- Verbotene Techniken: Zugriff auf die Ordner RH_medical/*, Zugriff auf
Gehaltsdateien.
- Regelung: White-Box, Quellcode verfügbar auf GitLab des Kunden.
Übergreifende Ausschlüsse
- AS/400-Server (10.20.30.99) — kritische Legacy-Maschine, nicht getestet.
- Arbeitsplätze der Mitarbeiter — keine Kompromittierung von Kunden.
- Jede Infrastruktur, die Shopify gehört.
Der Geltungsbereich passt auf eine Seite. Jede Zeile lässt sich vor einem Richter verteidigen.
2.3. Erlaubte und verbotene Techniken (Zusammenfassung von Zone B, als Beispiel)
| Technik | Erlaubt? | Anmerkungen |
|---|---|---|
| Aktiver Portscan | Ja | Außerhalb der Geschäftszeiten, max. --max-rate 500. |
| Ausnutzung | Ja | Kein destruktives Schreiben. |
| SQL-Injektion | Ja | Nur auf Demo-Daten. |
| Rechteausweitung | Ja | Kein dauerhaftes Konto nach Behebung. |
| Datenextraktion | Ja | Maximal 100 Zeilen pro Tabelle, nach der Extraktion geschwärzt. |
| Brute-Force-Angriff | Ja | Max. 5 Versuche pro Konto. |
| Denial of Service | Nein | — |
| Social Engineering | Siehe Zone D | — |
Zone D wird gesondert behandelt, weil Phishing eigene Regeln hat.
2.4. Zone D — Social Engineering
- Vektor: Phishing ausschließlich per E-Mail.
- Ziele: 30 Mitarbeiter, gelistet in Anhang B. Geschäftsführer ausgeschlossen.
- Volumen: maximal 2 E-Mail-Wellen, im Abstand von 5 Tagen.
- Versandfenster: Mittwoch 09:00 → 11:00 (Montrealer Zeit).
- Absenderdomain: boutique-eclair-support.com (für die Übung erworben).
- Nach dem Klick: Weiterleitung auf eine interne Sensibilisierungsseite
(vom Kunden bereitgestellt), kein Diebstahl echter Zugangsdaten.
- Bericht: anonymisierte Liste der Klicks; Namen nur an die Personalabteilung.
Jede dieser Vorgaben ist eine Absicherung. Die Zeile „Sensibilisierungsseite, kein Diebstahl von Zugangsdaten“ verhindert einen internen Skandal.
Definition — ethisches Phishing, und warum man niemals wirklich Zugangsdaten stiehlt
Das in einem Pentest autorisierte Phishing zielt nicht darauf ab, nutzbare Passwörter zu erlangen. Es zielt darauf ab, eine Klickrate und eine Eingaberate auf einer präparierten Seite zu messen. Diese Unterscheidung ändert alles, technisch wie rechtlich.
Auf der Zielseite wird eine gefälschte Authentifizierungsaufforderung präsentiert — Logo des Kunden, realistisches Formular, glaubwürdige URL auf der für die Übung erworbenen Domain. Wenn der Mitarbeiter dort seine E-Mail und sein Passwort eingibt, überträgt das Formular die Daten nicht an einen Server, der sie speichern würde. Es verwirft die Eingabe sofort und leitet auf eine Sensibilisierungsseite weiter: „Sie sind gerade auf ein simuliertes Phishing hereingefallen, so erkennen Sie es beim nächsten Mal.“ Der Pentester sieht das Passwort niemals im Klartext; der Bericht enthält nur den Zähler, gegebenenfalls pseudonymisiert.
Dieser Rahmen hat drei Vorzüge. Er macht die Übung konform mit den Vorschriften zu personenbezogenen Daten — man sammelt kein Authentifizierungsgeheimnis. Er macht die Übung für die Personalabteilung vertretbar, die den Mitarbeitern versprechen kann, dass kein Test sie wirklich hereinlegt. Und er maximiert den pädagogischen Wert: Der Mitarbeiter wird der Sensibilisierungsseite in der Sekunde nach seinem Klick ausgesetzt, dem Moment, in dem das Lernen am besten funktioniert. Ein Phishing, das wirklich Zugangsdaten stehlen würde, hätte dieselbe Messung ohne die drei Vorzüge.
2.5. Zeitfenster für Eingriffe
Woche 1 (15.-19. April)
Zone A — Dokumentenprüfung, tagsüber
Zone C — erster Scan, Mittwoch 22:00 → Donnerstag 06:00
Woche 2 (22.-26. April)
Zone B — Ausnutzung, Dienstag und Donnerstag, 09:00 → 18:00
Zone D — Phishing-Welle 1, Mittwoch 09:00 → 11:00
Woche 3 (29. April - 3. Mai)
Zone C — vertiefte Ausnutzung, Samstag 20:00 → Sonntag 08:00
Zone D — Phishing-Welle 2, Mittwoch 09:00 → 11:00
Pufferfenster: 6.-8. Mai, Berichterstellung.
Jedes Feld im Kalender hat eine Absicht. Der Kunde weiß, was ihn erwartet. Sie wissen, was Sie dienstags um 14 Uhr nicht tun dürfen.
2.6. Eskalationskontakte
Operativer Kontakt — Frau Sophie Tremblay, CISO
Telefon: (514) 555-0142 (mobil, erreichbar 9-17 Uhr ET)
E-Mail: sophie.tremblay@boutique-eclair.ca
Notfall-Eskalation (24/7) — Herr Karim Bélanger, CIO
Telefon: (514) 555-0177 (privates Mobiltelefon)
E-Mail: karim@boutique-eclair.ca
Signal: +1 514 555 0177
Missionsleiter (Dienstleister) — Sie
Telefon: (514) 555-0100
PGP: siehe Anhang C
Drei Personen. Drei Mobilnummern. Keine Zentrale. Keine E-Mail mit Abwesenheitsassistent.
2.7. Umgang mit kritischen Situationen
Entdeckung einer ausnutzbaren kritischen Schwachstelle in Produktion
1. Sofortiger Stopp der Ausnutzung.
2. Benachrichtigung von Sophie Tremblay innerhalb von 2 Stunden.
3. Verfassen eines Kurzvermerks (1 Seite) innerhalb von 24 Stunden.
4. Fortsetzung des Pentests auf anderen Achsen.
Entdeckung eines bereits bestehenden Einbruchs
1. Vollständiger Stopp der Tests in der betroffenen Zone.
2. Anruf bei Karim Bélanger innerhalb von 1 Stunde, auf seiner privaten Nummer.
3. Sicherung der Kompromittierungsindikatoren (IoC).
4. Übergang zu einem „Incident-Response“-Mandat, als Nachtrag zu diesem Vertrag.
Entdeckung eines Lecks personenbezogener Daten
1. Benachrichtigung von Sophie Tremblay innerhalb von 1 Stunde.
2. Anwendung der Loi-25-Pflichten: Meldung an die Commission d'accès
à l'information, falls das Leck bestätigt ist und ein ernstes Risiko darstellt.
Diese Verfahren sind keine Gedichte. Es sind Entscheidungsbäume. Man wiederholt sie im Kick-off-Meeting, damit jeder sie auswendig kennt.
2.8. Beweissicherung
Speicherung
- Dedizierte Missionsmaschine, verschlüsselt mit LUKS (aes-xts-plain64, 256 Bit).
- Kein Cloud-Speicher während des Auftrags.
Benennung
- JJJJ-MM-TT_boutique-eclair_<zone>_<ziel>_<aktion>.<ext>
- Bsp.: 2026-04-23_boutique-eclair_zoneB_api_login_bruteforce.pcap
Aufbewahrung
- 90 Tage nach Übergabe des Abschlussberichts.
- Zertifizierte Vernichtung durch DBAN-Überschreibung + unterzeichnete Bescheinigung.
Übergabe
- PGP-verschlüsselter Bericht, Fingerabdruck des Kundenschlüssels telefonisch
mit Sophie Tremblay vor der Übergabe überprüft.
Eines Tages wird jemand Sie fragen: „Was haben Sie mit unseren gestohlenen Passwörtern gemacht?“. Die Antwort steht dort.
2.9. Liefergegenstände
1. Management-Zusammenfassung (2-3 Seiten), an Karim Bélanger übergeben.
Datum: 2026-05-13.
2. Vollständiger technischer Bericht, an Sophie Tremblay übergeben.
Datum: 2026-05-13.
Format: verschlüsseltes PDF + Anhänge (Beweisdateien, Skripte, Screenshots).
3. Mündliche Vorstellungssitzung: 2026-05-16, 90 Minuten, vor Ort.
4. Nachtest-Sitzung nach der Behebung: als Nachtrag abzugrenzen, innerhalb
von 6 Monaten nach dem Bericht, gedeckelt auf 3 Personentage.
Schritt 3 — Gegenlesen lassen
Ein nicht gegengelesenes RoE ist ein unvollständiges RoE. Lassen Sie es vor der Unterschrift von zwei Augenpaaren gegenlesen:
- Ein Jurist — Haftungsklauseln, rechtlicher Rahmen, Dateneigentum.
- Ein Pentester-Kollege — technische Kohärenz, Realismus der Zeitfenster, Vollständigkeit des Geltungsbereichs.
Jede Gegenlesung bringt 5 bis 10 Korrekturen. Das ist normal. Ein beim ersten Wurf perfektes RoE ist ein RoE, das man nicht gegengelesen hat.
Schritt 4 — Unterschrift
Qualifizierte elektronische Signatur, wenn möglich (DocuSign, Notarius). Andernfalls handschriftliche Unterschrift + Scan. Niemals ein einfaches „ja, wir sind uns einig“ in einer E-Mail.
Sobald es unterschrieben ist, wird das RoE zum technischen Anhang Ihres Vertrags. Jede Änderung erfolgt über einen schriftlichen und unterzeichneten Nachtrag. Eine in einem Meeting getroffene Anpassung, festgehalten in einem Protokoll, hält stand — aber man sichert immer zusätzlich über einen Nachtrag ab.
Was gerade passiert ist
- Sie haben einen Kunden getroffen, der spontan ein gefährliches, halbseitiges RoE produziert hätte.
- Sie haben zwölf Fragen gestellt, mehrere davon unangenehm.
- Sie haben ein solides, drei Seiten langes RoE erstellt, das standhält.
- Sie haben noch keinen einzigen Befehl ausgeführt. Das ist normal. Ein Pentest beginnt auf Papier.
Nächste Lektion: Jetzt sind Sie dran. Sie verfassen ein vollständiges RoE für ein anderes, vorgegebenes Szenario, mit zu erkennenden Fallen.