Wie wird eine Maschine von Anfang an sicher im Sinne von »secure« entwickelt?
Es wird nicht funktionieren, eine Maschine als eine vom Rest der Welt unabhängige Insel zu entwickeln und danach Security »überzustülpen«. Jetzt nicht (mehr) und in ein paar Monaten erst recht(lich) nicht mehr. Ich möchte die Kolumne nicht mit der IEC 62443 Teil 4-1
»Anforderungen an den Lebenszyklus für eine sichere Produktentwicklung « erschlagen, auch wenn der Verweis dorthin zumindest für die Entwicklung von Produkten und im ferneren Ansatz für Maschinen bzw. Anlagen nahe liegend und empfehlenswert ist. Unabhängig von Normen und
Good-Practices sowie gesetzlich-extrinsischer Motivation zur Anwendung dieser, möchte ich eine mitunter neue Denkweise im Entwicklungsprozess adressieren.
Zweifelsfrei gilt das nicht für alle Unternehmen, aber die meisten werden sich vermutlich darin wiederfinden, dass die Prioritäten in der Entwicklung einer neuen Maschine oder Anlage darauf liegen, dass die Anforderungen hinsichtlich Funktionalität und Leistung kostenoptimiert erfüllt werden.
Die Mechanik soll mit geringstmöglichem Material- und Fertigungsaufwand den zu erwartenden Lasten standhalten können. Dies gilt analog auch für die Elektrik, die Automatisierung, die Software etc. Sofern etablierte Vorgänger bestehen, auf denen eine Evoltionsstufe aufbaut, soll
möglichst viel Bestand übernommen werden. »Never touch a running system« ist ein Mantra oftmals nicht nur bei Endanwendern im Sinne von Betreibern, sondern auch bei Entwicklern. Da bleibt es dann gut und gerne bei einer flachen Netzwerkstruktur, bei Default-Passwörtern und bei
Konfigurationsfehlern, die niemand hinterfragt hat. Das Hinterfragen ist es aber letztlich, was uns weiterbringt! Der Mechanik-Entwickler fragt sich, wie er das Bauteil noch leichter, einfacher zu fertigen und somit günstiger machen kann, der Automatisierungs-Spezialist fragt
sich wie er den Prozess noch weiter optimieren kann usw. Aber wer fragt sich: Wenn jemand böse wäre, wie könnte er/sie in mein System eindringen? Was könnte man mit diesen Daten und dem erworbenen Wissen anstellen? Welchen (maximalen) Schaden könnte man damit verursachen?
Das sind jedoch zentral wichtige Fragen. Zweifelsfrei stehen dahinter auch gesetzliche sowie vertragliche Anforderungen und es ist die Essenz des Risikomanagements aus zahlreichen Normen und Good-Practices, aber es ist vor allem auch eine gedankliche Einstellung, die einen ständig begleiten
sollte.
Fragwürdig? Ja, im wahrsten Sinne des Wortes. Es ist zu fragen. Es muss gefragt werden. Solange man den »White (Hard-)Hat« behält. Wir sperren auch die Büroeingangstüre ab, weil man ganz selbstverständlich daran denkt, dass eingebrochen werden könnte und nicht nur, weil es die
Versicherung fordert. Wieso dann nicht unbenötigte Services abschalten, die auf Anfragen von außen antworten? Wer stellt diese Frage in Ihrer Entwicklungsabteilung? Erst wenn die Antworten auf diese Fragen existieren, kennt man die Risiken und das maximale Gefährdungsereignis. Erst dann
macht es Sinn, entsprechende zielgerichtete Milderungsmaßnahmen, z.B. nach der IEC 62443 Teil 3-3 oder 4-2, umzusetzen und zu validieren.
In diesem Sinne, ganz international: Know your risks and how bad it can get!
erschienen in der Austromatisierung | Ausgabe 05-2024 | August 2024