Ein Orientierungsrahmen für CISOs, IT-Leiter und Sicherheitsverantwortliche
Der Pentest, der perfekt lief – und das Red Teaming, das alles erschütterte
Das Projekt galt intern als Vorzeigebeispiel.
Mehrere Pentests in Folge waren sauber durchgelaufen, die Berichte lasen sich gut. Die meisten Findings waren längst abgearbeitet, die Ampeln in den Management-Slidedecks leuchteten grün. Es gab ein gutes Gefühl: „Wir sind auf einem ordentlichen Niveau.“
Einige Monate später der nächste Schritt in der Security-Roadmap: ein Red Teaming. Der Auftrag: realistische Angriffssimulation, Fokus auf Domain Admin und Zugriff auf bestimmte geschäftskritische Systeme. Alle Beteiligten fühlten sich gut vorbereitet.
Ein paar Tage später liegt der erste Zwischenbericht auf dem Tisch. Ergebnis: Domain-Admin-Rechte erlangt, persistenter Zugriff aufgebaut, keine einzige Alarmierung, keine erkennbare Reaktion.
Keine Zero-Day-Exploits. Kein spektakulärer Remote-Code-Exploit. Stattdessen schwache Erkennung, blinde Flecken im Monitoring, Rollenunklarheiten im Incident Response und ein Satz veralteter Berechtigungen, die nie konsequent bereinigt wurden.
In diesem Moment wird schmerzhaft deutlich:
Erfolgreiche Pentests bedeuten nicht automatisch Red-Teaming-Bereitschaft.
Und genau an dieser Stelle beginnt die Frage nach dem Pentest-Reifegrad.
Warum Red Teaming ein Reifegrad-Thema ist – nicht ein Budget-Thema
Red Teaming klingt auf dem Papier oft wie „Pentest auf Steroiden“. Mehr Zeit, mehr Kreativität, mehr Szenarien, mehr Realismus. Wer nur aus Budgetperspektive denkt, könnte meinen: „Wenn wir uns schon Pentests leisten, können wir jetzt auch ein Red Teaming machen.“
Der Kernunterschied liegt allerdings nicht im Umfang, sondern im Ziel. Ein Pentest soll Schwachstellen finden und bewerten. Ein Red Teaming prüft, ob ein realistischer Angreifer seine Ziele erreichen kann, wie lange er unentdeckt bleibt und wie Verteidiger reagieren.
Damit verschiebt sich der Fokus: Weg vom einzelnen System, hin zum Zusammenspiel aus Angriffsfläche, Detection, Response und Organisation.
Fehlt die grundlegende Sicherheits-Hygiene, wirkt Red Teaming wie ein Flutlicht auf alle Defizite gleichzeitig. Das Ergebnis ist oft ein Gefühl von Überforderung. Findings stapeln sich, das SOC wird kritisch beäugt, Prozesse wirken plötzlich unzureichend. Statt Klarheit entsteht Chaos.
Der eigentliche Zweck eines Red Teamings ist ein anderer. Es soll Resilienz messbar machen. Also die Fähigkeit, einen Angriff überhaupt zu bemerken, sinnvoll einzuordnen und rechtzeitig zu unterbrechen.
Genau dafür braucht es Reifegrad. Nicht, um alles perfekt zu haben, sondern um die Ergebnisse aufnehmen und in Verbesserungen übersetzen zu können.
Was Pentest-Reifegrad bedeutet
Pentest-Reifegrad lässt sich pragmatisch definieren als die Fähigkeit einer Organisation, die Ergebnisse realistisch simulierter Angriffe sinnvoll auszuwerten. Es geht nicht nur darum, ob ein Alarm ausgelöst wird, sondern ob die Organisation versteht, was er bedeutet, wer handeln muss und wie sich daraus Maßnahmen ableiten lassen.
Mehrere Dimensionen spielen hinein. Typischerweise gehören dazu:
- Sicherheitsprozesse: Wie wiederholbar und definiert sind Abläufe, gerade bei Änderungen oder Störungen.
- Monitoring und Logging: Welche Daten werden gesammelt und wie werden sie ausgewertet.
- Incident Response: Wie schnell und koordiniert reagiert die Organisation auf Auffälligkeiten.
- Organisatorische Klarheit: Wer entscheidet, wer verantwortet, wer informiert.
- Kultur und Kommunikation: Welche Rolle Sicherheit im Alltag spielt und wie offen über Fehler gesprochen wird.
Ein bildhafter Vergleich hilft bei der Einordnung:
Der Pentest ist die TÜV-Prüfung. Er schaut, ob die sicherheitsrelevanten Teile des Fahrzeugs in Ordnung sind. Red Teaming ist der Crashtest. Hier wird getestet, was passiert, wenn wirklich etwas schiefgeht.
Wer den TÜV ignoriert, braucht über den Crashtest gar nicht nachzudenken. Wer jedoch nur den TÜV macht und nie testet, wie das Gesamtsystem reagiert, hat ein trügerisches Gefühl von Sicherheit.
Wo Unternehmen fälschlicherweise glauben, sie seien bereit
Viele Organisationen schätzen ihre Red-Teaming-Reife zu optimistisch ein. Einige typische Denkfehler tauchen immer wieder auf.
Der erste Irrtum: „Wir hatten schon viele Pentests, also ist alles getestet.“ Pentests liefern wichtige Einblicke in Schwachstellen, aber selten ein vollständiges Bild der Angriffswege. Sie folgen einem definierten Scope. Sie enden dort, wo der Auftrag endet, nicht dort, wo der Angreifer aufhören würde.
Der zweite Irrtum: „Wir haben ein SIEM, also erkennen wir Angriffe.“ Logging an sich bedeutet noch keine Detection. Wenn keine sinnvollen Use Cases modelliert sind, keine Korrelation aufgebaut wurde und niemand die Alerts im Kontext bewertet, sind Logdaten nur Datensammlung, kein Radar.
Der dritte Irrtum: „Unser SOC arbeitet im 24/7-Modus, also sind wir sicher.“ Auch ein rund um die Uhr besetztes SOC kann blind sein, wenn die Signale fehlen oder die Analysten in Alert-Flut untergehen. Überlastung, schlechte Triage-Prozesse und fehlende Feineinstellungen führen schnell zu Alarmmüdigkeit.
Der vierte Irrtum: „Wir haben keine Incidents, also sind wir gut geschützt.“ Häufig ist genau das Gegenteil der Fall. Keine Incidents kann bedeuten, dass schlicht nichts gesehen wird. In reifen Organisationen ist ein bestimmtes Grundrauschen an Meldungen und abgefangenen Versuchen normal.
Red Teaming macht diese Missverständnisse sichtbar. Es zeigt, was passiert, wenn ein Gegner nicht brav im Scope bleibt, sondern den Weg der geringsten Widerstände sucht.
Warum ein Red Team dort durchbricht, wo Pentests enden
Ein Pentestbericht listet drei kritische Schwachstellen auf. Alle werden sauber gestopft, Patches eingespielt, Konfigurationen gehärtet. Der nächste Scan zeigt: Alles im grünen Bereich.
Ein Jahr später startet ein Red-Team-Projekt. Statt sich auf die bereits getesteten Systeme zu konzentrieren, beginnt das Team mit OSINT. Es entdeckt in einer alten Ausschreibung Hinweise auf ein Drittanbieterportal, stößt auf einen unscheinbaren VPN-Endpunkt, der in keinem aktuellen Inventar mehr auftaucht, und findet über Social Media heraus, wie sich interne Rollen nennen.
Es folgt ein Social-Engineering-Szenario, das einen Mitarbeiter dazu bringt, einmalig Zugangsdaten auf einem gefälschten Portal einzugeben. Die Kombination aus gültigen Credentials, einem schlecht segmentierten Netzwerk und einem alten Dienst, der nie in einem Scope stand, reicht aus, um sich lateral zu bewegen. Nach einiger Zeit landet das Team auf Systemen, die nie Teil eines Pentests waren.
Der Unterschied liegt nicht in der technischen Brillanz, sondern in der Angriffslogik. Pentests beenden ihren Auftrag mit dem letzten Step des Scopes. Angreifer orientieren sich an Zielen und Möglichkeiten.
Reifegrad heißt, genau diese Logik in den eigenen Strukturen mitzudenken.
Die fünf zentralen Reifegrad-Dimensionen
Um einzuschätzen, ob eine Organisation bereit für ein Red Teaming ist, lohnt sich ein Blick auf fünf Kernbereiche.
Asset- und Angriffsflächen-Transparenz
Wer seine eigene Angriffsfläche nicht kennt, bekommt beim Red Teaming vor allem eines: Überraschungen. Die Frage lautet: Wissen Sie, was extern sichtbar ist, welche Systeme wirklich erreichbar sind, welche Subdomains existieren, welche Cloud-Dienste genutzt werden.
Eine aktuelle Inventarisierung ist die Basis. Idealerweise existieren Mechanismen, die neue Systeme automatisch sichtbar machen, etwa durch regelmäßige externe Discovery oder Attack-Surface-Management. Ein Klassiker sind vergessene Subdomains in Certificate-Transparency-Logs oder alte Portale, die noch online sind, obwohl niemand sie mehr verantwortet.
Ein gutes Zeichen für Reife ist, wenn die Lücken in der Transparenz kleiner sind als die dokumentierte Angriffsfläche.
Monitoring, Logging und Detection
Die zweite Dimension dreht sich darum, ob auffällige Aktivitäten überhaupt gesehen werden. Werden ungewöhnliche Anmeldeversuche erkannt. Gibt es Use Cases, die laterale Bewegung abbilden. Werden Cloud-Logins überwacht, und zwar nicht nur aus der eigenen Region.
Entscheidend ist nicht, möglichst viele Logs zu sammeln, sondern sinnvolle Muster zu erkennen. Reife Organisationen haben False Positives soweit im Griff, dass echte Alerts nicht untergehen. Sie wissen, welche Signale einen Analysten aufhorchen lassen müssen.
Incident Response und Reaktionsgeschwindigkeit
Erkennen ist die eine Hälfte, reagieren die andere. Ein Incident-Response-Plan auf Papier bringt wenig, wenn ihn niemand geübt hat.
Eine zentrale Frage lautet: Was passiert in den ersten 15 Minuten nach einem kritischen Alert. Weiß das SOC, wen es anrufen darf. Gibt es klar benannte Rollen? Dürfen Systeme isoliert werden, ohne dass monatelang diskutiert wird?
Reife zeigt sich daran, dass das SOC nicht nur erkennt, sondern auch handeln kann, ohne jedes Mal das Organigramm rauf und runter zu telefonieren.
Prozessreife und organisatorische Klarheit
Technik allein reicht nicht. Wenn Changes nicht dokumentiert werden, Shadow IT unentdeckt bleibt und Freigabeprozesse nur auf dem Papier existieren, sind Red-Teaming-Ergebnisse schwer zu verarbeiten.
Stabile Prozesse sorgen dafür, dass die Organisation realistische Angriffsszenarien verkraftet, ohne in operative Panik zu fallen. Dazu gehören nachvollziehbare Change- und Release-Prozesse, eine gelebte Verantwortung für Systeme und ein Mindestmaß an Governance, das auch in Projektdruckzeiten Bestand hat.
Sicherheitskultur und Verhalten
Die fünfte Dimension ist weicher, aber entscheidend. Können Mitarbeiter Zweifel äußern, ohne Spott oder Sanktionen zu fürchten. Melden Führungskräfte selbst verdächtige E-Mails oder ungewöhnliche Anrufe. Können Teams Tests stoppen oder hinterfragen, wenn sie das Gefühl haben, dass etwas nicht stimmt.
Dort, wo Security als gemeinsame Verantwortung verstanden wird, fällt es leichter, Red-Teaming-Erkenntnisse anzunehmen und in Veränderungen zu übersetzen. Wenn Sicherheit ausschließlich als IT-Aufgabe gilt, entsteht schnell eine „Wir gegen die“-Haltung.
Ein Reifegradmodell ohne Buzzword-Bingo
Um das Ganze greifbarer zu machen, hilft ein einfaches Modell. Es muss nicht wissenschaftlich perfekt sein, sondern vor allem Orientierung geben.
Auf der ersten Stufe befindet sich die reaktive Organisation. Sicherheitsmaßnahmen entstehen situativ, oft als Reaktion auf Vorfälle oder Audits. Es gibt wenige definierte Prozesse, Monitoring ist rudimentär, Pentests finden selten oder nur aus Compliance-Gründen statt.
Die zweite Stufe ist strukturiert, aber fragmentiert. Pentests werden regelmäßig durchgeführt, es gibt Policies und erste Prozesse. Ergebnisse werden aber häufig isoliert betrachtet. Mal reagiert die IT, mal ein Projektteam, manchmal niemand.
Stufe drei beschreibt ein etabliertes Grundniveau. Monitoring läuft, Incident Response existiert nicht nur auf dem Papier, sondern wurde wenigstens teilweise geübt. Pentests werden bewusst eingesetzt, um Risiken zu bewerten, nicht nur, um Häkchen zu setzen.
Auf Stufe vier arbeitet die Organisation proaktiv und lernfähig. Angriffsfläche wird aktiv reduziert, etwa durch systematische Bereinigung der externen Exposition. Das SOC nutzt definierte Use Cases, Lessons Learned aus Vorfällen werden wirklich in Prozesse eingebaut.
Stufe fünf schließlich ist Red-Teaming-ready. Angriffe werden erkannt, verstanden und in einem sinnvollen Zeitfenster gestoppt. Nicht jeder Versuch wird verhindert, aber die Organisation bleibt handlungsfähig und gewinnt aus jeder Übung konkrete Verbesserungen.
Was Red Teaming nicht ist
Ein kurzer Realitätsabgleich hilft, Erwartungen zu klären. Red Teaming ist kein reiner Technologietest, der zeigt, ob eine bestimmte Lösung „gut genug“ ist.
Es ist auch kein Beweis, wie schlecht oder gut eine IT-Abteilung arbeitet. Wer Red Teaming als Strafaktion nutzt, zerstört Vertrauen und verhindert offene Diskussionen.
Das Format ist ungeeignet, um grundlegende Schwachstellen zu finden, die auch ein standardisierter Pentest erkannt hätte. Wer noch mit ungepatchten öffentlich erreichbaren Servern kämpft, sollte nicht mit Red Teaming beginnen, sondern mit Basis-Hygiene.
Vor allem ist es kein Werkzeug für unreife Organisationen. Ohne Mindestniveau in den genannten Dimensionen erzeugt Red Teaming mehr Frustration als Fortschritt.
Das Unternehmen, das „fast“ bereit war
Ein mittelgroßes Unternehmen hatte investiert. Ein SOC war aufgebaut, ein SIEM eingeführt, zentrale Systeme wurden überwacht. Pentests liefen regelmäßig und zeigten ein solides Niveau.
Auf dieser Basis entschied sich das Management für ein Red Teaming. Die Vorbereitung wirkte gut. Es gab Eskalationswege, definierte Ansprechpartner und ein grobes Zielbild.
Im Verlauf der Übung gelang es dem Red Team, einen alten Service-Account mit weitreichenden Rechten zu finden. Der Account war formal einem Projekt zugeordnet, das seit Jahren abgeschlossen war. Niemand hatte die Berechtigung bereinigt.
Das Team nutzte diesen Zugang für laterale Bewegung und erreichte in mehreren Schritten Systeme, die stark geschützt galten. Das SIEM sah ungewöhnliche Aktivitäten, es gab sogar einzelne Alerts. Doch in keinem Playbook war definiert, was bei solchen Mustern passieren sollte.
Die Technik war da, das Monitoring ebenfalls, aber der Prozess für Berechtigungsverwaltung und die Verknüpfung zur Reaktion waren schwach.
Die wichtigste Erkenntnis dieser Übung: Das Problem lag nicht in fehlenden Tools, sondern in Lücken bei Prozessen und Verantwortlichkeiten.
Wie Organisationen sich auf Red Teaming vorbereiten können
Der Weg zur Red-Teaming-Reife beginnt nicht bei den Angreifern, sondern im eigenen Haus.
Ein sinnvoller Startpunkt ist die ehrliche Bestandsaufnahme entlang der genannten Reifegrad-Dimensionen. Wo fehlt Transparenz über Assets. Welche Logs werden zwar gesammelt, aber nie systematisch ausgewertet. Wo existieren Incident-Response-Pläne nur als Dokumente im Wiki, statt als gelebte Praxis.
Danach lohnt es sich, Monitoring und Detection gezielt zu priorisieren. Statt „alles zu loggen“ ist die Frage wichtiger, welche Szenarien wirklich im Fokus stehen sollen. Verdächtige Anmeldeversuche, ungewöhnliche Bewegungen zwischen Zonen, Auffälligkeiten in Cloud-Umgebungen und privilegierter Zugriff sind gute Startpunkte.
Incident-Response-Grundlagen sollten geübt werden, bevor ein Red Team kommt. Tabletop-Übungen mit realistischen Szenarien helfen, Rollen zu klären, Kommunikationswege zu testen und Entscheidungszeiten zu verkürzen.
Parallel dazu empfiehlt es sich, die Angriffsfläche bewusst zu reduzieren. Shadow IT, Cloud-Wildwuchs und unkontrollierte externe Exposition sind häufige Einfallstore. Wer hier vorher aufräumt, stellt sicher, dass ein Red Team sich auf die wirklich relevanten Pfade konzentriert.
Schließlich braucht es gutes Erwartungsmanagement. Ein Red Teaming liefert keine „Note“, sondern einen Spiegel. Es ist normal, dass eine erste Übung schmerzhafte Erkenntnisse bringt. Entscheidend ist, ob die Organisation daraus lernt oder in Abwehrhaltung geht.
An dieser Stelle kann ein Dienstleister wie die pen.sec AG hilfreich sein, wenn er nicht nur Angriffe simuliert, sondern auch beim Aufbau eines passenden Reifegradmodells und bei der Auswertung unterstützt. Entscheidend ist, dass der Fokus auf Lernkurve und Strukturverbesserung liegt.
Wenn Reifegrad auf Red Teaming trifft
Ein Unternehmen mit gutem Pentest-Niveau, aber schwachem Monitoring steht anders in einem Red Teaming da als eines, das zwar noch technische Baustellen hat, dafür aber schnell reagiert.
Ein praktisches Beispiel: In einem Unternehmen wurde zunächst gezielt in SOC-Erweiterung und Prozessaufbau investiert. Alert-Use-Cases wurden definiert, Playbooks geschrieben und in mehreren Übungen getestet. Gleichzeitig begann das Team, externe Angriffsfläche zu reduzieren und Verantwortlichkeiten klarer zuzuordnen.
Erst danach startete das erste Red Teaming. Die Übung war anspruchsvoll. Das Team fand Einfallstore, nutzte Kombinationen aus technischen und organisatorischen Schwächen und erreichte mehrere Ziele.
Der Unterschied zum Eingangsszenario: Mehrere Aktivitäten wurden erkannt. Es gab teilweise verzögerte, aber grundsätzlich sinnvolle Reaktionen. Nach Abschluss der Übung lagen nicht nur technische Findings vor, sondern konkrete Hinweise darauf, welche Detection-Regeln zu schärfen waren, wo Rollen noch unklar waren und welche Prozesse in Stresssituationen versagen.
In der zweiten Red-Team-Runde, einige Zeit später, verkürzten sich die Reaktionszeiten deutlich. Mehrere Angriffsversuche wurden frühzeitig zurückgedrängt. Die Organisation hatte gelernt, und zwar nicht in der Theorie, sondern im Ernstfalltraining.
Fazit: Red Teaming ist ein Meilenstein, kein Startpunkt
Red Teaming ist kein Statussymbol. Es ist ein Instrument, das seinen vollen Wert erst entfaltet, wenn die Organisation einen bestimmten Reifegrad erreicht hat.
Pentests bleiben zentral, weil sie technische Schwachstellen sichtbar machen. Sie sind die Grundlage. Doch wer sich von grünen Ampeln in Reports in Sicherheit wiegen lässt, ohne sich um Detection, Response und Prozesse zu kümmern, riskiert böse Überraschungen in realistischen Angriffssimulationen.
Reifegrad ist gestaltbar. Organisationen können Schritt für Schritt dorthin gelangen, an dem ein Red Teaming nicht als Katastrophe, sondern als Chance erlebt wird.
Wer den Zeitpunkt klug wählt, erhält aus einem Red Teaming Erkenntnisse, die weit über einzelne Schwachstellen hinausgehen. Dann wird sichtbar, wie gut das Zusammenspiel aus Technik, Prozessen und Menschen wirklich funktioniert. Und genau das entscheidet am Ende darüber, ob ein Angriff nur ein Test bleibt oder zur Krise wird.