Beitragsserie Sicherheitsanforderungen

Teil 3 – BDEW Sicherheitsanforderungen 2018: Was ist neu?

Strommast

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.

In Teil 3 analysiert xmera die Abschnitte ‚Projektorganisation‘ und ‚Basissystem‘ des Kapitels Sicherheitsanforderungen.

Sie erfahren in diesem Beitrag welche zusätzlichen Maßnahmen Sie in Ihrem ISMS einpflegen sollten, um die Wirksamkeit von Sicherheits- und Abnahmetests, Systemhärtung und Schadsoftware-Schutz zu erhöhen.

Falls Sie in Ihrer zentralen Sekundärtechnik Virtualisierungstechnologien einsetzen, dann gibt es zudem noch eine Reihe neuer Sicherheitsanforderungen, die Sie berücksichtigen sollten.

Bevor es jedoch mit der Analyse losgeht, blicken wir gemeinsam auf die Erkenntnisse aus dem zweiten Teil der Serie zurück.

Der eilige Leser kann gerne direkt auf den Abschnitt seiner Wahl in diesem Beitrag springen.

Rückblick auf Teil 2

In Teil 2 der Beitragsserie zum neuen BDEW/OE Whitepaper wurde im Kapitel Sicherheitsanforderungen das erste Unterkapitel mit der Bezeichnung ‚Allgemeine Anforderungen‘ analysiert.

Wichtige Neuerungen gegenüber der Vorgängerversion des BDEW/OE Whitepapers beziehen sich auf die Themen Systemarchitekturentwicklung, Patch- und Updatemanagement, Support, Einsatz Kryptographischer Verfahren sowie die Nutzung von Cloud-Diensten.

Aus den Neuerungen ergibt sich eine Reihe von Aufgaben im Rahmen Ihres Informationssicherheitsmanagements. Dazu gehören beispielsweise:

  • Aufbau einer konsistenten bottom-up Vererbungslogik für den Schutzbedarf von Komponenten Ihrer Steuerungs- und Telekommunikationssysteme.
  • Die Überprüfung der Wartungs- und Serviceverträge für Ihre Systeme, Anwendungen und Komponenten.
  • Berücksichtigung der neuen Empfehlungen des BSI und der Mindestanforderungen aus der Normenreihe IEC 62351 sowie weitere Kriterien zum Einsatz Kryptographischer Verfahren.

Ausführlichere Informationen über die Auswirkungen des neuen BDEW/OE Whitepapers im Abschnitt ‚Allgemeine Anforderungen‘ können sie in Teil 2 – BDEW Sicherheitsanforderungen 2018: Was ist neu? nachlesen.

Funktionsweise des Textvergleichs

Bevor Sie sich den Vergleich der alten und neuen Kapitel ‚Projektorganisation‘ und ‚Basissystem‘ anschauen, empfehle ich zunächst die Funktionsweise des Textvergleiches in Teil 1 der Beitragsserie nachzuvollziehen.

Textvergleich: Projektorganisation

Unter Projektorganisation im Rahmen des BDEW/OE Whitepapers werden projektbezogene Anforderungen und Abläufe verstanden. Hierzu wurden Grundanforderungen und Mindestmaßnahmen bezüglich der Informationssicherheit formuliert.

Analyse der Unterkapitel

Das Kapitel ‚Projektorganisation‘ gab es in den Ausführungshinweisen Version 1.1 11/2014 nicht. Das neue BDEW/OE Whitepaper (Version 2.0 05/2018) fasst darunter die nachfolgenden Unterkapitel zusammen:

<>
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: - Hinzugefügt: Ansprechpartner
  Hinzugefügt: Sicherheits- und Abnahmetests
  Hinzugefügt: Sichere Datenspeicherung und Übertragung
  Hinzugefügt: Übergabe projektspezifischer Anpassungen

Das Unterkapitel ‚Ansprechpartner‘ war in der alten Version im Bereich ‚Allgemeine Anforderungen‘ integriert. Alle anderen Kapitelüberschriften sind neu.

Gibt es trotz neuer Kapitelüberschriften ähnliche Inhalte an einer anderen Stelle in den Ausführungshinweisen Version 1.1 11/2014, werden diese den vermeintlich neuen Kapiteln gegeübergestellt. Ein Verweis auf den Fundort findet sich zu Beginn der Tabellenspalte im Textvergleich.

Inwieweit sich hinter den neuen Bezeichnungen auch neue Inhalte verbergen, wird die nachfolgende Analyse aufzeigen.

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!

<>Ansprechpartner - 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: 6.1.1, 6.1.5, 15.1.2
Gelöscht: Der Auftragnehmer muss einen Ansprechpartner definieren, der während der Angebotsphase, der System-Entwicklung und während des geplanten Betriebszeitraumes für den  Bereich der IT-Sicherheit verantwortlich ist.  Hinzugefügt: Der Auftragnehmer muss einen Ansprechpartner definieren, der während der Angebotsphase, der System-Entwicklung und während des geplanten Betriebs- und  Wartungszeitraumes für den Bereich der IT-Sicherheit verantwortlich ist.
<>Ansprechpartner - Ergänzungen und Anmerkungen

-keine Veränderungen-

<>Sicherheits- und Abnahmetests - Sicherheitsanforderungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: 2.1.1.8 Interne/externe Sicherheits- und Anforderungstests und zugehörige Dokumentation  
Gelöscht: ISO/IEC 27002:2013: 14.2.7, 14.2.8, 14.2.9, 15.2.1  Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 14.2.7, 14.2.8, 14.2.9, 15.2.1
Gelöscht: Die einzelnen Systemkomponenten und die wesentlichen Funktionen des Gesamtsystems (in einer repräsentativen Konfiguration) müssen vor der Auslieferung vom Auftragnehmer durch eine vom Entwicklungsteam unabhängige Abteilung einem Sicherheits- und Stresstest unterzogen werden. Die Vorgehensweise ist mit dem Auftraggeber abzustimmen. Die Ergebnisse der Tests sowie die dazugehörige Dokumentation (Softwarestände, Prüfkonfiguration, etc.) werden dem Auftraggeber zur Verfügung gestellt.  Hinzugefügt: Die einzelnen Systemkomponenten und die wesentlichen Funktionen des Gesamtsystems müssen in einer repräsentativen Konfiguration vor der Auslieferung vom Auftragnehmer durch eine vom Entwicklungsteam unabhängige Organisationseinheit einem Sicherheits- und Stresstest unterzogen werden. Die Vorgehensweise ist mit dem Auftraggeber abzustimmen. Die Ergebnisse der Tests sowie die dazugehörige Dokumentation (Softwarestände, Prüfkonfiguration, etc.) werden dem Auftraggeber zur Verfügung gestellt.
Unverändert: Zusätzlich hat der Auftraggeber das Recht, diese Tests auch selbst vorzunehmen oder durch einen externen Dienstleister durchführen zu lassen. Unverändert: Zusätzlich hat der Auftraggeber das Recht, diese Tests auch selbst vorzunehmen oder durch einen externen Dienstleister durchführen zu lassen.
  Hinzugefügt: Art und Umfang der Abnahmetests werden durch den Auftraggeber festgelegt. Dem Auftraggeber bzw. dem von ihm Beauftragten ist für die Prüfungen ein Systemzugriff mit den technisch maximal möglichen Zugriffsrechten einzuräumen.
<>Sicherheits- und Abnahmetests - Ergänzungen und Anmerkungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: Bei der Übernahme bzw. Abnahme eines Systems sollte der Nachweis erbracht werden, dass ein umfangreicher Sicherheitstest durch den Lieferanten erfolgt ist. In der Auslieferungsdokumentation sollte die Dokumentation des Sicherheitstests in einer für eine Bewertung hinreichenden Detailtiefe enthalten sein.  Hinzugefügt: Bei der Übernahme bzw. Abnahme eines Systems sollte der Nachweis erbracht werden, dass ein umfangreicher Sicherheitstest durch den Auftragnehmer erfolgt ist. In der Auslieferungsdokumentation sollte die Dokumentation des Sicherheitstests in einer für eine Bewertung hinreichenden Detailtiefe enthalten sein.
  Hinzugefügt: Unabhängig von den Sicherheitsprüfungen durch den Auftragnehmer sollte der Auftraggeber im Rahmen von Abnahme- und Funktionsprüfungen eigene Sicherheitsprüfungen durchführen. Umfang und Testtiefe sollten dabei je nach Systemkomplexität und -kritikalität von einfachen Stichproben bis hin zu einer vollständigen Auditierung reichen. Entsprechende Sicherheitsprüfungen sollten auch während des Betriebszeitraums regelmäßig wiederholt werden.
  Hinzugefügt: Im Rahmen der Sicherheitsprüfung sollten die effektive und vollständige Umsetzung der vereinbarten Sicherheitsmaßnahmen geprüft werden und ggf. vorhandene oder in der aktuellen Konzeption nicht angemessen berücksichtigte Schwachstellen identifiziert werden.
Gelöscht: Bei Standardkomponenten ist im Regelfall eine Typprüfung pro Produktrelease ausreichend. Dabei ist aber zu berücksichtigen, dass die Grundparametrierung (z.B. aktive Netzwerkdienste und genutzte Protokolle) des Testsystems mit der Einsatzumgebung des Auftraggebers möglichst weitgehend übereinstimmen muss. Hierzu sollten die Einstellungen entsprechend eines Typprüfungsprotokolls bei der Inbetriebnahme überprüft werden.  Hinzugefügt: Bei Standardkomponenten ist im Regelfall eine Typprüfung pro Produktrelease ausreichend. Dabei ist aber zu berücksichtigen, dass die Grundparametrierung (z.B. aktive Netzwerkdienste und genutzte Protokolle) des Testsystems mit der Einsatzumgebung des Auftraggebers möglichst weitgehend übereinstimmt. Hierzu sollten bei der Inbetriebnahme die Einstellungen entsprechend eines Typprüfungsprotokolls überprüft werden.
Gelöscht: Im Rahmen von Abnahme- und Funktionsprüfungen sollten auch durch den Auftraggeber Sicherheitsprüfungen durchgeführt werden. Umfang und Testtiefe sollte dabei je nach Systemkomplexität und -kritikalität von einfachen Stichproben bis hin zu einem vollständigen Audit reichen.  
Gelöscht: Die Sicherheits- und Anforderungsprüfungen auf Seiten von Auftraggeber und Auftragnehmer sollten auch Last- und Stresstests beinhalten.  Hinzugefügt: Die Sicherheits- und Anforderungsprüfungen auf Seiten der Auftraggeber und Auftragnehmer sollten auch Last- und Stresstests beinhalten.
  Hinzugefügt: Im Rahmen der Sicherheits- und Abnahmetests sollte die Integrität des zu prüfenden Systems gegen ungewünschte Veränderungen sichergestellt werden. Gegebenenfalls ist eine Neuinstallation nach dem Test vorzusehen.
<>Sicherheits- und Abnahmetests – Haupttechnologiebereiche
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: Betriebsführungs- / Leitsysteme und Systembetrieb: Leitsysteme und zentrale Betriebsführungssysteme sind häufig angepasste Individualentwicklungen und sollten i.d.R. bei der Abnahme explizit durch ein vollständiges Audit überprüft werden.  Hinzugefügt: Betriebsführungs- / Leitsysteme und Systembetrieb: Leitsysteme und zentrale Betriebsführungssysteme sind häufig angepasste Individualentwicklungen und sollten i.d.R. bei der Abnahme explizit durch eine vollständige Auditierung überprüft werden.
Unverändert: Übertragungstechnik / Sprachkommunikation: Im Rahmen der Sicherheitstests sollten sowohl Netzelemente und Endgeräte als auch zentrale Server, Management- und  Überwachungssysteme berücksichtigt werden. Für Netzelemente und Endgeräte sind i.d.R. einmalige Sicherheitstests im Rahmen eines Typtests ausreichend. Unverändert: Übertragungstechnik / Sprachkommunikation: Im Rahmen der Sicherheitstests sollten sowohl Netzelemente und Endgeräte als auch zentrale Server, Management- und  Überwachungssysteme berücksichtigt werden. Für Netzelemente und Endgeräte sind i.d.R. einmalige Sicherheitstests im Rahmen eines Typtests ausreichend.
Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: In der Regel ist ein einmaliger Test im Rahmen des Typtests für Sekundär-,  Automatisierungs- und Fernwirkkomponenten als ausreichend anzusehen, der ggf. nach signifikanten Änderungen wiederholt werden sollte. Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: In der Regel ist ein einmaliger Test im Rahmen des Typtests für Sekundär-,  Automatisierungs- und Fernwirkkomponenten als ausreichend anzusehen, der ggf. nach signifikanten Änderungen wiederholt werden sollte.
Gelöscht: Bei Klein-Leitsystemen, z.B. im Stationsbereich sollte geprüft werden, ob individuelle Anpassungen eine Abnahmeprüfung notwendig machen oder ob hier eine Typprüfung ausreichend ist.  Hinzugefügt: Bei Klein-Leitsystemen, z.B. im Stationsbereich, sollte geprüft werden, ob individuelle Anpassungen eine Abnahmeprüfung notwendig machen oder ob hier eine Typprüfung ausreichend ist.
<>Sichere Datenspeicherung und Übertragung - Sicherheitsanforderungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: 2.5.2 Sichere Datenhaltung und Übertragung  
Gelöscht: ISO/IEC 27002:2013: 13.2.4, 13.2.2, 8.3.3, 13.2.3, 6.2.1, 10.1.1, 14.3.1  Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 6.2.1, 8.3.3, 10.1.1, 13.2.2, 13.2.3, 13.2.4, 14.3.1
Gelöscht: Sensible Daten des Auftraggebers, die im Entwicklungs- und Wartungsprozess benötigt werden oder anfallen, dürfen über ungeschützte Verbindungen nur verschlüsselt übertragen werden. Gegebenenfalls, z. B. bei der Nutzung auf mobilen Systemen, dürfen solche Daten auch nur verschlüsselt gespeichert werden. Das betrifft z. B. interne Informationen und Dokumente des Auftraggebers, aber auch Protokolldateien, Fehleranalysen und relevante Systemdokumentation.  Hinzugefügt: Vertrauliche Daten des Auftraggebers, die im Entwicklungs- und Wartungsprozess benötigt werden oder anfallen, dürfen über ungeschützte Verbindungen nur verschlüsselt übertragen werden. Bei einer Speicherung auf mobilen Datenträgern oder Systemen dürfen solche Daten nur verschlüsselt gespeichert werden.
Gelöscht: Die Menge und die Dauer der Aufbewahrung der gespeicherten Daten muss auf das notwendige Minimum beschränkt sein.  Hinzugefügt: Die Menge und die Dauer der Aufbewahrung der gespeicherten Daten müssen auf ein vertraglich festzulegendes Minimum beschränkt sein.
<>Sichere Datenspeicherung und Übertragung - Ergänzungen und Anmerkungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: Alle Informationen und Daten des Auftraggebers, die dem Auftragnehmer im Rahmen seiner Tätigkeit bekannt werden bzw. anfallen, sollten zunächst als vertraulich behandelt  werden, bis sie vom Auftraggeber anderweitig klassifiziert worden sind. Hiervon sollten nur offensichtlich nicht vertrauliche Informationen ausgenommen sein. In Zweifelsfällen sollte der Auftragnehmer eine Klassifizierung durch den Auftraggeber anzufordern.  Hinzugefügt: Alle Informationen und Daten des Auftraggebers, die dem Auftragnehmer im Rahmen seiner Tätigkeit bekannt werden bzw. anfallen, sollten zunächst als vertraulich bzw. projektintern behandelt werden, bis sie vom Auftraggeber anderweitig klassifiziert worden sind. Hiervon sollten nur offensichtlich nicht vertrauliche Informationen ausgenommen sein. In Zweifelsfällen sollte der Auftragnehmer eine Klassifizierung durch den Auftraggeber anfordern.
Gelöscht: Vertrauliche und sicherheitsrelevante Projektinformationen sollten generell verschlüsselt übertragen werden.  
  Hinzugefügt: Das betrifft z.B. interne Informationen und Dokumente des Auftraggebers, aber auch Protokolldateien, Fehleranalysen und relevante Systemdokumentation.
Gelöscht: Es sollten vertragliche Regelungen getroffen werden, nach denen der Verlust von Daten oder Datenträgern bzw. missbräuchliche Verwendung oder missbräuchlicher Zugriff umgehend dem Auftraggeber/ Betreiber zu melden ist.  Hinzugefügt: Es sollten vertragliche Regelungen getroffen werden, nach denen der Verlust von Daten oder Datenträgern bzw. die missbräuchliche Verwendung oder der missbräuchliche Zugriff umgehend dem Auftraggeber/ Betreiber zu melden ist.
Gelöscht: Das „notwendige Minimum“ der Datenspeicherung sowie die Art der Datenhaltung und Übertragung sollte in einer Vereinbarung zwischen Auftraggeber/Betreiber und Auftragnehmer geregelt werden.  Hinzugefügt: Die als vertraulich bzw. projektintern anzusehenden Daten, das „notwendige Minimum“ der Datenspeicherung sowie die Art der Datenhaltung und Übertragung sollte in einer Vereinbarung zwischen Auftraggeber/Betreiber und Auftragnehmer geregelt werden.
<>Übergabe projektspezifischer Anpassungen - Sicherheitsanforderungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: 2.5.7 Sourcecode-Hinterlegung  
Gelöscht: ISO/IEC 27002:2013: 14.2.7  Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 14.2.7
Gelöscht: Bei Bedarf ist die Hinterlegung des Quellcodes und der entsprechenden Dokumentation bei einem Treuhänder zu vereinbaren, um beispielsweise im Falle einer Insolvenz des  Auftragnehmers sicherheitskritische Updates zu ermöglichen. Hinzugefügt: Bei Individualprojekten und bei projekt- bzw. kundenspezifischen Erweiterungen, Anpassungen und Engineering-Dienstleistungen müssen alle projektspezifischen  Parametrierungen, Änderungen und Anpassungen dem Auftraggeber vollständig und umfassend dokumentiert ausgehändigt werden.
<>Übergabe projektspezifischer Anpassungen - Ergänzungen und Anmerkungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
  Hinzugefügt: Gegebenenfalls sollte die Hinterlegung des Quellcodes und der entsprechenden Dokumentation bei einem Treuhänder vereinbart werden, um beispielsweise im Falle einer Insolvenz des Auftragnehmers sicherheitskritische Updates zu ermöglichen.
  Hinzugefügt: Wird hierbei seitens des Auftragnehmers einer Sourcecode-Hinterlegung nicht zugestimmt, sollte ein Service-Vertrag abgeschlossen werden, der zum Inhalt hat, dass ein separates Referenzsystem mit dem gesamten Sourcecode beim Auftragnehmer vorgehalten wird.
Gelöscht: Die Umsetzung dieser Sicherheitsanforderung ist insbesondere im Rahmen von Individualprojekten und bei projekt- bzw. kundenspezifischen Erweiterungen und Anpassungen sinnvoll. Hinzugefügt: Die entsprechenden Regelungen sollten in den Liefer- bzw. Service- und Wartungsverträgen berücksichtigt werden.
Gelöscht: Wird hierbei seitens des Lieferanten einer Sourcecode-Hinterlegung nicht zugestimmt, sollte ein Service-Vertrag abgeschlossen werden, der zum Inhalt hat, dass ein separates Referenzsystem mit dem gesamten Sourcecode beim Lieferanten vorgehalten wird.   
Gelöscht: Generell sollten projektspezifische Parametrierungen, Änderungen und Anpassungen dem Auftraggeber vollständig und umfassend dokumentiert ausgehändigt werden.  
<>Grundsicherung und Systemhärtung - Haupttechnologiebereiche
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: Betriebsführungs-/ Leitsysteme und Systembetrieb:  -  Hinzugefügt: Betriebsführungs-/ Leitsysteme und Systembetrieb: Für relevante Systeme der Betriebsführung sind Sicherheitstest i.d.R. jährlich durchzuführen.
Unverändert: Übertragungstechnik / Sprachkommunikation: - Unverändert: Übertragungstechnik / Sprachkommunikation: -
Gelöscht: Sekundär-, Automatisierungs- und Fernwirktechnik: Auf prozessnahen Komponenten wie Steuerungen, SPSen und Automatisierungskomponenten oder Gateways sollten  insbesondere alle nicht für den Betrieb notwendigen Kommunikationsdienste und Parametrierzugänge deaktiviert werden. Ggf. vorhandene Standardpasswörter sollten auf sichere Werte gesetzt werden sowie sicherheitserhöhender Konfigurationsoptionen aktiviert werden.  Hinzugefügt: Sekundär-, Automatisierungs- und Fernwirktechnik: Auf prozessnahen Komponenten wie Steuerungen, SPSen und Automatisierungskomponenten oder Gateways sollten  insbesondere alle nicht für den Betrieb notwendigen Kommunikationsdienste und Parametrierzugänge deaktiviert werden. Ggf. vorhandene Standardpasswörter sollten auf sichere Werte gesetzt sowie sicherheitserhöhende Konfigurationsoptionen aktiviert werden.
Gelöscht: Organisatorische Anmerkungen: Die Systemhärtung sollte im Rahmen regelmäßig (i.d.R. jährlich) durchzuführender Sicherheitstests überprüft und ggf. angepasst werden. Die Überprüfung sollte dabei im Regelfall von vom Hersteller unabhängigen Prüfern durchgeführt werden.  
  Hinzugefügt: Organisatorische Anmerkungen: -

Textvergleich: Basissystem

Zum Basissystem gehören Firmware, Betriebssystem und Middleware-Systeme. Die Sicherheitsanforderungen an das Basissystem beschreibt dieses Kapitel.

Analyse der Unterkapitel

<>
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Unverändert: Grundsicherung und Systemhärtung Unverändert: Grundsicherung und Systemhärtung
Gelöscht: Antiviren-Software Hinzugefügt: Schadsoftware-Schutz
Unverändert: Autonome Benutzerauthentifizierung Unverändert: Autonome Benutzerauthentifizierung
  Hinzugefügt: Virtualisierungstechnologien

Die Möglichkeiten zur Virtualisierung in der IT haben deutlich zugenommen.  Da das Thema längst nicht mehr nur ein Trend ist, werden die Sicherheitsanforderungen an den Einsatz von Virtualisierungstechnologien erstmals im neuen BDEW/OE Whitepaper beschrieben.

<>Grundsicherung und Systemhärtung - Sicherheitsanforderungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: 2.2.1 Grundsicherung und Systemhärtung  
Gelöscht: ISO/IEC 27002:2013: 9.4.4, 12.6.2, 13.1.2, 14.2.4  Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.4.4, 12.6.2, 13.1.2, 14.2.4, 14.2.10 ENR
Gelöscht: Alle Komponenten des Basissystems müssen anhand anerkannter Best-Practice-Guides dauerhaft gehärtet und mit aktuellen Service-Packs und Sicherheits-Patches versehen sein. Ist dieses technisch nicht durchführbar, ist für die Übergangsphase (bis zur vollständigen Erfüllung der Forderung aus 2.1.1.3) eine dokumentierte entsprechende Sicherheitsmaßnahme zu ergreifen. Unnötige Benutzer, Defaultuser, Programme, Netzwerkprotokolle, Dienste und Services sind deinstalliert, oder – falls eine Deinstallation nicht möglich ist – dauerhaft deaktiviert und gegen versehentliches Reaktivieren geschützt. Die sichere Grundkonfiguration der Systeme muss überprüft und dokumentiert sein.  Insbesondere müssen die in diesem Dokument geforderten Maßnahmen, die zur Härtung der Systeme beitragen, durchgeführt sein.  Hinzugefügt: Alle Komponenten des Basissystems müssen anhand anerkannter Best-Practice-Guides dauerhaft gehärtet und mit aktuellen Service-Packs und Sicherheits-Patches versehen sein. Unnötige Benutzer, Default User, Programme, Netzwerkprotokolle, Dienste und Services müssen deinstalliert, oder – falls eine Deinstallation nicht möglich ist – dauerhaft deaktiviert und gegen versehentliches Reaktivieren geschützt werden. Die sichere Grundkonfiguration des Gesamtsystems muss überprüft und dokumentiert sein.
<>Grundsicherung und Systemhärtung - Ergänzungen und Anmerkungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: Alle Standard-Komponenten (Betriebssystem und ggf. eingesetzte Datenbanksysteme und Serverdienste) sollten nach anerkannten Vorgaben gehärtet werden.  Hinzugefügt: Alle Standard-Komponenten (Betriebssystem, Firmware und ggf. eingesetzte Datenbanksysteme und Serverdienste) sollten nach anerkannten Vorgaben gehärtet werden.
Gelöscht: Zu den anzuwenden Härtungsmaßnahmen zählen u.a.  Hinzugefügt: Zu den anzuwenden Härtungsmaßnahmen zählen u.a.:
Gelöscht: - Deinstallation oder Deaktivierung unnötiger Softwarekomponenten  Hinzugefügt: - Deinstallation oder Deaktivierung nicht benötigter Softwarekomponenten und Funktionen
Gelöscht: - Deaktivierung unnötiger System- und Kommunikationsdienste  Hinzugefügt: - Deaktivierung unsicherer bzw. nicht benötigter System- und Kommunikationsdienste
Gelöscht: - Deaktivierung unnötiger Standardnutzer  
  Hinzugefügt: - Deaktivierung bzw. Löschung nicht benötigter Standardnutzer
Gelöscht: - Änderung von Standardpassworten Hinzugefügt: - Änderung aller Standardpassworte
  Hinzugefügt: - Löschung von Installations- und temporären Dateien
Unverändert: - Aktivierung sicherheitserhöhender Konfigurationsoptionen Unverändert: - Aktivierung sicherheitserhöhender Konfigurationsoptionen
Gelöscht: - Einschränkung der Rechte von Nutzern und Programmen  Hinzugefügt: - Einschränkung der Rechte von Nutzern und Programmen auf das notwendige Minimum
Gelöscht: - Deaktivierung unnötiger Kommunikations- und Datenträgerschnittstellen (CD/DVD, USB, Bluetooth, WLAN, usw.)  Hinzugefügt: - Deaktivierung nicht benötigter Kommunikations- und Datenträgerschnittstellen (CD/DVD, USB, Bluetooth, WLAN, usw.)
Unverändert: - Deaktivierung nicht benutzter Switch-Ports Unverändert: - Deaktivierung nicht benutzter Switch-Ports
  Hinzugefügt: - Aktivierung von Application-Whitelisting
Gelöscht: Eine Sammlung von Best-Practice Härtungsguides für verschiedene Betriebssysteme, Serverdienste und Standardanwendungen findet sich z.B. beim Center for Internet Security (http://www.cisecurity.org) oder bei den jeweiligen System- bzw. Softwareherstellern. Können gewisse Standardmaßnahmen aus technischen Gründen nicht angewandt werden, sollte dies durch den Auftragnehmer explizit begründet werden, z.B. im Rahmen der Pflichtenheftphase.  Hinzugefügt: Eine Sammlung von Best-Practice Härtungs-Guides für verschiedene Betriebssysteme, Serverdienste und Standardanwendungen findet sich z.B. beim Center for Internet Security (http://www.cisecurity.org) oder bei den jeweiligen System- bzw. Softwareherstellern. Können gewisse Standardmaßnahmen aus technischen Gründen nicht angewandt werden, sollte dies durch den Auftragnehmer explizit begründet werden, z.B. im Rahmen der Pflichtenheftphase.
Unverändert: Benötigen die Anwendungsnutzer keinen Zugriff auf das Betriebssystem, sollte ein solcher Zugriff wirksam verhindert werden. Ist ein Betriebssystemzugriff notwendig, sollte dieser für einen Standardanwender nur mit eingeschränkten Nutzerrechten erfolgen. Insbesondere ist hierbei eine unberechtigte Manipulation des Betriebssystems, der Anwendungsprogramme und Anwendungsdaten sowie der Anwendungskonfiguration und der Projektierungsdaten wirksam zu verhindern. Bei der Implementierung des Zugriffschutzes ist insbesondere darauf zu achten, dass dieser nicht durch das Starten von Hilfsanwendungen wie Web- und Hilfebrowsern, Dateibetrachtern o.ä. umgangen werden kann. Unverändert: Benötigen die Anwendungsnutzer keinen Zugriff auf das Betriebssystem, sollte ein solcher Zugriff wirksam verhindert werden. Ist ein Betriebssystemzugriff notwendig, sollte dieser für einen Standardanwender nur mit eingeschränkten Nutzerrechten erfolgen. Insbesondere ist hierbei eine unberechtigte Manipulation des Betriebssystems, der Anwendungsprogramme und Anwendungsdaten sowie der Anwendungskonfiguration und der Projektierungsdaten wirksam zu verhindern. Bei der Implementierung des Zugriffschutzes ist insbesondere darauf zu achten, dass dieser nicht durch das Starten von Hilfsanwendungen wie Web- und Hilfebrowsern, Dateibetrachtern o.ä. umgangen werden kann.
Unverändert: Wird vom Auftragnehmer nur ein Teil der Komponenten des Gesamtsystems geliefert, sollte von ihm beschrieben werden, wie die weiteren Teilkomponenten (z.B. Betriebssystem oder Datenbanksysteme) auf Basis anerkannter Best-Practice-Guides gehärtet werden können, ohne dass die Funktion der vom Auftragnehmer gelieferten Systemkomponenten und des Gesamtsystems beeinträchtigt wird. Unverändert: Wird vom Auftragnehmer nur ein Teil der Komponenten des Gesamtsystems geliefert, sollte von ihm beschrieben werden, wie die weiteren Teilkomponenten (z.B. Betriebssystem oder Datenbanksysteme) auf Basis anerkannter Best-Practice-Guides gehärtet werden können, ohne dass die Funktion der vom Auftragnehmer gelieferten Systemkomponenten und des Gesamtsystems beeinträchtigt wird.
Gelöscht: Die Grundkonfiguration und die Härtungsmaßnahmen sollten geprüft und in der Sicherheitsdokumentation aufgeführt werden (z.B. installierte Programme und Anwendungen, aktive bzw. deaktivierte Dienste und Ports, Dateifreigaben, Einstellungen zur Systemkonfiguration etc.).  Hinzugefügt: Die Grundkonfiguration und die Härtungsmaßnahmen sollten geprüft und in der Sicherheitsdokumentation aufgeführt werden (z.B. installierte Programme und Anwendungen, aktive bzw. deaktivierte Dienste und Ports, Dateifreigaben, Einstellungen zur Systemkonfiguration etc.). Die sichere Grundkonfiguration sollte nach Möglichkeit automatisiert verifizierbar sein.
  Hinzugefügt: Die Systemhärtung sollte entsprechend einer Risikobewertung im Rahmen regelmäßig durchzuführender Sicherheitstests überprüft und bei Bedarf in Abstimmung mit dem Auftragnehmer angepasst werden. Die Überprüfung sollte dabei im Regelfall von vom Auftragnehmer unabhängigen Prüfern durchgeführt werden.
<>Schadsoftware-Schutz - Sicherheitsanforderungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: ISO/IEC 27002:2013: 12.2.11 ISO/IEC TR 27019:2013: 10.4.1  Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.2.1
Gelöscht: Alle vernetzten, IP-basierenden Systeme müssen an geeigneter Stelle mit Antiviren-Software und Malware-Schutz versehen sein. Alternativ zum Einsatz von Antiviren-Scannern auf allen Systemen ist vom Lieferanten ein umfassendes Antiviren-Konzept vorzulegen, das einen gleichwertigen Schutz bietet.  Hinzugefügt: Alle vernetzten Systeme müssen an geeigneter Stelle mit einem Schadsoftware-Schutz versehen sein. Alternativ zum Einsatz eines Schadsoftware-Schutzes auf allen  Systemkomponenten ist vom Auftragnehmer ein umfassendes Schadsoftware-Schutzkonzept vorzulegen, das einen gleichwertigen Schutz bietet.
Gelöscht: Für eine automatische und zeitnahe Aktualisierung der Antiviren-Pattern-Dateien muss gesorgt sein, wobei keine direkte Verbindung mit Updateservern in externen Netzen, wie dem Internet benutzt werden darf. Eine  Realisierungsmöglichkeit wäre zum Beispiel die Verwendung eines internen Updateservers. Der Zeitpunkt der Aktualisierung auf den Endsystemen ist konfigurierbar. Als Alternative zur automatischen Aktualisierung ist ein sicherer Prozess zu definieren und zu dokumentieren, bei dem die Updates regelmäßig und zeitnah manuell in das System eingespielt werden.  
  Hinzugefügt: Sofern eine Pattern-basierte Lösung eingesetzt werden soll, muss eine automatische und zeitnahe Aktualisierung der Pattern-Dateien möglich sein. Dabei darf keine direkte Verbindung mit Updateservern in externen Netzen wie dem Internet benutzt werden. Der Zeitpunkt der Aktualisierung auf den Endsystemen muss konfigurierbar sein.
<>Schadsoftware-Schutz - Ergänzungen und Anmerkungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: Es sollten technische und organisatorische Schutzmaßnahmen im System und an den Schnittstellen vorgesehen werden, durch die ein dauerhaft effektiver Schutz gegen Schadsoftwarebefall bei einer gleichzeitig hohen Systemverfügbarkeit sichergestellt werden kann. Der Schnittstellenschutz umfasst insbesondere auch die logischen und technischen Schnittstellen zum Datenaustausch mit externen Netzen wie der Büroumgebung, die Schnittstellen für Fernzugriff, Fernwartung und Prozessankopplung sowie alle stationären und mobilen Arbeitsplätze, Parametriernotebooks und Programmiergeräte.  Hinzugefügt: Es sollten technische und organisatorische Schutzmaßnahmen im System und an den Schnittstellen vorgesehen werden, durch die ein dauerhaft effektiver Schutz gegen Schadsoftwarebefall bei einer gleichzeitig hohen Systemverfügbarkeit sichergestellt werden kann. Der Schnittstellenschutz umfasst insbesondere auch die logischen und technischen Schnittstellen zum Datenaustausch mit externen Netzen wie der Büro-IT, Schnittstellen für Fernzugriff, Fernwartung und Prozessankopplung sowie alle stationären und mobilen Arbeitsplätze, Parametriernotebooks und Programmiergeräte.
Gelöscht: Die Möglichkeit zur Installation und zum Betrieb eines Schadsoftwareschutzes („Antiviren-Software“) sollte prinzipiell für alle Systeme gegeben sein, für die entsprechende Schutzsoftware am Markt verfügbar ist. Für alle anderen Systeme, insbesondere für Komponenten, bei denen industrielle Embedded-Systeme eingesetzt werden, sollten abgesicherte Schnittstellen, die die Gefahr eines Schadsoftwarebefalls oder von durch Schadsoftware induzierten Störungen reduzieren, oder gleichwertige Alternativmaßnahmen vorgesehen werden.  Hinzugefügt: Die Möglichkeit zur Installation und zum Betrieb eines Schadsoftwareschutzes sollte prinzipiell für alle Systeme gegeben sein, für die entsprechende Schutzsoftware am Markt verfügbar ist. Für alle anderen Systeme insbesondere für Komponenten, bei denen industrielle Embedded- Systeme eingesetzt werden sollten abgesicherte Schnittstellen, welche die Gefahr eines Schadsoftwarebefalls oder von durch Schadsoftware induzierten Störungen reduzieren, oder gleichwertige Alternativmaßnahmen vorgesehen werden.
Gelöscht: Der Einsatz von bereits im Unternehmen vorhandenen Antivirus- Produkten ist häufig sinnvoll. Allerdings kann bei erhöhtem Schutzbedarf der Einsatz anderer oder ergänzender Produkte notwendig sein.  Hinzugefügt: Der Einsatz von bereits im Unternehmen vorhandenen Schadsoftwareschutz- Produkten ist häufig sinnvoll. Allerdings kann bei erhöhtem Schutzbedarf der Einsatz anderer oder ergänzender Produkte notwendig sein.
  Hinzugefügt: Der Schadsoftwareschutz sollte nicht nur Datenträgerzugriffe, sondern auch den Arbeitsspeicher überwachen.
Gelöscht: Für patternbasierte Schutzsoftware sollte das vorgesehene Konzept für Patternupdates geprüft werden. Falls hier Freigaben und Tests notwendig sind, müssen die realisierbaren Fristen und Zyklen so gewählt sein, dass ein dauerhaft effektives Schutzniveau gewährleistet werden kann. Die Verwendung dedizierter zentraler, prozessnetzinterner Updateserver sollte angestrebt werden.  Hinzugefügt: Für pattern-basierte Schutzsoftware sollte das vorgesehene Konzept für Pattern-Updates geprüft werden. Falls hier Freigaben und Tests notwendig sind, müssen die realisierbaren Fristen und Zyklen so gewählt sein, dass ein dauerhaft effektives Schutzniveau gewährleistet werden kann. Die Verwendung dedizierter zentraler, prozessnetzinterner Update-Server sollte angestrebt werden.
  Hinzugefügt: Dort, wo keine pattern-basierte Schutzsoftware eingesetzt werden kann, sollte die Verwendung von sog. Whitelisting-Lösungen geprüft werden. Dort, wo diese zum Einsatz kommen sollen, ist sicherzustellen, dass mit der vorgesehenen Technik und Konfiguration ein hinreichend hohes Schutzniveau erreicht werden kann.
  Hinzugefügt: Der Auftragnehmer sollte die zum Einsatz freigegebenen Schutzprogramme und die ggf. notwendigen Konfigurationsoptionen spezifizieren, z.B. Ausschluss von bestimmten Verzeichnissen, Nutzung bestimmter Scan-Arten, Konfiguration der Whitelisting-Anwendungen. Bei der Inbetriebnahme des Basissystems sollte seitens des Auftragnehmers die Kompatibilität der Schutzsoftware mit dem Gesamtsystem explizit geprüft werden.
  Hinzugefügt: Alle vom Auftragnehmer gelieferten Systeme und Datenträger sollten vor der Auslieferung bzw. Übergabe einer Untersuchung auf Schadsoftwarebefall unterzogen werden. Bevorzugt sollten dabei Rechnersysteme durch einen Offline-Scan mit einem von einem externen Medium gebooteten Betriebssystem geprüft werden.
Gelöscht: Falls sog. Whitelisting-Lösungen genutzt werden sollen, ist sicherzustellen, dass mit der vorgesehen Technik und Konfiguration ein hinreichend hohes Schutzniveau erreicht werden kann. Hinzugefügt: In der Notfallkonzeption sollten auch Szenarien berücksichtigt werden, bei denen es auf Grund von Fehl-Erkennungen oder Fehlkonfigurationen des Schadsoftwareschutzes zu Systemausfällen kommt.
Gelöscht: Der Auftragnehmer sollte die zum Einsatz freigegebenen Schutzprogramme und die ggf. notwendigen Konfigurationsoptionen spezifizieren, z.B. Ausschluss von bestimmten Verzeichnissen, Nutzung bestimmter Scan-Arten, Konfiguration der Whitelisting-Anwendungen. Bei der Inbetriebnahme des Basissystems sollte seitens des Lieferanten die Kompatibilität der Schutzsoftware mit der Lieferantensoftware explizit geprüft werden.   
Gelöscht: Alle vom Auftraggeber gelieferten Systeme und Datenträger sollten vor der Auslieferung bzw. Übergabe einer Untersuchung auf Schadsoftwarebefall unterzogen werden. Bevorzugt sollten dabei Rechnersysteme durch einen Offline-Scan mit einem von einem externen Medium gebooteten Betriebssystem geprüft werden.   
<>Schadsoftware-Schutz - Haupttechnologiebereiche
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: Betriebsführungs- / Leitsysteme und Systembetrieb: s.o.  Hinzugefügt: Betriebsführungs- / Leitsysteme und Systembetrieb:  -
Gelöscht: Übertragungstechnik / Sprachkommunikation: Derzeit ist der Einsatz von Antivirus-Software auf Netzwerkkomponenten wie Switches, Router oder Netzelementen i.d.R. nicht möglich. Die Installation von Schutzsoftware sollte aber insbesondere auf Management- und Überwachungssystemen sowie auf Konfigurations- und Wartungsgeräten vorgesehen werden.  Hinzugefügt: Übertragungstechnik / Sprachkommunikation: Derzeit ist der Einsatz von Schadsoftwareschutz-Software auf Netzwerkkomponenten wie Switches, Router oder Netzelementen i.d.R. nicht möglich. Die Installation von Schutzsoftware sollte aber insbesondere auf Management- und Überwachungssystemen sowie auf Konfigurations- und Wartungsgeräten vorgesehen werden.
Gelöscht: Sekundär-, Automatisierungs- und Fernwirktechnik: Im Stations- und Automatisierungsumfeld betrifft die Anforderung insbesondere Stationsbedienplätze, Kleinleitsysteme, Nahsteuerungen, Feldanzeigen, Wartungsgeräte, usw. Der Einsatz von Antivirus- Software auf Automatisierungskomponenten ist derzeit i.d.R. nicht möglich.  Hinzugefügt: Sekundär-, Automatisierungs- und Fernwirktechnik: Im Stations- und Automatisierungsumfeld betrifft die Anforderung insbesondere Stationsbedienplätze, Kleinleitsysteme, Nahsteuerungen, Feldanzeigen, Wartungsgeräte, usw. Der Einsatz von Schadsoftwareschutz- Software auf Automatisierungskomponenten ist derzeit i.d.R. nicht möglich.
Unverändert: Eine Möglichkeit zur Einbindung in eine zentralisierte Lösung, insbesondere mit Hinblick auf die Problematik von Update-Prozessen innerhalb der i.d.R. dezentral aufgebauten Stationsumgebungen, sollte angestrebt werden. Unverändert: Eine Möglichkeit zur Einbindung in eine zentralisierte Lösung, insbesondere mit Hinblick auf die Problematik von Update-Prozessen innerhalb der i.d.R. dezentral aufgebauten Stationsumgebungen, sollte angestrebt werden.
<>Autonome Benutzerauthentifizierung - Sicherheitsanforderungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: ISO/IEC 27002:2013: 9.2.1, 9.2.2, 9.4.2  Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.2.1, 9.2.2, 9.4.2
Gelöscht: Die zur Nutzeridentifizierung und -authentifizierung auf Betriebssystemebene nötigen Daten dürfen nicht ausschließlich von außerhalb des Prozessnetzes bezogen werden. Die Anbindung an einen zentralen, prozessnetz-internen Directory Service sollte in Betracht gezogen werden.  Hinzugefügt: Die zur Nutzeridentifizierung und -authentifizierung notwendigen Daten dürfen nicht ausschließlich von außerhalb des Prozessnetzes bezogen werden.
<>Autonome Benutzerauthentifizierung - Ergänzungen und Anmerkungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
  Hinzugefügt: Die Anforderung umfasst alle Arten der Nutzeridentifizierung und -authentifizierung, z.B. auf Betriebssystem- und Anwendungsebene.
Gelöscht: Die Integration der Basissystemkomponenten in einen zentralen Directory-Service ist anzustreben, wobei dies mit prozessnetz-internen Directory-Servern realisiert werden sollte. Dabei kann ein eigener Directory-Service aufgebaut werden oder die Integration in einen bestehenden Directory-Service erfolgen. Hierbei ist auf eine Struktur zu achten, die das Schutzniveau des Prozessnetzes nicht herabsetzt und auch keine Abhängigkeiten zu Diensten außerhalb des Prozessnetzes schafft. Bei der Nutzung einer zentralen Benutzerverwaltung sollten lokale Notfallpassworte für den Fall einer Störung des Benutzerverwaltungsdienstes vorgesehen werden.  Hinzugefügt: Die Integration der Basissystemkomponenten in einen zentralen Directory-Dienst ist anzustreben, wobei dies mit prozessnetz-internen Directory-Servern realisiert werden sollte. Dabei kann ein eigener Directory-Service aufgebaut werden oder die Integration in einen bestehenden Directory-Dienst erfolgen. Hierbei ist auf eine Struktur zu achten, die das Schutzniveau des Prozessnetzes nicht herabsetzt und auch keine Abhängigkeiten zu Diensten außerhalb des Prozessnetzes schafft. Bei der Nutzung einer zentralen   Benutzerverwaltung sollten lokale Notfallpassworte für den Fall einer Störung des Benutzerverwaltungsdienstes vorgesehen werden.
Gelöscht: Ist für die Nutzung der Systeme ein Betriebssystem-Login erforderlich, sollte hierzu ein niedrig privilegierter Account verwendet werden. Systemaccounts sollten nicht für die normale, nicht-administrative Anwendungsnutzung verwendet werden.  Hinzugefügt: Ist für die Nutzung der Systeme ein Betriebssystem-Login erforderlich, sollte hierzu ein niedrig privilegierter Account verwendet werden. System-Accounts sollten nicht für die normale, nicht-administrative Anwendungsnutzung verwendet werden.
<>Autonome Benutzerauthentifizierung - Haupttechnologiekomponenten
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: Die Verwendung eines Mehrnutzerbetriebs auf System- und Anwendungsebene sollte insbesondere für HMI-Arbeitsplätze auf Stationsebene und in Automatisierungsumgebungen prinzipiell möglich sein. Die Anbindung an zentrale DirectoryDienste sollte bei Bedarf realisierbar sein. Hierbei muss insbesondere für dezentrale Systeme wie z.B. verteilte Stationen die Verfügbarkeitsproblematik zentraler Directory-Dienste hinreichend berücksichtigt werden.  Hinzugefügt: Sekundär-, Automatisierungs- und Fernwirktechnik: Die Verwendung eines Mehrnutzerbetriebs auf System- und Anwendungsebene sollte insbesondere für HMI-Arbeitsplätze auf Stationsebene und in Automatisierungsumgebungen prinzipiell möglich sein. Die Anbindung an zentrale Directory-Dienste sollte bei Bedarf realisierbar sein. Hierbei sollte insbesondere für dezentrale Systeme, wie z.B. verteilte Stationen, die Verfügbarkeitsproblematik zentraler Directory-Dienste hinreichend berücksichtigt werden.
<>Virtualisierungstechnologien - Sicherheitsanwendungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
Gelöscht: - Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.1.3, 12.3.1, 12.6.1, 13.1.3, 17.2.1
  Hinzugefügt: Bei der Nutzung von Virtualisierungstechnologien sind die folgende Anforderungen zu berücksichtigen:
  Hinzugefügt: a) Virtualisierte Komponenten, die unterschiedlichen Sicherheits- oder Vertrauenszonen zugeordnet sind (z.B. interne Komponenten und DMZ-Komponenten), dürfen nicht auf denselben Virtualisierungsservern betrieben werden. Die Netzwerksegmentierung von separierten Sicherheitszonen darf nicht über die Virtualisierungsserver umgangen werden können.
  Hinzugefügt: b) Die für Verwaltungs- und Administrationsdienste sowie die für die Datenspeicherung der Virtualisierungsinfrastruktur genutzten Netzwerke müssen von weiteren Netzwerken durch Firewalls segmentiert werden, an denen nur die minimal benötigten Netzwerkdienste restriktiv freigeschaltet werden. Der Zugriff auf die Verwaltungs- und Administrationsdienste und die o.g. Netzwerke muss auf Administratoren beschränkt werden.
  Hinzugefügt: c) Die Virtualisierungsschicht, die Verwaltungs- und Administrationsschnittstellen und die zugehörige Infrastruktur müssen gemäß Hersteller-Empfehlungen einheitlich konfiguriert, gesichert und gehärtet sowie im Patch-Management und im Datensicherungskonzept berücksichtigt werden.
  Hinzugefügt: d) Die Virtualisierungsserver müssen über hinreichende Ressourcen für den Betrieb aller auf ihnen betriebenen virtualisierten Komponenten verfügen. Dies gilt insbesondere auch für Betriebssituationen unter erhöhter Last.
  Hinzugefügt: e) Der Ausfall von Virtualisierungsservern oder sonstigen Komponenten der Virtualisierungsinfrastruktur darf keine negativen Auswirkungen auf die definierten Verfügbarkeitsanforderungen haben. Störungen und Ausfälle der Virtualisierungsumgebung müssen auch in der Notfallkonzeption und Wiederanlaufplanung berücksichtigt werden (siehe 4.8.2)
<>Virtualisierungstechnologien - Ergänzungen und Anmerkungen
BDEW Version 1.1 11/2014 BDEW Version 2.0 05/2018
  Hinzugefügt: Das Testsystem sollte auch die wesentlichen Komponenten und Funktionen der Virtualisierungsinfrastruktur umfassen, um gewährleisten zu können, dass das Verhalten der virtuellen Komponenten in der Testumgebung nicht von der Produktivumgebung abweicht.
  Hinzugefügt: Die Vorteile der Virtualisierung sollen insbesondere im Rahmen des Backups, des Patch-Managements sowie bei der Notfallplanung und Wiederanlaufplanung genutzt werden, z.B. durch das Einfrieren und Speichern von Betriebszuständen virtueller Komponenten (sog. Snapshots).
Gelöscht: - Hinzugefügt: zu a)
  Hinzugefügt: Virtualisierte Komponenten der Prozesssteuerung und der Büro-IT sollten auf getrennten Virtualisierungsservern betrieben werden. Entwicklungs- bzw. Test- und  Produktivumgebungen sollten ebenfalls auf verschiedenen Virtualisierungsservern betrieben werden.
  Hinzugefügt: zu d)
  Hinzugefügt: Die Überbuchung von Ressourcen wie Hauptspeicher oder Massenspeicherplatz sollte vermieden werden. Es sollte jederzeit sichergestellt sein, dass eine Ressourcen-Überbuchung keine negative Einflüsse auf die Verfügbarkeit, Funktionsfähigkeit und Performance des Produktivsystems haben kann.

Auswirkungen auf Ihr ISMS

Wirksamkeit von Sicherheits- und Abnahmetests erhöhen

Die Abnahme von in Auftrag gegebenen Systemkomponenten erfolgt unter anderem nach erfolgreich durchgeführten Sicherheits- und Stresstests.

Im überarbeiteten BDEW/OE Whitepaper sind nachfolgende Themen dazugekommen:

  • Zugriffsrechte für Testpersonen,
  • Sicherheitsprüfungen auch während des Betriebszeitraums,
  • Umsetzungsumfang von vertraglich vereinbarten Sicherheitsmaßnahmen,
  • Integrität des zu prüfenden Systems.
  • Prüfen Sie Ihre ISMS-Richtlinien zum Thema Sicherheits- und Abnahmeprüfungen, passen Sie gegebenenfalls Ihr Betriebshandbuch sowie Ihren Maßnahmenkatalog an.

Erweiterung der Härtungsmaßnahmen

Die Maßnahmen zur Härtung der Systeme und Komponenten werden ausgeweitet. Die folgenden Maßnahmen sind neu:

  • Löschung von Installations- und temporären Dateien,
  • Aktivierung von Application-Whitelisting,
  • eine nach Möglichkeit automatisch verifizierbare sichere Grundkonfiguration,
  • jährliche Prüfung der Grundkonfiguration und Härtungsmaßnahmen für Betriebsführungs- / Leitsysteme und Systembetrieb.
  • Erfüllen Sie heute schon die Anforderungen zur Härtung Ihrer Systeme?

Mehr Effektivität im Schadsoftware-Schutz

Um den Schutz vor Angriffe durch Schadsoftware effektiver zu machen, wurden neue Sicherheitsmaßnahmen definiert:

  • Überwachung von Arbeitsspeicher,
  • Notfallkonzeption bezüglich Fehlerkennungen und Fehlkonfigurationen des Schadsoftware-Schutzes erweitern.
  • Prüfen Sie den Einsatzbereich Ihres Schadsoftware-Schutzes und erweitern Sie gegebenenfalls Ihr Notfallkonzept.

Sicherheitsmaßnahmen für Virtualisierungstechnologien

Das Thema Virtualisierung wurde im Kapitel ‚Basissystem‘ neu dazu genommen. Hier wurden Sicherheitsanforderungen bezüglich der virtualisierten Komponenten, benötigten Netzwerke, Konfiguration, Sicherung, Härtung sowie Betrieb und Ausfall der Virtualisierungsserver definiert.

  • Nutzen Sie bereits die Möglichkeiten der Virtualisierung? Dann machen Sie sich mit den neuen Sicherheitsanforderungen vertraut.

Zusammenfassung und Ausblick

xmera hat die Sicherheitsanforderungen in den Kapiteln ‚Projektorganisation‘ und ‚Basissystem‘ des neuen BDEW/OE Whitepapers für Sie analysiert.

Neue Sicherheitsanforderungen sind in den Themen Sicherheits- und Abnahmetests, Grundsicherung sowie Systemhärtung, Schadsoftware-Schutz und Virtualisierungstechnologien zu finden.

Sicherheits- und Abnahmetests, Grundsicherung und Systemhärtung sind bekannte Instrumente zur Erhöhung der Informationssicherheit. Die zusätzlich in das Whitepaper aufgenommenen Maßnahmen dienen zur Erhöhung ihrer Wirksamkeit.

Der Einsatz von Virtualisierungstechnologien wurde in der vorherigen Version des Whitepapers nicht behandelt. Durch die vielen Vorteile der Virtualisierung wird sie längst auch bei EVUs betrieben. Daher kann das Thema informationssicherheitstechnisch nicht länger ignoriert werden. Entsprechend wurde eine Reihe von Anforderungen für einen sicheren Einsatz von Virtualisierungstechnologien definiert.

In Teil 4 unserer Beitragsserie „BDEW Sicherheitsanforderungen 2018: Was ist neu?“ analysiert xmera die Kapitel ‚Netzwerk‘ und ‚Kommunikation‘ für Sie.

Bekommen Sie schon unseren xmera blogletter? Nein? Dann melden sie sich für unserem kostenfreien Infoservice an!