OEE-Software-Sicherheitsbewertung: 20 Fragen, die Sie vor der Verbindung mit Ihrem SPS-Netzwerk stellen sollten.

Das Anschließen von OEE‑Software an das SPS‑Netzwerk einer Produktionsanlage schafft einen neuen Datenweg zwischen Betriebstechnik (OT) und Informationstechnologie (IT)-Umgebungen. In den meisten Werken sind OT‑Netzwerke bewusst von den unternehmensweiten IT‑Netzwerken isoliert, um Produktionssysteme vor Cyberbedrohungen zu schützen, ein Einbruch in eine Produktions‑SPS ist ein Risiko für die Sicherheit und die Geschäftskontinuität, nicht nur ein Datensicherheitsrisiko.

Jegliche Software, die diese OT‑IT‑Grenze überschreitet, einschließlich OEE‑Plattformen, erfordert vor der Bereitstellung eine gründliche Sicherheitsbewertung. Die Sicherheitslage bei OEE‑Software hat sich in den letzten fünf Jahren deutlich verbessert, aber die Unterschiede zwischen den Anbietern sind groß.

Cloud‑native OEE‑Plattformen, die auf modernen Sicherheitsarchitekturen basieren, haben grundlegend andere Sicherheitsprofile als On‑Premise‑OEE‑Systeme, die in den 2000er‑Jahren entwickelt wurden und nicht mit Blick auf die Sicherheit der OT‑IT‑Grenze konzipiert wurden.

Die Fragen in einer Sicherheitsbewertung sollten diese Unterschiede offenlegen und dokumentierte Nachweise zur Sicherheitslage des Anbieters liefern, die Ihre IT‑ und OT‑Sicherheitsteams vor der Freigabe einer Netzwerkverbindung prüfen können.

Die Folgen einer unzureichenden OEE‑Sicherheitsbewertung reichen von geringfügigen Problemen, unbefugter Datenzugriff oder Verstöße gegen Datenschutzauflagen, bis hin zu schwerwiegenden Vorfällen, etwa Ransomware, die über einen kompromittierten OEE‑Server ins OT‑Netzwerk gelangt und die Produktionsabläufe stört.

Da OEE‑Software mit Produktionsanlagen auf jeder Linie verbunden ist, hat eine kompromittierte OEE‑Plattform breiteren Netzwerkzugang als die meisten IT‑Systeme, die mit der OT‑Umgebung verbunden sind. Dieses erhöhte Risikoprofil rechtfertigt eine gründlichere Sicherheitsprüfung als bei üblichen Bewertungen von Unternehmenssoftware.

Architektur- und Datenflussfragen: (1) Verwendet die OEE-Plattform eine unidirektionale Datenflussarchitektur von OT zu IT (nur Lesezugriff auf SPS), oder verfügt sie über bidirektionale Kommunikationsfähigkeit? (2) Wo werden Produktionsdaten gespeichert, vor Ort (on‑premise), in einer bestimmten Cloud‑Region oder in einer gemeinsam genutzten mandantenfähigen Cloud?

(3) Wird der OEE‑Server in einer DMZ zwischen den OT‑ und IT‑Netzwerken platziert, oder benötigt er gleichzeitigen direkten Zugriff auf beide Netzwerke? (4) Welche Netzwerkports und -protokolle müssen zwischen den OT‑ und IT‑Netzwerken für die OEE‑Plattform geöffnet sein? (5) Unterstützt die OEE‑Plattform eine Bereitstellung ohne eingehende Internetverbindungen (netzisoliert/air‑gapped oder vollständig vor Ort)?

Authentifizierungs- und Zugriffskontrollfragen: (6) Unterstützt die Plattform SAML 2.0 oder OIDC für die Enterprise‑SSO‑Integration? (7) Wird Multi‑Faktor‑Authentifizierung (MFA) unterstützt und kann sie für alle Benutzerrollen durchgesetzt werden? (8) Implementiert die Plattform rollenbasierte Zugriffskontrolle (RBAC), die den Datenzugriff nach Werk, Produktionslinie und Funktion einschränkt?

(9) Gibt es separate Administratoranmeldeinformationen für die OEE‑Anwendung und die zugrunde liegende Infrastruktur (Datenbank, Betriebssystem)? (10) Wie werden API‑Schlüssel und Service‑Account‑Anmeldeinformationen verwaltet und rotiert/erneuert? Datensicherheitsfragen: (11) Sind Daten bei der Übertragung für alle Kommunikationen mit TLS 1.2 oder höher verschlüsselt? (12) Sind ruhende Daten (data at rest) verschlüsselt, und welcher Verschlüsselungsstandard wird verwendet?

(13) Welche Produktionsdaten werden in die Cloud gesendet bzw. vor Ort (on‑premise) aufbewahrt? (14) Protokolliert die Plattform alle Benutzerzugriffsereignisse und Datenexportaktionen in einem Prüfprotokoll, das dem Kunden zugänglich ist? (15) Wie lautet die Datenaufbewahrungsrichtlinie und der Löschprozess, wenn ein Kunde den Vertrag beendet?

Fragen zum Schwachstellenmanagement und zur Vorfallreaktion: (16) Wie ist der Prozess des Anbieters zur Verteilung von Sicherheitspatches, und wie lange dauert es typischerweise von der Offenlegung einer Schwachstelle bis zur Verfügbarkeit eines Patches? (17) Hat der Anbieter in den letzten 12 Monaten einen Penetrationstest durch Dritte durchgeführt, und ist eine Executive‑Summary der Ergebnisse verfügbar?

(18) Verfügt der Anbieter über eine veröffentlichte Richtlinie zur Offenlegung von Schwachstellen und einen dedizierten Sicherheitskontakt? (19) Wie lautet die Incident‑Response‑SLA des Anbieters, wenn eine Sicherheitsverletzung festgestellt wird, die Kundendaten betrifft? (20) Verfügt der Anbieter über relevante Sicherheitszertifizierungen (ISO 27001, SOC 2 Type II), die die OEE‑Plattform‑Infrastruktur abdecken?

Bei der Auswertung von Anbieterantworten auf den Sicherheitsfragebogen sollte man auf Spezifität statt auf bloße Behauptungen achten.

Ein Anbieter, der auf die Frage „Sind Daten während der Übertragung verschlüsselt?“ mit „Ja, wir verwenden branchenübliche Verschlüsselung“ antwortet, ist weniger glaubwürdig als einer, der antwortet: „Ja, alle Kommunikationen nutzen TLS 1.3 mit Certificate Pinning auf mobilen Clients.“ Vage positive Aussagen sind leicht zu machen; spezifische technische Angaben sind schwerer zu erfinden und leichter zu überprüfen.

Behandle bestimmte Antworten als Hard Stops, die vor einer Genehmigung der Bereitstellung geklärt werden müssen.

Dazu gehören: bidirektionale Netzwerkkommunikation von OT‑Systemen zur Cloud des Anbieters (schafft eine eingehende Angriffsfläche); keine MFA‑Unterstützung für Admin‑Zugänge (inakzeptabel für OT‑verbundene Systeme); Speicherung von Daten in einer Gerichtsbarkeit, die den Anforderungen an Ihre Datensouveränität widerspricht; kein Penetrationstest durch Dritte in den letzten 18 Monaten; und kein dokumentierter Incident‑Response‑Prozess.

Dies sind keine Verhandlungspunkte, sie sind Sicherheitsgrundlagen, die eine verantwortungsbewusste OT‑Netzwerksicherheit erfordert. Verankern Sie die Sicherheitsanforderungen, die Anbieter erfüllen müssen, vor der Unterzeichnung im Kaufvertrag.

Nehmen Sie spezifische Klauseln auf, die Folgendes regeln: Benachrichtigungspflichten, falls der Anbieter einen Sicherheitsvorfall feststellt, der Ihre Daten betrifft; das Recht, jährlich eine eigene Sicherheitsbewertung der Plattform durchzuführen; die Verpflichtung des Anbieters, kritische Schwachstellen innerhalb von 30 Tagen zu beheben; und das Recht des Kunden, den Vertrag ohne Strafe zu kündigen, wenn der Anbieter seine Sicherheitszusagen nicht einhält.

Sicherheitsanforderungen, die nicht vertraglich festgelegt sind, sind Vorschläge, vertragliche Sicherheitsanforderungen sind Verpflichtungen, die Rechtsbehelfe schaffen, wenn sie verletzt werden.