IT-Sicherheit in Regelungs- und Steuerungssystemen unterscheidet sich grundlegend von den typischen Anforderungen einer klassischen IT-Infrastruktur. Diese entscheidenden Unterschiede sind jedoch den IT-Sicherheitsverantwortlichen längst nicht in jedem Unternehmen bewusst und selbst externe Sicherheitsberater sind von den stark divergierenden Anforderungen häufig überrascht.
Unternehmen, die ihre Regelungs- und Steuerungssystemen an das Firmennetz anbinden wollen, stehen vor einer besonderen Herausforderung: Die installierten Systeme, egal ob zur Steuerung der Klimatechnik eines Hochhauses oder zur Regelung der Heizkessel in einem Kraftwerk, sind klassischerweise fast immer isolierte Systeme gewesen. Dieser Schutz durch Isolation entfällt aber durch den Wunsch nach Vernetzung. Die Gefahr: Viele derartige Systeme sind nicht gehärtet und können – wenn überhaupt – erst nach Freigabe durch den Hersteller mit Patches und Updates versorgt werden, da sonst einerseits die Gewährleistung erlischt und andererseits der ungestörte Betrieb der Produktionsanlage nicht mehr gesichert ist.
Das zeigt auch der Fall eines Herstellers von Systemen zur Gebäudeautomation, der seinem Kunden ausdrücklich schriftlich bestätigt hat, dass Patches auf den Systemen nicht eingespielt werden dürfen, da sonst der Betrieb gestört werden kann. Die letzten Updates stammen jedoch noch vom Mai 1999 angesichts des Jahrtausendwechsels. Zum Zeitpunkt der Installation war das Netz zur Gebäudeautomation komplett isoliert; seit einigen Jahren besteht aber eine Verbindung zum Unternehmensnetz – ein sich dort verbreitender Wurm könnte so vermutlich die gesamte angeschlossene Haustechnik stilllegen.
Ein noch drastischeres Beispiel der Schwierigkeiten von IT-Sicherheit in Produktionsanlagen lieferte Anfang 2005 der Betreiber einer Nahrungsmittelfabrik in Belgien: Auf Wunsch der Geschäftsleitung wurden die Leittechnik-Systeme mit dem Firmennetz verbunden, um im Warenwirtschaftssystem laufend die aktuellen Produktionsdaten abrufen zu können. Da die Leittechnik nicht auf aktuellem Patchlevel gehalten werden konnte, führte ein per Notebook eingeschleppter Wurm zu einem fast 24-stündigen Ausfall der Produktionsanlage. Nach dem Wiederanfahren zeigte eine Analyse der IT Security Group, dass tatsächlich fehlende Patches und Viren-Scanner für den Ausfall verantwortlich waren – diese wurden prompt installiert. Der Viren-Scanner behinderte jedoch den Echtzeitzugriff auf die Datenbank. Das führte schließlich – inklusive Deinstallation des Scanners – zu einem weiteren mehrstündigen Ausfall der Anlage.
Leider sind solche Vorkomnisse keine Einzelfälle: Bereits im Januar 2003 drang der Slammer-Wurm über einen fehlerhaft konfigurierten Remote-Access-Zugang in die Davis-Besse Nuklearanlage ein. Das Netzwerk wurde überlastet und die Server-Kommunikation gestört; die Überwachungssysteme zur Reaktorsicherheit fielen für fünf Stunden aus. Die Anlage war zu diesem Zeitpunkt bereits wegen Wartungsarbeiten stillgelegt, sodass kein schlimmerer Schaden eintrat [1,2,3].
Im August 2003 führte eine "Cyberterrorismus"-Gruppe der US Air Force einen simulierten Angriff auf das Stromnetz der Vereinigten Staaten durch und erlangte Kontrolle über die Stromverteilung der Westküste zwischen Seattle und San Diego ( www.newsmax.com/archives/articles/2003/8/19/121729.shtml). Ein Hackerangriff auf die IT-Systeme des größten amerikanischen Hafens in Houston, Texas führte im Oktober 2003 zum Ausfall aller Steuerungs- und Kontrollsysteme zur Überwachung der Schiffe ( www.guardian.co.uk/uk_news/story/0,3604,1057364,00.html). Im Mai 2004 stecken 300 000 Passagiere auf australischen Bahnhöfen und in Zügen fest: Der Sasser-Wurm wird verdächtigt, für den Ausfall beim Betreiber RailCorp in New South Wales verantwortlich zu sein ( www.railpage.com.au/modules.php?name=News&file=article&sid=266, www.news.com.au/story/0,10117,9455677-15306,00.html). Und und und...
Das oberste Sicherheitsziel der IT-Sicherheit ist in vielen Unternehmen die Vertraulichkeit der Daten. Der IT-Leiter einer großen Online-Bank sagte einmal wörtlich: "Hier geht nichts raus. Wenn irgendwo die Gefahr besteht, dass Externe Zugriff auf Kundendaten bekommen oder Daten sonstwie kompromittiert werden, wird zuerst abgeschaltet. Und dann kümmern wir uns um das Problem". Das funktioniert sehr gut in einer Bank, die alternative Möglichkeiten wie Telefon oder Fax hat, mit ihren Kunden zu kommunizieren. Mit der Steuerung eines chemischen Reaktors, einer Ölbohrplattform in der Nordsee, eines Heizkraftwerks oder sogar Kernreaktors mitten in Europa funktioniert das hingegen nicht. Das elementare Sicherheitsziel dieser Steuerungssysteme ist die Verfügbarkeit. Die folgenden Beispiele sollen die unterschiedlichen Anforderungen deutlich machen:
Abbildung 1: Darstellung eines Leitsystems mit redundanter Vernetzung (am Beispiel einer typischen ABB-Aufteilung)
Leittechnik verlangt deshalb heute nach Sicherheitssystemen, die kostengünstig und ökonomisch an den Standorten der verteilten Controller implementiert werden können. Vielen IT-Sicherheitsbeauftragten und Beratern für IT-Sicherheit ist zudem nicht bewusst, dass die abweichenden Sicherheitsziele auch divergierende Ziele im Risikomanagement bedeuten (vgl. Tab. 1): Während "normale" IT als Hauptrisiko oft den Verlust der Vertraulichkeit und Integrität von Daten (dadurch Geschäftseinbußen) ansieht, liegt das Hauptrisiko bei Automationstechnik bei Schäden an Leib und Leben, Umwelt oder Material. Der Schutz von Daten (IT) muss dabei hinter dem Schutz von Menschen und Umwelt (Automation) zurückstehen. Statt einfachem Abschalten und Neustart bei Fehlern ist zudem in der Leittechnik eine erhöhte Fehlertoleranz elementarer Bestandteil.
Ein Beispiel: Eine Betreiberfirma von Ölbohrplattformen verlangt für den Betriebsleiter die Möglichkeit, sich innerhalb von 15 Sekunden einen Überblick über den Zustand der gesamten Anlage zu verschaffen. Da bereits die Anmeldung an einem Betriebssystem und der Start der entsprechenden Anwendung in der Regel länger dauern , sind automatische Bildschirmsperren oder automatisches Logout untersagt.
Unternehmens-IT | Leittechnik | |
---|---|---|
Hauptrisiko | Verlust von Daten | Schaden an Leib und Leben, Umweltschäden, Zerstörung von Produktionsanlagen |
Risikomanagement | Wiederherstellung durch Reboot | Fehlertoleranz überlebenswichtig |
Betriebssicherheit (safety) ist kein Schwerpunkt | explizite Gefährdungsanalysen (oft sogar gesetzlich vorgeschrieben) | |
Ausfallsicherheit | gelegentliche Ausfälle tolerierbar | Ausfälle nicht tolerierbar |
Betatest im Betrieb akzeptabel (und bei Standard-Software oft üblich) | umfassende Qualitätssicherung vorab notwendig | |
Leistungsanforderungen | hoher Durchsatz (Bandbreite) vom Benutzer verlangt | bescheidene Durchsatzraten sind oft akzeptabel |
Verzögerungen und Schwankungen in der Qualität akzeptiert | Zeitverzug ist bei Produktionsanlagen ein Sicherheitsrisiko | |
Sicherheit | viele Standorte physisch kaum gesichert (Besuchsverkehr etc.) | hohe physische Sicherheit |
kaum Segmentierung interner Netzwerkbereiche | Unternehmensnetze von Produktionsnetzen oft (noch) streng getrennt | |
Fokus liegt auf der Absicherung zentraler Dienste und Server | Fokus liegt auf der Zugangskontrolle sowie Betriebssicherheit und Verfügbarkeit |
Tabelle 1: Sicherheitsanforderungen und Risikomanagement der Leittechnik betonen Verfügbarkeit und Betriebssicherheit und weniger die Vertraulichkeit von Daten.
Für die Sicherheit von Regelungs- und Steuerungssystemen sind etliche spezielle Standards verfügbar und bei verschiedenen Gremien in Arbeit (vgl. Tab. 2). Doch auch die aus der "normalen" IT-Sicherheit bekannte ISO 17799, die auf dem BS 7799 "Information Security Management" des British Standards Institute beruht, ist hier zur Einführung eines umfassenden Sicherheitsmanagements im Unternehmen sowie mit einer Reihe von Empfehlungen zur Absicherung der IT-Infrastruktur einschlägig.
Zudem führt der ISA SP99 "Manufacturing and Control Systems Security" der Instrumentation, Systems and Automation Society ( www.ISA.org) in einer Reihe von Arbeitsgruppen IT-Sicherheitstechniken ein: Working Group (WG) 1 behandelt Security Technologies for Manufacturing and Control Systems [4], in WG 2 geht es um Integrating Electronic Security into the Manufacturing and Control Systems Environment [5] (SP99 Teil 2) und WG 3 erstellt Teil 1 des Standards SP99 "Part 1: Reference Model".
Der zukünftige Standard IEC 62443 "Security for Industrial Process Measurement and Control – Network and System Security" der International Electrotechnical Commission ( www.IEC.ch) definiert für eine Reihe von Profilen (u. a. Verbindung zum Corporate Intranet, Remote Operation und Dial-up Remote Access) Anwendungsszenarien sowie Bedrohungen und mögliche Empfehlungen. Von etlichen Profilen liegen inzwischen Drafts vor, die Verabschiedung des Standards wird für Ende 2007 erwartet.
Der ebenfalls noch nicht verabschiedete Standard IEC 61784-4 von der IEC-Arbeitsgruppe SC65c (Digital Communications Committee) WG13 (Cyber Security Workgroup) "Digital data communications for Measurement and Control, Cyber Security" soll eine umfassende Beschreibung von Sicherheitsanforderungen für Anbieter und Integratoren von Komponenten und Systemen der Leittechnik bieten. Die Arbeitsgruppe tagt seit Januar 2004, die Verabschiedung des Standards wird ebenfalls für Ende 2007 erwartet [6].
Das Process Control Security Requirements Forum (PCSRF), geleitet vom US-amerikanischen National Institute for Standards and Technology ( www.NIST.gov), entwickelt darüber hinaus eine Reihe von System Protection Profiles (SPP) und Protection Profiles (PP) für die Leittechnik. Ziel ist die Evaluierung von Systemen und Komponenten nach Common Criteria (CC) Evaluation Assurance Level (EAL) 3 und EAL 3+. Hier liegen bereits System Capabilities Profile (ICS-SCP) vom September 2003 und System Protection Profile (ICS-SPP) vom April 2004 vor. Die Vorschläge des Forums werden von den Leittechnik-Herstellern jedoch nur langsam angenommen, da bestehende Systeme die Anforderungen in der Regel nicht erfüllen und die Zertifizierung zu aufwändig erscheint.
Eine standardisierte Vorgehensweise zur Inventarisierung von Software und Implementierung eines effizienten Patch-Managements beschreibt die NIST Special Publication 800-40 "Procedures for Handling Security Patches" [8].
Der NERC Cyber Security Standard des North American Electric Reliability Council ist der in den USA verbindliche Standard zur Absicherung kritischer Energieversorgungsinfrastruktur sowie von Kraftwerken. Der Standard wurde nach 2001 entwickelt und gilt seit August 2003 als "Urgent Action Standard" ( www.nerc.com/~filez/standards/Cyber-Security-Permanent.html).
Anforderungen an eine Firewall in der Leittechnik beschreibt der NISCC Practice Guide on Firewall Deployment for SCADA and Process Control Networks, entwickelt vom British Columbia Institute of Technology ( www.BCIT.ca) und herausgegeben vom britischen National Infrastructure Security Co-ordination Centre ( www.NISCC.gov.uk) – er enthält zudem eine Reihe konkreter Konfigurationsempfehlungen [7].
Tabelle 2: Einschlägige Standards zur Sicherheit von Leitsystemen und Automationstechnik
In praktisch allen größeren Unternehmen existiert ein Sicherheitskonzept, das zumindest eine Richtlinie, in der Regel aber detaillierte Forderungen zur Einhaltung der IT-Sicherheit in den betriebsrelevanten Systemen enthält. Dieses Sicherheitskonzept gilt es auf alle Systeme in Produktionsumgebungen auszudehnen. In diesem Zuge müssen gleichzeitig geeignete Sicherheitsmaßnahmen für diese Systeme entwickelt werden, die sich wie angemerkt oft grundlegend von den "üblichen" Maßnahmen unterscheiden.
Alle Systeme einer Leittechnik-Installation sollten auch physisch gesichert sein: Der Zugang zu Systemen, Netzwerk, Controllern und sonstigem Equipment sollte auf berechtigte Benutzer beschränkt werden.
Nur berechtigte Benutzer sollten sich an Leittechnik anmelden dürfen. Kennungen sollten nicht von mehreren Benutzern verwendet (z. B. Operator), sondern immer personalisiert werden. Aktuelle Leittechniksysteme sind gezielt auf die Anforderungen des US-amerikanischen Sarbanes-Oxley Act (SOX) ausgelegt, aus dem sich unter anderem eine Protokollierung sicherheitsrelevanter Ereignisse herleiten lässt. Diese Protokollierung lässt sich jedoch nur mit zuordnungsfähigen – nicht jedoch mit gemeinsam genutzten – Kennungen erreichen. Die Hersteller der Leittechnik sollten diese Umstellung gezielt fördern, beispielsweise durch die Vermeidung von Default-Accounts sowie der Möglichkeit, alle Aktionen im System zu protokollieren.
Die Installation von Software auf Leittechniksystemen sollte untersagt und technisch verhindert werden. Die Nutzung von CD-ROMs, DVDs und sonstigen Datenträgern sollte eingeschränkt und nur virengeprüfte Datenträger dürfen verwendet werden. Anwender von Leittechnik sollten entsprechende Regelungen erlassen und Software zur Sperrung von Datenträgern oder eine geeignete Systemhärtung implementieren. Hier sind primär auch die Hersteller von Produktionsanlagen gefordert, diese Software zu testen und gegebenenfalls Implementierungsempfehlungen herauszugeben. Bei einer Ausschreibung für neue Anlagen kann jedoch bereits im Vorfeld gezielt darauf geachtet werden, Anforderungen an die IT-Sicherheit in die Ausschreibungsunterlagen mit aufzunehmen.
Das Leittechnik-Segment sollte vom restlichen Unternehmensnetz getrennt beziehungsweise logisch separiert bleiben, da dieses Netz nicht als vertrauenswürdig erachtet werden kann (vgl. Abb. 2). Um Angriffe auf die Produktionsanlage rechtzeitig erkennen zu können, sollte ein Intrusion Detection/Prevention System (IDS/IPS) implementiert werden. Da viele Leittechniksysteme proprietäre Kommunikationsprotokolle verwenden und häufig konkrete Anforderungen an die Firewall und IDS/IPS gestellt werden, sollten Anwender von den Herstellern der Leittechnik Empfehlungen zur Firewall-Konfiguration und detaillierte Traffic-Flow-Dokumente einfordern.
In der Praxis sind Firewall-Systeme mit Protokollanalyse (Deep Inspection, Application Intelligence) sinnvoll, als Appliance bieten sie darüber hinaus den Vorteil, bei einem Fehler schnell wiederhergestellt werden zu können. Als Intrusion Protection System haben sich vor allem überwiegend protokollbasierte Systeme bewährt, da weniger Tuning und kein permanentes Updates der Signaturen erforderlich ist.
Abbildung 2: Mögliche Netzwerk-Segmentierung mit Leittechnik, die weitestgehend den Anforderungen des IEC 62443 entspricht
Alle genutzten Medien sollten vor der Verwendung auf Viren untersucht werden. Auf den Systemen der Leittechnik sollten Viren-Scanner jedoch mit Vorsicht und nur nach Freigabe des Herstellers eingesetzt werden. Die meisten Hersteller liefern inzwischen detaillierte Konfigurationsempfehlungen der unterstützten Produkte; ansonsten sollten Anwender solche Empfehlungen vom Hersteller einfordern.
Achtung: Eine ganze Reihe von Produktionssystem-Anbietern lehnt die weitere Wartung der Systeme ab, wenn nicht-autorisierte Sicherheitsprogramme installiert werden. Die Konfiguration des Viren-Scanners verlangt in der Regel, dass die Verzeichnisse der Leittechnik-Software vom Scan-Prozess explizit ausgenommen werden, da immer wieder Probleme auftreten. In einer Testumgebung hat ein Viren-Scanner eines namhaften Herstellers schon einmal die Steuerungssoftware einer Produktionsanlage fälschlicherweise als Virus erkannt – ein Blockieren des Zugriffs oder automatisches Löschen wäre in solchen Fällen fatal!
Patches dürfen in der Regel erst nach Freigabe des Leittechnik-Herstellers eingespielt werden. Anwender sollten hier konkret Druck auf die Hersteller ausüben, Patches innerhalb einer Woche zu testen und freizugeben. Die Hersteller-Tests sollten dabei zumindest die jeweils aktuelle sowie eine Vorgängerversion des Produkts umfassen. Auch hier sind primär die Anbieter gefordert; Anwender sollten die Verfügbarkeit von Informationen zum Patch-Management ebenso wie zum Virenschutz jedoch bereits beim Entscheidungsprozess für eine Lösung mit berücksichtigen.
Remote-Zugriff auf eine Produktionsanlage zählt zu den heikelsten Anforderungen an eine sichere Infrastruktur. Einerseits muss der Zugriff verschlüsselt und mit starker Authentifizierung erfolgen, zum anderen muss der ein- und ausgehende Datenstrom umfassend überwacht und kontrolliert werden. Dabei spielen neben dem Zugriff über das Internet auch klassische Dial-in-Verfahren mit Modem und ISDN weiterhin eine wichtige Rolle.
Abbildung 3: Mögliche Architektur für den Remote Access über Einwahlleitungen
Das Hauptproblem beim Zugang über das Internet ist die dafür notwendige Anbindung des oft isolierten Produktionsnetzes an das Firmennetz. Hier sind bereits umfangreiche Sicherheitsmaßnahmen notwendig. Ein weiterer Knackpunkt ist die Terminierung der verschlüsselten Verbindung: Aus Sicht einer Leit-Anlage ist ein VPN-Gateway möglichst nahe an der Anlage wünschenswert, die zentrale Unternehmens-IT bevorzugt ein VPN-Gateway in der DMZ. Bewährt haben sich in der Praxis Zugänge über ein SSL-basiertes Virtual Private Network (VPN), bei dem über einen Browser eine Verbindung zu einem Terminal-Server in der Produktionsanlage aufgebaut werden kann. Von diesem Server ist dann der Zugriff auf die anderen Systeme der Anlage möglich.
Aspekte der IT-Sicherheit | Unternehmens-IT | Steuerungs- und Regelungs-IT |
---|---|---|
Lebenszeit der Systeme | 3–5 Jahre | 5–20 Jahre |
Anti-Virus | weit verbreitet | oft schwierig/unmöglich zu installieren (verträgt sich nicht mit der Leittechnik) |
Patch-Management | weit verbreitet (oft tägliche Updates) | kaum (Einspielen von Patches erst nach Freigabe des Herstellers möglich) |
System-Änderungen | regelmäßig | selten |
Kritische Anwendungen | Verzögerungen oder Abstürze sind tolerierbar | Verzögerungen sind bereits kritisch, Abstürze sicherheitsrelevant |
Verfügbarkeit | Ausfall / Reboot in der Nacht möglich | 24/7/365-Betrieb |
Sicherheitserfahrung und -bewusstsein | relativ hoch | kaum vorhanden |
Sicherheits-/Penetrationstests | weit verbreitet | können nur mit Vorsicht eingesetzt werden |
Physische Sicherheit | oft Sicherheitsbereiche für die IT mit ständiger Bewachung | oft weit entfernte, unbemannte Betriebsstellen |
Outsourcing | relativ weit verbreitet | selten für Betriebsanlagen |
Tabelle 3: Sicherheitsmechanismen in der Unternehmens-IT sowie in Steuerungsnetzen haben unterschiedliche Anforderungen. Hier sind sowohl Anwender als auch Hersteller gefordert, geeignete Lösungen zu implementieren, um die Sicherheit in Steuerungs- und Leitsystemen auf einen Stand vergleichbar zum restlichen Unternehmensnetz zu bringen.
Die Interkama als Leitmesse für Regelungstechnik in Hannover hat bereits im letzten Jahr gezeigt, dass ein verstärkter Bedarf zur Anbindung der ehemals isolierten Leittechnik-Netze an das allgemeine Firmennetz besteht. Zum einen sind Unternehmen gezwungen immer flexibler auf neue Anforderungen zu reagieren und müssen daher in Echtzeit im Warenwirtschaftssystem den Ausstoß der Produktion erkennen können, zum anderen werden lokale Leitwarten häufig aus Kostengründen wegrationalisiert. Selbst komplexe Anlagen müssen aus der Ferne von einer zentralen Leitwarte komplett gesteuert werden, ohne dass dieser Betrieb mit besonderen Risiken verbunden sein darf.
Mit der zunehmenden Vernetzung geraten aber auch die Automations-Systeme künftig immer stärker ins Visier gezielter (Hacking, Sabotage) und ungezielter (bspw. Malware) Angriffe – IT-Sicherheit muss daher unter Berücksichtigung der besonderen Anforderungen auch in der Steuer-, Regelungs- und Leittechnik implementiert werden. Hier sind neben den Anbietern auch die Anwender gefragt, die bei der Auswahl und Wartung entsprechende (ggf. unbequeme) Nachfragen an die Hersteller richten sollten – nicht zuletzt um ihrer eigenen Pflicht zum Risikomanagement nachzukommen.
Christian H. Gresser ist geschäftsführender Gesellschafter der NESEC Gesellschaft für angewandte Netzwerksicherheit mbH ( www.nesec.de). Stefan Kubik ist ausgewiesener Sicherheitsexperte der ABB Automation Products GmbH ( www.abb.de).
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2006#1, Seite 76