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 | 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 | 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 | 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 | 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 | 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 | 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 | 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: | 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: | 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 | 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 | 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 | 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: | 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 | |
| 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 | 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 | 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 | Hinzugefügt: - Deinstallation oder Deaktivierung nicht benötigter Softwarekomponenten und Funktionen |
| Gelöscht: - Deaktivierung | 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 | 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 | 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 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.2.1 |
| Gelöscht: Alle vernetzten | 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 | 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 | 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 | 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 | 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 | |
| Gelöscht: Alle vom |
<>Schadsoftware-Schutz - 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: - |
| Gelöscht: Übertragungstechnik / Sprachkommunikation: Derzeit ist der Einsatz von | 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 | 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 | 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- | 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. | 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 | 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!
