within a safety critical context
Most control room operators have a strong focus on safety. Successful cyber-attacks can disrupt such critical procedures. IT security threats are one possible root cause for safety hazards.
Legislators globally have reacted to this problem by enacting new laws targeting cybersecurity of vital infrastructures. At the same time, integrating IT security practices with safety requirements is not necessarily easy as many common security practices conflict with safety. At times, organisations may feel that they are in a no-win scenario. So how can security be achieved in a safety-critical context?
Watch our video and get more details!
Ohne Security gibt es keine Safety. Gleichzeitig stehen einige bewährte IT-Security-Verfahren im Widerspruch zu Safety-Anforderungen. Bewährte Security-Verfahren erfordern beispielsweise den Einsatz wichtiger System-Updates, sobald diese verfügbar sind, was aber unter Umständen gegen Software-Assurance-Verordnungen verstoßen kann. Darüber hinaus lauern weitere Herausforderungen: starke Passwörter und der Einsatz von Passwortblockierungen sind für den Schnellzugriff im Notfall nicht gerade hilfreich, Antivirus-Software bricht möglicherweise – nach einem Update – die Ausführung eines wichtigen Prozesses ab. Solche Konflikte bringen die verantwortlichen Organisationen in eine schwierige Situation: Safety hängt von Security ab und beides muss im Rahmen der Sorgfaltspflicht für den Betrieb der Infrastruktur angemessen verwaltet werden.
Die Schwierigkeit, Security- und Safety-Anforderungen in einer gemeinsamen Lösung zu vereinen, ist eines der Hauptthemen der Operational Technology (Betriebstechnologie; OT). Daher haben sich – neben den bekannten und bewährten IT-Security-Verfahren – in einigen Bereichen unterschiedliche Konzepte und Best Practices für die Absicherung von OT etabliert. Die IT-Security konzentriert sich auf den Schutz von Daten, die OT-Security befasst sich mit dem Schutz von Betriebsabläufen und Prozessen.
Systemarchitektur, die Safety und Security unterstützt
In sicherheitskritischen Umgebungen rät Frequentis zur Einführung von „Protection Zones“ (Schutzzonen), um den jeweils passenden Mix von IT- und OT-Security-Konzepten an den richtigen Stellen anzuwenden. Schutzzonen werden definiert als eine Zusammenfassung von Hardware, Software und Personal mit einem gemeinsamen Trust Level (Vertrauensstufe).
Die Systeme von Frequentis umfassen für gewöhnlich drei unterschiedliche Protection Zones: Die „Internal Zone“ (interne Zone), ohne direkte Verbindungen zu anderen Systemen, die „Shared Zone“ (gemeinsame Zone), mit Verbindungen zu anderen „vertrauenswürdigen“ Netzwerken, und die „Public Zone“ (öffentliche Zone), mit Verbindungen in eine nicht vertrauenswürdige Umgebung (z. B. ein öffentliches Netz). Bei der Integration des Subsystems von Frequentis in das Gesamtsystem vor Ort ist es einerseits wichtig, die Protection Zones zu respektieren, und andererseits, für Security auf Gesamtsystemebene zu sorgen. Die Security eines Subsystems hängt von der Security des Gesamtsystems ab.
Um Security- und Safety-Anforderungen auf Gesamtsystemebene zu erfüllen, können nun für jede Schutzzone spezifische Maßnahmenkombinationen angewendet werden. Beispiele hierfür sind: häufiges Einspielen von Patches in der öffentlichen Zone versus gesicherte Software-Revisionen in der internen Zone; strikte Kontosperrpolitik in der öffentlichen Zone versus Zugriffsüberwachung ohne automatische Kontosperre in der internen Zone. Voraussetzung für diese Methodik ist ein Systemdesign, das es ermöglicht, einzelne Systemfunktionen gemäß der Safety-Kritikalität und dem Schutzbedarf den jeweils entsprechenden Protection Zones zuzuordnen.
Diese Architektur ermöglicht ein angemessenes Gleichgewicht von Security und Safety auf der Grundlage eines risikobasierten Ansatzes (im Gegensatz zu einem rein Compliance-basierten Ansatz, der zu unlösbaren Konflikten von Safety- und Security-Anforderungen führen würde).
Die Basis für das sichere Design, die sichere Programmierung und die Security-Verifizierung von Frequentis-Produkten bildet die Frequentis System Security Policy. Diese basiert auf den wichtigsten System-Security-Standards verschiedener Länder, wie dem BSI Grundschutz (Deutschland), NIS (USA), ISM (Australien) usw. und stellt einen gemeinsamen Minimal-Security-Standard für alle Frequentis Produkte sicher. Darüber hinausgehende kundenspezifische Security-Anforderungen können zusätzlich implementiert werden.
Die Frequentis System Security Policy kommt auch dann zum Tragen, wenn verschiedene Frequentis-Produkte miteinander kombiniert, angepasst und mit Komponenten von Drittanbietern integriert werden, um so ein kundenspezifisches Projekt zu realisieren. Ein wichtiger Meilenstein eines jeden Projekts ist die Security-Planung zu Projektbeginn, bei der zusammen mit dem für die System-Security zuständigen Team die Security-Anforderungen abgestimmt und Schutzzonen definiert werden. Bei Bedarf wird zusätzlich eine Security-Risikobewertung durchgeführt.
Vor der Lieferung wird geprüft, ob die Security-Anforderungen vollständig erfüllt sind. Nach der Lieferung wird die Verantwortung für die Security des Systems an den Kunden übergeben. Frequentis übermittelt dem Kunden alle notwendigen Passwörter und Schlüssel sowie die Secure Operations Guideline. Damit beginnt die Wartungsphase, in der der Kunde die Verantwortung für die Systemsicherheit trägt. Da laufend neue Angriffsmethoden bekannt werden, die die Security eines Systems beeinträchtigen können, muss jeden Tag von Neuem an der Security gearbeitet werden.
Jede einzelne der erforderlichen Aufgaben zur Gewährleistung der Systemsicherheit muss von irgendjemandem erledigt werden. Gestaltbar ist, wie diese Aufgaben zwischen dem Systembetreiber, den Herstellern und, sofern relevant, den Integratoren aufgeteilt werden. Einige Systembetreiber verfügen über ein dediziertes Security-Team und benötigen lediglich minimale allgemeine Security-Support-Leistungen, wie das Bereitstellen von Applikations-Patches und das Testen von Patches, um die Kompatibilität mit den selbst eingekauften Standardprodukten zu gewährleisten.
Andere hingegen betreiben hochgradig kundenspezifische Systeme oder möchten den Umstieg auf neue Produktversionen vermeiden und ihr spezifisches System weiter betreiben. In diesen Fällen sind dedizierte systemspezifische Security-Support-Leistungen erforderlich. Andere Systembetreiber wollen möglichst viele Security-Aufgaben von den Herstellern erledigen lassen. Sie bevorzugen es, bei den Herstellern, Integratoren oder Dritten erweiterte Security-Support-Leistungen einzukaufen, statt ein eigenes Security-Team zu unterhalten. Aber ganz gleich, wie sich die Zusammenarbeit konkret gestaltet – alle Beteiligten eint das gemeinsame Ziel: Der Systembetreiber soll in der Lage sein, gegenüber den Regulierungs- und Aufsichtsbehörden jederzeit nachweisen zu können, dass er alle Sorgfaltspflichten ordnungsgemäß erfüllt hat.
Eine Anmerkung zu Altsystemen
Viele Organisationen betreiben Altsysteme, die vor etlichen Jahren entwickelt und gekauft wurden. Diese Systeme mögen zwar weiterhin die Produktivitätsanforderungen erfüllen und alles an Funktionen bieten, was die Betreiber benötigen, aber die Cyberbedrohungen und die Lösungen zum Schutz von Systemen haben sich in den letzten Jahren grundlegend geändert. Wenn die Security dieser Systeme nicht kontinuierlich auf dem aktuellen Stand gehalten wurde, ist es ratsam, diese Systeme einem Security-Health-Check zu unterziehen.
