Cybersecurity-Norm: Anwendung birgt Sprengstoff
Vor einiger Zeit ist mit der ISO 8102-20:2022 eine eigene Norm zum Thema Cybersecurity in Kraft getreten. Auch wenn diese noch nicht harmonisiert ist, verlangen die Prüforganisationen seit dem Sommer 2024 eine Herstellererklärung.
Darin muss plausibel dargelegt werden, wie die Norm vom Hersteller erfüllt wird. Das birgt einigen Sprengstoff ...
Die ISO 8102-20 beschreibt eigentlich für Aufzüge, Fahrsteige und Fahrtreppen die Umsetzung der IEC 62443-4 (Industrielle Kommunikationsnetze – IT-Sicherheit für Netze und Systeme). Dort sind die eigentlichen Aufgaben hinterlegt, nicht in der ISO 8102-20!
Die IEC 62443-4 besteht aus mehreren Teilen, wobei der erste Teil die organisatorischen Aspekte behandelt. Beim Lesen wird der eine oder andere an die ISO 9001 erinnert und es hilft bei der praktischen Umsetzung, wenn diese ISO 9001 bereits im Unternehmen umgesetzt wird. Verantwortlichkeiten und Abläufe werden hier in Form von Rollendiagrammen (RACI) und Flussdiagrammen dargestellt.
Abschnitte zum Secure Management
In der IEC 62443-4 gibt es einzelne Abschnitte zum Secure Management (SM). Denn Cybersecurity ist nicht nur ein Thema für die IT-Abteilung und die Ingenieure, sondern auch für die Unternehmensleitung. Worum geht es darin?
• Abschnitt SM-4 der 62443-4-1 fordert, dass ein Prozess vorhanden sein muss, um Schulungsprogramme zur IT-Sicherheit im Unternehmen zu installieren. Damit soll sichergestellt werden, dass Personen die Rollen und Aufgaben zugewiesen bekommen, die sie kontinuierlich erfüllen können.
• Im Abschnitt SM-7 geht es darum, dass das Arbeitsumfeld der Ingenieure vor unbefugtem Zugriff geschützt wird, um sicherzustellen, dass ein Cyberangriff nicht bereits während der Produktentwicklung erfolgt.
• Abschnitt SM-8 fordert eine Definition, wie digitale Schlüssel im Unternehmen gehandhabt werden. Dies ist wichtig für diejenigen, die Software entwickeln und diese heute typischerweise digital signieren, bevor sie sie an Kunden ausliefern.
• Von besonderem Interesse ist der Abschnitt SM-13, der sich damit befasst, wie Schwachstellen, die in der NVD (National Vulnerability Database) gesammelt werden, im Unternehmen genutzt werden können. So kann man prüfen, ob die eigenen Produkte betroffen sein könnten. Die NVD ist die US-amerikanische Datenbank für diesen Zweck, aber auch die EU arbeitet derzeit im Rahmen des Cyber Resilience Act an einer eigenen Datenbank.
Dokumentation des wöchentlichen 'Entwicklungsmeetings'
Foto: © okapidesign / Frei nutzbar gemäß Adobe Firefly-LizenzGenerell kann der Einsatz von Managementmethoden wie KANban auch ein Mittel sein, um Abschnitte der Norm 62443-4-1 wie SM-1 'Entwicklungsprozess' oder SM-2 'Verantwortlichkeiten' zu erfüllen. Denn in diesen Abschnitten wird gefordert, die Rollen und Verantwortlichkeiten bei der Entwicklung zu organisieren und den Arbeitsablauf der Entwicklungsschritte zu dokumentieren, kontinuierlich zu überprüfen und zu verbessern.
Ein Werkzeug, das häufig von kleinen Teams für diesen Zweck verwendet wird, ist Jira. Es ist nicht perfekt, aber gut genug und einfach zu handhaben. Natürlich gibt es auch andere Tools auf dem Markt.
Übrigens gehört auch die Dokumentation des wöchentlichen 'Entwicklungsmeetings' zum Secure Management. Wenn man hier etwa die neuesten Security-Einträge der NVD bespricht und kurz aufschreibt, ob sie auf das eigene Produkt zutreffen oder nicht, hilft das bei der Einhaltung des Standards.
Wer-hat-Was-Wann geändert?
Als Softwareentwickler kommt man nicht um diese beiden Teile der IEC 62443-4 herum. Vor allem der Teil 2 greift die Softwareentwicklung auf und fordert zum Beispiel die Verwendung eines modernen Speichersystems (Repository) für den Quellcode, wie SVN oder GIT. Damit wird sichergestellt, dass beim Bearbeiten von Quelltextänderungen automatisch dokumentiert wird, wer was wann geändert hat. Die meisten Unternehmen, die Software entwickeln, werden das schon aus rein organisatorischen Gründen längst so machen.
Neu für einige Entwickler dürfte die Forderung nach statischer Codeanalyse sein, also nach Programmen, die den Quellcode gegenlesen und auf typische Schwachstellen untersuchen. Hier gibt es ebenfalls gute Open-Source-Lösungen, z. B. die freie Variante CPPCheck.
Die Frage nach der Dokumentation
Ein Punkt, der auch in Teil 2 angesprochen wird, sind "Fuzzing Tests". Sie sollen sicherstellen, dass die exponierten Schnittstellen robust genug sind, um Angriffen standzuhalten. Bei diesen Tests werden die Schnittstellen gezielt mit fehlerhaften Daten und Syntaxfehlern bombardiert, um zu prüfen, ob sich Zugriffsrechte erschleichen lassen oder die Schnittstelle dadurch einfach unbrauchbar wird.
Auch das ist für Softwareentwickler eigentlich nichts Neues. Neu ist aber, dass durch den Verweis auf die IEC aus der ISO heraus nun die Frage nach der Dokumentation gestellt werden kann. Hier ist vor allem der Steuerungshersteller oder der Hersteller eines Cloud-Gateways gefordert.
Auch die regelmäßigen CANopen-Plugfeste, bei denen firmenübergreifend die CANopen-Schnittstellen des jeweils anderen auf Kompatibilität mit dem eigenen Produkt getestet werden, sind eine Maßnahme, die in die Umsetzung des Teils 2 der IEC 62443-4 einfließen kann.
Fazit
Cybersecurity ist nicht nur eine Frage der Softwareentwicklung, sondern vor allem eine Frage der Organisation im Unternehmen. Niemand kann allein für Cybersecurity sorgen! Dazu gehören die sichere Entwicklung und sorgfältige Tests aber auch die Nutzer, die durch ihr Verhalten direkt dazu beitragen können, die Aufzüge vor unbefugtem Zugriff zu schützen. Einer allein in der Kette kann dies nicht leisten!
Der Autor ist Senior Software Ingenieur bei Thor, einem Steuerungs-Softwarehersteller.
Ausblick: Auf die ISO 8102-20 folgt nun die ISO 8102-21, die sich mit dem Thema der Softwareaktua-lisierung beschäftigt. Sie fordert zum Beispiel, dass der Hersteller einer Software dem Tech-niker am Ende der Kette beschreiben muss, wie er ein Back-up und ein Update ausführen muss. Dazu gehört auch, dass der Techniker am Ende sicherstellen kann, dass die Datei, die er auf der Komponente installiert, auch die Datei ist, die der Hersteller zuvor freigegeben hat (Stichwort Checksumme/Hash). Denn auch auf dem digitalen Transportweg und bei der Lagerung auf Fileservern ist ein Angriff oder eine Manipulation möglich.
Kommentar schreiben