OT-Asset-Inventar erstellen: Praxischeckliste für Produktionsunternehmen

Praxisorientierte Einordnung zu OT-Asset-Inventar erstellen: Praxischeckliste für Produktionsunternehmen: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für OT-Security aufbauen.

Ein belastbares OT-Asset-Inventar ist keine exportierte Geräteliste aus einem Netzwerkwerkzeug. Es ist ein Arbeitsmodell der Produktion: Es zeigt, welche technischen Komponenten einen physischen Prozess steuern, welche Kommunikation dafür notwendig ist, wer Änderungen verantwortet und welche Folgen ein Ausfall oder eine Manipulation hätte. Erst mit diesem Zusammenhang lassen sich Schutzmaßnahmen priorisieren, Wartungszugänge kontrollieren und Störungen sicher untersuchen.

Gerade in gewachsenen Werken ist diese Transparenz selten vollständig. Anlagen wurden über Jahre erweitert, Maschinenbauer greifen über unterschiedliche Fernwartungswege zu und ältere Steuerungen lassen sich nicht ohne Produktionsrisiko aktiv scannen. Die Lösung ist deshalb kein einmaliger Discovery-Lauf, sondern ein abgestimmtes Vorgehen aus Dokumentenprüfung, passiver technischer Erfassung und Interviews mit Betrieb, Instandhaltung und Automatisierung. Dieser Leitfaden zeigt, wie Produktionsunternehmen daraus ein nutzbares Inventar aufbauen.

Warum eine klassische IT-Inventarliste für OT nicht genügt

Ein IT-Inventar beantwortet typischerweise Fragen nach Gerät, Betriebssystem, Eigentümer und Patchstand. In der OT fehlen damit entscheidende Zusammenhänge. Eine SPS kann technisch alt erscheinen und dennoch für einen sicheren Prozess unverzichtbar sein. Ein Engineering-Notebook ist vielleicht nur stundenweise verbunden, besitzt aber weitreichende Änderungsrechte. Ein scheinbar unkritischer Datenkonzentrator kann die einzige Verbindung zwischen Produktionslinie und Leitsystem darstellen.

NIST SP 800-82 Rev. 3 betont deshalb die besonderen Anforderungen industrieller Steuerungssysteme: Verfügbarkeit, sichere Prozesszustände, Echtzeitverhalten und Auswirkungen auf Menschen oder Umwelt verändern die Risikobewertung. Ein OT-Inventar muss diese Bedingungen abbilden. Es soll nicht nur zählen, sondern Entscheidungen ermöglichen. Dazu gehören mindestens die Fragen, welche Funktion ein Asset im Prozess erfüllt, wie es kommuniziert, wie Änderungen erfolgen und welche betrieblichen Folgen bei Ausfall entstehen.

Auch die gemeinsame OT-Inventar-Empfehlung von CISA, BSI und weiteren Behörden aus dem Jahr 2025 betrachtet das Inventar als Grundlage für Architektur, Schwachstellenmanagement und Reaktion auf Vorfälle. Das ist ein wichtiger Perspektivwechsel: Vollständigkeit allein ist kein Erfolgskriterium. Ein Inventar ist dann wertvoll, wenn operative und sicherheitsbezogene Teams dieselbe belastbare Sicht auf die Anlage nutzen.

Mit dem Produktionsprozess beginnen – nicht mit dem Netzwerk

Der schnellste Weg zu einem unbrauchbaren Inventar ist der Versuch, sofort jedes Gerät eines gesamten Standorts zu erfassen. Besser ist ein prozessorientierter Scope. Wählen Sie eine konkrete Linie, Anlage oder Versorgungsfunktion und beschreiben Sie zunächst deren Zweck, Betriebsgrenzen und Abhängigkeiten. Erst danach ordnen Sie technische Komponenten zu.

Für den Start bewährt sich ein zweistündiger Workshop mit Produktionsleitung, Instandhaltung, Automatisierung, lokaler IT und Informationssicherheit. Auf einem vereinfachten Prozessbild werden Materialfluss, Steuerungsstufen, Bedienplätze, Qualitätskontrollen und externe Verbindungen markiert. Wichtig sind auch Hilfsmedien wie Energie, Druckluft, Kühlung oder industrielle Netzzeit. Sie werden in IT-zentrierten Erhebungen leicht übersehen, können aber den gesamten Wiederanlauf bestimmen.

Das Ergebnis des Workshops ist keine fertige Liste, sondern eine Erhebungskarte. Sie legt fest, welche Schaltschränke, Netzsegmente, Leitsysteme, Engineering-Arbeitsplätze und Dienstleisterzugänge untersucht werden. Gleichzeitig benennt sie einen fachlichen Eigentümer. Diese Zuordnung verhindert, dass die Inventarisierung zu einem isolierten Security-Projekt wird, dessen Daten nach wenigen Monaten veralten.

Das minimale Datenmodell für ein belastbares OT-Inventar

Unternehmen beginnen häufig mit zu vielen Feldern. Das bremst die Erfassung und führt zu Lücken. Sinnvoller ist ein verbindlicher Mindestdatensatz, der anschließend risikobasiert erweitert wird. Für jedes Asset sollten mindestens folgende Informationen vorliegen:

Eindeutige Identität: interne Asset-ID, Hersteller, Modell, Seriennummer und – soweit sicher feststellbar – Firmware- oder Softwarestand.
Physischer und logischer Ort: Standort, Halle, Linie, Schaltschrank sowie Netzwerkzone und relevante Adressierung.
Prozessfunktion: verständliche Beschreibung dessen, was das Asset steuert, überwacht oder absichert.
Verantwortung: fachlicher Eigentümer, technische Betreuung und zuständiger externer Dienstleister.
Kommunikation: notwendige Gegenstellen, Protokolle, Ports, Datenrichtung und Zweck der Verbindung.
Zugriffswege: lokale Bedienung, Engineering-Zugang, Fernwartung, verwendete Konten und Freigabeverfahren.
Kritikalität: Folgen für Sicherheit, Umwelt, Qualität, Lieferfähigkeit und Wiederanlauf bei Ausfall oder Manipulation.
Lebenszyklus: Inbetriebnahme, Supportstatus, Ersatzteilstrategie, geplante Ablösung und bekannte Einschränkungen.

Zusätzlich sollte jede Information eine Quelle und ein Prüfdatum besitzen. „Firmwarestand unbekannt“ ist dabei besser als eine scheinbar präzise, aber ungeprüfte Angabe. Durch den Herkunftsnachweis lässt sich später unterscheiden, ob ein Wert aus einer passiven Beobachtung, einem Typenschild, einer Herstellerdokumentation oder einer Aussage im Interview stammt.

Drei Erhebungswege kombinieren

Keine einzelne Methode liefert in industriellen Umgebungen ein vollständiges und zugleich sicheres Bild. Ein praxistaugliches Vorgehen kombiniert dokumentenbasierte, passive und gezielt manuelle Erhebung.

1. Dokumente und vorhandene Daten auswerten

Beginnen Sie mit Netzplänen, Stromlaufplänen, Stücklisten, Wartungsverträgen, Lieferantendokumentationen, Backup-Verzeichnissen und Change-Protokollen. Auch Einkaufs- und Ersatzteildaten können Hinweise auf Komponenten geben, die im Netz nicht dauerhaft sichtbar sind. Diese Quellen sind oft veraltet, liefern aber die notwendige Ausgangshypothese. Jede Abweichung zwischen Plan und Realität wird als Klärungspunkt dokumentiert.

2. Netzwerkkommunikation passiv beobachten

Passive Sensorik kann Geräte, Protokolle und Kommunikationsbeziehungen erkennen, ohne Pakete aktiv an Steuerungen zu senden. Sie eignet sich besonders für dauerhaft verbundene Komponenten. Die Platzierung der Sensoren entscheidet jedoch über die Sichtbarkeit. Ein Sensor an der IT/OT-Grenze sieht nicht automatisch die Kommunikation innerhalb einer Maschinenzelle. Vor der Einführung sollte deshalb festgelegt werden, welche Switches Spiegelports bereitstellen, wie lange beobachtet wird und wer Auffälligkeiten validiert.

3. Vor Ort verifizieren

Nicht vernetzte Sicherheitseinrichtungen, saisonal betriebene Anlagen, serielle Verbindungen und nur zeitweise angeschlossene Engineering-Systeme bleiben technisch leicht unsichtbar. Eine strukturierte Begehung ergänzt deshalb Typenschilder, Schrankzuordnung, physische Schnittstellen und tatsächlich verwendete Wartungsgeräte. Fotos können hilfreich sein, müssen aber wegen möglicher sensibler Anlageninformationen kontrolliert gespeichert und eindeutig zugeordnet werden.

Aktive Scans sind nicht grundsätzlich verboten, dürfen aber nie unkoordiniert erfolgen. Vor jedem Einsatz sind Herstellerfreigabe, Anlagenzustand, Wartungsfenster, Scanprofil, Abbruchkriterien und Rückfallplan zu klären. Für empfindliche Altkomponenten kann selbst eine vermeintlich harmlose Abfrage unerwünschte Zustandsänderungen auslösen.

Kommunikationsbeziehungen als Teil des Inventars erfassen

Eine Liste sagt, welche Assets existieren. Erst die Kommunikationsmatrix zeigt, wie sich ein Angreifer oder eine Fehlkonfiguration durch die Umgebung bewegen könnte. Deshalb sollten Verbindungen nicht als Freitext an einzelnen Geräten abgelegt werden, sondern als eigenständige Beziehungen: Quelle, Ziel, Protokoll, Port, Richtung, betrieblicher Zweck, Freigabeverantwortlicher und erwartete Betriebszeit.

Aus dieser Matrix entsteht eine belastbare Soll-Kommunikation. Sie ermöglicht später Firewall-Regeln nach dem Prinzip „deny by default“, ohne notwendige Prozessdaten versehentlich zu blockieren. CISA empfiehlt, Verbindungen zwischen IT und OT über kontrollierte Zwischenstufen wie DMZ, Jump Host oder Bastion Host zu führen und nur ausdrücklich benötigte Kommunikation zuzulassen. In der Praxis ist das Inventar damit der Vorläufer einer sicheren Segmentierung – nicht deren Nebenprodukt.

Besondere Aufmerksamkeit verdienen Fernzugänge. Dokumentieren Sie nicht nur VPN-Gateways, sondern auch herstellerspezifische Router, Mobilfunkverbindungen, Cloud-Portale, Remote-Desktop-Werkzeuge und temporäre Ausnahmen. Für jeden Weg muss erkennbar sein, wer ihn freigibt, wie Identität geprüft wird, ob Sitzungen protokolliert werden und wie der Zugang nach Ende der Wartung geschlossen wird.

Kritikalität anhand von Auswirkungen bewerten

Eine reine Einteilung in „hoch, mittel, niedrig“ bleibt ohne Kriterien beliebig. Bewerten Sie stattdessen getrennte Auswirkungsdimensionen. Ein Asset kann geringe finanzielle Auswirkungen haben, aber eine hohe Bedeutung für Personensicherheit. Ein anderes verursacht keinen unmittelbaren Stillstand, ist jedoch für den kontrollierten Wiederanlauf unverzichtbar.

Bewährt haben sich fünf Perspektiven: mögliche Gefährdung von Menschen, Umweltfolgen, Produktions- und Lieferausfall, Qualitätsverlust sowie regulatorische oder vertragliche Auswirkungen. Ergänzend wird die Wiederbeschaffungs- und Wiederherstellungszeit betrachtet. Proprietäre Hardware mit zwölf Monaten Lieferzeit kann kritischer sein als ein leistungsstärkeres, aber kurzfristig ersetzbares Standardsystem.

Die Bewertung sollte in einem moderierten Gespräch erfolgen und eine nachvollziehbare Begründung enthalten. Formulierungen wie „Ausfall stoppt Linie 3 innerhalb von 15 Minuten; manueller Betrieb maximal zwei Stunden; Wiederanlauf erfordert Hersteller“ sind für Priorisierungen deutlich wertvoller als eine alleinstehende rote Ampel.

Vom Inventar zu konkreten Sicherheitsentscheidungen

Der Nutzen zeigt sich, wenn das Inventar in operative Prozesse eingebunden wird. Bei einer neuen Schwachstelle kann das Team sofort feststellen, welche Modelle betroffen sind, welche Prozessfolgen ein Eingriff hätte und welcher Eigentümer entscheidet. Bei einem Sicherheitsvorfall liefert die Kommunikationsmatrix erwartete Gegenstellen und hilft, ungewöhnliche Verbindungen einzuordnen. In Beschaffungsprojekten wird früh sichtbar, welche Support- und Fernwartungsanforderungen fehlen.

Mindestens fünf Prozesse sollten auf das Inventar zugreifen: Change Management, Schwachstellenmanagement, Backup und Recovery, Incident Response sowie Lieferantensteuerung. Jede Änderung an Netz, Firmware, Fernzugang oder Komponentenbestand muss eine Aktualisierung auslösen. Zusätzlich sind periodische Abgleiche erforderlich, weil nicht jede Veränderung den formalen Änderungsweg nimmt.

Eine einfache Qualitätskennzahl ist der Anteil kritischer Assets mit verifiziertem Eigentümer, dokumentierter Kommunikation, bekanntem Supportstatus und geprüftem Wiederherstellungsweg. Diese Aussage ist steuerungsrelevanter als die bloße Zahl inventarisierter Geräte.

Ein realistischer 90-Tage-Einstieg

Tag 1 bis 15 – Scope und Verantwortungen: Pilotanlage wählen, Prozessgrenzen festlegen, bestehende Quellen sammeln und den fachlichen Eigentümer benennen. Gleichzeitig werden Regeln für sensible Daten, Zugriff und Ablage vereinbart.

Tag 16 bis 40 – Erheben und abgleichen: Dokumente auswerten, passive Sichtbarkeit einrichten und Begehungen durchführen. Unklare Geräte oder Verbindungen kommen in eine separate Klärungsliste, statt mit Annahmen gefüllt zu werden.

Tag 41 bis 60 – Zusammenhänge validieren: Prozessfunktion, Kommunikationszweck, Fernzugänge und Auswirkungen gemeinsam mit Betrieb und Instandhaltung prüfen. Kritische Abhängigkeiten werden in einem vereinfachten Architekturmodell sichtbar gemacht.

Tag 61 bis 75 – Sicherheitslücken ableiten: Unkontrollierte Zugänge, nicht benötigte Verbindungen, unbekannte Supportstände, fehlende Backups und Single Points of Failure priorisieren. Maßnahmen erhalten Verantwortliche und realistische Betriebsfenster.

Tag 76 bis 90 – Betrieb etablieren: Aktualisierung an Change- und Beschaffungsprozesse anbinden, Qualitätskennzahlen festlegen und den nächsten Anlagenbereich auswählen. Erst jetzt wird aus der Pilotaufnahme ein skalierbarer Inventarprozess.

Typische Fehler und ihre praktische Korrektur

Ein Werkzeug wird mit dem Prozess verwechselt: Discovery-Produkte liefern Beobachtungen, aber keine Prozessfunktion, Verantwortung oder Auswirkungsbewertung. Ergänzen Sie technische Daten konsequent durch fachliche Validierung.
Unbekannte Werte werden geschätzt: Kennzeichnen Sie Unsicherheit ausdrücklich und führen Sie eine Klärungsliste mit Fälligkeit. Falsche Präzision gefährdet spätere Entscheidungen.
Nur IP-fähige Geräte werden erfasst: Beziehen Sie serielle Komponenten, Safety-Systeme, Engineering-Laptops, Wechselmedien und nicht dauerhaft verbundene Wartungsgeräte ein.
Das Inventar bleibt ein Security-Dokument: Geben Sie Betrieb und Instandhaltung einen direkten Nutzen, etwa bessere Ersatzteilplanung, schnellere Störungsanalyse und klare Dienstleisterkontakte.
Es gibt keinen Pflegeauslöser: Verknüpfen Sie Aktualisierungen mit Change, Beschaffung, Wartung, Abnahme und Außerbetriebnahme. Ein jährlicher Gesamtcheck allein reicht in dynamischen Umgebungen nicht.
Zu großer Startumfang: Erproben Sie Datenmodell und Arbeitsablauf an einer repräsentativen Anlage. Ein vollständig gepflegter Pilot ist wertvoller als eine standortweite Liste mit ungeklärten Angaben.

Praxischeckliste für den Projektstart

Eine klar abgegrenzte Pilotanlage und deren geschäftliche Funktion sind benannt.
Produktion, Instandhaltung, Automatisierung, IT und Informationssicherheit sind beteiligt.
Für Inventardaten bestehen Verantwortlicher, Ablageort und Zugriffsregeln.
Der Mindestdatensatz und der Umgang mit unbekannten Werten sind verbindlich definiert.
Vorhandene Pläne, Stücklisten, Wartungsverträge und Backup-Daten wurden gesammelt.
Passive Beobachtung und Vor-Ort-Erhebung sind aufeinander abgestimmt.
Aktive Prüfungen erfolgen nur nach Risikobewertung und betrieblicher Freigabe.
Kommunikationsbeziehungen und Fernwartungswege werden separat dokumentiert.
Kritikalität wird anhand konkreter Auswirkungen und Wiederherstellbarkeit begründet.
Change-, Beschaffungs-, Incident- und Schwachstellenprozesse nutzen das Inventar.
Qualitätskennzahlen messen Verlässlichkeit statt nur die Anzahl der Einträge.
Nach dem Pilot ist die Ausweitung auf weitere Linien mit festen Verantwortungen geplant.

Fazit: Transparenz muss im Betrieb funktionieren

Ein OT-Asset-Inventar ist dann belastbar, wenn es die reale Produktion verständlich abbildet und konkrete Entscheidungen beschleunigt. Dafür braucht es mehr als technische Erkennung: Prozesswissen, dokumentierte Kommunikation, klare Eigentümer, nachvollziehbare Kritikalität und einen dauerhaft verankerten Pflegeprozess. Wer klein beginnt, Unsicherheiten sichtbar macht und den betrieblichen Nutzen in den Mittelpunkt stellt, schafft in wenigen Monaten eine Grundlage für Segmentierung, Schwachstellenmanagement und sichere Reaktion auf Vorfälle.

BlackMount unterstützt Produktionsunternehmen bei der strukturierten Bestandsaufnahme, der Entwicklung eines passenden OT-Datenmodells und der Ableitung einer realistischen Schutz-Roadmap. Mehr dazu finden Sie unter OT-Security Beratung.