Iec 62443: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

IEC 62443 ist im industriellen Umfeld kein einzelnes Dokument, sondern eine Normenfamilie für die Sicherheit von Industrial Automation and Control Systems. In der Praxis wird sie häufig falsch behandelt: als reine Compliance-Vorgabe, als Checkliste für Audits oder als abstraktes Management-Thema. Für Purple Teaming in OT-Umgebungen ist genau diese Sichtweise zu flach. Entscheidend ist, wie sich Anforderungen aus IEC 62443 in überprüfbare Sicherheitsmechanismen, belastbare Erkennungslogik und kontrollierte Testabläufe übersetzen lassen.

Der operative Mehrwert entsteht dort, wo technische Anforderungen aus der Norm mit realistischen Angriffspfaden verbunden werden. Ein Purple-Team-Ansatz ist dafür besonders geeignet, weil nicht nur Schwachstellen gesucht werden, sondern gleichzeitig geprüft wird, ob Überwachung, Alarmierung, Segmentierung und Reaktionsfähigkeit im OT-Betrieb tatsächlich funktionieren. Wer den generellen Ansatz vertiefen will, findet ergänzende Grundlagen unter Purple Teaming sowie eine methodische Einordnung unter Methodik.

Im OT-Kontext unterscheidet sich die Zielsetzung deutlich von klassischen IT-Übungen. Verfügbarkeit, Prozesssicherheit, deterministische Kommunikation, Safety-Abhängigkeiten und Herstellerrestriktionen begrenzen die Testtiefe. Gleichzeitig sind die Auswirkungen eines erfolgreichen Angriffs oft gravierender als in Office-Netzen: Produktionsstillstand, Qualitätsverlust, Fehlsteuerung, physische Schäden oder Gefährdung von Personal. Deshalb muss Purple Teaming nach IEC 62443 nicht aggressiver, sondern präziser werden.

Ein häufiger Denkfehler besteht darin, IEC 62443 nur auf Netzwerksegmentierung zu reduzieren. Segmentierung ist wichtig, aber sie ist nur ein Teil des Gesamtbilds. Die Norm adressiert unter anderem Rollen, Zugriffskontrolle, Systemhärtung, Patch- und Änderungsmanagement, Ereignisprotokollierung, Fernwartung, Integrität, Backup-Strategien und Sicherheitszonen. Purple Teaming muss diese Bereiche nicht theoretisch referenzieren, sondern in konkrete Prüffragen übersetzen: Welche Kommunikationsbeziehungen sind erlaubt? Welche davon sind tatsächlich aktiv? Welche Anomalien werden erkannt? Welche Admin-Zugriffe sind technisch möglich, obwohl sie organisatorisch verboten sind?

Gerade in industriellen Netzen ist das Zusammenspiel zwischen Engineering-Workstations, Historian, HMI, PLC, SCADA, Jump Hosts, Domain Services und Fernwartungszugängen oft komplexer als dokumentiert. IEC 62443 liefert dafür einen strukturierten Rahmen. Purple Teaming macht daraus einen überprüfbaren Prozess. Das Ziel ist nicht, eine Norm „abzuhaken“, sondern Sicherheitsannahmen gegen reale Taktiken zu testen. In vielen Fällen zeigt sich erst in solchen Übungen, dass eine Zone zwar auf dem Papier existiert, aber durch falsch konfigurierte Firewalls, gemeinsam genutzte Admin-Konten oder ungefilterte Protokolle praktisch wirkungslos ist.

Besonders wertvoll wird der Ansatz, wenn OT-Verantwortliche, Security Operations, Netzwerkteam und Anlagenbetrieb gemeinsam arbeiten. Dann lassen sich technische Kontrollen nicht isoliert, sondern entlang echter Betriebsabläufe bewerten. Genau dort trennt sich formale Konformität von wirksamer Sicherheit.

Wer Purple Teaming nach IEC 62443 sauber aufsetzt, beginnt nicht mit Tools, sondern mit dem Architekturmodell. Zonen und Conduits sind kein Dokumentationsformalismus, sondern die Grundlage für jede sinnvolle Angriffssimulation und jede Detection-Validierung. Eine Zone bündelt Assets mit ähnlichen Sicherheitsanforderungen. Ein Conduit beschreibt den kontrollierten Kommunikationspfad zwischen Zonen. In der Praxis bedeutet das: Nicht nur Geräte zählen, sondern Vertrauensgrenzen, Kommunikationsmuster und betriebliche Abhängigkeiten.

Ein typisches Problem in OT-Umgebungen ist die Vermischung von funktionaler und sicherheitstechnischer Sicht. Ein Netzsegment wird oft als „Produktionsnetz“ bezeichnet, obwohl darin Systeme mit völlig unterschiedlichen Schutzbedarfen liegen: HMI, Engineering-Station, Patch-Server, Historian, Domänencontroller, Backup-Systeme und externe Wartungszugänge. Für Purple Teaming ist diese Unschärfe gefährlich. Wenn die Zonendefinition unpräzise ist, werden Tests zu breit, zu riskant oder schlicht unbrauchbar.

Security Levels werden ebenfalls häufig missverstanden. Sie sind keine Marketingstufe und kein allgemeiner Reifegrad, sondern beschreiben das angestrebte Widerstandsniveau gegen definierte Angreiferfähigkeiten. Für Purple Teaming heißt das: Ein Testfall muss zur angenommenen Bedrohung passen. Ein opportunistischer Angreifer, ein interner Administrator mit Fehlverhalten und ein gezielter OT-Akteur erzeugen unterschiedliche Anforderungen an Prävention und Erkennung. Ohne diese Differenzierung entstehen Übungen, die entweder unrealistisch harmlos oder unnötig invasiv sind.

Ein belastbarer Workflow beginnt mit einer technischen Kartierung:

• Welche Assets gehören logisch und betrieblich in dieselbe Zone?
• Welche Protokolle und Kommunikationsrichtungen sind über Conduits erlaubt?
• Welche Authentisierungs- und Autorisierungsmechanismen schützen diese Übergänge?
• Welche Logs, NetFlow-, SPAN- oder Sensor-Daten stehen pro Zone tatsächlich zur Verfügung?
• Welche Aktionen sind testbar, ohne Safety, Verfügbarkeit oder Prozessintegrität zu gefährden?

Erst danach werden Angriffsszenarien definiert. Ein Beispiel: Zwischen einer Unternehmenszone und einer OT-DMZ existiert ein Historian-Replikationspfad. Formal ist der Conduit dokumentiert. Im Purple Teaming wird nun geprüft, ob nur die erwarteten Verbindungen erlaubt sind, ob Authentisierung erzwungen wird, ob ungewöhnliche Datenmengen auffallen und ob seitliche Bewegungen von der DMZ in Richtung Leitnetz technisch oder organisatorisch verhindert werden. Die Norm liefert die Struktur, die Übung zeigt die Realität.

In vielen Umgebungen lohnt sich zusätzlich die Verbindung mit Threat Modeling und einer sauberen Strategie. Gerade in OT ist es entscheidend, nicht nur einzelne Hosts zu betrachten, sondern Prozessketten, Wartungswege und implizite Vertrauensbeziehungen. Ein falsch platzierter Jump Host oder ein Engineering-Laptop mit Mehrfachanbindung kann eine komplette Zonenseparation aushebeln, obwohl Firewalls formal korrekt konfiguriert sind.

Die wichtigste Erkenntnis aus der Praxis: Zonen und Conduits sind nur dann nützlich, wenn sie mit beobachtbaren Sicherheitskontrollen verknüpft werden. Ein Conduit ohne Logging, ohne Regelreview und ohne Testfall ist nur eine Annahme. Purple Teaming macht aus dieser Annahme einen messbaren Zustand.

Die meisten Probleme entstehen nicht durch fehlende Tools, sondern durch falsche Annahmen über das Umfeld. In klassischen IT-Netzen lassen sich viele Tests wiederholen, isolieren und bei Bedarf zurückrollen. In OT gilt das nur eingeschränkt. Purple Teaming nach IEC 62443 scheitert oft daran, dass Teams mit IT-Denkmustern in Produktionsumgebungen arbeiten. Das führt zu riskanten Testdesigns, unvollständigen Ergebnissen oder falschen Schlussfolgerungen.

Eine verbreitete Fehlannahme lautet: Wenn keine aktive Ausnutzung stattfindet, ist der Test automatisch sicher. Das stimmt nicht. Bereits Scans mit ungeeigneten Timing-Parametern, Protokollabweichungen, Broadcast-Last oder ungetestete Authentisierungsversuche können ältere Geräte destabilisieren. Noch kritischer wird es bei proprietären Protokollen oder Gateways, deren Fehlerverhalten kaum dokumentiert ist. Deshalb muss jede Übung vorab zwischen passiver Beobachtung, kontrollierter Interaktion und aktiver Simulation unterscheiden.

Ebenso problematisch ist die Annahme, dass vorhandene IT-Sicherheitskontrollen automatisch auf OT übertragbar sind. Ein EDR-Agent auf einer Engineering-Workstation kann hilfreich sein, aber auf einem HMI mit Herstellerbindung oder auf einem Legacy-Windows-System kann derselbe Agent zu Inkompatibilitäten führen. Ein SIEM kann Logs korrelieren, aber wenn SPS-nahe Kommunikation nicht sichtbar ist, bleibt die Erkennung lückenhaft. Wer diese Unterschiede ignoriert, bewertet Kontrollen falsch. Ergänzende Perspektiven zu Detection und Betriebsintegration finden sich unter Und Siem, Und Soc und Und Detection Engineering.

Ein weiterer Fehler ist die Vermischung von Audit-Fragen und Angriffspfaden. Ein Audit fragt, ob ein Prozess existiert. Purple Teaming fragt, ob der Prozess unter realen Bedingungen wirksam ist. Beispiel: Fernwartung ist formal freigegeben, per VPN abgesichert und organisatorisch genehmigungspflichtig. In der Übung zeigt sich aber, dass ein altes Wartungskonto nie deaktiviert wurde, dass MFA nur für interne Nutzer gilt oder dass der Jump Host gleichzeitig Zugriff auf mehrere Zonen erlaubt. Formal ist vieles vorhanden, praktisch bleibt der Pfad angreifbar.

Besonders kritisch sind folgende Fehlmuster:

• Testziele werden aus Office-IT übernommen, ohne Prozess- und Safety-Abhängigkeiten zu prüfen.
• Asset-Inventare sind unvollständig, wodurch kritische Kommunikationsbeziehungen übersehen werden.
• Detektionsregeln werden nur gegen bekannte IT-Indikatoren validiert, nicht gegen OT-spezifische Verhaltensmuster.
• Ergebnisse werden als Einzelbefunde dokumentiert, ohne Bezug zu Zonen, Conduits und Betriebsrisiken.
• Lessons Learned bleiben im Security-Team und erreichen Anlagenbetrieb, Engineering und Instandhaltung nicht.

Ein sauberer Purple-Team-Prozess muss deshalb immer die Frage beantworten, welche Annahme gerade geprüft wird. Nicht „Kann ein Host erreicht werden?“, sondern „Ist der definierte Conduit technisch auf das notwendige Minimum begrenzt, wird Missbrauch erkannt und kann der Betrieb kontrolliert reagieren?“ Diese Präzision verhindert Aktionismus und erzeugt Ergebnisse, die im OT-Alltag belastbar sind.

Gerade Einsteiger unterschätzen oft, wie viel Vorarbeit nötig ist. Für einen strukturierten Einstieg eignen sich Purple Teaming Für Anfänger und Im Ot Bereich, wenn der Fokus auf industriellen Umgebungen liegt.

Ein belastbarer Workflow in OT beginnt lange vor dem ersten Testpaket. Der Kern besteht aus Freigabe, Scope, Sicherheitsgrenzen, Beobachtbarkeit, Abbruchkriterien und Nachbereitung. In IEC-62443-nahen Umgebungen ist das kein bürokratischer Overhead, sondern die Voraussetzung dafür, dass Übungen technisch aussagekräftig und betrieblich vertretbar bleiben.

Der erste Schritt ist die Scope-Definition entlang von Zonen und Conduits. Nicht „Werk A testen“, sondern klar eingrenzen: Welche Zone, welche Systeme, welche Kommunikationspfade, welche Zeitfenster, welche Protokolle, welche Rollen, welche erlaubten Interaktionen. Danach folgt die Risikoabstimmung mit Betrieb, OT-Engineering, Netzwerkteam und Security. Hier werden auch No-Go-Bereiche festgelegt, etwa Safety-Systeme, produktionskritische Steuerungen oder Herstellerkomponenten ohne Freigabe für aktive Tests.

Im nächsten Schritt wird die Beobachtbarkeit geprüft. Ein Test ohne Telemetrie ist in OT oft wertlos. Vor der Übung muss klar sein, welche Datenquellen verfügbar sind: Firewall-Logs, IDS-Sensoren, Switch-Mirroring, Windows-Events auf Engineering-Stationen, VPN-Logs, Jump-Server-Protokolle, Historian-Zugriffe, Authentisierungsereignisse und gegebenenfalls OT-spezifische Netzwerküberwachung. Fehlt diese Sichtbarkeit, sollte zuerst die Erfassungsbasis verbessert werden, bevor komplexe Szenarien gefahren werden.

Danach werden Testfälle in Eskalationsstufen aufgebaut. Statt direkt mit aggressiven Aktionen zu beginnen, wird schrittweise validiert: passive Erkennung, kontrollierte Verbindungsversuche, Authentisierungsereignisse, erlaubte und unerlaubte Kommunikationsmuster, Missbrauch legitimer Wartungspfade, laterale Bewegung innerhalb definierter Grenzen. Diese Staffelung reduziert Risiko und erhöht den Erkenntnisgewinn. Methodisch passt das gut zu Workflow, Ablauf und Playbook.

Ein praxistauglicher Ablauf sieht oft so aus:

1. Architektur und Zonengrenzen validieren
2. Kritische Kommunikationspfade identifizieren
3. Telemetrie und Logging prüfen
4. Testhypothesen formulieren
5. Risiko- und Freigabefenster abstimmen
6. Passive und low-impact Tests durchführen
7. Detection und Alarmierung live bewerten
8. Findings sofort mit Betrieb und Blue Team spiegeln
9. Regeln, Segmentierung oder Prozesse anpassen
10. Testfall wiederholen und Wirksamkeit nachmessen

Wichtig ist die direkte Rückkopplung. Purple Teaming in OT darf nicht erst Wochen später in einem Bericht enden. Wenn ein unerwarteter Zugriffspfad sichtbar wird oder eine Erkennung ausbleibt, muss die Hypothese sofort mit den beteiligten Teams geprüft werden. Oft zeigt sich dabei, dass nicht nur eine technische Lücke vorliegt, sondern ein Prozessfehler: unklare Verantwortlichkeit, fehlende Regelpflege, veraltete Dokumentation oder eine Ausnahme, die nie zurückgebaut wurde.

Ein sauberer Workflow enthält außerdem Abbruchkriterien. Dazu gehören erhöhte CPU-Last auf sensiblen Hosts, Kommunikationsstörungen, unerwartete Prozessalarme, HMI-Verzögerungen, Paketverluste auf kritischen Segmenten oder Fehlermeldungen in Steuerungsnähe. Wer solche Kriterien nicht vorab definiert, reagiert im Ernstfall zu spät oder diskutiert während der Störung über Zuständigkeiten.

Der Unterschied zwischen einem guten und einem schlechten OT-Purple-Teaming liegt selten in der Toolauswahl. Entscheidend ist, ob der Ablauf kontrolliert, beobachtbar und wiederholbar ist. Genau daraus entstehen Verbesserungen, die über einen Einzelfund hinausgehen.

Gute OT-Szenarien orientieren sich nicht an spektakulären Malware-Narrativen, sondern an realistischen Eintrittspfaden und betrieblichen Schwachstellen. IEC 62443 hilft dabei, weil die Norm Sicherheitsfunktionen strukturiert, aber die eigentliche Qualität entsteht erst durch die Auswahl plausibler Taktiken. In industriellen Umgebungen sind das häufig Fernwartung, Engineering-Zugänge, schwach segmentierte DMZs, gemeinsam genutzte Konten, unkontrollierte Dateitransfers, veraltete Windows-Systeme und implizites Vertrauen zwischen Betriebs- und Administrationssystemen.

Ein typisches Szenario beginnt in der IT-nahen Zone: kompromittierter Wartungszugang, Missbrauch eines Jump Hosts oder Zugriff auf eine Engineering-Workstation. Von dort wird nicht sofort „die SPS angegriffen“, sondern zunächst geprüft, welche Übergänge tatsächlich möglich sind. Kann auf Freigaben zugegriffen werden? Lassen sich Projektdateien lesen? Werden ungewöhnliche RDP- oder SMB-Verbindungen erkannt? Ist die Trennung zwischen Historian, Engineering und HMI technisch wirksam oder nur organisatorisch beschrieben?

Ein weiteres realistisches Szenario ist der Missbrauch legitimer Werkzeuge. In OT sind viele administrative Aktionen grundsätzlich erlaubt, solange sie von autorisierten Personen ausgeführt werden. Genau das macht Erkennung schwierig. Purple Teaming sollte deshalb nicht nur auf Malware-Indikatoren setzen, sondern auf Kontextabweichungen: Zugriff außerhalb von Wartungsfenstern, Engineering-Aktivität ohne Change-Ticket, Dateiübertragungen in unerwartete Zonen, neue Kommunikationsbeziehungen zwischen sonst getrennten Segmenten oder Authentisierung von Konten auf Systemen, auf denen sie nie genutzt werden sollten.

Für die Szenarioentwicklung ist die Verbindung zu Szenarien, Angriffe Simulieren und Und Mitre Attack sinnvoll. Allerdings darf MITRE-Mapping in OT nicht mechanisch erfolgen. Eine Technik ist erst dann nützlich, wenn sie auf die konkrete Architektur, die vorhandene Telemetrie und die betrieblichen Grenzen passt.

Ein praxistaugliches OT-Szenario sollte mindestens folgende Elemente enthalten:

• klarer Startpunkt mit realistischer Vorbedingung, etwa Fernwartung, kompromittierte IT-nahe Systeme oder Insider-Zugriff
• definierte Zielhandlung, zum Beispiel unautorisierter Zugriff auf Engineering-Daten, laterale Bewegung oder Missbrauch eines Conduits
• begrenzte technische Aktionen mit abgestuften Risikoklassen und klaren Stop-Kriterien
• erwartete Telemetrie und konkrete Detection-Hypothesen pro Schritt
• betriebliche Bewertung: Welche Auswirkung hätte derselbe Pfad im Ernstfall auf Verfügbarkeit, Integrität und Sicherheit?

Ein Beispiel aus der Praxis: Ein externer Dienstleister verbindet sich per VPN mit einem Wartungsportal. Die Authentisierung ist gültig, aber das Konto ist überprivilegiert. Über den Jump Host wird eine Engineering-Station erreicht. Dort liegen Projektdateien und gespeicherte Verbindungsprofile. Die eigentliche Übung besteht nicht darin, Steuerungslogik zu verändern, sondern zu prüfen, ob dieser Pfad erkannt, begrenzt und nachvollzogen wird. Werden ungewöhnliche Dateizugriffe geloggt? Fällt die Verbindung außerhalb des Wartungsfensters auf? Ist der Zugriff auf die Engineering-Station zonenseitig korrekt beschränkt? Kann das SOC den Vorgang von legitimer Wartung unterscheiden?

Solche Szenarien sind technisch realistisch, betrieblich vertretbar und liefern deutlich mehr Erkenntnis als pauschale Schwachstellenscans auf Produktionssystemen.

Viele OT-Programme investieren zuerst in Segmentierung und härten danach einzelne Systeme. Detection wird oft nachgelagert behandelt. Genau das rächt sich im Purple Teaming. Ohne belastbare Telemetrie bleibt unklar, ob eine Kontrolle wirksam ist oder nur zufällig nicht umgangen wurde. IEC 62443 fordert keine beliebige Log-Sammlung, sondern nachvollziehbare Sicherheitsfunktionen. In der Praxis bedeutet das: Ereignisse müssen so erfasst werden, dass Missbrauch von Zonenübergängen, privilegierten Konten, Fernwartung und Engineering-Aktivitäten sichtbar wird.

In industriellen Umgebungen ist die Datenlage heterogen. Manche Systeme liefern Windows-Events, andere nur proprietäre Protokolle, wieder andere gar keine lokalen Logs. Deshalb muss Detection mehrschichtig aufgebaut werden. Netzwerknahe Sicht ist oft wichtiger als Host-Telemetrie, besonders bei Legacy-Systemen. Firewalls, OT-IDS, VPN-Gateways, Jump Hosts, Authentisierungsdienste und zentrale Log-Plattformen bilden zusammen das Rückgrat. Ergänzend können Engineering-Stationen, Historian-Server und administrative Systeme tiefer überwacht werden, sofern Herstellerfreigaben und Betriebsstabilität das zulassen.

Ein häufiger Fehler ist die Übernahme klassischer IT-Regeln ohne OT-Kontext. Eine Regel auf „PowerShell-Ausführung“ kann auf einer Engineering-Station sinnvoll sein, sagt aber wenig über missbräuchliche Nutzung eines legitimen Hersteller-Tools aus. Wertvoller sind Regeln, die Kontext und Architektur berücksichtigen: neue Kommunikationsbeziehungen über einen Conduit, RDP in nicht freigegebenen Wartungsfenstern, Dateiübertragungen zwischen DMZ und Leitnetz, Authentisierung eines Dienstleisterkontos auf unerwarteten Hosts oder Änderungen an Firewall-Regeln in produktionsnahen Segmenten.

Praxisnah wird Detection erst, wenn sie gegen echte Testfälle validiert wird. Genau hier spielt Purple Teaming seine Stärke aus. Statt abstrakt zu diskutieren, ob eine Regel „gut“ ist, wird geprüft, ob sie unter realen Bedingungen auslöst, ob sie verständlich genug ist und ob das Betriebsteam daraus handlungsfähige Entscheidungen ableiten kann. Vertiefend passen dazu Und Threat Detection, Und Log Analyse und Und Alerting.

Wichtig ist auch die Trennung zwischen Sichtbarkeit und Erkennung. Sichtbarkeit bedeutet, dass ein Ereignis technisch beobachtbar ist. Erkennung bedeutet, dass daraus ein verwertbarer Hinweis entsteht. Viele OT-Umgebungen haben zwar Logs, aber keine belastbaren Korrelationen. Andere haben Alarme, die so generisch sind, dass sie im Betrieb ignoriert werden. Purple Teaming sollte deshalb immer drei Fragen beantworten: Wurde das Ereignis gesehen? Wurde es korrekt interpretiert? Wurde angemessen reagiert?

Ein Beispiel: Ein Dienstleisterkonto meldet sich außerhalb des Wartungsfensters am Jump Host an. Sichtbarkeit wäre das Login-Event. Erkennung wäre die Korrelation mit Zeitfenster, Quell-IP, Zielzone und Benutzerrolle. Reaktion wäre die Prüfung, ob die Sitzung legitim ist, ob weitere Verbindungen aufgebaut wurden und ob ein Containment ohne Betriebsunterbrechung möglich ist. Erst wenn alle drei Ebenen funktionieren, ist die Kontrolle belastbar.

In OT ist weniger oft mehr. Zehn präzise Regeln mit sauberem Kontext sind wertvoller als hunderte generische Signaturen, die niemand pflegt. Purple Teaming hilft, genau diese Priorisierung technisch zu begründen.

Technische Qualität allein reicht in OT nicht aus. Viele Übungen scheitern an organisatorischen Reibungen: unklare Freigaben, fehlende Ansprechpartner, widersprüchliche Zuständigkeiten oder Kommunikationswege, die im Störungsfall nicht funktionieren. IEC 62443 adressiert Governance und Verantwortlichkeiten nicht zufällig. In industriellen Umgebungen ist Sicherheit immer an Betrieb und Instandhaltung gekoppelt. Wer Purple Teaming ohne diese Realität plant, produziert unnötige Risiken.

Ein klassischer Fehler ist die Freigabe auf Management-Ebene ohne operative Einbindung. Das Security-Team hat grünes Licht, aber Schichtleitung, Leitstand, OT-Engineering und externe Dienstleister wissen nichts von der Übung oder kennen nur grobe Eckdaten. Tritt dann ein unerwarteter Alarm auf, wird entweder zu spät reagiert oder die Übung wird mit einer echten Störung verwechselt. Beides verfälscht Ergebnisse und beschädigt Vertrauen.

Ebenso problematisch ist die unklare Rollenverteilung zwischen IT-Security, OT-Betrieb und externen Integratoren. Wer darf Tests stoppen? Wer bewertet Prozessrisiken? Wer entscheidet über kurzfristige Regeländerungen? Wer dokumentiert Abweichungen an Firewalls oder Jump Hosts? Ohne diese Klarheit entstehen in kritischen Momenten Diskussionen statt Entscheidungen.

Saubere Kommunikation im Purple Teaming bedeutet nicht, jede Aktion im Voraus anzukündigen. Aber alle Beteiligten müssen die Spielregeln kennen: Scope, Eskalationsstufen, Notfallkontakte, Abbruchkriterien, Freigabefenster und Dokumentationspflichten. Besonders in KRITIS-nahen Umgebungen ist das unverzichtbar. Ergänzend hilfreich sind Communication, Collaboration und Kritis.

Ein weiterer Fehler liegt in der Trennung von Security- und Betriebsdokumentation. Findings werden oft in Security-Berichten festgehalten, ohne dass Anlagenbezug, Prozessauswirkung oder technische Eigentümer sauber vermerkt sind. Dadurch bleiben Maßnahmen liegen, weil niemand eindeutig verantwortlich ist oder weil die Formulierung für OT-Teams zu abstrakt bleibt. Ein guter Befund beschreibt nicht nur die Schwachstelle, sondern auch Zone, Conduit, betroffene Systeme, beobachtete Telemetrie, Betriebsrelevanz und empfohlene Gegenmaßnahmen mit Priorität.

In der Praxis bewährt sich ein gemeinsames Lagebild während der Übung: Wer beobachtet welche Datenquellen, wer bestätigt betriebliche Normalität, wer dokumentiert Abweichungen, wer hält Entscheidungen fest. Das reduziert Missverständnisse und beschleunigt die Nachbereitung erheblich. Purple Teaming wird dadurch nicht langsamer, sondern kontrollierter und aussagekräftiger.

Tooling im OT-Purple-Teaming wird oft überschätzt. Kein Werkzeug kompensiert fehlendes Architekturverständnis oder schlechte Freigaben. Trotzdem ist die Auswahl entscheidend, weil falsche Werkzeuge oder falsche Parameter in industriellen Netzen schnell zu Störungen führen. Die wichtigste Regel lautet: Testtiefe folgt Risiko und Freigabe, nicht umgekehrt.

Netzwerkbasierte Sicht ist meist der sicherste Einstieg. Passive Sensoren, SPAN-Ports, Firewall-Logs und Flow-Daten liefern oft genug Material, um Kommunikationspfade, Anomalien und Segmentierungsfehler zu bewerten. Aktive Werkzeuge müssen deutlich restriktiver eingesetzt werden als in Office-Netzen. Selbst bekannte Scanner können mit Standardprofilen zu aggressiv sein. Timing, Parallelität, Protokolloptionen und Zielauswahl müssen an das konkrete Umfeld angepasst werden.

Für unterstützende Werkzeuge lohnt sich ein Blick auf Tools, Open Source Tools und Mit Nmap. Entscheidend ist jedoch nicht das Werkzeug selbst, sondern die Frage, ob es im jeweiligen Segment zulässig und technisch verträglich ist. Ein Nmap-Scan mit konservativen Optionen gegen einen freigegebenen Jump Host ist etwas völlig anderes als ein breit gestreuter Portscan in Richtung älterer Steuerungssegmente.

Auch bei Simulationsplattformen und Frameworks gilt Zurückhaltung. In OT ist der Mehrwert oft nicht die Ausnutzung einer Schwachstelle, sondern die kontrollierte Nachbildung eines Verhaltensmusters. Ein Beispiel: Statt eine unsichere SMB-Konfiguration aktiv auszunutzen, kann bereits der Versuch einer nicht erlaubten Verbindung aus einer falschen Zone genügen, um Segmentierung und Detection zu validieren. Statt Payloads auf produktionsnahen Systemen auszuführen, kann die Übung auf Jump Hosts, Testsegmenten oder Engineering-Stationen mit Freigabe begrenzt werden.

Die sichere Testtiefe hängt von mehreren Faktoren ab: Kritikalität des Prozesses, Herstellerfreigaben, Redundanz, Wartungsfenster, vorhandene Telemetrie und Reaktionsfähigkeit des Betriebs. In vielen Fällen ist ein abgestuftes Modell sinnvoll:

Stufe 1: rein passive Beobachtung und Log-Validierung
Stufe 2: kontrollierte Verbindungsversuche ohne Zustandsänderung
Stufe 3: Authentisierungs- und Zugriffssimulation auf freigegebenen Systemen
Stufe 4: begrenzte Missbrauchsszenarien auf nicht-produktionskritischen Hosts
Stufe 5: tiefergehende Tests nur in Labor, FAT/SAT-Umgebung oder dediziertem OT-Testnetz

Diese Staffelung verhindert, dass Teams aus Ehrgeiz zu tief in produktionsnahe Systeme eingreifen. Gerade bei IEC-62443-orientierten Programmen ist das wichtig, weil die Norm nicht maximale Aggressivität fordert, sondern wirksame und beherrschte Sicherheitsmaßnahmen. Ein Test, der den Betrieb gefährdet, ist kein Qualitätsmerkmal.

Besonders sinnvoll ist die Kombination aus Produktionsumgebung und Labor. In der Produktion werden Sichtbarkeit, Segmentierung, Freigaben und Reaktionsprozesse validiert. Im Labor lassen sich tiefere technische Hypothesen prüfen: Protokollverhalten, Exploit-Auswirkungen, Härtungsmaßnahmen oder Herstellerrestriktionen. Erst die Verbindung beider Ebenen liefert ein realistisches Gesamtbild.

Ein häufiger Fehler in OT-Sicherheitsprogrammen ist die Behandlung von Purple Teaming als Einzelereignis. Eine Übung wird durchgeführt, ein Bericht geschrieben, einige Maßnahmen beschlossen und danach verschwindet das Thema im Tagesgeschäft. Für IEC-62443-nahe Umgebungen ist das zu wenig. Sicherheit in industriellen Netzen verändert sich mit jeder Anlagenanpassung, jedem Dienstleisterzugang, jedem Firewall-Change und jeder neuen Fernwartungslösung. Deshalb müssen Ergebnisse so dokumentiert werden, dass sie wiederholbar und vergleichbar bleiben.

Gutes Reporting beschreibt nicht nur, was passiert ist, sondern unter welchen Bedingungen. Dazu gehören Scope, Zone, Conduit, Testhypothese, erlaubte Aktionen, beobachtete Telemetrie, tatsächliche Erkennung, Reaktionszeit, betriebliche Auswirkungen und empfohlene Maßnahmen. Ohne diesen Kontext sind Befunde später kaum reproduzierbar. Besonders wichtig ist die Trennung zwischen technischem Detailbericht und Management-Sicht. OT-Verantwortliche brauchen konkrete Umsetzungsinformationen, nicht nur Risikofarben.

Metriken müssen praxisnah sein. Reine Zählwerte wie „Anzahl erkannter Events“ sind wenig aussagekräftig. Besser sind Kennzahlen, die Wirksamkeit abbilden: Anteil korrekt erkannter Testschritte, Zeit bis zur Sichtbarkeit, Zeit bis zur Einordnung, Zeit bis zur Eskalation, Anzahl unerwarteter Kommunikationspfade, Anteil dokumentierter Conduits mit verifizierter Regelbasis, Anzahl privilegierter Konten mit zonenfremder Nutzung. Solche Metriken zeigen, ob sich die Sicherheitslage tatsächlich verbessert.

Wiederholbarkeit entsteht durch standardisierte Testfälle und saubere Dokumentation. Wenn ein Szenario „Missbrauch Fernwartungspfad“ heute durchgeführt wird, muss es nach einer Regelanpassung oder Architekturänderung erneut gefahren werden können. Nur so lässt sich belegen, ob eine Maßnahme wirkt oder nur formal eingeführt wurde. Dazu passen Reporting, Dokumentation und Metriken.

Ein praxistauglicher Bericht in OT beantwortet immer vier Ebenen: Was war die Annahme? Was wurde technisch beobachtet? Welche betriebliche Relevanz ergibt sich daraus? Welche konkrete Änderung ist erforderlich? Wenn eine Firewall-Regel zu breit ist, reicht es nicht, das als „Segmentierungsproblem“ zu notieren. Es muss klar sein, welche Zonen betroffen sind, welche Kommunikation unnötig erlaubt ist, welche Detection fehlte und wie die Regel nach der Änderung erneut validiert wird.

Der eigentliche Reifegewinn entsteht erst in der Iteration. Eine gute Purple-Team-Organisation misst nicht nur, ob ein Test erfolgreich war, sondern ob sich die nächste Durchführung verbessert. Weniger Blind Spots, präzisere Alarme, schnellere Einordnung, sauberere Freigaben und klarere Verantwortlichkeiten sind die Kennzeichen eines funktionierenden Programms.

Ein belastbares Programm im industriellen Umfeld braucht keine maximale Tooldichte, sondern Disziplin in Architektur, Testdesign und Nachverfolgung. Purple Teaming nach IEC 62443 funktioniert dann gut, wenn Sicherheitsanforderungen in überprüfbare Hypothesen übersetzt werden und jede Übung einen konkreten Beitrag zur Härtung von Zonen, Conduits, Zugriffswegen und Erkennungsmechanismen leistet.

Der erste Grundsatz lautet: Architektur vor Aktion. Ohne belastbare Sicht auf Zonen, Kommunikationspfade und Eigentümerstrukturen sind Ergebnisse kaum verwertbar. Der zweite Grundsatz lautet: Beobachtbarkeit vor Tiefe. Wenn ein Testschritt nicht sauber gesehen und bewertet werden kann, bringt zusätzliche Aggressivität wenig. Der dritte Grundsatz lautet: Betrieb vor Show-Effekt. In OT zählt kontrollierter Erkenntnisgewinn mehr als spektakuläre Demonstration.

Aus der Praxis haben sich folgende Leitlinien bewährt:

Tests sollten entlang realer Betriebswege geplant werden: Fernwartung, Engineering, Historian, administrative Übergänge, Dateiübertragung und Domänenabhängigkeiten. Jede Übung braucht klare Stop-Kriterien und eine abgestufte Eskalation. Findings müssen immer an technische Eigentümer und Betriebsverantwortliche rückgebunden werden. Detection-Regeln sollten auf wenige, hochwertige Signale fokussieren, die im Kontext der Anlage interpretierbar sind. Maßnahmen müssen nach Umsetzung erneut validiert werden, sonst bleibt unklar, ob die Änderung wirksam ist.

Ebenso wichtig ist die Trennung zwischen Produktions- und Laborzielen. Produktionsnahe Übungen validieren Sichtbarkeit, Segmentierung und Reaktion. Labore oder dedizierte Testumgebungen erlauben tiefere technische Analysen, etwa Protokollmanipulation, Exploit-Verhalten oder Herstellergrenzen. Wer beides vermischt, riskiert entweder zu wenig Erkenntnis oder zu viel Betriebsrisiko.

Für den organisatorischen Ausbau helfen häufig ergänzende Themen wie Best Practices, Prozess und Iteration. Gerade in OT ist Reife kein Zustand, sondern ein fortlaufender Abgleich zwischen dokumentierter Architektur und tatsächlichem Verhalten im Netz.

Am Ende ist IEC 62443 im Purple Teaming kein Selbstzweck. Der Nutzen entsteht dort, wo Normanforderungen in technische Realität übersetzt werden: Welche Übergänge existieren wirklich? Welche davon sind notwendig? Welche werden überwacht? Welche könnten missbraucht werden? Welche Reaktion ist unter Produktionsbedingungen möglich? Wer diese Fragen regelmäßig, kontrolliert und nachvollziehbar beantwortet, verbessert nicht nur die Sicherheitslage, sondern auch die betriebliche Handlungsfähigkeit im Ernstfall.