Bereits Anfang Mai veröffentlichte der BDEW (Bundesverband der Energie- und Wasserwirtschaft) zusammen mit OE (Oesterreichs Energie) eine von Grund auf überarbeitete Version des Whitepapers zum Thema „Anforderungen an sichere Steuerungs- und Telekommunikationssysteme“ und die zugehörigen Ausführungshinweisen.
Welche Inhalte des neuen Whitepapers nun wirklich neu sind und welche lediglich umstrukturiert wurden, erfahren Sie als Energieversorger detailiert im Rahmen unserer mehrteiligen Beitragsserie.
Teil 1 – BDEW Sicherheitsanforderungen 2018: Was ist neu?
Sie erhalten einen ersten groben Überblick über strukturelle Veränderungen des BDEW/OE Whitepapers.
Teil 2 – BDEW Sicherheitsanforderungen 2018: Was ist neu?
Es geht tiefer ins Detail. Sie erfahren warum Sie die Vererbungslogik des Schutzbedarfs Ihrer Systeme, Verträge mit Auftragnehmern sowie den Einsatz Kryptographischer Verfahren prüfen sollten.
Teil 3- BDEW Sicherheitsanforderungen 2018: Was ist neu?
Informieren Sie sich über zusätzliche Maßnahmen in den Bereichen Sicherheits- und Abnahmetests, Systemhärtung und Schadsoftware-Schutz. Machen Sie sich mit den neuen Sicherheitsmaßnahmen für den Einsatz von Virtualisierungstechnologien vertraut.
Teil 4- BDEW Sicherheitsanforderungen 2018: Was ist neu?
Erfahren Sie mit welchen Maßnahmen Sie Ihr ISMS in Sachen ‚Netzwerk und Kommunikation‘ erweitern. Wir zeigen Ihnen Neuerungen zu den Themen Datenübertragungsprotokolle, Netzwerkstrukturen, Fern-Zugänge und Funktechnologien auf.
Teil 5- BDEW Sicherheitsanforderungen 2018: Was ist neu?
Eine Anpasung an Ihr ISMS kann arbeitsreich werden. Im Bereich ‚Anwendung‘ gibt es eine Reihe von Verweise auf externe Standards.
In Teil 5 analysiert xmera den Abschnitt ‚Anwendung‘ des Kapitels Sicherheitsanforderungen. Dabei werden die Themen Rollenkonzepte, Authentifizierung, Autorisierung, Webanwendungen, Integritätsprüfung und Logging betrachtet.
Dabei steckt die Arbeit für Sie vor allem in den Verweisen auf externe Standards.
Bevor es jedoch mit der Analyse losgeht, blicken wir gemeinsam auf die Erkenntnisse aus dem viertenTeil der Serie zurück.
Der eilige Leser kann gerne direkt auf den Abschnitt seiner Wahl in diesem Beitrag springen.
Rückblick auf Teil 4
Teil 4 der Beitragsserie befasste sich mit dem Thema ‚Netzwerk und Kommunikation‘.
Neuerungen konnten in den Bereichen
- Prozessdatenkommunikation,
- Prozessnetze,
- Fern-Zugänge,
- Funkwellen
aufgedeckt werden.
Ausführlichere Informationen über die Auswirkungen des neuen BDEW/OE Whitepapers in den Abschnitten ‚Netzwerk und Kommunikation‘ können Sie in Teil 4 – BDEW Sicherheitsanforderungen 2018: Was ist neu? nachlesen.
Funktionsweise des Textvergleichs
Bevor Sie sich den Vergleich des alten und neuen Kapitels ‚Netzwerk und Kommunikation‘ anschauen, empfehle ich zunächst die Funktionsweise des Textvergleiches in Teil 1 der Beitragsserie nachzuvollziehen.
Textvergleich: Anwendung
Die Sicherheitsanforderungen im Bereich ‚Anwendung‘ beziehen sich beispielsweise auf Anwendungen der zentralen / dezentralen Leittechnik und Kommunikationstechnik. Ebenfalls können Parametriersoftware und Prognose-Tools dazu gehören.
Welche Themen sich im Bereich ‚Anwendung‘ im Vergleich mit der alten Version des BDEW/OE Whitepapers verändert haben, zeigt die Analyse der Unterkapitel aus den Inhaltsverzeichnissen der beiden Whitepaper.
Analyse der Unterkapitel
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Benutzerverwaltung | |
| Unverändert: Rollenkonzepte | Unverändert: Rollenkonzepte |
| Unverändert: Benutzer-Authentifizierung und Anmeldung | Unverändert: Benutzer-Authentifizierung und Anmeldung |
| Unverändert: Autorisierung von Aktionen auf Benutzer- und Systemebene | Unverändert: Autorisierung von Aktionen auf Benutzer- und Systemebene |
| Gelöscht: Anwendungsprotokolle | |
| Gelöscht: Web-Applikationen | |
| Hinzugefügt: Web-Applikationen und Web-Services | |
| Gelöscht: Integritätsprüfung | Hinzugefügt: Integritätsprüfung |
| Gelöscht: Protokollierung, Audit-Trails, Timestamps, Alarmkonzepte | |
| Gelöscht: Self-Test und System-Verhalten | |
| Hinzugefügt: Logging |
Von den sechs Veränderungen im Inhaltsverzeichnis sind drei nicht relevant. Das Kapitel Benutzerverwaltung diente lediglich der Verzeichnisstrukturierung. Die Kapitel ‚Web-Applikationen‘ und ‚Integritätsprüfung relevanter Daten‘ wurden geringfügig umbenannt.
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!
Für die übrigen drei Kapitel gibt es keine offensichtliche namentliche Ähnlichkeit. Mit ihnen könnten Neuerungen in der Neufassung des BDEW/OE Whitepapers verbunden sein.
Allerdings kann erst der nachfolgende Textvergleich tatsächliche inhaltliche Neuerungen aufdecken.
BDEW Version 1.1 11/2014
BDEW Version 2.0 05/2018
Gelöscht: ISO/IEC 27002:2013: 6.1.2, 9.2.1, 9.2.3, 9.2.6, 9.4.1
Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 6.1.2, 9.2.1, 9.2.3, 9.2.6, 9.4.1
Gelöscht: Das System muss über ein Benutzerkonzept verfügen, in dem mindestens folgende Benutzerrollen vorgesehen sind:
Hinzugefügt: Das Gesamtsystem muss eine granulare Zugriffskontrolle auf Daten und Ressourcen erlauben und muss hierzu über ein Benutzerkonzept verfügen, in dem mindestens folgende Benutzerrollen vorgesehen sind:
Unverändert: - Administrator: Benutzer, der das System installiert, wartet und betreut. Der Administrator hat deshalb u. a. die Berechtigung zur Änderung der Sicherheits- und Systemkonfiguration. Unverändert: - Administrator: Benutzer, der das System installiert, wartet und betreut. Der Administrator hat deshalb u. a. die Berechtigung zur Änderung der Sicherheits- und Systemkonfiguration. Gelöscht: - Auditor: Benutzerrolle, die ausschließlich die Berechtigung zum Einsehen und Archivieren der Audit-Logs besitzt. Gelöscht: - Operator: Benutzer, der das System im Rahmen der vorgesehenen Nutzung bedient. Dies beinhaltet auch das Recht zur Änderung von betriebsrelevanten Einstellungen.
Hinzugefügt: - Bediener: Benutzer, der das System im Rahmen der vorgesehenen Nutzung bedient. Dies beinhaltet auch das Recht zur Änderung von betriebsrelevanten Einstellungen.
Gelöscht: - Data-Display: Benutzer, der den Status des Systems abrufen und definierte Betriebsdaten lesen darf, aber nicht berechtigt ist, Änderungen durchzuführen.
Hinzugefügt: - Read-Only-Nutzer: Benutzer, der den Status des Systems abrufen und definierte Betriebsdaten lesen darf, aber nicht berechtigt ist, Änderungen durchzuführen.
Gelöscht: Gegebenenfalls wird eine Benutzerrolle „Backup-Operator“ definiert, die Datensicherungen aller relevanten System- und Anwendungsdaten durchführen kann. Gelöscht: Das System muss eine granulare Zugriffskontrolle auf Daten und Ressourcen erlauben. Die Zugriffsrechte entsprechen einer sicheren Systemkonfiguration. Sicherheitsrelevante Systemeinstellungen und Konfigurationswerte können nur von der Administrator-Rolle gelesen und geändert werden. Zur normalen Systemnutzung sind nur Operator oder Data-Display Rechte notwendig. Benutzer-Accounts können einzeln deaktiviert werden, ohne sie vom System entfernen zu müssen.
Hinzugefügt: Die Standard-Zugriffsrechte müssen einer sicheren Systemkonfiguration entsprechen. Sicherheitsrelevante Systemeinstellungen und Konfigurationswerte dürfen nur von der Administrator-Rolle gelesen und geändert werden können. Zur normalen Systemnutzung sind nur Bediener- oder Read-Only-Nutzer-Rechte notwendig. Benutzer-Accounts müssen einzeln deaktiviert werden können, ohne sie vom System entfernen zu müssen.
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Benutzerrollen ermöglichen eine einheitliche und leichtere Zuordnung von Berechtigungen für die einzelnen Benutzer. Rollenkonzepte dienen auch dazu, unabsichtliche Fehlhandlungen zu verhindern. | Unverändert: Benutzerrollen ermöglichen eine einheitliche und leichtere Zuordnung von Berechtigungen für die einzelnen Benutzer. Rollenkonzepte dienen auch dazu, unabsichtliche Fehlhandlungen zu verhindern. |
| Unverändert: Eine Festlegung der den Rollen zugewiesenen Rechte sollte durch den Auftraggeber erfolgen bzw. mit ihm abgestimmt werden. | Unverändert: Eine Festlegung der den Rollen zugewiesenen Rechte sollte durch den Auftraggeber erfolgen bzw. mit ihm abgestimmt werden. |
| Unverändert: Gegebenenfalls kann es sinnvoll sein, durch das Rollenkonzept ein Vier-Augen-Prinzip zu erzwingen, z.B.: | Unverändert: Gegebenenfalls kann es sinnvoll sein, durch das Rollenkonzept ein Vier-Augen-Prinzip zu erzwingen, z.B.: |
| Unverändert: - Rolle „Änderung von Parametrierungen“ | Unverändert: - Rolle „Änderung von Parametrierungen“ |
| Unverändert: - Rolle „Freigabe der Parametrierungsänderungen“ | Unverändert: - Rolle „Freigabe der Parametrierungsänderungen“ |
| Gelöscht: Neben den benutzergebundenen Berechtigungen sollten auch systemgebundene Berechtigungen bzw. Rollen vorgesehen sein, um den unterschiedlichen Arbeitsplätzen (Warte, Backoffice, Systembetreuung, | Hinzugefügt: Neben den benutzergebundenen Berechtigungen sollten auch systemgebundene Berechtigungen bzw. Rollen vorgesehen sein, um den unterschiedlichen Arbeitsplätzen (Warte, Backoffice, Systembetreuung, etc.) unabhängig vom Benutzer bestimmte Rechte oder Einschränkungen zuzuordnen. Die systemgebundenen Berechtigungen und Rollen müssen dabei immer stärker sein als die benutzergebundenen Berechtigungen und Rollen. |
| Gelöscht: Die Berechtigungen sollten nicht nur auf Ebene der Bedien- und Benutzeroberfläche realisiert sein, sondern sollten durchgehend in der gesamten Applikation und ggf. auch auf | Hinzugefügt: Die Berechtigungen sollten nicht nur auf Ebene der Bedien- und Benutzeroberfläche realisiert sein, sondern sollten durchgehend in der gesamten Applikation und ggf. auch auf Betriebssystem- und Datenbankebene umgesetzt werden. |
| Gelöscht: Die Möglichkeit zur zeitlichen Befristung von Rollen sollte bei Bedarf vorgesehen werden. | Hinzugefügt: Die Möglichkeit zur zeitlichen Befristung von Rollen und/oder Rechtevergaben sollte bei Bedarf vorgesehen werden. |
| Hinzugefügt: Die Normen IEC 62351-8 und 62351-90-1 behandeln rollenbasierte Zugriffssteuerung für Steuerungssysteme der Energieversorgung und können zur Umsetzung eines Rollenkonzepts herangezogen werden. Die im System hinterlegten Rollen sollten mit der Organisationsstruktur abgeglichen werden und sich bei Änderungen anpassen lassen. |
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Betriebsführungs-/ Leitsysteme und Systembetrieb: Beispiele für Nutzerrollen im Umfeld von Betriebsführungs- und Leitsystemen sind z.B.: | Unverändert: Betriebsführungs-/ Leitsysteme und Systembetrieb: Beispiele für Nutzerrollen im Umfeld von Betriebsführungs- und Leitsystemen sind z.B.: |
| Unverändert: - Administrator | Unverändert: - Administrator |
| Unverändert: - Parametrierung/Datenaufbereitung | Unverändert: - Parametrierung/Datenaufbereitung |
| Unverändert: - Bedien-/Schaltberechtigung | Unverändert: - Bedien-/Schaltberechtigung |
| Gelöscht: - Beobachtungsbetrieb | Hinzugefügt: - Beobachtung/Überwachung |
| Unverändert: - Datentest/Qualitätssicherung | Unverändert: - Datentest/Qualitätssicherung |
| Unverändert: Übertragungstechnik / Sprachkommunikation: Anzuwenden insbesondere für Management-Systeme. Beispiele für im ÜT-Umfeld anwendbare Nutzerrollen sind: | Unverändert: Übertragungstechnik / Sprachkommunikation: Anzuwenden insbesondere für Management-Systeme. Beispiele für im ÜT-Umfeld anwendbare Nutzerrollen sind: |
| Unverändert: - Administrator | Unverändert: - Administrator |
| Unverändert: - Konfiguration | Unverändert: - Konfiguration |
| Unverändert: - Beobachtung/Überwachung | Unverändert: - Beobachtung/Überwachung |
| Gelöscht: Sekundär-, Automatisierungs- und Fernwirktechnik: Im Stationsumfeld sollen angepasste und abgestufte Rollen umgesetzt werden. Dies gilt insbesondere für Stationsbediensysteme. Beispiele für im Stationsumfeld anwendbare Nutzerrollen sind: | Hinzugefügt: Sekundär-, Automatisierungs- und Fernwirktechnik: Im Stationsumfeld sollen angepasste und abgestufte Rollen umgesetzt werden. Dies gilt insbesondere für Stationsbediensysteme. Beispiele für im Stationsumfeld anwendbare Nutzerrollen sind (in Klammern ist ein beispielhaftes Mapping zu den in IEC 62351-8 definierten Rollen angegeben): |
| Gelöscht: - Administrator | |
| Gelöscht: - Schaltberechtigter | |
| Gelöscht: - Beobachter | |
| Hinzugefügt: - Administrator (INSTALLER / SECADM) | |
| Hinzugefügt: - Bedien-/Schaltberechtigung (OPERATOR) | |
| Hinzugefügt: - Beobachtung/Überwachung (VIEWER) | |
| Gelöscht: - Parametrierung | Hinzugefügt: - Parametrierung (ENGINEER) |
| Unverändert: - Änderung von Betriebsparametern | Unverändert: - Änderung von Betriebsparametern |
| Gelöscht: - Beobachtungsbetrieb | |
| Unverändert: - Diagnose (ohne Parametrier- und Schaltmöglichkeit) | Unverändert: - Diagnose (ohne Parametrier- und Schaltmöglichkeit) |
| Unverändert: - Datentest/Qualitätssicherung. | Unverändert: - Datentest/Qualitätssicherung. |
| Gelöscht: Für aktuelle Geräte der Schutz- und Automatisierungstechnik sind Rollenkonzepte derzeit häufig noch nicht umfassend realisierbar. In diesem Fall sollte mindestens ein Passwortschutz und/oder ein Schlüsselschalter vorgesehen werden. Zukünftig sollten auch bei diesen Geräten eine Trennung von Nutzerrollen sowie eine Einbindung in Directory-Dienste möglich sein. | |
| Gelöscht: Organisatorische Anmerkungen: Die im System hinterlegten Rollen sollten mit der Organisationsstruktur abgeglichen werden und sich bei Änderungen anpassen lassen. |
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 9.3.1, 9.4.2, 9.2.1, 9.2.2, 9.4.3 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.3.1, 9.4.2, 9.2.1, 9.2.2, 9.4.3,12.4.1 |
| Gelöscht: ISO/IEC TR 27019:2013: 11.3.1, 11.5.2 | |
| Gelöscht: | Hinzugefügt: Die Anwendung muss eine personenspezifische Identifizierung und Authentifizierung vornehmen, Gruppen-Accounts werden von Auftraggeber nur in genau spezifizierten Ausnahmefällen erlaubt. |
| Gelöscht: | Hinzugefügt: a) Ohne erfolgreiche Benutzer-Authentifizierung darf das System nur genau definierte Aktionen erlauben. |
| Gelöscht: c) Das System muss Passwörter mit vom Auftraggeber definierbarer Stärke und Gültigkeitsdauer erzwingen. | Hinzugefügt: b) Das System muss eine Passwort-Policy unterstützten, welche dem Stand der Technik entspricht. |
| Gelöscht: | Hinzugefügt: c) Wo technisch möglich, wird eine starke 2-Faktor-Authentifizierung verwendet, z.B. durch die Verwendung von Tokens oder SmartCards. |
| Gelöscht: e) Die zur Nutzeridentifizierung und Authentifizierung benötigten Daten dürfen nicht ausschließlich von außerhalb des Prozessnetzes bezogen werden. Die Anbindung an einen zentralen, prozessnetzinternen Directory Service sollte in Betracht gezogen werden. | |
| Gelöscht: f) Erfolgreiche und fehlgeschlagene Anmeldeversuche müssen zentral geloggt werden. | |
| Gelöscht: Die folgenden Punkte sind gegebenenfalls unter vorrangiger Beachtung der Anforderungen an einen sicheren Anlagenbetrieb und von Verfügbarkeitsaspekten umzusetzen: | |
| Gelöscht: Das System soll Mechanismen implementieren, die eine sichere und nachvollziehbare Übergabe von Benutzer-Sessions im laufenden Betrieb ermöglichen. | |
| Gelöscht: Wo möglich und sinnvoll sollen Benutzer-Sessions nach einer definierbaren Inaktivitäts-Zeit gesperrt werden. | |
| Hinzugefügt: d) Die zur Nutzeridentifizierung und Authentifizierung benötigten Daten dürfen nicht ausschließlich von außerhalb des Prozessnetzes bezogen werden (siehe auch 4.3.3). | |
| Gelöscht: Bei einer Überschreitung einer konfigurierbaren Anzahl von fehlgeschlagenen Anmeldeversuchen soll eine Alarmmeldung ausgelöst und wenn möglich das Konto gesperrt werden. | Hinzugefügt: e) Erfolgreiche und fehlgeschlagene Anmeldeversuche müssen zentral geloggt werden, fehlgeschlagene Anmeldeversuche müssen zentral alarmiert werden können. |
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Passworte und andere Authentisierungsinformationen dürfen nur kryptographisch gesichert übertragen und im System gespeichert werden. | Unverändert: Passworte und andere Authentisierungsinformationen dürfen nur kryptographisch gesichert übertragen und im System gespeichert werden. |
| Hinzugefügt: Der Betreiber sollte sicherstellen, dass eine Passwort-Policy festgelegt ist und umgesetzt wird. | |
| Hinzugefügt: Die Standardbenutzer-Accounts aller Applikationen und Systeme sollten bei Übernahme des Systems deaktiviert werden. | |
| Hinzugefügt: Die folgenden Punkte sind gegebenenfalls unter vorrangiger Beachtung der Anforderungen an einen sicheren Anlagenbetrieb und von Verfügbarkeitsaspekten umzusetzen: | |
| Hinzugefügt: - Das System soll Mechanismen implementieren, die eine sichere und nachvollziehbare Übergabe von Benutzer-Sessions im laufenden Betrieb ermöglichen. | |
| Hinzugefügt: - Wo möglich und sinnvoll sollen Benutzer-Sessions nach einer definierbaren Inaktivitäts-Zeit gesperrt werden. | |
| Hinzugefügt: - Bei Überschreitung einer konfigurierbaren Anzahl von fehlgeschlagenen Anmeldeversuchen soll eine Alarmmeldung ausgelöst und das Konto ggf. gesperrt werden. | |
| Gelöscht: zu | Hinzugefügt: zu a) |
| Hinzugefügt: Der Betreiber sollte konkret festlegen, welche Aktionen das System ohne erfolgreiche Benutzer-Authentifizierung zulässt. | |
| Hinzugefügt: zu b) | |
| Gelöscht: Im Rahmen der Anwendungskonfiguration sollte die erforderliche Passwortkomplexität durch den Anwendungsadministrator möglichst umfassend konfigurierbar sein. Zu definierende Parameter umfassen z.B. | Hinzugefügt: Im Rahmen der Anwendungskonfiguration sollte die erforderliche Passwortkomplexität durch den Anwendungsadministrator möglichst umfassend konfigurierbar sein (gemäß der Password-Policy des Unternehmens). Zu definierende Parameter umfassen z.B.: |
| Gelöscht: | Hinzugefügt: |
| Unverändert: - minimale Anzahl von bestimmten Zeichen/Zeichengruppen, z.B. Groß- und Kleinbuchstaben, Ziffern, Sonderzeichen, etc. | Unverändert: - minimale Anzahl von bestimmten Zeichen/Zeichengruppen, z.B. Groß- und Kleinbuchstaben, Ziffern, Sonderzeichen, etc. |
| Unverändert: - Gültigkeitsdauer | Unverändert: - Gültigkeitsdauer |
| Unverändert: - Verhinderung der Nutzung eines vorherigen Passwortes beim Passwortwechsel | Unverändert: - Verhinderung der Nutzung eines vorherigen Passwortes beim Passwortwechsel |
| Unverändert: - maximale Anzahl von Passwortänderungen pro Zeiteinheit (z.B. pro Tag) | Unverändert: - maximale Anzahl von Passwortänderungen pro Zeiteinheit (z.B. pro Tag) |
| Hinzugefügt: zu c) | |
| Hinzugefügt: Insbesondere bei Fernarbeitsplätzen sollte eine 2-Faktor-Authentifizierung vorgesehen werden. | |
| Unverändert: zu d) | Unverändert: zu d) |
| Gelöscht: Insbesondere bei Fernarbeitsplätzen sollte eine 2-Faktor-Authentifizierung vorgesehen werden. Die Standardbenutzeraccounts aller Applikationen und Systeme sollten bei Übernahme des Systems deaktiviert werden. | Hinzugefügt: Eine kryptographisch gesicherte Anbindung an einen zentralen, prozessnetzinternen Directory Service sollte in Betracht gezogen werden. |
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Betriebsführungs-/ Leitsysteme und Systembetrieb: Um eine kontinuierliche Anlagenüberwachung durch das Bedienpersonal und eine sichere Betriebsführung sicherstellen zu können, sollten auf den hierfür notwendigen Systemen (z.B. HMI/Bedienplatz der Leitsysteme) Möglichkeiten für eine sichere und nachvollziehbare Übergabe von Benutzer-Sessions im laufenden Betrieb, beispielsweise beim Schichtwechsel, vorhanden sein. Hierbei sollten auch Protokollierungsanforderungen berücksichtigt werden. | Unverändert: Betriebsführungs-/ Leitsysteme und Systembetrieb: Um eine kontinuierliche Anlagenüberwachung durch das Bedienpersonal und eine sichere Betriebsführung sicherstellen zu können, sollten auf den hierfür notwendigen Systemen (z.B. HMI/Bedienplatz der Leitsysteme) Möglichkeiten für eine sichere und nachvollziehbare Übergabe von Benutzer-Sessions im laufenden Betrieb, beispielsweise beim Schichtwechsel, vorhanden sein. Hierbei sollten auch Protokollierungsanforderungen berücksichtigt werden. |
| Unverändert: Übertragungstechnik / Sprachkommunikation: - | Unverändert: Übertragungstechnik / Sprachkommunikation: - |
| Unverändert: Sekundär-, Automatisierungs-und Fernwirktechnik: zu a) Die derzeit verbreitete Technik erfordert zum Teil eine lokale Anmeldung über Gruppen-Accounts. Mittelfristig sollte eine Umsetzung ohne die Nutzung von Gruppen-Accounts angestrebt werden. | Unverändert: Sekundär-, Automatisierungs-und Fernwirktechnik: zu a) Die derzeit verbreitete Technik erfordert zum Teil eine lokale Anmeldung über Gruppen-Accounts. Mittelfristig sollte eine Umsetzung ohne die Nutzung von Gruppen-Accounts angestrebt werden. |
| Unverändert: zu d) Für lokale Zugriffe im Stationsumfeld in der Regel nicht notwendig. | Unverändert: zu d) Für lokale Zugriffe im Stationsumfeld in der Regel nicht notwendig. |
| Gelöscht: zu e) Aktuelle Schutz- und Automatisierungskomponenten unterstützen häufig keine Einbindung von Directory-Diensten. | |
| Gelöscht: Insbesondere im dezentralen Stationsumfeld ist auch für | Hinzugefügt: zu e) Insbesondere im dezentralen Stationsumfeld ist auch für HMI-Systeme die Nutzung zentraler Directory-Dienste aus Verfügbarkeitsgründen u.U. mit aktueller Technik derzeit nicht zu realisieren. |
| Unverändert: Zukünftig sollte auch hier eine Einbindung in Directory-Dienste möglich sein. | Unverändert: Zukünftig sollte auch hier eine Einbindung in Directory-Dienste möglich sein. |
| Gelöscht: Organisatorische Anmerkungen: Der Betreiber sollte sicherstellen, dass eine Passwortpolicy festgelegt ist und umgesetzt wird. |
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 9.4.1, 9.4.4 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.4.1, 9.4.4 |
| Unverändert: Vor bestimmten sicherheitsrelevanten/-kritischen Aktionen muss die Autorisierung des anfordernden Benutzers bzw. der anfordernden Systemkomponente überprüft werden. Zu den relevanten Aktionen können auch das Auslesen von Prozess-Datenpunkten oder Konfigurationsparametern gehören. | Unverändert: Vor bestimmten sicherheitsrelevanten/-kritischen Aktionen muss die Autorisierung des anfordernden Benutzers bzw. der anfordernden Systemkomponente überprüft werden. Zu den relevanten Aktionen können auch das Auslesen von Prozess-Datenpunkten oder Konfigurationsparametern gehören. |
Autorisierung von Aktionen auf Benutzer- und Systemebene – Ergänzungen und Anmerkungen
-keine Veränderungen-
Autorisierung von Aktionen auf Benutzer- und Systemebene – Haupttechnologiebereiche
-keine Veränderungen-
| 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: 14.2.5 |
| Gelöscht: Neben allgemeinen Aspekten der sicheren Anwendungsprogrammierung sind bei Web-Applikationen besonders die folgenden Punkte zu berücksichtigen: | |
| Gelöscht: a) Die Applikation ist in verschiedene Module (z. B. Präsentations-, Anwendungs- und Datenschicht) zu trennen. Gegebenenfalls sind diese Module auf verschiedene Server zu verteilen. | |
| Gelöscht: b) Die verschiedenen Komponenten und Prozesse sind mit den minimal möglichen Rechten zu betreiben, sowohl auf Anwendungs als auch auf Systemebene. | |
| Gelöscht: c) Sämtliche Parameter, die vom Anwender (bzw. seinem Web-Browser) an die Web-Anwendung gesendet werden sind genau auf Gültigkeit, maximale Länge sowie auf korrekten Typ und Wertebereich hin zu überprüfen. Dies gilt auch für Parameter, die von der Web-Anwendung selbst in einem vorhergehenden Schritt zum Anwender geschickt wurden. Dabei ist insbesondere auf sog. XSS- und Injection-Sicherheitslücken zu achten, über die ein Angreifer eigene Kommandos ausführen kann. | |
| Gelöscht: d) Es ist besonders auf sicheres Session-Management zu achten, z. B. durch verschlüsselte oder signierte Session-IDs und zeitbeschränkte Sessions. Die Übertragung von Session-IDs ist durch SSL-Verschlüsselung zu schützen. | Hinzugefügt: Für Web-Applikationen, Web-Schnittstellen und Web-Services sind die Empfehlungen der OWASP TOP 10 und des OWASP Application Security Verification Standard Projekte sowie des BSI-Leitfadens zur Entwicklung sicherer Webanwendungen zu berücksichtigen. |
| Gelöscht: e) Der Anwender soll zwar bei Fehlverhalten mit Fehlermeldungen informiert werden, dabei dürfen aber keine für einen Angreifer verwertbaren Informationen mitgeliefert werden. Solche Informationen dürfen ausschließlich in einem nur intern zugänglichen Logfile gespeichert werden. | |
| Gelöscht: f) Web-Anwendungen mit hohem Schutzbedarf sollten vor Inbetriebnahme einem Sicherheits-Audit unterzogen werden. | Hinzugefügt: Abweichungen sind zu begründen und vom Auftraggeber vorab zu genehmigen. |
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Die Einführung von Webanwendungen sollte generell nur in Abstimmung und nach einer expliziten Freigabe durch den Auftraggeber/Betreiber erlaubt werden. | Unverändert: Die Einführung von Webanwendungen sollte generell nur in Abstimmung und nach einer expliziten Freigabe durch den Auftraggeber/Betreiber erlaubt werden. |
| Gelöscht: Beim Einsatz von Web-Anwendungen sollten allgemein anerkannte Sicherheitsempfehlungen und Hinweise wie z.B. die des Open Web Application Security Project (OWASP, http://www.owasp.org) oder der ÖNORM A-7700 „Informationsverarbeitung ― Sicherheitstechnische Anforderungen an Webapplikationen“ berücksichtigt und umgesetzt werden. | |
| Unverändert: Sollten die eingesetzten Systemkomponenten über Browserschnittstellen (z.B. zur Parametrierung) verfügen, ist auch hier eine sichere Implementierung zu gewährleisten. Andernfalls sollten die Schnittstellen deaktiviert werden. | Unverändert: Sollten die eingesetzten Systemkomponenten über Browserschnittstellen (z.B. zur Parametrierung) verfügen, ist auch hier eine sichere Implementierung zu gewährleisten. Andernfalls sollten die Schnittstellen deaktiviert werden. |
| Hinzugefügt: Von den Anforderungen des OWASP Application Security Verification Standard Projekts sollte im Bereich der Prozessteuerung der Energieversorgung mindestens Level L2 (Standard), im Bereich kritischer Infrastrukturen Level L3 (Advanced) umgesetzt werden. |
Web-Applikationen und Web-Services – Haupttechnologiebereiche
-keine Veränderungen-
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 14.2.5 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 14.2.5 |
| Unverändert: Die Integrität von Daten, die in sicherheitsrelevanten Aktionen verarbeitet werden, muss vor der Verarbeitung überprüft werden (beispielsweise auf Plausibilität, korrekte Syntax und Wertebereich). | Unverändert: Die Integrität von Daten, die in sicherheitsrelevanten Aktionen verarbeitet werden, muss vor der Verarbeitung überprüft werden (beispielsweise auf Plausibilität, korrekte Syntax und Wertebereich). |
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: | Hinzugefügt: Die Konsistenz der verarbeiteten Daten sollte jederzeit sichergestellt sein. Ein konsistenter Eingangsdatensatz sollte immer in einen konsistenten Ausgabedatensatz übergeführt werden. Insbesondere darf es zu keinen inkonsistenten Zwischenzuständen kommen. |
| Gelöscht: Daten aus externen Systemen oder über Nutzerschnittstellen eingegebene Daten sollten immer auf Konsistenz und Gültigkeit geprüft werden (z.B. Typ, Länge, Umfang, Syntax, Wertebereich, Plausibilität, Alter). Dies gilt insbesondere, wenn fehlerhafte oder manipulierte Daten den sicheren Systembetrieb gefährden könnten (z.B. beim Import von Parametrierungen). Ebenso sollte eine solche Prüfung innerhalb der Anwendung bzw. innerhalb des Systems realisiert werden, z.B. an der Schnittstelle zwischen Anwendungskomponenten oder | Hinzugefügt: Daten aus externen Systemen oder über Nutzerschnittstellen eingegebene Daten sollten immer auf Konsistenz und Gültigkeit geprüft werden (z.B. Typ, Länge, Umfang, Syntax, Wertebereich, Plausibilität, Alter). Dies gilt insbesondere, wenn fehlerhafte oder manipulierte Daten den sicheren Systembetrieb gefährden könnten (z.B. beim Import von Parametrierungen). Ebenso sollte eine solche Prüfung innerhalb der Anwendung bzw. innerhalb des Systems realisiert werden, z.B. an der Schnittstelle zwischen Anwendungskomponenten oder Programm-Modulen. |
| Gelöscht: Beispiele: | |
| Gelöscht: - Überprüfung des möglichen Stellbereichs eines Betriebsmittels | |
| Gelöscht: - Prüfung des Änderungsdatums einer Parametrierung, um vor dem Überschreiben einer ggf. aktuelleren Version zu warnen. |
Integritätsprüfung – Haupttechnologiebereiche
-keine Veränderungen-
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: 2.4.6 Protokollierung, Audit-Trails, Timestamps, Alarmkonzepte | |
| Gelöscht: ISO/IEC 27002:2013: 12.4.1, 12.4.2, 12.4.3, 12.4.4, 18.1.3 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 12.4.1, 12.4.2, 12.4.3, 12.4.4, 18.1.3 |
| Gelöscht: ISO/IEC TR 27019:2013: 10.10.1, 10.10.6 | |
| Gelöscht: a) | Hinzugefügt: a) Das Gesamtsystem muss über eine einheitliche Systemzeit verfügen und die Möglichkeit zur Synchronisation dieser Systemzeit mit einer externen, gesicherten Zeitquelle bieten. |
| Unverändert: b) Das System muss Benutzeraktionen sowie sicherheitsrelevante Aktionen, Vorkommnisse und Fehler in einem zur nachträglichen und zentralen Auswertung geeignetem Format protokollieren. Es werden Datum und Uhrzeit, involvierte Benutzer und Systeme sowie das Ereignis und Ergebnis für einen konfigurierbaren Mindestzeitraum aufgezeichnet. | Unverändert: b) Das System muss Benutzeraktionen sowie sicherheitsrelevante Aktionen, Vorkommnisse und Fehler in einem zur nachträglichen und zentralen Auswertung geeignetem Format protokollieren. Es werden Datum und Uhrzeit, involvierte Benutzer und Systeme sowie das Ereignis und Ergebnis für einen konfigurierbaren Mindestzeitraum aufgezeichnet. |
| Gelöscht: c) Das Logging von Events soll einfach konfigurierbar und modifizierbar sein. | |
| Gelöscht: d) Sicherheitsrelevante Events sollen in den Systemlogs als solche markiert werden, um eine automatische Auswertung zu erleichtern. | |
| Gelöscht: e) Die zentrale Speicherung der Logdateien erfolgt an einem frei konfigurierbarem Ort. | |
| Gelöscht: f) Ein Mechanismus zur automatisierten Übertragung des Logfiles auf zentrale Komponenten muss zur Verfügung stehen. | |
| Hinzugefügt: c) Die zentrale Speicherung der Logdateien erfolgt an einem frei konfigurierbaren Ort. Ein Mechanismus zur automatisierten Übertragung des Logfiles auf zentrale Komponenten muss zur Verfügung stehen. | |
| Gelöscht: | Hinzugefügt: d) Das Logfile muss gegen spätere Modifikation geschützt sein. |
| Gelöscht: h) Das Logfile darf nur von der Benutzerrolle Auditor archiviert werden können. | |
| Gelöscht: | Hinzugefügt: e) Bei Überlauf des Logfiles werden die älteren Einträge überschrieben, das System muss bei knapp werdendem Logging-Speicherplatz warnen. |
| Gelöscht: | Hinzugefügt: f) Es muss möglich sein, sicherheitsrelevante Meldungen in ein vorhandenes Alarm-Management aufzunehmen. |
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Eine Pflicht zur Protokollierung kann auf Grund von betrieblichen, behördlichen oder rechtlichen Anforderungen bestehen. | Unverändert: Eine Pflicht zur Protokollierung kann auf Grund von betrieblichen, behördlichen oder rechtlichen Anforderungen bestehen. |
| Hinzugefügt: Um eine zielgerichtete Verwaltung der Logfiles zu gewährleisten, sollten die Kriterien dafür in einem Logging-Betriebskonzept festgelegt werden. Der Auftraggeber sollte Vorgaben für den Mindestzeitraum bzw. die Mindestanzahl der zu speichernden Meldungen für die lokale und zentrale Speicherung festlegen. | |
| Hinzugefügt: Das Logging von Events sollte möglichst einfach konfigurierbar und modifizierbar sein. | |
| Hinzugefügt: Sicherheitsrelevante Events sollen in den Systemlogs als solche markiert werden, um eine automatische Auswertung zu erleichtern. | |
| Hinzugefügt: Beispiele: abgewiesener Befehl wegen Zeitdifferenz/Befehlsalter, Anmeldeversuche mit falschem Passwort. | |
| Unverändert: zu a) | Unverändert: zu a) |
| Unverändert: Als Systemzeit sollte entweder die lokale Zeit, CET oder UTC verwendet werden. Für alle Systeme, die direkt oder indirekt an externe Partner angebunden sind, sollte der genutzte Standard mit diesen abgestimmt werden. | Unverändert: Als Systemzeit sollte entweder die lokale Zeit, CET oder UTC verwendet werden. Für alle Systeme, die direkt oder indirekt an externe Partner angebunden sind, sollte der genutzte Standard mit diesen abgestimmt werden. |
| Hinzugefügt: Bei der Nutzung des NTP-Protokolls sollte eine kryptographische Authentisierung gemäß RFC 2030 / RFC 1305 vorgesehen werden. | |
| Gelöscht: Ausfälle der Verfügbarkeit des Zeitsignals bzw. der externen Zeitsynchronisierung sollten keine bzw. nur wohldefinierte Auswirkungen auf leittechnische Funktionen haben. | Hinzugefügt: Ausfälle der Verfügbarkeit des Zeitsignals bzw. der externen Zeitsynchronisierung sollten keine bzw. nur wohldefinierte Auswirkungen auf leittechnische Funktionen haben. Gegebenenfalls sollte eine redundante Zeitquelle vorgesehen werden. |
| Gelöscht: zu | Hinzugefügt: zu e) |
| Gelöscht: Beispiele: abgewiesener Befehl wegen Zeitdifferenz/Befehlsalter, Einlogversuche mit falschem Passwort. | |
| Hinzugefügt: Sofern ein Ringspeicher-Mechanismus eingesetzt wird, ist die Anforderung nicht direkt anwendbar. In diesem Fall sollte die Mindestgröße des Ringspeichers festgelegt und eine Speicherung auf einem zentralen Logserver (siehe c)) vorgesehen werden. |
| 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: - |
| Unverändert: Sekundär-, Automatisierungs-und Fernwirktechnik: zu a) Im Stationsbereich sollte systemintern UTC verwendet werden. Die Ein- und Ausgabe sollte dann in der konfigurierbaren Ortszeit erfolgen. | Unverändert: Sekundär-, Automatisierungs-und Fernwirktechnik: zu a) Im Stationsbereich sollte systemintern UTC verwendet werden. Die Ein- und Ausgabe sollte dann in der konfigurierbaren Ortszeit erfolgen. |
| Unverändert: zu b) Die Protokollierung kann z.B. im Betriebsprotokoll erfolgen. | Unverändert: zu b) Die Protokollierung kann z.B. im Betriebsprotokoll erfolgen. |
| Gelöscht: zu | Hinzugefügt: zu c) Für Schutz- und Automatisierungskomponenten erfolgt das Logging i.d.R. auf Ebene der übergeordneten Systeme. Im Umfeld der dezentralen Stationstechnik sollte eine Speicherung in der Station und eine Synchronisation bzw. Übertragung auf eine Zentrale vorgesehen werden. |
| Gelöscht: zu | Hinzugefügt: zu d) siehe c) |
| Gelöscht: Organisatorische Anmerkungen: Um eine zielgerichtete Verwaltung der Logfiles zu gewährleisten, sollten die Kriterien dafür in einem Logging-Betriebskonzept festgelegt werden. |
Auswirkungen auf Ihr ISMS
Der Bereich ‚Anwendung‘ zeichnet sich im direkten Textvergleich dadurch aus, dass hauptsächlich die Wortwahl überarbeitet wurde.
Jedoch steckt der Teufel im Detail. Wenn Sie genau hinschauen, werden Sie feststellen, dass es doch noch eine Reihe von neuen Sicherheitsstandards gibt, die wohlmöglich in Ihr ISMS übernommen werden müssen.
Verweise auf externe Standards
Die Neufassung des BDEW/OE Whitepapers empfiehlt erstmals für den Bereich ‚Anwendung‘ eine Reihe von externen Standards:
Rollenkonzepte
Im Zusammenhang mit Rollenkonzepte für Steuerungssysteme wird auf die entsprechenden Standards der International Electrotechnical Commision (IEC) verwiesen:
- IEC 62351-8 – Role based access control
- IEC 62351-90-1 – Guidelines for handling role-based access control in power systems
Web-Applikationen und Web-Services
Für Web-Applikationen und Web-Services verweist das BDEW auf drei verschiedene Standards der Intitutionen Open Web Application Security Project (OWASP) und Bundesamt für Sicherheit in der Informationstechnik (BSI):
- OWASP TOP 10
- OWASP Application Security Verification Standard Project
- BSI-Leitfadens zur Entwicklung sicherer Webanwendungen
Die Empfehlungen der OWASP sollten für die Prozessteuerung der Energieversorgung mindestens für Level L2 (Standard), im Bereich kritischer Infrastrukturen für Level L3 (Advanced) umgesetzt werden. Abweichungen durch den Auftragnehmer sind Genehmigungspflichtig.
Logging
Bei der Nutzung des NTP-Protokolls sollte eine kryptographische Authentisierung gemäß
- RFC 2030 (SNTP)
- RFC 1305 (NTP)
vorgesehen werden.
RFC steht für ‚Request for Comments‘, die wiederum für eine Reihe technischer und organisatorischer Dokumente über das Internet stehen. Veröffentlicht werden sie unter dem Namen RCF-Editor.
Außnahmen werden für Ringspeicher-Mechanismen gemacht.
- Wenn Ihnen die obigen Standards noch nicht bekannt sind, sollten Sie sich mit Ihnen vertraut machen und die Sicherheitsmaßnahmen in Ihrem ISMS gegebenenfalls erweitern.
Direkte Neuerungen bei den BDEW/OE Sicherheitsstandards
In der Vorgängerversion des Whitepapers waren Ausnahmen bzgl. Rollenkonzepte für Geräte der Schutz- und Automatisierungstechnik formuliert. Diese Lockerung wurde in der Neufassung entfernt.
Fehlgeschlagene Anmeldeversuche müssen zentral alarmiert werden können.
- Haben Sie bereits ein Rollenkonzept für Geräte der Schutz- und Automatisierungstechnik erstellt? Wie steht es um die zentrale Alarmierung von fehlgeschlagenen Anmeldeversuchen?
Zusammenfassung und Ausblick
Auf den ersten Blick scheint sich im Bereich ‚Anwendung‘ nicht viel verändert zu haben. Der Abschnitt ‚Self-Test und System-Verhalten‘ entfällt ganz. Aus dem Textvergleich gehen direkt lediglich zwei neue Sicherheitsanforderungen für Rollenkonzepte und Anmeldeversuche hervor.
Trotzdem kann die Überarbeitung Ihres ISMS mit Aufwand verbunden sein. Das BDEW/OE Whitepaper empfiehlt für die Themen Rollenkonzepte, Web-Applikationen und Web-Services und Logging eine Reihe von externen Sicherheitsstandards. Werden diese Standards nicht schon von Ihnen berücksichtigt, ist eine Integration in Ihr ISMS unumgänglich.
In Teil 6 unserer Beitragsserie „BDEW Sicherheitsanforderungen 2018: Was ist neu?“ wendet sich xmera den Kapiteln ‚Entwicklung‘, ‚Wartung‘, ‚Datensicherung und Notfallplanung‘ für Sie zu.
Bekommen Sie schon unseren xmera blogletter? Nein? Dann melden sie sich für unserem kostenfreien Infoservice an!
