Risikoanalyse in Produktionsnetzen: Entscheiden mit unvollständigen Informationen und knappem Budget

Warum die Analyse fast immer mit Lücken beginnt

In der Büro-IT lässt sich ein Inventar mit Agenten und Verzeichnisdiensten in Tagen erzeugen. In der Produktion funktioniert das leider nicht. Steuerungen, Frequenzumrichter, Scanner und Bedienpanels laufen ohne Agenten. Ein aktiver Scan kann eine ältere SPS zum Absturz bringen. Viele Anlagen sind als Paket vom Maschinenbauer gekommen, dessen interne Verkabelung nie jemand aufgenommen hat. Dazu kommen Fernwartungszugänge, die vor Jahren „vorübergehend" eingerichtet wurden, und Netzübergänge, die niemand mehr zuordnen kann. Wie oft trifft man auf die typischen Mobilfunkverbindungen zu Fernwartungszwecken, die mitten in der Produktion terminieren und dort direkt mit dem Internet verbunden sind. Abgesehen von einer eventuell davor installierten PAP-Infrastruktur ist an diesem Punkt keine wirkliche Sicherheit vorhanden und über Updates wird an dieser Stelle meißt nicht nachgedacht.

Das sind keine Versäumnisse, die man vor der Risikoanalyse erst beheben müsste. Es ist der Normalzustand, mit dem die Analyse umgehen muss. Wer wartet, bis das Inventar vollständig ist, analysiert nie (und die gesetzliche Pflicht wartet nicht). Das NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 ohne Übergangsfrist in Kraft, § 30 BSIG verlangt Risikoanalyse und Risikomanagementmaßnahmen, § 38 BSIG verpflichtet die Geschäftsleitung, diese Maßnahmen zu billigen und zu überwachen. Betroffene Einrichtungen mussten sich bis zum 6. März 2026 beim BSI registrieren.

Vom Geschäftsprozess zur Netzarchitektur, nicht umgekehrt

Der häufigste methodische Fehler ist, bei der Schwachstelle anzufangen. Ein Scanner liefert eine Liste veralteter Firmware, und daraus wird eine Maßnahmenliste. Das Ergebnis ist eine Priorisierung nach CVSS-Wert (Common Vulnerability Scoring System), die mit dem tatsächlichen Schaden für das Unternehmen wenig zu tun hat. Die tragfähige Reihenfolge lautet: Geschäftsprozess, dann Anlagen und Systeme, die ihn tragen, dann Netzsegmente und Übergänge, über die diese Systeme erreichbar sind.

Praktisch heißt das, mit der Produktionsleitung drei Fragen zu klären, für die man keine technischen Daten braucht:

• Welche Linien oder Anlagen dürfen wie lange stehen, bevor Liefertermine, Verträge oder Vertragsstrafen greifen? Eine Stundenzahl reicht, ein Eurobetrag ist besser.
• Welche Anlagen sind sicherheitsrelevant (in Bezug auf Safety), also mit Gefahr für Personen, Umwelt oder das Equipment selbst?
• Wo gibt es keine manuelle Rückfallebene mehr, weil Rezepturen, Auftragsdaten oder Qualitätsfreigaben nur noch digital vorliegen?

Aus diesen Antworten entsteht eine Rangfolge der Prozesse. Erst dann werden die Systeme dahinter aus der Perspektive der Erreichbarkeit betrachtet: Von wo aus kann ein Angreifer oder eine Fehlkonfiguration dieses System überhaupt beeinflussen? Diese Frage lässt sich am Netz beantworten, auch wenn man über das Endgerät selbst wenig weiß.

Mit unvollständigen Informationen arbeiten

Passiv erheben statt aktiv scannen

Was im Endgerät steckt, ist oft unbekannt. Was über das Netz läuft, lässt sich dagegen ohne Risiko für die Anlage beobachten. Ein Mirror-Port oder ein TAP am zentralen Produktionsswitch, ein paar Tage Aufzeichnung, dazu die MAC- und ARP-Tabellen der Switches, DHCP-Leases und (falls vorhanden) NetFlow oder sFlow: Damit erhält man ein Bild, welche Adressen mit wem über welche Protokolle sprechen. Dieses Bild ist unvollständig, aber es zeigt zuverlässig die Übergänge, die für die Risikoanalyse zählen: Verbindungen aus dem Office-Netz in die Zellenebene, direkte Internetzugänge aus Anlagen heraus, Fernwartungstunnel, die dauerhaft aufgebaut bleiben.

Annahmen sichtbar machen

Jede Aussage in der Analyse bekommt einen Vermerk, worauf sie beruht: gemessen, aus Dokumentation entnommen, vom Anlagenbetreuer mündlich bestätigt, oder angenommen. Das klingt bürokratisch, ist aber der wichtigste Einzelschritt. Eine Risikobewertung, die auf der Annahme beruht, dass die Verpackungslinie nur mit dem MES spricht, ist etwas anderes als eine, die diese Beziehung im Mitschnitt gesehen hat. Wenn die Annahme später kippt, weiß man sofort, welche Bewertungen neu zu prüfen sind.

Das Unbekannte als eigene Zone behandeln

Geräte, die sich nicht zuordnen lassen (unbekannte MAC-Adressen, Adressbereiche ohne Ansprechpartner, ein Switch im Schaltschrank ohne Management-Zugang) werden nicht ignoriert, sondern als Zone „nicht klassifiziert" geführt. Für diese Zone gilt in der Bewertung die ungünstigste plausible Annahme: kein Patchstand, keine Authentifizierung, erreichbar aus allen angrenzenden Netzen. Das erzeugt bewusst ein hohes Risiko und damit den Anreiz, die Zone entweder aufzuklären oder am Netzübergang so zu begrenzen, dass die Unkenntnis keinen Schaden mehr anrichten kann. Genau hier zahlt sich Netzwerkarchitektur aus: Ein Segment mit restriktiver Zugangsregel ist auch dann sicherer, wenn man nicht weiß, was darin steht.

Bewerten, wenn die Zahlen fehlen

Quantitative Modelle mit Eintrittswahrscheinlichkeiten pro Jahr scheitern in der Produktion regelmäßig daran, dass niemand die Wahrscheinlichkeiten kennt. Die IEC 62443-3-2 setzt deshalb auf Zonen und Conduits. Für jede Zone wird ein tolerierbares Risiko definiert und daraus ein anzustrebendes Security Level abgeleitet. Die Bewertung geschieht qualitativ in wenigen Stufen. Das ist für den Einstieg völlig ausreichend, solange die Stufen konsistent definiert und mit dem Geschäftsprozess verknüpft sind. Der BSI-Standard 200-3 beschreibt einen vergleichbaren Ansatz mit vier Stufen für Häufigkeit und Auswirkung.

Drei Regeln haben sich bewährt:

1. Die Auswirkung wird ausschließlich aus dem Geschäftsprozess abgeleitet, nie aus der Technik. Ein ungepatchter Windows-Rechner an einer Prüfstation, deren Ausfall zwei Tage lang manuell überbrückt werden kann, hat eine geringe Auswirkung.
2. Die Eintrittswahrscheinlichkeit wird über die Erreichbarkeit geschätzt: direkt aus dem Internet, aus dem Office-Netz, nur aus dem Produktionsnetz, nur physisch. Diese Einstufung ist aus dem Netzplan ablesbar und damit auch bei lückenhaftem Wissen über das Endgerät belastbar.
3. Worst-Case-Annahmen werden begrenzt. Wer für jede Lücke den Totalausfall des Werks annimmt, erzeugt eine Liste, in der alles rot ist und nichts mehr priorisierbar. Der realistische Schaden ist der, den der konkrete Netzpfad erlaubt.

Budgetgrenzen als Priorisierungswerkzeug

Ein begrenztes Budget ist kein Hindernis für die Risikoanalyse, sondern ihr eigentlicher Zweck. Ohne Budgetgrenze bräuchte man keine Priorisierung. Die Frage lautet nicht „Was müssten wir alles tun?", sondern „Welche Maßnahme senkt pro eingesetztem Euro das meißte Risiko in den wichtigsten Prozessen?".

Aus der Erfahrung ergibt sich in Produktionsnetzen fast immer dieselbe Reihenfolge:

1. Sichtbarkeit herstellen. Mirror-Port, Flow-Export und eine einfache Auswertung kosten wenig und verbessern jede weitere Entscheidung.
2. Übergänge kontrollieren, nicht Endgeräte härten. Eine Firewall oder eine ACL zwischen Office und Produktion schützt hundert Geräte gleichzeitig; ein Firmware-Update schützt eines und braucht ein Wartungsfenster. Häufig reicht der vorhandene Layer-3-Switch mit ACLs und VLANs, bevor neue Hardware nötig wird.
3. Fernzugriffe bündeln. Ein einziger, protokollierter Fernwartungszugang mit Freischaltung durch den Betreiber/Maschinenbetreiber ersetzt ein Dutzend Herstellerlösungen mit Dauertunnel.
4. Wiederanlauf sichern. Gesicherte Steuerungsprogramme, Rezepturen und Konfigurationen der Netzkomponenten, offline abgelegt und einmal probehalber eingespielt. Das senkt die Auswirkung fast aller Szenarien auf einmal.

Was dabei bewusst nach hinten rutscht: Gerätehärtung an Anlagen mit geringer Prozessrelevanz, Ablösung alter Steuerungen allein aus Sicherheitsgründen, Monitoring-Plattformen mit Lizenzkosten, bevor die Grundstruktur steht. Diese Punkte sind nicht falsch, sie sind nur nicht zuerst dran.

Restrisiko benennen und tragen lassen

Was nach der Budgetentscheidung offen bleibt, ist das Restrisiko. Es verschwindet nicht dadurch, dass es nicht finanziert wird. Es gehört mit Prozess, Szenario, geschätzter Auswirkung und dem Grund für die Zurückstellung in ein Dokument, das die Geschäftsleitung unterschreibt. Das ist kein Formalismus: § 38 BSIG macht die Billigung und Überwachung der Risikomanagementmaßnahmen zur Aufgabe der Leitungsebene, und ein Auditor fragt nicht nur, was umgesetzt wurde, sondern warum das andere nicht.

Aus Sicht des Technikers hat dieses Dokument einen zweiten Nutzen: Es verlagert die Entscheidung dorthin, wo sie hingehört. Ob ein Stillstand von acht Stunden an der Linie drei akzeptabel ist, kann und soll die IT nicht allein beantworten. Sie liefert die technische Einschätzung, welche Pfade zu diesem Stillstand führen und was deren Schließung kostet. Die Abwägung gegen Liefertermine und Vertragsstrafen trifft der Betrieb.

Fortschreiben statt neu beginnen

Die erste Analyse ist grob. Das ist in Ordnung, solange sie einen klaren Zyklus hat. Die als angenommen markierten Aussagen werden nach und nach durch Messungen ersetzt, die Zone „nicht klassifiziert" schrumpft mit jedem Werksrundgang, und die Bewertung wird bei jedem Umbau, jeder neuen Anlage und jeder Änderung an Netzübergängen angepasst. Wer das quartalsweise in einer Stunde mit Produktionsleitung und Instandhaltung durchgeht, hat nach einem Jahr ein Bild, das mit einem großen Einmalprojekt nie entstanden wäre – und eine Dokumentation, die jeder Prüfer als gelebtes Risikomanagement erkennt.

Die Kernaussage bleibt: Unvollständige Informationen und knappe Budgets sind nicht das Hindernis für eine Risikoanalyse in der Produktion, sondern ihre Randbedingungen. Wer die Bewertung am Geschäftsprozess aufhängt, die Erreichbarkeit über das Netz als Maßstab nimmt und Übergänge vor Endgeräten absichert, kommt mit dem, was da ist, zu Entscheidungen, die vor der Geschäftsleitung und vor dem Prüfer standhalten.