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.
Teil 3 – BDEW Sicherheitsanforderungen 2018: Was ist neu?
Informieren Sie sich über zusätzliche Maßnahmen in den Bereichen Sicherheits- und Abnahmetests, Systemhärtung und Schadsoftware-Schutz. Machen Sie sich mit den neuen Sicherheitsmaßnahmen für den Einsatz von Virtualisierungstechnologien vertraut.
Teil 4 – BDEW Sicherheitsanforderungen 2018: Was ist neu?
Erfahren Sie mit welchen Maßnahmen Sie Ihr ISMS in Sachen ‚Netzwerk und Kommunikation‘ erweitern. Wir zeigen Ihnen Neuerungen zu den Themen Datenübertragungsprotokolle, Netzwerkstrukturen, Fern-Zugänge und Funktechnologien auf.
Teil 5 – BDEW Sicherheitsanforderungen 2018: Was ist neu?
Eine Anpasung an Ihr ISMS kann arbeitsreich werden. Im Bereich ‚Anwendung‘ gibt es eine Reihe von Verweise auf externe Standards.
Teil 6 – BDEW Sicherheitsanforderungen 2018: Was ist neu?
Sie können aufatmen. Teil 6 ist der letzte Teil der Beitragsserie. Neue Sicherheitsanforderungen der Bereiche ‚Entwicklung‘, ‚Wartung‘, ‚Datensicherung und Notfallplanung‘ betreffen in erster Linie Auftragnehmer von Energieversorgungsnetzbetreibern.
In Teil 6 analysiert xmera die Abschnitte ‚Entwicklung‘, ‚Wartung‘, ‚Datensicherung und Notfallplanung‘ des Kapitels Sicherheitsanforderungen aus dem BDEW/OE Whitepaper.
Neue Sicherheitsanforderungen betreffen in erster Linie Auftragnehmer von Energieversorgungsnetzbetreibern. Trotzdem werden Sie von diesen Neuerungen mehr oder weniger betroffen sein.
Bevor es jedoch mit der Analyse losgeht, blicken wir gemeinsam auf die Erkenntnisse aus dem fünften Teil der Serie zurück.
Der eilige Leser kann gerne direkt auf den Abschnitt seiner Wahl in diesem Beitrag springen.
Rückblick auf Teil 5
In Teil 5 unserer Beitragsserie BDEW Sicherheitsanforderungen 2018: Was ist neu? wurden die Sicherheitsanforderungen zum Thema ‚Anwendung‘ aus dem neuen BDEW/OE Whitepaper analysiert. Dabei konnten nur wenig direkte Neuerungen identifiziert werden.
Dennoch könnte es sein, dass die Anpassung Ihres ISMS an das neue Whitepaper zum Thema ‚Anwendung‘ aufwendig für Sie wird. Grund dafür sind zahlreiche Verweise auf externe Standards. Diese betreffen die folgenden Bereiche:
- Rollenkonzepte,
- Web-Aplikationen und Web-Services,
- Logging.
Ausführlichere Informationen über die Auswirkungen des neuen BDEW/OE Whitepapers im Abschnitt ‚Anwendung‘ können Sie in Teil 5 – BDEW Sicherheitsanforderungen 2018: Was ist neu? nachlesen.
Funktionsweise des Textvergleichs
Bevor Sie sich den Vergleich der alten und neuen Kapitel anschauen, empfehle ich zunächst die Funktionsweise des Textvergleiches in Teil 1 der Beitragsserie nachzuvollziehen.
Textvergleich: Entwicklung, Wartung, Datensicherung und Notfallplanung
Im Kapitel ‚Entwicklung‘ wird es um Sicherheitsanforderungen für die Hard- und Softwareentwicklung sowie Integration von Standardsystemen oder -komponenten gehen.
Das Kapitel ‚Wartung‘ bezieht sich auf Sicherheitsanforderungen, die in Verbindung mit Service-Leistungen wie bspw. Instandhaltungsarbeiten, Störungsanalysen, Fehler- und Störungsbehebung, Verbesserungen und Anpassungen in Zusammenhang stehen.
Als letztes Kapitel behandelt das neue Whitepaper Sicherheitsanforderungen zu den Themen Datensicherung und Notfallplanung.
Welche Themen sich in den Bereichen ‚Entwicklung‘, ‚Wartung‘, ‚Datensicherung und Notfallplanung‘ im Vergleich mit der alten Version des BDEW/OE Whitepapers verändert haben, zeigt die Analyse der Unterkapitel aus den Inhaltsverzeichnissen der beiden Whitepaper.
Analyse der Unterkapitel
<>
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Entwicklung | Hinzugefügt: Entwicklung |
| Unverändert: - Sichere Entwicklungsstandards, Qualitätsmanagement und Freigabeprozesse | Unverändert: - Sichere Entwicklungsstandards, Qualitätsmanagement und Freigabeprozesse |
| Gelöscht: - Sichere Datenhaltung und Übertragung | |
| Gelöscht: - Sichere Entwicklungs | Hinzugefügt: - Sichere Entwicklungs- und Test-Systeme, Integritäts-Prüfung |
| Hinzugefügt: Wartung | |
| Hinzugefügt: - Anforderung an die Wartungsprozesse | |
| Gelöscht: - Sichere Update- und Wartungsprozesse | Hinzugefügt: - Sichere Updateprozesse |
| Unverändert: - Konfigurations- und Change-Management, Rollbackmöglichkeiten | Unverändert: - Konfigurations- und Change-Management, Rollbackmöglichkeiten |
| Unverändert: - Behandlung von Sicherheitslücken | Unverändert: - Behandlung von Sicherheitslücken |
| Gelöscht: - Sourcecode-Hinterlegung | |
| Gelöscht: Datensicherung | Hinzugefügt: Datensicherung und Notfallplanung |
| Unverändert: - Backup: Konzept, Verfahren, Dokumentation, Tests | Unverändert: - Backup: Konzept, Verfahren, Dokumentation, Tests |
| Unverändert: - Notfallkonzeption und Wiederanlaufplanung | Unverändert: - Notfallkonzeption und Wiederanlaufplanung |
Auf dem ersten Blick scheint nicht viel in den Kapiteln ‚Entwicklung‘, ‚Wartung‘ und ‚Datensicherung und Notfallplanung‘ verändert worden zu sein.
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!
In der alten Fassung des BDEW/OE Whitepapers waren die Wartungsthemen im Kapitel Entwicklung enthalten. Das neue Whitepaper widmet dem Thema Wartung ein eigenes Kapitel.
Tatsächliche inhaltliche Neuerungen kann allerdings erst der nachfolgende Textvergleich aufdecken.
<>Sichere Entwicklungsstandards, Qualitätsmanagement und Freigabeprozesse - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 9.4.5, 14.2.2, 14.2.3, 14.2.4, 14.2.5, 14.2.6, 14.2.7, 14.2.8, 14.2.9, 14.3.1 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.4.5, 14.2.2, 14.2.3, 14.2.4, 14.2.5, 14.2.6, 14.2.7, 14.2.8, 14.2.9, 14.3.1 |
| Gelöscht: ISO/IEC TR 27019:2013: 10.1.4 | |
| Unverändert: a) Das System muss beim Auftragnehmer von zuverlässigen und geschulten Mitarbeitern entwickelt werden. Falls die Entwicklung oder Teile davon an einen Subunternehmer ausgelagert werden sollen, bedarf dies der schriftlichen Zustimmung durch den Auftraggeber. An den Unterbeauftragten sind mindestens die gleichen Sicherheitsanforderungen zu stellen wie an den Auftragnehmer. | Unverändert: a) Das System muss beim Auftragnehmer von zuverlässigen und geschulten Mitarbeitern entwickelt werden. Falls die Entwicklung oder Teile davon an einen Subunternehmer ausgelagert werden sollen, bedarf dies der schriftlichen Zustimmung durch den Auftraggeber. An den Unterbeauftragten sind mindestens die gleichen Sicherheitsanforderungen zu stellen wie an den Auftragnehmer. |
| Gelöscht: b) Der Auftragnehmer muss das System nach anerkannten Entwicklungsstandards und Qualitätsmanagement/-sicherungs-Prozessen entwickeln. Das Testen des Systems erfolgt nach dem 4-Augenprinzip: Entwicklung und Tests werden von verschiedenen Personen durchgeführt. Die Testpläne und –prozeduren, sowie erwartete und tatsächliche Testergebnisse müssen dokumentiert und nachvollziehbar sein, sie können vom Auftraggeber eingesehen werden. | |
| Hinzugefügt: b) Der Auftragnehmer muss das System nach anerkannten Entwicklungsstandards und Qualitätsmanagement/-sicherungs-Prozessen entwickeln. Im Rahmen des Entwicklungsprozesses müssen insbesondere die folgenden sicherheitsrelevanten Entwicklungsschritte berücksichtigt werden: | |
| Hinzugefügt: - Definition der Sicherheitsanforderungen | |
| Hinzugefügt: - Bedrohungsmodellierung und Risikoanalyse | |
| Hinzugefügt: - Ableitung von Anforderungen an Systemdesign und Implementierung | |
| Hinzugefügt: - Sichere Programmierung | |
| Hinzugefügt: - Anforderungstests | |
| Hinzugefügt: - Sicherheitsprüfungen vor der Inbetriebnahme | |
| Hinzugefügt: c) Das Testen erfolgt nach dem 4-Augen-Prinzip: Entwicklung und Tests werden von verschiedenen Personen durchgeführt. Die Testpläne und -prozeduren sowie erwartete und tatsächliche Testergebnisse müssen dokumentiert und nachvollziehbar sein. Sie können bei Bedarf vom Auftraggeber eingesehen werden. | |
| Gelöscht: | Hinzugefügt: d) Der Auftragnehmer muss über einen dokumentierten Entwicklungs-Sicherheitsprozess verfügen, der die physische, organisatorische und personelle Sicherheit abdeckt und die Integrität und Vertraulichkeit des Systems schützt. Die Effektivität des o.g. Prozesses kann durch eine externe Auditierung überprüft werden. |
| Gelöscht: | Hinzugefügt: e) Der Auftragnehmer muss über eine Programmierrichtlinie verfügen, in der auf sicherheitsrelevante Anforderungen explizit eingegangen wird: So sind z.B. unsichere Programmiertechniken und Funktionen zu vermeiden. Eingabedaten müssen verifiziert werden, um z.B. Pufferüberlauf-Fehler zu verhindern. Wo möglich, werden sicherheitserhöhende Compileroptionen und Bibliotheken benutzt. |
| Gelöscht: | Hinzugefügt: f) Die Freigabe des Systems bzw. von Updates/Sicherheits-Patches muss anhand eines spezifizierten und dokumentierten Freigabe-Prozesses stattfinden. |
<>Sichere Entwicklungsstandards, Qualitätsmanagement und Freigabeprozesse - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Anerkannte Vorgehensmodelle und Standards sollten im Entwicklungsprozess angewendet werden. Die angewandten Prozesse und Aktivitäten sollten umfassend dokumentiert werden. | Unverändert: Anerkannte Vorgehensmodelle und Standards sollten im Entwicklungsprozess angewendet werden. Die angewandten Prozesse und Aktivitäten sollten umfassend dokumentiert werden. |
| Unverändert: Sichere Softwareentwicklung setzt kein bestimmtes Entwicklungsmodell zwingend voraus, ggf. müssen aber die notwendigen sicherheitsbezogenen Entwicklungsschritte und Aktivitäten angepasst und in die vorhandene Entwicklungsmethodik integriert werden. | Unverändert: Sichere Softwareentwicklung setzt kein bestimmtes Entwicklungsmodell zwingend voraus, ggf. müssen aber die notwendigen sicherheitsbezogenen Entwicklungsschritte und Aktivitäten angepasst und in die vorhandene Entwicklungsmethodik integriert werden. |
| Unverändert: zu a) | Unverändert: zu a) |
| Unverändert: Besonders die Weitergabe von projektspezifischen Entwicklungen an Subunternehmen bedarf der schriftlichen Zustimmung des Auftraggebers/Betreibers, da Spezifika der Anlagen des Auftraggebers/Betreibers nicht ungeschützt verbreitet werden dürfen. | Unverändert: Besonders die Weitergabe von projektspezifischen Entwicklungen an Subunternehmen bedarf der schriftlichen Zustimmung des Auftraggebers/Betreibers, da Spezifika der Anlagen des Auftraggebers/Betreibers nicht ungeschützt verbreitet werden dürfen. |
| Unverändert: zu b) | Unverändert: zu b) |
| Unverändert: Die Entwicklung und das Testen sollten so weit wie möglich auf vom Produktivsystem getrennten Test- und Entwicklungssystemen erfolgen. | Unverändert: Die Entwicklung und das Testen sollten so weit wie möglich auf vom Produktivsystem getrennten Test- und Entwicklungssystemen erfolgen. |
| Unverändert: zu d) | Unverändert: zu d) |
| Unverändert: Es sollten auch routinemäßige Kontrollen des Quellcodes mit automatisierten Prüftools durchgeführt werden. Diese Prüfung sollte möglichst automatisiert in den Entwicklungsprozess integriert werden. | Unverändert: Es sollten auch routinemäßige Kontrollen des Quellcodes mit automatisierten Prüftools durchgeführt werden. Diese Prüfung sollte möglichst automatisiert in den Entwicklungsprozess integriert werden. |
| Gelöscht: Beispiele für anerkannte Entwicklungs- und Qualitätsmanagementstandards und Initiativen: | |
| Gelöscht: - BSI – Build Security In | |
| Gelöscht: - BSIMM – Building Security In Maturity Model | |
| Gelöscht: - CERT Secure Coding Standards | |
| Gelöscht: - CMMI - Capability Maturity Model Integration | |
| Gelöscht: - EFQMM - European Foundation for Quality Management Model | |
| Gelöscht: - ISO 9001 | |
| Gelöscht: - Microsoft SDL - Security Development Lifecyle | |
| Gelöscht: - OWASP | |
| Gelöscht: - SAFECode | |
| Gelöscht: - SAMM – Software Assurance Maturity Model | |
| Gelöscht: - Software Assurance Consortium | |
| Gelöscht: - Software Engineering Body of Knowledge | |
| Gelöscht: - V-Model |
Sichere Entwicklungsstandards, Qualitätsmanagement und Freigabeprozesse – Haupttechnologiebereiche
-keine Veränderungen-
<>Sichere Entwicklungs- und Test-Systeme, Integritäts-Prüfung - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.4.5, 12.1.4, 14.2.7, 14.3.1 |
| Gelöscht: ISO/IEC TR 27019:2013: 10.1.4 | |
| Gelöscht: a) Die Entwicklung muss auf sicheren Systemen erfolgen, die Entwicklungsumgebung, Quellcode und Binärdateien sind gegen fremde Zugriffe zu sichern. | |
| Hinzugefügt: a) Die Entwicklung muss auf sicheren Systemen erfolgen, die Entwicklungsumgebung, Quellcode und Binärdateien müssen gegen fremde Zugriffe gesichert sein. Alle Entwicklungssysteme müssen anhand anerkannter Best-Practice-Vorgaben und nach aktuellem Stand der Technik gehärtet sein und über einen aktuellen Schadsoftwareschutz verfügen sowie mit allen aktuellen Sicherheits-Patches versehen sein. | |
| Gelöscht: b) Entwicklung und Test des Systems sowie von Updates, Erweiterungen und | Hinzugefügt: b) Entwicklung und Test des Systems sowie von Updates, Erweiterungen und Sicherheits-Patches muss in einer vom Produktivsystem getrennten Test-Umgebung erfolgen. |
| Gelöscht: c) Auf Produktiv-Systemen darf kein Quellcode gespeichert werden. | |
| Hinzugefügt: c) Auf Produktiv-Systemen darf mit Ausnahme von interpretierten Skriptsprachen kein Quellcode gespeichert werden. | |
| Unverändert: d) Es muss möglich sein, die Integrität von Quellcode und Binärdateien auf unerlaubte Veränderungen hin zu überprüfen, beispielsweise durch gesicherte Prüfsummen. | Unverändert: d) Es muss möglich sein, die Integrität von Quellcode und Binärdateien auf unerlaubte Veränderungen hin zu überprüfen, beispielsweise durch gesicherte Prüfsummen. |
| Gelöscht: e) Es ist eine Versionshistorie für alle eingesetzte Software zu führen, die es ermöglicht die durchgeführten Softwareänderungen nachzuvollziehen. | Hinzugefügt: e) Es ist eine Versionshistorie für alle eingesetzte Software zu führen, die es ermöglicht, die durchgeführten Softwareänderungen nachzuvollziehen. |
<>Sichere Entwicklungs- und Test-Systeme, Integritäts-Prüfung - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Die Entwicklungssysteme und -umgebungen sowie die | Hinzugefügt: Die Entwicklungssysteme und -umgebungen sowie die Testsysteme sollten immer nach Stand der Technik gesichert und vom allgemeinen Unternehmensnetz getrennt sein. |
| Gelöscht: Ein Zugriff auf unsichere Netze, z.B. zur Internet- oder | Hinzugefügt: Ein Zugriff auf unsichere Netze, z.B. zur Internet- oder Mail-Nutzung, sollte von den genannten Systemen nicht möglich sein. Ist für die Entwickler ein solcher Zugriff notwendig, sollten die Systeme, von denen der Zugriff erfolgt, von der Entwicklungsumgebung umfassend abgeschottet sein, z.B. durch die Nutzung von Virtualisierungs- oder Proxylösungen. Es sollte sichergestellt sein, dass Risiken durch Verbindungen zu Internet oder Mailnutzung größtmöglich minimiert werden. |
| Gelöscht: Alle Entwicklungssysteme sollten anhand anerkannter Best-Practice-Vorgaben und nach aktuellem Stand der Technik gehärtet sein. Alle Entwicklungssysteme sollten über einen aktuellen Schadsoftwareschutz verfügen und mit allen aktuellen Sicherheitspatches versehen sein. | |
| Gelöscht: Die Entwicklungssysteme und -umgebungen sowie die | Hinzugefügt: Die Entwicklungssysteme und -umgebungen sowie die Testsysteme sollten mit einem sicheren logischen Zugangsschutz versehen sowie vor unberechtigtem physischem Zugriff geschützt sein. |
| Unverändert: zu c) | Unverändert: zu c) |
| Gelöscht: | Hinzugefügt: Ein ausreichender Schutz gegen unerlaubte Veränderung sollte vorgesehen werden, z.B. Code-Signing. |
| Gelöscht: Ein | Hinzugefügt: Ein Test-System (z.B. als Testsäule aus Redundanzkomponenten) sollte generell vorgesehen werden. Bei der Korrektur nach einem Fehlerfall kann es notwendig sein, die konkreten Rahmenbedingungen nachzustellen, um die Korrektur des Fehlers zu überprüfen. Diese Rahmenbedingungen sind ggf. im Test-System nicht immer nachbildbar. Eine Fehleranalyse ist ggf. auch nur im Produktiv-System sinnvoll. Dies beinhaltet in der Regel aber nur das Debuggen des Fehlers - ein vollumfänglicher Entwicklungszyklus auf dem Produktivsystem inklusive Anwendungs-Kompilierung kann zu weitreichenden Störungen führen. Ebenso ist die korrekte Versions- und Änderungskontrolle stark erschwert. |
| Unverändert: Vor einer Fehleranalyse und Tests im Produktiv-System sollten immer eine individuelle Risikoabschätzung und eine formale Freigabe durch den Betreiber erfolgen. | Unverändert: Vor einer Fehleranalyse und Tests im Produktiv-System sollten immer eine individuelle Risikoabschätzung und eine formale Freigabe durch den Betreiber erfolgen. |
<>Sichere Entwicklungs- und Test-Systeme, 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: zu b) | Unverändert: zu b) |
| Unverändert: Vor der Inbetriebnahme darf eine Entwicklung auf den späteren Produktivsystemen erfolgen. Nach erfolgter Inbetriebnahme sollte dies nicht mehr geschehen. | Unverändert: Vor der Inbetriebnahme darf eine Entwicklung auf den späteren Produktivsystemen erfolgen. Nach erfolgter Inbetriebnahme sollte dies nicht mehr geschehen. |
| Unverändert: zu c) | Unverändert: zu c) |
| Unverändert: Zur Fehleranalyse („Debugging“) kann die temporäre Installation des Quellcodes hilfreich sein. Nach Abschluss der Fehlerbehebung sollte der Quellcode wieder entfernt werden, um Manipulationen der Leitsystemanwendung zu verhindern. | Unverändert: Zur Fehleranalyse („Debugging“) kann die temporäre Installation des Quellcodes hilfreich sein. Nach Abschluss der Fehlerbehebung sollte der Quellcode wieder entfernt werden, um Manipulationen der Leitsystemanwendung zu verhindern. |
| Unverändert: Eine weitere Möglichkeit ist die Nutzung eines netzwerkbasierten Debuggers. Der hierfür notwendige Dienst sollte aber nur temporär aktiviert werden und gegen unbefugte Zugriffe geschützt sein. | Unverändert: Eine weitere Möglichkeit ist die Nutzung eines netzwerkbasierten Debuggers. Der hierfür notwendige Dienst sollte aber nur temporär aktiviert werden und gegen unbefugte Zugriffe geschützt sein. |
| Unverändert: Übertragungstechnik/ Sprachkommunikation: - | Unverändert: Übertragungstechnik/ Sprachkommunikation: - |
| Unverändert: Sekundär-, Automatisierungs und Fernwirktechnik: | Unverändert: Sekundär-, Automatisierungs und Fernwirktechnik: |
| Unverändert: zu b) | Unverändert: zu b) |
| Gelöscht: Systementwicklung, Tests, etc. finden i.d.R. beim | Hinzugefügt: Systementwicklung, Tests, etc. finden i.d.R. beim Auftragnehmer statt. Ggf. kann dort eine Auftraggeber-bezogene Testumgebung bereitgehalten werden. |
| Unverändert: Vor der Inbetriebnahme darf eine Entwicklung auf den späteren Produktivsystemen erfolgen. Nach erfolgter Inbetriebnahme sollte dies nicht mehr geschehen. | Unverändert: Vor der Inbetriebnahme darf eine Entwicklung auf den späteren Produktivsystemen erfolgen. Nach erfolgter Inbetriebnahme sollte dies nicht mehr geschehen. |
<>Anforderung an die Wartungsprozesse - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: 2.3.3.2 Anforderungen an die Wartungsprozesse | |
| Gelöscht: ISO/IEC 27002:2013: 9.1.2, 9.2.1, 9.2.2, 15.1.1, 15.1.2 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.1.2, 9.2.1, 9.2.2, 15.1.1, 15.1.2 |
| Gelöscht: ISO/IEC TR 27019:2013: 11.5.2 | |
| Hinzugefügt: a) Der Fern- und Vor-Ort-Zugriff darf nur durch einen definierten und geschulten Personenkreis und nur von abgesicherten Systemen aus erfolgen. Die für den Fern- und Vor-Ort-Zugriff genutzten Zugangs-Systeme und IT-Infrastrukturen müssen anhand anerkannter Best-Practice-Vorgaben und nach aktuellem Stand der Technik gehärtet sein und über einen aktuellen Schadsoftwareschutz verfügen sowie mit allen aktuellen Sicherheits-Patches versehen sein. | |
| Hinzugefügt: b) Durch einen definierten Wartungsprozess muss sichergestellt sein, dass das Wartungspersonal im Rahmen seiner Tätigkeiten nur Zugriff auf die benötigten Systeme, Dienste und Daten und Zutritt zu den entsprechenden Räumlichkeiten erhält. | |
| Gelöscht: | Hinzugefügt: c) Der interaktive Fern-Zugang muss über personalisierte Accounts und unter Nutzung von 2-Faktor-Authentifizierung erfolgen. Für automatisierte Abläufe sind spezielle Kennungen einzurichten, die nur bestimmte Funktionen ausführen können und die keinen interaktiven Zugang ermöglichen. |
| Gelöscht: | Hinzugefügt: d) Es muss technisch sichergestellt sein, dass ein Fern-Zugriff nur erfolgen kann, wenn dieser vom verantwortlichen Betreiber freigegeben wird. Bei externen Dienstleistern müssen die Freigabe und die Trennung für jede Fernzugriffs-Sitzung einzeln erfolgen. Eine Sitzung ist nach Ablauf einer angemessenen Zeit automatisch zu trennen. |
| Gelöscht: c) Am Standort des Auftragnehmers muss der Fern-Zugriff durch einen definierten und geschulten Personenkreis und nur von speziell gesicherten Systemen aus erfolgen. Insbesondere sind diese Zugangs-Systeme während des Fern-Zugriffs von anderen Netzen logisch oder physikalisch zu entkoppeln. Eine physikalische Entkopplung ist der logischen vorzuziehen. | |
| Gelöscht: | |
| Gelöscht: e) Das Wartungspersonal muss den aktuell gültigen Anforderungen gemäß der SÜFV genügen, sofern es für Unternehmen mit überregionaler Elektrizitätsversorgung tätig ist. | |
| Gelöscht: f) Die Vorortwartung durch Servicetechniker stellt ein ernst zu nehmendes Sicherheitsrisiko dar. Es ist zu vermeiden, dass der Auftragnehmer eigene Hardware an das Prozessnetz anschließt (z. B. Wartungs-Notebooks, aber auch Speichergeräte wie USBSticks). | |
| Gelöscht: Falls dies doch nötig sein sollte, muss diese Hardware speziell abgesichert und vom Auftraggeber genehmigt sein sowie zeitnah auf Malware untersucht werden. Der Auftragnehmer ist verpflichtet, die Durchsetzung einer angemessenen internen Sicherheitsrichtlinie für diese Dienstleistung nachzuweisen. | |
| Hinzugefügt: Insbesondere sind die für den Fernzugriff genutzten Zugangs-Systeme während des Fern-Zugriffs von anderen Netzen logisch oder physisch zu entkoppeln. Eine physische Entkopplung ist der logischen vorzuziehen. |
<>Anforderung an die Wartungsprozesse - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Hinzugefügt: Die hier genannten Anforderungen sollten bereits bei Projektplanungen und bei Wartungsvereinbarungen in Zusammenarbeit zwischen Auftraggeber und Auftragnehmer bzw. Dienstleister berücksichtigt werden. Ebenso sollten Datenschutz- und Geheimhaltungsvereinbarungen schriftlich vereinbart werden. | |
| Hinzugefügt: Ein Ziel der Anforderung ist u.a., dass kein unbemerkter und unbefugter Fernwartungszugang von Extern erfolgen kann. Generell sollte bei Wartungsarbeiten die Betriebsführung, z.B. in der Warte, über Arbeiten an den Anlagen informiert werden, beispielsweise durch Zu- oder Abschalten des Fernwartungszuganges. Dies gilt auch für Wartungszugriffe durch internes Personal. Insbesondere bei Zugriffen externer Dienstleister kann dies ggf. durch die Hinterlegung des Authentifizierungstokens in der Warte erreicht werden. | |
| Hinzugefügt: Die Vorortwartung durch Servicetechniker stellt ein ernst zu nehmendes Sicherheitsrisiko dar. Es sollte vermieden werden, dass der Auftragnehmer eigene Hardware an das Prozessnetz anschließt (z.B. Wartungs-Notebooks, aber auch Speichergeräte wie USB-Sticks). Stattdessen sollte eine Bereitstellung von Auftraggeber-eigener Hardware erfolgen. Falls die Nutzung von Hardware des Auftragnehmers doch notwendig sein sollte, sollte dies vom Auftraggeber explizit genehmigt werden. | |
| Hinzugefügt: Die Absicherung der für Fern- und Vor-Ort-Wartung genutzten Systeme sollte insbesondere die folgenden Punkte umfassen: | |
| Hinzugefügt: - Die Wartungssysteme sollten mit einem sicheren logischen Zugangsschutz versehen sowie vor unberechtigten physischen Zugriff geschützt sein. | |
| Hinzugefügt: - Die Wartungssysteme sollten anhand anerkannter Best-Practice-Vorgaben und nach aktuellem Stand der Technik gehärtet sein. | |
| Hinzugefügt: - Fernwartungszugriffe sollten nur aus einer abgesicherten und gegen unberechtigte Zugriffe geschützten DMZ-Umgebung erfolgen. | |
| Hinzugefügt: - Mobile Systeme zur Vor-Ort-Wartung sollten mit einer restriktiv konfigurierten Firewall-Software geschützt werden. | |
| Gelöscht: Die hier genannten Anforderungen sollten bereits bei Projektplanungen und bei Wartungsvereinbarungen in Zusammenarbeit zwischen Auftraggeber und Hersteller bzw. Dienstleister berücksichtigt werden. | Hinzugefügt: - Die Wartungssysteme sollten beim Wartungszugriff über einen aktuellen Schadsoftwareschutz verfügen und mit allen aktuellen Sicherheits-Patches versehen sein. |
| Gelöscht: Ein Ziel der Anforderung ist u.a., dass kein unbemerkter und unbefugter Fernwartungszugang von Extern erfolgen kann. Generell sollte bei Wartungsarbeiten die Betriebsführung, z.B. in der Warte, über Arbeiten an den Anlagen informiert werden, beispielsweise durch Zu- oder Abschalten des Fernwartungszuganges. Dies gilt auch für Wartungszugriffe durch internes Personal. Insbesondere bei Zugriffen externer Dienstleister kann dies ggf. durch die Hinterlegung des | |
| Hinzugefügt: Der Auftragnehmer sollte verpflichtet werden, die Durchsetzung einer angemessenen internen Sicherheitsrichtlinie für diese Dienstleistung nachzuweisen. Die Sicherheitsrichtlinie sollten mindestens die folgenden Punkte behandeln: | |
| Hinzugefügt: - Zugriffs- und Zugangsschutz | |
| Hinzugefügt: - Sichere Authentisierung am Gerät | |
| Hinzugefügt: - Sichere Speicherung von Kundendaten | |
| Hinzugefügt: - Datenträgerverschlüsselung | |
| Hinzugefügt: - Festlegung zur Datenübertragung (Verschlüsselung / Integritätsschutz) | |
| Hinzugefügt: - Datensicherung und –wiederherstellung | |
| Hinzugefügt: - Patch-Management | |
| Hinzugefügt: - Schadsoftwareschutz | |
| Hinzugefügt: - Sichere Mechanismen zur Löschung von Kundendaten | |
| Hinzugefügt: Das Wartungspersonal muss den jeweils anwendbaren gesetzlichen Vorgaben, z.B. bezüglich einer Sicherheitsüberprüfung, bei Tätigkeiten im Bereich Kritischer Infrastrukturen genügen. Für Wartungszugriffe auf kritische Systeme sollte das Wartungspersonal des Auftragnehmers bzw. Dienstleisters namentlich benannt werden. | |
| Hinzugefügt: Die Anforderungen an Wartungsprozesse sollten vertraglich geregelt sein. Eine entsprechende, ggf. gegenseitige Sicherheitsregelung sollte durch den Auftraggeber festgelegt und den Servicetechnikern nachweislich zur Kenntnis gebracht werden. | |
| Gelöscht: Vergleiche hierzu auch | Hinzugefügt: Vergleiche hierzu auch 4.4.4 |
| Gelöscht: zu f) | |
| Gelöscht: Für Arbeiten vor Ort sollte eine Bereitstellung von Auftraggebereigener Hardware erfolgen. Ein Anschluss von Hardware des Lieferanten sollte vermieden werden. |
Anforderungen an die Wartungsprozesse – Haupttechnologiebereiche
-keine Veränderungen-
<>Sichere Updateprozesse - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: 2.5.4 Sichere Update- und Wartungsprozesse | |
| Gelöscht: ISO/IEC 27002:2013: 12.5.1, 14.2.2, 14.2.3, 14.2.7, | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.5.1, 14.2.2, 14.2.3, 14.2.7,14.2.9 |
| Gelöscht: ISO/IEC TR 27019:2013: 12.4.1 | |
| Gelöscht: | Hinzugefügt: Die Bereitstellung und Installation von Updates, Erweiterungen und Patches muss nach einem definierten Prozess und nach Rücksprache mit dem Auftraggeber erfolgen. |
| Gelöscht: b) Von Seiten des Auftragnehmers muss die Wartung durch einen definierten, geschulten Personenkreis und von speziell gesicherten Systemen aus erfolgen. |
<>Sichere Updateprozesse - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Der Stellenwert der Systeme der Energieversorgung ist gesellschaftlich, soziologisch und ökonomisch sehr hoch. Um einen sicheren und zuverlässigen Betrieb zu gewährleisten, ist es deshalb i.d.R. notwendig, schnelle Reaktionszeiten zu ermöglichen sowie gleichzeitig einen definierten und geregelten Wartungsprozess einzuhalten. | Hinzugefügt: Der Stellenwert der Systeme der Energieversorgung ist gesellschaftlich, soziologisch und ökonomisch sehr hoch. Um einen sicheren und zuverlässigen Betrieb zu gewährleisten, ist es deshalb i.d.R. notwendig, schnelle Reaktionszeiten zu ermöglichen sowie gleichzeitig einen definierten und geregelten Wartungsprozess einzuhalten. |
| Gelöscht: zu a) | |
| Gelöscht: Updates und Patches sollten vom | Hinzugefügt: Updates und Patches sollten vom Auftragnehmer immer überprüft und freigegeben sein. Sie sollten zudem vorab auf einem Testsystem getestet werden. |
| Unverändert: Insbesondere bei Individualentwicklungen bietet sich hierfür ein mehrstufiges Vorgehen an: | Unverändert: Insbesondere bei Individualentwicklungen bietet sich hierfür ein mehrstufiges Vorgehen an: |
| Gelöscht: 1. Der | Hinzugefügt: 1. Der Auftragnehmer prüft auf Basis des zugrundeliegenden Standardprodukts. |
| Gelöscht: 2. Test und Freigabe durch den | Hinzugefügt: 2. Test und Freigabe durch den Auftragnehmer erfolgen auf einer Testumgebung, die dem System des Betreibers möglichst entspricht. |
| Gelöscht: 3. Gegebenenfalls prüft der Betreiber bzw. der | Hinzugefügt: 3. Gegebenenfalls prüft der Betreiber bzw. der Auftragnehmer im Auftrag des Betreibers Updates und Patches auf dem eigenen System entsprechend eines vorher definierten Testplans. |
| Gelöscht: Unter Umständen sollte eine mehrstufige Inbetriebnahme vorgesehen werden, die es im Fehlerfall ermöglicht, den Betrieb aufrecht zu erhalten (vgl. | Hinzugefügt: Unter Umständen sollte eine mehrstufige Inbetriebnahme vorgesehen werden, die es im Fehlerfall ermöglicht, den Betrieb aufrecht zu erhalten (vgl. 4.1.2). |
| Unverändert: In Abhängigkeit von der Kritikalität der betroffenen Systeme sollte im Rahmen der Wartungsprozesse durch den Betreiber geprüft werden, ob bestimmte Änderungen nicht per Fernzugriff sondern vor Ort durchgeführt werden müssen. | Unverändert: In Abhängigkeit von der Kritikalität der betroffenen Systeme sollte im Rahmen der Wartungsprozesse durch den Betreiber geprüft werden, ob bestimmte Änderungen nicht per Fernzugriff sondern vor Ort durchgeführt werden müssen. |
| Gelöscht: zu b) | |
| Gelöscht: Die für Vor-Ort- und Fernwartung genutzten Systeme sollten nach aktuellem Stand der Technik gesichert sein. Die Sicherung sollte insbesondere die folgenden Punkte umfassen: | |
| Gelöscht: - Die Wartungssysteme sollten mit einem sicheren logischen Zugangsschutz versehen sowie vor unberechtigten physischen Zugriff geschützt sein. | |
| Gelöscht: - Die Wartungssysteme sind anhand anerkannter Best-Practice-Vorgaben und nach aktuellem Stand der Technik zu härten. | |
| Gelöscht: - Fernwartungszugriffe sollten nur aus einer abgesicherten und gegen unberechtigte Zugriffe geschützten DMZ-Umgebung erfolgen. | |
| Gelöscht: - Mobile Systeme zur Vor-Ort-Wartung sollten mit einer restriktiv konfigurierten Firewallsoftware geschützt werden. | |
| Gelöscht: - Die Wartungssysteme sollten beim Wartungszugriff über einen aktuellen Schadsoftwareschutz verfügen und mit allen aktuellen Sicherheitspatches versehen sein. |
Sichere Updateprozesse – Haupttechnologiebereiche
-keine Veränderungen-
<>Konfigurations- und Change-Management, Rollbackmöglichkeiten - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 12.1.2, | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.1.2, 12.5.1, 12.6.2, 12.9.1 ENR, 14.2.2, 14.2.9, |
| Gelöscht: ISO/IEC TR 27019:2013: 10.12.1, 12.4.1 | |
| Gelöscht: a) Das System muss mit einem Konfigurations- und | Hinzugefügt: a) Das System muss mit einem Konfigurations- und Change-Management entwickelt und betrieben werden. |
| Unverändert: b) Das System muss ein Rollback auf eine festgelegte Anzahl von Konfigurationszuständen unterstützen. | Unverändert: b) Das System muss ein Rollback auf eine festgelegte Anzahl von Konfigurationszuständen unterstützen. |
<>Konfigurations- und Change-Management, Rollbackmöglichkeiten - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Sind im Laufe des Systembetriebs nicht-triviale Konfigurations- oder Parametrierungsänderungen zu erwarten, sollte das System ein ausreichendes Konfigurations- und | Hinzugefügt: Sind im Laufe des Systembetriebs nicht-triviale Konfigurations- oder Parametrierungsänderungen zu erwarten, sollte das System ein ausreichendes Konfigurations- und Change-Management unterstützen. |
| Unverändert: Insbesondere sollte ein Rollback auf eine festzulegende Anzahl von vorhergehenden Konfigurationszuständen möglich sein. | Unverändert: Insbesondere sollte ein Rollback auf eine festzulegende Anzahl von vorhergehenden Konfigurationszuständen möglich sein. |
| Gelöscht: zu a) | |
| Gelöscht: Die entsprechenden Prozesse sollten vorgesehen werden. | Hinzugefügt: Die Anforderung gilt sowohl für den Auftragnehmer als auch für den Auftraggeber/Betreiber. Auf Betreiberseite sollten die für eine Konfigurations- und Change-Management notwendigen Prozesse definiert und realisiert werden. |
| Unverändert: zu b) | Unverändert: zu b) |
| Gelöscht: Eine Sicherung von mindestens einem älteren Datenstand (Parametrier-und | Hinzugefügt: Eine Sicherung von mindestens einem älteren Datenstand (Parametrier-und Firmware-Stand, Datenmodell, etc.), sowie eine Rollbackmöglichkeit sollten vorgesehen werden. Alle Änderungen sollten dokumentiert werden. |
<>Konfigurations- und Change-Management, Rollbackmöglichkeiten - 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: Eine | Hinzugefügt: Eine Rollback-Möglichkeit sollte auf Anwendungsebene für dynamische und statische Daten vorgesehen werden. Für Software- und Systemänderungen sollten alle Änderungen und Erweiterungen projektspezifisch verwaltet werden. |
| Unverändert: Übertragungstechnik/ Sprachkommunikation: - | Unverändert: Übertragungstechnik/ Sprachkommunikation: - |
| Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: | Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: |
| Gelöscht: Aufgrund des eingeschränkten Speicherausbaus der aktuellen Gerätetechnik sind Rollback-Möglichkeiten auf Ebene der Schutz- und Automatisierungskomponenten häufig noch nicht realisierbar. Die Sicherung von Parameter- und | Hinzugefügt: Aufgrund des eingeschränkten Speicherausbaus der aktuellen Gerätetechnik sind Rollback-Möglichkeiten auf Ebene der Schutz- und Automatisierungskomponenten häufig noch nicht realisierbar. Die Sicherung von Parameter- und Firmware-Ständen sollte aber über die Bedien- und Wartungsprogrammen der Geräte möglich sein. |
<>Behandlung von Sicherheitslücken - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 12.6.1, 16.1.2, 16.1.3 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.6.1, 16.1.2, 16.1.3 |
| Gelöscht: Der Auftragnehmer muss über einen dokumentierten Prozess verfügen, um Sicherheitslücken zu behandeln. Innerhalb dieses Prozesses | Hinzugefügt: Der Auftragnehmer muss über einen dokumentierten Prozess verfügen, um Sicherheitslücken zu behandeln. Innerhalb dieses Prozesses muss es allen Beteiligten, aber auch Außenstehenden möglich sein, tatsächliche oder potentielle Sicherheitslücken zu melden. Außerdem muss sich der Auftragnehmer über aktuelle Sicherheitsprobleme, die das System oder Teilkomponenten betreffen könnten, zeitnah informieren. |
| Gelöscht: Der Prozess definiert, wie und in welchem Zeitrahmen eine bekanntgewordene Lücke überprüft, klassifiziert, | Hinzugefügt: Der Prozess definiert, wie und in welchem Zeitrahmen eine bekanntgewordene Lücke überprüft, klassifiziert, behoben und an alle betroffenen Kunden mit entsprechenden Maßnahmenempfehlungen weitergemeldet wird. Wenn dem Auftragnehmer eine Sicherheitslücke bekannt wird, muss er den Auftraggeber unter der Maßgabe der Vertraulichkeit zeitnah informieren, auch wenn noch kein Patch zur Behebung des Problems zur Verfügung steht. |
<>Behandlung von Sicherheitslücken - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Die zu vereinbarenden Prozesse zum | Hinzugefügt: Die zu vereinbarenden Prozesse zum Schwachstellen-Management sollten u.a. festlegen, wie der Auftraggeber zeitnah über aktuelle Sicherheitsprobleme, die sein System oder Teilkomponenten betreffen könnten, informiert wird. |
| Hinzugefügt: Sofern ein Branchen-CERT existiert, sollte auch dieses in den Prozessen des Schwachstellen-Managements berücksichtigt werden. | |
| Hinzugefügt: Die Meldung und Information durch den Auftragnehmer zu Schwachstellen und Sicherheitslücken erfolgt i.d.R. als Dienstleistung, deren genauer Umfang individuell in einem Service- und Wartungsvertrag festgelegt wird. |
Behandlung von Sicherheitslücken – Haupttechnologiebereiche
-keine Veränderungen-
<>Backup: Konzept, Verfahren, Dokumentation, Tests - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 12.1.1, 12.3.1 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.1.1, 12.3.1 |
| Gelöscht: ISO/IEC TR 27019:2013: 10.1.1 | |
| Gelöscht: Es müssen dokumentierte Verfahren zur Datensicherung und -wiederherstellung der | Hinzugefügt: Es müssen dokumentierte und getestete Verfahren zur Datensicherung und -wiederherstellung der Einzelkomponenten bzw. des Gesamtsystems und der jeweiligen Konfigurationen existieren. Die Konfigurationsparameter von dezentralen Komponenten müssen zentral gesichert werden können. Die Dokumentation und die Verfahren müssen bei relevanten System-Updates angepasst und erneut getestet werden. |
<>Backup: Konzept, Verfahren, Dokumentation, Tests - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Die Datensicherung sollte alle relevanten Daten umfassen. Hierzu gehören z.B. statische Daten (Parameter, Applikations- und System-Konfigurationen), dynamische Daten (Handeingaben, Nachführungen, etc.). In der Regel werden Prozessdaten nicht im Rahmen der regelmäßigen Backups gesichert. | Unverändert: Die Datensicherung sollte alle relevanten Daten umfassen. Hierzu gehören z.B. statische Daten (Parameter, Applikations- und System-Konfigurationen), dynamische Daten (Handeingaben, Nachführungen, etc.). In der Regel werden Prozessdaten nicht im Rahmen der regelmäßigen Backups gesichert. |
| Unverändert: Unter Umständen können Archivdaten wie Langzeitarchive und die Systeminstallationen ebenfalls in die Datensicherung einbezogen werden. | Unverändert: Unter Umständen können Archivdaten wie Langzeitarchive und die Systeminstallationen ebenfalls in die Datensicherung einbezogen werden. |
| Unverändert: Der genaue Umfang der zu sichernden Daten sollte vom Auftraggeber definiert werden. | Unverändert: Der genaue Umfang der zu sichernden Daten sollte vom Auftraggeber definiert werden. |
| Unverändert: Es sollten maximale Sicherungs- und Rücksicherungszeiten definiert werden. | Unverändert: Es sollten maximale Sicherungs- und Rücksicherungszeiten definiert werden. |
| Unverändert: Die Sicherungsverfahren sollten dabei so konzipiert sein, dass die in der geplanten Systemlaufzeit zu erwartende Datenmenge in den definierten Zeiten gesichert und rückgesichert werden können. | Unverändert: Die Sicherungsverfahren sollten dabei so konzipiert sein, dass die in der geplanten Systemlaufzeit zu erwartende Datenmenge in den definierten Zeiten gesichert und rückgesichert werden können. |
| Hinzugefügt: Das Sicherungs-/Rücksicherungsverfahren sollte jederzeit für das Gesamtsystem konsistente Datenstände gewährleisten können. | |
| Gelöscht: Es sollten Mechanismen vorgesehen werden, mit denen die Vollständigkeit und Korrektheit einer Datensicherung | Hinzugefügt: Es sollten Mechanismen vorgesehen werden, mit denen die Vollständigkeit und Korrektheit einer Datensicherung gegen den aktuellen Datenbestand geprüft werden kann. |
| Hinzugefügt: Das Sicherungsverfahren sollte den Schutzbedarf der zu sichernden Daten berücksichtigen, z.B. durch Verwendung von Verschlüsselung. | |
| Hinzugefügt: Die Datensicherungs- und Rücksicherungsverfahren sollten ausführlich dokumentiert werden. | |
| Unverändert: Im Rahmen des Abnahmetests sollte eine vollständige Sicherung und Rücksicherung mit realistischen Datenmengen geprüft werden. | Unverändert: Im Rahmen des Abnahmetests sollte eine vollständige Sicherung und Rücksicherung mit realistischen Datenmengen geprüft werden. |
| Hinzugefügt: Die Tests sollten durch den Systembetreiber regelmäßig wiederholt werden. |
Backup: Konzept, Verfahren, Dokumentation, Tests – Haupttechnologiebereiche
-keine Veränderungen-
<>Notfallkonzeption und Wiederanlaufplanung - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 17.1.1, 17.2.1 |
| Gelöscht: Für relevante Notfall- und Krisenszenarien müssen vom Auftragnehmer dokumentierte | Hinzugefügt: Für relevante Notfall- und Krisenszenarien müssen vom Auftragnehmer dokumentierte und getestete Vorgehensweisen und Wiederanlaufpläne inklusive Angabe der Wiederherstellungszeiten zur Verfügung gestellt werden. Die Dokumentation und Verfahren müssen bei relevanten System-Updates angepasst und im Rahmen des Abnahmeverfahrens für Release-Wechsel erneut getestet werden. |
<>Notfallkonzeption und Wiederanlaufplanung - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Relevante Notfall- und Krisenszenarien sollten auf Seiten des Betreibers bzw. Auftraggebers im Rahmen eines bereichsübergreifenden | Hinzugefügt: Relevante Notfall- und Krisenszenarien sollten auf Seiten des Betreibers bzw. Auftraggebers im Rahmen eines bereichsübergreifenden Notfallmanagements identifiziert und bewertet werden. Hierbei sollte eine Klassifikation der Funktionen und Applikationen nach der Wichtigkeit der Geschäftsprozesse mit einem besonderen Augenmerk auf der gesicherten Betriebsführung in den Anlagen erfolgen. Für die identifizierten Szenarien sollten Notfallkonzepte und Wiederanlaufplanungen vorgesehen werden. Im Rahmen der Systemplanung, sind die in der Notfallplanung definierten maximalen Ausfall- und Wiederanlaufzeiten zu berücksichtigen. |
| Unverändert: Der Auftragnehmer sollte für die relevanten Szenarien die für Wiederanlauf und Notbetrieb notwendigen Mechanismen vorsehen und im Rahmen der Projekt- und Systemdokumentation die notwendigen Informationen zur Verfügung stellen. Eine genaue Dokumentation der Abläufe für den Notfall sollte vorliegen. | Unverändert: Der Auftragnehmer sollte für die relevanten Szenarien die für Wiederanlauf und Notbetrieb notwendigen Mechanismen vorsehen und im Rahmen der Projekt- und Systemdokumentation die notwendigen Informationen zur Verfügung stellen. Eine genaue Dokumentation der Abläufe für den Notfall sollte vorliegen. |
| Hinzugefügt: Werden Dienstleistungen des Auftragnehmers für Wiederanlauf und Notbetrieb benötigt, sollten diese vertraglich vereinbart werden. | |
| Unverändert: Sowohl der Notbetrieb als auch der Wiederanlauf aus relevanten Störszenarien sollten in der Abnahme als Testpunkte umfassend geprüft werden. Die Wiederherstellungszeiten sollten dabei ermittelt und mit den im Rahmen der Notfallplanung definierten Maximalzeiten abgeglichen werden. | Unverändert: Sowohl der Notbetrieb als auch der Wiederanlauf aus relevanten Störszenarien sollten in der Abnahme als Testpunkte umfassend geprüft werden. Die Wiederherstellungszeiten sollten dabei ermittelt und mit den im Rahmen der Notfallplanung definierten Maximalzeiten abgeglichen werden. |
| Unverändert: Eine in der System- bzw. Sicherheitsdokumentation hinterlegte Vorgehensweise zum Wiederaufsetzen des Gesamtsystems aus Einzelkomponenten unter Beachtung der ggf. notwendigen Rücksicherungen der Backups von Parametrier- und Betriebsdaten kann ggf. als ausreichend angesehen werden. Dies ist durch den Auftraggeber zu prüfen. | Unverändert: Eine in der System- bzw. Sicherheitsdokumentation hinterlegte Vorgehensweise zum Wiederaufsetzen des Gesamtsystems aus Einzelkomponenten unter Beachtung der ggf. notwendigen Rücksicherungen der Backups von Parametrier- und Betriebsdaten kann ggf. als ausreichend angesehen werden. Dies ist durch den Auftraggeber zu prüfen. |
| Hinzugefügt: Auf Betreiberseite sollten Wiederanlaufplanung und die Notfallkonzepte zyklische geprüft und ggf. angepasst werden. |
Notfallkonzeption und Wiederanlaufplanung – Haupttechnologiebereiche
-keine Veränderungen-
Auswirkungen auf Ihr ISMS
Die neuen Sicherheitsanforderungen in den Bereichen ‚Entwicklung‘, ‚Wartung‘ und ‚Datensicherung und Notfallplanung‘ betreffen im Wesentlichen den Auftragnehmer.
Auftragnehmerpflichten
Die neuen Sicherheitsanforderungen für den Auftragnehmer umfassen folgende Themen:
- Systementwicklung nach anerkannten Standards und Qualitätsmanagement/ -sicherungsprozessen unter Berücksichtigung von durch den Auftraggeber vordefinierten Entwicklungsschritten,
- Fern-Zugang mittels 2-Faktor-Authentifizierung,
- Verpflichtung zum Datenschutz und Geheimhaltung,
- Einhaltung der vom Auftraggeber definierten Mindestanforderungen an die internen Sicherheitsrichtlinien für Dienstleistungen,
- Einhaltung der gesetzlichen Vorgaben bei Tätigkeiten im Bereich kritischer Infrastrukturen,
- Namentliche Benennung des Wartungspersonals des Auftragnehmers bei Wartungszugriffen auf kritischen Systemen,
- Ermöglichung eines Rollback auf eine festzulegende Zahl an vorherigen Konfigurationszuständen.
Auftraggeberpflichten
Ihre neu hinzu gekommenen Pflichten als Auftraggeber und Betreiber beziehen sich auf:
- Ermöglichung eines Rollback auf eine festzulegende Zahl an vorherigen Konfigurationszuständen,
- vertragliche Vereinbarung von Dienstleistungen für Wiederanlauf und Notbetrieb, sofern diese benötigt werden.
- Prüfen Sie die neuen Auftragnehmerpflichten und überarbeiten Sie ggf. Ihre Vereinbarungen mit Dienstleistern der Bereiche Entwicklung, Wartung, Datenspeicherung und Notfallplanung.
Zusammenfassung und Ausblick
Mit Teil 6 der Beitragsserie BDEW Sicherheitsanforderungen: Was ist neu? hat xmera für Sie die letzten Kapitel des neuen BDEW/OE Whitepapers analysiert.
Dabei standen die Bereiche ‚Entwicklung‘, ‚Wartung‘ sowie ‚Datensicherung und Notfallplanung‘ im Fokus. Für diese Bereiche konnten vor allem für Auftragnehmer von Energieversorgungsnetzbetreibern neue Sicherheitsanforderungen identifiziert werden.
Für Sie als Auftraggeber und Betreiber hat dies zur Folge, dass Sie bestehende Vereinbarungen mit Dienstleistern überprüfen und sie bei Bedarf neu formulieren sollten.
Um Ihnen die Anpassung Ihres ISMS bezüglich des neuen BDEW/OE Whitepapers nochmals zu erleichtern, wird xmera exklusiv für Abonennten des xmera blogletters demnächst eine Zusammenfassung der Beitragsserie veröffentlichen.
Bekommen Sie schon unseren xmera blogletter? Nein? Dann melden sie sich für unserem kostenfreien Infoservice an!
