Was vorher fertig sein muss
Eine Strategie, ein Plan, eine Architektur oder eine Loesung liegt in pruefbarer Form vor, sodass die Red Team konkret angreifen kann.
Es liegen erste Risiko-Hypothesen vor, sodass Red Team an realen Schwachpunkten ansetzen kann.
Was vor Start vorliegen muss
Vollstaendige Unterlagen zur Vorlage (Strategie, Architektur, Plan); Whiteboard oder Miro mit Angriffs-Tabelle (Angriffsvektor, Wirkung, Wahrscheinlichkeit, Mitigation); ggf. STRIDE/PASTA-Templates fuer Security.
Eine Red Team (3-5 Personen) idealerweise extern zum Originalteam; ein Originalteam-Vertreter fuer Verstaendnisfragen (nicht zur Verteidigung); ein Moderator; ein Scribe.
Vorlage 2-3 Tage vor Workshop bereitstellen; Kontext und Annahmen klaeren; bekannte Angriffsmuster im Bereich (Security: OWASP; Business: Wettbewerber-Spielzuege); Zeitlimit fuer Red-Team-Vorbereitung.
1-2 Tage (Vorbereitung 1 Tag, Workshop 4-8 h)
Red Team arbeitet vor Workshop autonom an Angriffsstrategien. Workshop hat klare Regeln: Originalteam nicht verteidigt, sondern hoert zu und notiert. Erst nach kompletter Praesentation Q-and-A.
Die eine Frage, die diese Methode beantwortet
Welche Angriffsvektoren, Schwachstellen oder Eintrittspfade ueberwinden die Vorlage, und welche dieser Vektoren sind hinreichend wahrscheinlich, um eine Mitigation zu rechtfertigen?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Vorbereitung der Red Team | 4-8 h | Red Team studiert die Vorlage. Generiert Angriffsbaum oder Liste. Pro Angriff: Vektor, benoetigte Faehigkeiten, Wirkung, Wahrscheinlichkeit, Vorhandensein bestehender Mitigation. | Red Team braucht Zeit und Distanz. Ohne Vorbereitung wird Red Teaming zur Diskussionsrunde. Externe Personen sind oft kreativer als interne. |
2Phase 2: Kontext und Regeln | 30 min | Moderator stellt Vorlage kurz vor. Red Team und Originalteam stellen Verstaendnisfragen. Regeln klar: Originalteam hoert zu, antwortet auf Fakten, verteidigt nicht. | Verteidigungsreflex ist der haeufigste Methodenfehler. Klare Regel: Diskussion erst in Phase 4. |
3Phase 3: Angriffspraesentation | 2-3 h | Red Team praesentiert Angriffe systematisch. Pro Angriff: Vektor, Szenario, Wirkung. Originalteam fragt nur fuer Verstaendnis, nicht zur Entkraeftung. | Wenn Originalteam unterbricht und verteidigt, Moderator unterbricht zurueck. Praesentation muss vollstaendig sein, bevor Bewertung kommt. |
4Phase 4: Bewertung und Priorisierung | 90 min | Pro Angriff Bewertung (Wirkung, Wahrscheinlichkeit, Mitigation-Aufwand). Originalteam ergaenzt Kontext, der Wahrscheinlichkeit aendert. Top-Angriffe als Risiken auf Risiko-Register. | Wahrscheinlichkeit ist subjektiv. Konsens nicht erforderlich, aber Begruendung muss dokumentiert sein. |
5Phase 5: Mitigationen und Followups | 60-90 min | Pro Top-Angriff Mitigation skizzieren (Praevention, Detection, Reaktion). Owner und Frist. Anpassungen an Vorlage protokollieren. | Mitigation muss konkret sein. „Mehr Monitoring“ ohne Detail ist keine Mitigation. Owner pflicht. |
Was am Ende rauskommt
Red-Team-Report mit Vorlagen-Beschreibung, Angriffsliste (Vektor, Szenario, Wirkung, Wahrscheinlichkeit, Mitigation-Aufwand), priorisierten Risiken und Mitigationen mit Owner und Frist. Ergaenzt um Methodik-Notizen und offene Fragen.
Pro Red-Team-Sitzung eigener Eintrag mit Datum und Vorlagen-Version. Mitigationen werden separat ueber Zeit verfolgt. Bei groesseren Aenderungen der Vorlage neuer Red-Team-Lauf.
Kompakte Arbeitsvorlage für Red Teaming mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Red Teaming Arbeitsvorlage
## Ziel
Unabhängige Challenge einer Strategie, Lösung oder Annahme aus adversarialer Perspektive.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Challenge Findings:
- Risk Register:
- Mitigation Plan:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Red-Team-Report - Workspot Booking API v2 Architektur, Mai 2026
**Red Team**: 3 externe Architekten + 1 interner Security Champion. Vorbereitung 6 h.
**Top-Angriffsvektoren**
### A1: Partner-Lastspike via geleakter API-Schluessel
- Szenario: Partner-API-Schluessel landen in oeffentlichem GitHub-Repo. Bot-Traffic generiert 50.000 Anfragen/min.
- Wirkung: Booking API ueberlastet, p95 reisst, Mehrkosten ca. 8.000 EUR/Tag, Reputationsschaden.
- Wahrscheinlichkeit: Hoch (mehrere Partner sind Solo-Selbststaendige ohne strenge Secret-Hygiene).
- Mitigation: Pro-Partner-Rate-Limit (Owner @ben, bis 30.06.), Token-Rotation-API (Owner @anna, bis 15.07.), Public-Repo-Scanner fuer Secrets (Owner @marcus, bis 30.07.).
### A2: Inventory-Race bei Multi-Region-Buchung
- Szenario: zwei Buchungen fuer denselben Workspace in unterschiedlichen Regionen werden gleichzeitig bestaetigt.
- Wirkung: Doppelbuchung, Kundenstreit, manueller Rollback.
- Wahrscheinlichkeit: Mittel (entsteht erst bei aktiv-aktiv Multi-Region).
- Mitigation: Sticky Region pro Workspace-ID statt Mandant (Owner @lisa, ADR-014 anpassen).
### A3: Notification-Worker als Single Point of Failure
- Szenario: Kafka-Konsumer haengt, Notifications stauen sich, Bestaetigungs-Emails verspaetet.
- Wirkung: Aktivierungsrate sinkt, Support-Volumen steigt.
- Wahrscheinlichkeit: Mittel.
- Mitigation: Konsumer in 2 Replicas + Alert bei Lag >100 (Owner @marcus, bis 22.06.).
**Weitere Angriffe (Auszug, ohne sofortige Mitigation)**: Cache-Invalidation-Bug, Compliance-Audit-Findings bei eu-west-Region, Auth-Service-Downtime.
**Folge**: Top-3 ins Risiko-Register Booking-API, ADR-014 wird angepasst, Reviews in 30 Tagen.Symptome erkennen, gegensteuern
Praesentation wird zur Diskussion, Red Team kommt nicht durch ihre Angriffsliste.
Moderator unterbricht. Klare Regel: Verstaendnisfragen ja, Verteidigung nein. Bewertung erst in Phase 4.
Angriffe sind generisch, treffen die Vorlage nicht.
Vorbereitungszeit verbindlich. Red Team muss Vorlage 2-3 Tage vorher haben. Bei kurzem Zeitfenster verschieben.
Red Team und Originalteam teilen Annahmen, blinde Flecken bleiben.
Externe Personen ins Red Team holen, idealerweise mit anderer Perspektive. Wenn nicht moeglich, mindestens andere Abteilung.
Lange Angriffsliste, niemand uebernimmt Mitigation, Liste verstaubt.
Top-Angriffe pflicht mit Mitigation, Owner, Frist. Andere Angriffe als Watchlist mit naechstem Review-Datum.
Red Team wird benutzt, um interne Konflikte auszutragen, Angriffe sind versteckte Karriere-Spielzuege.
Moderator unabhaengig. Angriffe auf Vorlage bezogen, nicht auf Personen. Bei Personifizierung Moderator unterbricht.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.