In diesem Artikel werden die Grenzen & Wechselwirkungen zwischen den Disziplinen der IT Sicherheit (Cyber-/Industrial Security) und Funktionaler Sicherheit (ISO 13849, IEC 62061 ISO 26262, IEC 61508, IEC 61511) behandelt. Dreh- und Angelpunkt ist der Mensch. Im Kontext der Funktionalen Sicherheit wird der Mensch vor mehr oder weniger bekannten Gefahren eines technischen Systems geschützt. Im Kontext der IT Sicherheit (IT Secutity) wird dagegen ein technisches System vor dem Menschen (z.B. Hacker) geschützt, um Schäden durch unbekannte Ein- bzw. Angriffe abzuwehren.
Sie ahnen es schon, während die Gefahrenmenge in der Regel endlich ist, ist die IT Sicherheit dynamisch, oft an die rasante technische Entwicklung gekoppelt. Der digitale Trend hin zu Industrie 4.0 (I4.0, IoT, II4.0) und die zunehmende Vernetzung der Automatisierungssysteme führt zu unerwünschten Wechselwirkungen aus Sicht der Funktionalen Sicherheit. Erste Bestrebungen, diese Gefahren in der Risikobeurteilung nach ISO 12100 zu adressieren finden sich in der ISO/TR 22100-4. Doch wo ist die Grenze zwischen IT und Maschinenbau? Im Folgenden der Versuch, Industrial Security (IT Sicherheit) aus der Perspektive von Functional Safety abzugrenzen.
Theorie vs. Realität zur IT Sicherheit
Im Kontext der Funktionalen Sicherheit (IEC 61508, IEC 61511, IEC 62061, ISO 13849, ISO 26262) sind zwei Eigenschaften im gesamten Sicherheitslebenszyklus wünschenswert. Zufällige Hardwarefehler beherrschen und systematische Fehler vermeiden. Abhängig vom dem Sicherheitsintegritätslevel (IEC 61508: SIL, ISO 13849: PL) werden Bedingungen an die Struktur (Hardwarefehlertoleranz (HFT), Kategorie (Cat.)) und Maßnahmen im Prozess (Analyse, V&V, Unabhängigkeit etc.) definiert. Der Mensch ist eine Quelle für systematische Fehler. Vernetzen ohne Plan und ohne Analyse kommt in der Realität öfters vor. Obwohl absolut jeder Mensch mittlerweile die Auswirkungen eines Softwareupdates auf dem heimischen Computer, auf dem Smartphone oder des WLAN-Routers kennt, wird diese Erfahrung im Arbeitsalltag oft verdrängt. Die Komplexität der Systeme steigt unaufhörlich und diese kann nie zu 100% beherrscht werden. Das heißt, es ist nur eine Frage der Zeit, bis ein Teilsystem, welches eine systematische Schwachstelle besitzt, im Kontext der IT Sicherheit unsicher wird und damit die Sicherheitsintegrität verletzt.
Ein Machine Risk Assessment bzw. eine Risikobeurteilung, eine LOPA oder eine Gefahrenanalyse wird i.d.R. erst modifiziert, wenn sich das Gefährdungspotenzial ändert. Doch wann haben Sie zuletzt eine Bedrohungsnalyse durchgeführt ? Fragen Sie mal Ihren IT Administrator und er wird Augen machen (User – größtes IT Bedrohungssubjekt – kommt und fragt nach Bedrohungsanalyse). Eine Bedrohungsanalyse mit dem Scope (Betrachungsumfang) auf das Industrial Ethernet oder das Netzwerk der Produktion oder den Laptop mit der Programmiersoftware drauf etc… findet sich noch nicht sehr oft.
Normative Bezüge zur IT Sicherheit
Normativ findet sich der Einstieg zur IT Sicherheit in der ISO/IEC-27000-Reihe (Informationssicherheit). Die Prioritäten der Schutzziele in der IT Sicherheit im Office-Bereich sind anders als in der IT-Industrial-Automatisierung (Hochverfügbarkeit, Echtzeit) bzw. Funktionalen Sicherheit (Integrität). Dazu kommt, dass viele Unternehmen die ISO 27001 nur wenig kennen und maximal einige Anforderungen nach dem BSI IT-Grundschutz wegen dem Datenschutz (DSGVO) erfüllen. Wer jedoch die ISO 27001 bereits erfüllt, wird die Anforderungen der IEC 62443 mit wenig Mehraufwand leicht erfüllen können. Netzwerkfähige Produkte und Systeme zur Automatisierung im Industrieumfeld gibts seit 2016 auch zertifiziert nach IEC 62443 (IT Sicherheit für industrielle Automatisierungssysteme). Damit wird bescheinigt, dass der gesamte Lebenszyklus herstellerseitig betrachtet, getestet und überwacht wird. Damit kann der Integrator leichter die IT Sicherheitsanforderungen erfüllen. Für die Kollegen der Prozess- und Anlagensicherheit ist auch die Namur NA 163 empfehlenswert.
Seit 2010 finden sich erste Anforderungen zur Cybersecurity in der IEC 61508, die IEC 61511 hat 2016 nachgezogen. In IEC 61511:2016 findet sich in 8.2.4 die Forderung nach einem Security Risk Assessment des SIS mit Spezifikation einer adäquaten Risikominderungsmaßnahme. Die Lösung dieser Anforderungen aus der IT Sicherheit findet sich in der IEC 62443.
Die IEC hat 4 Teile:
- IEC 62443-1-1 bis IEC 62443-1-4 Allgemeine Anforderungen
- IEC 62443-2-1 bis IEC 62443-2-4 Richtlinien (Anforderungen an Management & Betrieb) bzw. Verfahren (IACS Security- & Patch Management)
- IEC 62443-3-1 bis IEC 62443-3-3 Systeme, Technologien, Security Level (SL)
- IEC 62443-4-1 bis IEC 62443-4-2 Anforderungen an Produkte/Komponenten (Zertifizierung)
Für Systemintegratoren sind IEC 62443-2-3 und -4 sowie IEC 62443-3-3 relevant, während für Hersteller IEC 62443-4-x relevant ist.
Allgemein finden sich viele Gemeinsamkeiten wie z.B. ein „Level“ (SIL, SL) oder gleiche Prozessschritte zwischen der Funktionalen Sicherheit (Safety) und der IT Sicherheit (Security) in den Normen wie IEC 61508 und IEC 62443. Ein Management überwacht und plant, während durch analytische Tätigkeiten eine Menge an Gefährdungen (Hazards) bzw. Bedrohungen (Threads) identifiziert werden und letzendlich das Design beeinflussen. Nun hängt es vom technischen Sicherheitskonzept ab, wie das System, welches eine Sicherheitsfunktion ausführt, gestaltet ist.
Wenn die Logik in einem SIS oder SRP/CS keine Ethernet-Kommunikationsfähigkeiten besitzt (z.B. USB konfigurierbares Sicherheitsrelais), dann wird der Fokus der IT-Bedrohungsanalyse nur auf die Konfigurationssoftware des Sicherheitsrelais gerichtet sein. Ganz anders sieht es beim integrierten Automatisierungsgrundsatz aus. Wenn ich sicherheitsrelevante Funktionen mit verteilten Elementen (Sensor per Ethernet an SPS Controller & Abschaltpfad über eine dezentrale Peripherie am anderen Ende der Anlage) realisiere, dann ist die Kommunikation sicherheitsrelevant und die Elemente sind tendenziell über das LAN zugänglich.
Analysieren, testen & sensibilisieren im Sinne der IT Sicherheit
Eine grundlegende Sicherheitsanforderung ist die Resilienz des Safety Instrumented System (SIS) gegen unbefugtes Eindringen und Stören der Funktion. Nach IEC 62443-4-1 wird der Hersteller sein Industrial Automated Control System (IACS) mittels Communication Robustness Testing (CRT) testen, wenn er ein zertifiziertes Produkt im Kontext der IT Sicherheit im Angebot hat. Wenn Sie jedoch historisch gewachsene Maschinen und Anlagen betreiben, sind Sie in der Verantwortung. Sie müssen ihr IACS und seine Schwachstellen kennen. Es gab eine Zeit, in der alles vernetzt wurde und Fernwartung überall gewünscht und gefordert wurde. Nun sind diese Altlasten (z.B. SCADA + Erweiterungen, Port-Expander/Transducer, Shop-Floor-WLAN-APs etc…) gerade in heutiger Zeit problematisch. Dazu die Datensammelwut der Industrie 4.0 oder dem IoT. Kreative und Agile ITler produzieren in der Cloud maschinenlesbaren Code, der seine Wege findet in die Maschine, wenn das Personal da nicht sensibel ist.
Pauschal wird in der IT-Bedrohungsanalyse argumentiert, dass ein Air-Gap vorhanden ist, also das SIS nicht vernetzt ist und somit keine Bedrohung (Threads) vorhanden ist. Doch was ist mit dem Computer mit der Konfigurationssoftware, welche jährlich mal genutzt wird, um Testungen durchzuführen ? Der wird vielleicht nicht regelmäßig geupdated. Wenn Sie einen Dienstleister einsetzen, prüfen Sie ihn gründlich, denn eigene wie fremde Mitarbeiter werden oft unbewusst zu Innentätern, welche in der Bedrohungsanalyse oft fehlen.
Der Computerwurm Stuxnet hat 2010 Steuerungen vom Typ Siemens Simatic S7 beeinflusst und vorrangig Uranzentrifugen zerstört. Eine Gruppe von Experten hat im Project Basecamp Schwachstellen in PLCs gefunden und veröffentlicht, um die Betreiber zum Handeln zu zwingen. Diese Schwachstellen haben die Betreiber und Hersteller bis dato als nicht relevant angesehen. Dies zeigt mal wieder, dass der Mensch an sich oft ein systematischer Fehler ist und aus Motiven der Bequemlichkeit und des Kapitals handelt.
Der Mitarbeiter als Innentäter ist ein Spezialfall und wird gerne von Hackenr im Rahmen des Social Engineering instrumentalisiert, um einen Zugang zu erhalten. Wenn sich plötzlich Hersteller am Telefon melden udn Detailfragen stellen, wenn USB-Sticks in der Kantine oder auf dem Parkplatz rumliegen, wenn Emails mit Updates und Patches ihren Weg ins Control System finden, war der Hacker über den Weg des Mitarbeiters als unbewusster Komplitze erfolgreich.
Kompetenzüberschreitungen bei IT Sicherheit & FuSi vermeiden
In der Funktionalen Sicherheit versuchen wir, systematisch den systematischen Fehlerquellen auf die Spur zu kommen. Einen Fehler im Programmcode eines Kommunikationsmoduls, welches das Sicherheitsziel durch eine Datenintegritätsverletzung gefährdet, entdecken wir möglicherweise. Doch das ein Fehler in einem Netzwerkverteiler (Layer 3 Switch) zu einer offenen Tür für einen Menschen mit schlechten Absichten führt, entdecken wir in einem Black-Channel-Kommunikationsprinzip eher nicht aus dieser Perspektive. Was wir aus der Funktionalen Sicherheit selbstverständlich tun, ist ein Härten des Systems (SIS). Wir prüfen die Datenintegrität und sichern diese in einem Sicherheitskonzept ab. Doch müssen wir gerade bei Sicherheitsfunktionen im Netzwerk auch den sicheren Zustand bei Kommunikationsfehlern berücksichtigen. Gerade zeitsensistive Netzwerke (TSN) im Fail-Safe-Kontext mit Zwischenzuständen bis zum sicheren Zustand sind problematisch und genauer zu analysieren.
Die IT hat Ihre Technologien wie z.B. Protokolle auf unterschiedlichen Ebenen (HTTP, Modbus, DirectNet, TCP/IP, TFTP (CLI)). Mit dem Know How über diese Technologien lässt sich viel erreichen. Wenn sich eine FTP-Session öffnen lässt, ist es zum buffer overflow oft nicht weit. Gerade Altanlagen müssen ausreichend geschützt werden, denn oft steckt in der Tiefe des Altbestandes die Verletzlichkeit des Systems.
IT Sicherheit – ein moving target in der Automatisierung ?
Egal welches Cyber-Security Konzept (Defense In Depth, air gap) sie umsetzen, es gibt keine dauerhafte 100% Lösung zur IT Sicherheit. Die Lösung steckt in Ihnen, Ihrer Firmenkultur und Ihrer Kompetenz. Dort wo eine Serielle-, USB-, oder Ethernet-Schnittstelle ist, muss genauer analysiert werden. Achten Sie bei der Planung auf den Einsatz zertifizierter Produkte. Ein Produkt mit ISA-Secure-Zertifikat nach ISA-62443-4-1 & -2 ist stets zu bevorzugen. Wenn Sie als Integrator selbst verantwortlich sind, machen Sie sich Gedanken, welche Schwachstellen vorhanden sind. Sie nutzen i.d.R. MS Windows, Datenbanksysteme und Kommunikationsprotokolle wie TCP/IP. Dies macht Sie angfreiffbar, wenn in diesen Systemen Schwachstellen durch Hacker gefunden wurden. Sie integrieren Ihre Maschinen in das Firmennetzwerk, Sie lassen evtl. eine Fernwartung zu. Eine Hackerorganisation arbeitet 24/7 und hat Zugriff auf die Einrichtungsanleitungen der verwendeten Teilsysteme wie WLAN-AP oder die SPS oder den Gateway oder das VoIP Telefon. Default Benutzernamen und Kennwörter sind oft unverändert.
