Industrie 3.99 ß

Typische IT-Schwachstellen im industriellen Umfeld

Trotz immer stärkerer Vernetzung industrieller IT und auch einer zunehmenden Zahl von
IT-Sicherheitsvorfällen im Bereich der Automatisierungs- und Steuerungstechnik findet man
in der Praxis weiterhin „systemische“ Schwachstellen. Dabei würden auf dem Weg zur
„Industrie 4.0“ oft bereits einfache Maßnahmen für Besserung sorgen.

Von Thomas Störtkuhl, München

IT-Sicherheit ist bei Automatisierungs- und Steuerungsanlagen noch lange keine Selbstverständlichkeit. Erfahrungen des TÜV SÜD zeigen dabei, dass sich viele typische Schwachstellen durch einfache Maßnahmen beheben ließen – oft genug mangelt es nicht zuletzt am nötigen Bewusstsein für die IT-Security und einer achtsamen Zusammenarbeit der Beteiligten. Der folgende Text skizziert wesentliche Schwachstellen, wie sie in Projekten vor Ort und bei Penetrationstests im Industrial- Security-Labor identifiziert wurden.

Engineering-Workstations und USB-Sticks

In vielen Steuerungsumgebungen setzen die Techniker von Dienstleistern Engineering-Workstations ein, die nicht unter der Kontrolle des Anlagen-Betreibers stehen. Diese Workstations werden zudem häufig in den unterschiedlichsten Umgebungen verwendet: sowohl im LAN des Dienstleisters als auch im LAN der betreuten Kunden. Diese Verwendung von Engineering-Workstations in wechselnden IT-Landschaften birgt naturgemäß ein hohes Risiko der Infektion mit Schadsoftware: So kann möglicherweise Malware insbesondere in Umgebungen eingeschleust werden, die den Safety-relevanten Bereich der Steuerung betreffen. Ein ähnliches Gefahrenpotenzial geht von USB-Sticks aus, die ebenfalls unkontrolliert in verschiedenen IT-Infrastrukturen zum Einsatz kommen.

Eine deutliche Reduktion des Risikos schafft hier die Bereitstellung von Workstations oder USB-Sticks, die der Betreiber administriert und kontrolliert. Natürlich müssen solche Systeme den Technikern des Dienstleisters dennoch die erforderliche Arbeitsumgebung bereitstellen, die sie zur Erledigung ihrer Aufgaben benötigen. Diese eher organisatorische Maßnahme trifft bei Dienstleistern nicht immer auf Verständnis – dafür ist offenbar noch einiges an Aufklärungs- und Bewusstseinsarbeit zu leisten. Dienstleister und Betreiber müssen jedoch zusammenarbeiten, um das erhebliche Gefahrenpotenzial von Engineering- Workstations und USB-Sticks zu reduzieren.

Remote-Access

Fernwartungszugänge sind notwendig, damit Dienstleister ihre Wartungsarbeiten kostengünstig ausführen und in Notfällen den Betreiber zeitnah unterstützen können. In vielen Kunden-Projekten hat der TÜV SÜD jedoch folgende unbefriedigende Situationen vorgefunde

  • Die Dienstleister installieren ihre eigene Remote- Access-Lösung beim Betreiber – sie verlangen dies zum Teil sogar als Voraussetzung der kostengünstigen Erbringung ihrer Dienstleistung.
  • Der Betreiber hat mehrere Remote-Access-Lösungen verschiedener Dienstleister in seiner Netzwerkumgebung implementieren lassen.
  • Der Betreiber kann die implementierten Lösungen hinsichtlich der Security nicht prüfen oder überwachen, da im eigenen Hause kein Know-how zur Netzwerksicherheit vorhanden ist.

Spätestens wenn alle genannten Punkte zutreffen, befindet sich der Betreiber bezüglich der Sicherheit der Fernwartungszugänge in einer sehr misslichen Lage. Abhilfe kann nur geschaffen werden, wenn er das notwendige Know-how bei seinen Mitarbeitern aufbaut oder dieses Wissen einkauft. Dann kann der Betreiber in klaren Security-Richtlinien seine Anforderungen für Remote- Access festlegen und die Dienstleister zur Einhaltung verpflichten oder entsprechende Lösungen selbst implementieren und betreiben.

Auch hier muss das Bewusstsein für Security- Belange bei Betreibern wie Dienstleistern noch erhöht und die Zusammenarbeit zwischen den beiden Parteien weiter gefördert werden.

Software

Penetrationstests bringen häufig einfachste Schwachstellen in industrieller Software ans Licht, die sich sehr leicht ausnutzen lassen:

  • unverschlüsselt übertragene oder gespeicherte Passwörter,
  • Schwachstellen, die seit Längerem bekannt sind und für die Exploits im Internet existieren,
  • eigenentwickelte, fehlerhafte kryptografische Algorithmen sowie
  • der Einsatz nicht-getesteter Software von Dritten.

Alle diese Beispiele zeigen, dass in die Software- Entwicklung im industriellen Sektor noch viel stärker als bisher die „Qualität Security“ integriert werden muss – und zwar in allen Phasen der Entwicklung von der Spezifikation der (Security-)Anforderungen, über Design, Implementierung und Tests bis hin zur Auslieferung und Wartung der Software – allem voran sollte ein Mitarbeiter explizit für die Security im Entwicklungsprozess verantwortlich sein.

Wie man die Sicherheit in den Entwicklungsprozess für Software im Bereich Automatisierung und Steuerung integrieren kann, beschreibt zum Beispiel der Standard IEC 62443-4-1 (auch wenn dieser erst in einer Draft-Version vorliegt [6]).

Patch-Management

Das Thema Patch-Management ist für industrielle Steuerungsumgebungen nach wie vor schwierig zu lösen, da meist ein 7x24-Stunden-Betrieb gefordert ist und unproduktive Zeiten auf ein absolut notwendiges Minimum beschränkt werden müssen. Patches können häufig auch nur dann eingespielt werden, wenn dadurch keine Haftungsansprüche verletzt werden.

  • Identifikation der Komponenten, die einen Patch benötigen,
  • Identifikation der Komponenten, die bei definierten Wartungsfenstern einen Patch eingespielt bekommen können,
  • Testprozeduren von Patches in Testumgebungen,
  • definierte Rückfallprozeduren zu einer funktionierenden Infrastruktur, wenn ein neu eingespielter Patch zu Problemen führt sowie
  • vertraglich geregelter Support der Hersteller für das Patch-Management.

Ein wirkungsvolles Patch-Management enthält also sowohl organisatorische und vertragliche als auch technische Maßnahmen (vgl. [2,3]).

Security-Monitoring

Ein effektives Security-Monitoring bildet eine weitere wesentliche Säule der IT-Sicherheit, ist in vielen Unternehmen aber überhaupt nicht oder nur rudimentär vorhanden – letztlich benötigt ein Security-Informationund -Event-Management (SIEM) technische Komponenten wie Logging-Mechanismen, Sensoren und Auswertetools. Auf dem Markt angebotene SIEM-Produkte sind jedoch fast ausschließlich für die Büro-IT konzipiert. Technisch muss daher noch einiges geleistet werden, um zum Beispiel industrielle Protokolle wie PROFINET oder MODBUS in eine SIEM-Infrastruktur integrieren zu können.

Zudem ist eine SIEM-Infrastruktur sinnlos ohne ein definiertes Security-Incident-Handling, das zum Beispiel Kritikalität, zugehörige Bewertungsschemen und die Dokumentation von Sicherheitsvorfällen für das Unternehmen einheitlich definiert, Verantwortlichkeiten und Eskalationspfade beschreibt, Schnittstellen zum Beispiel zum Change-und Problem-Management festlegt und ein Lernen aus Vorfällen ermöglicht – denn nur wer Vorfälle rechtzeitig erkennt und darauf korrekt und schnell reagiert, kann Schäden begrenzen.

Zu beachten ist hier nicht zuletzt, dass mit dem aktuellen Entwurf für ein deutsches IT-Sicherheitsgesetz Betreiber kritischer Infrastrukturen dazu verpflichtet werden, IT-Sicherheitsvorfälle entweder an die Bundesnetzagentur (BNetzA) oder an das Bundesamt für Sicherheit in der Informationstechnik (BSI) zu melden. Somit werden sich die betroffenen Unternehmen zwangsläufig mit einem SIEM-Konzept und Prozessen für das Security- Incident-Handling auseinandersetzen müssen, wenn dies nicht schon längst geschehen sein sollte.

Fazit

Die Erfahrungen aus der Praxis zeigen, dass folgende Aspekte bei der IT-Sicherheit von Steuerungsanlagen bedacht beziehungsweise stärker berücksichtigt werden sollten:

  • Viele Schwachstellen hinsichtlich der IT-Security verlangen nicht unbedingt nach teuren und schwer umzusetzenden technischen Sicherheitsmaßnahmen. Damit bestehen im industriellen Sektor Möglichkeiten von „Quick Wins“, mit denen man die Security schnell, kostengünstig und nachhaltig verbessern kann.
  • Es gibt Security-Standards für das industrielle Umfeld wie zum Beispiel den IEC 62443, die als Leitfaden für IT-Sicherheit dienen können.
  • Das Zusammenspiel von Hersteller, System-Integrator und Betreiber muss auch bezüglich der IT-Security funktionieren – Sicherheit muss auch hier als Prozess begriffen werden.
  • Nach wie vor sind eine Stärkung des Bewusstseins für IT-Security bei allen Beteiligten und eine ausreichende Ausbildung der verantwortlichen Mitarbeiter hinsichtlich der IT-Security dringend notwendig.

Dr. Thomas Störtkuhl ist Teamleiter Industrial IT-Security bei der TÜV SÜD Rail GmbH.

Literatur

[1] ENISA, National Cyber Security Strategies, Practical Guide on Development and Execution, December 2012, www.enisa.europa.eu/activities/Resilience-and-CIIP/ national-cyber-security-strategies-ncsss/national-cybersecurity- strategies-an-implementation-guide

[2] Peter Mell, Tiffany Bergeron, David Henning, Creating a Patch and Vulnerability Management Program, NIST Special Publication 800-40, Version 2.0, http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf

[3] Murugiah Souppaya, Karen Scarfone, Guide to Enterprise Patch Management Technologies, NIST Special Publication 800-40, Revision 3, July 2013, http://dx.doi. org/10.6028/NIST.SP.800-40r3

[4] Paul Cichonski, Tom Millar, Tim Grance, Karen Scarfone, Computer Security Incident Handling Guide, NIST Special Publication 800-61, Revision 2, August 2012, http://dx.doi.org/10.6028/NIST.SP.800-61r2

[5] Keith Stouffer, Joe Falco, Karen Scarfone, Guide to Industrial Control Systems (ICS) Security, NIST Special Publication 800-82, Juni 2011, http://csrc.nist.gov/publications/ nistpubs/800-82/SP800-82-final.pdf

[6] DRAFT IEC 62443-4-1 Industrial communication networks - Network and system security - Part 4-1: Product development requirements, 65/546/NP:2014, siehe etwa http://isa99.isa.org/ISA99%20Wiki/WP-4-1.aspx

[7] BSI, ICS-Security-Kompendium, 2013, www.bsi.bund.de/DE/Themen/weitereThemen/ICS-Security/Empfehlungen/ Empfehlungen_node.h