HINWEIS: Dieser Artikel richtet sich nicht nur an Unternehmen, die bereits gehackt wurden... Die IEC 62443 ist ein generischer Standard, der in kritischen Sektoren wie der Fertigung, dem Energiesektor, dem Transportwesen, dem Gesundheitswesen und vielen anderen als anwendbar gilt.
Dieser Artikel ist die zweite Folge einer Serie von 8 Artikeln, die die wichtigsten Praktiken abdeckt, die von jeder Organisation implementiert werden müssen, die den Stand der Technik in der Cybersicherheit für industrielle und automatisierte Steuerungssysteme erfüllen will. Auf der Grundlage eines pragmatischen Ansatzes zeigt dieser Artikel, wie Sie die Definition von Anforderungen in Bezug auf einen sicheren Entwicklungslebenszyklus (IEC 62443-4-1) innerhalb Ihrer aktuellen Organisationsprozesse handhaben können.
Um systematisch sichere Produkte zu entwickeln, muss die Sicherheit über den gesamten Software-Lebenszyklus hinweg betont werden, so dass die Ergebnisse "secure by design" sind. Daher muss jede Phase eines gängigen Software-Lebenszyklus mit Sicherheitspraktiken angereichert werden. Dies führt zu einem sicheren Entwicklungslebenszyklus, wie unten dargestellt. In dieser zweiten Folge konzentrieren wir uns auf gute Praktiken, die erforderlich sind, um ein sicheres System von Anfang an zu erstellen, den Secure Design Process.
Der Begriff "Security by Design " beschreibt Praktiken, mit denen sichergestellt wird, dass ein Produkt sicher ist und von Beginn der Entwurfsphase an Defense-in-Depth-Prinzipien folgt. Die für den sicheren Entwurf erforderlichen Prozesse müssen in allen Phasen des Produktentwurfs angewendet werden, vom konzeptionellen Entwurf bis zum detaillierten Entwurf und auf allen Ebenen des Produktentwurfs, von der Gesamtarchitektur bis zum Entwurf einzelner Komponenten.
Im Normteil 62443-4-1 werden vier Hauptthemen für sicheres Design angesprochen. Diese Punkte werden im Folgenden beschrieben.
Erstens ist eine sichere Entwurfsdokumentation erforderlich, um sicherzustellen, dass die Sicherheit für den Zugriff auf Assets aus der Perspektive der externen und internen Schnittstellen des Produkts, über die Angriffe erfolgen können, umfassend behandelt wird. Dieser Prozess bedeutet, dass die Schnittstellen des Produkts identifiziert und durch die über sie stattfindenden Interaktionen (z. B. Daten- und Kontrollflüsse), die zu ihrem Schutz vorgesehenen Sicherheitsmechanismen und die Assets, die bei unzureichendem Schutz kompromittiert werden können, charakterisiert werden. Die Betrachtung der Schnittstellen innerhalb des vom Produktsicherheitskontext vorgegebenen Rahmens ermöglicht es dem Sicherheitsentwurf, sich auf die spezifische Umgebung zu konzentrieren, in der das Produkt voraussichtlich betrieben wird, einschließlich der vom Produktsicherheitskontext gebotenen Schutzmaßnahmen und der daraus resultierenden Schwachstellen. Im Folgenden wird ein Beispiel vorgestellt. Die gleiche Frage sollte für jede Schnittstelle in einem systematischen Ansatz beantwortet werden:
Zweitens ist ein "Defense in depth"-Design erforderlich. Dieses Prinzip besteht darin, mehrere Sicherheitsschichten bereitzustellen, um Sicherheitsbedrohungen zu vereiteln. Jede Schicht einer Defense-in-Depth-Strategie ist so konzipiert, dass sie die Assets vor Angriffen schützt, falls alle anderen Schichten kompromittiert wurden. Es muss ein Prozess eingesetzt werden, um diese mehreren Verteidigungsschichten unter Verwendung eines risikobasierten Ansatzes auf der Grundlage des Bedrohungsmodells zu implementieren.
Zum Beispiel könnte der TCP/IP-Stack auf ungültige Pakete prüfen, ein HTTP-Server könnte Eingaben authentifizieren, und dann könnte eine andere Schicht validieren, dass die Eingaben und Audit-Protokolle für administrative Änderungen erstellt werden. Jede Schicht bietet einen zusätzlichen Verteidigungsmechanismus, hat eine Verantwortung und bietet eine Reduzierung der Angriffsfläche für die nächste Schicht. Jede Schicht geht davon aus, dass die vor ihr liegende Schicht kompromittiert werden kann. Die folgende Abbildung zeigt diesen Ansatz in einem größeren Maßstab.
Drittens ist eine Überprüfung des Sicherheitsentwurfs erforderlich, um sicherzustellen, dass der Sicherheitsentwurf die für das Produkt definierten Anforderungen und Bedrohungen berücksichtigt und dass die Best Practices für den Entwurf befolgt wurden (siehe letztes Thema). Alle entdeckten sicherheitsrelevanten Probleme sind zu dokumentieren und nachzuverfolgen. Die Durchführung dieses Prozesses bedeutet, dass jede Version des Entwurfs überprüft wird, um festzustellen:
- ob irgendwelche Produktsicherheitsanforderungen durch die Defense-in-Depth-Strategie nicht ausreichend berücksichtigt wurden
- ob es Bedrohungsvektoren (Pfade, denen Bedrohungen folgen) gibt, die die Defense-in-Depth-Strategie umgehen oder die auf andere Weise in der Lage sind, die Defense-in-Depth-Strategie zu durchbrechen.
In jedem Fall ist das Bedrohungsmodell zu aktualisieren, um sicherheitsrelevante Probleme zu berücksichtigen, die als Ergebnis des Überprüfungsprozesses entdeckt wurden.
Als viertes und letztes Thema sind Best Practices für den sicheren Entwurf erforderlich, um sicherzustellen, dass den Entwicklern Anleitungen zur Verfügung gestellt werden, die ihnen helfen, häufige Fallstricke während des Entwurfs zu vermeiden, die zu späteren Sicherheitsproblemen führen könnten. Ein solcher Prozess bedeutet, dass der Produktlieferant über eine Liste von Best Practices für die Sicherheit verfügt, die während der Entwicklung des sicheren Entwurfs für das Produkt gepflegt und befolgt wird. Diese Best Practices sollten auf den allgemein akzeptierten Best Practices der Industrie für die Art des zu entwickelnden Produkts basieren. Es liegt ganz im Ermessen des Lieferanten, welche Praktiken er für seine Entwurfspraktiken für am besten geeignet hält. Diese Praktiken werden sowohl durch Änderungen in der Branche als auch durch die Anwendung der vom Produktlieferanten gewonnenen Erfahrungen auf dem neuesten Stand gehalten.
Beispiele für bewährte Verfahren finden Sie unten:
- Least Privilege (Gewährung von nur den Rechten an Benutzer/Software, die zur Durchführung der beabsichtigten Operationen erforderlich sind);
- Verwendung bewährter sicherer Komponenten/Designs, wo immer möglich;
- Ökonomie der Mechanik (Streben nach einfachen Konstruktionen);
- Verwendung sicherer Entwurfsmuster;
- Reduzierung der Angriffsfläche;
- die Dokumentation aller Vertrauensgrenzen als Teil des Designs;
- das Entfernen von Debug-Ports, Headern und Traces von Leiterplatten, die während der Entwicklung verwendet werden, von der Produktionshardware oder das Dokumentieren ihres Vorhandenseins und der Notwendigkeit, sie vor unberechtigtem Zugriff zu schützen.
Auch wenn die Einhaltung der 62443 nicht das ultimative Ziel ist, sollte der sichere Designprozess als Basis betrachtet werden, die von der Organisation, die ein sicheres Produkt entwickelt, implementiert und gehandhabt werden muss.
Wenn Sie Fragen zu sicheren Design-Prozessen und/oder Zertifizierungskriterien haben, zögern Sie bitte nicht, unseren Cyber-Security-Spezialisten zu kontaktieren: Kilian Marty