Ein Data-Governance-Audit durchführen: von der Policy zum Nachweis auf dem Shop Floor

# Ein Data-Governance-Audit durchführen: von der Policy zum Nachweis auf dem Shop Floor

Ein Werksleiter in Ohio ruft das Dashboard des MES (Manufacturing Execution System) auf und findet dort drei Jahre an Operator-Login-Datensätzen im aktiven Speicher, vier Jahre über die Aufbewahrungsfrist hinaus, die die eigene Policy des Unternehmens festgelegt hatte. Gelöscht hat sie niemand, weil niemand für die Prüfung zuständig war. Genau diese eine Lücke, gefunden bei einem Routine-Audit, macht aus einer sauber aussehenden Governance-Policy eine echte Haftungsfrage.

Data-Governance-Policies lesen sich gut in einem Board-Deck. Der eigentliche Test ist, ob sie den Kontakt mit einem Shop Floor überleben, der in drei Schichten läuft, drei PLC-Anbieter (Programmable Logic Controller) einsetzt und eine Kontraktorenliste hat, die sich jedes Quartal ändert. Ein Audit ist der Weg, das herauszufinden, bevor eine Aufsichtsbehörde, ein Kunde oder ein Angreifer es tut.

Warum Governance-Audits in der Fertigung anders sind

Fertigungsdaten liegen an mehr Orten als Bürodaten. Sie auditieren:

• MES-Datensätze (Produktionszählungen, Qualitätssperren, Operator-IDs, Zeitstempel)
• SCADA/PLC-Logs (Supervisory Control and Data Acquisition / Programmable Logic Controller) von Maschinensteuerungen
• ERP-Systeme (Enterprise Resource Planning) mit Lieferanten- und Kundendaten
• IIoT-Sensordatenströme (Industrial Internet of Things) aus Predictive-Maintenance-Systemen
• Zugangskontrollsysteme für Badge- und Netzwerkzugang

Jedes System hat andere Owner, andere Aufbewahrungsregeln und oft andere Anbieter, teilweise jahrzehntealte Anlagen, die nie mit Blick auf Datenschutz entworfen wurden. Ein PLC von 2015, der eine Stanzpresse steuert, wurde nicht mit Gedanken an die GDPR gebaut (General Data Protection Regulation, das EU-Datenschutzrecht von 2018).

Der regulatorische Hintergrund, kurz

Sie müssen kein Jurist sein, aber Sie müssen wissen, wogegen ein Audit prüft:

• GDPR (EU, in Kraft seit 2018): regelt personenbezogene Daten von EU-Beschäftigten und -Kunden, einschließlich Operator-Namen, die mit Maschinenlogs verknüpft sind. Verlangt Datenminimierung und definierte Aufbewahrungsfristen.
• CCPA/CPRA (California Consumer Privacy Act / Privacy Rights Act): vergleichbarer Schutz personenbezogener Daten für Betroffene mit Kalifornien-Bezug, relevant, wenn ein US-Hersteller an kalifornische Kunden verkauft oder Einwohner Kaliforniens beschäftigt.
• NIST Cybersecurity Framework (USA, freiwillig, aber weit verbreitet, besonders bei Herstellern mit Verteidigungsbezug): nist.gov/cyberframework legt praktische Kontrollkategorien fest: Identify, Protect, Detect, Respond, Recover.
• IEC 62443: der zentrale internationale Standard speziell für die Sicherheit industrieller Steuerungssysteme (ICS), auf den Auditoren sich beziehen, wenn sie die Netzwerksegmentierung von PLC und SCADA prüfen.
• CMMC (Cybersecurity Maturity Model Certification): Pflicht für Lieferanten des US-Verteidigungsministeriums, zunehmend ein De-facto-Benchmark auch für Hersteller ohne Verteidigungsbezug.

Keines davon sagt Ihnen genau, wie Sie Ihr Werk betreiben sollen. Sie setzen die Messlatte. Im Audit messen Sie Ihr Werk an dieser Messlatte.

Die Audit-Checkliste: drei konkrete Tests

Test 1: MES-Datensätze auf Einhaltung der Aufbewahrungsfristen stichprobenartig prüfen

Ziehen Sie eine Zufallsstichprobe von MES-Datensätzen (etwa 50 Batches aus den letzten zwei Jahren). Prüfen Sie für jeden:

• Existiert eine dokumentierte Aufbewahrungsregel für diesen Datensatztyp (z. B. „Qualitätsaufzeichnungen: 7 Jahre“, „Operator-Login-Logs: 90 Tage“)?
• Liegt das tatsächliche Alter der Daten innerhalb dieser Frist?
• Wenn eine Löschung hätte erfolgen müssen: Gibt es ein Löschprotokoll, das das belegt?

Rechenbeispiel: Die Policy sagt, Badge-Zugangslogs werden 180 Tage aufbewahrt. Sie prüfen 50 Datensätze. 42 liegen innerhalb von 180 Tagen. 8 sind älter, einer ist 14 Monate alt. Das ist eine Compliance-Rate von 84 % in dieser Stichprobe, deutlich unter einer akzeptablen Schwelle (die meisten internen Auditstandards erwarten 95 %+, bevor eine Kontrolle als „wirksam“ gilt). Der Befund: Die Löschung nach Aufbewahrungsfrist ist nicht automatisiert, sie hängt davon ab, dass sich jemand erinnert.

Lösungsmuster: Löschung über einen geplanten Job automatisieren statt manueller Durchsicht, und jedes Löschereignis als Nachweis protokollieren.

Test 2: Zugangslogs gegen Rollendefinitionen prüfen

Hier trifft Governance-Policy auf die Realität. Holen Sie die RBAC-Matrix (Role-Based Access Control), also das Dokument, das festlegt, wer auf was zugreifen darf, und vergleichen Sie sie mit den tatsächlichen Systemlogs.

Konkret:

1. Exportieren Sie die Login-Events der letzten 30 Tage aus dem MES und dem SCADA-Historian.

2. Ordnen Sie jeden Nutzer seiner zugewiesenen Rolle zu (Operator, Qualitätsingenieur, Wartungskontraktor, Werks-IT).

3. Markieren Sie jeden Zugriff außerhalb der definierten Rolle, z. B. einen Kontraktoren-Account mit Schreibzugriff auf Rezeptparameter, obwohl der Vertrag nur lesende Diagnose erlaubte.

# Simplified access-audit logic (pseudocode)
for user in access_log:
    role = role_registry.get(user.id)
    if user.action not in role.permitted_actions:
        flag_finding(user, role, user.action, timestamp)

Eine solche Abfrage ist trivial, sobald die Logs zentralisiert sind, aber in vielen Werken gibt es weiterhin Zugriffe auf PLC-Ebene, die nie in einem zentralen Log landen, was selbst ein Befund ist, der dokumentiert werden sollte.

Test 3: Eine Incident-Response-Übung für einen simulierten PLC-Breach durchführen

Tabletop-Übung: Nehmen Sie an, ein Angreifer hat Remote-Zugriff auf einen PLC erlangt, der einen kritischen Prozess steuert (einen Ofen, einen Chemiemischer, eine Roboterschweißzelle). Messen Sie, wie lange das Team braucht, um:

• Die Anomalie zu erkennen (ungewöhnliches Befehlsmuster, unerwartete Parameteränderung)
• Das betroffene Netzwerksegment zu isolieren
• Die erforderlichen Stellen zu informieren (interne Security, und falls personenbezogene oder sicherheitsrelevante Daten betroffen sind, Aufsichtsbehörden innerhalb des 72-Stunden-Fensters der GDPR für Meldungen)
• Aus einem bekannt guten Backup wiederherzustellen

Referenzpunkt aus der Praxis: Der Ransomware-Vorfall bei Colonial PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → 2021 (USA) zeigte, wie eng Operational Technology (OT) und Information Technology (IT) gekoppelt sein kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen, sodass ein IT-Breach zum Produktionsstillstand führt. Fertigungswerke mit schlechter IT/OT-Netzwerksegmentierung haben dasselbe Risiko.

🎬 [VIDEO: "Industrial Control Systems Security Basics" - youtube.com/@CISAgov - CISAs Überblick über die Grundlagen der ICS/SCADA-Sicherheit für kritische Infrastruktur und Fertigungsumgebungen]

Einen Audit-Report bauen, der tatsächlich genutzt wird

Ein Audit, das ein 40-seitiges PDF produziert, das niemand liest, ist schlimmer als kein Audit. Strukturieren Sie Befunde so, dass Werksleiter und Compliance-Verantwortliche handeln kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen:

| Befund | Risikostufe | Nachweis | Owner | Frist |

|---|---|---|---|---|

| Badge-Logs 14 Monate über Policy hinaus aufbewahrt | Mittel | Stichprobe von 50 Datensätzen, 8 nicht konform | Werks-IT | Q2 |

| Kontraktor hat Schreibzugriff über seine Rolle hinaus | Hoch | Abgleich der Zugangslogs | Security Lead | Sofort |

| Breach-Übung: 47 Min. bis zur Segmentisolierung (Ziel: 15 Min.) | Hoch | Zeitprotokoll der Übung | OT Security | Q1 |

Jede Zeile braucht einen namentlichen Owner und ein Datum. Governance-Audits scheitern in der Praxis nicht daran, dass niemand Probleme findet, sondern daran, dass Befunde in einem Report liegen bleiben, ohne verantwortlichen Owner.

Typische Fehlermuster, die man benennen sollte

• Shadow IT auf dem Shop Floor: Ingenieure, die zur Fehlersuche ein Laptop direkt an einen PLC hängen und protokollierte Zugriffe komplett umgehen.
• Blinde Flecken bei Anbietern: OEM-Serviceverträge (Original Equipment Manufacturer), die Remote-Zugriff für Wartung einräumen und nach der Erstunterzeichnung selten überprüft werden.
• Aufbewahrungs-Policy, die nur auf Papier existiert: im Governance-Handbuch geschrieben, nie als automatisierte Kontrolle umgesetzt.
• Access Reviews jährlich statt kontinuierlich: Der Zugriff eines Kontraktors überlebt seinen Vertrag um Monate.

Die ENISA-Leitlinien (European Union Agency for Cybersecurity) für industrielle Steuerungssysteme sind eine nützliche kostenlose Referenz, um OT-spezifische Kontrollen gegen EU-Erwartungen zu benchmarken.

Key Takeaways

• Ein Audit ist die Nachweisebene für eine Governance-Policy: Prüfen Sie echte MES- und Zugangsdatensätze stichprobenartig, statt allein dem Policy-Dokument zu vertrauen.
• Die Einhaltung von Aufbewahrungsfristen sollte mit einer konkreten Stichprobe und einer Bestehensschwelle gemessen werden (Ziel: 95 %+); alles darunter deutet auf einen manuellen, unzuverlässigen Prozess hin.
• Access-Audits erfordern den Abgleich von Logs mit einer dokumentierten RBAC-Matrix, und Zugriff auf PLC-Ebene, der nie im zentralen Logging landet, ist selbst eine Governance-Lücke.
• Incident-Response-Übungen brauchen einen zeitlich gemessenen Benchmark (Erkennung, Isolierung, Meldung, Wiederherstellung), da GDPR und ähnliche Regime feste Meldefristen für Breaches vorschreiben.
• Jeder Audit-Befund braucht einen namentlichen Owner und eine Deadline; offene Befunde sind der häufigste Grund, warum Audits das Verhalten auf dem Shop Floor nicht verändern.