Mechanismen und Maßnahmen
Systemintegrität als Kernelement
Im ersten Teil des Beitrags wurden aktuelle Entwicklungen der Bedrohungslage im Umfeld der Industrial Security und die Norm IEC62443 als Basis für eine Verteidigungsstrategie dargestellt. Der vorliegende zweite Teil befasst sich mit bewährten funktionalen, technischen Mechanismen und Maßnahmen zur Gewährleistung der Systemintegrität. Anschließend wird auf die Anforderungen der IEC62443 hinsichtlich des sogenannten Echtheits- bzw. Originalitätsnachweises und der sogenannten Public-Key-Infrastruktur, die im Kontext der Systemintegrität von Bedeutung sind, eingegangen.
Bild: Siemens AGZur Gewährleistung der Systemintegrität im Kontext einer industriellen Anlage tragen verschiedene, sorgfältig aufeinander abgestimmte, zuverlässige und möglichst rückwirkungsfreie funktionale Mechanismen und Maßnahmen bei. Mittlerweile haben sich die folgenden Mechanismen und Maßnahmen sehr gut bewährt:
- • Know-how-Schutz als Schutz der Algorithmen gegen unberechtigte Zugriffe und Modifikationen. Im Kontext der speicherprogrammierbaren Steuerungen (englisch Industrial Controller) wird dazu beispielsweise durch den Passwortschutz der Bausteine und deren Verschlüsselung beigetragen.
- • Kopierschutz als Schutz der Programme gegen unberechtigte Vervielfältigung, der beispielsweise für speicherprogrammierbare Steuerungen durch die Verknüpfung der Bausteine mit der Seriennummer des zugehörigen Geräts realisiert werden kann.
- • Manipulationsschutz als Schutz der übertragenen Daten vor unberechtigter Manipulation. Beispielsweise wird mit Hilfe entsprechender Mechanismen zum Manipulationsschutz die Manipulation von übertragenen Engineering-Daten erkannt.
- • Zugriffsschutz als Schutz der Geräte und Systeme vor dem unberechtigten Zugriff auf system- oder prozessrelevante Funktionen, der beispielsweise für speicherprogrammierbare Steuerungen als Passwortschutz (im Idealfall als Bestandteil einer anlagenweiten zentralen Benutzerverwaltung) realisiert werden kann.
- • Deaktivierung von Diensten und Ports in der Grundkonfiguration der Produkte. Erst wenn diese Dienste im Rahmen einer Automatisierungslösung genutzt werden sollen, werden sie durch Konfiguration aktiviert. Das Abschalten nicht benötigter Dienste und Ports wird oft als Härtung (engl. Hardening) bezeichnet.
- • Whitelisting zur Sicherstellung, dass nur erwünschte und nicht manipulierte Programme auf PC-basierten Systemen ausgeführt werden können und dadurch zum sicheren Betrieb der Engineering-Software, der HMI-Systeme und der Prozessleitsysteme wie z.B. Simatic PCS 7 - gerade im Hinblick auf Zero Day Exploits - beigetragen wird. Um einen einwandfreien Betrieb der Produkte mit den Whitelisting-Mechanismen sicherzustellen, sind Verträglichkeitstests erforderlich.
- • Virenscanner zur Erkennung und Beseitigung von Schadsoftware. Wie beim Whitelisting sollen die entsprechenden Produkte an die Rahmenbedingungen der Automatisierungslösung angepasst sein, was fundierte Verträglichkeitstests notwendig macht.
Bild: Siemens AGOriginalität und Echtheit nachweisen
Als weitere Mechanismen zur Gewährleistung der Systemintegrität, die insbesondere im Hinblick auf Industrie 4.0. an Bedeutung gewinnen, sind die Mechanismen zum Nachweis der Originalität bzw. Echtheit (engl. Originality) von Geräten, beispielsweise die sogenannten Gerätezertifikate, zu erwähnen. Die den Security Levels 3 bis 4 entsprechende Anforderung des Entwurfs der IEC62443-4-2 hinsichtlich der Steuerungskomponenten lautet wie folgt:
? ECR 3.10 - Originality
Requirement: The embedded device shall provide a proof of originality mechanism.
Die den Security Levels 2 bis 4 entsprechende Anforderung des
Entwurfs der IEC62443-4-2 hinsichtlich der PC-basierten Systemen und Netzwerkkomponenten lauten wie folgt:
? HCR 3.10 - Originality
Requirement: The host device shall provide a proof of originality mechanism.
Requirement enhancement: (1) Unalterable proof of originality The proof of originality shall be provably unalterable and uncloneable.
? NCR 3.10 - Originality
Requirement: The network component shall provide a proof of originality mechanism.
Requirement enhancements: (1) Unalterable proof of originality The proof of originality shall be provably unalterable and uncloneable. @Aufzählung 2:
Während die Mechanismen zum Nachweis der Originalität bzw. der Echtheit bereits während der Fertigung diverser Geräte implementiert werden müssen, kommen die sogenannten operativen Zertifikate erst zur Laufzeit im Anlagenkontext zum Einsatz. Das Ziel ist hier, die Authentifikation und Kommunikationsintegrität durch kryptographische Mittel zu erreichen. Der im Gerät sicher hinterlegte, private Schlüssel wird an den zugehörigen öffentlichen Schlüssel gebunden. Dabei wird die automatisierte Unterstützung der Abläufe zum Management von derartigen Zertifikaten und den zugehörigen kryptographischen Schlüsseln im Kontext einer Public Key Infrastruktur (PKI) - insbesondere als Basis für die sichere Kommunikation zwischen den Applikationen und Geräten - zunehmend wichtig. Durch die Reduktion der manuellen Aktionen im Rahmen des Zertifikatsmanagements und zunehmend automatisierte Abläufe auf der Basis von Standardprotokollen (insbesondere zum Ausrollen und Erneuerung von Zertifikaten) wird zur Erhöhung der Flexibilität und der Interoperabilität im Anlagenkontext beigetragen. Die den Security Levels 2 bis 4 entsprechende Anforderung der IEC62443-3-3 hinsichtlich der PKI-Nutzung im Kontext eines aus verschiedenen Applikationen und Geräten zusammengesetzten Systems lautet (abgekürzt) wie folgt.
? 5.10 SR 1.8 - Public key infrastructure (PKI) certificates
5.10.1 Requirement: Where PKI is utilized, the control system shall provide the capability to operate a PKI according to commonly accepted best practices or obtain public key certificates from an existing PKI.
Durch die genannte Anforderung hinsichtlich des Systems wird die folgende, in der IEC62443-4-2 aufgeführte, den Security 2 bis 4 entsprechende Anforderung hinsichtlich Applikationen und Geräten impliziert:
? CR 1.8 - Public key infrastructure certificates
Requirement: When public key infrastructure (PKI) is utilized, the application or device shall provide the capability to interact and operate within the scope of the PKI according to IEC 62443-3-3.
Bild: Siemens AGProaktive Erkennung von
Angriffen und Abweichungen
Einen besonderen Stellenwert bekommt im Hinblick auf das erhöhte Bedrohungspotenzial, das besonders durch die im Kontext der im Teil 1 genannten Trends bedingt ist, eine proaktive Erkennung von Hinweisen auf mögliche Angriffe, Anomalien und Richtlinienverletzungen, sowie die langfristige Speicherung von Security-relevanten Informationen mit Hilfe adäquater Werkzeuge. Aufgrund des im Juli 2015 in Kraft getretenen IT-Sicherheitsgesetzes wird eine derartige proaktive Erkennung und die Rückverfolgbarkeit auf Basis der langfristigen Speicherung von Security relevanten Informationen für die Betreiber der kritischen Infrastrukturen zukünftig noch wichtiger als zuvor werden. Im industriellen Umfeld bezeichnet man obengenannte adäquate Werkzeuge als Industry Security Information Event Management (Industry SIEM). Sie ermöglichen eine Erhöhung des Schutzniveaus von Komponenten, Systemen und Anlagen und tragen zur Konformität mit den Anforderungen der relevanten Standards bei. In der Norm IEC62443-3-3 ist die entsprechende Anforderung so formuliert:
? "SR 2.8 - Auditable events
6.10.1 Requirement: The control system shall provide the capability to generate audit records relevant to security for the following categories: access control, request errors, operating system events, control system events, backup and restore events, configuration changes, potential reconnaissance activity and audit log events. Individual audit records shall include the timestamp, source (originating device, software process or human user account), category, type, event ID and event result."
Die Bedeutung von 'Security Events'
Eine essenzielle Voraussetzung für einen nutz- und erfolgsbringenden Einsatz derartiger Werkzeuge besteht darin, dass die in den industriellen Anlagen eingesetzten Komponenten und Systeme diverse 'Security Events' erfassen und über standardisierte Schnittstellen bereitstellen können. Eine weitere wichtige Voraussetzung bildet das Vorhandensein von durchdachten, auf die jeweilige Anlage zugeschnittenen Korrelationsregeln zur Erkennung von Hinweisen auf diverse Angriffsszenarien und Verletzungen von obligatorischen Richtlinien. Derartige Regeln können in verschiedene allgemeine, normspezifische, industriespezifische, IT-spezifische, herstellerspezifische und anlagenspezifische Kategorien unterteilt werden. Durch die Anbindung einer Anlage an ein sogenanntes Cyber Security Operation Center (CSOC) wird die Nutzung der weltweiten Informationen über Bedrohungen - sogenanntes Threat Intelligence, die umfassende Korrelationsregeln beinhaltet - ermöglicht. Von dort aus prüfen Industrial-Security-Spezialisten Industrieanlagen auf mögliche Cyberbedrohungen. Sie überwachen proaktiv globale Schwachstellen und Aktivitäten zu Cyberbedrohungen, um möglichst schnell Warnungen und Hinweise herauszugeben. Falls ein erhöhtes Risiko ansteht, definieren und liefern die CSOCs die entsprechenden proaktiven Schutzmaßnahmen. Falls ein Vorfall in einer Anlage entdeckt wird, koordinieren die Security-Spezialisten einen Reaktionsplan, der aus Untersuchung, forensischer Analyse und Schadensbehebung besteht. Abhängig von der Art des Ereignisses erfolgt die Behebung entweder automatisch oder vor Ort. Wie bereits erwähnt, ist die Anforderung bezüglich der Bereitstellung der Security Events über standardisierte Schnittstellen sehr wichtig - unabhängig davon, ob eine SIEM-Installation vor Ort in einer Anlage erfolgt oder ob die Anlage an ein CSOC angebunden wird. Repräsentative Beispiele für Security Events, die auf der Betriebssystemebene gängig sind und inzwischen auch von verschiedenen Automatisierungskomponenten generiert werden, sind: Erfolgreiche Anmeldung, Fehlgeschlagener Anmeldeversuch, Benutzerwechsel, Änderung der Security-Einstellungen. Auf der Herstellerseite soll die Definition von Security Events für einzelne Automatisierungskomponenten bzw. Komponentenfamilien unter Berücksichtigung anlagenspezifischer Anforderungen sowie der relevanten Standards und der zu erkennenden Angriffsszenarien systematisch erfolgen. Dabei soll die Fähigkeit, Security Events zu erfassen, nicht nur vorhanden sein, sondern auch aktiv genutzt werden. Bei der Konfiguration von Anlagenkomponenten, wie etwa industriellen Firewalls und Switches, soll dazu die Option 'Logging' aktiviert werden. Ferner haben die Struktur, das Format sowie der Informationsgehalt, der von verschiedenen Komponenten generierten und zur Weiterverarbeitung in einem SIEM-System vorgesehenen Security Events, einen großen Einfluss auf die Qualität und die Ergebnisse der Korrelationen, sowie auf den zur Erstellung der Korrelationsregeln benötigten Aufwand. Durch die Etablierung einer einheitlichen Struktur sowie eines einheitlichen Formats für Security Events im Automatisierungsumfeld kann dieser Aufwand erheblich reduziert werden. Damit ein Anlagenbediener bzw. -administrator oder ein weiterer zuständiger Experte über besonders wichtige SIEM-Events und -Alarme zeitnah informiert werden kann, sind geeignete Schnittstellen zwischen einer Industry-SIEM-Lösung und den Meldesystemen der in Automatisierungsanlagen eingesetzten Automatisierungs- bzw. HMI-Systemen erforderlich. Alternativ bzw. zusätzlich kann die im Umfang der meisten SIEM-Systeme vorhandene Weiterleitung von Events und Alarmen per SMS und/oder E-Mail genutzt werden.
Ausblick auf Teil 3
Der nächste und letzte Teil der Beitragsreihe beschäftigt sich mit diversen Aspekten der proaktiven Erkennung von Angriffen und Abweichungen sowie mit der sogenannten Rückwirkungsfreiheit. Außerdem liefert er einen Ausblick auf die zukünftigen Herausforderungen, die insbesondere in sogenannten Schutzlevels zur Gesamtbewertung des Schutzes einer Anlage und dem sogenannten Holistic Security Concept (HSC) liegen.
Bild: Siemens AGOriginalität und Echtheit nachweisen
Als weitere Mechanismen zur Gewährleistung der Systemintegrität, die insbesondere im Hinblick auf Industrie 4.0. an Bedeutung gewinnen, sind die Mechanismen zum Nachweis der Originalität bzw. Echtheit (engl. Originality) von Geräten, beispielsweise die sogenannten Gerätezertifikate, zu erwähnen. Die den Security Levels 3 bis 4 entsprechende Anforderung des Entwurfs der IEC62443-4-2 hinsichtlich der Steuerungskomponenten lautet wie folgt:
? ECR 3.10 - Originality
Requirement: The embedded device shall provide a proof of originality mechanism.
Die den Security Levels 2 bis 4 entsprechende Anforderung des
Entwurfs der IEC62443-4-2 hinsichtlich der PC-basierten Systemen und Netzwerkkomponenten lauten wie folgt:
? HCR 3.10 - Originality
Requirement: The host device shall provide a proof of originality mechanism.
Requirement enhancement: (1) Unalterable proof of originality The proof of originality shall be provably unalterable and uncloneable.
? NCR 3.10 - Originality
Requirement: The network component shall provide a proof of originality mechanism.
Requirement enhancements: (1) Unalterable proof of originality The proof of originality shall be provably unalterable and uncloneable. @Aufzählung 2:
Während die Mechanismen zum Nachweis der Originalität bzw. der Echtheit bereits während der Fertigung diverser Geräte implementiert werden müssen, kommen die sogenannten operativen Zertifikate erst zur Laufzeit im Anlagenkontext zum Einsatz. Das Ziel ist hier, die Authentifikation und Kommunikationsintegrität durch kryptographische Mittel zu erreichen. Der im Gerät sicher hinterlegte, private Schlüssel wird an den zugehörigen öffentlichen Schlüssel gebunden. Dabei wird die automatisierte Unterstützung der Abläufe zum Management von derartigen Zertifikaten und den zugehörigen kryptographischen Schlüsseln im Kontext einer Public Key Infrastruktur (PKI) - insbesondere als Basis für die sichere Kommunikation zwischen den Applikationen und Geräten - zunehmend wichtig. Durch die Reduktion der manuellen Aktionen im Rahmen des Zertifikatsmanagements und zunehmend automatisierte Abläufe auf der Basis von Standardprotokollen (insbesondere zum Ausrollen und Erneuerung von Zertifikaten) wird zur Erhöhung der Flexibilität und der Interoperabilität im Anlagenkontext beigetragen. Die den Security Levels 2 bis 4 entsprechende Anforderung der IEC62443-3-3 hinsichtlich der PKI-Nutzung im Kontext eines aus verschiedenen Applikationen und Geräten zusammengesetzten Systems lautet (abgekürzt) wie folgt.
? 5.10 SR 1.8 - Public key infrastructure (PKI) certificates
5.10.1 Requirement: Where PKI is utilized, the control system shall provide the capability to operate a PKI according to commonly accepted best practices or obtain public key certificates from an existing PKI.
Durch die genannte Anforderung hinsichtlich des Systems wird die folgende, in der IEC62443-4-2 aufgeführte, den Security 2 bis 4 entsprechende Anforderung hinsichtlich Applikationen und Geräten impliziert:
? CR 1.8 - Public key infrastructure certificates
Requirement: When public key infrastructure (PKI) is utilized, the application or device shall provide the capability to interact and operate within the scope of the PKI according to IEC 62443-3-3.
Siemens AG
Dieser Artikel erschien in SPS-MAGAZIN 9 2017 - 07.09.17.Für weitere Artikel besuchen Sie www.sps-magazin.de
