ITAM vs. OTAM im Betrieb

Was unterscheidet ITAM und OTAM im Betrieb?

Die folgende Abgrenzung ist ein Arbeitsmodell für Security und Betrieb, keine normative Definition. ITAM konsolidiert den technischen und organisatorischen Kontext von IT-Assets. OTAM erweitert ihn um den physischen Prozess. CISA verlangt für OT deshalb neben dem Inventar eine Taxonomie nach Funktion oder Kritikalität sowie dokumentierte Kommunikationswege und Abhängigkeiten.

Welche Daten gehören in ein belastbares OT-Asset-Inventar?

CISA priorisiert für jedes OT-Asset 14 Attribute, darunter Kritikalität, Rolle oder Typ, Hersteller, Modell, Betriebssystem, Hostname, IP- und MAC-Adresse, Standort, Protokolle, Ports und Dienste, Benutzerkonten sowie Logging. Diese Felder bilden den technischen Kern. Für den Betrieb müssen Herkunft, Beziehungen und Verantwortlichkeit hinzukommen.

• Identität: eindeutige Asset-Nummer, Hersteller, Modell, Hostname sowie IP- und MAC-Adresse
• Technischer Zustand: Betriebssystem, Firmware oder Software, aktive Protokolle, Ports und Dienste
• Betriebskontext: Rolle oder Typ, physischer Standort, Zone, Kommunikationswege und Prozessabhängigkeiten
• Security-Kontext: Kritikalität, Logging, Benutzerkonten und vorhandene technische Kontrollen
• Verantwortung: zuständige Person, technischer Betreiber, Instandhaltung und beteiligte Dienstleister
• Evidenz: Datenquelle, Erfassungszeitpunkt, Änderungsverlauf und Status der Validierung

Der BSI-Anforderungskatalog ergänzt für relevante KRITIS-Assets eine eindeutige Verantwortungszuweisung über den gesamten Lebenszyklus und eine einheitliche, risikobasierte Klassifikation. Ein gemeinsames IT-/OT-Modell sollte diese organisatorischen Felder deshalb genauso belastbar behandeln wie technische Merkmale.

Wie wird ein OT-Asset-Inventar nach CISA aufgebaut?

CISA beschreibt einen fünfstufigen Prozess vom festgelegten Scope bis zum Lebenszyklusmanagement. Das Ergebnis ist kein einmaliger Scan, sondern ein gepflegtes Inventar mit validierter Taxonomie.

1. Scope und Ziele definieren

   Governance, Rollen und Programmgrenzen werden festgelegt. Zonen, Standorte und Systeme gehören ebenso zum Scope wie eine klare Definition, was als Asset gilt.

2. Assets und Attribute erfassen

   Physische Inspektion und logische Bestandsaufnahme werden mit digitalen und netzwerkbasierten Informationen kombiniert. Auch dokumentierte Assets und Infrastrukturabhängigkeiten werden einbezogen.

3. Taxonomie und Beziehungen aufbauen

   Assets werden nach Funktion oder Kritikalität klassifiziert. Kommunikationswege, Zonen, Prozessabhängigkeiten, Namenskonventionen sowie Rollen von Betreibern und Dienstleistern werden dokumentiert.

4. Daten validieren und verwalten

   Inventardaten werden auf Richtigkeit und Vollständigkeit geprüft, Beziehungen visualisiert und durch Herstellerunterlagen, Wartungsdaten, Konfigurationen und Betriebsdaten ergänzt.

5. Lebenszyklus integrieren

   Beschaffung, Bereitstellung, Inbetriebnahme, Wartung und Außerbetriebnahme werden mit dem Inventar verknüpft. Hinzugefügte oder entfernte Geräte müssen auch bei Notfalländerungen zu einem Inventar-Update führen.

Welche Anforderungen ergänzt der BSI-Katalog für KRITIS?

Der BSI-Katalog konkretisiert die Kriterien des § 8a Absatz 1 und 1a BSIG für KRITIS-Betreiber und dient als Orientierung bei der Auswahl geeigneter Prüfmaßstäbe. Das BSI weist zugleich darauf hin, dass die einzelnen Kriterien nicht automatisch verbindlich sind. Ihre Angemessenheit ist im jeweiligen Betreiberkontext zu bewerten.

• Inventarqualität (AM-01): vollständig, richtig, aktuell und konsistent, Änderungen nachvollziehbar historisieren und fehlende Automatisierung durch regelmäßige manuelle Prüfungen ausgleichen
• Verantwortlichkeit (AM-02): jedes relevante Asset einer verantwortlichen Person auf Betreiberseite zuweisen und über den gesamten Lebenszyklus korrekt inventarisieren und klassifizieren
• Klassifikation (AM-05): Informationen und Assets einheitlich auf Basis von Risikoanalyse und Folgeabschätzung klassifizieren
• Netztopologie (KOS-06): Architektur aktuell und nachvollziehbar dokumentieren, einschließlich unterschiedlicher Umgebungen, Netzsegmente und Datenflüsse
• Änderungsmanagement (BEI-03 bis BEI-10): Risiken bewerten, Änderungen kategorisieren und priorisieren, Tests und Freigaben dokumentieren, Rollback ermöglichen und Notfalländerungen nachvollziehen

Wie werden ITAM und OTAM praktisch zusammengeführt?

Ein gemeinsames Modell vereinheitlicht Identität, Evidenz und Qualitätsregeln. IT und OT behalten jedoch ihre eigenen Erfassungswege, Freigaben und Betriebsgrenzen.

1. Mit einem belastbaren Scope beginnen

   Einen kritischen Dienst, Standort, eine Zone oder Produktionslinie auswählen, den Asset-Begriff festlegen und Verantwortliche benennen.

2. Quellen getrennt erfassen

   IT-Systemquellen, physische Bestandsaufnahme, Netzwerkdaten, Engineering-Unterlagen und Wartungsdaten liefern Beobachtungen mit Herkunft und Zeitpunkt.

3. Identitäten und Beziehungen abgleichen

   Dubletten und Widersprüche werden aufgelöst. Zonen, Kommunikationswege, Dienste und Prozessabhängigkeiten bleiben als Beziehungen erhalten.

4. Verantwortung und Klassifikation ergänzen

   Jedes relevante Asset erhält eine zuständige Person, eine betriebliche Rolle und eine nachvollziehbare Kritikalitäts- oder Risikoklassifikation.

5. Änderungen zu Inventarereignissen machen

   Inbetriebnahme, Wartung, Austausch und Außerbetriebnahme aktualisieren das Inventar. Regelmäßige Validierung prüft Vollständigkeit, Richtigkeit, Aktualität und Konsistenz.