Zwei Regelwerke, ein gemeinsames technisches Problem
Die EU-Maschinenverordnung betrachtet Maschinen und zugehörige Produktsicherheit. Der Cyber Resilience Act adressiert Cybersicherheitsanforderungen an Produkte mit digitalen Elementen und deren Pflege über den Produktlebenszyklus. Anwendungsbereich, Rollen, Bewertungswege und Einzelfallpflichten sind nicht identisch. Eine pauschale Aussage wie „eine Maschine muss jetzt CRA-konform gemacht werden“ ist deshalb technisch und rechtlich zu grob.
Die offizielle Einordnung der Europäischen Kommission zum CRA hebt Anforderungen über Planung, Entwurf, Entwicklung und Wartung sowie den Umgang mit Schwachstellen während des Lebenszyklus hervor. Die Maschinenverordnung enthält ihrerseits Anforderungen, bei denen sichere und zuverlässige Steuerungssysteme, softwarebezogene Informationen und Schutz vor unbeabsichtigter oder absichtlicher Verfälschung technisch relevant werden können.
Daraus folgt noch keine fertige Maßnahmenliste. Es folgt eine Bestandsfrage: Kann der Hersteller für jede relevante Produkt- oder Maschinenvariante überhaupt nachvollziehen, welche Software, Komponenten und Konfigurationen ausgeliefert wurden und wie Änderungen daran kontrolliert werden?
Bevor über einzelne Sicherheitsmaßnahmen entschieden wird, muss klar sein, welches technische System bewertet, gepflegt und nach einer Änderung wieder geprüft werden soll.
1. System- und Produktgrenze festlegen
Der erste technische Fehler besteht häufig darin, nur die SPS-Anwendung zu betrachten. Eine moderne oder nachgerüstete Maschine kann zusätzlich HMI, Industrie-PC, Betriebssystem, Datenbank, Fernwartungszugang, Router, OPC-UA-Server, Weboberfläche, Updatewerkzeug und angebundene Dienste enthalten. Welche Teile zum betrachteten Produkt gehören und welche als externe Betriebsumgebung behandelt werden, ist eine grundlegende Architekturfrage.
Für die Bestandsaufnahme sollte eine Systemübersicht mindestens zeigen:
- relevante Hardware- und Softwarekomponenten samt Verantwortungsgrenze,
- Netzwerkzonen, physische und logische Schnittstellen,
- Daten- und Befehlsflüsse einschließlich Fernzugriff und Wartung,
- Identitäten, Rollen und Vertrauensbeziehungen,
- Produkt-, Maschinen- und Optionsvarianten,
- sowie externe Komponenten, deren Ausfall oder Manipulation die Funktion beeinflusst.
Diese Übersicht ist kein Rechtsgutachten und kein Vollständigkeitsnachweis. Sie verringert aber das Risiko, dass eine spätere technische Bewertung einen versteckten Updatekanal, ein herstellerseitiges Standardkonto oder einen relevanten Kommunikationspartner übersieht.
2. Quellstände und ausgelieferte Versionen zuordnen
Ein Repository ist nur dann hilfreich, wenn sich seine Revision einer ausgelieferten Variante zuordnen lässt. In gewachsenen Beständen existieren häufig Projektarchive, lokale Exporte, manuelle Hotfixes und unterschiedliche Bibliotheksstände nebeneinander. Eine Versionsnummer im HMI beweist nicht automatisch, welcher SPS- und IPC-Quellstand dahintersteht.
Eine belastbare Zuordnung verbindet deshalb:
- Maschinen- oder Produktvariante,
- freigegebene Quellrevisionen für SPS, HMI, IPC und weitere Software,
- Konfiguration und aktivierte Optionen,
- verwendete Werkzeug- und Bibliotheksstände,
- erzeugte Artefakte mit eindeutiger Kennzeichnung,
- Auslieferungs- beziehungsweise Installationsnachweis,
- und spätere Änderungen im Feld.
Wo diese Kette historisch nicht mehr geschlossen werden kann, sollte die Lücke nicht rückwirkend „glatt dokumentiert“ werden. Stattdessen wird festgehalten, was belegt, plausibel und unbekannt ist. Erst danach kann entschieden werden, ob eine technische Aufnahme am realen System, ein Neu-Build oder eine begrenzte Migration die Unsicherheit reduziert.
3. Den Build als kontrollierten Prozess behandeln
Softwarepflege setzt voraus, dass ein freigegebener Stand erneut erzeugt werden kann. Dazu gehören nicht nur Quelltexte, sondern Entwicklungsumgebung, Zieldefinitionen, Herstellerpakete, Bibliotheken, Compileroptionen, Variantenparameter und gegebenenfalls Signier- oder Paketierungsschritte.
Ein reproduzierbarer Build beantwortet drei praktische Fragen: Sind alle notwendigen Eingänge vorhanden? Ist ihre Version festgelegt? Kann der Vorgang unabhängig von einem einzelnen Entwicklerrechner wiederholt werden? Das Ergebnis kann ein automatisierter Build sein, muss es bei proprietären Engineering-Systemen aber nicht zwingend. Auch ein dokumentierter, kontrollierter Import- und Buildweg ist wertvoll, solange Eingänge und Ergebnisse eindeutig sind.
Build-Reproduzierbarkeit ist keine Funktionsfreigabe. Sie ist die Voraussetzung dafür, dass ein Schwachstellen-Fix oder eine andere Änderung überhaupt aus einem bekannten Stand erzeugt und später nachvollzogen werden kann.
4. Komponenten und Abhängigkeiten beherrschbar machen
Maschinen-Software enthält neben eigenem Code häufig Laufzeiten, Betriebssystempakete, Kommunikationsbibliotheken, Webkomponenten, Treiber, Datenbanken und herstellerspezifische SPS-Bibliotheken. Für Pflege und Schwachstellenbewertung muss erkennbar sein, welche Komponente in welcher Variante verwendet wird und wer Informationen sowie Aktualisierungen bereitstellt.
Eine Komponentenliste oder Software Bill of Materials kann dafür ein wichtiges technisches Hilfsmittel sein. Ihr Format und ihre rechtliche Rolle hängen vom Kontext ab. Technisch sollte sie mindestens die Identifikation, Version, Herkunft, Einsatzstelle und bekannte Abhängigkeiten relevanter Komponenten ermöglichen. Ein Eintrag „Linux“, „Webserver“ oder „CODESYS-Bibliothek“ ohne konkrete Version ist für die Bewertung meist zu ungenau.
Ebenso wichtig ist die Pflegeentscheidung: Wird die Komponente aktiv aktualisiert, bewusst auf einem eingefrorenen Stand betrieben, durch Netzsegmentierung begrenzt oder mittelfristig ersetzt? Eine alte Version ist nicht allein deshalb automatisch unsicher; ein unbekannter, unüberwachter und nicht aktualisierbarer Stand ist jedoch schwer belastbar zu behandeln.
5. Angriffsflächen entlang realer Datenwege prüfen
Eine technische Cyberresilienz-Prüfung beginnt nicht bei einer generischen Scannerliste, sondern bei den realen Eintrittspunkten. Dazu gehören Netzwerkdienste, Fernwartung, Wechseldatenträger, Service-Laptops, Updatepakete, Benutzerkonten, Funkverbindungen und Schnittstellen zu übergeordneten Systemen.
Für jeden Pfad sind konkrete Fragen zu beantworten:
- Wer oder was darf die Verbindung aufbauen?
- Wie werden Identität und Berechtigung geprüft?
- Welche Befehle und Daten können übertragen werden?
- Wie werden Integrität und gegebenenfalls Vertraulichkeit geschützt?
- Welche Standardzugänge, Schlüssel oder Geheimnisse existieren?
- Was wird protokolliert, und ist die Zeitbasis der Protokolle verlässlich?
- Wie verhält sich das System bei Ausfall, Manipulation oder ungültigen Eingaben?
Nicht jede Maschine benötigt dieselben Mechanismen. Ein isolierter Serviceport, ein dauerhaftes VPN und eine öffentliche Webschnittstelle haben unterschiedliche Angriffsflächen. Maßnahmen müssen deshalb aus Systemgrenze, Bedrohung und betrieblichen Randbedingungen abgeleitet werden.
6. Update- und Fernwartungsweg als Teil des Produkts verstehen
Ein Update ist nicht nur eine Datei. Es ist ein Prozess aus Erzeugung, Freigabe, Verteilung, Authentizitäts- und Integritätsprüfung, Installation, Neustart, Funktionsprüfung und gegebenenfalls Rückkehr zum vorherigen Stand. In der Praxis muss außerdem geklärt werden, wer Zugriff hat, wie eine Maschine im Feld erreicht wird und was bei unterbrochener Übertragung passiert.
Ein belastbarer Updateweg dokumentiert:
- welche Komponenten getrennt oder gemeinsam aktualisiert werden,
- wie Pakete einer freigegebenen Revision zugeordnet werden,
- wie unbeabsichtigte oder manipulierte Pakete erkannt werden,
- welche Voraussetzungen und Datenmigrationen vor der Installation nötig sind,
- wie Fehler und Teilstände behandelt werden,
- welche Prüfung nach dem Update folgt,
- und welche Rückfallstrategie technisch möglich und organisatorisch freigegeben ist.
Ein Fernwartungszugang ist dabei selbst pflegebedürftige Infrastruktur. Konten, Berechtigungen, Protokollierung, Freigabeverfahren und eingesetzte Komponenten gehören in dieselbe Betrachtung wie die eigentliche Maschinensoftware.
7. Schwachstellenbehandlung braucht eine geschlossene Bearbeitungskette
Ein Postfach für Meldungen allein löst keine Schwachstelle. Technisch benötigt der Prozess eine Verbindung von Eingang, Bewertung, betroffenen Versionen, Änderung, Test, Freigabe, Auslieferung und Kommunikation.
- Eingang: Meldungen aus Lieferkette, eigener Analyse, Betrieb oder externen Hinweisen werden eindeutig erfasst.
- Betroffenheit: Die Komponenten- und Auslieferungsdaten zeigen, welche Varianten geprüft werden müssen.
- Bewertung: Erreichbarkeit, Auswirkung, vorhandene Begrenzungen und Betriebsbedingungen werden technisch untersucht.
- Änderung: Ein Fix oder eine andere Maßnahme wird gegen einen bekannten Quellstand umgesetzt.
- Nachweis: Build, Regressionstests und reale Integrationsprüfung werden nach ihrer tatsächlichen Aussagekraft dokumentiert.
- Auslieferung: Betroffene Empfänger, Updateweg und verbleibende Einschränkungen sind nachvollziehbar.
Welche Melde-, Informations- oder Aufbewahrungspflichten im Einzelfall bestehen, ist eine rechtliche und organisatorische Frage. Technisch lässt sich aber früh prüfen, ob die notwendigen Daten für eine fristgerechte und zielgerichtete Bearbeitung überhaupt vorhanden wären.
8. Softwareänderung und Maschinensicherheit zusammen betrachten
Cybersicherheit und funktionale Maschinensicherheit sind nicht dasselbe. Sie können sich dennoch beeinflussen. Eine manipulierte Sollwertschnittstelle, ein ausgefallener Kommunikationspfad oder ein fehlerhaftes Update kann zu einem unsicheren Zustand beitragen. Umgekehrt kann eine gut gemeinte Security-Maßnahme Reaktionszeiten, Diagnose oder Verfügbarkeit verändern.
Deshalb muss für Änderungen sichtbar sein, welche Steuerungsfunktionen, Betriebsarten, Kommunikationspfade und sicherheitsbezogenen Annahmen betroffen sind. Die technische Softwarearbeit liefert dafür Versions- und Testevidenz. Ob eine Änderung eine erneute Risikobeurteilung, besondere Validierung oder ein bestimmtes Konformitätsverfahren erfordert, kann sie nicht pauschal entscheiden.
9. Vier Nachweisstufen nicht vermischen
Quellcodeanalyse
Zeigt Struktur, Datenflüsse, Abhängigkeiten, potenzielle Angriffsflächen und auffällige Implementierungen. Sie beweist weder erreichbare Ausnutzbarkeit noch richtiges Maschinenverhalten.
Reproduzierbarer Build
Zeigt, dass ein definierter Stand mit kontrollierten Abhängigkeiten erzeugt werden kann. Er beweist nicht, dass die resultierende Software fachlich korrekt oder sicher integriert ist.
Logiktest und DryRun
Prüfen definierte Eingaben, Fehlerfälle, Zustände und erwartete Ausgaben ohne reale Aktoransteuerung. Sie können Protokoll- und Updatefehler früh sichtbar machen, bilden aber reale Netze, Hardware und Prozessphysik nur begrenzt ab.
Reale Maschinenvalidierung
Prüft das integrierte System unter geplanten Bedingungen mit echter Hardware, Kommunikation, Bedienung und Mechanik. Umfang, Verantwortlichkeiten und Freigabe müssen am konkreten Produkt festgelegt werden.
Ein sinnvoller technischer Einstieg
Für einen unklaren Bestand ist eine begrenzte technische Bestandsprüfung oft sinnvoller als ein sofortiges Großprojekt. Sie beginnt mit einer repräsentativen Maschinen- oder Produktvariante und beantwortet zunächst nur:
- Welche Systemgrenze und welche Rollen sind noch fachlich zu klären?
- Welche Quell- und Auslieferungsstände sind belastbar zuordenbar?
- Welche Builds lassen sich reproduzieren?
- Welche Komponenten und externen Schnittstellen sind bekannt?
- Wie funktionieren Update, Fernwartung und Schwachstellenbearbeitung heute tatsächlich?
- Welche Tests existieren, und welche Aussage haben sie?
- Welche Lücken blockieren Pflegefähigkeit oder eine weitere Bewertung?
Das Ergebnis ist keine Bescheinigung. Es ist eine technische Ausgangslage mit belegten Stärken, offenen Fragen, Risiken und priorisierten nächsten Schritten. Juristische Einordnung, Risikobeurteilung, Konformitätsbewertung und gegebenenfalls externe Prüfung bleiben getrennte Aufgaben.