[Aufmachergrafik: heller, corporate design]IT-Sicherheit für Leittechnik

Ordnungsmerkmale

erschienen in: <kes> 2006#1, Seite 76

Rubrik: Management und Wissen

Schlagwort: Sicherheit für Leittechnik

Autor: Von Christian Gresser, Garching, und Stefan Kubik, Minden

Zusammenfassung: Die viel beschworene Konvergenz der Netze lässt auch immer mehr Leittechnik mit allgemeinen IT-Strukturen zusammenwachsen. In Sachen Sicherheit stellen Regelungs- und Steuerungssysteme jedoch deutlich andere Anforderungen als die "klassische" IT.

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.

Praxisbeispiele

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 ([externer Link] 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 ([externer Link] 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 ([externer Link] www.railpage.com.au/modules.php?name=News&file=article&sid=266, [externer Link] www.news.com.au/story/0,10117,9455677-15306,00.html). Und und und...

Abweichende Sicherheitsziele

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:

[Illustration]
Abbildung 1: Darstellung eines Leitsystems mit redundanter Vernetzung (am Beispiel einer typischen ABB-Aufteilung)

Divergierendes Risikomanagement

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.

Standards

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 ([externer Link] 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".

Work in Progress

Der zukünftige Standard IEC 62443 "Security for Industrial Process Measurement and Control – Network and System Security" der International Electrotechnical Commission ([externer Link] 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 ([externer Link] 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" ([externer Link] 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 ([externer Link] www.BCIT.ca) und herausgegeben vom britischen National Infrastructure Security Co-ordination Centre ([externer Link] www.NISCC.gov.uk) – er enthält zudem eine Reihe konkreter Konfigurationsempfehlungen [7].

Standard Titel Gremium
BS 7799/ISO 17799 Information Security Management British Standards Institute / International Organization for Standardization
ISA SP99 Manufacturing and Control Systems Security Instrumentation Systems and Automation
IEC 62443 (in Arbeit) Security for Industrial Process Measurement and Control – Network and System Security International Electrotechnical Commission
IEC 61784-4 (in Arbeit)
(IEC SC65c WG13)
Digital Data Communications for Measurement and Control, Cyber Security International Electrotechnical Commission
NIST Process Control Security Requirements Forum (PCSRF) Verschiedene System Protection Profiles (SPP) und Protection Profiles (PP) für Leittechnik gemäß Common Criteria (ISO 15408) National Institute for Standards and Technology
NERC Cyber Security Standard in den USA verbindlicher IT-Security-Standard für alle Betreiber von Kraftwerken und Energieversorgungsanlagen North American Electric Reliability Council
NISCC Practice Guide on Firewall Deployment for SCADA and Process Control Networks Firewall Deployment for SCADA and Process Control Networks National Infrastructure Security Coordination Centre
NIST Special Publication 800-40 Procedures for Handling Security Patches National Institute for Standards and Technology

Tabelle 2: Einschlägige Standards zur Sicherheit von Leitsystemen und Automationstechnik

Praxis-Empfehlungen

Sicherheitskonzept

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.

Physische Sicherheit

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.

Systemsicherheit

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.

Software

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.

Netzwerksegmentierung

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.

[Illustration]
Abbildung 2: Mögliche Netzwerk-Segmentierung mit Leittechnik, die weitestgehend den Anforderungen des IEC 62443 entspricht

Viren-Scanner

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!

Patch-Management

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 Access

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.

[Illustration]
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.

Ausblick

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 ([externer Link] www.nesec.de). Stefan Kubik ist ausgewiesener Sicherheitsexperte der ABB Automation Products GmbH ([externer Link] www.abb.de).

Literatur

[1]
Kevin Poulsen, Slammer worm crashed Ohio nuke plant network, [externer Link] http://securityfocus.com/news/6767
[2]
SQL Slammer Worm Lessons Learned for Consideration by the Electricity Sector, North American Electric Reliability Council, [externer Link] www.esisac.com/publicdocs/SQL_Slammer_2003.pdf
[3]
NRC Information Notice 2003-14, Potential Vulnerability of Plant Computer Network to Worm Infection, United States Nuclear Regulatory Commission, [externer Link] www.nrc.gov/reading-rm/doc-collections/news/2003/03-108.html
[4]
Instrumentation, Systems and Automation Society (ISA), Security Technologies for Manufacturing and Control Systems, Technical Report ANSI/ISA-TR99.00.01-2004, März 2004, bestellbar über [externer Link] www.isa.org
[5]
ISA, Integrating Electronic Security into the Manufacturing and Control Systems Environment, Technical Report ANSI/ISA-TR99.00.02-2004, April 2004, bestellbar über [externer Link] www.isa.org
[6]
International Electrotechnical Commission, Enterprise Network – Control Network Interconnection Profile (ECI), IEC/SC 65C/WG 13 Draft v1.04 , Dezember 2004
[7]
National Infrastructure Security Co-ordination Centre (NISCC), NISCC Good Practice Guide on Firewall Deployment for SCADA and Process Control Networks, Revision 1.4, Februar 2005, [externer Link] www.niscc.gov.uk/niscc/docs/re-20050223-00157.pdf
[8]
NIST, Procedures for Handling Security Patches, NIST Special Publication 800-40, August 2002, [externer Link] http://csrc.nist.gov/publications/nistpubs/