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.
In Teil 4 analysiert xmera den Abschnitt ‚Netzwerk und Kommunikation‘ des Kapitels Sicherheitsanforderungen und zeigt Ihnen Neuerungen zu Sicherheitsmaßnahmen für Übertragungsprotokolle, Netzwerkstrukturen, Fern-Zugänge und Funktechnologien auf.
Bevor es jedoch mit der Analyse losgeht, blicken wir gemeinsam auf die Erkenntnisse aus dem dritten Teil der Serie zurück.
Der eilige Leser kann gerne direkt auf den Abschnitt seiner Wahl in diesem Beitrag springen.
Rückblick auf Teil 3
Teil 3 unserer Beitragsserie befasste sich mit den Sicherheitsanforderungen zu den Themen ‚Projektorganisation‘ und ‚Basissystem‘.
Ziel der Neuerungen der aktuellen Version des BDEW/OE Whitepapers ist die Wirksamkeit von bereits installierten Informationssicherheitsmaßnahmen zu erhöhen. Dazu wurden neue Maßnahme für bekannte Instrumente wie
- Sicherheits- und Abnahmetests,
- Systemhärtung und
- Schadsoftware-Schutz
formuliert. Zudem wird in der Neufassung der Sicherheitsanforderungen nun auch der vermehrte Einsatz von Virtualisierungstechnologien gewürdigt. Hierzu wurden Sicherheitsanforderungen zu den
- virtualisierten Komponenten,
- benötigten Netzwerken,
- Konfiguration und Sicherung,
- Härtung sowie Betrieb und Ausfall der Virtualisierungsserver
definiert.
Ausführlichere Informationen über die Auswirkungen des neuen BDEW/OE Whitepapers in den Abschnitten ‚Projektorganisation‘ und ‚Basissystem‘ können sie in Teil 3 – 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: Netzwerk und Kommunikation
Sicherheitsanforderungen zum Thema ‚Netzwerk und Kommunikation‘ beziehen sich auf den Datenaustausch in Netzwerken, auf den Fern-Zugriff auf Netzwerke, die Netzwerksegmentierung sowie die Kommunikation über VoIP und Funk.
Welche Themen sich 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: Sichere Netzwerkkonzeption und Kommunikationsverfahren | |
| Unverändert: Eingesetzte Protokolle und Technologien | Unverändert: Eingesetzte Protokolle und Technologien |
| Unverändert: Sichere Netzwerkstruktur | Unverändert: Sichere Netzwerkstruktur |
| Unverändert: Dokumentation der Netzwerkstruktur und -konfiguration | Unverändert: Dokumentation der Netzwerkstruktur und -konfiguration |
| Gelöscht: Sichere Wartungsprozesse und RAS-Zugänge | |
| Unverändert: Sichere Fern-Zugänge | Unverändert: Sichere Fern-Zugänge |
| Gelöscht: Anforderung an die Wartungsprozesse | |
| Gelöscht: Funktechnologien | Hinzugefügt: Funktechnologien |
Von den drei wegfallenden Kapiteln waren zwei im alten Whitepaper lediglich Strukturelemente. Sie dienten als Oberkapitel ohne eigenen Inhalt.
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!
Das Kapitel ‚Anforderungen an die Wartungsprozess‘ dagegen entfällt tatsächlich. Es wurde in das Kapitel ‚Wartung‘ verschoben, was wir in Teil 6 dieser Beitragsserie analysieren werden.
Inhaltliche Neuerungen der beibehaltenen Kapitel des Abschnittes ‚Netzwerk und Kommunikation‘ wird der nachfolgende Textvergleich aufdecken.
<>Eingesetzte Protokolle und Technologien - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 9.4.1, 9.4. | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.4.1, 9.4.2, 10.1.1, 10.1.2, 12.9.1 |
| Gelöscht: ISO/IEC TR 27019:2013: 10.6.3, 10.12.1, 11.4.5 | |
| Hinzugefügt: ENR, 13.1.1, 13.1.2, 13.1.3, 13.1.4 ENR | |
| Gelöscht: a) Wo technisch möglich, dürfen nur sichere Kommunikationsstandards | Hinzugefügt: a) Wo technisch möglich, dürfen generell nur sichere Kommunikationsstandards und Protokolle benutzt werden, die Integritätsüberprüfung, Authentifizierung und ggf. Verschlüsselung bieten. |
| Gelöscht: Das betrifft besonders die Protokolle zur Remote-Administration oder durch welche Benutzer-Anmeldeinformationen übertragen werden. Passwort-Übertragungen im Klartext sind nicht erlaubt (z. B. kein Telnet, keine Unix r-Dienste). Eine aktuelle Liste der sicheren Protokolle kann nach den jeweils internen Regularien des Auftraggebers bereit gestellt werden. | |
| Hinzugefügt: Für Protokolle zur Remote-Administration und Parametrierung ist dies zwingend umzusetzen. Bei nicht standardkonformen bzw. proprietären Protokollen sind die genannten Punkte ebenfalls zu berücksichtigen. | |
| Gelöscht: b) Das Gesamtsystem und jede dazugehörige Netzwerkkomponente müssen sich in die Netzwerk-Konzeption des Gesamtunternehmens einbinden lassen. Relevante Netzwerk-Konfigurationsparameter wie IP-Adressen müssen zentral | Hinzugefügt: b) Das Gesamtsystem und jede dazugehörige Netzwerkkomponente müssen sich in die Netzwerk-Konzeption des Gesamtunternehmens einbinden lassen. Relevante Netzwerk-Konfigurationsparameter wie IP-Adressen müssen zentral verwaltet werden können. Zur Administration und zum Monitoring werden sichere Protokolle verwendet, die Integritätsschutz, Authentifizierung und Verschlüsselung gewährleisten. Die Netzwerkkomponenten sind gehärtet, unnötige Dienste und Protokolle sind deaktiviert, Management-Interfaces sind durch ACLs geschützt. |
| Gelöscht: c) Netzwerkkomponenten, die vom Auftragnehmer bereitgestellt werden, müssen in ein zentrales Inventory- und | Hinzugefügt: c) Netzwerkkomponenten, die vom Auftragnehmer bereitgestellt werden, müssen in ein zentrales Inventory- und Patch-Management eingebunden werden können. |
| Gelöscht: d) Wo technisch möglich, wird auf WAN-Verbindungen das | Hinzugefügt: d) Wo technisch möglich, wird auf WAN-Verbindungen das IP-Protokoll verwendet und unverschlüsselte Applikations-Protokolle durch Verschlüsselung auf den unteren Netzwerkebenen geschützt (z.B. durch TLS-Verschlüsselung oder durch verschlüsselte VPN-Technologie). |
| Gelöscht: e) Wo technisch möglich, werden Firewall-freundliche Protokolle benutzt: z. B. TCP anstatt UDP, OPC über Netzgrenzen hinweg vermeiden. | |
| Gelöscht: | Hinzugefügt: e) Beim Einsatz von gemeinsam genutzten Netzwerk-Infrastrukturkomponenten (z.B. bei VLAN- oder MPLS-Technologie) definiert das Netzwerk mit dem höchsten Schutzbedarf die Anforderungen an die Hardware und deren Parametrierung. Eine gleichzeitige Nutzung der Netzwerkkomponenten bei unterschiedlichem Schutzbedarf darf nur vorgenommen werden, wenn eine Herabsetzung des Schutzniveaus oder der Verfügbarkeit durch die Gleichzeitigkeit in keinem Fall möglich ist. |
<>Eingesetzte Protokolle und Technologien - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Bieten die genutzten Netzwerkprotokolle sicherheitserhöhende Optionen, sollten diese aktiviert werden. | Unverändert: Bieten die genutzten Netzwerkprotokolle sicherheitserhöhende Optionen, sollten diese aktiviert werden. |
| Gelöscht: zu a) | |
| Gelöscht: Für interaktive Nutzerzugänge (z.B. zur Fernadministration) sollten ausschließlich sichere Protokolle – wie beschrieben – eingesetzt werden. Zur Fernadministration sollten bevorzugt SSH / SCP / SFTP bzw. RDP in den aktuellen Versionen und mit aktivierten Sicherheitseinstellungen verwendet werden. | Hinzugefügt: Protokolle, die UDP als Transportprotokoll nutzen, sollten generell vermieden werden. Dies gilt insbesondere beim Einsatz über die Grenzen von Sicherheitszonen hinweg. Ausnahmen gelten momentan für die folgenden Standardprotokolle: |
| Gelöscht: Schreibende Zugriffe auf Daten und Variablen sollten nur nach einer erfolgreichen Authentisierungs- und Autorisierungsprüfung möglich sein. Parametrier- und Engineering-Zugriffe sollten nur über gesicherte Protokolle erfolgen und sollten ebenso nur nach einer erfolgreichen Authentisierungs- und Autorisierungsprüfung möglich sein. | |
| Gelöscht: zu b und c) | |
| Gelöscht: Zu empfehlen ist eine strikte Trennung der technischen und kaufmännischen Netze und der Aufbau eines zentralen Netzwerkmanagementsystems für die Prozessnetze. | |
| Gelöscht: zu e) | |
| Gelöscht: Protokolle, die UDP als Transportprotokoll nutzen, sollten generell vermieden werden. Ausnahmen gelten momentan für die folgenden Standardprotokolle: | |
| Gelöscht: | Hinzugefügt: |
| Unverändert: - NTP / SNTP (Network Time Protocol / Simple Network Time Protocol) | Unverändert: - NTP / SNTP (Network Time Protocol / Simple Network Time Protocol) |
| Gelöscht: - SNMP (Simple Network Management Protocol) | Hinzugefügt: - SNMP (Simple Network Management Protocol, mindestens in der Version 3) |
| Hinzugefügt: - RADIUS (Remote Authentication Dial In User Service) | |
| Unverändert: Die Nutzung von Protokollen mit dynamischer Portvergabe (z.B. RPC/DCOM) sollte über Firewalls hinweg prinzipiell vermieden werden. | Unverändert: Die Nutzung von Protokollen mit dynamischer Portvergabe (z.B. RPC/DCOM) sollte über Firewalls hinweg prinzipiell vermieden werden. |
| Gelöscht: Für das häufig zur Systemkopplung eingesetzte OPC-Protokoll sollten die im Folgenden aufgeführten Hinweise berücksichtigt werden. Diese gelten primär für die DCOM-basierten OPC-Versionen. Für OPC-XML und OPC-UA sind die Hinweise entsprechend angepasst umzusetzen: | Hinzugefügt: Aus der häufig zur Systemkopplung eingesetzten OPC-Protokollfamilie sollte ausschließlich die im Hinblick auf Sicherheitsaspekte entwickelte Protokollversion OPC-UA genutzt werden. Dabei sollten die folgenden Einstellungen aktiviert werden: |
| Gelöscht: - Netzwerkbasierter OPC-Zugriff sollte auf OPC-Serverbasis selektiv freigegeben werden. Wird nur ein lokaler OPC-Zugriff benötigt, sollte für den OPC-Server der Remotezugriff unterbunden werden. | |
| Gelöscht: - OPC-Kommunikation sollte über Firewallgrenzen nur über kryptographisch gesicherte OPC-Tunnellösungen geführt werden. | |
| Gelöscht: - OPC-Zugriff auf Systeme mit erhöhtem Schutzbedarf sollte nur über gesicherte und gehärtete Proxysysteme erfolgen, die mit einem aktiven Schadsoftwareschutz und unter Anwendung eines Patchmanagementprozesses betrieben werden. | |
| Gelöscht: - Wird nur lesender OPC-Zugriff benötigt, sollten Schreibzugriffe generell unterbunden werden. Notwendige Schreibzugriffe sollten möglichst selektiv auf die benötigten Datenpunkte eingeschränkt werden. Wird dies vom OPC-Server nicht nativ unterstützt, sollten hierzu ggf. zusätzliche OPC-Sicherheitslösungen eingesetzt werden. | |
| Gelöscht: - Kritische Systemvariablen sollten nicht zum Schreibzugriff freigegeben werden. | |
| Gelöscht: - Die OPC- bzw. DCOM-Rechtevergabe sollte möglichst restriktiv erfolgen. Dies beinhaltet u.a. die Nutzung niederprivilegierter Nutzeraccounts für den Datenzugriff und die Nutzung verschiedener Accounts für Launch- und Access-Permissions. Freigaben für die Everyone-Gruppe sollten nicht erfolgen. OPC-Server- und OPC-Serverbrowserdienst sollten nicht mit SYSTEM-Privilegien betrieben werden. | Hinzugefügt: - Der securityMode sollte 'Sign' (Signieren von Nachrichten) oder 'SignAndEncrypt' (Signieren und Verschlüsseln von Nachrichten) sein. Damit wird unter anderem eine Authentifizierung auf Applikationsebene erzwungen. Der securityMode 'SignAndEncrypt' sollte dann genutzt werden, wenn über Integrität hinaus vertrauliche Daten zu schützen sind. Der securityMode 'None' bietet keinerlei Schutz. |
| Gelöscht: - Die Option „Authentisierungslevel“ sollte mindestens auf „Packet Integrity“ gesetzt sein. | |
| Gelöscht: - OPC sollte nur für die benötigten Protokolle aktiviert werden. I.d.R. ist dies ausschließlich TCP/IP. Zugriffe über andere Protokolle wie UDP, NetBEUI, HTTP bzw. COM Internet Services oder IPX sollten deaktiviert werden. | |
| Gelöscht: Die Standard-Protokolle IEC 60870-5 und IEC 61850 bieten ohne zusätzliche Maßnahmen keine sichere Integritätsüberprüfung, Authentifizierung und Verschlüsselung, vgl. hierzu 2.4.3. | |
| Hinzugefügt: - Bei der Wahl der kryptographischen Verfahren sollte die Security-Policy 'Basic256SHA256' gewählt werden. | |
| Hinzugefügt: - Benutzerauthentifizierung: Die Möglichkeit der Anmeldung mit der Kennung 'anonymous' sollte unterbunden werden. | |
| Hinzugefügt: Entsprechend den technischen Möglichkeiten sollten in allen Bereichen standardisierte IEC-Protokolle angewendet werden. Der private Bereich dieser Kommunikationsprotokolle sollte nur bei technischer Notwendigkeit verwendet werden. Die Standard-Protokolle IEC 60870-5-101/104 und IEC 61850 bieten ohne zusätzliche Maßnahmen keine sichere Integritätsüberprüfung, Authentifizierung und Verschlüsselung. Hier sollten die verfügbaren Erweiterungen gemäß IEC 62351 eingesetzt werden. Mögliche Einschränkungen bei der Fehlerdiagnose sowie die notwendige Infrastruktur und Prozesse zur Schlüsselverwaltung sollten berücksichtigt werden. | |
| Hinzugefügt: zu a) | |
| Hinzugefügt: Zur Fernadministration sollten bevorzugt SSH (Secure Shell), SCP (Secure Copy), SFTP (SSH File Transfer Protocol), HTTPS (Hypertext Transfer Protocol Secure) bzw. RDP (Remote Desktop Protocol) in den aktuellen Versionen und mit aktivierten Sicherheitseinstellungen verwendet werden. | |
| Hinzugefügt: Schalthandlungen und schreibende Zugriffe auf Daten und Variablen sollten nur nach einer erfolgreichen Authentisierungs- und Autorisierungsprüfung möglich sein. Parametrier- und Engineering-Zugriffe sollten nur über gesicherte Protokolle erfolgen und sollten ebenso nur nach einer erfolgreichen Authentisierungs- und Autorisierungsprüfung möglich sein. | |
| Hinzugefügt: zu b und c) | |
| Hinzugefügt: Zu empfehlen ist eine strikte Trennung der technischen, kaufmännischen und VoIP-Netze und der Aufbau eines zentralen Netzwerkmanagementsystems für die Prozessnetze. |
<>Eingesetzte Protokolle und Technologien - Haupttechnologiekomponenten
| 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: |
| Hinzugefügt: Insbesondere die Datenkopplung mit weiteren Leitsystemen und mit Automatisierungs-/Fernwirkkomponenten sollte über genormte Protokolle erfolgen. | |
| Hinzugefügt: Die Kommunikation innerhalb des Leitsystems ist i.d.R. herstellerabhängig. Hier sollten gleichwertige Sicherungsmechanismen vorgesehen werden. | |
| Gelöscht: Übertragungstechnik / Sprachkommunikation: | Hinzugefügt: Übertragungstechnik / Sprachkommunikation: |
| Hinzugefügt: Insbesondere für Voice-over-IP-Kommunikation sollten Sicherheitsmechanismen eingesetzt werden, die die Vertraulichkeit der Kommunikation sicherstellen und eine sichere Authentisierung der Kommunikationspartner und -komponenten gewährleisten. | |
| Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: | Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: |
| Hinzugefügt: Die Kommunikation zwischen einzelnen Automatisierungskomponenten erfolgt vielfach über Industriestandards oder proprietäre Herstellerprotokolle (z.B. Industrial Ethernet, Profinet, Profibus, etc.). Die Anbindung an die Stationsebene und an das Leitsystem sollte über die angeführten Standardprotokolle erfolgen. | |
| Unverändert: zu d) | Unverändert: zu d) |
| Gelöscht: Derzeit werden die VPN-Tunnel zumeist noch auf Routern in der Station terminiert. Zukünftig sollte | Hinzugefügt: Derzeit werden die VPN-Tunnel zumeist noch auf Routern in der Station terminiert. Zukünftig sollte ggf. eine Terminierung direkt auf den Steuerungseinheiten erfolgen. |
| Unverändert: zu e) | Unverändert: zu e) |
| Gelöscht: Die Nutzung von OPC über Anlagengrenzen hinweg sollte vermieden werden. | |
| Gelöscht: zu f) | |
| Unverändert: Beim Einsatz einer gemeinsamen Netzwerk-Infrastruktur in Automatisierungsnetzen für Prozesskommunikation und zur sonstigen Netzkommunikation (wie z.B. Parametrier- und Verwaltungskommunikation) sind insbesondere die Auswirkungen von Netzwerkstörungen oder Überlasten auf das Zeitverhalten in der Prozesskommunikation zu berücksichtigen (Beispiel: IEC 61850, GOOSE und Sampled Values, VLAN-Nutzung in der Stationsautomatisierung). | Unverändert: Beim Einsatz einer gemeinsamen Netzwerk-Infrastruktur in Automatisierungsnetzen für Prozesskommunikation und zur sonstigen Netzkommunikation (wie z.B. Parametrier- und Verwaltungskommunikation) sind insbesondere die Auswirkungen von Netzwerkstörungen oder Überlasten auf das Zeitverhalten in der Prozesskommunikation zu berücksichtigen (Beispiel: IEC 61850, GOOSE und Sampled Values, VLAN-Nutzung in der Stationsautomatisierung). |
<>Sichere Netzwerkstruktur - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 9.4.1, 13.1.3, 13.1.2 | |
| Gelöscht: ISO/IEC TR 27019:2013: 10.6.3, 10.12.1, 11.4.5, 11.4.8 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.4.1, 12.9.1 ENR, 13.1.1, 13.1.2, 13.1.3, 13.1.4 ENR, 13.1.5 ENR |
| Unverändert: a) Vertikale Netzwerksegmentierung: Soweit anwendbar und technisch möglich, wird die dem System zugrundeliegende Netzwerkstruktur in Zonen mit verschiedenen Funktionen und unterschiedlichem Schutzbedarf aufgeteilt. Wo technisch möglich, werden diese Netzwerk-Zonen durch Firewalls, filternden Router oder Gateways getrennt. Die Kommunikation mit weiteren Netzwerken hat ausschließlich über vom Auftraggeber zugelassene Kommunikationsprotokolle unter Einhaltung der geltenden Sicherheitsregeln zu erfolgen. | Unverändert: a) Vertikale Netzwerksegmentierung: Soweit anwendbar und technisch möglich, wird die dem System zugrundeliegende Netzwerkstruktur in Zonen mit verschiedenen Funktionen und unterschiedlichem Schutzbedarf aufgeteilt. Wo technisch möglich, werden diese Netzwerk-Zonen durch Firewalls, filternden Router oder Gateways getrennt. Die Kommunikation mit weiteren Netzwerken hat ausschließlich über vom Auftraggeber zugelassene Kommunikationsprotokolle unter Einhaltung der geltenden Sicherheitsregeln zu erfolgen. |
| Unverändert: b) Horizontale Netzwerksegmentierung: Soweit anwendbar und technisch möglich, wird die dem System zugrundeliegende Netzwerkstruktur auch horizontal in unabhängige Zonen (z.B. nach Standorten) aufgeteilt, wobei die Trennung der Zonen ebenfalls durch Firewalls, filternde Router oder Gateways erfolgen muss. | Unverändert: b) Horizontale Netzwerksegmentierung: Soweit anwendbar und technisch möglich, wird die dem System zugrundeliegende Netzwerkstruktur auch horizontal in unabhängige Zonen (z.B. nach Standorten) aufgeteilt, wobei die Trennung der Zonen ebenfalls durch Firewalls, filternde Router oder Gateways erfolgen muss. |
| Gelöscht: c) Firewalls und VPNs werden über einen vom Auftraggeber definierten Prozess zentral bereitgestellt und administriert. |
<>Sichere Netzwerkstruktur - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Die Anforderungen sind in der Regel projektspezifisch umzusetzen. | Unverändert: Die Anforderungen sind in der Regel projektspezifisch umzusetzen. |
| Gelöscht: Für Datenschnittstellen zu Fremdsystemen oder internen Netzen und Systemen, die in erhöhtem Maße externen Sicherheitsbedrohungen ausgesetzt sind (z.B. ein Büro-LAN mit Internetnutzung, dezentrale Anlagen mit vermindertem | Hinzugefügt: Netzwerke der Prozesssteuerung sollten von Büro-IT Netzwerken durch eine Firewall mit restriktivem Regelsatz segmentiert werden. Für Datenschnittstellen zu Fremdsystemen oder internen Netzen und Systemen, die in erhöhtem Maße externen Sicherheitsbedrohungen ausgesetzt sind (z.B. ein Büro-LAN mit Internetnutzung, dezentrale Anlagen mit vermindertem physischem Zugangsschutz, etc.), sollte die Funktion einer DMZ vorgesehen werden. Hierbei sollte immer die Regel gelten, dass DMZ-Komponenten keinen Zugriff auf interne Systemkomponenten in den Zonen mit höherem Sicherheitslevel haben dürfen. Der initiale Aufbau der Kommunikationsverbindung sollte immer vom hohen Sicherheitslevel zum geringeren gerichtet sein. Ausgenommen hiervon ist der interaktive Fernzugriff aus einer DMZ über gesicherte Protokolle (vgl. 4.4.1). |
| Unverändert: Mit Ausnahme von WAN/ÜT-Strecken sollten sich technische Netzwerke nur im inneren Sicherheitsbereich des physischen Objektschutzes befinden. Werden technische Systeme über diese Sicherheitsbereiche hinweg gekoppelt, sollte der Einsatz von VPNs geprüft werden. | Unverändert: Mit Ausnahme von WAN/ÜT-Strecken sollten sich technische Netzwerke nur im inneren Sicherheitsbereich des physischen Objektschutzes befinden. Werden technische Systeme über diese Sicherheitsbereiche hinweg gekoppelt, sollte der Einsatz von VPNs geprüft werden. |
| Unverändert: Sicherheitsgerichtete Kommunikation im Sinne der funktionalen bzw. Anlagensicherheit sollte nur innerhalb abgeschlossener, aus dedizierten Hardwarekomponenten aufgebauten Netzwerksegmenten erfolgen. Möglichkeiten zur Konfiguration der Parameter der funktionalen bzw. Anlagensicherheit über Netzwerkzugriffe sollten generell vermieden werden. Werden diese zwingend benötigt, sollten sie nur über die o.g. abgeschlossenen Netzwerksegmente zugänglich sein. | Unverändert: Sicherheitsgerichtete Kommunikation im Sinne der funktionalen bzw. Anlagensicherheit sollte nur innerhalb abgeschlossener, aus dedizierten Hardwarekomponenten aufgebauten Netzwerksegmenten erfolgen. Möglichkeiten zur Konfiguration der Parameter der funktionalen bzw. Anlagensicherheit über Netzwerkzugriffe sollten generell vermieden werden. Werden diese zwingend benötigt, sollten sie nur über die o.g. abgeschlossenen Netzwerksegmente zugänglich sein. |
| Hinzugefügt: Der Auftraggeber sollte prüfen, ob Netzwerk- und Security-Komponenten wie Firewalls oder VPN-Konzentratoren selbst beigestellt werden oder gegebenenfalls zum Lieferumfang des Auftragnehmers gehören. | |
| Unverändert: zu a) | Unverändert: zu a) |
| Gelöscht: Eine | Hinzugefügt: Eine physische Trennung funktionaler Ebenen sollte einer logischen Trennung vorgezogen werden. Wenn eine physische Trennung nicht möglich ist, ist das Restrisiko zu bewerten. |
| Unverändert: Zur Netzwerktrennung sollte die Nutzung von Gateways, die eine Protokollwandlung durchführen und keinen direkten IP-Verkehr zulassen, geprüft werden. | Unverändert: Zur Netzwerktrennung sollte die Nutzung von Gateways, die eine Protokollwandlung durchführen und keinen direkten IP-Verkehr zulassen, geprüft werden. |
<>Sichere Netzstruktur - 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: |
| Gelöscht: Insbesondere an Netzwerkübergängen von systeminternen Netzwerken (z.B. Leitsystem-LAN) zu weiteren internen Netzwerken und zu WAN-Netzen (z.B. zur Prozessankopplung) sollte eine DMZ-Struktur und die Installation von | Hinzugefügt: Insbesondere an Netzwerkübergängen von systeminternen Netzwerken (z.B. Leitsystem-LAN) zu weiteren internen Netzwerken und zu WAN-Netzen (z.B. zur Prozessankopplung) sollte eine DMZ-Struktur und die Installation von Firewall-Funktionalitäten vorgesehen werden. |
| Unverändert: Übertragungstechnik / Sprachkommunikation: | Unverändert: Übertragungstechnik / Sprachkommunikation: |
| Gelöscht: Wo möglich, sollte betriebseigene Infrastruktur verwendet werden. Bei | Hinzugefügt: Wo möglich, sollte betriebseigene Infrastruktur verwendet werden. Bei der Nutzung von fremdbetriebener Kommunikations-Infrastruktur sollte die Einhaltung von Sicherheitsstandards vertraglich eingefordert und ggf. überprüft werden. Es sollte geprüft werden, ob die Kommunikation im Fremdnetz durch ein eigenbetriebenes VPN abgesichert werden muss. |
| Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: | Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: |
| Gelöscht: An Übergängen von lokalen Netzwerken (z.B. Stations- oder Anlagen-LAN) zu weiteren Netzwerken (z.B. Leitstellen oder benachbarte Stationen/Anlagen) sollte die Installation von | Hinzugefügt: An Übergängen von lokalen Netzwerken (z.B. Stations- oder Anlagen-LAN) zu weiteren Netzwerken (z.B. Leitstellen oder benachbarte Stationen/Anlagen) sollte die Installation von Gateways mit Firewall-Funktionalitäten auf Netzwerk- und Applikationsebene (Telegramm-/Profilfilterung) vorgesehen werden. |
| Gelöscht: Eine Trennung unterschiedlicher Funktionen ist generell zu empfehlen. So sollten bei leittechnischen Anwendungen Terminal- und Anlagennetzwerk durch getrennte Netzwerkkomponenten realisiert werden. Die direkte Anbindung von Schutzgeräten an das allgemeine Automatisierungsnetz sollte vermieden werden, falls eine direkte Kommunikation mit anderen Automatisierungskomponenten funktional nicht notwendig ist. Gegebenenfalls sollte eine Segmentierung mit VLANs geprüft werden | Hinzugefügt: Eine Trennung unterschiedlicher Funktionen ist generell zu empfehlen. So sollten bei leittechnischen Anwendungen Terminal- und Anlagennetzwerk durch getrennte Netzwerkkomponenten realisiert werden. Die direkte Anbindung von Schutzgeräten an das allgemeine Automatisierungsnetz sollte vermieden werden, falls eine direkte Kommunikation mit anderen Automatisierungskomponenten funktional nicht notwendig ist. Gegebenenfalls sollte eine Segmentierung mit VLANs geprüft werden. |
| Gelöscht: Die direkte Kopplung unterschiedlicher Anlagen, Systeme und Anwendungen über ein gemeinsames Anlagennetzwerk sollte vermieden werden. Ein systemübergreifender Zugriff auf Komponenten am Anlagennetzwerk sollte stattdessen über gehärtete | Hinzugefügt: Die direkte Kopplung unterschiedlicher Anlagen, Systeme und Anwendungen über ein gemeinsames Anlagennetzwerk sollte vermieden werden. Ein systemübergreifender Zugriff auf Komponenten am Anlagennetzwerk sollte stattdessen über gehärtete Gateway-Komponenten realisiert werden. |
<>Dokumentation der Netzwerkstruktur und -konfiguration - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 8.1.1 | |
| Gelöscht: ISO/IEC | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 8.1.1 |
| Gelöscht: Die Netzwerkkonzeption und -konfiguration, alle | Hinzugefügt: Die Netzwerkkonzeption und -konfiguration, alle physischen, virtuellen und logischen Netzwerkverbindungen und die verwendeten Protokolle, IP-Adressen und Ports sowie die Netzwerk-Perimeter, die Bestandteil des Systems sind bzw. mit ihm interagieren, müssen dokumentiert sein. Änderungen, z.B. durch Updates, werden innerhalb des Change-Managements in die Dokumentation aufgenommen. Die Dokumentation muss Angaben über normale und maximal zu erwartende Datenübertragungsraten enthalten, damit gegebenenfalls auf den Netzwerkkomponenten eine Limitierung der Datenübertragungsraten zur Verkehrssteuerung und Verhinderung von DoS-Problemen implementiert werden kann. |
<>Dokumentation der Netzwerkstruktur und -konfiguration - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: Neben Kabellaufplänen sollten auch die logische Segmentierung in Sicherheitszonen und die Informationsflüsse in der Netzwerkdokumentation enthalten sein | Hinzugefügt: Neben Kabellaufplänen sollten auch die logische Segmentierung in Sicherheitszonen und die Informationsflüsse in der Netzwerkdokumentation enthalten sein. |
| Gelöscht: Die Dokumentation sollte | Hinzugefügt: Die Dokumentation sollte Port-genau sein, Kabel sollten mit Kabelnummer und Ziel und Gegenziel beschriftet werden. |
| Unverändert: Informationen in der Dokumentation sollten im Zeichnungs-Layer getrennt werden, um Dokumente mit unterschiedlichem Informationsgehalt (z.B. Netzwerkstruktur ohne IP-Adressen) zur Verfügung zu haben. | Unverändert: Informationen in der Dokumentation sollten im Zeichnungs-Layer getrennt werden, um Dokumente mit unterschiedlichem Informationsgehalt (z.B. Netzwerkstruktur ohne IP-Adressen) zur Verfügung zu haben. |
| Gelöscht: | Hinzugefügt: Es sollte die maximal zulässige Netzwerkbelastung angeben werden, unterhalb der eine zuverlässige Funktion des Gesamtsystems und der Einzelkomponenten gewährleistet ist. |
| Hinzugefügt: Die aktuelle Dokumentation sollte jederzeit (insbesondere auch bei Ausfall des betroffenen Netzwerks) verfügbar sein, z.B. für den Bereitschaftsdienst. |
<>Dokumentation der Netzwerkstruktur und -konfiguration - Haupttechnologiebereiche
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Betriebsführungs- / Leitsysteme und Systembetrieb: - | Unverändert: Betriebsführungs- / Leitsysteme und Systembetrieb: - |
| Unverändert: Übertragungstechnik / Sprachkommunikation: - | Unverändert: Übertragungstechnik / Sprachkommunikation: - |
| Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: | Unverändert: Sekundär-, Automatisierungs- und Fernwirktechnik: |
| Unverändert: Zur korrekten Umsetzung der Sicherheitsanforderung sollte auch die Kommunikation zwischen den Komponenten in der Station und mit dem Feld dokumentiert werden. | Unverändert: Zur korrekten Umsetzung der Sicherheitsanforderung sollte auch die Kommunikation zwischen den Komponenten in der Station und mit dem Feld dokumentiert werden. |
| Gelöscht: | Hinzugefügt: Unter dem Begriff „Perimeter“ ist im Stations-Umfeld die „Außenschnittstelle“ zwischen der einzelnen Station und anderen Netzen zu verstehen (Leitstelle, Ferndiagnose, etc.). |
<>Sichere Fern-Zugänge - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 9.1.2, 9.4.1, 9.4.2 | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 9.1.2, 9.4.1, 9.4.2 |
| Gelöscht: a) Administration, Wartung und Konfiguration aller Komponenten muss auch über ein Out-of-Band-Netz, zum Beispiel | Hinzugefügt: a) Administration, Wartung und Konfiguration aller Komponenten muss auch über ein Out-of-Band-Netz, zum Beispiel über lokalen Zugriff, via serielle Schnittstelle, Netzwerk oder direkter Steuerung der Eingabegeräte (KVM), möglich sein. |
| Gelöscht: b) Fern-Zugriff muss über zentral verwaltete | Hinzugefügt: b) Fern-Zugriff muss über zentral verwaltete Zugangsserver unter der Kontrolle des Systembetreibers durchgeführt werden. Die Zugangsserver,müssen in einer DMZ betrieben werden und eine Isolation des Prozessnetzes sicherstellen. Es muss ein 2-Faktor-Authentifizierungsverfahren benutzt werden. |
| Gelöscht: c) Direkte Einwahl | Hinzugefügt: c) Direkte Einwahl-Zugänge in Endgeräte sind grundsätzlich nicht erlaubt. |
| Gelöscht: d) Der Zugriff auf einen | Hinzugefügt: d) Der Zugriff auf einen Fernzugang muss zentral geloggt werden, wiederholte Fehlversuche werden gemeldet. |
| Unverändert: e) Alle Fern-Zugangs-Möglichkeiten müssen dokumentiert werden. | Unverändert: e) Alle Fern-Zugangs-Möglichkeiten müssen dokumentiert werden. |
<>Sichere Fern-Zugänge - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Eine direkte Kopplung mit externen Netzwerken oder Systemen sollte insbesondere für Systeme mit erhöhten Sicherheitsanforderungen vermieden werden. Generell darf die Fernwartung eine Netzwerktrennung und die vorhandenen Sicherheitsmechanismen nicht umgehen. | Unverändert: Eine direkte Kopplung mit externen Netzwerken oder Systemen sollte insbesondere für Systeme mit erhöhten Sicherheitsanforderungen vermieden werden. Generell darf die Fernwartung eine Netzwerktrennung und die vorhandenen Sicherheitsmechanismen nicht umgehen. |
| Gelöscht: Für Fernzugriffe | Hinzugefügt: Für Fernzugriffe sollten immer Zugangsserver unter Kontrolle des Betreibers genutzt werden. Damit wird sichergestellt, dass alle internen Sicherheitsanforderungen und Richtlinien jederzeit überprüfbar erfüllt werden. Alle für die Wartung benötigten Werkzeuge sollten dann in bzw. mit der Zugangsserver-Umgebung lauffähig sein und einen Mehrbenutzerbetrieb unterstützen. |
| Hinzugefügt: Die Zugangsserver sollten gehärtet und mit Schadsoftwareschutz versehen sein und immer auf aktuellem Softwarestand gehalten werden. Des Weiteren sollte eine Überwachung und Protokollierung der Fernwartung möglich sein. | |
| Gelöscht: Zusätzlich zu empfehlen | Hinzugefügt: Zusätzlich zu empfehlen sind separat aktivierbare Zugangspunkte (manuelle Freischaltung bzw. Trennung sowie zeitgesteuerte Trennung) in das jeweilige technische Netz bzw. Netzsegment. Für jede Netzwerkzone und jeden Dienstleister sollte nach Möglichkeit ein eigener, logisch separierter Fernwartungszugang und Server geschaffen werden. Für alle Fernzugriffe müssen mindestens die gleichen Sicherheitsanforderungen gelten wie für lokale Wartungszugriffe. |
| Unverändert: Auf Betreiberseite sollte eine Protokollierung aller relevanten Verbindungsdaten, wie z.B. der Zeitpunkt des Auf-/Abbaus der Verbindung bzw. der Wartungssitzung, die Netzwerk-Adressen von Einwahl- und Zielsystemen, die Nutzerkennungen etc. erfolgen. Ggf. sollten auch relevante Aktionen in Sende- und Empfangsrichtung protokolliert werden. | Unverändert: Auf Betreiberseite sollte eine Protokollierung aller relevanten Verbindungsdaten, wie z.B. der Zeitpunkt des Auf-/Abbaus der Verbindung bzw. der Wartungssitzung, die Netzwerk-Adressen von Einwahl- und Zielsystemen, die Nutzerkennungen etc. erfolgen. Ggf. sollten auch relevante Aktionen in Sende- und Empfangsrichtung protokolliert werden. |
| Gelöscht: | Hinzugefügt: Es sollten für alle Dienstleister standardisierte und je nach Anwendungsumfeld zentralisierte Fernwartungsinfrastrukturen und –prozesse genutzt werden. |
| Gelöscht: Bei einem Fernzugriff auf | Hinzugefügt: Bei einem Fernzugriff auf von Anwendern direkt genutzte Komponenten sind die entsprechenden gesetzlichen Rahmenbedingungen wie z.B. Datenschutzgesetze oder Betriebsverfassungsgesetz zu berücksichtigen. In der Regel ist dem Anwender der Fernzugriff eindeutig zu signalisieren. |
Sichere Fern-Zugänge – Haupttechnologiebereiche
-keine Veränderungen-
<>Funktechnologien - Sicherheitsanforderungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Gelöscht: ISO/IEC 27002:2013: 10.1.1, 13.1.1, 13.1.2, | Hinzugefügt: ISO/IEC 27002:2013 / 27019:2017: 10.1.1, 13.1.1, 13.1.2, 13.1.3 |
| Gelöscht: ISO/IEC TR 27019:2013: 12.1.1 | |
| Gelöscht: Der Einsatz von WLAN, Bluetooth | Hinzugefügt: Der Einsatz von Nahbereichs-Funktechnologien (z.B. WLAN, Bluetooth, ZigBee, RFID etc.) ist nur nach Analyse der damit verbundenen Risiken und unter Beachtung der nachfolgend beschriebenen Mindestsicherungsmaßnahmen in Abstimmung mit dem Auftraggeber und nach Genehmigung zulässig: |
| Gelöscht: - WLANs dürfen nur in dedizierten und durch Firewalls und Applikations-Proxies abgetrennten Netzwerk-Segmenten betrieben werden. | |
| Unverändert: - Drahtlose Übertragungstechnik muss nach dem Stand der Technik abgesichert werden. | Unverändert: - Drahtlose Übertragungstechnik muss nach dem Stand der Technik abgesichert werden. |
| Hinzugefügt: - WLANs dürfen nur in dedizierten und durch Firewalls und Applikations-Proxies abgetrennten Netzwerksegmenten betrieben werden. | |
| Gelöscht: - | Hinzugefügt: - WLANs sind so einzurichten, dass bestehende WLANs nicht gestört oder beeinträchtigt werden. |
<>Funktechnologien - Ergänzungen und Anmerkungen
| BDEW Version 1.1 11/2014 | BDEW Version 2.0 05/2018 |
|---|---|
| Unverändert: Alle Funktechnologien sollten generell nur bei zwingendem Bedarf und nach expliziter Freigabe durch den Auftraggeber eingesetzt werden. | Unverändert: Alle Funktechnologien sollten generell nur bei zwingendem Bedarf und nach expliziter Freigabe durch den Auftraggeber eingesetzt werden. |
| Gelöscht: Generell | Hinzugefügt: Generell sollte bei einem Einsatz von Funktechnologien ein möglicher Durchgriff in weitere Kommunikationsnetze sicher verhindert werden. |
| Unverändert: Drahtlose Peripheriegeräte und Eingabegeräte wie Tastaturen, Mäuse sowie Überwachungseinrichtungen wie Kameras sollten ebenfalls berücksichtigt werden. | Unverändert: Drahtlose Peripheriegeräte und Eingabegeräte wie Tastaturen, Mäuse sowie Überwachungseinrichtungen wie Kameras sollten ebenfalls berücksichtigt werden. |
| Unverändert: Die Nutzung von sicherheitsgerichteter Kommunikation über drahtlose Kommunikationstechnologien sollte i.d.R. vermieden und darf nur nach einer expliziten Risikoanalyse durchgeführt werden. Ggf. sind hierfür spezielle Baugruppen und ein spezifischer Schutz gegen externe Störstrahlung nötig. | Unverändert: Die Nutzung von sicherheitsgerichteter Kommunikation über drahtlose Kommunikationstechnologien sollte i.d.R. vermieden und darf nur nach einer expliziten Risikoanalyse durchgeführt werden. Ggf. sind hierfür spezielle Baugruppen und ein spezifischer Schutz gegen externe Störstrahlung nötig. |
| Gelöscht: Für weitere Hinweise zum sicheren Einsatz von WLAN und | Hinzugefügt: Für weitere Hinweise zum sicheren Einsatz von WLAN, Bluetooth und RFID siehe die NIST-Dokumente „NIST Special Publication 800-153 - Guidelines for Securing Wireless Local Area Networks (WLANs)“, „NIST Special Publication 800-121 - Guide to Bluetooth Security“ und „NIST Special Publication 800-98 - Guidelines for Securing Radio Frequency Identification (RFID) Systems”. |
Funktechnologien – Haupttechnologiebereiche
-keine Veränderungen-
Auswirkungen auf Ihr ISMS
Die Sicherheitsanforderungen zum Thema ‚Netzwerk und Kommunikation‘ wurden in Hinblick auf Protokolle, Netzwerkstruktur, Fern-Zugänge und Funk erweitert.
Wohlmöglich muss auch der Maßnahmenkatalog Ihres ISMS erweitert werden.
Prozessdatenkommunikation auf dem Prüfstand
Prozessdaten werden über Protokolle kommuniziert. Dabei ist es grundsätzlich möglich die Datenintegrität und Authentifizierung zu gewährleisten sowie Daten zu verschlüsseln.
Für die Remote-Administration und Parametrierung sowie für nicht standardkonforme bzw. proprietäre Protokolle werden die gerade genannten Protokollfähigkeiten im neuen Whitepaper zwingend gefordert.
Für die Prozessdatenkommunikation zwischen verschiedenen Systemen steht eine Reihe von Protokollen aus der OPC-Protokollfamilie zur Verfügung. Daraus sollte jedoch nur noch die Protokollversion OPC-UA eingesetzt werden. Sie wurde mit Fokus auf Informationssicherheit entwickelt und wird daher bereits als neuer Industrie 4.0-Standard bezeichnet. Das neue BDEW/OE Whitepaper reagiert darauf mit explizit für diesen Standard definierten Aktivierungsempfehlungen.
- Welche Protokolle verwenden Sie zur Datenübertragung? Prüfen Sie, ob Sie neue Sicherheitsmaßnahmen zur Erfüllung der Sicherheitsanfoderungen des BDEW einführen sollten.
Prozessnetze möglichst isolieren
Eine direkte oder indirekte Internetanbindung von Steuerungskomponenten erschwert die Einhaltung von Schutzzielen für Systeme und Anlagen.
Der BDEW spricht sich daher für eine strikte Trennung der technischen, kaufmännischen und VoIP-Netze voneinander aus. Desweiteren wird für Prozessnetze der zentrale Aufbau eines Netzwerkmanagementsystems sowie der Einsatz einer restriktiven Firewall zwischen Büro-IT Netzwerken und Prozessnetzen empfohlen.
- Wie steht es um die Isolation Ihrer Prozessnetze von Netzen mit Internetanbindung? Weitere Sicherheitsmaßnahmen könnten das Sicherheitsrisiko reduzieren.
Einbruchsichere Fern-Zugänge
Damit Fern-Zugänge nicht zur Sicherheitslücke werden, wurden auch hierzu die Sicherheitsanforderungen durch die Organisationen BDEW und OE ergänzt.
Das Augenmerk wurde dabei auf den Zugangsserver gelegt. Dieser sollte gehärtet und mit Schadsoftwareschutz ausgestattet und immer auf aktuellem Softwarestand gehalten werden. Des Weiteren sollte eine Überwachung und Protokollierung der Fernwartung möglich sein.
- Berücksichtigt Ihr ISMS bereits Zugangsserver für den Fernzugriff auf externe Netzwerke oder Systeme? Vielleicht gibt es in diesem Bereich noch Handlungsbedarf für Sie.
Abhören von Funkwellen erschweren
Funkwellen, wie sie beispielsweise durch WLAN oder RFID entstehen, sind grundsätzlich von jedermann abhörbar. Das National Institute of Standards and Technology (NIST) hat Richtlinien zur Reduzierung dieses Sicherheitsrisikos erarbeitet. Das BDEW empfiehlt:
- NIST Special Publication 800-153 – Guidelines for Securing Wireless Local Area Networks (WLANs)
- NIST Special Publication 800-98 – Guidelines for Securing Radio Frequency Identification (RFID) Systems
- Wenn Sie Funktechnologien wie WLAN oder RFID einsetzen, kann Ihre Informationssicherheit von der Berücksichtigung aktueller Richtlinien profitieren.
Zusammenfassung und Ausblick
Das vollständig überarbeitete BDEW/OE Whitepaper enthält Sicherheitsanforderungen für Energieversorgungsnetzbetreiber. xmera hat daraus den Abschnitt ‚Netzwerk und Kommunikation‘ in Hinblick auf Neuerungen analysiert.
Für Ihr ISMS bedeutet die Neufassung der Sicherheitsanforderungen, dass Sie vermutlich in Bezug auf Datenübertragungsprotokolle, Netzwerkstrukturen, Fern-Zugänge und Funk weitere Sicherheitsmaßnahmen einführen sollten.
Neue Maßnahmen sind verbunden mit der Trennung der technischen Netze, insbesondere Prozessnetze, von Netzen mit Internetanbindung. Ebenfalls könnte es für Sie notwendig sein, Zugangsserver für Fernzugriffe auf externe Netzwerke oder Systeme restriktiver zu betreiben.
Aktualisierungen von bereits vorhandenen Maßnahmen betreffen die Nutzung von Datenübermittlungsprotokollen und Funktechnologien nach aktuelle Standards. Hierzu macht der BDEW explizite Empfehlungen und referenziert Richtlinien des National Institute of Standards and Technology (NIST).
In Teil 5 unserer Beitragsserie „BDEW Sicherheitsanforderungen 2018: Was ist neu?“ wendet sich xmera dem Kapitel ‚Anwendung‘ für Sie zu.
Bekommen Sie schon unseren xmera blogletter? Nein? Dann melden sie sich für unserem kostenfreien Infoservice an!
