Embed Size (px)
Citation preview
Informationssicherheit in der Energieversorgung
Grundlegende organisatorische und technische Anforderungen
zur Erhöhung der IKT-Sicherheit in der Energiewirtschaft
Oesterreichs Energie 2/19
Informationssicherheit in der Energieversorgung
Grundlegende organisatorische und technische Anforderungen
zur Erhöhung der IKT-Sicherheit in der Energiewirtschaft
Herausgeber:
Oesterreichs E-Wirtschaft
Brahmsplatz 3, 1040 Wien, Österreich
Ansprechpartner:
Armin Selhofer (Österreichs E-Wirtschaft)
Erwin Bosin (TINETZ-Stromnetz Tirol AG)
Fachliche Unterstützung:
Dr. Stephan Beirer (GAI NetConsult GmbH, Berlin/Deutschland)
Rocco Gundlach (GAI NetConsult GmbH, Berlin/Deutschland)
Trotz sorgfältiger Prüfung wird keine Gewähr für die inhaltliche Richtigkeit übernommen. Außer für Vorsatz und grobe
Fahrlässigkeit ist jegliche Haftung von Herausgeber und Medieninhaber aus dem Inhalt dieses Werks ausgeschlossen.
Diese Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. © 2014
Version 1.1 von 20140331
Oesterreichs Energie 3/19
Inhalt
Vorwort ................................................................................................................................. 4
Sicherheitsanforderungen ................................................................................................... 5
1 Sicherheitsorganisation ..................................................................................................5
2 Risikomanagement .........................................................................................................5
3 Bedeutung der Personalsicherheit ..................................................................................6
4 Sicherheitsvereinbarungen mit Dritten ............................................................................7
5 Schutz sensibler Daten ...................................................................................................8
6 Sicheres Systemdesign ..................................................................................................8
7 Sichere Software-Entwicklung ........................................................................................9
8 Sichere Netzwerkstruktur und Kommunikationsprotokolle ............................................ 10
9 Grundsicherung und Systemhärtung ............................................................................ 11
10 Rollen- und Berechtigungskonzept ............................................................................... 11
11 Konfigurations- und Änderungsmanagement ................................................................ 12
12 Patch- und Versionsmanagement ................................................................................. 13
13 Schadsoftwareschutz .................................................................................................... 14
14 Sichere Wartungsprozesse ........................................................................................... 14
15 Physische und umgebungsbezogene Sicherheit ........................................................... 15
16 Protokollierung und Überwachung ................................................................................ 16
17 Datensicherung und Wiederherstellung ........................................................................ 16
18 Reaktion auf Sicherheitsereignisse, Notfall- und Incidentmanagement ......................... 17
Literatur .............................................................................................................................. 18
Abkürzungsverzeichnis ..................................................................................................... 19
Oesterreichs Energie 4/19
Vorwort
Das vorliegende Dokument beschreibt wesentliche Informationssicherheitsanforderungen für
Beschaffung und Betrieb der für Überwachung und Steuerung der Energieversorgung
eingesetzten IKT-Komponenten und Systeme. Es ist eine Zusammenfassung der im
BDEW/OE-Whitepaper „Anforderungen an sichere Steuerungs- und
Telekommunikationssysteme“, der ISO/IEC TR 27019 „Information security management
guidelines based on ISO/IEC 27002 for process control systems specific to the energy utility
industry“ sowie den ENISA Guidelines „Appropriate security measures for smart grids“
aufgezeigten Maßnahmen und Anforderungen zur Minimierung des Informations-
Sicherheitsrisikos.
Der Leitfaden soll als Checkliste für Projektleiter, Asset- oder Systemverantwortliche,
Informationssicherheitsbeauftragte und das Management auf Energieversorger- bzw.
Herstellerseite dienen, anhand derer sichergestellt werden kann, dass keine wesentlichen
Maßnahmenkomplexe in der Beschaffung, Projektabwicklung, im Betrieb und in der
Organisation unberücksichtigt bleiben. Des Weiteren sollen wesentliche Aufgabenbereiche
im Bereich des Informationssicherheitsmanagements kurz beschrieben werden. Die
Hinweise referenzieren sowohl auf Maßnahmen im technischen als auch im
organisatorischen Bereich. Der Leitfaden soll einen Überblick über die wichtigsten
Themenbereiche bieten. Nähere Detailinformationen sind den aufgeführten Quellen zu
entnehmen.
Oesterreichs Energie 5/19
Sicherheitsanforderungen
1 Sicherheitsorganisation
Informationssicherheit soll innerhalb des Unternehmens eingeführt und gesteuert werden.
Die Bedeutung von Informationen und der informationsverarbeitenden Systeme für alle
Unternehmensprozesse in der Energieversorgung sowohl im kaufmännischen als auch im
technischen Bereich wird damit unterstrichen.
Dafür soll das Management entsprechende Rahmenbedingungen schaffen, wie z.B.:
Eine Leitlinie zur Informationssicherheit verabschieden, die eine Richtungsvorgabe
hinsichtlich der Informationssicherheit darstellt und dabei Geschäftsanforderungen und
geltende Gesetze, Verträge und Regelungen berücksichtigt
Sicherheitsbezogene Verantwortlichkeiten und Rollen benennen und mit den notwendigen
Ressourcen ausstatten
Die Wirksamkeit der Leitlinie überprüfen und deren Verbesserung fördern, indem
Mitarbeiter geschult, relevante Verfahren und Abläufe erfasst und ausgewertet sowie
erkannte Abweichungen beseitigt, Prozesse angepasst oder Risiken minimiert bzw.
vermieden werden
Kontakte zu relevanten Behörden, Institutionen, speziellen Interessensgruppen und
Interessensvertretungen, wie z.B. Oesterreichs Energie, aufbauen und pflegen. Dazu
zählt auch, die Kommunikation zu anderen Anwendern über Internetforen oder Kongresse
zu fördern.
Um eine umfassende Sicherheitsorganisation gegenüber Externen nachweisen zu können,
kann eine Zertifizierung z.B. nach ISO/IEC 27001 sinnvoll sein.
Verweise:
OE / BDEW-Whitepaper: -
ISO/IEC TR 27019: 5.1 „Informationssicherheitsleitlinie“ und 6.1 „Interne Organisation“
ENISA Guidelines: Domain 1 „Security governance & risk management“
2 Risikomanagement
Innerhalb des Unternehmens soll ein Prozess eingeführt sein, der die Erfassung und
Bewertung von Risiken für den Geschäftsbetrieb beschreibt und dabei insbesondere auch
Informationssicherheitsrisiken betrachtet. Dies umfasst beispielsweise:
Eine umfassende Strategie zum Risikomanagement bezüglich aller relevanten Prozesse
der Organisation und organisationseigener Informations-Assets, wie z.B. Informationen,
Daten, Anwendungen, Systeme und IKT-Komponenten, die für die Erbringung der
Leistungen der Organisation notwendig sind.
Bestimmung von gesetzlichen, vertraglichen und gesellschaftlichen Anforderungen an die
Organisation
Erfassung von potenziellen Bedrohungen für diese Assets
Oesterreichs Energie 6/19
Bewertung von Schwachstellen, Eintrittswahrscheinlichkeiten und möglichen
Auswirkungen
Insbesondere soll im Risikomanagement die gesellschaftliche Relevanz einer sicheren
Energieversorgung beachtet werden. Sicherheitsrisiken soll mit entsprechenden
Maßnahmen begegnet werden, wobei der Aufwand für die Maßnahmen mit den potenziellen
Schäden infolge des Schadeneintritts korreliert.
Verweise:
OE / BDEW-Whitepaper: -
ISO/IEC TR 27019: 4.2 „Informationssicherheits-Managementsysteme im Bereich
der Energieversorgung“
ENISA Guidelines: Domain 1 „Security governance & risk management“
3 Bedeutung der Personalsicherheit
Eigene Angestellte, Auftragnehmer und Mitarbeiter, die bei Dritten unter Vertrag stehen, sind
Bestandteil des Informationssicherheits-Prozesses. Diese internen und externen Mitarbeiter
sollen entsprechend in den Informationssicherheits-Prozess eingebunden werden. Zu den
umzusetzenden Maßnahmen zählen z.B.:
Internen und externen Mitarbeitern sollen die Bedeutung der Informationssicherheit sowie
damit in Zusammenhang stehende Abläufe und Verfahren im Unternehmen bekannt
gemacht werden
Während der Anstellung sollen regelmäßige Schulungen das Sicherheitsbewusstsein
(Awareness) vertiefen und Mitarbeiter über Neuerungen, wie Sicherheitsbedrohungen,
neue interne oder gesetzliche Bestimmungen usw. in Kenntnis gesetzt werden
Vor der Anstellung bzw. der Beauftragung sollen angemessene Prüfungen der Person
des Mitarbeiters durchgeführt werden, insbesondere dann, wenn Tätigkeiten in sensitiven
Bereichen zum Aufgabengebiet des Mitarbeiters zählen
In Dienstverträgen und ergänzenden Dienstanweisungen sollen Festlegungen zur
Vertraulichkeit enthalten sein
Nach Beendigung der Anstellung bzw. der Beauftragung sollen Benutzerkonten gelöscht,
Zugriffserlaubnisse eingezogen oder ausgehändigte IKT-Systeme zurückgefordert werden
Verweise:
OE / BDEW-Whitepaper: -
ISO/IEC TR 27019: 8 „Personalsicherheit“
ENISA Guidelines: Domain 4 „Personnel security, awareness and training“
Oesterreichs Energie 7/19
4 Sicherheitsvereinbarungen mit Dritten
Dritte, die auf Informationen oder informationsverarbeitende Einrichtungen des
Unternehmens zugreifen, Informationen verarbeiten sowie Systeme administrieren oder
warten, sollen auf relevante Sicherheitsanforderungen hingewiesen und auf deren
Einhaltung verpflichtet werden. Dazu zählen:
Einhaltung von Vertraulichkeit und Verschwiegenheit bezüglich sensitiver Informationen
Maßnahmen zur Sicherstellung des physischen und logischen Schutzes von Systemen
und Anwendungen
Installation eines aktuellen Schadsoftwareschutzes sowie die Sicherheit erhöhende
Updates bzw. Patches des Betriebssystems sowie der Anwendungen auf für
Wartungszugriffe genutzten Systemen, wie z.B. Parametrierlaptops
Maßnahmen, die die Rückgabe oder Vernichtung von Informationen bei Vertragsende
sicherstellen
Anforderungen an das Personal (vgl. Kapitel 3)
Anforderungen hinsichtlich einer funktionierenden Krisen- und Notfallkommunikation im
Fall von Großstörungen, Unfällen usw.
Regelung von Haftungs- und Schadensersatzfragen gemäß Einkaufsbedingungen bei
Verstößen durch Dritte
Ergänzt werden diese Vereinbarungen ggf. durch:
Spezielle Schulungen für Dritte
Definition von Service Levels (SLAs) bei der Erbringung von Leistungen durch Externe
Festlegung von Sicherheitsmaßnahmen, wenn Subunternehmen zum Einsatz kommen.
Diese sollen ebenfalls auf die Einhaltung der Festlegungen verpflichtet werden.
Werden Systeme oder Komponenten im Verantwortungsbereich anderer Energieversorger
betrieben, beispielsweise in Übergabestationen, sollen Sicherheitsanforderungen und ggf.
notwendige Maßnahmen vertraglich festgeschrieben werden.
Verweise:
OE / BDEW-Whitepaper: 2.3.2 „Sichere Wartungsprozesse und RAS-Zugänge“
ISO/IEC TR 27019: 6.2.3 „Adressieren von Sicherheit in Vereinbarungen mit
Dritten“
ENISA Guidelines: Domain 4 „Management of third parties“
Oesterreichs Energie 8/19
5 Schutz sensibler Daten
Sensible Daten, wie z.B. Passwörter, Parametrierdaten, vertrauliche Informationen usw.,
sollen nur verschlüsselt gespeichert oder übertragen werden. Im Rahmen einer
Klassifizierung der Informationen soll der Umfang des notwendigen Schutzes bei Nutzung
der Informationen festgelegt werden.
Informationen werden bezüglich ihres Werts, gesetzlicher Anforderungen und ihrer Kritikalität
für das Unternehmen erfasst, beurteilt und kategorisiert. Es müssen dabei neben
Informationssicherheitsaspekten auch Datenschutzanforderungen berücksichtigt werden.
Offensichtliche Anforderungen an den Schutzbedarf, wie beispielsweise die sichere
Speicherung von Passwörtern, sollen schon in der Standardkonfiguration einer
Softwarekomponente durch den Hersteller realisiert sein. Bei Umgang mit Datenträgern ist
die Sensitivität der darauf gespeicherten Informationen zu berücksichtigen.
Verweise:
OE / BDEW-Whitepaper: 2.1.1.6 „Verschlüsselung sensibler Daten bei Speicherung und
Übertragung“ und 2.1.1.7 „Verschlüsselungsstandards“
ISO/IEC TR 27019: 12.3 „Kryptographische Maßnahmen“ und weitere
ENISA Guidelines: Domain 9 „Information systems security“
6 Sicheres Systemdesign
Die Informationssicherheit im späteren Betrieb wird durch den Entwurf der Systemarchitektur
maßgeblich bestimmt. Wesentliche Grundprinzipien dafür sind:
Komponenten und Benutzer erhalten nur die minimal für den Systembetrieb notwendigen
Rechte und Berechtigungen (vgl. Kapitel 0)
Schutzmaßnahmen werden nicht nur auf einer Ebene, sondern auf mehreren Ebenen,
gestaffelt und sich ergänzend, etabliert
Sicherheitsrelevante Funktionen werden durch den Ausfall einzelner Komponenten nicht
außer Kraft gesetzt
Ergänzt werden diese Maßnahmen durch weitere Designprinzipien, wie beispielsweise
Zugriffs- und Zugangskontrollen oder Deaktivierung aller nicht explizit benötigten Dienste.
Ein „sicheres System“ lässt sich nur implementieren, wenn der gesamte Lebenszyklus von
der Definition der Anforderungen, über die Entwicklung, den Betrieb bis hin zur
Außerbetriebnahme unter Sicherheitsaspekten betrachtet wird.
Es dürfen nur standardisierte Kommunikations- und Anwendungsprotokolle Verwendung
finden. Ausnahmen von dieser Regelung sollen explizit begründet und durch den Betreiber
genehmigt werden. Protokolle, die die Integrität der Informationen bzw. eine Authentisierung
der Kommunikationspartner gewährleisten, sollen bevorzugt eingesetzt werden.
Web-Applikationen sollen nur nach Abstimmung und Freigabe durch den Betreiber unter
Berücksichtigung einer sicheren Netzwerkstruktur zum Einsatz kommen. Auf Grund häufig
auftretender Sicherheitslücken in Web-Applikationen sollen allgemein anerkannte
Sicherheitsempfehlungen, beispielsweise nach den Empfehlungen des Open Web
Oesterreichs Energie 9/19
Application Security Project (OWASP) oder der ÖNORM A-7700 „Informationsverarbeitung -
Sicherheitstechnische Anforderungen an Webapplikationen“ bei der Entwicklung von Web-
Applikationen beachtet werden.
Verweise:
OE / BDEW-Whitepaper: 2.1.1.1 „Sichere Systemarchitektur“, 2.4.3 „Anwendungsproto-
kolle“ und weitere
ISO/IEC TR 27019: 12 „Beschaffung, Entwicklung und Wartung von Informations-
systemen“ und weitere
ENISA Guidelines: Domain 3 „Secure lifecycle process for smart grid
components/systems and operating procedures“
7 Sichere Software-Entwicklung
Die für den Betrieb von Systemen und Komponenten notwendigen Betriebssysteme,
Firmware und Applikationen sollen in einem sicheren und wohlstrukturiertem
Entwicklungsprozess erstellt werden. Die Qualität der Entwicklung soll durch verschiedene
Maßnahmen und Prozesse sichergestellt werden, wie z.B.:
Einsatz von zuverlässigen und fachlich qualifizierten Mitarbeitern, die fortlaufend geschult
werden
Verwendung anerkannter Entwicklungsstandards und Qualitätssicherungs-Prozesse, die
insbesondere auch Informationssicherheitsaspekte berücksichtigen
Softwaretests werden in einem definierten Testverfahren und in von Produktiv-
umgebungen separierten Testumgebungen durchgeführt
Festlegung sicherheitsrelevanter Anforderungen in der Programmierrichtlinie
Versionierung und Änderungs- und Fehlerverfolgung in Quellcode-Verwaltungssystemen
Sicherstellung der Sicherheit der für die Entwicklung genutzten Systeme, beispielsweise
Schutz vor unberechtigten Zugriffen oder Sicherstellung der Integrität des Quellcodes.
Für besonders sensitive Systeme soll im Rahmen der Beauftragung vertraglich vorgesehen
werden, dass der Betreiber im Rahmen einer Auditierung die Einhaltung entsprechender
Qualitätszusagen überprüfen darf, z.B. in Form einer Quellcodeanalyse oder der
Begutachtung des Softwareentwicklungsprozesses.
Verweise:
OE / BDEW-Whitepaper: 2.5.1 „Sichere Entwicklungsstandards, Qualitätsmanagement
und Freigabeprozesse“ und weitere
ISO/IEC TR 27019: 12.5.5 „Ausgelagerte Softwareentwicklung“
ENISA Guidelines: -
Oesterreichs Energie 10/19
8 Sichere Netzwerkstruktur und Kommunikationsprotokolle
Das Design der Netzwerkstruktur sowie die Auswahl der Kommunikationsprotokolle sollen
sowohl funktionalen als auch sicherheitstechnischen Anforderungen genügen. Die
Netzwerkkonzeption soll die folgenden Vorgaben berücksichtigen:
Das Daten- bzw. Kommunikations-Netzwerk wird mit Hilfe von Firewalls, Routern oder
Switches in Zonen bzw. Segmente mit unterschiedlichen Funktionen und
unterschiedlichem Schutzbedarf unterteilt (Netzwerksegregation)
Die Netzwerke verschiedener Anwendungsbereiche (kaufmännische IKT, Leittechnik,
Fernwirktechnik, Smart Metering, Service-Netzwerke, etc.) sollen voneinander getrennt
werden, die notwendige Kommunikation soll ausschließlich über definierte und gesicherte
Übergänge stattfinden
Eine solche Zonierung findet auch Anwendung bei der Anbindung unterschiedlicher
Standorte, die Standorte werden jeweils unterschiedlichen Zonen zugeordnet
Die Kommunikation zwischen geographisch entfernten Standorten oder die Verbindungen
zu Dienstleistern oder anderen Externen sollen kryptographisch gesichert, z.B. in einem
VPN, erfolgen
Funktechnologien, wie WLAN, Bluetooth etc., sollen nur nach einer Risikoabschätzung
und unter Anwendung von entsprechenden Schutzmaßnahmen eingesetzt werden
Netzwerkzugriffe durch Externe im Rahmen von Wartungs- oder Servicearbeiten sollen
nicht direkt in das Prozessnetz durchgreifen, sondern zentral terminiert werden,
beispielsweise auf einem Terminalserver in einer dedizierten DMZ-Zone. Die Struktur und
die verwendeten Technologien bzw. Geräte richten sich nach den ermittelten
Anforderungen an das Kommunikationsnetz (z.B. Bandbreiten, Paketlaufzeiten,
Verzögerungen usw.)
Das Netzwerkkonzept, alle physikalischen oder logischen Verbindungen sowie alle
Schnittstellen sollen ausführlich dokumentiert werden. Diese Dokumentation soll stets auf
dem aktuellen Stand gehalten werden
Hinsichtlich der eingesetzten Technologien sollen die folgenden Anforderungen
berücksichtigt werden:
Protokolle sollen inhärent eine sichere Kommunikation durch Bereitstellung von
Authentifizierung oder Verschlüsselung bzw. einer Integritätsprüfung unterstützen. Bieten
die Protokolle sicherheitserhöhende Optionen, sollen diese genutzt werden
Alle Netzwerk-Komponenten sollen sich in eine zentrale Administration einbinden lassen.
Für administrative Zugriffe werden nur sichere Protokolle eingesetzt
Sicherheitseigenschaften, Service Levels (Vereinbarungen bezüglich maßgeblicher
Verbindungsparameter, wie Bandbreite, Paketverluste oder Verzögerungen) und
Administrationsanforderungen aller Netzdienste sollen ermittelt werden. Dies soll
unabhängig davon geschehen, ob die Dienste intern oder von externen Dritten erbracht
werden
Das Kommunikationsnetz soll durch geeignete Verfahren überwacht werden. Relevante
Ereignisse, ausgelöst durch Nutzer oder Netzdienste, sollen protokolliert werden. Ein
Oesterreichs Energie 11/19
geeignetes Auswerteverfahren, welches Meldungen und Protokolleinträge hinsichtlich ihrer
Kritikalität filtert, soll etabliert werden.
Verweise:
OE / BDEW-Whitepaper: 2.3.1 „Sichere Netzwerkkonzeption und Kommunikations-
verfahren“
ISO/IEC TR 27019: 10.6.1 „Maßnahmen für Netze“ und 10.6.2 „Sicherheit von
Netzdiensten“
ENISA Guidelines: Domain 10 „Network security“
9 Grundsicherung und Systemhärtung
Im Rahmen der Systemhärtung sollen der Funktionsumfang und damit die Anzahl
vorhandener Programme, Software-Module, Dienste und Netzwerkprotokolle auf
Komponenten auf das nötige Minimum reduziert werden. Weiterhin sollen Standard-Nutzer
und -Passworte gelöscht oder deaktiviert, verfügbare Sicherheitsupdates installiert und nicht
benötigte Schnittstellen blockiert werden. Härtungsmaßnahmen sollen sich an Best-Practice-
Empfehlungen oder an Vorgaben der Lieferanten bzw. Hersteller der Komponenten
orientieren.
Die Grundkonfiguration der Systeme bzw. Komponenten soll dokumentiert werden.
Durchgeführte Härtungsmaßnahmen sind in dieser Dokumentation aufzuführen. Die korrekte
Umsetzung der Härtungsmaßnahmen sollte regelmäßig, insbesondere auch nach
Systemänderungen und Updates geprüft und dem aktuellen Stand der Best-Practice-
Empfehlungen entsprechend angepasst werden.
Verweise:
OE / BDEW-Whitepaper: 2.2.1 „Grundsicherung und Systemhärtung“
ISO/IEC TR 27019: 11.1.1 „Leitlinie zur Zugangskontrolle“ und 11.2 „Benutzer-
verwaltung“
ENISA Guidelines: Domain 3 „Secure lifecycle process for smart grid
components/systems and operating procedures“ und Domain 9
„Information systems security“
10 Rollen- und Berechtigungskonzept
Nutzerzugriffe auf Anwendungen, Systeme und Komponenten sollen durch ein
Rollenkonzept gesteuert werden, welches Berechtigungen in einem Benutzerprofil
zusammenfasst. Es sollen Rollen eingerichtet werden, die unterschiedlich gewichtete
Möglichkeiten administrativer oder steuernder Zugriffe erlauben. Für kritische Änderungen
soll die Möglichkeit eines 4-Augen-Prinzips in Erwägung gezogen werden.
Die Erteilung von Zugangs- bzw. Zugriffsberechtigungen soll durch einen formalen Prozess
erfolgen, der beispielsweise Antragsformulare und eine Freigabe des Antrags durch einen
Oesterreichs Energie 12/19
berechtigten Vorgesetzten vorsieht. Der Prozess soll so gestaltet sein, dass Veränderungen
in der Organisation des Unternehmens oder des Benutzers berücksichtigt werden können,
z.B. bei einem Abteilungswechsel.
Der Bedienung eines Systems soll eine Authentifizierung des Benutzers vorausgehen. Bei
sensitiven Systemen soll eine 2-Faktor-Authentifizierung zur Anwendung kommen, die
beispielsweise Token, Smartcards oder biometrische Merkmale in Kombination mit einem
Passwort verwendet. Passwörter sollen den Passwortregelungen des Unternehmens
entsprechen.
Authentifizierungsinformationen sollen zentral verwaltet und durch geeignete technische
Maßnahmen stark gesichert gespeichert und übertragen werden. Erfolgreiche und
fehlgeschlagene Anmeldeversuche sowie alle Benutzeraktivitäten sollen unter
Berücksichtigung der entsprechenden Datenschutzvorschriften überwacht und protokolliert
werden.
Verweise:
OE / BDEW-Whitepaper: 2.4.1 „Benutzerverwaltung“
ISO/IEC TR 27019: 11.1.1 „Leitlinie zur Zugangskontrolle“ und 11.2 „Benutzer-
verwaltung“
ENISA Guidelines: Domain 9 „Information systems security“
11 Konfigurations- und Änderungsmanagement
Herstellerseitige Voreinstellungen von Systemen (z.B. Authentifizierungs-Informationen,
Nutzernamen, Konfigurationseinstellungen und -parameter) sollen erfasst und bei Bedarf
durch eine sichere Konfiguration ersetzt werden. Die so erzeugte Installation soll
dokumentiert werden.
Für Änderungen an Systemen beispielsweise durch Installation von Funktionserweiterungen,
Updates und Patches oder durch Parametrierungs-, Konfigurations- oder
Hardwareänderungen soll ein definierter Prozess zum Änderungsmanagement eingeführt
werden, der die Planung, Bewertung, Durchführung und Dokumentation von Änderungen
regelt und für sensitive und betriebskritische Änderungen auch ein Genehmigungsverfahren
umsetzt. Mindestens ein älterer Datenstand (Software-/ Firmwarestand, Datenmodell,
Parametrierung, etc.) soll gesichert und eine Rollbackmöglichkeit vorgesehen, dokumentiert
und ggf. getestet werden. Ein geeigneter Verwaltungsprozess für die eingesetzten
Softwareversionen soll implementiert werden.
Verweise:
OE / BDEW-Whitepaper: 2.5.5 „Konfigurations- und Change-Management, Rollback-
möglichkeiten“
ISO/IEC TR 27019: 10.1.2 „Änderungsverwaltung“ und 12.4.1 „Kontrolle von
Software im Betrieb“
ENISA Guidelines: Domain 3 „Secure lifecycle process for smart grid components /
systems and operating procedures“
Oesterreichs Energie 13/19
12 Patch- und Versionsmanagement
Software-Patches beseitigen Schwachstellen, Sicherheitslücken und funktionale Fehler oder
fügen Applikationen, Betriebssystemen oder Firmware neue oder verbesserte Funktionen
hinzu.
Die Softwareinstallation von Prozessteuerungs-Komponenten und der zugehörigen
Konfigurations- und Managementsysteme soll patchfähig sein, damit bekannt gewordene
Sicherheitslücken beseitigt werden können. Dies umfasst neben Betriebssystem und
Firmware auch Applikationen und Hilfskomponenten. Software, die von Dritten bezogen wird
(sogenannte 3rd-Party-Software), soll sich ebenfalls in den Patch- bzw. Updateprozess
einbinden lassen. Das Einspielen von Patches und Updates soll den normalen Betrieb nicht
unterbrechen und die Verfügbarkeit des Gesamtsystems nur gering beeinflussen. Updates
auf prozessnahen Komponenten (Steuerungen, Controller, Fernwirk- oder Schutzgeräte
usw.) sind häufig nur während einer Anlagenaußerbetriebnahme (Wartung, Revision)
möglich. Um die Verfügbarkeit von Sicherheitsupdates zu gewährleisten, sollen nur aktuelle
und absehbar noch im Support befindliche Softwareversionen beschafft und in Betrieb
genommen werden. Die Patchfähigkeit der Systeme soll über den gesamten Lebenszyklus
durch regelmäßige Upgrades auf eine noch im Support befindliche Version sichergestellt
werden.
Die Anzahl notwendiger Patches und damit von Betriebsunterbrechungen kann minimiert
werden, indem Komponenten gehärtet werden. Damit wird die Anzahl der Dienste und
Schnittstellen auf das notwendige Minimum begrenzt.
Der Hersteller / Lieferant der Komponenten soll die organisatorischen und technischen
Aspekte des Patchprozesses umfassend beschreiben. Hierzu zählen z.B. die
Vorgehensweise und Zyklen zur Patch-Bereitstellung, Test- und Freigabeprozesse durch
den Hersteller / Lieferanten sowie die konkrete Vorgehensweise zur Patchinstallation sowie
Deinstallation bzw. Rollbackverfahren für fehlerhaft installierte Patches.
Um Fehlfunktionen durch Patches zu vermeiden, müssen diese intensiv getestet werden. In
der Regel erfolgt eine umfassende Prüfung vorab durch den Systemlieferanten. Der
Betreiber soll ergänzend einen Test der Grundfunktionen vor der Inbetriebnahme der
gepatchten Komponente durchführen. Die notwendigen Testfälle und deren Durchführung
müssen in der Hersteller-Dokumentation beschrieben sein. Bei kritischen Systemen ist eine
umfassende Prüfung in einem vom Prozess isolierten Testsystem sowie eine umfassende
Planung und Vorbereitung des Roll-Out-Prozesses notwendig, um den sicheren Betrieb nicht
zu gefährden.
Ggf. werden Meldewege von Sicherheitslücken oder Schwachstellen durch den Hersteller /
Lieferant bzw. die Bereitstellung von Updates / Patches in einem separaten Wartungsvertrag
festgelegt.
Oesterreichs Energie 14/19
Verweise:
OE / BDEW-Whitepaper: Kapitel 2.1.1.3 „Patchfähigkeit, Patchmanagement“ und weitere
ISO/IEC TR 27019: 12.6.1 „Kontrolle technischer Schwachstellen“
ENISA Guidelines: Domain 3 „Secure lifecycle process for smart grid
components/systems and operating procedures“
13 Schadsoftwareschutz
Vernetzte, IP-basierende Systeme sollen mit einem Schadsoftwareschutz versehen sein. Ist
dies nicht möglich, beispielsweise bei sogenannten Embedded-Komponenten, soll alternativ
ein Konzept vom Hersteller / Lieferant vorgelegt werden, welches einen gleichwertigen
Schutz bietet, beispielsweise ein Perimeterschutz auf Schnittstellen. Die Kompatibilität des
Schadsoftwareschutzes zu den Applikationen und Komponenten der Prozessumgebung soll
unter Berücksichtigung der Empfehlungen des Herstellers / Lieferanten im Vorfeld verifiziert
werden.
Ein Schadsoftwareschutz kann entweder signaturbasiert (Blacklisting) oder als Whitelisting-
Lösung, die die Ausführung von nicht freigegebenen Programmen und Programmcode
verhindert, implementiert werden, wobei eine Kombination beider Varianten die
Schutzwirkung vor Schadsoftware erhöht. Die Konfiguration und Pflege der Schutzsoftware,
dazu zählt beispielsweise der Zyklus der Aktualisierung der Pattern bei signaturbasierten
Lösungen und deren Prüfung und Freigabe, soll gemeinsam mit dem Hersteller / Lieferanten
definiert und dokumentiert werden.
Verweise:
OE / BDEW-Whitepaper: Kapitel 2.2.2 „Antiviren-Software“
ISO/IEC TR 27019: 10.4.1 „Maßnahmen gegen Schadsoftware“
ENISA Guidelines: Domain 9 „Information systems security“
14 Sichere Wartungsprozesse
Im Rahmen von Wartungsarbeiten werden durch einen Dienstleister Service-Maßnahmen
durchgeführt mit dem Ziel, Systeme instand zu halten, Fehler oder Störungen zu beseitigen
oder Optimierungen bzw. Anpassungen an Komponenten / Systemen vorzunehmen.
Diesbezügliche Tätigkeiten können sowohl vor-Ort als auch im Rahmen sogenannter
Fernzugriffe erfolgen. In jedem Fall sollen an das Wartungspersonal, die für die Wartung
eingesetzten Systeme und an die Umgebung, aus der heraus die Zugriffe erfolgen,
besondere Sicherheits-Anforderungen gestellt werden:
Wartungspersonal des Dienstleisters soll gegenüber dem Betreiber benannt und
hinsichtlich der Systemumgebung des Betreibers geschult sein
Fernwartungs- und Vor-Ort-Zugriffe auf Systeme und Komponenten des Betreibers sollen
nur von speziell gesicherten Systemen des Dienstleisters aus erfolgen
Oesterreichs Energie 15/19
Fernwartungszugriffe sollen beim Dienstleister nur aus einer abgesicherten DMZ-
Umgebung erfolgen und bedürfen einer starken Authentifizierung des Wartungspersonals
sowie einer separaten Freigabe durch den Betreiber
Wartungssysteme des Dienstleisters sollen folgende Eigenschaften aufweisen:
Sicherer logischer Zugangsschutz und Schutz vor unberechtigtem physischen Zugriff
Die Systeme sollen gehärtet und mit aktuellem Schadsoftwareschutz und
Softwarepatches sowie einer restriktiv konfigurierten Firewall ausgestattet sein
Die Durchführung der Wartung und die damit verbundenen technischen und
organisatorischen Randbedingungen sollen zwischen Betreiber und Dienstleister schriftlich
fixiert werden, beispielsweise innerhalb eines Wartungs- oder Instandhaltungsvertrags.
Der Betreiber soll für die Fernwartung eine abgesicherte Fernwartungsinfrastruktur
aufbauen. Eine direkte Kopplung der Netze der Dienstleister mit der Prozessumgebung des
Betreibers soll verhindert werden (siehe hierzu auch Kapitel 0). Wartungsprozesse sollen
durch den Betreiber überwacht und protokolliert werden.
Verweise:
OE / BDEW-Whitepaper: Kapitel 2.3.2 „Sichere Wartungsprozesse und RAS-Zugänge“
ISO/IEC TR 27019: 6.2.1 „Identifizierung von Risiken in Zusammenhang mit
externen Mitarbeitern“ und weitere
ENISA Guidelines: Domain 9 „Information systems security“
15 Physische und umgebungsbezogene Sicherheit
Sensitive informationsverarbeitende Einrichtungen sollen in Sicherheitsbereichen platziert
werden, die durch Zugangskontrollsysteme und Sicherheitsbarrieren vor unberechtigtem
Zutritt, Beschädigungen oder Störungen, beispielsweise in Folge von Naturereignissen
geschützt sind. Abhängig von der Sensitivität der Systeme sollen ergänzenden Maßnahmen,
wie Einbruchmeldesysteme oder ein Objektschutz, in Erwägung gezogen werden. Werden
sensitive Komponenten in dezentralen Standorten, wie z.B. Umspannwerken, betrieben,
sollen sie in separaten Technikräumen oder Schränken platziert werden. Wenn
Komponenten auf öffentlichem Gelände oder in Umgebungen Dritter verbaut werden, soll ein
hinreichender physischer Schutz, z.B. durch verstärkte Gehäuse oder Öffnungskontakte
vorgesehen werden.
Zutritte zu Sicherheitszonen sollen überwacht und protokolliert werden. Ein Zutritt soll nur
nach einer Authentisierung des Mitarbeiters gewährt werden. Dafür kommen
unterschiedliche technische Maßnahmen, wie beispielsweise biometrische Merkmale oder
Zugangs-Chipkarten, in Frage. Diese Regelungen sollen so gestaltet sein, dass sie auch auf
Besucher oder Dritte (z.B. Mitarbeiter von Dienstleistern) angewendet werden können.
Vergebene Zutrittsberechtigungen sollen dokumentiert werden. Sie sind periodisch auf
Aktualität zu überprüfen. Nicht mehr benötigte Zutrittsberechtigungen, beispielsweise nach
Beendigung von Wartungsarbeiten, sollen zeitnah entzogen werden.
Oesterreichs Energie 16/19
Verweise:
OE / BDEW-Whitepaper: -
ISO/IEC TR 27019: 9.1.1 „Sicherheitszonen“ und weitere
ENISA Guidelines: Domain 8 „Physical security“
16 Protokollierung und Überwachung
Die Überwachung von Systemen soll Informationssicherheitsereignisse aufzeichnen. Dazu
gehören administrative Tätigkeiten, aufgetretene Fehler oder sonstige Ereignisse, wie das
Betreten einer Sicherheitszone durch eigene Mitarbeiter oder durch Dritte.
Die Nachvollziehbarkeit von Handlungen wird sichergestellt, indem Zeitpunkt, Nutzername
und durchgeführte Handlungen / Nutzeraktivitäten protokolliert werden. Der Prozess der
Überwachung soll hinsichtlich der folgenden Punkte genauer spezifiziert sein:
Aufbau einer technischen Infrastruktur, in der Meldungen und Alarme erfasst, gespeichert
und ausgewertet werden
Festlegung der organisatorischen Abläufe im Alarm- oder Ereignisfall
Definition der aufzuzeichnenden Parameter und einer Auslöseschwelle für eine
Protokollierung
Auswerteregime (wer wertet in welchen Zeiträumen Aufzeichnungsprotokolle aus?) unter
Beachtung des Datenschutzes
Schutz der Aufzeichnungsprotokolle gegen Manipulation und Überschreiben
Definition einer einheitlichen Systemzeit durch Nutzung von zentralen Zeitservern
Aufbau eines Alarmmanagements, welches bestimmte Ereignisse an benannte Personen
oder Systeme unverzüglich weitermeldet
Verweise:
OE / BDEW-Whitepaper: 2.4.6 „Protokollierung, Audit-Trails, Timestamps, Alarm-
konzepte“
ISO/IEC TR 27019: 10.10 „Überwachung“ und weitere
ENISA Guidelines: Domain 6 „Audit and accountability“
17 Datensicherung und Wiederherstellung
Die Datensicherung und Wiederherstellung einzelner Anwendungen, des Gesamtsystems
und der jeweiligen Konfigurationsstände soll definiert und dokumentiert sein. Dafür sollen
eine angemessene technische Ausstattung, ausführliche Beschreibungen der Abläufe sowie
entsprechend geschultes Personal vorgehalten werden. Die Sicherungs- und
Wiederherstellungsprozesse sollen regelmäßig getestet und trainiert und bei Veränderungen
angepasst werden.
Für die Datensicherung verwendete Speichermedien sollen sicher und getrennt vom
Produktivsystem aufbewahrt und periodisch einer technischen Überprüfung unterzogen
Oesterreichs Energie 17/19
werden. Sicherheitskritische Datensicherungen sollen geschützt abgelegt bzw. gespeichert
werden, z.B. durch Einsatz von Verschlüsselung.
Verweise:
OE / BDEW-Whitepaper: 2.6.1 „Backup: Konzept, Verfahren, Dokumentation, Tests“
ISO/IEC TR 27019: 10.5 „Backup“
ENISA Guidelines: Domain 7 „Continuity of operations“
18 Reaktion auf Sicherheitsereignisse, Notfall- und Incidentmanagement
Der Betreiber soll technische und personelle Kapazitäten vorhalten sowie Prozesse
definieren, um auf Sicherheitsvorfälle angemessen reagieren zu können.
Bedrohungsanalysen in Bezug auf die Prozessumgebung sollen durchgeführt und in deren
Ergebnis Gegenmaßnahmen ergriffen werden.
Notfall- und Krisenszenarien sollen auf Seiten des Betreibers im Rahmen eines
bereichsübergreifenden Risiko- und Notfallmanagements identifiziert, bewertet, dokumentiert
und in ihrer Durchführung trainiert werden. Dabei sollen insbesondere Störungen oder
Ausfälle von kritischen IKT- und Prozesssteuerungsumgebungen betrachtet werden. Es
sollen essentielle Prozesse identifiziert werden, deren Weiterbetrieb im Notfall gewährleistet
werden muss (z.B. Not-Betriebsführung in den Anlagen oder Sicherstellung einer
Notfallkommunikation). Für identifizierte Szenarien sollen Notfallkonzepte und
Wiederanlaufplanungen dokumentiert und getestet werden.
Akzeptable maximale Ausfall- und Wiederanlaufzeiten sollen definiert sein. Dokumentation
und Verfahren sollen bei relevanten System-Updates angepasst und im Rahmen des
Abnahmeverfahrens für Release-Wechsel erneut getestet werden.
Betreiber energietechnischer Anlagen sollen sicherstellen, dass
Kommunikationsverbindungen (Sprache und Daten) zu relevanten Systemen und
Organisationen in einer Notfallsituation funktionstüchtig sind. Sie unterliegen einer
gesonderten Notfallvorsorge in Eigenregie des Betreibers.
Verweise:
OE / BDEW-Whitepaper: Kapitel 2.6.2 „Notfallkonzeption und Wiederanlaufplanung“
ISO/IEC TR 27019: Kapitel 14 „Business Continuity Management“
ENISA Guidelines: Domain 7 „Continuity of operations“
Oesterreichs Energie 18/19
Literatur
Oesterreichs Energie und BDEW: „Anforderungen an sichere Steuerungs- und
Telekommunikationssysteme, Ausführungshinweise zur Anwendung des BDEW Whitepaper,
Version 1.0“
ISO/IEC 27019:2013: „Information Technology - Security techniques - Information security
management guidelines based on ISO/IEC 27002 for process control systems specific to the
energy utility industry“
European Network and Information Security Agency (ENISA): „Appropriate security
measures for smart grids, Guidelines to assess the sophistication of security measures
implementation, Version 1.7“
Oesterreichs Energie 19/19
Abkürzungsverzeichnis
Abkürzung Erläuterung
DMZ Demilitarisierte Zone. Bezeichnet ein Netzwerksegment zwischen
einem geschützten Netzwerk (Unternehmens-LAN, technische Netze
etc.) und einem unsicheren Netzwerk (bspw. Internet, Dienstleister,
Partnerunternehmen etc.), in dem Zugriffe aus dem unsicheren
Netzwerk heraus terminiert werden. Meist werden innerhalb einer DMZ
Schnittstellendienste bereitgestellt.
IKT Informations- und Kommunikationstechnik
IP Internet Protocol
LAN Local Area Network. In seiner Ausdehnung begrenztes
Kommunikationsnetzwerk. Meist wird damit das Netzwerk eines
Unternehmens oder eines Unternehmensstandortes beschrieben.
OWASP Open Web Application Security Project. Eine Organisation, die das Ziel
verfolgt, die Sicherheit von Anwendungen und Diensten, die auf
Webtechnologien basieren, zu verbessern
RAS Remote Access Services. Fernzugänge über ein ungeschütztes
Netzwerk auf Komponenten innerhalb der geschützten Netzwerk-
Umgebung des Unternehmens
SLA Service Level Agreements. Vereinbarungen zwischen zwei Parteien
bezüglich der Dienstgüte bei der Erbringung von Leistungen.
VPN Virtuelles Privates Netzwerk. Zusammenfassung von Techniken, um
geographisch auseinander liegende Standorte eines Unternehmens
sicher über ein als unsicher eingestuftes Übertragungsnetz (meist das
Internet) zu verbinden. Die Sicherheit wird durch kryptographische
Verfahren gewährleistet. Dabei werden die Authentizität, Integrität und
Vertraulichkeit von Nachrichten sichergestellt.
WLAN Wireless Local Area Network. Eine Funktechnologie zur drahtlosen
Datenübertragung innerhalb eines LAN.
