Sicherheit und IT-Architektur
PRECOG läuft im Pilot in einer vom Hersteller betriebenen Cloud und in der Produktion auf einem Server des Kunden. Beide Modelle folgen denselben Sicherheitsprinzipien.
Betrieb
Betriebsmodelle
Die PRECOG-Web-API und die Anwendungsdienste laufen in einer Cloud-Umgebung, die Vida Soft betreibt, und werden über das Internet erreicht. Das Messgerät nutzt das vorhandene Netzwerk des Kunden, mit Ethernet oder einem Unternehmens-WLAN, und braucht kein eigenes Gateway. Berechtigte Nutzer arbeiten in einem Browser. Die Daten werden in der EU gespeichert und verarbeitet.
Ein dedizierter PRECOG-Server im Serverraum des Kunden betreibt die API, die Analyse, die KI, die Datenbank und die Browseroberfläche. Die Geräte verbinden sich mit dem lokalen API-Endpunkt, sodass der Normalbetrieb nicht von einem externen Cloud-Dienst abhängt.
Das System ist beobachtend. Es liest Messwerte und sendet keine Steuerbefehle an die Maschinen.
Edge
Messgeräte
- Nur die Dienste, die für Messung, Verbindung und API-Kommunikation nötig sind, sind aktiv.
- Der ausgehende Datenverkehr nutzt einen verschlüsselten HTTPS-Kanal.
- Jede Nachricht wird mit einem Maschinenschlüssel (HMAC) signiert, der ihre Herkunft und Integrität schützt.
- Der Netzwerkzugriff auf das Gerät wird durch die WLAN- oder Ethernet-Kontrollen des Kunden begrenzt.
- Physischer Zugang, Firmware-Verwaltung und Wartung folgen kontrollierten Prozessen.
- Geht die Verbindung verloren, behält das Gerät die Datensätze in seinem eigenen Speicher und lädt sie in der richtigen Reihenfolge hoch. Ein Datensatz gilt erst als geliefert, wenn die API ihn bestätigt hat.
Schnittstelle
API und Kommunikation
Transport
TLS 1.2 oder höher, im Pilot TLS 1.3. Unverschlüsseltes HTTP, FTP und Telnet werden im Normalbetrieb nicht benötigt.
Authentifizierung
Geräte nutzen eine HMAC-Signatur und eine Geräteidentifikation. Dienste nutzen eigene Konten ohne interaktive Anmeldung. Integrationen nutzen ein Geheimnis oder ein Zertifikat.
Eingaben und Fehler
Der Server prüft Typ, Bereich, Länge und Format jeder Eingabe. Fehlermeldungen sind allgemein gehalten und verraten nichts über das System.
Sitzungskennungen werden nie als URL-Parameter gesendet. Der Zugriff folgt dem Prinzip der minimalen Rechte. Erfolgreiche und fehlgeschlagene API-Ereignisse werden protokolliert.
Daten
Daten und Eigentum
PRECOG verarbeitet technische Telemetrie, Anlageninformationen, Analyseergebnisse, Ereignisse, Nutzerdaten und Verwaltungsprotokolle. Die Verarbeitung hat einen festgelegten Zweck, der Zugriff hängt von der Rolle ab, und wesentliche Änderungen sind prüfbar. Ein Pilotpaket kann auf anonyme technische Werte mit einem Zeitstempel, einer Folgenummer und einer neutralen Gerätekennung beschränkt werden. Es enthält dann keine personenbezogenen Daten und keinen Maschinennamen, keine Seriennummer und keinen genauen Standort.
Die Daten durchlaufen einen gesteuerten Lebenszyklus: Erfassung, Aufbewahrung, Nutzung, Backup und kontrollierte Löschung. Datendateien, Backups und sensible Konfigurationen sind im Ruhezustand verschlüsselt. Schlüssel und Geheimnisse werden getrennt von den Daten verwaltet, mit eingeschränktem Zugriff und dokumentierter Rotation und Sperrung.
Zugriff
Zugriffskontrolle
- Geräte: HMAC-Maschinenauthentifizierung mit einem eindeutigen Geheimnis und Schutz vor Wiedereinspielung.
- Nutzer: eine eindeutige ID und ein starkes Passwort, mit Multi-Faktor-Authentifizierung, wo sie integriert ist.
- Administratoren: getrennte personalisierte Konten, Multi-Faktor-Authentifizierung, wo integriert, und Sitzungsprotokollierung.
- Rollenbasierter Zugriff: Betrachter, Wartungstechniker, Wartungsleiter, Systemadministrator und Prüfer.
- Jede Rolle sieht nur die Funktionen und Daten, die sie braucht.
- Privilegierte Rechte werden regelmäßig überprüft, inaktive Konten werden gesperrt und Zugriffsereignisse werden protokolliert.
Betrieb
Protokollierung, Backup und Patching
Protokollierung
Audit-, API-, Sicherheits-, Anwendungs-, Datenbank- und Betriebssystemprotokolle teilen sich eine gemeinsame Zeitquelle, eine Quellkennung, einen Ereignistyp, ein Ergebnis und eine Korrelationskennung. Ist ein SIEM angebunden, können die Protokolle dorthin weitergeleitet werden.
Backup und Wiederherstellung
Das Backup-Modell fügt sich in die zentrale Datensicherung des Kunden ein: häufige Datenbank-Backups, ein tägliches Vollbackup, ein Konfigurations-Backup nach jeder genehmigten Änderung und ein Systemabbild vor größeren Änderungen. Die Wiederherstellung folgt einer dokumentierten Reihenfolge.
Richtlinie
NIS2-Richtlinie: was sie verlangt
Die Richtlinie (EU) 2022/2555, bekannt als NIS2, legt gemeinsame Cybersicherheitsregeln für wesentliche und wichtige Einrichtungen in der EU fest. Jeder Mitgliedstaat setzt sie durch sein eigenes nationales Recht um. Artikel 21 nennt die Risikomanagementmaßnahmen, die eine Einrichtung ergreifen muss. Artikel 23 beschreibt, wie erhebliche Sicherheitsvorfälle gemeldet werden.
Die Pflichten liegen bei der betreibenden Organisation. Ein Lieferant kann sie nicht übernehmen. Ein Lieferant kann ein Produkt anbieten, das sicher gebaut, klar dokumentiert und leicht in das Sicherheitsprogramm des Betreibers einzufügen ist. So ist PRECOG ausgelegt.
PRECOG ist ein beobachtendes System. Es liest Messwerte und sendet keine Steuerbefehle an die Maschinen, daher schafft es keine Möglichkeit, einen Prozess zu beeinflussen. Die Architektur und die Kontrollen sind in den Abschnitten oben beschrieben.
Artikel 21
NIS2-Maßnahmen und PRECOG
Jede Karte nennt eine Maßnahme aus Artikel 21 Absatz 2 und zeigt, was PRECOG dafür bietet.
Das Betriebsmodell, die Sicherheitszonen und jede Netzwerkverbindung sind dokumentiert, mit Quelle, Ziel, Protokoll, Port und geschäftlichem Grund. Der Betreiber kann diese Beschreibung direkt in seiner eigenen Risikoanalyse verwenden.
Audit-, API- und Sicherheitsereignisse werden mit einer gemeinsamen Zeitquelle, einem Ereignistyp, einem Ergebnis und einer Korrelationskennung protokolliert. Die Protokolle können an ein SIEM weitergeleitet werden. Sicherheitsereignisse folgen einem klassifizierten Prozess mit einer protokollbasierten Untersuchung, einem Verifikationstest und einem dokumentierten Abschluss.
Das Backup-Modell fügt sich in die zentrale Datensicherung des Kunden ein: Datenbank-Backups, ein tägliches Vollbackup, ein Konfigurations-Backup nach jeder genehmigten Änderung und ein Systemabbild vor größeren Änderungen. Die Wiederherstellung folgt einer dokumentierten Reihenfolge. Ein Messgerät behält seine Datensätze bei einem Netzwerkausfall und lädt sie in der richtigen Reihenfolge hoch.
Die unterstützte Infrastruktur ist aufgeführt. Komponenten, deren Herstellerunterstützung endet, werden migriert. Das Eigentum an den Daten und an der Software ist schriftlich festgelegt, sodass der Betreiber PRECOG als Lieferanten bewerten kann.
Schwachstellenbewertungen laufen vor der Inbetriebnahme, nach wesentlichen Änderungen und in regelmäßigen Abständen. Die Befunde werden nach Risiko, Ausnutzbarkeit und geschäftlicher Auswirkung eingestuft. Vor dem Go-live wird die externe und interne Angriffsfläche getestet, und ein erneuter Test bestätigt die Behebung. Änderungen folgen einem kontrollierten Freigabeprozess.
Penetrationstests und erneute Tests, regelmäßige Schwachstellenbewertungen und die Überwachung der Plattform selbst liefern Nachweise dafür, wie gut die Maßnahmen wirken. Die Plattformüberwachung verfolgt Verfügbarkeit, Antwortzeit, Fehlerrate und Ressourcennutzung.
Nur die nötigen Dienste sind aktiv. Unnötige Ports sind geschlossen, Dienste laufen unter nicht privilegierten Konten, und es gibt keine direkte Administratoranmeldung aus der Ferne. Die Schulung der Mitarbeitenden ist eine organisatorische Maßnahme des Betreibers.
Die Kommunikation nutzt TLS 1.2 oder höher, im Pilot TLS 1.3. Jede Gerätenachricht wird mit einem Maschinenschlüssel (HMAC) signiert. Datendateien, Backups und sensible Konfigurationen sind im Ruhezustand verschlüsselt. Schlüssel werden getrennt verwaltet, mit dokumentierter Rotation und Sperrung. Alte SSL- und TLS-Versionen sowie schwache Algorithmen sind deaktiviert.
Der Zugriff ist rollenbasiert, mit fünf Rollen vom Betrachter bis zum Prüfer, und folgt dem Prinzip der minimalen Rechte. Privilegierte Rechte werden regelmäßig überprüft, inaktive Konten werden gesperrt und Zugriffsereignisse werden protokolliert. Jedes Gerät hat eine eindeutige Kennung und ein eindeutiges Geheimnis.
Nutzer und Administratoren können die Multi-Faktor-Authentifizierung nutzen, wo sie integriert ist, und Administratoren haben getrennte personalisierte Konten. Die drahtlose Verbindung der Geräte kann mit WPA3 Enterprise und 802.1X geschützt werden. Der ausgehende Datenverkehr nutzt einen verschlüsselten Kanal.
Artikel 23
NIS2-Meldung von Sicherheitsvorfällen
Eine Einrichtung muss innerhalb von 24 Stunden, nachdem sie von einem erheblichen Sicherheitsvorfall erfahren hat, eine Frühwarnung senden, innerhalb von 72 Stunden eine Meldung und innerhalb eines Monats einen Abschlussbericht. Dafür braucht der Betreiber schnell verlässliche Fakten.
Die Protokolle von PRECOG teilen sich eine Zeitquelle und tragen eine Quellkennung, einen Ereignistyp, ein Ergebnis und eine Korrelationskennung. Sie können an das SIEM des Betreibers weitergeleitet werden, wo sie sich mit den anderen Protokollen verbinden. Die Entscheidung, ob ein Sicherheitsvorfall erheblich ist, und die Meldung an die Behörde bleiben beim Betreiber.
Sektoren
Wo NIS2 gilt
Die Richtlinie nennt Sektoren wie Energie, Verkehr einschließlich Luft- und Schienenverkehr, Trinkwasser und Abwasser, Gesundheit, digitale Infrastruktur sowie die Herstellung elektrischer Ausrüstungen und von Maschinen. Flughäfen, Bahnen, Versorger und Hersteller gehören zu den Organisationen, in denen PRECOG Elektromotoren überwacht.
Ob eine Organisation unter die Richtlinie fällt, hängt von ihrem Sektor, ihrer Größe und dem nationalen Recht des Landes ab, in dem sie tätig ist.
Geltungsbereich
Geltungsbereich des NIS2-Abschnitts
Haben Sie IT-, Sicherheits- oder NIS2-Anforderungen, die wir vor einem Pilot beantworten sollen?