Red Teaming vs. Pentesting: die Unterschiede und was du brauchst

Red Teaming und Penetrationstests setzen deine Verteidigung unter Druck, beantworten aber unterschiedliche Sicherheitsfragen. Ein Pentest fragt in der Regel, ob definierte Systeme Schwachstellen enthalten, die sich ausnutzen lassen. Eine Red-Team-Übung fragt, ob ein realistischer Angreifer ein vereinbartes Ziel erreicht, ohne gestoppt zu werden. Wer den Unterschied zwischen Red Teaming und Pentesting kennt, wählt Scope, Budget und Ergebnis passender – besonders dann, wenn vernetzte Produkte die Angriffsfläche um Firmware, Hardware-Schnittstellen, Zulieferkomponenten und Sicherheitsanforderungen erweitern.

Was ist ein Penetrationstest?

Ein Penetrationstest ist eine autorisierte Sicherheitsprüfung, bei der Testerinnen und Tester versuchen, Schwachstellen innerhalb eines vereinbarten Scopes auszunutzen. Das NIST beschreibt ihn als Test, der reale Angriffe nachahmt, um Wege an Sicherheitsfunktionen vorbei zu finden – oft durch die Kombination mehrerer Schwachstellen für weitergehenden Zugriff. Der Auftrag ist üblicherweise durch definierte Ziele, Zeit, Techniken und Regeln begrenzt.

Was ein Penetrationstest belegen soll

Ein Pentest ist meist schwachstellenorientiert. Du kannst eine Webanwendung, eine API, ein Netzsegment, eine Cloud-Umgebung, ein Gerät, ein Firmware-Image, eine Funkschnittstelle oder ein Hardware-Ziel prüfen lassen – mit der Frage, welche Schwächen sich tatsächlich ausnutzen lassen. Es geht um praktische Validierung, nicht um einen weiteren automatisierten Schwachstellen-Scan.

Ein guter Test führt von der Erkennung über die kontrollierte Ausnutzung bis zur Einordnung der geschäftlichen oder produktbezogenen Auswirkung. Der Pentesting-Ansatz von ONEKEY umfasst Scoping, Reconnaissance und Threat Modeling, Schwachstellenbewertung, Exploitation und Validierung sowie Reporting und Empfehlungen zur Behebung. Bei eingebetteten Systemen kann der Scope Firmware, Hardware-Schnittstellen, Netzwerkinteraktionen und Softwarekomponenten einschließen.

Was du aus einem Pentest mitnimmst

Das wichtigste Ergebnis ist eine Reihe validierter Befunde, die sich auf die Systeme im Scope beziehen. Ein guter Bericht erklärt die Schwachstelle, den Nachweis, die wahrscheinliche Auswirkung, die Bedingungen für die Ausnutzung, den Schweregrad und die empfohlene Behebung. Dein Engineering- oder IT-Team sollte daraus konkrete Fixes ableiten können.

Was ist Red Teaming?

Red Teaming ist eine breitere Angreifersimulation, die sich an Zielen statt an einer Liste zu testender Systeme orientiert. Das NIST definiert ein Red Team als autorisierte Gruppe, die die Angriffs- oder Ausnutzungsfähigkeiten eines potenziellen Gegners nachbildet, um die Auswirkung erfolgreicher Angriffe zu zeigen und die Verteidigung im laufenden Betrieb zu testen. Eine ausgereifte Red-Team-Übung kann Technik, Menschen, Prozesse, Erkennung und Reaktion einbeziehen.

Was eine Red-Team-Übung belegen soll

Das Red Team startet mit einem Ziel: ein kritisches System erreichen, auf geschützte Informationen zugreifen oder einen Weg zu einer sensiblen Funktion aufzeigen. Die Testenden verhalten sich dann eher wie echte Bedrohungsakteure und wählen Taktiken und Wege, die sie innerhalb der vereinbarten Regeln ans Ziel bringen. Je nach Modell weiß das verteidigende Blue Team nicht, dass die Übung läuft.

Threat Intelligence macht das Szenario realistischer. Das TIBER-EU-Rahmenwerk der Europäischen Zentralbank nutzt beispielsweise zugeschnittene Bedrohungsinformationen sowie Taktiken, Techniken und Vorgehensweisen von Angreifern, um Attacken auf kritische Funktionen, Menschen, Prozesse und Technologien zu simulieren. Im Mittelpunkt steht die Frage, wie Prävention, Erkennung und Reaktion gegen einen glaubwürdigen Angriffspfad bestehen.

Was du aus Red Teaming mitnimmst

Ein Red-Team-Bericht erzählt eine Geschichte, die eine Schwachstellenliste nicht liefern kann. Er beschreibt den Angriffspfad, wo Kontrollen versagt oder gegriffen haben, was die Verteidigung erkannt hat, wie sich der Angreifer bewegt hat und welches Ziel erreichbar war. Die Befunde können technische Schwachstellen, schwache Prozesse, Identitätsprobleme, Erkennungslücken oder Kombinationen kleinerer Schwächen umfassen.

Red Teaming vs. Penetrationstest: die zentralen Unterschiede

Am einfachsten verstehst du Red Teaming und Penetrationstests über die Frage, die der jeweilige Auftrag beantworten soll. Pentesting fragt: „Was lässt sich in diesem definierten Scope ausnutzen?“ Red Teaming fragt: „Kann ein Angreifer dieses Ziel erreichen – und wie gut erkennen und stoppen wir ihn?“

1. Zielsetzung

Pentesting ist in der Regel darauf ausgerichtet, Schwachstellen zu finden und zu validieren. Red Teaming zielt darauf, ein vereinbartes Ziel zu erreichen und sich dabei wie ein realistischer Angreifer zu verhalten. Dieser Unterschied prägt fast jede weitere Entscheidung – vom Scope bis zum Reporting.

2. Scope

Ein Pentest hat normalerweise klare technische Grenzen, damit die vereinbarten Assets effizient abgedeckt werden. Red Teams dürfen sich, sofern die Regeln es zulassen, über mehrere Systeme, Identitäten, Nutzerkonten oder physische Wege bewegen. Die Entscheidung zwischen Red Teaming und Pentesting hängt deshalb auch davon ab, ob du Tiefe im Ziel oder Breite im Angriffspfad brauchst.

3. Realismus des Angriffs

Pentesterinnen und Pentester nutzen echte Angriffstechniken, suchen aber meist so viele relevante Schwachstellen, wie der Scope zulässt. Red Teams stellen realistisches Angreiferverhalten in den Vordergrund und verzichten auf auffällige Techniken, wenn Unauffälligkeit Teil des Ziels ist. Ein Red Team kann Schwachstellen bewusst unangetastet lassen, weil das Finden jeder Lücke nicht sein Ziel ist.

4. Kenntnisstand der Verteidigung

Deine Administration und Entwicklung wissen normalerweise, dass ein Penetrationstest ansteht, auch wenn die genauen Testaktivitäten nicht angekündigt werden. Eine Red-Team-Übung begrenzt dieses Vorwissen oft, damit du beobachten kannst, ob Monitoring und Reaktionsprozesse den Angriff im Normalbetrieb erkennen. Ein Control- oder White Team steuert dabei weiterhin Sicherheit, Autorisierung und Eskalation.

5. Abdeckung

Ein Pentest deckt ein definiertes technisches Ziel meist gründlicher ab, weil dieser Scope systematisch untersucht wird. Red Teaming deckt eine breitere Angriffskette ab, prüft einzelne Assets dafür aber weniger vollständig. Eine erfolgreiche Red-Team-Übung als Beleg dafür zu werten, dass jedes System schwachstellenfrei ist, wäre deshalb ein Fehler.

6. Ergebnisse

Pentest-Berichte ordnen Befunde meist nach Schwachstelle, Schweregrad, Nachweis und Behebung. Red-Team-Berichte betonen den Ablauf der Kompromittierung, Beobachtungen zur Verteidigung, die Angriffsziele und Lehren für Erkennung und Reaktion. Beide sollten umsetzbare Maßnahmen liefern, unterstützen aber unterschiedliche Entscheidungen.

7. Erfolgskriterien

Ein Pentest ist erfolgreich, wenn er dir innerhalb des vereinbarten Scopes brauchbare Abdeckung und validierte Befunde liefert. Eine Red-Team-Übung ist erfolgreich, wenn sie realistische Erkenntnisse über die Leistungsfähigkeit deiner Verteidigung erzeugt – selbst wenn das Red Team das finale Ziel nie erreicht. Ein abgewehrter Angriff kann wertvoll sein, weil er zeigt, welche Kontrollen gegriffen haben. 09-26 - Red Teaming vs. Pentest…

Was sich bei Embedded-, IoT- und OT-Systemen ändert

Der übliche Vergleich zwischen Pentesting und Red Teaming stammt weitgehend aus der Unternehmens-IT – vernetzte Produkte bringen andere Rahmenbedingungen mit. Du musst Firmware womöglich ohne Quellcode analysieren, Hardware-Schnittstellen prüfen, Komponenten von Drittanbietern identifizieren, Update-Mechanismen testen und Aktionen vermeiden, die Betriebssicherheit oder Produktion beeinträchtigen. Produkt-Cybersicherheit braucht deshalb Methoden, die auf Geräte zugeschnitten sind und nicht nur auf Unternehmensinfrastruktur.

Firmware und Hardware vergrößern die Angriffsfläche

Ein eingebettetes Ziel kann UART, JTAG, Debug-Schnittstellen, Bootloader, lokalen Speicher, Funkprotokolle, Webdienste, APIs, Update-Pakete und Cloud-Anbindungen offenlegen. Ein Pentest untersucht ausgewählte Teile dieser Fläche in der Tiefe, während ein Red Team prüft, ob mehrere Schwächen zu einem realistischen Kompromittierungspfad zusammenkommen. Physischer Hardwarezugriff kann außerdem die Annahmen hinter Authentifizierung, Verschlüsselung oder Secure Boot verändern.

OT bringt betriebliche Grenzen mit, die aggressives Testen an laufenden Anlagen einschränken. Ein technisch gültiger Exploit kann gegen eine Produktionssteuerung, ein Medizinsystem oder einen industriellen Prozess trotzdem unsicher sein. Deine Rules of Engagement müssen Betriebssicherheit, Verfügbarkeit, Wiederanlauf und physischen Zugang klären, bevor der Test beginnt.

Produktsicherheit muss zwischen manuellen Tests weiterlaufen

Manuelle Tests liefern fachliche Tiefe, doch zwischen zwei großen Prüfungen ändert sich die Firmware oft mehrfach. Neue CVEs können außerdem nach der Auslieferung auftauchen, selbst wenn sich die Firmware gar nicht verändert hat. Red Team Software ergänzt wiederholbare Analysen über alle Builds hinweg, sodass sich Spezialistinnen und Spezialisten auf Geschäftslogik, komplexe Exploit-Ketten und produktspezifische Angriffspfade konzentrieren können.

Damit wird automatisierte Analyse nicht zum Red Team im klassischen Sinn. Sie schließt eine Abdeckungslücke, indem sie Firmware fortlaufend auf Komponenten, bekannte Schwachstellen, Schwächen auf Binärebene und relevantes Risiko prüft, während sich Releases ändern. Menschliche Angriffssimulation und automatisierte Produktanalyse lösen unterschiedliche Teile desselben Sicherheitsproblems.

Kosten und Zeitaufwand im Vergleich

Es gibt keinen allgemeingültigen Preis und keine feste Dauer, weil Scope, Komplexität, Sicherheitsanforderungen und Erfahrung der Testenden eine Rolle spielen. Ein fokussierter Pentest lässt sich leichter eingrenzen, während ein Red Team mehr Planung, Reconnaissance, Abstimmung und Durchführungszeit braucht. Der Budgetunterschied zwischen Red Teaming und Penetrationstest sollte sich an deiner Fragestellung orientieren, nicht am Label im Angebot.

Warum Pentests leichter zu budgetieren sind

Ein Pentest lässt sich anhand einer definierten Zahl von Anwendungen, Geräten, Schnittstellen oder Netzbereichen kalkulieren. Das Testfenster reicht je nach Tiefe und Komplexität von wenigen Tagen bis zu mehreren Wochen, gefolgt von Reporting und häufig einem Retest. Hardware- und Embedded-Tests erhöhen den Aufwand, weil physische Geräte, Firmware-Extraktion, Reverse Engineering oder Spezialequipment nötig sein können.

Warum Red Teams länger dauern

Red Teams brauchen Zeit, um Szenarien zu planen, Reconnaissance zu betreiben, Zugang aufzubauen, sich durch die Umgebung zu bewegen und der Verteidigung eine realistische Chance zur Reaktion zu geben. TIBER-EU weist darauf hin, dass die Dauer im Verhältnis zum Scope stehen sollte, und nennt für sein formales, Threat-Intelligence-geführtes Modell rund 10 bis 12 Wochen als angemessenen Testzeitraum. Deine eigene Übung kann kürzer oder länger ausfallen, denn TIBER-EU ist ein spezifisches Rahmenwerk und kein allgemeiner Zeitplan.

Red Teaming ist zudem meist teurer, weil es über einen längeren Zeitraum Spezialistenzeit bindet und mehr Abstimmung verlangt. Die Kosten steigen weiter, wenn Threat Intelligence, Social Engineering, physische Tests, eigene Werkzeuge oder komplexe eingebettete Ziele dazukommen. Dein Budget sollte den gewünschten Realitätsgrad, die nötige Expertise und den Koordinationsaufwand abbilden.

Purple Teaming: wo beide Ansätze zusammenkommen

Purple Teaming ist weder ein günstigeres Red Team noch ein kollaborativerer Pentest. Es ist ein Arbeitsmodell, in dem offensive und defensive Fachleute Informationen teilen, damit beide Seiten Kontrollen, Erkennung und Reaktion verbessern. Im Vordergrund steht das Lernen und die Stärkung der Verteidigung, nicht die Geheimhaltung des Angreifers.

Wie Purple Teaming funktioniert

Das Red Team zeigt dem Blue Team, welche Technik es genutzt hat, während die Verteidigung prüft, ob Logs, Alerts und Kontrollen wie erwartet reagiert haben. Die Teams können einen Angriff wiederholen, eine Erkennung nachschärfen, eine Konfiguration ändern und erneut testen, solange die technischen Details noch frisch sind. Diese kurze Feedbackschleife hilft besonders, wenn du gezielt einzelne Verteidigungsfähigkeiten verbessern willst.

TIBER-EU beschreibt Purple Teaming als gemeinsame Aktivität von Red und Blue Team. Das aktuelle Rahmenwerk sieht eine Purple-Teaming-Übung in der Abschlussphase vor, während begrenztes Purple Teaming während des aktiven Tests besonderen Fällen vorbehalten bleibt. So steigt der Lerneffekt, ohne dem eigentlichen Red-Team-Test seinen gegnerischen Charakter zu nehmen.

Wo Produktteams profitieren

Teams für vernetzte Produkte können dasselbe Prinzip auf Firmware-Befunde anwenden. Sicherheitsforschende zeigen einen Exploit oder Angriffspfad, während Entwicklung und PSIRT die betroffene Komponente nachverfolgen, die Behebung validieren und Monitoring oder Entwicklungskontrollen anpassen. So entsteht eine Brücke zwischen einem einmaligen Test und dem laufenden Betrieb der Produktsicherheit.

Automatisiertes Schwachstellenmanagement hält Befunde, Bewertungen, Behebungsstatus und Produktversionen auch nach dem Ende der manuellen Übung zusammen. Dein nächster Test startet dann mit besserem Kontext, statt dasselbe Schwachstellenbild neu aufzubauen.

Was braucht dein Unternehmen? Eine Entscheidungshilfe

Die richtige Wahl hängt davon ab, welche Entscheidung der Auftrag stützen soll. Orientiere dich an eurer aktuellen Sicherheitsreife, den Zielsystemen, regulatorischen Anforderungen, dem Produktrisiko und daran, ob du Schwachstellenabdeckung oder einen realistischen Test der Verteidigung brauchst. Viele erfahrene Organisationen nutzen beides – an unterschiedlichen Punkten im Sicherheitszyklus.

Penetrationstest, wenn du gezielte Sicherheit brauchst

Ein Pentest ist meist der bessere Einstieg, wenn du ein definiertes System oder Produkt hast und wissen willst, was sich ausnutzen lässt. Sinnvoll ist er auch vor einem Release, bei einer größeren Architekturänderung oder wenn du prüfen willst, ob eine Behebung bekannte Angriffswege geschlossen hat. Hersteller vernetzter Produkte sollten darauf achten, dass Firmware und Hardware im Scope liegen, wo diese Ebenen die Sicherheit beeinflussen.

Red Teaming, wenn du Resilienz testen willst

Red Teaming wird dann interessant, wenn grundlegendes Schwachstellenmanagement und Schutzmaßnahmen bereits etabliert sind. Getestet wird, ob ein fähiger Angreifer Schwächen verketten, Kontrollen umgehen und ein relevantes Ziel erreichen kann, während deine Verteidigung im Normalbetrieb arbeitet. Besonders wertvoll ist das, wenn die Geschäftsführung Belege zu Erkennung und Reaktion sehen will statt einer weiteren Schwachstellenliste.

Beides, wenn das Risiko es rechtfertigt

Ein praxistaugliches Programm nutzt Pentesting für gezielte Absicherung und Red Teaming für den breiteren Resilienztest. Automatisierte Analyse hält die Abdeckung zwischen diesen punktuellen Prüfungen aufrecht. Dieses gestufte Modell reserviert Expertenzeit für die Arbeit, die menschliche Einschätzung braucht.

Nutze diese Checkliste für deine Entscheidung:

• Wähle einen Pentest, wenn deine Hauptfrage lautet: „Welche ausnutzbaren Schwächen enthält dieses Produkt oder System?“
• Wähle eine Red-Team-Übung, wenn deine Hauptfrage lautet: „Kann ein realistischer Angreifer ein kritisches Ziel erreichen, ohne gestoppt zu werden?“
• Wähle Purple Teaming, wenn du vor allem Erkennung und Reaktion durch direkte Zusammenarbeit verbessern willst.
• Kombiniere die Methoden, wenn du risikoreiche vernetzte Produkte, kritische Infrastruktur oder komplexe Umgebungen verantwortest, in denen ein einzelner Testansatz wichtige Lücken lässt.
• Prüfe regulatorische und kundenseitige Anforderungen separat, denn eine Red-Team-Übung erfüllt einen geforderten Penetrationstest nicht automatisch.

Testen ist nur ein Teil regulatorischer Bereitschaft. Ein CRA Readiness Assessment hilft Herstellern, die weiteren Anforderungen an Risikobewertung, Umgang mit Schwachstellen, Dokumentation, Tests und Prozesse im Produktlebenszyklus zu prüfen. Das ist etwas anderes, als aus einem erfolgreichen Pentest auf umfassende Konformität zu schließen.

Wie automatisierte Werkzeuge die Rechnung verändern

Manuelles Testen bleibt wertvoll, weil erfahrene Angreifer Kontext, unerwartetes Verhalten und Exploit-Ketten durchdenken können. Automatisierung verändert die Wirtschaftlichkeit, indem sie wiederholbare Erkennung und Analyse über mehr Systeme oder Firmware-Versionen ausführt, als ein Team manuell in derselben Frequenz prüfen könnte. Ein starkes Modell nutzt Automatisierung für die Abdeckung und reserviert Expertenzeit für die gegnerische Einschätzung.

Wo Automatisierung den größten Nutzen bringt

Automatisierte Produktanalyse kann Firmware-Builds untersuchen, Komponenten erkennen, eine SBOM erzeugen, bekannte Schwachstellen abgleichen und wiederholbare Prüfungen auf Binärebene ausführen. Das gibt Testenden einen besseren Ausgangspunkt für Exploitation und Angriffsketten. Dieselbe Analyse läuft erneut, sobald sich die Firmware ändert.

Automatisiertes CVE-Monitoring ist nach dem Release besonders nützlich, weil sich die Bedrohungslage auch dann ändert, wenn das Gerät gleich bleibt. Neu veröffentlichte CVEs können Komponenten betreffen, die bereits im Feld sind – ein Pentest von vor einigen Monaten bleibt dadurch nicht von allein aktuell. Fortlaufende Analyse hilft zu entscheiden, wann ein neuer Befund eine manuelle Untersuchung verdient.

Wo menschliche Testende weiterhin zählen

Menschen bleiben wichtig, wenn Erfolg von Kreativität, Geschäftslogik, ungewöhnlichem Geräteverhalten, Social Engineering, physischem Zugang oder dem Verketten mehrerer kleiner Schwächen abhängt. Erfahrene Testende ändern die Richtung, wenn sich ein Ziel unerwartet verhält, und beurteilen, ob ein Angriffspfad im realen Produktkontext überhaupt zählt. Solche Aufgaben lassen sich kaum in einen festen Scanner-Workflow gießen.

Red Teams testen außerdem die Verteidigung, nicht nur die Technik. Eine automatisierte Plattform liefert Befunde und Nachweise, bildet aber nicht jeden Aspekt eines motivierten Gegners ab, der mit Menschen und Betriebsprozessen interagiert. Geht es um organisatorische Resilienz, bleiben von Menschen geführte Übungen wertvoll.

Wo KI hilft, ohne Pentester zu ersetzen

KI kann Sicherheitsarbeit beschleunigen: Befunde abfragen, komplexe technische Informationen einordnen, Nachweise zusammenfassen oder die Analyse unterstützen. Der AI Agent von ONEKEY ist zum Beispiel darauf ausgelegt, mit Plattformergebnissen wie Firmware-Extraktion, Binärprüfung, SBOM-Daten, Komponentenanalyse und Schwachstelleninformationen zu arbeiten, statt die zugrunde liegende technische Analyse zu ersetzen. ONEKEY beschreibt das als nachweisbasierten Ansatz, bei dem KI Sicherheitsentscheidungen stützt, statt die Nachweise selbst zu erfinden.

KI kann Testende außerdem beim Recherchieren von Code, beim Bilden von Hypothesen oder beim Ordnen großer Ergebnismengen unterstützen – plausible Ausgaben sind aber kein validierter Exploit. Sicherheitstests brauchen weiterhin wiederholbare Nachweise, kontrollierte Validierung und menschliche Einschätzung der Auswirkung. Die wahrscheinliche Entwicklung heißt nicht Pentesting gegen Red Teaming gegen KI, sondern menschliches Testen, gestützt von deterministischer Automatisierung und sorgfältig verankerter KI.