Die Rolle des ISB beim SRA nach IEC 62443 in der Produktion
Der Informationssicherheitsbeauftragte (ISB) bewegt sich oft souverän in der Welt von Firewalls, Patch-Management und Zugriffskontrolle. Doch sobald es um Produktionsinfrastrukturen geht – Maschinen, Steuerungssysteme, Automatisierungsnetze – stoßen klassische IT-Sicherheitskonzepte an ihre Grenzen. Während ein Webserver ohne Weiteres für ein Sicherheits-Update heruntergefahren werden kann, verursacht eine stehende Produktionslinie schnell fünf- oder sechsstellige Beträge pro Stunde.
Genau hier verschiebt sich der Auftrag des ISB: Er muss industrielle Umgebungen nach internationalen Standards absichern und zugleich das Denken der Operational Technology (OT) verstehen. Dazu zählen Verfügbarkeiten, langen Lebenszyklen und engen Wartungsfenstern. Ein zentraler Baustein dafür ist die IEC 62443, der internationale Cybersecurity-Standard für industrielle Automatisierungs- und Steuerungssysteme (IACS).
ISB zwischen OT-Realität und Sicherheitsanforderungen
In der Produktion gelten andere Prioritäten als im klassischen IT-Umfeld. Verfügbarkeit und Sicherheit müssen in ein tragfähiges Gleichgewicht gebracht werden, statt „Security by Default“ einfach durchzudrücken. Viele OT-Systeme laufen zehn bis zwanzig Jahre, werden nur selten neu gestartet und steuern physische Prozesse, bei denen Fehler unmittelbare betriebliche oder sogar sicherheitsrelevante Folgen haben.
Der ISB agiert hier nicht als technischer Entscheider, sondern als Übersetzer und Moderator. Er bringt die Sicht der Produktion, der IT und des Managements in einen strukturierten Risikodialog.
Während Engineering und Betrieb stark auf Durchlauf, OEE und Anlagenverfügbarkeit schauen, bringt der ISB Aspekte wie Bedrohungsszenarien, Angriffsflächen und regulatorische Anforderungen ein.
IEC 62443 als Rahmen für strukturierte OT-Sicherheit
Die IEC 62443 liefert dem ISB ein Vokabular und ein Strukturmodell, um Produktionsinfrastrukturen systematisch zu betrachten. Die Normfamilie deckt vom Managementsystem über Systemarchitektur bis zu Komponentenanforderungen verschiedene Ebenen ab und richtet sich an Betreiber, Integratoren und Hersteller.
Zentral sind zwei Konzepte: Security Levels und die Idee der „Zones & Conduits“. Security Levels beschreiben, gegen wie leistungsfähige Angreifer eine Zone geschützt sein soll. Das reicht von zufälliger Fehlbedienung bis hin zu hochprofessionellen, gezielten Angreifern. Zones & Conduits helfen, eine bisher monolithische Anlagenlandschaft in logisch getrennte Bereiche mit klar definierten Schnittstellen zu überführen.
Strukturierte Netzwerk Segmentierung nach Zones & Conduits
Viele Produktionsnetze sind historisch gewachsen: eine Mischung aus Switches, Feldbussen, Remote-Zugängen und später hinzugefügten Security-Komponenten. Die IEC 62443 fordert, diese Landschaft in Zonen mit ähnlichem Schutzbedarf zu unterteilen und die Kommunikationspfade dazwischen bewusst zu gestalten.
Für den ISB ist diese Zonierung ein Hebel, um Sicherheit und Betrieb versöhnlich zu verbinden. Statt pauschal „mehr Firewalls“ zu fordern, lässt sich konkret diskutieren, welche Zone welchen Security Level erreichen soll, welche Übergänge besonders sensibel sind und wo Monitoring priorisiert werden muss. In der Praxis bedeutet das oft, dass besonders kritische Steuerungsbereiche stärker isoliert werden, während weniger empfindliche Segmente pragmatischer abgesichert werden dürfen.
Sicherheit Risk Assessment (SRA) nach IEC 62443‑3‑2
Der vielleicht wichtigste Baustein für den ISB im Kontext IEC 62443 ist das Security Risk Assessment (SRA) nach Teil 3‑2 der Norm.
Anders als ein Penetrationstest fragt ein SRA nicht „Kommt jemand rein?“, sondern „Welche Risiken bestehen insgesamt, wie kritisch sind sie und welche Maßnahmen sind dafür angemessen?“.
Im Kern durchläuft ein SRA mehrere Schritte:
- Zunächst wird der „System under Consideration“ (SuC) klar abgegrenzt. Das kann eine bestimmte Produktionslinie oder ein Anlagenteil sein.
- Anschließend werden kritische Geschäftsprozesse, Assets und Abhängigkeiten erfasst, um zu verstehen, welche Auswirkungen ein Ausfall oder Manipulation hätte. Ein hilfreiches Werkzeug dafür sind Angriffsbäume. Sie unterstützen durch ihre Struktur, potenzielle Angriffspfade systematisch nachzuvollziehen und daraus gezielte Maßnahmen abzuleiten.
- Darauf aufbauend werden Bedrohungen, Schwachstellen und mögliche Szenarien analysiert, in eine Risikomatrix überführt und mit geeigneten technischen wie organisatorischen Maßnahmen hinterlegt.
Ein entscheidender Vorteil des SRA-Ansatzes ist seine OT-Tauglichkeit: Tests, die Systeme „an die Grenze“ bringen oder produktive Steuerungen aktiv angreifen, sind in vielen Umgebungen schlicht nicht akzeptabel. SRA setzt daher auf strukturierte Analyse, Experteninterviews, vorhandene Logs und ergänzende technische Informationen (z.B. Vulnerability-Scans), ohne die Anlage in ihrem Betrieb zu gefährden.
Abgrenzung zu Penetrationstests und anderen Sicherheitsüberprüfungen
Gerade im OT-Kontext ist es wichtig, SRA sauber von anderen Prüfverfahren abzugrenzen. Ein Penetrationstest zielt darauf ab, konkrete Schwachstellen praktisch auszunutzen und zu demonstrieren, wie weit Angreifer kommen können. Das ist wertvoll, aber punktuell und häufig auf bestimmte Systeme oder Schnittstellen begrenzt.
Ein SRA hingegen zeichnet ein Gesamtbild: Es berücksichtigt nicht nur technische Lücken, sondern auch organisatorische Schwächen, fehlende Prozesse, übermäßige Abhängigkeiten von Einzelkomponenten oder unklare Verantwortlichkeiten. Damit eignet sich ein SRA besonders als Grundlage für Roadmaps, Investitionsentscheidungen und das Design einer Zielarchitektur nach IEC 62443, während Penetrationstests eher als ein Bestandteil eines SRA dienen können.
Auch klassische Audits oder Maturity-Assessments haben einen anderen Fokus: Sie prüfen, ob bestimmte Anforderungen erfüllt oder Prozesse formal etabliert sind. Ob diese Kontrollen im konkreten Anlagenkontext die wesentlichen Risiken tatsächlich adressieren, beantwortet eher ein gut aufgesetztes SRA als eine Checkliste.
| Kriterium | Penetrationstest | Security Risk Assessment (SRA) |
|---|---|---|
| Ziel | Nachweis, ob ein Angreifer tatsächlich in Systeme eindringen kann. | Ganzheitliche Bewertung von Risiken, Bedrohungen und Schwachstellen – inklusive ihrer Auswirkungen auf das Geschäft. |
| Fokus | Technische Schwachstellen und Exploits. | Technische, organisatorische und prozessuale Risikofaktoren. |
| Methode | Kombination aus automatisierten Scans und manuellen Angriffssimulationen. | Strukturierte Risikoanalyse nach definiertem Vorgehen (z. B. IEC 62443‑3‑2). |
| Ergebnis | Bericht mit konkreten Schwachstellen und Proof‑of‑Concepts. | Risikobewertung mit Prioritätenliste und Maßnahmenempfehlungen. |
| Einbindung des ISB | Koordiniert Durchführung und bewertet Ergebnisse im Kontext der Gesamtstrategie. | Leitet Prozess, moderiert Risiko-Workshops und bindet Fachbereiche ein. |
| Risikobetrachtung | Begrenzt auf getestete Systeme und Zeitrahmen. | Umfassend; berücksichtigt Geschäftsprozesse, OT‑Systeme und Schnittstellen. |
| Häufigkeit | Periodisch oder nach Systemänderungen. | Kontinuierlich im Rahmen des ISMS oder CSMS. |
| Einsatzgebiete | Validierung technischer Sicherheitsmaßnahmen. | Grundlage für Sicherheitsstrategie, Maßnahmenplanung und Budgetpriorisierung. |
| Risiken im OT‑Umfeld | Kann produktive Systeme stören; meist nur eingeschränkt möglich. | Nicht invasiv; geeignet für laufende Produktionsumgebungen. |
| Typischer Output | Liste gefundener Schwachstellen mit Bewertung nach CVSS. | Risikoregister mit Ursachen, Bewertung, empfohlenen Maßnahmen und Verantwortlichkeiten. |
Rolle des ISB im SRA-Kontext
Für das Thema Produktionsinfrastruktur lässt sich jedoch festhalten: Der ISB ist weniger derjenige, der jede Bedrohung technisch im Detail analysiert, sondern derjenige, der ein SRA initiiert, sauber aufsetzt und dafür sorgt, dass die Ergebnisse im Unternehmen andocken.
Er trägt Verantwortung dafür, dass Scope, Zonenbildung und Bewertungslogik zur Realität der Organisation passen, dass Betrieb, Engineering und IT einbezogen werden und dass am Ende nicht nur ein Dokument entsteht, sondern eine tragfähige Entscheidungsgrundlage für Maßnahmen, Budgets und Prioritäten. So wird das SRA von einem reinen Compliance-Artefakt zu einem Steuerungsinstrument, das OT-Sicherheit nachvollziehbar macht.
Details zur organisatorischen Position des ISB können an anderer Stelle vertieft werden etwa im Artikel „Der ISB als Schnittstelle zwischen Organisation und Risiken“.