Bereits Anfang Mai veröffentlichte der BDEW (Bundesverband der Energie- und Wasserwirtschaft) zusammen mit OE (Oesterreichs Energie) eine von Grund auf überarbeitete Version des Whitepapers zum Thema „Anforderungen an sichere Steuerungs- und Telekommunikationssysteme“ und die zugehörigen Ausführungshinweisen.
Welche Inhalte des neuen Whitepapers nun wirklich neu sind und welche lediglich umstrukturiert wurden, erfahren Sie als Energieversorger detailiert im Rahmen unserer mehrteiligen Beitragsserie.
Teil 1 – BDEW Sicherheitsanforderungen 2018: Was ist neu?
Sie erhalten einen ersten groben Überblick über strukturelle Veränderungen des BDEW/OE Whitepapers.
Teil 2 – BDEW Sicherheitsanforderungen 2018: Was ist neu?
Es geht tiefer ins Detail. Sie erfahren warum Sie die Vererbungslogik des Schutzbedarfs Ihrer Systeme, Verträge mit Auftragnehmern sowie den Einsatz Kryptographischer Verfahren prüfen sollten.
In Teil 2 analysiert xmera den Abschnitt ‚Allgemeine Anforderungen‘ des Kapitels Sicherheitsanforderungen. Themen wie Patch- und Updatemanagement, Kryptographische Verfahren und Cloud-Dienste stehen dabei im Mittelpunkt.
Sie erfahren in diesem Beitrag warum Sie die Vererbungslogik des Schutzbedarfs Ihrer Systeme, Verträge mit Auftragnehmern sowie den Einsatz Kryptographischer Verfahren prüfen sollten.
Bevor es mit der Analyse der Allgemeinen (Sicherheits-)Anforderungen weitergeht, blicken wir gemeinsam auf die Erkenntnisse aus dem ersten Teil der Serie zurück.
Der eilige Leser kann gerne direkt auf den Abschnitt seiner Wahl in diesem Beitrag springen.
Rückblick auf Teil 1
Das neue BDEW/OE Whitepaper „Anforderungen an sichere Steuerungs- und Telekommunikationssysteme“, Version 2.0 05/2018 fällt deutlich schlanker aus, als sein zweiteiliger Vorgänger, da aus den zwei Dokumenten ein kompaktes Dokument gemacht wurde.
Im Inhaltsverzeichnis wurde viel umbenannt und umstrukturiert. Die neue Struktur verbessert vor allem die Lesbarkeit. Lediglich die Themen „Nutzung von Cloud-Diensten“ und „Virtualisierungstechnologien“ sind neu aufgenommen worden.
Welche Neuerungen in den einzelnen Sicherheitsanforderungen und den zugehörigen Ergänzungen und Anmerkungen vorgenommen wurden, soll in diesem und den folgenden Teilen der Beitragsserie geklärt werden.
Textvergleich: Allgemeine Anforderungen
Bevor Sie sich den Vergleich des alten und neuen Kapitels ‚Allgemeine Anforderungen‘ anschauen, empfehle ich zunächst die Funktionsweise des Textvergleiches in Teil 1 der Beitragsserie nachzuvollziehen.
Analyse der Unterkapitel
Im Kapitel ‚Allgemeine Anforderungen‘ werden allgemeine und übergreifende Sicherheitsanforderungen, die für das Gesamtprojekt und alle Technologiebereiche anwendbar sind, definiert. Die Unterkapitel haben sich wie folgt verändert:
<>
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Sichere Systemarchitektur | Unverändert: Sichere Systemarchitektur |
| Gelöscht: Ansprechpartner | |
| Gelöscht: Patchfähigkeit | Hinzugefügt: Patchfähigkeit und Patch-Management |
| Gelöscht: Bereitstellung von | Hinzugefügt: Bereitstellung von Sicherheits-Patches für alle Systemkomponenten |
| Unverändert: Support für eingesetzte Systemkomponenten | Unverändert: Support für eingesetzte Systemkomponenten |
| Gelöscht: Verschlüsselung | Hinzugefügt: Verschlüsselung vertraulicher Daten |
| Gelöscht: Verschlüsselungsstandards | |
| Gelöscht: Interne/externe Sicherheits- und Anforderungstests und zugehörige Dokumentation | |
| Hinzugefügt: Kryptographische Verfahren | |
| Gelöscht: Sichere Standard-Konfiguration | Hinzugefügt: Sichere Standard-Konfiguration |
| Unverändert: Integritäts-Prüfung | Unverändert: Integritäts-Prüfung |
| Hinzugefügt: Nutzung von Cloud-Diensten | |
| Hinzugefügt: Anforderungen an die Dokumentation |
Im Wesentlichen handelt es sich bei den Änderungen der Themen um Umbenennungen.
Der Abschnitt ‚Ansprechpartner‘ wurde in ein anderes Hauptkapitel ausgelagert. Das Thema ‚Dokumentation‘ wurde neu in diesen Abschnitt integriert. In der alten Version ist dem Thema ‚Dokumentation‘ ein eigenes Hauptkapitel gewidmet.
Die wichtigste Neuerung ist der Abschnitt ‚Nutzung von Cloud-Diensten‘.
Wenn Sie keine Zeit finden, um regelmäßig hier im xmera blog vorbei zu schauen, dann melden sie sich für unserem kostenfreien Infoservice an!
<>Sichere Systemarchitektur - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 9.4.1, 13.1.3, 14.2.5, 14.2.7, 17.2.1 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.4.1, 13.1.3, 14.2.5, 14.2.7, 17.2.1 |
| Gelöscht: | Hinzugefügt: Die Einzelkomponenten und das Gesamtsystem müssen auf einen sicheren Betrieb hin entworfen und entwickelt werden. Zu den Prinzipien eines sicheren Systemdesigns gehören: |
| Hinzugefügt: Security-By-Design: Das Gesamtsystem und seine Einzelkomponenten sind von Grund auf im Hinblick auf Sicherheit entwickelt. Vorsätzliche Angriffe und unberechtigte Handlungen werden explizit betrachtet, die Auswirkungen von Sicherheitsvorfällen werden durch das Systemdesign minimiert. | |
| Gelöscht: Minimal-Need-To-Know-Prinzip: Jede Komponente und jeder Benutzer erhält nur die Rechte, die für die Ausführung einer Aktion | Hinzugefügt: Minimal-Need-To-Know-Prinzip: Jede Komponente und jeder Benutzer erhält nur die Rechte, die für die Ausführung einer Aktion notwendig sind. So werden z.B. Anwendungen und Netzwerk-Dienste nicht mit Administratorprivilegien, sondern nur mit den minimal nötigen Systemrechten betrieben. |
| Unverändert: Defence-In-Depth Prinzip: Sicherheitsrisiken werden nicht durch einzelne Schutzmaßnahmen angegangen, sondern durch die Implementierung gestaffelter, auf mehreren Ebenen ansetzender und sich ergänzender Sicherheitsmaßnahmen begrenzt. | Unverändert: Defence-In-Depth Prinzip: Sicherheitsrisiken werden nicht durch einzelne Schutzmaßnahmen angegangen, sondern durch die Implementierung gestaffelter, auf mehreren Ebenen ansetzender und sich ergänzender Sicherheitsmaßnahmen begrenzt. |
| Gelöscht: Redundanz-Prinzip: Das | Hinzugefügt: Redundanz-Prinzip: Das Gesamtsystem ist so ausgelegt, dass der Ausfall einzelner Komponenten die sicherheitsrelevanten Funktionen nicht beeinträchtigt. Das Systemdesign verringert die Wahrscheinlichkeit und die Auswirkungen von Problemen, die durch das uneingeschränkte Anfordern von Systemressourcen, wie z.B. Arbeitsspeicher oder Netzwerkbandbreite entstehen (sog. Resource-Consumptionoder DoS-Angriffe). |
<>Sichere Systemarchitektur - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Sicherheitsanforderung | Hinzugefügt: Sicherheitsanforderung 4.1.1 richtet sich in erster Linie an Systemdesigner und Entwickler und soll eine Leitlinie für das gesamte Systemdesign und den Entwicklungsprozess darstellen. |
| Gelöscht: Neben den genannten grundlegenden Sicherheitsprinzipien existieren weitere sinnvolle und ergänzende Designprinzipien, die ebenfalls berücksichtigt werden sollten, wie z.B. Access Control, Input | Hinzugefügt: Neben den genannten grundlegenden Sicherheitsprinzipien existieren weitere sinnvolle und ergänzende Designprinzipien, die ebenfalls berücksichtigt werden sollten, wie z.B. Access Control, Input Sanitization und -Validation, Default Deny etc. |
| Gelöscht: Das Redundanzprinzip ist als allgemeines Designprinzip in Ergänzung des Defence-in-Depth-Prinzips zu verstehen und besagt, dass es beim Ausfall einzelner Systemkomponenten oder Sicherheitsfunktionen nicht zu einem Totalausfall des Systems bzw. der Sicherheitsmechanismen kommen darf. In Hinblick auf Sicherheitsfunktionen ist hier insbesondere eine logische Redundanz im Sinne des Defence-in-Depth-Prinzips gemeint, | Hinzugefügt: Das Redundanzprinzip ist als allgemeines Designprinzip in Ergänzung des Defence-in-Depth-Prinzips zu verstehen und besagt, dass es beim Ausfall einzelner Systemkomponenten oder Sicherheitsfunktionen nicht zu einem Totalausfall des Systems bzw. der Sicherheitsmechanismen kommen darf. In Hinblick auf Sicherheitsfunktionen ist hier insbesondere eine logische Redundanz im Sinne des Defence-in-Depth-Prinzips gemeint, nach dem das Gesamtsystem über mehrere, gestaffelte Sicherheitsfunktionen verfügen muss. Hieraus ist aber nicht zwingend abzuleiten, dass alle Komponenten im Sinne einer Hardware-Redundanz doppelt ausgelegt werden müssen. |
| Gelöscht: Beispiele für | Hinzugefügt: Beispiele für Maßnahmen zur Realisierung des Redundanz- und Defence-in-Depth-Prinzips: |
| Hinzugefügt: - Implementierung von Laufzeitüberwachungs-Mechanismen, z.B. Watch-Dogs, Exception-Handling etc. | |
| Unverändert: - Echtzeit-Schadsoftwareschutz auf den Systemkomponenten bei gleichzeitiger Prüfung aller Datenschnittstellen und Blockierung der nicht benötigten Datenträgerschnittstellen wie USB-Ports und Wechseldatenträgern | Unverändert: - Echtzeit-Schadsoftwareschutz auf den Systemkomponenten bei gleichzeitiger Prüfung aller Datenschnittstellen und Blockierung der nicht benötigten Datenträgerschnittstellen wie USB-Ports und Wechseldatenträgern |
| Hinzugefügt: - Deaktivierung oder besser Deinstallation von nicht benötigten Diensten, wie z.B. DHCP | |
| Unverändert: - Konsistenzprüfung von Daten sowohl an der Außenschnittstelle einer Anwendung als auch bei der Übergabe zwischen den verschiedenen Systemmodulen innerhalb der Applikation | Unverändert: - Konsistenzprüfung von Daten sowohl an der Außenschnittstelle einer Anwendung als auch bei der Übergabe zwischen den verschiedenen Systemmodulen innerhalb der Applikation |
| Hinzugefügt: - Kommunikations-Gateways mit Prüffunktionen auf Applikations-Ebene, z.B. zur Filterung nach erlaubten bzw. nicht freigegebenen Telegrammtypen | |
| Gelöscht: - Redundante Übertragungswege | Hinzugefügt: - Redundante Übertragungswege und Vermeidung von Verbindungen über das öffentliche Internet |
| Unverändert: - Überprüfung der Quelladressen (IP-Adressen) von Fernwirktelegrammen nicht nur an der Außenschnittstelle (Firewall) der Station,sondern auch durch die Zielkomponente | Unverändert: - Überprüfung der Quelladressen (IP-Adressen) von Fernwirktelegrammen nicht nur an der Außenschnittstelle (Firewall) der Station,sondern auch durch die Zielkomponente |
| Unverändert: - Fehlertolerante und unabhängige Implementierung von kritischen Funktionen der Anlagensicherheit | Unverändert: - Fehlertolerante und unabhängige Implementierung von kritischen Funktionen der Anlagensicherheit |
| Gelöscht: Die Umsetzung der sicheren Systemarchitektur sollte in der | Hinzugefügt: Die Umsetzung der sicheren Systemarchitektur sollte in der Systemdokumentation beschrieben werden. |
Sichere Systemarchitektur – Haupttechnologiebereiche
-keine Veränderungen-
<>Patchfähigkeit und Patch-Management - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.6.1 |
| Gelöscht: Alle | Hinzugefügt: Alle Systemkomponenten müssen patchfähig sein. |
| Gelöscht: Das Einspielen eines Patches sollte möglichst ohne Unterbrechung des normalen Betriebs und mit geringen Auswirkungen auf die Verfügbarkeit des Gesamtsystems erfolgen. Beispielsweise ist eine primärtechnische Außerbetriebnahme der kompletten Anlage zum Patchen der sekundärtechnischen Komponenten zu vermeiden. Bevorzugt werden die Patches zuerst auf den passiven Redundanz-Komponenten eingespielt und nach einem Switch-Over-Prozess (Wechsel der aktiven Komponente im Redundanzsystem) und einem darauffolgendem Test auf den restlichen Komponenten installiert. | |
| Hinzugefügt: Der Auftragnehmer muss einen Patch-Managementprozess für die Einzelkomponenten und das Gesamtsystem unterstützen, anhand dessen das Testen, Installieren und Dokumentieren von Sicherheits-Patches und Updates gesteuert und verwaltet werden kann. | |
| Gelöscht: Der Hersteller muss einen Patchmanagementprozess für das gesamte System unterstützen, anhand dessen das Testen, Installieren und Dokumentieren von Sicherheitspatches und Updates gesteuert und verwaltet werden kann. Die Updates sollen vom Betriebspersonal, das diese Systeme administriert, eingespielt werden. Das Installieren bzw. Deinstallieren von Patches muss vom Anlagenbetreiber autorisiert werden und darf nicht automatisch geschehen. | Hinzugefügt: Sicherheits-Patches und Updates müssen durch den Betreiber selbst bzw. durch vom ihm beauftragte Dienstleister installiert werden können. Das Installieren bzw. Deinstallieren von Patches muss vom Betreiber autorisiert werden und darf nicht automatisch geschehen. Die Installation bzw. Deinstallation ist im System nachvollziehbar und manipulationsgeschützt zu protokollieren. |
| Hinzugefügt: Die Integrität von Sicherheits-Patches und Updates muss durch einen kryptographischen Mechanismus prüfbar sein. |
<>Patchfähigkeit und Patch-Management - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Unter Patchen wird das Implementieren von sicherheitsrelevanten und funktionalen | Hinzugefügt: Unter Patchen wird das Implementieren von sicherheitsrelevanten und funktionalen Softwareupdates verstanden. Dies umfasst sowohl die reine Fehlerbeseitigung als auch die Erweiterung, Ergänzung und Optimierung von Funktionalitäten und betrifft sowohl die Anwendungsebene als auch alle unterlagerten Systemkomponenten (z.B. Basis und Betriebssysteme, Datenbanken, Programmbibliotheken und Komponenten von Drittherstellern, Firmware, BIOS und Management-Schnittstellen usw.). |
| Gelöscht: Die Vorgehensweise zur Installation von | Hinzugefügt: Die Vorgehensweise zur Installation von Sicherheits-Patches sowie für Deinstallation und Rollback sollte für alle Systemkomponenten detailliert dokumentiert werden. Werden keine Komplettsysteme geliefert, sollten vom Auftragnehmer die notwendigen Prozesse und Voraussetzungen zur Installation von Sicherheits-Patches und sonstigen Updates für die im System genutzten Drittkomponenten genannt werden. |
| Hinzugefügt: Das Einspielen eines Patches sollte möglichst ohne Unterbrechung des normalen Betriebs und mit geringen Auswirkungen auf die Verfügbarkeit des Gesamtsystems erfolgen. Beispielsweise ist eine primärtechnische Außerbetriebnahme der kompletten Anlage zum Patchen der sekundärtechnischen Komponenten zu vermeiden. Bevorzugt werden die Patches zuerst auf den inaktiven Redundanz-Komponenten eingespielt und nach einem Switch-Over-Prozess (Wechsel der aktiven Komponente im Redundanzsystem) und einem darauffolgendem Basis-Funktionstest bzw. Probelauf auf den restlichen Komponenten installiert. Insbesondere übergeordnete Systeme ohne direkte Prozess-Anbindung sollten dabei so ausgeführt werden, dass eine Außerbetriebnahme der Anlage zur Patch-Installation i.d.R. nicht notwendig ist. | |
| Gelöscht: Das | Hinzugefügt: Das Gesamtsystem sollte so aufgebaut sein, dass die Anzahl der notwendigen Sicherheits-Patches bzw. der zu patchenden Komponenten sowie ggf. notwendiger Betriebsunterbrechungen auf ein Minimum reduziert werden kann. Eine umfassende Härtung kann hierbei unterstützend wirken (vgl. 4.3.1). |
| Gelöscht: Grundsätzlich ist anzustreben, sämtliche Systeme und Komponenten patchfähig auszuführen. Insbesondere übergeordnete Systeme ohne direkte Prozess-Anbindung sollten dabei so aus geführt werden, dass eine (primärtechnische) Außerbetriebnahme der Anlage zur Installation i.d.R. nicht notwendig ist. | |
| Gelöscht: Erfordert das | Hinzugefügt: Erfordert das Gesamtsystem bzw. seine Komponenten nach einem Update die Durchführung von Funktionstests, sollten diese nach Möglichkeit automatisiert werden und die hierfür notwendigen Mechanismen im System vorgesehen sein. Der Auftragnehmer sollte die notwendigen Testfälle und die bei einem erfolgreichen Testdurchlauf zu erwartenden Ergebnisse dokumentieren (Testbuch). |
| Hinzugefügt: Zur Durchführung von Funktionstests kann in Abhängigkeit von der Kritikalität der Systeme ein kundenspezifisches Testsystem beim Auftragnehmer und ggf. ein zusätzliches Testsystem beim Kunden notwendig sein. | |
| Unverändert: Fallback- bzw. Rollbackfunktionen für den Fall von fehlerhaften Patches oder bei fehlgeschlagenen Tests sollten so konzipiert sein, dass eine rasche und möglichst einfache Rückkehr auf den letzten funktionsfähigen Versions- und Konfigurationsstand möglich ist. | Unverändert: Fallback- bzw. Rollbackfunktionen für den Fall von fehlerhaften Patches oder bei fehlgeschlagenen Tests sollten so konzipiert sein, dass eine rasche und möglichst einfache Rückkehr auf den letzten funktionsfähigen Versions- und Konfigurationsstand möglich ist. |
| Gelöscht: Im Patchmanagement sind auch die Parametrier- und Managementsysteme zu berücksichtigen. | |
| Gelöscht: Die Patches sollten durch den Hersteller eindeutig versioniert werden und mit Integritätsprüfungsmechanismen versehen sein. | Hinzugefügt: Im Patch-Management sind auch Embedded-Komponenten, Parametrier- und Managementsysteme sowie Management-Schnittstellen zu berücksichtigen. |
| Hinzugefügt: Die Patches sollten durch den Auftragnehmer eindeutig versioniert werden. Sollten Patches bestimmte Firmware-Stände erfordern, ist dies gesondert zu überprüfen und sicherzustellen. | |
| Hinzugefügt: Die im Rahmen des Patch-Managements durchgeführten Prozesse sollten sich an anerkannten Betriebs- und Servicemanagement-Standards orientieren (z.B. COBIT, ITIL etc.). | |
| Hinzugefügt: In der Regel sind für das Patch-Management Administrationswerkzeuge und Systeme zum System- und Versionsmanagement notwendig (z.B. zentrale Update-Server, Versionierungs- und Konfigurationsmanagement-Datenbanken etc.). Hierfür sollte eine von der Büro-IT getrennte Infrastruktur betrieben werden. | |
| Gelöscht: Vergleiche auch | Hinzugefügt: Vergleiche auch 4.7.2. |
<>Patchfähigkeit und Patch-Management - Haupttechnologiebereiche
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Betriebsführungs-/ Leitsysteme und Systembetrieb: | Unverändert: Betriebsführungs-/ Leitsysteme und Systembetrieb: |
| Gelöscht: Grundsätzlich sollten sämtliche Systeme patchfähig ausgeführt sein. | |
| Unverändert: Wo möglich sollten zur Sicherstellung eines kontinuierlichen Betriebs Redundanzkomponenten genutzt werden. | Unverändert: Wo möglich sollten zur Sicherstellung eines kontinuierlichen Betriebs Redundanzkomponenten genutzt werden. |
| Unverändert: Übertragungstechnik / Sprachkommunikation: | Unverändert: Übertragungstechnik / Sprachkommunikation: |
| Gelöscht: Berücksichtigt werden sollten sowohl Netzwerkkomponenten und Netzelemente, Endgeräte und zentrale | Hinzugefügt: Berücksichtigt werden sollten sowohl Netzwerkkomponenten und Netzelemente, Endgeräte und zentrale Kommunikations-, Management und Überwachungssysteme. |
| Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: | Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: |
| Gelöscht: Übergeordnete Systeme ohne direkte Prozess-Anbindung sollten so ausgeführt werden, dass im Regelfall eine primärtechnische Außerbetriebnahme der Station bzw. Anlage zur Patchinstallation nicht notwendig ist. | |
| Gelöscht: Die Installation von Sicherheits- und | Hinzugefügt: Die Installation von Sicherheits- und Firmware-Updates in prozessnahen Komponenten (z.B. Steuerungen, SPSen, Feldeinheiten, Schutzgeräten) ist unter Umständen nur während einer Anlagenaußerbetriebnahme, wie z.B. während einer Revision, möglich. Diese Komponenten sollten möglichst so ausgeführt sein, dass dann ein Patchen vor Ort und ohne Ausbau der Komponenten durchführbar ist und nur einen möglichst geringen Prüfaufwand erfordert. |
| Gelöscht: Falls für die prozessnahen Komponenten stark erhöhte Verfügbarkeitsanforderungen bestehen und eine Außerbetriebnahme für | Hinzugefügt: Falls für die prozessnahen Komponenten stark erhöhte Verfügbarkeitsanforderungen bestehen und eine Außerbetriebnahme für Soft-/Firmware-Änderungen nicht möglich ist, sollte für diese Komponenten die Notwendigkeit der Implementierung einer Patchfähigkeit im laufenden Betrieb geprüft werden. In der Regel wird dies eine redundante Ausführung der betroffenen Komponenten erfordern. |
| Gelöscht: Organisatorische Anmerkungen: | |
| Gelöscht: Die im Rahmen des Patchmanagements durchgeführten Prozesse sollten sich an anerkannten Betriebs- und Servicemanagement-Standards orientieren (z.B. COBIT, ITIL etc.) In der Regel sind für das Patchmanagement Administrationswerkzeuge und Systeme zum System- und Versionsmanagement notwendig (z.B. zentrale Updateserver, Versionierungs- und Konfigurationsmanagement-Datenbanken etc.). |
<>Bereitstellung von Sicherheits-Patches für alle Systemkomponenten - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013 12.6.1 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.5.1, 12.6.1 |
| Gelöscht: Der Auftragnehmer muss Sicherheitsupdates für alle Systemkomponenten während des gesamten | Hinzugefügt: Der Auftragnehmer muss gewährleisten, dass Sicherheitsupdates für alle Systemkomponenten während des gesamten, vertraglich geregelten Betriebszeitraums zur Verfügung stehen. Updates von Basiskomponenten, die nicht vom Auftragnehmer entwickelt wurden, wie z.B. Betriebssystem, Bibliotheken oder Datenbank- Managementsystem, muss der Auftragnehmer von den jeweiligen Herstellern beziehen, diese testen und sie gegebenenfalls an den Auftraggeber weiterleiten. Test, Freigabe und Bereitstellung der Updates müssen innerhalb eines angemessenen, vertraglich geregelten Zeitrahmens erfolgen. |
<>Bereitstellung von Sicherheits-Patches für alle Systemkomponenten - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Hinzugefügt: Der Bereitstellungsprozess sollte alle zum Lieferumfang gehörenden Software- und Systemkomponenten umfassen, z.B. Basis- und Betriebssysteme, Datenbanken, Programmbibliotheken und Komponenten von Drittherstellern, Firmware, BIOS und Management-Schnittstellen usw. | |
| Hinzugefügt: Die Installation von Sicherheits-Patches und Updates erfordert i.d.R. eine individuelle Prüfung und Freigabe der einzelnen Patches und Updates durch den Auftragnehmer. Hierfür kann in Abhängigkeit von der Kritikalität der Systeme ein kundenspezifisches Testsystem beim Lieferanten und ggf. ein zusätzliches Testsystem beim Kunden notwendig sein. Für weniger kritische Anwendungen ist ggf. eine generische Freigabe bestimmter Patch- und Updatekategorien durch den Auftragnehmer möglich. | |
| Hinzugefügt: Ist eine Prüfung und Freigabe notwendig, sollte sich der Auftragnehmer für alle genutzten Komponenten und Softwareprodukten Dritter selbsttätig über vorliegende Sicherheitsupdates informieren und eine komponenten- bzw. anlagenspezifische Relevanzbewertung vornehmen. Die Bewertung und die Ergebnisse der Freigabetests sollten durch den Auftragnehmer dokumentiert und dem Auftraggeber zur Verfügung gestellt werden. Informationen über zu installierende Updates sollten dem Auftraggeber regelmäßig und zeitnah zur Verfügung gestellt werden. Für die Freigabeprozesse sollten die folgenden Aspekte beachtet werden: | |
| Hinzugefügt: - Der Auftragnehmer sollte alle relevanten Sicherheits-Patches beziehen und den notwendigen Freigabe- und Qualifizierungstests unterziehen. | |
| Hinzugefügt: - Informationen über freigegebene Sicherheits-Patches sollten dem Auftraggeber zeitnah nach deren Veröffentlichung zur Verfügung gestellt werden, z.B. per E-Mail, über eine Webseite oder ein Supportforum. | |
| Hinzugefügt: - Eine Information über kritische Sicherheitslücken sollte in der Regel unverzüglich erfolgen. | |
| Hinzugefügt: - Wenn ein Sicherheits-Patch im gegebenen Systemumfeld als nicht relevant eingestuft wird, sollte dies dokumentiert und dem Auftraggeber mitgeteilt werden. | |
| Hinzugefügt: - Wird für einen Sicherheits-Patch keine Freigabe durch den Auftragnehmer oder Auftraggeber erteilt, sollten Alternativmaßnahmen entwickelt werden. | |
| Hinzugefügt: - Es sollte explizit dokumentiert werden, ob zur Anwendung eines Patches eine Betriebsunterbrechung notwendig ist, beispielsweise auf Grund von Neustarts von Diensten oder Komponenten. | |
| Hinzugefügt: - Zu jedem Patch sollte dokumentiert sein, welche Sicherheitslücken adressiert und welche Änderungen vorgenommen werden. | |
| Hinzugefügt: Es sollte sichergestellt sein, dass in zyklischen Abständen alle verfügbaren relevanten und freigegebenen Sicherheitsupdates und sicherheitsrelevanten Service-Packs installiert werden, um die Abweichung vom aktuell unterstützten Release-Stand möglichst gering zu halten. | |
| Hinzugefügt: Für viele Leittechniktypen und Anwendungsszenarien ist für das Gesamtsystem oder einzelne Teilkomponenten (z.B. Sekundär-/ Automatisierungstechnikkomponenten oder Fernwirktechnik) von einem längerfristigen Betriebszeitraum auszugehen, der den Lebenszyklus von einzelnen Softwareprodukten i.d.R. weit übertrifft. Für Systemkomponenten, für die der angestrebte Betriebszeitraum des Gesamtsystems absehbar nicht erreichbar ist (z.B. typische PC-basierte Komponenten), sollte durch ein entsprechendes Systemdesign eine leichte Austauschbarkeit vorgesehen werden und ein Migrationskonzept grob skizziert und vertraglich festgeschrieben werden. | |
| Gelöscht: Die Installation von Sicherheitspatches und Updates erfordert i.d.R. eine individuelle Prüfung und Freigabe der einzelnen Patches und Updates durch den Systemhersteller. Für weniger kritische Anwendungen ist ggf. eine generische Freigabe bestimmter Patch- und Updatekategorien durch den Systemhersteller möglich. | Hinzugefügt: Verbindliche Vereinbarungen zu Vorgehensweisen wie Überprüfung, Bereitstellung und Freigabe der Patches und Updates sowie zu Zeitrahmen und Fristen sollten vertraglich, z.B. im Rahmen eines Wartungsvertrags, berücksichtigt werden. Wo möglich, sollten hier auch schon absehbare Migrationsszenarien behandelt werden. |
| Gelöscht: Ist eine Prüfung und Freigabe notwendig, sollte sich der Auftragnehmer für alle im System genutzten Komponenten und Softwareprodukten Dritter selbsttätig über vorliegende Sicherheitsupdates informieren und eine komponenten- bzw. anlagenspezifische Relevanzbewertung vornehmen. Informationen über zu installierende Updates sollten dem Auftraggeber regelmäßig und zeitnah zur Verfügung gestellt werden. Für die Freigabeprozesse sollten die folgenden Aspekte beachtet werden: | |
| Gelöscht: - Der Auftragnehmer sollte alle relevanten | |
| Gelöscht: - Informationen über freigegebene | |
| Gelöscht: - Wenn ein | |
| Gelöscht: - Wird für einen | |
| Gelöscht: - Es sollte explizit dokumentiert werden, ob zur Anwendung eines Patches eine Betriebsunterbrechung notwendig ist, beispielsweise | |
| Gelöscht: Für viele Leittechniktypen und Anwendungsszenarien ist für das Gesamtsystem oder einzelne Teilkomponenten (z.B. Sekundär-/ Automatisierungstechnikkomponenten oder Fernwirktechnik) von einem längerfristigen Betriebszeitraum auszugehen, der den Lebenszyklus von einzelnen Softwareprodukten i.d.R. weit übertrifft. Für |
Bereitstellung von Sicherheits-Patches für alle Systemkomponenten – Haupttechnologiebereiche
-keine Veränderungen-
<>Support für eingesetzte Systemkomponenten - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 12.6.1, 14.2.7 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.6.1, 14.2.7 |
| Gelöscht: Der Auftragnehmer muss sicherstellen, dass für | Hinzugefügt: Der Auftragnehmer muss sicherstellen, dass sowohl für von ihm eigenentwickelte als auch für fremdentwickelte Systemkomponenten (z.B. Betriebssystem, Datenbank-Managementsystem, etc.) innerhalb des geplanten und vertraglich festgeschriebenen Betriebszeitraums Herstellersupport und Sicherheitsupdates zur Verfügung stehen. Das Abkündigungsverfahren und alle relevanten Mindestlaufzeiten wie z.B. Last-Customer-Shipping und End-Of-Support müssen verbindlich festgeschrieben werden. |
<>Support für eingesetzte Systemkomponenten - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Betriebszeiträume, die den Lebenszyklus von System- oder Softwarekomponenten überschreiten, erhöhen das sicherheitstechnische Risiko und sollten daher unbedingt vermieden werden. Die | Hinzugefügt: Betriebszeiträume, die den Lebenszyklus von System- oder Softwarekomponenten überschreiten, erhöhen das sicherheitstechnische Risiko und sollten daher unbedingt vermieden werden. Die Auftragnehmer sollten den entsprechenden Support sowohl für selbst entwickelte als auch für 3rd-Party-Produkte bieten und bei Produkten mit langen Lebenszyklen bei Vertragsabschluss Migrationskonzepte vorweisen können. Es sollten zunächst nur Drittkomponenten (z.B. Betriebssystem, Protokoll-Stacks, etc.) genutzt werden, die aktuell und während der geplanten Laufzeit noch unterstützt werden. Auf Grund der üblicherweise langfristigen Betriebszeiträume in den betrachteten Bereichen kann der Auftragnehmer dies allerdings häufig nicht garantieren. Deshalb sollten hier dann Grobkonzepte und Kostenschätzungen für eine Migration auf neuere Versionen vorgelegt werden. |
| Gelöscht: | Hinzugefügt: Es sollte zusätzlich gefordert werden, dass bei Inbetriebnahme möglichst die zu diesem Zeitpunkt aktuellen System- und Komponentenversionen eingesetzt werden, falls dem keine technischen Gründe entgegenstehen. |
| Gelöscht: Die angestrebten | Hinzugefügt: Die angestrebten Betriebs- und Supportzeiträume einzelner Komponenten sollten vom Auftraggeber vorab definiert werden. |
| Gelöscht: Der | Hinzugefügt: Der Auftragnehmer sollte im Rahmen der Projektdokumentation die System- und Komponentenversionen und die zugehörigen Supportzeiträume dokumentieren. |
| Hinzugefügt: Die entsprechenden Anforderungen sind durch Auftraggeber und Auftragnehmer bereits bei Vertragsabschluss zu berücksichtigen. | |
| Hinzugefügt: Eine besondere Herausforderung stellen die stark unterschiedlichen Lebenszeiten der genutzten Drittsoftwarekomponenten und des gewünschten Lebenszyklus eines Systems dar. Für die Migration der Systeme sollte ein Konzept erstellt werden. | |
| Hinzugefügt: Falls der Auftraggeber in Ausschreibungen oder Projekten den Einsatz konkreter Produkte bzw. Versionen vorschreibt, ist die Umsetzung dieser Anforderung auf Auftraggeberseite entsprechend zu berücksichtigen. |
Support für eingesetzte Systemkomponenten – Haupttechnologiebereiche
-keine Veränderungen-
<>Verschlüsselung vertraulicher Daten - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 12.4.2, 13.1.2, 18.1.3, 18.1.4 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 10.1.1, 12.4.2, 13.1.2, 18.1.3, 18.1.4 |
| Gelöscht: Sensible Daten dürfen im System nur verschlüsselt gespeichert bzw. übertragen werden. Zu den zu schützenden Daten können beispielsweise Protokolldateien, Passwörter oder vertrauliche Daten nach behördlichen Vorgaben oder den relevanten Gesetzen, wie z.B. dem Bundesdatenschutzgesetz gehören. Gegebenenfalls soll das System auch die sichere, selektive Löschung bestimmter Daten ermöglichen, beispielsweise durch Überschreiben mit Zufallsdaten. | Hinzugefügt: Vertrauliche Daten dürfen nur verschlüsselt gespeichert bzw. übertragen werden. |
<>Verschlüsselung vertraulicher Daten - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Hinzugefügt: Beim Schutz vertraulicher Daten sollten sowohl Informationssicherheitsaspekte als auch Datenschutzanforderungen berücksichtigt werden. Eine Auflistung der vom System standardmäßig verarbeiteten Informationen sollte vom Auftragnehmer vorgelegt werden. Welche Daten als vertraulich anzusehen sind, ist durch den Auftraggeber festzulegen. | |
| Hinzugefügt: Dort, wo der Schutzbedarf offensichtlich ist (z.B. bei Authentisierungsinformationen wie Passwörtern), sollten entsprechende Maßnahmen durch den Auftragnehmer bereits in der Standardkonfiguration umgesetzt sein. | |
| Gelöscht: Beim Schutz sensibler Daten sollten sowohl Informationssicherheitsaspekte als auch Datenschutzanforderungen berücksichtigt werden. Welche Daten als sensibel anzusehen sind, sollte primär vom Auftraggeber festgelegt werden, da dies vom Einsatzgebiet, internen Richtlinien und der nationalen Gesetzgebung abhängt. Dort wo der Schutzbedarf offensichtlich ist (z.B. bei Authentisierungsinformationen wie Passwörtern), sollten entsprechenden Maßnahmen durch den Hersteller bereits in der Standardkonfiguration umgesetzt sein. | Hinzugefügt: Zu den zu schützenden Daten können beispielsweise Protokolldateien, Passwörter, Parametrierdaten oder vertrauliche Daten nach behördlichen Vorgaben oder den relevanten Gesetzen, wie z.B. dem Bundesdatenschutzgesetz oder Datenschutzgrundverordnung, gehören. Gegebenenfalls sollte das System auch die sichere, selektive Löschung bestimmter Daten, beispielsweise durch Überschreiben mit Zufallsdaten und die Anonymisierung bestimmter Daten, ermöglichen. |
| Gelöscht: Zu den sensiblen Daten der einzelnen Systembereiche können wie im BDEW-Whitepaper bereits aufgeführt Passwörter und Betriebsprotokolle, aber ggf. auch Parametrierdaten gehören. |
Verschlüsselung vertraulicher Daten -Haupttechnologiebereiche
-keine Veränderungen-
<>Kryptographische Verfahren - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 10.1.1, 10.1.2, | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 10.1.1, 10.1.2, 13.1.4 ENR, 18.1.5 |
| Gelöscht: Bei der Auswahl von | Hinzugefügt: Bei der Auswahl von kryptographischen Verfahren sind nationale Gesetzgebungen zu berücksichtigen. Es dürfen nur anerkannte Verfahren und Schlüsselmindestlängen benutzt werden, die nach aktuellem Stand der Technik auch in Zukunft als sicher gelten. Die Nutzung von selbstentwickelten kryptographischen Algorithmen ist nicht erlaubt |
<>Kryptographische Verfahren - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Als Stand der Technik | Hinzugefügt: Als Stand der Technik von Verfahren für Hashbildung, Signaturen und Verschlüsselung und die zugehörigen Schlüssellängen werden insbesondere die folgenden Verordnungen und Empfehlungen angesehen: |
| Hinzugefügt: - „BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen“ (Bundesamt für Sicherheit in der Informationstechnik, Deutschland) | |
| Gelöscht: - „Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung – Übersicht über geeignete Algorithmen“ (Bundesnetzagentur, Deutschland) | Hinzugefügt: - „Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung – Übersicht über geeignete Algorithmen“ (Bundesnetzagentur, Deutschland). |
| Gelöscht: - „Verordnung des Bundeskanzlers über elektronische Signaturen (Signaturverordnung 2008 – SigV 2008)“, Anhang Algorithmen und Parameter für qualifizierte elektronische Signaturen (Bundeskanzleramt Österreich) | |
| Gelöscht: - Special Publication 800-57 “Recommendation for Key Management“ (National Institute of Standards and Technology, USA) | |
| Gelöscht: Hiervon abweichende Verfahren oder Schlüssellängen sollten nur nach expliziter Freigabe durch den Auftraggeber eingesetzt werden. | |
| Hinzugefügt: Hiervon abweichende Verfahren oder Schlüssellängen sollten nur nach expliziter Freigabe durch den Auftraggeber eingesetzt werden. Insbesondere im Embedded-Bereich müssen bei der Spezifikation von Algorithmen und Schlüssellängen allerdings die teilweise beschränkten Ressourcen der Komponenten berücksichtigt werden. | |
| Hinzugefügt: Die Normenreihe IEC 62351 definiert für ihre Anwendungsbereich Mindestanforderungen an die zu unterstützenden kryptographischen Verfahren. Bei der Auswahl der im Projekt aktivierten und genutzten Verfahren sollte diese zusammen mit den o.g. BSI- und BNetzA-Empfehlungen berücksichtigt werden. | |
| Hinzugefügt: Das gewählte kryptographische Verfahren sollte, wo technisch möglich, durch ein neueres Verfahren im Rahmen eines Updates austauschbar sein bzw. veraltete Verfahren deaktiviert oder deinstalliert werden können. | |
| Hinzugefügt: Bei der Implementierung der kryptographischen Verfahren sollte, wo möglich, auf anerkannte Bibliotheken zurückgegriffen werden, um Implementierungsfehler zu vermeiden. Für Schlüsselverwaltung, Erzeugung von Zufallszahlen etc. kann der Einsatz von kryptographischen Hardware-Modulen wie eines Trusted Platform Module (TPM) sinnvoll sein. |
<>Kryptische Verfahren - Haupttechnologiebereiche
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Betriebsführungs-/Leitsysteme und Systembetrieb: - | Unverändert: Betriebsführungs-/Leitsysteme und Systembetrieb: - |
| Unverändert: Übertragungstechnik/Sprachkommunikation: - | Unverändert: Übertragungstechnik/Sprachkommunikation: - |
| Gelöscht: Sekundär-, Automatisierungs- und Fernwirktechnik: Insbesondere im Embbeded-Bereich müssen bei der Spezifikation von Algorithmen und Schlüssellängen die teilweise beschränkten Ressourcen der Komponenten berücksichtigt werden. | Hinzugefügt: Sekundär-, Automatisierungs- und Fernwirktechnik: - |
<>Sichere Standard-Konfiguration - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 9.4.4, 12.5.1, 14.3. | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.4.4, 12.5.1, 14.3.1 |
| Gelöscht: Das | Hinzugefügt: Das Gesamtsystem muss nach der Erstinstallation bzw. bei der (Wieder-) Inbetriebnahme in einem betriebssicheren Zustand konfiguriert sein, wobei diese definierte Grundkonfiguration dokumentiert sein muss. Dienste, Services und Funktionen sowie Daten, die nur zur Entwicklung oder zum Testbetrieb notwendig sind, müssen vor der Auslieferung bzw. vor dem Übergang in den Produktivbetrieb nachweisbar entfernt bzw. dauerhaft deaktiviert werden. |
Sichere Standard-Konfiguration – Ergänzungen und Anmerkungen
-keine Veränderungen-
Sichere Standard-Konfiguration – Haupttechnologiebereiche
-keine Veränderungen-
<>
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 12.5.1, 14.2.1, 14.2.4 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.5.1, 14.2.1, 14.2.4 |
| Gelöscht: Systemdateien, Anwendungen, Konfigurationsdateien und Anwendungs-Parameter müssen auf Integrität überprüft werden können, beispielsweise durch Prüfsummen. | Hinzugefügt: Systemdateien, Anwendungen, Konfigurationsdateien und Anwendungs-Parameter müssen auf Integrität überprüft werden können, beispielsweise durch kryptographische Prüfsummen. |
<>Integritäts-Prüfung - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Neben den Systemdateien des Betriebssystems sollten insbesondere Konfigurationsdaten, Anwendungsparameter sowie | Hinzugefügt: Neben den Systemdateien des Betriebssystems sollten insbesondere Konfigurationsdaten, Anwendungsparameter sowie Firmware-Parameter und Firmware-Versionen sicher auf Integrität geprüft werden können. Um gezielte Manipulationen verhindern bzw. erkennen zu können, sind hierzu i.d.R. kryptographisch berechnete Prüfsummen notwendig. |
| Gelöscht: Nach Möglichkeit sollten die Prüfungen für Patches und Updates die gleichen Mechanismen nutzen (vgl. | Hinzugefügt: Nach Möglichkeit sollten die Prüfungen für Patches und Updates die gleichen Mechanismen nutzen (vgl. 4.1.2). |
| Unverändert: Die Möglichkeit zur Integritätsprüfung auf der Ebene übergeordneter Systeme sollte eine Mindestanforderung sein. Mittelfristig sollte die Möglichkeit zur Integritätsprüfung auf allen Komponenten angestrebt werden. | Unverändert: Die Möglichkeit zur Integritätsprüfung auf der Ebene übergeordneter Systeme sollte eine Mindestanforderung sein. Mittelfristig sollte die Möglichkeit zur Integritätsprüfung auf allen Komponenten angestrebt werden. |
| Hinzugefügt: Die Integritätsprüfungen sollten insbesondere auch im Rahmen der Change-Management-Prozesse berücksichtigt werden. |
<>Integritäts-Prüfung - Haupttechnologiebereiche
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Betriebsführungs-/Leitsysteme und Systembetrieb: - | Unverändert: Betriebsführungs-/Leitsysteme und Systembetrieb: - |
| Unverändert: Übertragungstechnik/Sprachkommunikation: - | Unverändert: Übertragungstechnik/Sprachkommunikation: - |
| Gelöscht: Sekundär-, Automatisierungs- und Fernwirktechnik: Bei prozessnahen Komponenten sollte eine Integritätsprüfung mindestens im Konfigurationstool für Parametrierstände und | Hinzugefügt: Sekundär-, Automatisierungs- und Fernwirktechnik: Bei prozessnahen Komponenten sollte eine Integritätsprüfung mindestens im Konfigurationstool für Parametrierstände und Firmware-Versionen vorhanden sein. |
| Unverändert: Eine detaillierte Vergleichbarkeit von Parametrierständen insbesondere von Offline- und Onlineversionen und archivierten Parametrierungen ist anzustreben. | Unverändert: Eine detaillierte Vergleichbarkeit von Parametrierständen insbesondere von Offline- und Onlineversionen und archivierten Parametrierungen ist anzustreben. |
<>Nutzung von Cloud-Diensten - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: - | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 15.1.1, 15.1.2, 15.2.1 |
| Hinzugefügt: Bei der Nutzung von Cloud-Diensten sind die folgende Anforderungen zu berücksichtigen: | |
| Hinzugefügt: a) Mit dem Cloud-Dienstleister müssen Vereinbarungen getroffen werden, welche sicherheitsrelevante Prozesse für den Betrieb der Cloud-Infrastruktur regeln. | |
| Hinzugefügt: b) Funktionen zur Steuerung kritischer Infrastrukturen, deren Manipulation/ Veränderung die Energieversorgung gefährden kann, dürfen nicht in externen Cloud-Diensten realisiert werden. | |
| Hinzugefügt: c) Der Ausfall eines Cloud-Dienstes bzw. des Zugriffs auf diesen Dienst darf zu keinen wesentlichen Einschränkungen der definierten Grundfunktion des Systems führen. Störungen und Ausfälle des Cloud-Dienstes müssen auch in der Notfallkonzeption und Wiederanlaufplanung berücksichtigt werden (siehe 4.8.2). |
<>Nutzung von Cloud-Diensten - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Hinzugefügt: Cloud-Dienste im hier verwendeten Sinn umfassen die dynamische Nutzung von geteilten IT-Ressourcen und IT-Dienstleistungen wie Infrastruktur (z.B. Rechenleistung, Speicherplatz), Plattformen (z.B. Applikationsserver, Datenbanken), Software und Anwendungen über ein Netzwerk. | |
| Hinzugefügt: Die Nutzung von Cloud-Diensten im Bereich der Prozesssteuerung in der Energieversorgung ist nicht grundsätzlich abzulehnen, muss aber im Rahmen einer Risikobewertung kritisch hinterfragt werden. Dies gilt insbesondere bei der Nutzung von öffentlichen Cloud-Diensten (Public Cloud). Zur Risikobewertung sollte eine Cloud-Referenzarchitektur herangezogen werden, um sicherstellen zu können, dass alle relevanten Aspekte der Cloud-Nutzung und deren Risiken berücksichtigt werden. | |
| Hinzugefügt: Bei der Nutzung von Cloud-Diensten gibt der Eigentümer der Daten die eigentliche Datenhoheit an den Cloud-Dienstleister ab. Er muss sich in Bezug auf Verfügbarkeit, Integrität und Vertraulichkeit auf die sichere Umsetzung des Dienstes verlassen können. Bei einer Verarbeitung oder Speicherung von Daten mit erhöhten Sicherheitsanforderungen bezüglich Verfügbarkeit, Integrität und Vertraulichkeit ist hier besondere Sorgfalt geboten. Die konkrete Umsetzung von sicherheitsrelevanten Prozessen für einen sicheren Betrieb auf Seiten des Cloud-Dienstleisters ist nicht immer transparent. Das betrifft unter anderem das Patch-Management, das Backup, den Infrastrukturschutz, die sichere Datenübertragung und die Mandantentrennung in der Cloud-Infrastruktur. Bei der Speicherung im Ausland sind sich ändernde lokale rechtliche Regelungen nicht einschätzbar bzw. vorhersehbar. Hier besteht unter Umständen die Gefahr, dass Daten für Dritte zugänglich werden. | |
| Hinzugefügt: Es sollte geprüft werden, ob Daten, die in einem Cloud-Dienst verarbeitet oder gespeichert werden, in die Backup-Konzeption des Betreibers aufgenommen werden müssen. | |
| Gelöscht: - | Hinzugefügt: zu a) |
| Hinzugefügt: Es sollten insbesondere die folgenden Themen verbindlich geregelt werden: | |
| Hinzugefügt: - Authentisierung/Autorisierung der Zugriffe | |
| Hinzugefügt: - Mandantenfähigkeit / Trennung der Kundendaten | |
| Hinzugefügt: - Festlegung zur Datenübertragung (Verschlüsselung / Integritätsschutz) und zur Kommunikationsanbindung zwischen Kunden und Cloud-Dienstleister | |
| Hinzugefügt: - Datensicherung und –wiederherstellung | |
| Hinzugefügt: - Schutz der Dienstleister-Infrastruktur | |
| Hinzugefügt: - Sichere Speicherung der Daten | |
| Hinzugefügt: - Patch-Management der Cloud-Infrastruktur | |
| Hinzugefügt: - Personalsicherheit | |
| Hinzugefügt: - Physische Sicherheit der Rechenzentren und Zutrittsschutz | |
| Hinzugefügt: - Ort der Leistungserbringung durch den Cloud-Dienstleister | |
| Hinzugefügt: - Vorgaben zum Incident Handling | |
| Hinzugefügt: - Schadsoftwareschutz | |
| Hinzugefügt: - Sicherstellung der Datenlöschung | |
| Hinzugefügt: - Notfallvorsorge | |
| Hinzugefügt: - Möglichkeit der Dienstleisterauditierung | |
| Hinzugefügt: Empfehlungen zur Absicherung von Cloud-Diensten sind in den Internationalen Standards ISO/IEC 27017:2015 Code of practice for information security controls based on ISO/IEC 27002 for cloud services und ISO/IEC 27018:2014 Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors definiert. Dabei ist zu beachten, dass eine Zertifizierung des Cloud-Dienstleisters gemäß dieser Normen in der Regel nicht hinreichend ist, sondern ergänzende verbindliche Vereinbarungen zu den o.g. Themen notwendig sind. | |
| Hinzugefügt: zu c) | |
| Hinzugefügt: Cloud-Dienste können beispielsweise durch Störungen der Internet bzw. Cloud-Anbindung ausfallen. |
<>Anforderungen an die Dokumentation - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 12.1.1, 14.1.1, 14.2.7 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 7.2.2, 12.1.1, 14.1.1, 14.2.7 |
| Gelöscht: Dem Auftraggeber muss spätestens zur Abnahme eine | Hinzugefügt: Dem Auftraggeber muss spätestens zur Abnahme eine projektspezifische Dokumentation übergeben werden. |
| Hinzugefügt: Für Einzelkomponenten und Gesamtsysteme muss eine Beschreibung aller sicherheitsrelevanten Systemeinstellungen und Parameter sowie ihrer Standardwerte enthalten sein. Außerdem werden sicherheitsspezifische Implementierungsdetails aufgelistet und kurz beschrieben (z.B. verwendete kryptographische Verfahren). | |
| Gelöscht: | Hinzugefügt: Für ein Gesamtsystem sind zusätzlich Informationen über die Systemarchitektur zu dokumentieren. Dies umfasst den grundsätzlichen Aufbau des Systems und die Interaktionen aller beteiligten Komponenten. In dieser Dokumentation wird besonders auf die sicherheitsrelevanten oder schützenswerten Systemkomponenten sowie ihre gegenseitigen Abhängigkeiten und Interaktionen eingegangen. |
| Gelöscht: Außerdem werden sicherheitsspezifische Implementierungsdetails aufgelistet und kurz beschrieben (z. B. verwendete Verschlüsselungsstandards). |
<>Anforderungen an die Dokumentation - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Der Auftragnehmer sollte eine Sicherheitsdokumentation erstellen, in der alle IT-sicherheitsrelevanten Informationen zusammengefasst sind | Hinzugefügt: Der Auftragnehmer sollte eine Sicherheitsdokumentation erstellen, in der alle IT-sicherheitsrelevanten Informationen zusammengefasst sind. Neben der konkreten Sicherheitskonfiguration und der zugehörigen Parameter sollten z.B. auch System- und Kommunikationseinstellungen wie maximale Anzahl gleichzeitig angemeldeter Nutzer, maximale Anzahl von Netzwerkverbindungen, minimale Netzwerkbandbreiten usw. dokumentiert werden. Die Dokumentation sollte über den gesamten Projektverlauf aktuell gehalten werden. |
| Gelöscht: In der Regel enthält die Dokumentation eine grundsätzliche Beschreibung, die für alle Anwendungen und Konfigurationen gültig ist, sowie einen projektspezifischen Anteil, in dem die konkrete Umsetzung beschrieben ist, z.B. als Anhang zum Pflichtenheft. Alle sicherheitsrelevanten Beschreibungen sollten in einem separaten Dokument bereitgestellt werden | Hinzugefügt: In der Regel enthält die Dokumentation eine grundsätzliche Beschreibung, die für alle Anwendungen und Konfigurationen gültig ist, sowie einen projektspezifischen Anteil, in dem die konkrete Umsetzung beschrieben ist, z.B. als Anhang zum Pflichtenheft. Alle sicherheitsrelevanten Beschreibungen sollten in einem separaten Dokument bereitgestellt werden. |
| Hinzugefügt: Es sollten getrennte Dokumentationen für den Administrator und die System-Benutzer existieren. Beide Dokumentationen sollten für die jeweiligen Gruppen unter anderem eine Auflistung der sicherheitsrelevanten Einstellungen und Funktionen enthalten und Hinweise für sicherheitsverantwortliches Handeln nennen. Die Dokumentation von potentiell vertraulichen Informationen, z.B. Zugangsdaten wie Passwörter oder Portfreigaben, sollte nicht in der allgemeinen System- oder Sicherheitsdokumentation erfolgen, sondern sollte dem Auftraggeber separat in gesicherter Form übergeben werden. | |
| Hinzugefügt: Die Dokumentation sollte auf Konsequenzen von grob unsicheren Konfigurationseinstellungen hinweisen. Außerdem sollten alle sicherheitsspezifischen Log- und Audit-Meldungen erläutert und mögliche Ursachen sowie gegebenenfalls passende Gegenmaßnahmen genannt werden. | |
| Hinzugefügt: Die Dokumentation sollte gegebenenfalls eine Beschreibung der Voraussetzungen für einen sicheren Systembetrieb enthalten. Dazu zählen unter anderem Anforderungen an den Benutzerkreis, Netzwerkumgebung sowie Interaktion und Kommunikation mit anderen Systemen und Netzwerken sowie Anforderungen an physische Sicherheit und Umgebungsparameter wie Klimatisierung, Energieversorgung, EMVSchutz, Brand- und Havarieschutz, etc. | |
| Hinzugefügt: Die aktuelle Dokumentation sollte verfügbar sein, z.B. für den Bereitschaftsdienst. Die Prüfung der Dokumentation sollte Teil der Abnahmeprüfung sein. |
Anforderungen an die Dokumentation – Haupttechnologiebereiche
-keine Veränderungen-
Auswirkungen auf Ihr ISMS
Änderungen im Wortgebrauch
Die meisten Änderungen im Kapitel ‚Allgemeine Anforderungen‘ beziehen sich auf Formulierungen, die den Inhaltswert der Aussagen nicht verändern.
Drei Neuerungen im Wortgebrauch sind dennoch hervorzuheben. Die Begriffskombination ‚Gesamtsystem und Einzelkomponenten‘ wird neu eingeführt. Statt Hersteller oder Lieferant wird der Begriff ‚Auftragnehmer‘ verwendet. Anstelle sensible Daten zu verschlüsseln, wird die ‚Verschlüsselung von vertraulichen Daten‘ betont.
Die Ergänzung um die Einzelkomponenten betont, dass eine differenzierte Betrachtung der Systeme für ein wirkunsvolles ISMS notwendig ist. Ein besonderer Schutzbedarf von Einzelkomponenten sollte bis auf das Gesamtsystem vererbt werden und sich entsprechend in den Maßnahmen zur Risikoreduzierung wiederspiegeln.
- Ist die Vererbungslogik für den Schutzbedarf Ihrer Einzelkomponenten bis hin zum Gesamtsystem konsistent?
Die Verwendung des Begriffs Auftragnehmer impliziert, dass zwischen den Parteien ein erteilter Auftrag vorliegt, der auftragsbezogene Weisungen des Auftraggebers enthält. Dieses Verständnis spiegelt sich in vielen Themen des Bereichs ‚Allgemeine Anforderungen‘ durch geforderte vertragliche Regelungen wieder.
Die Wortwahl ‚vertraulich‘ in Bezug auf Daten wird dem aus den Normen bekannten Schutzziel der Vertraulichkeit gerecht.
Bezug zu Normen der ISO/IEC 27000 Normenreihe
Die alte Version des BDEW/OE Whitepapers bezieht sich auf die Normen 27002:2013 und TR 27019:2013 der ISO/IEC 27000 Normenreihe. Beide waren, als das Whitepaper erstellt wurde, die aktuellsten Versionen.
Die neue Whitepaper-Version aus diesem Jahr dagegen referenziert die Normen 27002:2013 und 27019:2017 der selben Reihe. Hier wurde scheinbar nicht auf Aktualität geachtet, da es bereits seit Mitte letzten Jahres die 27002:2017 gibt. Darüberhinaus wird die 27019:2017 in jeder Sicherheitsanforderung, unahängig davon, ob es einen Bezug gibt, referenziert.
Somit dienen die Bezüge zur Normenreihe lediglich als grobe Orientierung.
- Sie sollten selbst prüfen welche Sicherheitsanforderungen der Normenreihe sich mit denen des BDEW/OE Whitepapers decken.
Entwicklung der Systemarchitektur
Der effektivste Weg Schwachstellen zu reduzieren ist bereits bei der Entwicklung den Fokus auf Informationssicherheit zu setzen. Sicherheitsanforderungen sollten daher direkt in den Entwicklungsablauf eingebunden werden (Security-by-Design).
Weiterhin empfiehlt das Whitepaper die Laufzeitüberwachung der Systeme, das Meiden unnötiger Schnittstellen (öffentliches Internet und andere Dienste) sowie die Nutzung eines Kommunikations-Gateways mit Prüffunktion.
- Sind Ihre Systemarachitektur und verantwortlichen Mitarbeiter auf dem neusten Stand der Technik?
Mehr vertragliche Regelungen
Zwischen Auftraggeber- und Auftragnehmerseite sind mehr Regelungen vertraglich zu fixieren. Das betrifft insbesondere die Themen
- Patch- und Updatemanagement (Vorgehensweise, Überprüfung, Breitstellung und Freigabe von Patches und Updates),
- Supportgewährleistung durch Auftragnehmer für von ihm und fremdentwickelte Systeme während des vertraglich fixierten Betriebszeitraumes,
- Supportanforderungen vertraglich festlegen,
- Migrationskonzept für Systeme erstellen,
- Nutzung eines kundenspezifischen Testsystems auf Auftragnehmerseite und/oder Auftraggeberseite, sofern wegen Kritikalitätseinstufung erforderlich,
- Bereitstellung von Sicherheitspatches auf alle Software- und Systemkomponenten ausdehnen und Vereinbarungen zur Vorgehensweise vertraglich berücksichtigen,
- Test, Freigabe und Bereitstellung von Sicherheitspatches müssen innerhalb der vertraglich vereinbarten Zeit erfolgen,
- Nutzug von Cloud-Diensten.
- Eine Überprüfung der Vertragswerke verbessert Ihre Informationssicherheit.
Zusätzliche Anforderungen an das Patchmanagement
Für das Patchmanagement benötigte Server und Datenbanken sollen in einer eigenen von der Büro-IT getrennten Infrastruktur betrieben werden. Zudem wird empfohlen die zentralen Kommunikationssysteme der Betriebsführungs-/Leitsysteme und des Systembetriebs in das Patchmanagement mit einzubeziehen.
- Können Sie die zusätzlichen Anforderungen an das Patchmanagement schon heute erfüllen?
Einsatz Kryptographischer Verfahren
Die Integritätsprüfung mittels kryptographischer Prüfsummen soll auf Sicherheits-Patches und Updates ausgedehnt werden. Bei Systemdateien, Anwendungen, Konfigurationsdateien, Anwendungs-Parameter, Firmware-Parameter und Firmware-Versionen soll die Integritätsprüfung insbesondere in den Change-Management-Prozess integriert werden.
Bei der Auswahl von Kryptographischen Verfahren sind Empfehlungen des BSI, BNetzA und die Mindestanforderungen aus der Normenreihe IEC 62351 relevant. Die Implementierung der Verfahren sollte einen Austausch ermöglichen. Zur Vermeidung von Implementierungsfehlern wird auf die Verwendung von anerkannten Bibliotheken verwiesen.
- Decken sich Ihre aktuellen Maßnahmen zur Erhöhung Ihrer Informationssicherheit mit dem geforderten Einsatz Kryptographischer Verfahren?
Nutzung von Cloud-Diensten
Das Thema Nutzung von Cloud-Diensten wurde erstmalig in den Katalog der Sicherheitsanforderungen aufgenommen.
- Nutzen Sie bereits Cloud-Dienste oder ziehen die Nutzung in Erwägung, dann sollten Sie den gesamten Abschnitt durcharbeiten.
Zusammenfassung und Ausblick
Neuerungen der allgemeinen Sicherheitsanforderungen des neuen BDEW/OE Whitepapers beziehen sich vor allem auf die Themen Systemarchitekturentwicklung, Patch- und Updatemanagement, Support, Einsatz Kryptographischer Verfahren sowie die Nutzung von Cloud-Diensten.
Das Prinzip Security-by-Design wurde neu aufgenommen, um potentielle Schwachstellen bereits bei der Entwicklung aufdecken und reduzieren zu können. Im Bereich des Patch-/Updatemangement und Supports ist eine noch engere Abstimmung zwischen Auftraggeber und Auftragnehmer gefordert. Hierzu sollten die Verträge zwischen den Parteien geprüft und gegebenenfalls ergänzt werden.
Der Einsatz von Kryptographischen Verfahren wird insbesondere bei Integritätsprüfungen im Rahmen des Patch-/Updatemanagements gefordert. Hierbei wurden neue Empfehlungen des BSI und Mindestanforderungen aus der Normenreihe IEC 62351 sowie weitere Kriterien zum Einsatz der Verfahren ausgesprochen.
Die Nutzung von Cloud-Diensten findet erstmalig Erwähnung im neuen Whitepaper. Die Einbindung von Cloud-Diensten bedarf einer sehr kritischen Risiko-Nutzen-Analyse, was sich in den Sicherheitsanforderungen sowie Ergänzungen und Anmerkungen des Whitepapers wiederspiegelt.
Teil 3 unserer Beitragsserie „BDEW Sicherheitsanforderungen 2018: Was ist neu?“ durchleuchtet die Sicherheitsanforderungen zu den Kapiteln Projektorganisation und Basissystem.
Bekommen Sie schon unseren xmera blogletter? Nein? Dann melden sie sich für unserem kostenfreien Infoservice an!
xmera
[yuzo_related]
