Analyse der IT-Security in der industriellen Automation

Transkript

1 Analyse der IT-Security in der industriellen Automation Dipl.-Ing. T. Doehring, Dr.-Ing. M. Riedl, Institut f. Automation und Kommunikation, Magdeburg; B. Sc. J. Brand, Prof. Dr. S. Heiss, Institut für Industrielle Informationstechnik, Lemgo 1. Kurzfassung Automatisierungslösungen im industriellen Umfeld beinhalten zumeist schützenswerte Funktionseinheiten. Dazu gehören unter anderem klassische Steuerungs- und Regelungsfunktionen und Algorithmen. Diese Automatisierungslösungen sind je nach Betrachtungswinkel entweder einzelne Automatisierungsgeräte, Teilanlagen aber auch Gesamtanlagen, welche in der Regel aus Hard- und Softwareanteilen bestehen. Da keine Automatisierungslösung fehlerfrei ist, existieren somit potenzielle, risikobehaftete Schwachstellen [7]. Im Forschungsvorhaben VuTAT (Vulnerability Tests of AT Components [13]) wurde der Zusammenhang aus Bedrohung, Schwachstelle und auftretendem Risiko näher untersucht. Daraus konnte abgeleitet werden, wie Hersteller von Automatisierungslösungen einen wirkungsvollen Beitrag zur Berücksichtigung der IT-Security bei der Geräteentwicklung leisten können, um latente Bedrohungen durch Angriffe zu minimieren. Da die Verantwortung über die Endanwendung und das damit verbundene Risiko, welches sich durch die Faktoren Eintrittswahrscheinlichkeit und Schadensausmaß beschreiben lässt, im Bereich des Anwenders liegt, richtet sich der Fokus dieser Betrachtung auf die Schwachstellen, die schon während der Entwicklung durch den Hersteller vermieden werden sollten. Das bereits erwähnte Vorhaben VuTAT liefert hier einen entscheidenden Beitrag zur Identifikation und Analyse von Sicherheitsschwachstellen in Ethernet-basierten Automatisierungsgeräten. Dabei werden einerseits etablierte Testmethoden und techniken betrachtet, andererseits auch Lösungen für den Transfer in die Automatisierungstechnik und das industrielle Umfeld erarbeitet, so dass Design-, Implementierungs- oder Konfigurationsschwachstellen auf Geräteebene identifiziert werden können. So tragen diese Ergebnisse entscheidend zur objektiven Bewertung, beispielsweise der Robustheit von Automatisierungslösungen, bei [1, 2]. Im Beitrag werden Methoden und Techniken zur Identifikation und Analyse von IT-Security-relevanten Schwachstellen und deren einheitliche und standardisierte Anwendung auf Ethernet-basierte Automatisierungsgeräte

2 zusammenfassend präsentiert und bewertet. Die Ergebnisse werden aktuell in Standardisierungsgremien eingebracht. 2. Ziele des Forschungsprojektes Im Fokus des Foschungsprojektes VuTAT lagen entwicklungsbegleitende Schwachstellentests mit Commercial off-the-shelf (COTS)-Komponenten. Anforderungen waren dabei unter anderem der Einsatz von frei verfügbaren Softwarekomponenten (OpenSource). Das entwickelte Framework sollte schon in den frühen Stadien einer AT- Geräteentwicklung ohne besondere Spezialkenntnisse Einsatz finden, unter anderem Protokoll- und Implementierungsschwachstellen entdecken und beseitigen, und die Robustheit der Implementierungen steigern. Dabei richtete sich der Blick auf Protokolle und Dienste der Standard IT Protokollsuite. 3. Betrachtungsgegenstand Im Rahmen von VuTAT wurden Endgeräte und Infrastrukturgeräte der industriellen Automatisierungstechnik auf Schwachstellen untersucht. Neben den im industriellen Umfeld vorrangig zum Einsatz kommenden Ethernet-basierten Standardprotokollen wurden exemplarisch die PROFINET-Protokolle [3] betrachtet. Das Bild 1 zeigt die Auswahl der untersuchten Protokolle bzw. Dienste. AT-Gerät Hardware + Embedded Betriebssystem PROFINET Applikation NICHT dokumentierte Dienste/ Protokolle Standard IT-Dienste und Protokolle proprietäre Dienste und Protokolle Hardware + Embedded Betriebssystem PROFINET Applikation Anwendung LLDP ARP ICMP HTTPS SSH SSL/TLS SMTP HTTP FTP Telnet DNS SMB TFTP BOOTP DHCP SNTP SNMP CLRPC CM RTC RTA RTC RTA DCP PTCP MRP TCP TCP/UDP UDP IP Ethernet LLC und Medium Access Control Bild 1: Ethernet-basierte Protokolle und Dienste für PROFINET-Anwendungen

3 Als Grundlage für die Spezifikation der Schwachstellentests diente eine umfassende Beschreibung und Bewertung der relevanten Protokolle und Dienste. Die Bewertung erfolgte anhand einer Sicherheitsanalyse und der Einschätzung der Kritikalität. Eine Sicherheitsanalyse im Umfeld der funktionalen Sicherheit (z. B. IEC 61508) von Kommunikationsprotokollen und -diensten basiert auf der Betrachtung von dedizierten Fehlertypen. Dabei wird angenommen, dass diese Fehlertypen auch für eine Sicherheitsanalyse im Sinne der Informationssicherheit herangezogen werden können. Des Weiteren wird angenommen, dass ein Angreifer nicht nur alle übertragenen Daten abhören kann, sondern als aktiver Teilnehmer des betrachteten Netzwerks auch Daten senden und ggf. manipulieren kann ( Man in the middle ). Diesen Annahmen folgend, werden innerhalb der Sicherheitsanalyse die Fehlertypen Verzögern, Vertauschen, Einfügen, Wiederholen, Löschen und Verändern betrachtet. Für jedes Protokoll werden hierzu in einem einheitlichen Format folgende Informationen zur Verfügung gestellt: Kurzbeschreibung: Aufbau und Funktionsweise des Protokolls bzw. Dienstes wird kurz beschrieben (Text, Grafiken etc.) Sicherheitsanalyse: Die Sicherheitsanalyse umfasst die Darstellung bekannter oder offengelegter Schwachstellen. Schutzmaßnahmen: Schutzmaßnahmen zur Gewährleistung von IT-Sicherheitszielen werden beschrieben, bewertet und folgenden Kategorien zugeordnet: 1) Schutzmaßnahmen gegen vorsätzliche Handlungen (entsprechend BSI Gefährdungskatalog G5): im Allgemeinen gehen diese Angriffe vom Menschen aus, sie sind damit gezielt und intelligent [9]. 2) Schutzmaßnahmen gegen technisches Versagen (entsprechend BSI Gefährdungskatalog G4): diese eher unbeabsichtigten Angriffe werden hier ebenfalls als IT-Sicherheitsangriffe betrachtet, sie sind aber weniger gezielt und weniger intelligent [9]. Kritikalitätseinschätzung: Die Einschätzung der Kritikalität wird nur für Dienste vorgenommen, nicht explizit für Protokolle. Im Fokus der Analyse steht das Fehlverhalten von Kommunikationsdiensten. Ausgehend von möglichen Fehlverhalten (z. B. aufgrund von Implementierungsfehlern, Designfehlern, Protokollmanipulationen) werden Einflüsse auf die Automatisierungsanwendung diskutiert. Die analysierten Dienste basieren meist auf der Nutzung von einem oder mehreren Protokollen. Die Protokolle sind daher meist integraler Bestandteil von Diensten, so dass bei der Analyse von Diensten eine implizite Betrachtung von Protokollen gegeben ist.

4 4. Test von Komponenten mit dem Schwachstellenscanner OpenVAS OpenVAS ist ein Schwachstellenscanner, welcher aus der letzten freien Nessus-Version hervorgegangen ist [5, 6] und damit eine Open-Source-Variante zu diesem bildet. Diese freie Software ist aktuell in der Version 6 verfügbar. Bild 2: Aufbau der OpenVAS Umgebung [4] Wie dem Bild 2 zu entnehmen ist, wird der OpenVAS Server vom OpenVAS Manager gesteuert. Der OpenVAS Client besteht aus den Komponenten OpenVAS CLI, Greenbone Security Assistant (GSA) und Greenbone Security Desktop (GSD). OpenVAS CLI ist ein Command Line Interface, welches über eine Konsole bedient wird. Sehr komfortabel für die Bedienung ist der GSA: Dieser stellt einen HTTP- oder HTTPS-Server bereit, auf welchen mit einem Webbrowser zugegriffen werden kann. Die drei Komponenten kommunizieren mit dem OpenVAS Manager über das OpenVAS Management Protocol (OMP), während der Manager über das OpenVAS Transfer Protocol (OTP) mit dem Scanner kommuniziert. Eine weitere Komponente ist der OpenVAS Administrator, über welchen sich Einstellungen vornehmen und Benutzer verwalten lassen. Die Kommunikation zwischen den drei Benutzerschnittstellen und dem Administrator findet über das OpenVAS Administration Protocol (OAP) statt. Die Schwachstellentests werden als Skripte ausgeliefert, welche von der OpenVASCommunity erstellt werden. Derzeit sind dies mehr als , die jedoch nur Schwachstellen aus dem Umfeld der Office IT adressieren. Grundsätzlich werden bei den Untersuchungen der getesteten Geräte durch OpenVAS folgende Aspekte berücksichtigt:

5 Portscan (Identifikation unsicherer Dienste/Protokolle) Tests von Logins (Default-/Standardpasswörter, schwache Passwörter) Tests bekannter Protokoll-Angriffsmuster (Feststellen von Implementierungsfehlern: Bufferoverflow-Vulnerabilities, unzureichende Inputvalidierung) Bestimmung von Betriebssystem- und Programmversionen (Protokoll-Headerdaten, OS-Fingerprinting) Nutzung von Datenbanken zur Identifizierung (ggf. Testen) bekannter Schwachstellen Während erster Tests mit Komponenten der Automatisierungstechnik lieferte OpenVAS vielfach falsche Fehlerreports, die unter anderem auf instabiles Lastverhalten zurückzuführen sind. Die Herausforderung lag nun darin, das Framework dahingehend anzupassen und zu erweitern, dass auch Tests mit Geräten aus dem industriellen Umfeld durchgeführt werden und konkrete Aussagen zum Verhalten gemacht werden können. 5. Communication Robustness Testing (CRT) Communication Robustness Testing (CRT) [11] beinhaltet generische Protokolltests zur Überprüfung des Geräteverhaltens beim Empfang von fehlerhaften Netzwerkpaketen und bei Lasttests. Es wird also neben dem Verhalten des DUT (Device under Test) auf Netzwerkpakete mit fehlerhaften Inhalten und fehlerhaften Feldern das Verhalten auf eine große Anzahl von korrekten, aber auch fehlerhaften Paketen getestet (Testkonfiguration siehe Bild 3). Neben dem korrekten Verhalten der Ethernetschnittstelle wird auch das korrekte Verhalten der sogenannten Essential Services berücksichtigt. Für das CRT stellt das ISA Security Compliance Institute (ISCI) in einer Reihe von Embedded Device Security Assessment-Dokumenten (EDSA) - zur Zeit sieben Spezikationen - zur Verfügung: EDSA-310 CRT common: Allgemeine Spezifikation des CRT. Es werden der Testaufbau und die Testdurchführung beschrieben. EDSA-401 CRT Ethernet: Spezifikation des Ethernet CRT EDSA-402 CRT ARP: Spezifikation des ARP CRT EDSA-403 CRT IPv4: Spezifikation des IPv4 CRT EDSA-404 CRT ICMPv4: Spezifikation des ICMPv4 CRT EDSA-405 CRT UDP: Spezifikation des UDP CRT EDSA-406 CRT TCP: Spezifikation des TCP CRT

6 Bild 3: Testkonfiguration nach EDSA-310 Das CRT ist in fünf Prioritätsgruppen von Netzwerkprotokollen eingeteilt, wobei bis heute lediglich Gruppe 1 spezifiziert wurde. Die Gruppen zwei bis fünf sollen später folgen. Zur Gruppe 1 gehören IEEE (Ethernet), ARP, IPv4, ICMPv4, TCP und UDP. Interessant aus der Sicht des Forschungsprojektes VuTAT ist jedoch die Gruppe 4, zu der unter anderem die PROFINET Protokolle zählen. So bestand in VuTAT eine Aufgabe darin, eine formale Testspezifikation auf Grundlage der durchgeführten Sicherheitsanalyse der PROFINET spezifischen Protokolle und Dienste abzuleiten und zu erstellen. 6. Erweiterung von OpenVAS Erweitertes Scheduling und Monitoring Für den Test von AT-Komponenten zeigten erste Analysen, dass das OpenVAS-Framework nur bedingt für Untersuchungen im industriellen Umfeld geeignet ist. Diese Limitierung des Funktionsumfangs lassen sich wie folgt zusammenfassen: Externe Ereignisse (Absturz des DUT (Device under Test), Über-/Unterschreiten von Zeittoleranzen) können nicht in die Reports von OpenVAS integriert werden. Diese externen Ereignisse können nicht von der OpenVAS-Testablaufsteuerung berücksichtigt werden. Mit der Skriptsprache von OpenVAS können keine Layer-2 Pakete generiert werden und die

7 Ausführung diesertestskripte ist relativ langsam. Netzwerkpakete können nicht an Broad- oder Multicast-Adressen gesendet werden. Ein erster Konzeptansatz war, dass zur Durchführung von Lasttests für AT-Komponenten aus dem industriellen Umfeld die Integration eines Paketgenerators auf OSI-Layer 2 Ebene (wie z.b. Scapy [14]) im Testframework notwendig ist. Im folgenden Bild 4 ist die VuTAT Testablaufsteuerung mit dieser Erweiterung dargestellt. Der VuTAT-Ctrl empfängt hierbei die Liste der auszuführenden Skripte und löst die Abhängigkeiten dieser auf. Die Liste der Skripte wird vom VuTAT-Ctrl abgearbeitet und für jedes Skript entschieden, welches unterlagerte Modul angesprochen wird. Im ersten Fall wird die vorher empfangene Startanweisung, welche der Manager gesendet hat, auf dieses Skript reduziert und an den Scanner weitergeleitet. Im zweiten Fall wird das Scapy-Skript mithilfe des Python- Interpreters [15] ausgeführt. Die Ergebnisse der Skript-Ausführung, also Log-Informationen, Fehler und Statusnachrichten, werden vom VuTAT-Ctrl im richtigen Format erstellt und ebenfalls an den Manager geleitet. Ebenso können die Log-Informationen des Monitorings an den Manager weitergeleitet werden. Diese drei Möglichkeiten der Ergebnissnutzung werden somit in einem Report zusammengefasst. Bild 4: VuTAT Testablaufsteuerung Eine Monitoring Komponente (Monitoring Device) übernimmt die Überwachung der Downward Essential Services. Damit kann ein vorgegebener Spannungsverlauf der analogen und/oder digitalen Ausgänge des DUT beobachtet werden. Da diese Werte über das Steuerungsprogramm der SPS gesetzt werden, wird hiermit die Grundfunktionalität der

8 SPS überprüft. Bei Abweichungen vom vorgegebenen Verlaufsmuster, also Zeit, Spannung, Ausbleiben, Über-/Unterschwinger oder falsche Werte, soll eine Meldung an den VuTAT-Ctrl gesendet und schließlich an den OpenVAS Manager weitergeleitet werden, so dass diese Information in die Logs aufgenommen werden kann. Zusätzlich soll das Monitoring Device auf Befehl vom VuTAT-Ctrl über die Verbindung mit der IOKarte einen Neustart des DUT veranlassen. Eine weitere bereitzustellende Funktion ist die Möglichkeit, Log-Informationen auszugeben, um Analysen und Statistiken zu erstellen. Eine Zusammenfassung dieser Logs sollte auch in den Testreports zu sehen sein. Im Bild 4 ist das Monitoring Device im VuTAT- Ctrl integriert: Sobald ein Skript gestartet wird, wird auch das Monitoring gestartet. Ist die Ausführung dieses Skripts beendet, wird eine Log-Nachricht mit Informationen zu den Signalverläufen an den Manager gesendet. Falls das Monitoring während eines Skripts einen Fehler detektiert, wird dieser ebenfalls zum Manager übertragen. 7. Aufbau der Testumgebung der VuTAT Demonstrator Der schematische Aufbau der Testumgebung wird in dem Bild 05 gezeigt. Hierbei ist das Monitoring Device als getrenntes Gerät dargestellt. Dieses besitzt eine Standard PCI-IO- Karte, welche einerseits die Ausgänge des DUT beobachtet und andererseits über einen Ausgang ein Relais schaltet, welches die Spannungsversorgung des DUT unterbricht. Das Testing Device besteht aus einer OpenVAS-Konguration (Browser, Greenbone Security Assistant, OpenVAS Manager mit Ergebnisberichten und Kongurationen, OpenVAS Scanner mit den NVTs), bei der zwischen dem Scanner und dem Manager VuTAT-Ctrl operiert. Diese Komponente kommuniziert mit dem Monitoring Device, bietet aber auch die Möglichkeit, die Testausführung statt mit dem OpenVAS Scanner, mit Scapy auszuführen. Dabei hat Scapy Zugriff auf bereitgestellte Skripte für das Communication Robustness Testing. Die beiden ausführenden Komponenten sind über ein Netzwerk mit dem DUT, in diesem Fall einer speicherprogrammierbaren Steuerung, verbunden.

9 Bild 5: Aufbau des VuTAT Demonstrators Erste Ergebnisse von AT-Komponententests mit dem VuTAT Demonstrator zeigten unter anderem, dass ein präzises Monitoring der Essential Services durch ein Monitoring Device über IO-Karten erwartungsgemäß möglich ist. Mit den Erweiterungen ist der automatisierte Ablauf der Tests gewährleistet, da ein Neustart des DUT bei Änderungen der Startbedingungen (z.b. ARP Table verändert) oder bei Absturz automatisch durch das Framework ausgelöst wird. Die Ergebnisreports werden im OpenVAS-Manager in einheitlichem Format erstellt. Dabei werden Informationen zu den durchgeführten Schwachstellentests und CRTs ebenso berücksichtigt wie die Ergebnisse des Monitorings (Abweichungen der Signaldauer, Ausbleiben der Signale, Unsaubere Spannungsänderungen, falsche Spannungen (analog)). 8. Zusammenfassung und Ausblick Verschiedene Tests an unterschiedlichen Komponenten der Automatisierungstechnik brachte interessante Ergebnisse, welche die starke Relevanz einer solchen Testumgebung bestätigen. Neben einem erfolgreichen ARP-Poisoning (Senden von verfälschten ARP- Paketen zum Verändern der ARP-Tabellen damit der Datenverkehr zwischen 2 oder mehr Systemen abgehört werden kann), welches bei standardkonformen Implementierungen auftritt, und unkritischen Abweichungen von Standards (IP-Pakete mit reserved-flag werden akzeptiert, ICMP-Nachrichten mit ungültigen Code-Feldern werden beantwortet, ICMP- Antworten an Multicast- und Broadcast- Adressen,...) wurden auch kritische Verhaltensweisen beobachtet. Bei UDP-Echo-Anfragen mit zu geringem Wert in der

10 Längenangabe von UDP antwortete ein Gerät mit der korrekten Payload für die angegebene Länge, fügte aber Daten an die Payload an, welche ungleich 0 sind. Ohne Auswirkungen auf die Essential Services blieb auch eine Echo-Schleife, welche 100% CPU-Last produzierte. Diese Schleife wurde durch ein einfaches Echo-Paket ausgelöst, welches als Source- Adresse die Adresse des DUTs eingetragen hatte. Die kritischen Ergebnisse sind aber die, bei denen die Funktion der beobachteten Ausgänge gestört wurde. Hier führte bei einigen Geräten das Senden einer großen Menge von Paketen innerhalb sehr kurzer Zeit, also bei Lasttests, zu einer Änderung der Signaldauer oder zu einem Ausbleiben der Signale. Teilweise wurde die Funktion der Ausgänge nach Beendigung des Tests wieder hergestellt, teilweise war aber auch ein Neustart des DUT nötig. Auch das Senden vieler ARP-Requests mit unterschiedlichen MAC- und IP-Adressen (1280 Pakete) führte zu einem Ausbleiben der Signale. Zusammenfassend bieten die implementierten VuTAT Gerätetests detektierte Schwachstellen u.a. bei: hoher Netzwerklast IP-Fragmentation Angriffen ARP-Cache Flood Indizien für Memory Leaks diverse Spezifikationsverletzungen Als weiterführende Arbeiten ist u.a. die Spezifikation eines Formats zur Beschreibung von Testfällen zu nennen. Aber auch der Einsatz eines hardware-basierten Paketgenerators zur Realisierung von Robustheitstest mit hohen und exakten zeitlichen Anforderungen sollte im Fokus stehen. Für die Auswertung von zeitkritischer RT-Kommunikation ist ein exaktes Monitoring der Ethernet-Schnittstelle notwendig, auch dies muss Bestandteil weiterer Arbeiten zu diesem Thema sein. 9. Literatur [1] Doehring, Tino; Adamczyk, Heiko: ATP 02/2012 Entwicklung von IT-Security Tests für PROFINET IO [2] Heiss, Stefan; Jan-Christopher Brand; KommA 2012 Schwachstellen- und Robustheitstests in der Automatisierungstechnik [3] International Electrotechnical Commission (IEC): IEC : Industrial communication networks - Fieldbus specifications - Part 6-10: Application layer protocol specification - Type 10 elements, 2006.

11 [4] OpenVAS: About OpenVAS Software. Zuletzt aufgerufen am: [5] OpenVAS: OpenVAS - Protocol Documentation. Zuletzt aufgerufen am: [6] OpenVAS: The world's most advance Open Source vulnerability scanner and manager. Zuletzt aufgerufen am: [7] VDI/VDE Richtlinie 2182 Blatt1: Informationssicherheit in der industriellen Automatisierung - Allgemeines Vorgehensmodell, August Entwurf. [8] VDI/VDE Richtlinie 2185: Funkgestützte Kommunikation in der Automatisierungstechnik, August Entwurf. [9] Bundesamt für Sicherheit in der Informationstechnik (BSI): ITGrundschutz-Kataloge. Zuletzt aufgerufen am: [10] EDSA-310: ISA Security Compliance Institute - Common requirements for communication robustness testing of IP-based protocol implementations. [11] EDSA-310-Common-robustness-test-spec(v1_4).aspx. Zuletzt aufgerufen am: [12] ISASecure. Zuletzt aufgerufen am: [13] zuletzt aufgerufen am [14] Scapy: Zuletzt aufgerufen am [15] Python: zuletzt aufgerufen am