Security-by-Design in der Automatisierungstechnik: Die 8 Practices der IEC 62443
Ein Überblick über die acht Practices der IEC 62443 für einen sicheren Entwicklungsprozess (Security Development Lifecycle) aus Herstellersicht. Welche Anforderungen gibt es? Worauf muss ein Produkthersteller achten, um OT-Security für seine Abnehmer gewährleisten zu können?
Im Beitrag „Grundlagen der IEC 62443 – ein Überblick für Produkthersteller“ wurde bereits ein einführender Überblick zu Aufbau und Struktur der Normreihe IEC 62443 „IT-Sicherheit für industrielle Automatisierungssysteme“ gegeben. In diesem weiterführenden Beitrag geht es nun um die sogenannten 8 Practices, um einen sicheren Entwicklungsprozess (Security Development Lifecycle) aus Herstellersicht zu etablieren: Welche Anforderungen gibt es? Wie sind diese konkret zu verstehen? Worauf muss ein Produkthersteller achten, um OT Security für seine Abnehmer gewährleisten zu können?
Bis auf Practice 1 („Security Management“) und Practice 8 („Security Guidelines“) folgen Practice 2 bis 7 in der Aufteilung einem klassischen Entwicklungsmodell ausgehend von den Anforderungen, über das Design, die Implementierung, das Testing und Fehler Management, bis zum Umgang mit Updates. In diesem Sinne beginnt auch dieser Beitrag mit Practice 2, um am Ende mit Practice 1 zu schließen.
Practice 2: Specification of Security Requirements
Zu Beginn von Entwicklungsprojekten werden Anforderungen an das Produkt definiert. Im Rahmen dieser Practice geht es nicht um funktionale Anforderungen, sondern explizit nur um die Anforderungen, welche die Security-Eigenschaften des Produktes betreffen. Hier gibt die Norm vor, dass ein Bedrohungsmodell (Threat Model) erstellt werden muss. Im Rahmen der Bewertung möglicher Bedrohungen müssen Strategien entwickelt werden, diese Bedrohungen zu mitigieren. Aus diesen Strategien folgen dann wiederum Anforderungen.
Als Beispiel betrachten wir eine Webanwendung mit Anmeldemaske. Eine mögliche Bedrohung wäre, dass Angreifer so lange verschiedene Kombinationen aus Benutzername und Passwort ausprobieren, bis sie eine valide Kombination gefunden haben (Brute-Force-Angriff). Eine mögliche Mitigation dieser Bedrohung wäre das Sperren eines Accounts für 10 Minuten nach 3 erfolglosen Anmeldeversuchen. Diese Mitigation wäre dann als eine Security-Anforderung zu definieren.
Practice 3: Secure by Design
Die Anforderungen dieser Practice haben zum Ziel, ein sicheres Komponentendesign zu entwickeln. Dadurch wird sichergestellt, dass Security fest im Produkt verankert ist. Ein zentrales Konzept der IEC 62443 ist das Defense-in-Depth-Konzept. Hierbei müssen – wie bei Zwiebelschalen – mehrere Schichten entwickelt werden, von denen jede Schicht eine bestimmte Verteidigungsfunktion übernimmt. Als äußere Zwiebelschale kann beispielsweise eine Firewall Angreifer abwehren. Falls Angreifer diese Firewall überwinden, können Angriffe durch ein Intrusion Detection System erkannt und gegebenenfalls abgewehrt werden.
Einen Freiheitsgrad, den die Norm bezüglich eines Defense-in-Depth-Konzepts erlaubt, ist das Auslagern von Funktionen bzw. Verteidigungsschichten in die Systemumgebung. Wird ein Teil der Verteidigungsfunktionen von der Umgebung sichergestellt, spricht man auch von met-by-integration. Werden Funktionen von der Komponente selbst sichergestellt, spricht man von met-by-component.
Practice 4: Secure Implementation
Practice 4 fordert, das sichere Design auch sicher in Soft- und/oder Hardware umzusetzen. Zum einen muss dazu ein 4-Augen-System eingeführt werden. Weiterhin müssen Secure-Coding-Guidelines aufgestellt und befolgt werden. Diese Guidelines müssen sich auf mehrere Abstraktionsschichten beziehen. Je nach verwendeter Programmiersprache sollten Funktionen verboten werden, sodass diese vom Entwickler nicht verwendet werden. Darüber hinaus dürfen keine Code-Konstrukte verwendet werden, die ein mögliches Sicherheitsrisiko zur Folge haben. Auch Design-Konstrukte mit möglichen Sicherheitsrisiken dürfen nicht verwendet werden, z. B. die fehlende Überprüfung von Input-Werten.
Practice 5: Security Verification and Validation Testing
Practice 5 stellt sicher, dass erstellte Software adäquat getestet und somit einer umfangreichen Qualitätssicherung unterworfen wird, bevor sie veröffentlicht wird. Dies geschieht durch die Verpflichtung zu verschiedenen Tests, wie z. B. funktionale Tests von Security-Anforderungen, Penetrationtests oder Robustnesstests. Um sicherzustellen, dass kein Interessenskonflikt zwischen Testern und Entwicklern auftritt, gibt die Norm für verschiedene Tests verschiedene Grade der Unabhängigkeit vor. Beispielsweise müssen Penetrationtests unabhängig vom Entwicklungsteam durchgeführt werden.
Practice 6: Management of Security Related Issues
Für Kolleginnen und Kollegen stellt es immer wieder eine äußerst frustrierende Situation dar, wenn sie in Produkten Schwachstellen finden, diese den Verantwortlichen melden wollen, und dort auf taube Ohren stoßen. Die Umsetzung dieser Practice sorgt dafür, dass genau dies nicht geschieht. Die zentrale Anforderung hierbei ist, dass es eine dedizierte Meldekette von Schwachstellen geben muss. Diese muss allen potentiellen Anlaufstellen bekannt sein und sowohl die Möglichkeit berücksichtigen, dass eine Schwachstelle von intern, als auch von extern gemeldet wird.
Weiterhin werden hier Anforderungen an den darauffolgenden Prozess definiert. Dies beinhaltet die Bewertung von potenziellen Sicherheitslücken sowie der Umgang mit deren Veröffentlichung. Die Norm gibt hier keine harten Vorgaben an den Prozess. Wie vorgegangen wird, dies kann innerhalb der Organisation geregelt werden.
Practice 7: Security Update Management
Logische Folge der Behandlung einer Sicherheitslücke ist das Ausrollen eines Updates, um diese Sicherheitslücke zu schließen. In Practice 7 werden nun die Anforderungen an Updates beschrieben. Hier muss unter anderem sichergestellt werden, dass ein Update die Sicherheitslücke auch wirklich schließt. Um den Stillstand einer Anlage zu verhindern, muss ein Update im Rahmen seiner geplanten Betriebsumgebung funktionsfähig sein. Die Norm verbietet daher das Deaktivieren einer fehlerhaften Funktion und erzwingt die Korrektur selbiger.
Practice 8: Security Guidelines
Nachdem in den Practices 2 bis 7 nun alle Schritte eines klassischen Entwicklungs- bzw. Produktlebenszyklus, von der Definition der Anforderungen bis hin zur Updatefähigkeit abdeckt, werden in dieser Practice abschließend Anforderungen an Handbücher formuliert. Hier werden keine Anforderungen an die Handbücher zur Bedienung gestellt, sondern lediglich zur sicheren Bedienung. Mit anderen Worten: Die Handbücher müssen die Frage beantworten, was ein Kunde machen muss, um Angriffe auf das Produkt möglichst schwierig zu gestalten. Hier muss die komplette Lebensdauer von der In- bis zur Außerbetriebnahme betrachtet werden. Beispielsweise kann der Kunde dazu aufgefordert werden, bei der Inbetriebnahme ein neues Passwort zu vergeben und bei der Außerbetriebnahme alle Daten zu überschreiben.
Practice 1: Security Management
Practice 1 beinhaltet nun einige Punkte, die sich nur schwer thematisch gruppieren lassen und außerhalb eines klassischen Entwicklungszyklus stehen. Stellvertretend soll hier auf einige Punkte gezielt verwiesen werden. So fordert die Norm sowohl Konsistenz mit, als auch die Eingliederung in einen übergeordneten Entwicklungsprozess. Hierdurch kann sichergestellt werden, dass die Prozessschritte, die die Norm vorgibt, auch konsequent angewendet werden. Die Norm lässt aber ganz explizit die Freiheit nur auf einzelne Produkte oder Produktlinien angewandt zu werden.
Weiterhin wird hier wie auch in fast allen anderen Practices eine ständige Verbesserung durch Feedbackschleifen gefordert. Die jeweiligen Prozesse müssen also ständig überprüft und bei Bedarf verbessert werden. Hinsichtlich der Security in der Entwicklungsumgebung selbst gibt es punktuell eine gewisse Redundanz zu Informationssicherheitsmanagementsystemen (ISMS) wie nach ISO/IEC 27001. Hier werden Anforderungen an die IT Security im Entwicklungsprozess auf verschiedenen Abstraktionsebenen gestellt. Zum einen gibt es Anforderungen auf der Systemebene (z. B. an die Entwicklungsrechner) und zum anderen gibt es Anforderungen auf der Prozessebene (z. B. an den Umgang mit Signing-Keys).
In dieser Practice wird weiterhin auch auf die Lieferkette Bezug genommen. Es muss sichergestellt werden, dass Subkomponenten keine Sicherheitslücken verursachen. Die Norm differenziert hier zwischen 3rd-Party-Komponenten (z. B. Open-Source Programmbibliotheken) und Komponenten, die explizit für den Anwender der Norm entwickelt wurden. Ebenso muss der Anwender sicherstellen, dass eine gewisse Security-Expertise im Unternehmen vorhanden ist. Dies geschieht typischerweise durch Weiterbildungen.
Bis hierher wurde die IEC 62443-4-1 inhaltlich vorgestellt. Die Menge der Themen erfordert aber auch einen pragmatischen Umgang mit den knapp 50 Detailanforderungen der Practices. Hierzu bietet die Norm ein Reifegradmodell an, welches vier Stufen definiert, die Maturity-Level ML-1 bis ML-4. Über diesen Ansatz ist es möglich festzustellen, wo ein Anwender der Norm in Bezug auf eine Anforderung steht. Des Weiteren kann so über die acht Practices sowie über die gesamte Norm ein zusammengefasster Reifegrad ermittelt werden. Die Norm definiert dies zwar nicht explizit, in der praktischen Anwendung findet dies aber statt. Will man die Norm nun umsetzen, bietet es sich an, ML-2 über alle Anforderungen als Meilenstein zu definieren. Dies stellt sicher, dass alle Prozesse korrekt aufgesetzt und beschrieben sind. Durch die Anwendung im Rahmen einer Produktentwicklung wird dann quasi automatisch ML-3 als nächste Stufe erreicht.
