top of page

Risikonanalyse

Verschaffen Sie sich einen Überblick

Zu Beginn der Security-Betrachtung steht die Risikoanalyse, die als integraler Bestandteil des Entwicklungsprozesses der Maschine etabliert werden soll. Schon bei der ersten  Anforderungsanalyse zu Beginn der Entwicklung  können so Security-Aspekte in das Konzept und den Entwurf der Maschine einfliessen.

Die frühe Einbindung einer Risikoanalyse in den Konstruktions- und Entwicklungsprozess bedeutet zwar einen oftmals ungewohnten anfänglichen Mehraufwand, dieser lässt sich jedoch durch strukturiertes, wiederholbares Vorgehen auf ein überschaubares Maß reduzieren. Es hat sich als sinnvoll erwiesen, hierbei im Betrieb etablierte Methoden (wie etwa FMEA – Failure Mode and Effects Analysis) für die Risikobetrachtung zu adaptieren. Vor allen Dingen aber zahlt sich dieser frühe Mehraufwand im weiteren Verlauf der Entwicklung aus, da Security-Funktionen als integraler Bestandteil der Maschine aufgefasst werden können und diese nicht nachträglich teuer nachgerüstet werden müssen.

 

Alle nachfolgenden Schritte innerhalb der Risikoanalyse sollen während des Entwicklungsprozesses sowie regelmäßig zur Betriebszeit mit und ohne Gewährleistung seitens des Herstellers berücksichtigt werden.

 

Ein effizientes Vorgehen lässt sich auf die folgenden Punkte reduzieren (siehe auch die Richtlinie VDI/VDE 21821).

 

 

Identifikation der schutzbedürftigen Werte

Zunächst sollte ein Konsens darüber bestehen, welche Komponenten innerhalb der Maschine einen schutzbedürftigen Wert darstellen. Dies können beispielsweise Hardware- und Softwarekomponenten sein, aber auch Daten und Programme, die als geistiges Eigentum einen hohen Wert darstellen. Als erster Schritt ist also die Bewusstwerdung über materielle und immaterielle Werte zu empfehlen, die sich dann in der Identifikation und Auflistung der jeweiligen Komponenten widerspiegelt.

Ermittlung der Schutzziele

Nun lassen sich für die schutzbedürftigen Wert Schutzziele formulieren. Wurde einer speziellen Komponente innerhalb der Maschine (im ersten Schritt) ein hoher Wert zugemessen, so sollte ein entsprechendes Schutzziel für diese Komponente formuliert werden. Für einen Datensatz innerhalb der Maschine, der als kritisch eingestuft wurde und von dem auch das Funktionieren weiterer verbundener Maschinen abhängt, könnte das Schutzziel beispielsweise lauten: „Garantierte Verfügbarkeit der Daten bei Maschinen-Fernzugriff“.

Identifikation der Bedrohungen

Hat man die schutzbedürftigen Komponenten der Maschine identifiziert, lassen sich als nächstes Überlegungen zu den zugehörigen Bedrohungen anstellen. Eine Bedrohungsanalyse gibt Aufschluss darüber, mit welchen praktischen Bedrohungen man beim Betrieb der Maschine zu rechnen hat und welchen jeweiligen Schaden man ansetzen sollte. Als Hilfestellung bieten sich hier gängige Zusammenfassungen und Auflistungen aktueller Bedrohungen an, wie z.B. die Zusammenstellung des Bundesamtes für Informationstechnik (BSI)2. 

Risikobewertung

Es lassen sich nun auf Basis der Bedrohungsanalyse die den Bedrohungen zugeordneten Risiken bewerten. So ist das Risiko einer ausgeführten Bedrohung der mit der jeweiligen Eintrittswahrscheinlichkeit gewichtete Gesamtschaden. Die Bewertung erfolgt anhand eines vorab zu erstellenden Angreifermodells. In diesem werden die Annahmen zu den Fähigkeiten eines möglichen Angreifers festgehalten.

Eine vollständige Ermittlung aller Risiken und deren Priorisierung führt direkt zur Auswahl geeigneter Schutzmaßnahmen und bildet daher die Grundlage für eine optimale Absicherung der Maschine oder Anlage. Gleichzeitig kann eine umfassende Risikoanalyse sehr umfangreich sein und für ein mittelständisches Unternehmen einen nicht tragbaren Aufwand bedeuten.

 

Deshalb wird empfohlen, den Ansatz einer Risikoanalyse zumindest dahingehend in den Entwicklungsprozess zu integrieren, dass schutzbedürftige Werte erkannt und zugehörige Schutzziele formuliert werden und dass sich die jeweiligen Verantwortlichen in Planung und Entwicklung der Maschine über die gängigen Bedrohungen bewusst sind. In diesem Sinne stellt dieser Leitfaden ein Kompromiss zwischen dem Status quo einer oftmals nicht stattfindenden Security-Betrachtung und der idealen Ermittlung aller Schutzmaßnahmen auf Basis einer detaillierten Risikoanalyse dar. 

Risikoananlyse (Anker)

Netzsegmentierung

Teile und herrsche!

Die Anlage soll anhand des Schutzbedarfs der einzelnen Systemteile in Zonen aufgeteilt werden. Die verbundenen Maschinen und Komponenten innerhalb einer Zone zeichnen sich hierbei durch ähnlichen Schutzbedarf aus. Die Trennung der einzelnen Segmente sollte durch technische Maßnahmen realisiert sein. 

Definition des Risiko-basierten

Schutzbedarfs, der den Anlagen und Komponenten zugeordnet wird. Die Ermittlung des Schutzbedarfs soll anhand gängiger Methoden zur Risikoabschätzung vorgenommen werden. Es sollen hierzu zunächst die schutzbedürftigen Werte identifiziert werden. Nach der Ermittlung entsprechender Schutzziele erfolgt dann eine Bedrohungsanalyse. Eine Risikoanalyse liefert dann Aufschluss über den Schutzbedarf der Anlagen und Komponenten. Die Zuordnung des so ermittelten Schutzbedarfs ist Voraussetzung für die Ermittlung von Zonen, d.h. Netzsegmenten mit Komponenten vergleichbaren Schutzbedarfs. 

Zonierung der Dienste

Die verschiedenen Netzbereiche der Produktion (wie z.B. ERP-, MES- oder SCADA-Netz) zeichnen sich insbesondere durch die bereitgestellten Dienste aus. Bei der Zonierung sollen insbesondere auch diese Dienste innerhalb des Produktionsnetzes berücksichtigt werden.

 

So soll sichergestellt werden, dass sich innerhalb des unmittelbar mit der Maschine verbundenen Netzsegmentes ausschließlich Dienste mit vergleichbarem Schutzbedarf befinden. Dienste können beispielsweise Softwaremodule zur Verarbeitung oder Bereitstellung von Maschinendaten sein, aber auch Konfigurationsmodule, welche Maschinenfunktionen entsprechend einer Konfigurationsdatei zusammenstellen.


Bei der Zonierung soll darauf geachtet werden, dass bei Ausfall einer Zone möglichst wenig andere Zonen betroffen sind.

Einsatz von Isolationsmassnahmen

Sind den Hardware- und Softwarekomponenten der Maschine Sicherheitszonen zugeordnet, sollen diese durch technische Maßnahmen ausreichend voneinander getrennt werden. Dies soll bei einer Kompromittierung eines Teilbereiches der Maschine die Ausbreitung in das Gesamtsystem erschweren.

 

Mögliche technische Maßnahmen zur Trennung der ausgewiesenen Segmente können z.B. Firewalls oder Datendioden sein. Für die Maschine bedeutet dies insbesondere, dass sie abhängig vom Schutzbedarf nicht nur Filterfunktionen für aus- und eingehende Kommunikation bereitstellen soll, sondern auch für Kommunikation innerhalb der Maschine selbst.

 

Es wird empfohlen, die Erkennung von Schadsoftware oder Protokollanomalien anhand der Netzwerkkommunikation zwischen den definierten Netzsegmenten durchzuführen. Solche Schutztechnologien kommen oft direkt auf Firewalls zum Einsatz. 

 

Für besonders gefährdete Netzsegmente sollen Datendioden sicherstellen, dass Informationen ausschließlich in eine vordefinierte Richtung fließen. Hierbei ist jenen Lösungen der Vorzug zu geben, bei denen die Isolation durch eine hardwaremäßige Trennung erfolgt. Um Datendioden sinnvoll einsetzen und anpassen zu können, sollen sämtliche Datenflüsse in und aus der Maschine identifiziert werden.

 

Ferner ermöglichen VPN-Lösungen das Zusammenfassen räumlich getrennter Netze zu einem Segment, um ähnliche oder gleiche Anlagen trotz räumlicher Entfernung gemeinsam verwalten zu können. 

Periodische Überprüfung der Isolationsmassnahmen auf Effektivität und Patchbarkeit von Filterkomponenten

Isolationsmaßnahmen auf Effektivität und Patchbarkeit von Filterkomponenten Die technischen Isolationsmaßnahmen sollen regelmäßig hinsichtlich ihrer Effektivität überprüft werden können. Im Falle von Firewalls und anderen Filtertechniken kann eine regelmäßige Überprüfung der Filterregeln notwendig sein.

 

Der Anlagenbauer soll eine Updatefähigkeit gewährleisten, sodass diese Aufgabe entweder vom Betreiber selbst durchgeführt werden kann, oder als Service dem Betreiber angeboten wird. Der zeitliche Abstand zwischen den Überprüfungen hängt dabei sehr stark von der jeweiligen Maschine ab. Während Maschinen mit geringer Konnektivität auch mit relativ statischen Filterregelnsicher konfiguriert werden können, sollten die Filterregeln bei Maschinen mit hoher Funktionsvariabilität und entsprechender Kommunikation häufiger überprüft und angepasst werden. 

Auch muss davon ausgegangen werden, dass sich der Schutzbedarf einer Anlage durch Produktumstellungen oder Umbau/Umzug ändert, wodurch weitere Anpassungen an der Netz- und IP-Konfiguration notwendig sein können. Im Falle von bekannt gewordenen Schwachstellen in den Filterkomponenten soll sichergestellt sein, dass die betroffenen Module vom Hersteller zeitnah gepatcht werden können. 

DNS und andere Services pro Zone

Vor dem Hintergrund des zu erwartenden starken Anstiegs von kommunikationsfähigen Komponenten innerhalb der Anlage ist davon auszugehen, dass zentrale DNS-Server mit der Gesamtheit der Anfragen aus der Anlage zunehmend überlastet werden. Deshalb soll die Netzsegmentierung so weit wie möglich auf die DNS-Infrastruktur abgebildet werden. Aufgrund teils sehr komplexer Netze und einer großen Zahl an Netzsegmenten ist hier auch denkbar, mehrere Segmente mit ähnlichem Schutzbedarf einem einzelnen DNS-Server zuzuordnen. Da die DNS-Konfiguration sowohl vom Integrator als auch vom Betreiber vorgenommen wird, sollen die Maschinen und Anlagen die entsprechende Funktionalität zur flexiblen Konfiguration gewährleisten.

Quelle: VDMA Leitfaden Industrie 4.0 Security

Netzsegmentierung

Benutzerkonten, Credentials, Authentisierung und Autorisierung

Nicht jeder darf alles machen…

Die Anlage soll das sichere Verwalten von Benutzerkonten und zugeordneter Zugangsdaten (Credentials, z.B. Passwörter, Token, SSH-Schlüssel oder biometrische Authentisierungsdaten) gewährleisten.

Individuelle Benutzerkonten

Es sollen individuelle Benutzerkonten für jeden Akteur eingerichtet werden können. Als Akteure sind sowohl mit der Maschine interagierende Menschen gemeint, aber auch andere Maschinen und Systeme, die auf bereitgestellte Dienste zugreifen. Dies bezieht sich sowohl auf Akteure, die via Fernzugriff mit der Maschine interagieren, als auch auf Akteure mit lokalem Zugriff.

 

Nur so kann eine auf den Akteur beziehbare Protokollierung aller Zugriffe auf die Maschine stattfinden, welche wiederum in die Angriffserkennung und die Untersuchung von IT-Sicherheitsvorfällen einfließt.

 

Hierbei ist zu beachten, dass dem Betreiber die Möglichkeit gegeben werden soll, sämtliche Benutzerkonten von Maschinen zu dokumentieren und diese jeweils einem menschlichen Verantwortlichen zuzuordnen, der über Herkunft und Wirkweise des technischen Kontos informiert ist. 

Auch sind individuelle Benutzerkonten Grundlage für eine nachfolgende Rechteverteilung auf Individuen und Rollen. Hierbei ist insbesondere zu berücksichtigen, dass es keine Konten für eine Gruppe von mehreren Akteuren geben soll: Benutzerkonten sind nicht nur aufgrund von zugeordneten Rollen, sondern individuell für jeden Nutzer der Anlage zu erstellen.

Account Management

Die Menge der Akteure kann je nach Einsatzumgebung der Maschine starker Fluktuation unterliegen. Im günstigsten Fall wird die Maschine für lange Zeitabschnitte von derselben Gruppe von Akteuren bedient. Im ungünstigsten Fall wechseln die Akteure sehr oft, mitunter bedienen sie die jeweilige Maschine nur wenige Schichten.

 

Die Maschine soll deshalb eine effiziente Handhabung zur Verwaltung der individuellen Benutzerkonten gewährleisten, insbesondere in Bezug auf das Hinzufügen, Aktivieren, Modifizieren, Abschalten und Beseitigen von Konten.

 

Dies ist oftmals durch eine zentrale Verwaltung der Benutzerkonten zu erreichen. So wird empfohlen, dass die Maschine eine Integration in bestehende Identitätsmanagementsysteme oder die Einbindung der Benutzerkonten in Verzeichnisdienste unterstützt. 

Verteilung und Management der Credentials(Zugangsdaten)

Jedes der individuellen Benutzerkonten ist mit Zugangsdaten verknüpft, die zur späteren Authentisierung und Autorisierung dem jeweiligen Akteur bekannt sein sollen. Das Management dieser Credentials soll hierbei so gestaltet sein, dass eine sowohl sichere als auch effiziente Verteilung möglich ist.

 

Praktisch bedeutet dies, dass das Verfahren zum Zurücksetzen der Credentials bei Verlust zwar dem jeweiligen Schutzbedarf entspricht, jedoch so flexibel gestaltet werden soll, dass der Betrieb der Maschine immer gewährleistet ist.

 

Dies soll Ausfallzeiten aufgrund zu komplexer Rücksetzungsregelungen verhindern. Bei Einsatz von Passwörtern soll gewährleistet sein, dass beim Zurücksetzen auch Default-Passwörter verändert werden können. 

 

Die Erstellung der Credentials soll aktuellen Standards und Empfehlungen genügen. Für die Aufbewahrung und Speicherung der Credentials werden vor physischen Angriffen geschützte Sicherheitsmodule (wie z.B. TPMs oder SmartCards) empfohlen.

Stehen diese nicht zur Verfügung, so ist zumindest darauf zu achten, dass Credentials niemals im Klartext gespeichert werden dürfen, sondern lediglich deren Salted-Hashes (siehe auch BSI ICS-Kompendium für Hersteller und Integratoren3).

Authentisierung menschlicher Nutzer sowie von Softwareprozessen und – komponenten

Sämtliche menschlichen Nutzer sowie Softwareprozesse und -komponenten sollen sich vor jedem Zugriff bei der Maschine authentisieren. Dies soll auf Basis der definierten Authentisierungsdaten erfolgen. Hat die Maschine den Akteur erfolgreich authentisiert, so soll der Zugriff nur auf die jeweilige Sitzung beschränkt werden. ​

Public-Key Authentisierung

Bei der Authentisierung sollen wenn möglich Public-Key Verfahren zum Einsatz kommen. Neben einem sicheren und effizienten Schlüsselmanagement sowie einer sicheren und auf die Möglichkeiten von eingebetteten Systemen abgestimmten Wahl des kryptographischen Materials (siehe Abschnitt 14) ist hier insbesondere die Integration der Maschine in bereits bestehende Public-Key Infrastrukturen zu empfehlen.

 

Dabei ist zu berücksichtigen, dass eine PKI üblicherweise keine Funktionen für das Certificate Lifecycle Management mitbringt, welches spätestens durch den Betreiber beigestellt werden soll um Systemausfälle aufgrund abgelaufener Zertifikate zu vermeiden. 

Zonenbildung und Zugriffskonzepte mit entsprechender Authentifizierung 

Die Authentifizierung der Akteure soll nicht nur auf den einzelnen Komponenten der Maschine erfolgen, sondern auch beim Übertreten der in Abschnitt 2 definierten Zonengrenzen. Will sich ein Akteur auf einer Komponente authentisieren, die nicht innerhalb seiner Zone liegt, so soll eine Authentisierung an jedem Zonenübergang auf dem Weg zur Zielkomponente stattfinden.

 

Weiter soll bei Zugriff über jegliche Schnittstellen der Maschine eine Authentifizierung erfolgen. Es ist aus Sicht der Usability zielführend und effizient, hierbei etablierte Verfahren zur Automatisierung anzuwenden (Single Sign-On durch Übermittlung von Tokens, etwa SAML, Kerberos oder OAuth 2.0).

Die Maschine soll nach jeder Authentifizierung eine Autorisierungsprüfung der Akteure/Dienste gewährleisten

Wurde ein Akteur erfolgreich von der Maschine authentifiziert, sollen direkt anschließend die seinem individuellen Benutzerkonto zugeordneten Rechte überprüft werden. Stimmen die dem Akteur zugeteilten Rechte nicht mit den zum Zugriff erforderlichen Rechten überein, soll der Zugriff verweigert und ein entsprechender Eintrag für das Ereignisprotokoll generiert werden.

 

Während die Rechteverteilung seitens des Akteurs vom Account-Management geleistet wird, so sollen die den Komponenten und Diensten zugeordneten Zugriffsrechte bereits vom Integrator vordefiniert und dokumentiert sein.

 

Die Zugriffsrechte auf Komponenten und Dienste sollen auch nach Inbetriebnahme der Maschine noch verändert werden können. Dies ist aufgrund sich verändernder Umgebungsanforderungen erforderlich. Um die Verwaltung der Berechtigungen für den Betreiber zu vereinfachen und die Komponenten zu entlasten kann es sinnvoll sein, diese (z.B. unter Verwendung von XACML) zentral verwaltbar zu machen. 

Starke Authentisierung auf externen Schnittstellen

Sämtliche Zugriffe auf externe Schnittstellen der Anlage sollen durch starke Authentisierung abgesichert sein. Im Falle kryptographischer Authentisierungsmechanismen sollen die jeweiligen Parameter (z.B. Schlüssellängen) gemäß aktueller Standards gewählt werden. Beispielsweise liefern verschiedene VPN Lösungen, IPSec und TLS bei Fernzugriff bereits eine starke Authentisierung, sichere Konfiguration vorausgesetzt.

 

Es sei hier erwähnt, dass Maschinenkomponenten im Werkszustand oftmals mit initialen Standardkonten (z.B. Administrator mit Standardpasswort) ausgeliefert werden. Starke Authentisierung bedeutet auch und insbesondere, dass solche Standardkonten bei Inbetriebnahme der Maschine auf die tatsächlichen Konten und die dazu vorgesehenen Identitäten angepasst werden.

 

Hardcodierte und damit unveränderliche Credentials sind nicht nur unsicher, sondern erfordern einen kostspieligem Austausch der Hardware bei Kompromittierung der Zugangsdaten. 

Quelle: VDMA Leitfaden Industrie 4.0 Security

Benutzerkonten
Authentisierung menschlicher

Nutzung sicherer Protokolle ​

Mithören und ändern verboten​

Für Angreifer, die nicht direkten Zugang zur Maschine haben, bietet sich oftmals die Kommunikation zu externen Komponenten als initialer Angriffspunkt an. Es sollen daher ausschließlich sichere Protokolle Verwendung finden, die Vertraulichkeit, Integrität und Authentizität der gesendeten Daten gemäß Stand der Technik gewährleisten. Dabei sollen wenn möglich bereits standardisierte Protokolle zum Einsatz kommen. 

Vertraulichkeit der Kommunikation bei IP basierten Protokollen

Für IP-basierte Protokolle zur Kommunikation örtlich verteilter Maschinen lässt sich die Vertraulichkeit und Integrität der übermittelten Daten durch etablierte Absicherungsmaßnahmen realisieren. Empfohlen wird hierbei insbesondere die Verwendung von TLS 1.3 und darauf aufbauender Protokolle (wie z.B. HTTPS). Ist eine Verschlüsselung aufgrund erforderlicher Abwärtskompatibilität zu Altsystemen nicht möglich, so sollte die Kommunikation durch ein sicheres Protokoll getunnelt werden. Diese Empfehlung wird unter der Annahme ausgesprochen, dass zeitkritische Anwendungen nicht über IP-basierte Protokolle kommunizieren und die zusätzliche Latenz durch Verschlüsselung der Anwendungsdaten vernachlässigbar ist.​

Integrität der Kommunikation

Die Integrität der Kommunikationsdaten soll sowohl innerhalb als auch außerhalb der Maschine gewährleistet sein. Die korrekte Funktionsweise der Maschine ist unmittelbar an die Korrektheit der übertragenen Anwendungsdaten verbunden. Dies hat zur Folge, dass eine unentdeckte Manipulation von Anwendungsdaten während der Übertragung ernstzunehmende Auswirkungen auf die Maschine als Ganzes haben kann. Auch hier empfiehlt sich für eine praktische Realisierung die Verwendung offener Standards und gängiger Implementierungen nach dem Stand der Technik, wie z.B. TLS 1.3. ​

Typ, Stärke und Qualität der Verschlüsselungsalgorithmen​

In Anbetracht der Vielzahl an kryptographischen Algorithmen und einer noch größeren Auswahl an möglichen Implementierungen ist unbedingt zu empfehlen, auf standardisierte und von öffentlichen Stellen empfohlene Verschlüsselungsverfahren zurückzugreifen. In den öffentlichen Empfehlungen (siehe Abschnitt 14) finden sich auch Vorgaben zur geeigneten Wahl der Parameter (z.B. Schlüssellängen). Diese Empfehlungen öffentlicher Stellen unterliegen aufgrund der sich ständig verändernden Bedrohungslage regelmäßiger Überarbeitung. Bei der Entwicklung der Maschine sollte deshalb darauf geachtet werden, dass eine entsprechende Anpassung in bereits bestehenden Maschinen und Anlagen möglich ist. Von Eigenentwicklungen, die nicht einer Kryptoanalyse durch Experten unterzogen wurden, ist dringend abzuraten.​

Sonderbetrachtung des Feldbus​

Nutzer sowie von Softwareprozessen und komponenten Sämtliche menschlichen Nutzer sowie Softwareprozesse und -komponenten sollen sich vor jedem Zugriff bei der Maschine authentisieren. Dies soll auf Basis der definierten Authentisierungsdaten erfolgen. Hat die Maschine den Akteur erfolgreich authentisiert, so soll der Zugriff nur auf die jeweilige Sitzung beschränkt werden. 

Quelle: VDMA Leitfaden Industrie 4.0 Security

Nutzung sicherer Protokolle ​
Absicherung von Funktechnologien 

Absicherung von Funktechnologien 

Von Luftbrücken und Luftlücken

Sämtliche von der Maschine unterstützten Funktechnologien sollen gemäß Stand der Technik abgesichert werden. ​

Sichere Konfiguration​

Neben funktionalen Anforderungen müssen auch die Security-Anforderungen der eingesetzten Funktechnologie erfüllt werden. Dies umfasst zunächst die sichere Konfiguration der eingesetzten Funktechnologien. So sollen möglichst geringe Reichweiten (durch Anpassung der Signalstärke oder Abschirmung) und eine möglichst hohe Störfestigkeit realisiert werden. Ist eine sichere Konfiguration der Komponenten aufgrund notwendiger Abwärtskompatibilität nicht durchführbar, so sollen die jeweiligen unsicheren Kommunikationskanäle getunnelt und durch sichere Protokolle abgesichert werden. 

Wireless Access Management​

Die Anlage soll bei Zugriff über Funktechnologien eine starke Authentisierung durchführen sowie sämtliche Interaktionen einer Sitzung protokollieren. Die Aktivierung einer Zugangsbeschränkung nach erstmaliger Einrichtung wird empfohlen, sofern diese nicht den effektiven Betrieb der Maschine maßgeblich einschränkt. Die Zugangsbeschränkung kann dabei je nach Bedürfnis konfiguriert werden, technisch kann dies durch eine MAC-Filterung realisiert werden. Dasselbe gilt für Relay-Stationen, die den physischen Signalbereich erheblich erweitern können. In Umgebungen mit besonderem Schutzbedarf sollte die Nutzung von 802.1x erwogen werden bzw. dessen Nutzung möglich sein.​

Zeitabhängigkeit der Sicherheit von Kryptographischen Funktionen

Aufgrund der Exponiertheit von Funknetzen bei gleichzeitiger langer Einsatzdauer der Maschinen soll eine regelmäßige Überprüfung der Security-Konfiguration erfolgen. Dies umfasst insbesondere die kryptographischen Funktionen des Funknetzes. Sind die eingesetzten Chiffrensammlungen, Parameter oder Implementierungen von aktuellen Angriffen betroffen, so sollten diese umgehend durch sichere Versionen ersetzt werden. Einen Überblick über aktuell sichere Protokolle und kryptographische Funktionen finden sich in entsprechenden Standards und Empfehlungen des BSI und des NIST.

Eignen sich die verwendeten Komponenten aufgrund ihrer limitierten Rechenkapazität nicht für stärkere Algorithmen, besteht als Ausweichmöglichkeit die schnelle Rotation des Schlüsselmaterials.

Quelle: VDMA Leitfaden Industrie 4.0 Security

Sichere Fernwartung

Sichere Fernwartung

Der Weg durch unsicheres Terrain​

Der Anlagenhersteller soll gewährleisten, dass die Systeme zur sicheren Fernwartung dem identifizierten Schutzbedarf entsprechen. ​

Regelungen zum Aufbau und Beenden einer Fernzugriffssitzung

Grundlage für die Etablierung eines sicheren Fernwartungsprozesses sind Regelungen zum Aufbau und Beenden einer Fernzugriffssitzung. So soll definiert sein, wann und unter welchen Bedingungen eine Sitzung gestartet werden darf. Vor jeder Fernwartung soll geprüft werden, ob der Akteur die erforderlichen Rechte besitzt und ob die gegenwärtige Auslastung der Maschine ein Wartungsintervall zulässt. Die Sitzung soll nach einer festgelegten Zeitspanne automatisch gesperrt werden, wenn der Nutzer in diesem Zeitraum keine Aktionen ausgeführt hat. Eine gesperrte Sitzung soll nur mittels erneuter Identifikation, Authentifikation und Autorisierung wiederaufgenommen werden können.

Das Beenden der Wartungssitzung soll sowohl von der Maschine als auch vom Nutzer der Fernwartung initiiert werden können. Das Beenden seitens der Maschine kann dann notwendig sein, wenn der Nutzer nicht autorisierte Funktionen aufrufen oder Einstellungen vornehmen will. Sämtliche Daten der Sitzung (einschließlich Zeitpunkt, Dauer und ausgeführter Aktionen) sollen protokolliert werden. Zusätzlich zu den genannten Maßnahmen kann ein Fernzugriff über weitere Filtermaßnahmen, z.B. Begrenzung des zugänglichen IP-Adressbereichs eingeschränkt werden.

Absicherung durch technische und organisatorische Maßnahmen

Auf organisatorischer Ebene soll vorgegeben werden, wann und unter welchen Bedingungen eine Fernwartung durchgeführt werden darf. So kann beispielsweise ausgeschlossen werden, dass eine Fernwartung zu Zeitpunkten stattfindet, zu denen die Maschine kritische Funktionen für weitere abhängige Maschinen ausführt. Die Einhaltung dieser Vorgaben soll technisch abgesichert sein, beispielsweise durch automatisierte Überprüfung einer vorgegebenen Policy vor jedem Fernwartungszugriff. 

Verschlüsselung der Verbindungen

Die Fernwartung soll über eine kryptographisch abgesicherte Verbindung erfolgen. Nur so können Authentizität des Akteurs sowie Vertraulichkeit der übermittelten Daten garantiert werden

Etablierung von Zugriffsprozessen

Für jeden Zugriff soll klar definiert sein, welche Aktionen der Akteur ausführen darf. Jegliche Abweichung von diesen Zugriffsprozessen soll zum Beenden der Sitzung führen. Wird die Verbindung innerhalb eines vordefinierten Zeitraums mehrfach hintereinander beendet (z.B. wegen falscher Anmeldedaten), so sollen weitere Zugriffe untersagt und erst dann wieder zugelassen werden, wenn ein Administrator mit entsprechenden Rechten eine erneute Freischaltung vorgenommen hat. 

Übergänge zu anderen Netzen absichern

Will sich ein Akteur mit bereits etablierter Verbindung zu einer Maschinenkomponente von dieser aus in eine weitere Komponente verbinden, so sollen für jede weitere Verbindung dieser Art erneut alle genannten Prozesse zum Aufbau und Beenden der Fernzugriffs-Sitzung sowie zur Etablierung von Zugriffsprozessen ausgeführt werden. Insbesondere soll eine erneute Autorisierung erfolgen, falls sich die Zielkomponente in einem anderen Netzsegment oder einer anderen Zone befindet, Es bietet sich an, dem Betreiber zusätzlich die Möglichkeit zur Wahl einer Fernwartungsplattform auf Basis von Standarddiensten zu ermöglichen, da der Mehraufwand für den parallelen Betrieb mehrerer Technologien zumeist für den Betreiber sehr hoch ist.​

Quelle: VDMA Leitfaden Industrie 4.0 Security

Monitoring und Angriffserkennung ​

Monitoring und Angriffserkennung ​

Vertrauen ist gut…​

Die Annahme einer vollständigen Absicherung der Maschine gegen Angriffe ist auch bei Einsatz von modernster Sicherheitstechnologie unrealistisch. Es sollen daher Funktionen zur Erkennung von Angriffen und anderen sicherheitsrelevanten Ereignissen bereitstehen. Sämtliche aufgezeichneten Daten sollen hierbei möglichst zentral gespeichert werden, um eine spätere Auswertung zu erleichtern.​

Monitoring aller Zugriffe auf Maschinenkomponenten​

Zunächst sollen sämtliche Zugriffe auf Maschinenkomponenten erfasst und zur weiteren Verarbeitung gespeichert werden. Insbesondere sollen sämtliche Zugriffe aus nicht-vertrauenswürdigen Netzen protokolliert werden. Auch die Zugriffe von Komponenten auf Dienste innerhalb der Maschine sollen hierbei berücksichtigt werden. Dabei sollen zumindest die Identität der involvierten Akteure/Komponenten, der Zeitpunkt, die Dauer und die Art des Zugriffs für eine spätere Auswertung vorgehalten werden. Das Monitoringsystem sollte vom Produktivsystem getrennt sein. Sollte bereits ein SIEM-System (Security Information and Event Monitoring) beim Betreiber im Einsatz sein, ist die Möglichkeit der Anbindung der Anlage zu prüfen. ​

Funktionen zum Monitoring in Leitstand integrieren

Die Funktionen zum Monitoring von Zugriffen sowie weiterer sicherheitsrelevanter Ereignisse sollen direkt in den Leitstand der Maschinen Integriert werden, d.h. Leitstände und andere den Maschinen direkt übergeordnete Systeme sollen die Möglichkeit zur Aufzeichnung ebenso unterstützen wie die Maschine selbst. Dies ermöglicht eine direkte Auswertung nach einem erkannten Störfall. Zu sicherheitsrelevanten Ereignissen zählen hier z.B. inkorrekte Passworteingaben, Ressourcenüberlastung, unbefugte Zugriffsversuche oder auch Änderungen in sicherheitsrelevanten Konfigurationsdateien  (vgl. auch die IT-Grundschutz-Kataloge des BSI5) . ​

Der Leitstand wird somit zur zentralen Komponente der Erfassung und Verarbeitung sicherheitsrelevanter Daten. Bei Entwurf und Entwicklung der Maschine sollte deshalb die zusätzliche Kommunikationslast zu dieser Komponente berücksichtigt werden, da im Falle komplexer und verteilter Maschinen ein erheblicher Datendurchsatz entstehen kann. ​

Ferner soll darauf geachtet werden, dass sämtliche erfasste Ereignisse keinerlei sensible Daten (wie z.B. Schlüsselmaterial) enthalten (siehe auch das BSI ICS-Kompendium für Hersteller und Integratoren).

Virenscanner

Die direkt mit der Maschine verbundenen Rechner sind oftmals Einfallstor für Programme mit Schadwirkung (Malware). Es empfiehlt sich daher der Einsatz von Virenscannern auf diesen Komponenten. Gängige Virenscanner erkennen Angriffe mittels einer vordefinierten Malware-Signatur. Solche regelbasierten Methoden zur Angriffserkennung haben den Vorteil, dass sie bereits bekannte Angriffsmuster relativ zuverlässig identifizieren. Bei der Erkennung neuartiger Schadsoftware, für die noch keine Signaturen generiert wurden, liefern diese Methoden hingegen eine ungenügende Erkennungsrate. Um einen rudimentären Schutz vor gängigen Schadprogrammen zu gewährleisten, sollen die Signaturen regelmäßig aktualisiert werden. ​

Um die Leistungsfähigkeit der Rechner nicht durch zu hohe Scan-Last zu beeinträchtigen, bieten fast alle Hersteller die Möglichkeit, adaptive Scans zu definieren, die bekanntermaßen Schadsoftware-freie Bibliotheken auf Basis ihrer Signatur vom Scan ausschließen.

Netzwerk IDS und Anomalieerkennung bei komplexen Maschinen

Um auch neuartige, noch nicht bekannte Angriffsmuster zu erkennen, sollen zusätzliche Maßnahmen zur Anomalieerkennung integriert werden. Dieser Ansatz geht von einem Normalverhalten der Maschine aus und erkennt von diesem abweichendes Fehlverhalten als Anomalie. Während solche Methoden in komplexen Netzwerken (z.B. im Office-Netz) oftmals Falschmeldungen generieren, eignen sie sich gut für Maschinennetze, deren Grundverhalten oftmals wesentlich gleichförmiger ist und eine einfachere Charakterisierung zulässt. Normalverhalten der Maschine kann dabei anhand vielfältiger Eigenschaften definiert werden, z.B. durch Muster in der Netzwerkkommunikation, Benutzerverhalten, Aktivität der Maschinenmodule, Sensordaten, oder System-Log-Dateien. ​

Es sollen Intrusion-Detection Systeme (IDS) und Intrusion-Prevention Systeme (IPS) zur Netzüberwachung von komplexen Maschinen eingesetzt, bzw. deren Einsatz durch den Betreiber ermöglicht werden. Insbesondere sollen besonders exponierte Komponenten mit entsprechender Funktionalität versehen werden, um auf Grundlage von Heuristiken ungewünschtes Verhalten zu erkennen. Es bleibt anzumerken, dass die im Anlagennetz genutzten Protokolle oftmals nicht ausreichend oder gar nicht mit den heute verfügbaren IDS/IPS Lösungen erkannt und verarbeitet werden können. Hier besteht dringender Kooperationsbedarf, um auf Protokollebene schadhafte Pakete automatisiert identifizieren zu können. ​

Quelle: VDMA Leitfaden Industrie 4.0 Security

Wiederherstellungsplan 

Wiederherstellungsplan 

Plan B​

Der Anlagenhersteller sowie der Integrator sollen einen Wiederherstellungsplan definieren, der im Fall einer Störung oder eines Angriffs die Anlage in einen vertrauenswürdigen Zustand zurücksetzt. ​

Erstellung von Backup-Systemen​

Backup-Systeme sind Speichersysteme, die die Sicherung sämtlicher Daten der Maschine ermöglichen. Backup-Systeme sollen fest in den Entwicklungsprozess der Maschine integriert werden und es wird empfohlen, durch mehrfache Sicherheitskopien ein angemessenes Maß an Datenverfügbarkeit und Ausfallsicherheit zu gewährleisten. Werden zentrale Backup- Server für die Speicherung genutzt, so soll die Maschine über Funktionen zum sicheren Datenaustausch mit diesen Servern verfügen. ​

Erstellung regelmäßiger Backups

Sämtliche für den Betrieb der Maschine notwendigen Daten sollen in regelmäßigen Abständen auf Backup-Systemen gesichert werden. Die Zeitintervalle und Verschlüsselungsanforderungen sollen dabei, auf Basis der Bedrohungslage und des Schutzbedarfs, angemessen von Integrator oder Betreiber festgelegt werden. 

Prüfung von Backups auf Wiederherstellbarkeit​

Sämtliche Backups sollen auf Wiederherstellbarkeit geprüft werden. Diese Prüfung soll regelmäßig erfolgen. Es soll durch Redundanz der Backup-Systeme garantiert werden, dass im Falle der Nicht-Wiederherstellbarkeit auf ein weiteres Backup ausgewichen werden kann. ​

Wiederherstellung eines vertrauenswürdigen Zustandes nach Störung/Angriff​

Nach einem Angriff ist es erforderlich, die Maschine wieder in einen vertrauenswürdigen Zustand zu bringen. Die regelmäßig erstellten Backups ermöglichen die Wiederherstellung eines Maschinenzustandes vor dem Zeitpunkt des Störfalls. Es wird weiter empfohlen, auch direkt von der betroffenen Maschine abhängige Komponenten zu überprüfen und gegebenenfalls auch diese in den entsprechend vertrauenswürdigen Zustand zurück zu setzen. ​

Wiederherstellung von verschlüsselten Daten ​

Bei der Wiederherstellung der Maschine in einen vertrauenswürdigen Zustand werden einige Daten nur verschlüsselt vorliegen. Die Backup-Systeme sollen die Wiederherstellung der verschlüsselten Daten ermöglichen.​

Quelle: VDMA Leitfaden Industrie 4.0 Security

Sicherer Produkt-Lebenszyklus ​

Sicherer Produkt-Lebenszyklus ​

Vom Design bis zum Phase-out​

Der Anlagenhersteller soll einen sicheren Maschinen-Lebenszyklus definieren und gewährleisten. Wie eingangs in Abschnitt 1 erwähnt, sollte das Produkt idealerweise einer regelmäßigen Risikoanalyse unterzogen werden. Dies ist für den Mittelstand oft aufgrund fehlender Ressourcen eine gewisse Herausforderung. Um dennoch einen sicheren Produkt-Lebenszyklus der Maschine zu gewährleisten, sind die folgenden praktischen Maßnahmen zu beachten.​

Beobachtung von Schwachstellen​

Maschinenhersteller, -integrator und –betreiber sollen neu bekannt gewordene Angriffsvektoren hinsichtlich ihres Gefährdungspotentials einordnen können. Insbesondere soll eine schnelle Abschätzung erfolgen, ob eine neu bekannt gewordene Schwachstelle für eine Maschinenkonfiguration relevant ist. Aufgrund von teils sehr komplexen Maschinenkonfigurationen mit vielfältigen Komponentenklassen sollte hierzu ein Maschineninventar geschaffen werden. Es sei darauf hingewiesen, dass die Inventarisierung seitens des Herstellers regelmäßig nur den Inbetriebnahme Zustand festhalten kann. Insofern kann die Verantwortung zum Führen eines solchen Inventars auf den Betreiber der Anlage übergehen, insbesondere bei Änderungen an der Konfiguration durch den Betreiber. ​

Beobachtung der Bedrohungslage durch die Hersteller​

Über die Beobachtung von aktuellen Schwachstellen hinaus sollte sich der Hersteller der aktuellen Bedrohungslage bewusst sein und dies in die Entwicklung neuer Maschinen einfließen lassen. Häufen sich zum Beispiel konkrete Angriffe auf eine in der Maschine verbaute Komponentenklasse, ohne dass die Maschine direkt davon betroffen ist, so sollte der Hersteller dennoch über Kenntnis entsprechender Schutzmaßnahmen verfügen. Der Anlagenhersteller soll anhand dokumentierter Bedrohungsmodelle gewährleisten, dass die Security-Funktionen der Anlage den Schutzbedarf angemessen erfüllen.

Reaktionsfähigkeit auf Schwachstellen​

Die Beobachtung von konkreten Schwachstellen und der allgemeinen Bedrohungslage soll den Hersteller/Integrator befähigen, auf bekannt gewordene Schwachstellen zeitnah reagieren und Maschinen und Anlagen gegen neue Gefährdungen schützen zu können. Eine angemessene Reaktionsfähigkeit setzt zumindest eine vordefinierte Vorgehensweise bei Bekanntwerden einer Schwachstelle voraus. So sollen innerbetriebliche Prozesse definiert werden, die gegebenenfalls jederzeit eingeleitet werden können.​

Festlegen der betrieblichen Kommunikationskanäle​

Zu den innerbetrieblichen Prozessen zählt insbesondere die Festlegung der Kommunikationskanäle. Es soll klar definiert sein, an welche Stelle des Betriebes extern entdeckte Schwachstellen berichtet werden können. Des Weiteren soll klar festgelegt werden, wie und an wen diese Information innerhalb des Betriebes kommuniziert werden soll. Was die außerbetriebliche Kommunikation betrifft, so ist zu empfehlen dass der Hersteller/Integrator die Betreiber der betroffenen Maschinenserie frühzeitig von identifizierten Schwachstellen in Kenntnis setzt.​

Patchmanagement​

Um die Anpassung der Anlage auf neue Gefährdungslagen und bekannt gewordene Schwachstellen zu gewährleisten, soll der Anlagenhersteller einen sicheren Prozess zur Handhabung und Integration von Patches definieren. Dies beinhaltet auch, dass alle dazu notwendigen Ressourcen im Vorhinein eingeplant werden. Des Weiteren sollen Verteilmechanismen für den Patch definiert werden, die eine zeitnahe Einbringung ermöglichen. Hierzu sollte eine Infrastruktur für die Patchverteilung an die Betreiber vorhanden sein, die ihrerseits wiederum Prozesse und Infrastrukturen für die Annahme, das Testen und die Installation der Patches vorhalten sollen. ​

Benennung von internen und externen Verantwortlichen​

Für den effizienten Ablauf aller geforderten Prozesse ist die Benennung von internen und externen Verantwortlichen notwendig. Es sollen Personen benannt werden, die für die Einschätzung einer eingehenden Schwachstellenmeldung, für die Entwicklung und für die Auslieferung der Patches verantwortlich sind. Den Verantwortlichen sollen Befugnisse eingeräumt und notwendige Mittel bereitgestellt werden, um das Patchmanagement effizient koordinieren zu können.

Umgang mit End Of Support (EOS)​

Endet der Support für eine Maschine, sollen hierzu klar definierte Prozesse definiert werden. Sofern möglich soll der Integrator den Betreiber frühzeitig darüber in Kenntnis setzen, dass der Support insbesondere in Form von Patches ausläuft. Da abhängig von der Einsatzumgebung mit sehr langen Betriebszeiten der Maschine über einige Jahre hinweg zu rechnen ist, sollte der Zeitpunkt des EOS idealerweise schon zu Beginn der Anlagenplanung bekannt sein. ​

Phase-out Management​

Endet der Support für eine Maschine, sollen hierzu klar definierte Prozesse definiert werden. Sofern möglich soll der Integrator den Betreiber frühzeitig darüber in Kenntnis setzen, dass der Support insbesondere in Form von Patches ausläuft. Da abhängig von der Einsatzumgebung mit sehr langen Betriebszeiten der Maschine über einige Jahre hinweg zu rechnen ist, sollte der Zeitpunkt des EOS idealerweise schon zu Beginn der Anlagenplanung bekannt sein. ​

Quelle: VDMA Leitfaden Industrie 4.0 Security

Anpassung und Prüfung der Komponenten​

Anpassung und Prüfung der Komponenten​

Survival of the fittest

Die Anlage soll regelmäßig hinsichtlich ihrer definierten Security-Funktionalität überprüft werden, um ihre Robustheit auch in einem sehr dynamischen Umfeld zu gewährleisten.

Anpassen der Standard-Einstellungen​

Bei initialer Einrichtung sowie bei jeder Wiederherstellung in einen vertrauenswürdigen Zustand soll darauf geachtet werden, dass die Standard-Einstellungen angepasst werden. So sind häufige Einfallstore z.B. Standardpasswörter für Administrator-Accounts (siehe Abschnitt 3) oder nicht aktivierte Security-Funktionen im Auslieferungszustand. Die Security- Funktionen der Maschine und deren sichere Konfiguration sind dabei vollständig in der Dokumentation gelistet (siehe Abschnitt 16). Die Anpassungen bzw. Einstellungen sollen sämtlich für nachfolgende Prüfungen protokolliert werden. Die Anpassung der Standardeinstellungen soll sicherstellen, dass die neue Konfiguration der Bedrohungslage angemessen ist.​

Anpassen der Hardwarekonfiguration​

Ist die Maschine in verschiedenen Hardwarekonfigurationen verfügbar, so soll noch vor Integration überprüft werden, ob die der Bedrohungslage angemessene Security-Funktionalität von der angestrebten Konfiguration erreicht wird.​

Zugriff auf das Internet innerhalb des ICS-Netzwerks​

Es soll überprüft werden, ob ein Zugriff auf das Internet innerhalb des Anlagennetzes möglich ist. Ist dies der Fall soll ferner geprüft werden, ob hierbei der Zugriff der definierten Security-Funktionalität der Anlage widerspricht und ob die zugreifende Komponente ausreichend von kritischen Teilen der Maschine isoliert ist.​

Prüfungen zur Verifikation und Validierung​

Es soll sowohl eine Verifikation der Security-Funktionen der Anlage stattfinden (Spezifikationsabgleich), als auch eine Validierung, (d.h. eine Überprüfung der Tauglichkeit der Security- Funktionen). Eine solche Prüfung kann das Auftreten von Schwachstellen zwar meist nicht ausschließen, jedoch stark reduzieren. Eine sorgfältige Testdurchführung erfordert zunächst die Erstellung eines Testplans, der Grundlage für die Testvorbereitung ist, welche die Planung von Testfällen und -szenarien beinhaltet (siehe auch das BSI ICS-Kompendium für Hersteller und Integratoren). Die Testdurchführung kann sehr umfangreich ausfallen und soll von den jeweiligen Verantwortlichen veranlasst werden. Die Ergebnisse der Prüfung sollen dokumentiert werden. ​

 Prüfung der Software- und Informationsintegrität​

Die Integrität jeglicher Softwarekomponenten sowie Konfigurationsdaten der Maschine soll gewährleistet sein. Hierzu bieten sich elektronische Signaturen an, die bei jedem Einlesen der Konfigurationsdaten und bei jeder Ausführung von Programmen überprüft werden. Die eingesetzten Signaturverfahren sollen bezüglich Parameter und kryptographischem Material dem Stand der Technik genügen (siehe Abschnitt 14). 

Auswahl sicherer Komponenten​

Oftmals werden externe Komponenten von Zulieferern in die Maschine integriert. In solchen Fällen soll vom Integrator geprüft werden ob die externen Komponenten den identifizierten Security- Anforderungen genügen. Eine solche Beurteilung kann sowohl anhand von Zertifizierungen der zugelieferten Komponenten, als auch von geschulten Entwicklern (siehe Abschnitt 17) getroffen werden. Werden Zertifizierungen zur Prüfung herangezogen, so sollte darauf geachtet werden, dass die Gültigkeit des Zertifikats mindestens bis zur Inbetriebnahme gegeben ist und der Umfang der Prüfung für den Einsatzzweck in der Anlage genügt.​

Quelle: VDMA Leitfaden Industrie 4.0 Security

Verzicht auf überflüssige Komponentenfunktionen​

Verzicht auf überflüssige Komponentenfunktionen​

So wenig wie möglich, so viel wie nötig​

Es kommt oft vor, dass Maschinen als Ganzes oder einzelne Komponenten innerhalb der Anlage über eine Reihe von Funktionen verfügen, die für den Betrieb in bestimmten Einsatzumgebungen nicht in Anspruch genommen werden. Solche im Anwendungsfall überflüssigen Produktfunktionen können die Angriffsoberfläche signifikant vergrößern und sind oft Einfallstor für Angreifer. Deshalb soll auf solche Funktionen, die für den jeweiligen Einsatzbereich der Maschine nicht relevant sind, verzichtet werden. ​

Anpassen der Standard-Einstellungen​

Bei initialer Einrichtung sowie bei jeder Wiederherstellung in einen vertrauenswürdigen Zustand soll darauf geachtet werden, dass die Standard-Einstellungen angepasst werden. So sind häufige Einfallstore z.B. Standardpasswörter für Administrator-Accounts (siehe Abschnitt 3) oder nicht aktivierte Security-Funktionen im Auslieferungszustand. Die Security- Funktionen der Maschine und deren sichere Konfiguration sind dabei vollständig in der Dokumentation gelistet (siehe Abschnitt 16). Die Anpassungen bzw. Einstellungen sollen sämtlich für nachfolgende Prüfungen protokolliert werden. Die Anpassung der Standardeinstellungen soll sicherstellen, dass die neue Konfiguration der Bedrohungslage angemessen ist.​

Anpassen der Hardwarekonfiguration​

Ist die Maschine in verschiedenen Hardwarekonfigurationen verfügbar, so soll noch vor Integration überprüft werden, ob die der Bedrohungslage angemessene Security-Funktionalität von der angestrebten Konfiguration erreicht wird.​

Zugriff auf das Internet innerhalb des ICS-Netzwerks​

Es soll überprüft werden, ob ein Zugriff auf das Internet innerhalb des Anlagennetzes möglich ist. Ist dies der Fall soll ferner geprüft werden, ob hierbei der Zugriff der definierten Security-Funktionalität der Anlage widerspricht und ob die zugreifende Komponente ausreichend von kritischen Teilen der Maschine isoliert ist.​

Prüfungen zur Verifikation und Validierung​

Es soll sowohl eine Verifikation der Security-Funktionen der Anlage stattfinden (Spezifikationsabgleich), als auch eine Validierung, (d.h. eine Überprüfung der Tauglichkeit der Security- Funktionen). Eine solche Prüfung kann das Auftreten von Schwachstellen zwar meist nicht ausschließen, jedoch stark reduzieren. Eine sorgfältige Testdurchführung erfordert zunächst die Erstellung eines Testplans, der Grundlage für die Testvorbereitung ist, welche die Planung von Testfällen und -szenarien beinhaltet (siehe auch das BSI ICS-Kompendium für Hersteller und Integratoren). Die Testdurchführung kann sehr umfangreich ausfallen und soll von den jeweiligen Verantwortlichen veranlasst werden. Die Ergebnisse der Prüfung sollen dokumentiert werden. ​

 Prüfung der Software- und Informationsintegrität​

Die Integrität jeglicher Softwarekomponenten sowie Konfigurationsdaten der Maschine soll gewährleistet sein. Hierzu bieten sich elektronische Signaturen an, die bei jedem Einlesen der Konfigurationsdaten und bei jeder Ausführung von Programmen überprüft werden. Die eingesetzten Signaturverfahren sollen bezüglich Parameter und kryptographischem Material dem Stand der Technik genügen (siehe Abschnitt 14). 

Auswahl sicherer Komponenten​

Oftmals werden externe Komponenten von Zulieferern in die Maschine integriert. In solchen Fällen soll vom Integrator geprüft werden ob die externen Komponenten den identifizierten Security- Anforderungen genügen. Eine solche Beurteilung kann sowohl anhand von Zertifizierungen der zugelieferten Komponenten, als auch von geschulten Entwicklern (siehe Abschnitt 17) getroffen werden. Werden Zertifizierungen zur Prüfung herangezogen, so sollte darauf geachtet werden, dass die Gültigkeit des Zertifikats mindestens bis zur Inbetriebnahme gegeben ist und der Umfang der Prüfung für den Einsatzzweck in der Anlage genügt.​

Quelle: VDMA Leitfaden Industrie 4.0 Security

Komponentenhärtung

Eine Kette ist so stark wie ihr schwächstes Glied​

Durch zunehmende Vernetzung und intelligentere Funktionen lässt sich Security nicht mehr ausschließlich mittels Abschottung implementieren. Sichere, gehärtete Komponenten werden dabei eine immer größere Rolle spielen.

Komponenten dürfen nur gehärteten Code ausführen​

Es sollen nur solche Programme auf der Maschine ausgeführt werden, deren Entwicklungsprozess ein Mindestmaß an Qualitätskriterien berücksichtigt. Hiermit soll sichergestellt werden, dass die Softwarekomponenten einem angemessenen Qualitätsstandard entsprechen. Allgemeiner wird empfohlen, die Programme gemäß dem Stand der Technik des Softwareengineerings zu entwickeln und zu warten. Der VDMA hat dazu einen Leitfaden „Softwarequalitätssicherung“ veröffentlicht 8. Zudem können als Leitfäden für Qualitätskriterien und die Bewertung von Softwareprodukten sowohl die Norm ISO/IEC 25000 (”Software engineering– Software product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE”) als auch die zugehörige Normenreihe ISO/IEC 250xx herangezogen werden. ​

Sicherheitstests als integraler Bestandteil bei der Entwicklung und Systemintegration

Sicherheitsanalysen sollen integraler Bestandteil bei Entwicklung und Anlagenintegration sein. Zunächst sollen mit Fuzzingtools sämtliche als kritisch eingestufte Softwareschnittstellen (APIs) sowie Netzwerkschnittstellen getestet werden. Das randomisierte Testen mit strukturierten aber ungültigen Eingaben deckt oftmals bereits wesentliche Schwachstellen auf, die dann vom Entwickler behoben werden können. Des Weiteren sollen Tools zur statischen Codeanalyse Verwendung finden. Diese unterstützen die Beseitigung häufiger Programmierfehler. Zusätzlich zu diesen automatisierten Herangehensweisen sollen ferner manuelle Codeanalysen vorgenommen werden. Dies kann dadurch geschehen, dass geschulte Entwickler innerhalb der Entwicklungsabteilungden Quellcode gegenprüfen.​

DoS Schutz​

Eine spezielle Gefahr für die Anlage stellt der „Denial of Service“ (DoS) dar, der eine Blockade des von der Anlage angebotenen Dienstes bedeutet. Neben speziellen Angriffsmethoden wird ein DoS mit Abstand am häufigsten durch eine Überlastung der Infrastruktur hervorgerufen, z.B. durch massenweises Versenden von Anfragen an den Dienst. Wird der Beginn eines DoS Angriffes erkannt, so sollen automatisch entsprechende Sperrlisten der Absenderadressen in die Firewall (siehe Abschnitt 2) eingetragen werden. Falls möglich sollen die Dienste durch Serverlastverteilung auf mehrere virtuelle Instanzen verteilt werden, um bei Ausfall eines einzelnen physischen Rechners die Last effektiv auf noch intakte Instanzen verteilen zu können. Über weitere Maßnahmen (wie z.B. die Erkennung von IP-Spoofing gemäß RFC 2267 oder SYN-Cookies) sollen die Entwickler in den jeweiligen Schulungen unterrichtet werden.

Application Whitelisting und Blacklisting

Durch Application-Whitelisting wird die Angriffsfläche der Anlage weiter reduziert. Dies kann z.B. dadurch geschehen, dass nur (vom Maschinenhersteller) signierte Programme auf der Maschine ausgeführt werden dürfen. Dabei wird vor jedem Programmstart geprüft, ob die Programmsignatur korrekt verifiziert werden kann und ob der Aussteller auf der Whitelist eingetragen ist. Mit Application-Whitelisting lassen sich sehr flexible wie auch restriktive Policies zur Programmausführung umsetzen. Analog zum Whitelisting kann auch das Blacklisting​

hinzugezogen werden, das heißt der Ausschluss von bekannt schadhaften oder prinzipiell nicht erlaubten Programmen (etwa Internet Explorer, Java, Flash). Blacklisting erfordert regelmäßige Aktualisierungen der Liste und daher einen entsprechenden Updateprozess in der Anlage.​

Reduzierung der Systemkomplexität​

Bei der Entwicklung der Maschine soll darauf geachtet werden, dass die Komplexität der Komponenten und des Gesamtsystems möglichst gering gehalten wird. Zunächst ist hier die Funktionsreduzierung zu nennen, die in Abschnitt 11 gesondert behandelt wird. Außerdem sollen ähnliche Funktionengruppen in Modulen und Komponenten zusammengefasst werden. Eine solche Zusammenfassung ermöglicht es oft, die Abstraktionsebenen der Maschinenfunktionen auf Komponenten abzubilden. Dies erleichtert die Wartbarkeit, Weiterentwicklung und Modifikation der Maschinen und verringert letztendlich die Angriffsfläche.​

Absicherung von Feldgeräten außerhalb der Anlage gegen physische Angriffe

Ist die Maschine als verteiltes System implementiert, so soll die Absicherung von entfernten Feldgeräten außerhalb der Anlage gewährleistet sein. Hierzu zählt insbesondere die Absicherung gegen physische Angriffe. Bei entfernten Komponenten mit besonders hohem Schutzbedarf ist hier gegebenenfalls der Einsatz von Hardware- Sicherheitsmodulen (HSM) zur sicheren Aufbewahrung von sensiblem Schlüsselmaterial notwendig.​

Absichern der elektronischen externen Schnittstellen

Sämtliche digitalen, externen Schnittstellen der Maschine sollen gegen vom Hersteller nicht beabsichtigte Zugriffe abgesichert sein. Eine solche Absicherung erfolgt zunächst auf Basis einer vollständigen Identifikation und Dokumentation aller implementierten Schnittstellen. Um auch solche Schnittstellen zu erfassen, die durch andere Systeme aufgerufen werden, sollen insbesondere auch alle Kommunikationswege zu externen Softwaremodulen definiert werden. Diese sind in Form eines Kontextdiagramms nachvollziehbar zu dokumentieren. Eine besondere Klasse stellen hier Debugschnittstellen dar, die oftmals von Angreifern mit direktem Zugang zur Maschine ausgenutzt werden. In einem ersten Schritt sollen deshalb zunächst alle Debugschnittstellen (wie z.B. IEEE 1149.1 JTAG, Background Debug Mode (BDM) oder auch USB Schnittstellen) identifiziert und dokumentiert werden. Die Behandlung solcher Debugschnittstellen hängt vom zu erwartenden Angreifermodell ab.​

Quelle: VDMA Leitfaden Industrie 4.0 Security

Komponentenhärtung
Isolationstechniken

Isolationstechniken innerhalb der Maschine / Virtualisierung

Fein säuberlich getrennt

Um die Auswirkungen eines Störfalls innerhalb der Maschine weitestgehend zu reduzieren, sollen die einzelnen Softwarekomponenten mittels geeigneter Isolationstechniken voneinander getrennt werden. Hierbei können sowohl Virtualisierungslösungen als auch Trusted Execution Environments (TEE) zum Einsatz kommen. Die Umsetzung dieser Techniken kann sich in bestimmten Maschinenkonfigurationen als anspruchsvoll erweisen.​

Schutz vor Schadcode durch Sandboxing und Virtualisierung

Oft können die Störungen durch Schadcode dadurch begrenzt werden, dass Maschinenprogramme in einer Sandbox oder einer virtuellen Umgebung ausgeführt werden. Erstens lassen sich dadurch die Rechte und Funktionen, die dem jeweiligen Programm zur Verfügung stehen, gezielt einschränken. Dies hat oft eine stark reduzierte Angriffsfläche zur Folge. Zweitens beschränken sich die Auswirkungen eines erfolgreichen Angriffs meist auf die lokale virtuelle Umgebung. Zwar sind genügend Angriffe bekannt, die gezielt gegen die Virtualisierungslösungen gerichtet sind (z.B. Angriffe auf Hypervisoren). Das Ausbrechen aus der isolierten Umgebung stellt jedoch für viele der gängigen Schadprogramme eine effektive Hürde dar.​

Die Maschine soll Restriktionen für „mobilen Code“ implementieren

Unter „mobilem Code“ sind hier oft ausgetauschte Programme und Skripte (z.B. in Java(Script), ActiveX oder VBScript) gemeint, die erheblichen Schaden innerhalb der Maschine anrichten können. Eine schwächere Variante dieser Empfehlung ist die Ausführung von Programmen unbekannter Herkunft mit stark reduzierten Rechten. Durch Sandboxing und Virtualisierung lassen sich Programme in Umgebungen mit vordefinierter und eingeschränkter Funktionalität ausführen. ​

Abgrenzung der Betriebs- und Konfigurationsdaten von Anwendungsprogrammen

Durch Virtualisierungstechniken ist es insbesondere möglich, Betriebs- und Konfigurationsdaten von Anwendungsprogrammen zu isolieren. Da auf solche Daten oft von mehreren Maschinenkomponenten zugegriffen wird, kann so das Risiko der Kompromittierung großer Teile der Maschine durch schadhafte Manipulation der Konfigurationsdaten weitestgehend minimiert werden.​

Quelle: VDMA Leitfaden Industrie 4.0 Security

Kryptographie 

Kryptographie 

Das Buch mit standardisierten Siegeln​

Basis für die Nutzung sicherer Protokolle, für Authentisierungsmaßnahmenund für die Absicherung von Funktechnologien ist die Verwendung von sicheren kryptographischen Verfahren. Es soll gewährleistet sein, dass sämtliche kryptographischen Algorithmen und Parameter dem Stand der Technik entsprechen. In diesem Abschnitt wird auf die Auswahl geeigneter Algorithmen und Parameter eingegangen. 

Implementierung von standardisierten Algorithmen

Die Entwicklung sicherer kryptographischer Algorithmen ist ein aufwändiger Prozess, der insbesondere die Kryptoanalyse durch Spezialisten beinhaltet.

 

Es wird deshalb dringend von Eigenentwicklungen abgeraten. Zusammenstellungen und Empfehlungen ausgereifter und aktuell sicherer Verfahren und Parameter werden von öffentlichen Stellen bereitgestellt. ​

 

Es wird dringend von kryptographischen Eigenentwicklungen abgeraten. ​

So werden z.B. in den entsprechenden Dokumenten des BSI 9, 10, des NIST11 und der Bundesnetzagentur12 Empfehlungen zu kryptographischen Verfahren und Schlüssellängen ausgesprochen. Bei der Auswahl soll der Produktlebenszyklus der Anlage herangezogen werden, um bei langer Einsatzdauer über viele Jahre hinweg auch die Entwicklung der Rechenleistung berücksichtigen zu können. ​

Die Schlüssellänge soll entsprechend der geplanten Einsatzdauer gewählt werden. Verfahren zum Austausch bzw. zur Aktualisierung der Cipher Suites sind nach Möglichkeit bereit zu stellen. 

Einbindung in bestehende PKI

Der Anlagenhersteller soll gewährleisten, dass die Anlagen in bestehende PKI integriert werden können. Insbesondere sollen bestehende Zertifikate bereits existierender PKI Verwendung finden können. Hierfür soll ein sicheres Verfahren zur Erzeugung, Einbringung und Handhabung des entsprechenden kryptographischen Materials definiert werden. Die Bereitstellung eines bzw. die Möglichkeit zur Nutzung eines Certificate Lifecycle Management (CLM) beim Betreiber ist vorzusehen, sodass Zertifikate im laufenden Betrieb aktualisiert werden können. Auf Microsoft Windows basierende Komponenten können hierbei Simple Certificate Enrollment Protocol (SCEP) und Network Device Enrollment Service (NDES) als Protokolle nutzen, falls eine Microsoft CA zum Einsatz kommt. ​

Bei der Validierung von Zertifikaten ist darauf zu achten, Inhaber, Aussteller und Gültigkeitsstatus zu überprüfen. Ferner sollen die Zertifikatsketten vollständig geprüft und möglichst wenige Root-Zertifikate in die Liste der vertrauenswürdigen Zertifikate aufgenommen werden. Da sich die Funktionsweise einer Certificate Revocation List (CRL) im Umfeld der Maschine zu Maschine (M2M) Kommunikation durch teilweise hohe Änderungshäufigkeit und damit schnell wachsende Listenlängen als nicht zielführend erweist, ist die Nutzung von OCSP (Online Certificate Status Protocol) zu erwägen.​

Quelle: VDMA Leitfaden Industrie 4.0 Security

Sicherheit-Anforderungenforderng

Bestimmung der Security-Anforderungen für Lieferanten und Zulieferer

Erkläre und fordere was du haben willst​

Werden zugelieferte Komponenten in Anlagen integriert und entsprechen diese Komponenten nicht den identifizierten Security-Anforderungen, so kann das Security-Konzept der Maschine dadurch unterlaufen werden. Als schwächstes Glied in der Kette bieten sich solche Komponenten oftmals als erster Einstiegspunkt für Angreifer da Es sollen daher geeignete Regelungen für sichere Drittkomponenten und einen sicheren Integrationsprozess von zugelieferten Komponenten definiert werden. 

Überprüfung der Security-Anforderungen an zugelieferte Komponenten

Die vom Hersteller/Integrator der Anlage identifizierten Security-Anforderungen sollen von jeder zugelieferten Komponente im Rahmen ihres Funktionsbereichs erfüllt werden. Die Überprüfung der Security-Anforderungen kann dabei vom Integrator, vom Zulieferer oder in gemeinsamer Zusammenarbeit erfolgen. Bei streng vertraulichen Projekten wird der Integrator die Überprüfung anhand der vom Zulieferer bereitgestellten Dokumentation vornehmen. Ist dies nicht erforderlich, so ist auch eine erste Konformitätsabschätzung in Form eines Angebots seitens des Zulieferers denkbar. Es soll sichergestellt sein, dass die zugelieferte Komponente dem identifizierten Schutzbedarf genügt. Dafür können auch Konformitätsprüfungen oder Auditergebnisse von Dritten herangezogen werden. ​

Identifikation der eigenen Rolle als Zulieferer

Wird eine Maschine wiederum als Unterkomponente in ein weiteres Produkt integriert, so soll der Hersteller eine Dokumentation aller Schutzmaßnahmen an den Kunden übergeben. Die Dokumentation soll eine Überprüfung ermöglichen, ob die auszuliefernde Komponente dem Schutzbedarf des Zielsystems entspricht. Der Hersteller sollte sich seiner eigenen Rolle als Zulieferer bewusst sein und dementsprechende Organisationsprozesse definieren. Dies kann die Überprüfung von Security-Anforderungen an die auszuliefernde Maschine mit entsprechendem Lieferangebot sein, aber auch die Dokumentation und Offenlegung des Schutzkonzeptes. ​

Ausgelagerte Softwareentwicklung

Werden Software oder Teile davon von Dritten zur Verfügung gestellt – dies betrifft insbesondere auch Bibliotheken und Code aus offenen Repositories – sind diese in den sicheren Entwicklungsprozess mit einzubeziehen. Dabei sind Kontrollmechanismen zu etablieren, die  einerseits die Umsetzung der eigenen Security- Maßnahmen auch im Drittprodukt sicherstellen, andererseits auch das Potential für Schwachstellen oder bewussten Schadcode minimieren. Auch fremde Systemteile sind hier in die Risikobewertung mit einzubeziehen, daher sind die hierfür notwendigen Informationen zu diesen Teilen einzuholen. 

Quelle: VDMA Leitfaden Industrie 4.0 Security

Dokumentation

Dokumentation

Wer schreibt der bleibt

Die reibungslose Umsetzung aller genannten Sicherheitsmaßnahmen kann nur dann geschehen, wenn diese vollständig dokumentiert werden. 

Schnittstellen

Sämtliche sicherheitsrelevanten Schnittstellen sollen identifiziert und dokumentiert werden. Hierzu zählen insbesondere auch Debug- Schnittstellen in Hardware und Software. ​

Etablierte Prozesse​

Sämtliche im Verlauf dieses Dokumentes benannten organisatorischen und technischen Prozesse sollen identifiziert und dokumentiert werden. Aus der Dokumentation sollen der organisatorische Ablauf und die zuständigen Rollen hervorgehen. Es soll auch eine mit dem Prozess nicht vertraute Person erkennen können, wie in einer der genannten Situationen zu verfahren ist. Die etablierten Prozesse sollen intern dokumentiert werden. ​

Dokumentation der Risikoanalyse ​

Die Ergebnisse der Risikoanalysen (siehe Abschnitt 1) sollen dokumentiert und für den späteren Gebrauch archiviert werden. Dazu zählen auch insbesondere dokumentierte Bedrohungsmodelle. Aus der Dokumentation sollte hervorgehen, welche Methode der Risikoanalyse zu Grunde lag und auf Basis welcher Information die Abschätzung von Auswirkung und Wahrscheinlichkeit der Angriffe stattgefunden hat. Eine offengelegte Risikoanalyse kann von Angreifern dazu genutzt werden, die Bedrohungen mit größtem Schadenspotential zu identifizieren. Deshalb soll die Risikoanalyse nur intern dokumentiert werden. Lediglich die resultierenden Anforderungen an Schutzmaßnahmen und Schutzbedarf sollen in die externe Dokumentation einfließen.

Rechteverteilung

Die Verteilung der Rechte auf die in Abschnitt 3 definierten Akteure soll dokumentiert werden. Insbesondere sollen Änderungen in der Rechteverteilung protokolliert und für spätere Sicherheitsanalysen herangezogen werden können. 

Maschineninventar

Der Hersteller soll ein Maschineninventar erstellen, das sämtliche relevanten Geräte-, Kommunikations- und Managementaspekte (Hard- und Software inklusive) berücksichtigt. Idealerweise ist die Maschine in der Lage, einen Report über die momentan installierten Komponenten mitsamt deren Eigenschaften zu generieren. Eine schematische Auflistung der Komponenten soll den funktionalen Zusammenhang zwischen den Komponenten veranschaulichen.

Dokument-Management

Es sollen organisatorische Prozesse zur Erstellung, Verteilung und Veröffentlichung von Dokumenten definiert werden. Relevante Dokumente sollen in regelmäßigen Abständen auf Aktualität überprüft werden.

Sicherheitsvorfälle

Sämtlichen Sicherheitsvorfälle sollen dokumentiert und archiviert werden. Hierzu zählen Vorfälle innerhalb der Organisation, wenn möglich aber auch Sicherheitsvorfälle, die bei bereits im Betrieb befindlichen Maschinen beobachtet wurden. Die Dokumentation der Sicherheitsvorfälle soll zunächst intern erfolgen. Sind von dem Sicherheitsvorfall auch Dritte betroffen oder bewirkt die Ursache des Vorfalls eine Gefahr für die Umwelt, so soll ein entsprechender Bericht erstellt und kommuniziert werden.

Strategie und Schutzmaßnahmen​

Das Security-Konzept sowie sämtliche Schutzmaßnahmen der Maschine sollen dokumentiert werden. Dies umfasst neben der reinen Funktion der Schutzmaßnahmen auch deren Implementierung, Konfiguration sowie Informationen zur Wartung. Dies ist Grundlage für Überprüfungen von Security-Anforderungen. Idealerweise stellt der Hersteller ein Handbuch zur Security-Funktionalität der Maschine zur Verfügung.

Organisatorische Prozesse und Rollen ​

Sämtliche sicherheitsrelevanten organisatorischen Prozesse sowie die jeweiligen Verantwortlichen, Zuständig und Ansprechpartner sollen dokumentiert werden.

Die Ansprechpartner nach außen hin sollen für externe Akteure dokumentiert und jederzeit erkenntlich sein.

Quelle: VDMA Leitfaden Industrie 4.0 Security

Entwicklerschulungen

Entwicklerschulungen bezüglich Security​

Schulen Sie Ihr Personal in Cyber – Security entsprechend Ihrem Einsatz​

Nichts ausser Wissen ersetzt Wissen. Der Ausbau der Kompetenzen der Mitarbeiter hinsichtlich Informationstechnologie im Allgemeinen, der IT-Sicherheit und Netzwerksicherheit sowie der IT-technischen Besonderheiten von Maschinen im Speziellen gehört zu den dringenden Massnahmen, die für eine nachhaltige Entwicklung und Verbesserung der Sicherheitslage absolut notwendig sind. Hierbei besteht die Anforderung, etablierte Berufsbilder um neu erforderlich gewordene Anforderungen zu ergänzen (die etwa durch Fortbildung gedeckt werden).

Inhalte

  • Awareness der Mitarbeiter steigern, damit kritische Handlungen frühzeitig erkannt werden.​

  • (Software-)Entwickler und Konstrukteure sollen zu den einschlägigen Sicherheitsthemen in Theorie sowie auch mit praktischen Übungen (Hacking und Codeanalyse) regelmässig trainiert werden. ​

  • Maschinen- /Anlagenplaner und Projektierer sollten besonders zu Netzwerk- und Systemsicherheit Bescheid wissen.​

  • Verantwortlicher für Produktschutz müssen sich mit Risikonanalysen im Bereich ICS/SCADA auskennen.​

  • Trainingsmethoden sollen sowohl Sicherheitsgrundlagen als auch technologie-spezifisches Wissen vermitteln und eine Laborumgebung für die praktische Vertiefung der gewonnen Erkenntnisse bieten.​

Quelle: VDMA Leitfaden Industrie 4.0 Security

bottom of page