Das Audit-Problem in OT
Ein Auditor fragt: „Zeigen Sie mir, wer am 3. März auf PLC-14 zugegriffen hat und welche Befehle ausgeführt wurden."
In den meisten OT-Umgebungen ist diese Frage nicht zu beantworten. Die Gründe:
- Gemeinsam genutzte Konten: Bediener melden sich an HMIs mit einem gemeinsamen „Operator"-Konto an. Drei Schichten, zwölf Personen, ein Benutzername.
- VPN-basierter Lieferantenzugang: Der Lieferant verbindet sich über ein Site-to-Site VPN. Das Firewall-Protokoll zeigt eine Verbindung aus dem IP-Bereich des Lieferanten. Es zeigt nicht, welche Person sich verbunden hat oder was sie getan hat.
- Kein Logging auf Befehlsebene: SCADA-Historiker zeichnen Prozesswerte auf. Syslog erfasst Netzwerkereignisse. Keines von beiden protokolliert die spezifischen Befehle, die ein Benutzer an eine PLC gesendet hat, oder die Bildschirme, die er an einem HMI aufgerufen hat.
- Keine Sitzungszuordnung: Selbst wenn Protokolle vorhanden sind, sind sie an IP-Adressen oder gemeinsame Konten gebunden, nicht an authentifizierte Personen.
Diese Lücke ist nicht theoretischer Natur. Sie ist genau die Lücke, die CMMC- und NIS2-Auditoren beanstanden werden.
Was die Vorschriften verlangen
CMMC-Anforderungen
AU.L2-3.3.1 (Audit-Ereignisse): Erstellen und aufbewahren von System-Audit-Protokollen und -Aufzeichnungen, um die Überwachung, Analyse, Untersuchung und Meldung von rechtswidrigen oder unbefugten Systemaktivitäten zu ermöglichen. Mit der CMMC-Frist im Oktober 2026, die eine Zertifizierung durch Dritte erfordert, ist die Erfüllung dieser Anforderung zeitkritisch.
AU.L2-3.3.2 (Audit-Inhalt): Sicherstellen, dass die Aktionen einzelner Systembenutzer eindeutig auf diese Benutzer zurückverfolgt werden können.
AC.L2-3.1.7 (Privilegierte Funktionen): Verhindern, dass nicht privilegierte Benutzer privilegierte Funktionen ausführen, und die Ausführung solcher Funktionen in Audit-Protokollen erfassen.
Das Schlüsselwort in 3.3.2 ist einzelner Benutzer. Gemeinsam genutzte Konten erfüllen diese Anforderung nicht. IP-adressbasiertes Logging erfüllt diese Anforderung nicht. Es wird eine benutzer- und sitzungsbezogene Rückverfolgbarkeit benötigt.
NIS2-Anforderungen
Artikel 21 schreibt Maßnahmen zum Cybersicherheitsrisikomanagement vor, einschließlich der Behandlung von Vorfällen. Konkret:
- Organisationen müssen Maßnahmen zur Erkennung, Reaktion und Wiederherstellung bei Vorfällen implementieren
- Nachweise müssen aufbewahrt und verfügbar sein für die Analyse nach einem Vorfall
- Maßnahmen zur Lieferkettensicherheit müssen die Überwachung des Zugangs Dritter umfassen
Wenn eine Lieferantensitzung zu einer PLC eine Prozessstörung verursacht, verlangt NIS2, dass genau rekonstruiert werden kann, was passiert ist, wer es getan hat und wann.
Wie Sitzungsaufzeichnung funktioniert
Sitzungsaufzeichnung in einer Proxy-basierten Architektur erfasst den vollständigen Inhalt jeder Verbindung zwischen einem Benutzer und einem OT-Asset. Der Proxy fängt die Sitzung ab, sodass die Aufzeichnung transparent erfolgt – ohne Software auf dem Endpunkt.
Die Aufzeichnungskette:
- Benutzer authentifiziert sich am Access Gate mit MFA. Die Identität wird verifiziert und an die Sitzung gebunden.
- Richtlinie wird ausgewertet. Das System prüft, ob dieser Benutzer berechtigt ist, auf dieses Asset zuzugreifen – zu diesem Zeitpunkt, mit diesem Protokoll.
- Sitzung wird aufgebaut. Der Proxy öffnet eine vermittelte Verbindung zum Zielgerät.
- Vollständige Sitzung wird aufgezeichnet. Bei RDP/VNC-Sitzungen: Bildschirmaufnahme. Bei SSH-Sitzungen: Terminal-Befehle und Ausgaben. Bei Modbus/OPC UA: Befehle und Antworten auf Protokollebene.
- Sitzung wird indiziert. Die Aufzeichnung wird mit Metadaten gespeichert: Benutzeridentität, Ziel-Asset, Protokoll, Startzeit, Endzeit, Dauer.
Das Ergebnis ist ein durchsuchbares, zuordenbares Protokoll jeder Interaktion mit jedem OT-Asset.
Sitzungsaufzeichnung und Compliance-Anforderungen
| Compliance-Anforderung | Control-ID | Was Auditoren verlangen | Wie Sitzungsaufzeichnung dies erfüllt |
|---|---|---|---|
| Erstellung von Audit-Ereignissen | CMMC AU.L2-3.3.1 | Protokolle aller Zugriffe auf CUI-Systeme | Jede Sitzung wird mit Benutzer, Asset, Protokoll und Zeitstempel protokolliert |
| Individuelle Rückverfolgbarkeit | CMMC AU.L2-3.3.2 | Nachweis, dass Aktionen auf Einzelpersonen zurückgeführt werden können | MFA-authentifizierte Benutzer sind an aufgezeichnete Sitzungen gebunden |
| Protokollierung privilegierter Funktionen | CMMC AC.L2-3.1.7 | Protokolle von Administrator-/Engineering-Aktionen | Schreiboperationen und Konfigurationsänderungen werden auf Protokollebene erfasst |
| Durchsetzung minimaler Rechte | CMMC AC.L2-3.1.5 | Nachweis von Zugriffsbeschränkungen | Richtlinien-Engine beschränkt Zugriff pro Benutzer, Asset und Operation |
| Erkennung und Reaktion bei Vorfällen | NIS2 Artikel 21(b) | Verfahren zur Vorfallbehandlung mit Nachweisen | Aufgezeichnete Sitzungen liefern forensische Beweise für die Rekonstruktion von Vorfällen |
| Beweissicherung | NIS2 Artikel 21 | Aufbewahrte Protokolle für die Analyse nach Vorfällen | Sitzungsaufzeichnungen werden mit konfigurierbarer Aufbewahrungsdauer und Manipulationsschutz gespeichert |
| Überwachung der Lieferkette | NIS2 Artikel 21(d) | Zugriffskontrollen für Lieferanten und Audit-Trail | Sitzungen Dritter werden mit derselben Genauigkeit aufgezeichnet wie interne Sitzungen |
| Berichterstattung zum Risikomanagement | NIS2 Artikel 21(a) | Nachweisbare Sicherheitskontrollen | Dashboards zur Sitzungsaufzeichnung zeigen Zugriffsmuster und Richtliniendurchsetzung |
Was Sitzungsaufzeichnung je Protokoll erfasst
Verschiedene Protokolle liefern unterschiedliche Arten von Audit-Daten:
| Protokoll | Sitzungstyp | Was aufgezeichnet wird |
|---|---|---|
| RDP / VNC | HMI-Zugriff, Engineering-Workstations | Vollständige Bildschirmaufnahme (Video), Tastenanschläge, Zwischenablage-Aktivität |
| SSH | Linux-basierte Controller, Netzwerkgeräte | Terminal-Befehle, Ausgaben, Dateiübertragungen |
| Modbus TCP | PLC-Kommunikation | Funktionscodes (Lesen vs. Schreiben), Registeradressen, Werte |
| OPC UA | SCADA zu PLC, Historiker-Verbindungen | Knotenzugriff, Lese-/Schreiboperationen, Browse-Aktivität |
| HTTP/HTTPS | Webbasierte HMIs, Geräteverwaltung | URLs, Formularübermittlungen, API-Aufrufe |
Diese Granularität auf Protokollebene unterscheidet Sitzungsaufzeichnung von Netzwerk-Logging. Ein Firewall-Protokoll zeigt, dass eine Modbus TCP-Verbindung stattgefunden hat. Sitzungsaufzeichnung zeigt, dass Benutzer X einen Write Single Register-Befehl (Funktionscode 06) an Register 40001 mit dem Wert 1 gesendet hat und damit den Sollwert einer Pumpe geändert hat.
Praxisleitfaden zur Einführung
Die Einführung von Sitzungsaufzeichnung in einer OT-Umgebung muss nicht auf einmal erfolgen. Ein phasenweiser Ansatz reduziert das Risiko und schafft organisatorisches Vertrauen.
Phase 1: Lieferanten-Fernzugang (Woche 1–2)
Hier beginnen. Lieferantensitzungen sind das Ziel mit dem höchsten Risiko und der höchsten Sichtbarkeit.
- Gesamten Lieferanten-Fernzugang über den Access Gate leiten
- Sitzungsaufzeichnung für alle Lieferantensitzungen aktivieren
- MFA für jede Lieferantenverbindung vorschreiben
- Aufbewahrungsrichtlinie festlegen (mindestens 90 Tage für CMMC, NIS2-Anforderungen berücksichtigen)
Warum zuerst: Lieferanten greifen auf kritische Assets zu, häufig mit erhöhten Rechten und über gemeinsam genutzte Zugangsdaten. Das ist die Lücke, die Auditoren zuerst suchen.
Phase 2: Interner Engineering-Zugang (Woche 3–4)
Aufzeichnung auf interne Ingenieure und Bediener ausweiten, die auf PLCs und HMIs zugreifen.
- Benutzerspezifische Zugriffsrichtlinien definieren (wer auf welche Assets zugreifen darf)
- Aufzeichnung für Engineering-Workstation-Sitzungen aktivieren
- Protokollbewusste Richtlinien implementieren (z. B. Lesen erlauben, Schreiben während der Produktionszeiten sperren)
Phase 3: Vollständige Abdeckung (Monat 2–3)
Auf alle OT-Zugriffspfade ausweiten.
- Alle Sitzungen zu SCADA-Servern und Historikern aufzeichnen
- Sitzungsprotokolle zur Korrelation in SIEM integrieren
- Compliance-Berichte erstellen, die Sitzungen den Kontrollanforderungen zuordnen
- Mock-Audit mit aufgezeichneten Sitzungen als Nachweis durchführen
Was von Auditoren zu erwarten ist
Wenn ein CMMC-Assessor oder NIS2-Auditor Ihre OT-Umgebung prüft, wird er Folgendes verlangen:
- Zugriffsprotokolle, die zeigen, wer wann auf welche Systeme zugegriffen hat
- Nachweis der individuellen Zuordnung (keine gemeinsam genutzten Konten)
- Nachweis der Durchsetzung minimaler Rechte (Benutzer auf autorisierte Assets beschränkt)
- Nachweise zur Vorfallreaktion (Fähigkeit, den Ablauf bei einem Sicherheitsereignis zu rekonstruieren)
Sitzungsaufzeichnung liefert eine einzige, durchsuchbare Nachweisquelle für alle vier Punkte. Anstatt Firewall-Protokolle, VPN-Protokolle, SCADA-Historiker-Einträge und Windows-Ereignisprotokolle zusammenzuführen, verweisen Sie den Auditor auf eine aufgezeichnete Sitzung mit dem Namen des Benutzers, dem Ziel-Asset und dem vollständigen Inhalt der Interaktion.
OT-Zugang sollte nicht als Netzwerkproblem behandelt werden, sondern als Identitätsproblem mit Nachweisen auf Sitzungsebene. Für einen tieferen Einblick, warum eine Proxy-basierte Architektur die richtige Grundlage für Sitzungsaufzeichnung in OT ist, beginnen Sie dort. Das ist es, was Auditoren erwarten, und das ist es, was Compliance-Frameworks verlangen.
Weitere CMMC-Ressourcen, Fallstudien und Implementierungsleitfäden finden Sie im CMMC Compliance for On-Premise hub.
Weitere NIS2-Ressourcen, souveräne Bereitstellungsoptionen und Compliance-Leitfäden finden Sie im NIS2 Compliance for On-Premise OT hub.
