Das in der Business-IT allgegenwärtige Ethernet und das Internet-Protokoll (IP) erobern zunehmend auch den Factory Floor. Getrieben wird diese Entwicklung von dem Wunsch nach einer durchgängigen Datenkommunikation von der Feldebene bis hinauf in die ERP-Systeme (Enterprise Resource Planning) der Unternehmen. Zudem versprechen solche Lösungen Kostenvorteile durch Standardisierung und die Verwendung von Massenprodukten, aber auch durch die Vereinheitlichung und den gemeinsamen Betrieb der bisher völlig getrennten Netzwerk-Welten. Hinzu kommt der massive Trend zur Fernwartung von Produktionsanlagen, die sich über eine offene Netzwerkumgebung mit Standardprotokollen leichter und effizienter implementieren lässt. Doch je weiter Industrial Ethernet und IP Einzug in die Produktionsumgebung halten, desto anfälliger werden solche Umgebungen für alle aus der Office-Welt bekannten Sicherheitsrisiken vom Virenbefall bis hin zur Industriespionage. Absicherung tut also Not – aber wer ist dafür verantwortlich?
IT und Produktion
Die IT-Abteilung besitzt ein über viele Jahre gewachsenes Know-how in Sachen IP und Security, hat aber nur unzulänglichen Einblick in die Notwendigkeiten und Gegebenheiten in der Produktion, die sich ganz grundlegend von denen im Büro unterscheiden. Die Produktionsleitung dagegen kennt ihre Fertigungsprozesse aus dem Effeff, hatte aber auf Grund ihrer historischen IT-Struktur mit autonomen und gegenüber der Außenwelt abgeschotteten Produktionszellen noch wenig Anlass, sich mit dem Thema IT-Security zu beschäftigen. Es scheint daher nahe liegend, dass IT-Abteilung und Produktion gemeinsam Lösungen zur Absicherung der Produktionsanlagen entwickeln.
Doch wenngleich dieser Ansatz richtig und notwendig ist, sollte man trotzdem nicht erwarten, dass die Spezialisten aus IT und Produktion eine Aufgabe lösen können, die gar nicht definiert ist. Denn wenn nicht zunächst festgelegt wird, was das Unternehmen überhaupt unter IT-Sicherheit in der Produktion versteht, welche Einrichtungen gegen welche Gefahren abgesichert werden sollen, welche Restrisiken tragbar erscheinen und welche Mittel überhaupt zur Verfügung stehen, operieren IT und Produktion im luftleeren Raum. Das bedeutet aber mit anderen Worten, dass das Management des Unternehmens Vorgaben machen muss – Sicherheit ist Chefsache. Und wenngleich das Top-Management sicher kein Betriebskonzept erarbeiten wird, ist es doch seine Aufgabe, über eine Leitlinie zur Sicherheitspolitik den Rahmen zu definieren, in dem ein solches Konzept entstehen kann. In dieser Leitlinie muss verbindlich für das gesamte Unternehmen festgelegt werden, welche Ziele erreicht werden sollen, warum und für wen sie erreicht werden sollen und wer für die Erreichung verantwortlich ist. Die Verbindlichkeit für das gesamte Unternehmen stellt dabei sicher, dass Produktion und IT an einem Strang ziehen, weil sie die gleichen Ziele haben.
Sicherheit als Prozess
Erst wenn Geschäftsführung oder Vorstand eine Leitlinie zur IT-Sicherheit im Unternehmen entwickelt und kommuniziert haben, ist es sinnvoll, den Aufbau eines Informationssicherheits-Management-Systems (ISMS) anzugehen. Dabei ist zu berücksichtigen, dass IT-Sicherheit nicht ein statischer Zustand ist, sondern ein Prozess mit einer Vielzahl von Regelgrößen und Rückkopplungen. Zudem hängt Sicherheit immer primär vom Menschen ab, nämlich vom Verhalten der Mitarbeiter ebenso wie von dem der Sicherheitsverantwortlichen. Die Natur der IT-Sicherheit als ein Prozess legt nahe, auch die Entwicklung eines ISMS prozessorientiert anzugehen. Bewährt hat sich dabei das PDCA-Modell (Plan-Do-Check-Act), das auch der DIN ISO/IEC 27001 zugrunde liegt, in der ein Modell für die Einrichtung und den Betrieb eines ISMS beschrieben wird.
Die Entwicklung eines Sicherheitskonzepts lässt sich in der Regel am effizientesten angehen, wenn das Management ein IT-Sicherheitsteam aus Mitarbeitern unterschiedlicher Bereiche zusammenstellt und innerhalb des Teams auch klare Verantwortungsbereiche definiert. Größe und Zusammensetzung eines solchen Teams werden dabei immer von der jeweiligen Aufgabe und vom zu realisierenden Projekt abhängen. Zumindest sollten aber der IT-Leiter, der Produktionsverantwortliche und der IT-Sicherheitsbeauftragte zu diesem Team gehören. Weitere Teilnehmer können beispielsweise Spezialisten für IT-Security oder der Datenschutzbeauftragte des Unternehmens sein. Expertenwissen darf dabei auch durch externe Berater eingebracht werden – so ist es oftmals sinnvoll, einen Rechtsanwalt oder Consultants eines Systemhauses in das Team einzubinden. Aufgrund der potenziell starken Auswirkungen eines Sicherheitskonzepts auf die Mitarbeiter kann es empfehlenswert sein, auch den Betriebsrat über einen Vertreter im Team von vornherein einzubinden. Schließlich lässt die Einbindung der Unternehmensführung erwarten, dass die Umsetzung von Handlungsempfehlungen sich deutlich beschleunigt. Mit der Bildung eines IT-Sicherheitsteams vermeidet man einen der zwei häufigsten Gründe für das Scheitern von Sicherheitsinitiativen: die schlechte oder gar fehlende Zusammenarbeit der unterschiedlichen Organisationen innerhalb des Unternehmens. Der prozessorientierte Ansatz und das PDCA-Modell nehmen sich des anderen an – des Versuchs, IT-Sicherheit durch die Implementierung eines Bündels organisatorischer und technischer Maßnahmen zu erreichen. Denn die Implementierung eines ISMS gehört zur Do-Phase des PDCA-Modells und setzt demzufolge zwingend eine Planungsphase voraus. Diese Planungsphase sollte im Wesentlichen die Identifizierung und Bewertung der zu schützenden Werte sowie eine eingehende Risikoanalyse umfassen.
Am Anfang steht die Analyse
Wenn ein Sicherheitskonzept entwickelt werden soll, steht zunächst einmal die Frage im Raum, welche Werte (Assets) im Bereich der IT überhaupt geschützt werden müssen. Um hier zu sinnvollen Antworten zu kommen, hat es sich bewährt, die vorhandenen Prozessketten in der Produktion näher zu analysieren. Für jede einzelne Station innerhalb einer Prozesskette müssen dabei einige grundlegende Fragen beantwortet werden. Dabei geht es zunächst darum, festzustellen, welche IT-Ressourcen an der jeweiligen Station überhaupt benötigt werden. Essentiell ist die Frage, wie lange die Station ohne IT „überleben“ kann, sprich nach welcher Ausfallzeit auch andere Stationen beeinträchtigt werden. Zudem muss betrachtet werden, was nach einem Ausfall getan werden muss, um den Betrieb wieder aufnehmen zu können. Schließlich sind auch die Abhängigkeiten der einzelnen Stationen voneinander im Detail zu analysieren.
Bei diesem Vorgehen entsteht sehr schnell ein Bild davon, welche Assets benötigt werden und – vor allem – wie wichtig diese für die Produktion und das Unternehmen sind. Zudem zeigen sich sehr deutlich die Schnittstellen sowohl innerhalb der Produktion als auch zu anderen Organisationen innerhalb wie außerhalb des Unternehmens – etwa zur Auftragsabwicklung oder zur IT. Nach der Identifizierung und Bewertung der Assets sollte dann eine umfassende Risikoanalyse erfolgen. Dabei geht es darum, die Bedrohungen und die Schwachstellen zu identifizieren und unter Einbeziehung der Wichtigkeit der einzelnen Assets eine Risikobewertung vorzunehmen. Erst aus dieser Bewertung können dann tatsächlich Handlungs- und Budgetempfehlungen abgeleitet werden. Hierfür werden „To-Dos“ definiert, priorisiert, mit Budgetansätzen versehen und zur Freigabe an das Management gegeben. Erst mit der Freigabe durch die Unternehmensführung ist die erste Planungsphase beendet und das ISMS festgelegt. Da keine Organisation sich zu 100 Prozent gegen alle Risiken absichern kann, ist in diesem Zusammenhang auch die Zustimmung des Managements zu den vorgeschlagenen Restrisiken erforderlich.
Das Betriebskonzept
Mit der Freigabe durch das Management hat das IT-Sicherheitsteam einen fest umrissenen Auftrag zur Implementierung des ISMS, in dem Ziele, Maßnahmen und Verantwortlichkeiten klar definiert sind. Da im ISMS bereits festgeschrieben ist, welche Assets gegen welche Bedrohungen geschützt werden müssen und welche Restrisiken akzeptabel sind, kann nun ein Betriebskonzept für dieses ISMS entwickelt werden. Dabei sind sowohl technische als auch organisatorische Aspekte zu berücksichtigen. Ein technisches Betriebskonzept soll im Grundsatz alle Elemente des laufenden Betriebs abdecken, während das organisatorische mehr an den Best Practices von ITIL orientiert und die Prozesse beschreibt, die von bestimmten Vorfällen ausgelöst werden.
Basis eines technischen Betriebskonzepts ist die Beschreibung der Umgebung, der Netzwerkarchitektur und der eingesetzten Systeme, mit denen die IT-Sicherheit gewährleistet werden soll. Dazu gehören nicht nur technische Daten, sondern beispielsweise auch Namenskonventionen, Zugriffsrechte und ähnliches. Neben diesem deskriptiven Aspekt muss das Betriebskonzept jedoch auch eine detaillierte Betrachtung der Operations, also des laufenden Betriebs beinhalten. Beispielsweise muss hier festgelegt werden, wie und durch wen die Systeme gewartet und welche Maßnahmen zur Überwachung und zum Monitoring implementiert werden. Auch das Change Management gehört zum Betriebskonzept – hier ist zu beschreiben, wie und von wem Änderungen an der Struktur oder an Systemen durchgeführt werden. Ein weiterer wichtiger Aspekt ist zudem die Frage, was passiert, wenn trotz aller Vorkehrungen ein Sicherheitsvorfall eingetreten ist (Incident Handling und Notfallmanagement). Und last but not least ist auch das Auditing des ISMS eine wesentliche Komponente des Betriebskonzepts.
Die Mitarbeiter nicht vergessen
Wenngleich in der Implementierungsphase die Definition und die Umsetzung des Betriebskonzeptes meist im Vordergrund stehen, darf, wie weiter oben schon erwähnt, eine Tatsache nicht vergessen werden: Sicherheit entsteht in den Köpfen. Deswegen muss die Implementierungsphase zwingend umfassende Maßnahmen zur Schulung aller betroffenen Mitarbeiter beinhalten. Denn was nutzen die besten Sicherheitseinrichtungen, wenn sie nicht richtig eingesetzt, gewartet und verwaltet werden? Neben die rein technische Schulung der mit dem Betrieb des ISMS befassten Mitarbeiter sollte zudem noch ein Awareness-Programm treten, mit dem alle Mitarbeiter im Unternehmen für die Bedrohungen sensibilisiert werden und in dem ihnen das ISMS in groben Zügen erläutert wird. Sicherheitsmaßnahmen gehen oft mit Einschränkungen einher, und die Mitarbeiter müssen verstehen und akzeptieren, dass diese Einschränkungen sinnvoll und erforderlich sind. Eine frühzeitige Einbindung des Betriebsrats in das IT-Sicherheitsteam wird sich in dieser Phase ebenso auszahlen wie eine aktive Rolle des Managements.
Sicherheits-Prozess
Mit der Implementierung des ISMS und der Aufnahme des laufenden Betriebs ist zwar ein wesentlicher Meilenstein erreicht, aber noch keine Sicherheit. Zwar darf man davon ausgehen, dass die bekannten Schwachstellen gesichert und die identifizierten Risiken abgedeckt sind, aber Sicherheit bleibt ein Prozess. Veränderungen in der Produktion können jederzeit neue Schwachstellen mit sich bringen; außerdem entstehen ständig neue Bedrohungspotenziale etwa durch neu entdeckte Bugs in Softwareprodukten. Zudem werden sich im laufenden Betrieb auch Schwächen zeigen, die sich bei der Definition oder der Implementierung des ISMS selbst eingeschlichen haben. Der Überwachung und dem Auditing, also dem „C“ im Plan-Do-Check-Act, kommt als Teil des laufenden Betriebs daher eine große Bedeutung zu. Allerdings müssen die dadurch gewonnenen Erkenntnisse auch wieder in Aktionen (Act) münden, mit denen das ISMS fortlaufend neuen Gegebenheiten angepasst und verbessert wird. Solche Veränderungen werden zunächst wieder geplant, womit sich der Kreis des PDCA-Modells schließt.
• more@click-Code: SIK09007
