Schwachstellen und Robustheitstest von Automatisierungskomponenten. Frank Schewe

Transkript

1 Schwachstellen und Robustheitstest von Automatisierungskomponenten Frank Schewe

2 Gliederung Einleitung Ziele des Forschungsprojektes VuTAT Framework Ergebnisse des Demonstrators Ausblick

3 Forschungsprojekt VuTAT Entwicklung eines Frameworks zur automatisierten Untersuchung von Ethernet-basierten Komponenten der Automatisierungstechnik (AT) zur Aufdeckung von IT-Schwachstellen Kurztitel: VuTAT (Vulnerability Test of AT components) Laufzeit: Gefördert vom BMWi (AiF, FKZ BG) Forschungsstellen: Liebigstr Lemgo Werner-Heisenberg-Str Magdeburg Tel: Fax: Tel: Fax:

4 Projektbegleitender GmbH Bosch Rexroth AG Hirschmann Automation and Control ifak system GmbH Langner Communications AG Phoenix Contact Electronics GmbH Pilz GmbH & Co. KG SICK AG Trebing & Himstedt Prozessautomation GmbH & Co. KG WAGO Kontakttechnik GmbH & Co. KG

5 Ziele des Forschungsprojektes Entwicklungsbegleitende Schwachstellentests mit Commercial off-the-shelf (COTS)-Komponenten Frei verfügbare Softwarekomponenten (OpenSource) Im Handel preiswert erhältliche Hardware Verwendung des Frameworks in frühen Stadien der Entwicklung ohne besondere Spezialkenntnisse Steigerung der Robustheit von Implementierungen Entdeckung und Beseitigung von Protokoll- und Implementierungsschwachstellen Fokussierung auf Protokolle der TCP/IP Protokollsuite und PROFINET

6 Arbeitspakete AP1: Bewertung der Informationssicherheit Ethernetbasierter Protokolle und Dienste in der industriellen Automatisierung AP2: Entwicklung einer flexiblen, adaptiven Testmethodik AP3: Definition von Tests zur Schwachstellenidentifikation AP4: Definition einer Analyseeinheit zur Bewertung von Schwachstellen AP5: Exemplarische Realisierung eines Demonstrators AP6: Test an ausgewählten Automatisierungskomponenten AP7: Dokumentation der Ergebnisse

7 Analyse der verwendeten Protokolle

8 Test von Komponenten der AT mit Schwachstellenscanner (OpenVAS) 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 PO9yZqZen0Khr4svjNo2qO9hH2 Herausforderung: OpenVAS liefert bei Komponenten der AT vielfach falsche Fehlerreports, die auf instabiles Lastverhalten zurückzuführen sind.

9 Aufbau der OpenVAS Umgebung Quelle: OpenVAS

10 Lasttests / Communication Robustness Testing (CRT) Generische Protokolltests zur Überprüfung des Geräteverhaltens beim Empfang von Netzwerkpaketen mit fehlerhaften Werten von Headerfeldern mit fehlerhaften Längen von Datenfeldern oder Paketen unter hoher Netzwerklast Testergebnisse auf Grundlage eines Monitorings von Antwortpaketen Geräteverhalten (Essential Services) Referenzen: EDSA-Spezifikation der ISCI (ISA Security Compliance Institute) und Lasttests für PROFINET-IO.

11 CRT ISASecure Compliance Institute (ISCI) veröffentlichte Testspezifikationen Embedded Device Security Assurance (EDSA) 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

12 Testkonfiguration nach EDSA-310

13 Limitierung von OpenVAS Externe Ereignisse (Über-/Unterschreiten von Zeittoleranzen beim Monitoring von Essential Services ) können nicht erfasst (Reports) und nicht bei der Testablaufsteuerung berücksichtigt werden. Last-/CRT-Tests lassen sich nur sehr eingeschränkt ausführen Layer-2 Pakete können nicht generiert werden Ausführung von Testskripten ist relativ langsam Idee: Zur Durchführung von Lasttests ist die Integration eines Paketgenerators (wie z.b. SCAPY) im Testframework notwendig.

14 VuTAT Testablaufsteuerung Manager Start Task (NASL1, Scapy1, NASL2) ERR Log des ERR des MD ERR MD Log des MD VuTAT Ctrl Warten auf Neustart des DuT Start Task (NASL1) ERR End of Task (NASL1) Start Script Scapy1 Result (Fail) Start Task (NASL2) Scanner Scapy Scanner t Log des MD End of Task (NASL2) End of Task (NASL1, Scapy2, NASL2)

15 Aufbau der Testumgebung Monitoring Component (CRT.R 7,8,9,14) for Upward Essential Services Testing Device (TD) DUT Output Monitoring Component (CRT.R 13,30,39) for Downward Essential Services Monitoring Device IO-Karte

16 Monitoring Device high low 1s 2s 3s 4s 5s 6s 7s 8s 9s 10s 11s 12s maxv minv 1s 2s 3s 4s 5s 6s 7s 8s 9s 10s 11s 12s 13s 14s 15s 16s 17s 18s 19s 20s 21s 22s 23s 24s 25s 26s 27s 28s 29s 30s 31s 32s 33s Monitoring Device Monitoring Software Anschlussblock Bildquelle:

17 VuTAT Demonstrator Browser Testing Device Greenbone Security Assistant CRTs Scapy OpenVAS Manager VuTAT-Ctrl OpenVAS Scanner Results, Configs NVTs Monitoring Device +24V IO-Karte

18 Ergebnisse des Demonstrators PO9yZqZen0Khr4svjNo2qO9hH2 Präzises Monitoring der Essential Services durch ein Monitoring Device über IO-Karten Integration von OpenVAS und Scapy in ein Framework Tests werden im OpenVAS-Manager erstellt und von der jeweiligen Komponente ausgeführt Automatisierter Ablauf der Tests Automatisch getriggerter Neustart des DuT bei Änderungen der Startbedingungen (z.b. ARP Table verändert) oder bei Absturz Einheitliche Ergebnisreports im OpenVAS-Manager von: Schwachstellentests (Netzwerk-Interface) CRTs (Netzwerk-Interface) Ergebnissen des Monitorings (Abweichungen der Signaldauer, Ausbleiben der Signale, Unsaubere Spannungsänderungen, falsche Spannungen (analog))

19 VuTAT Gerätetests Detektierte Schwachstellen u.a. bei: hoher Netzwerklast IP-Fragmentation Angriff ARP-Cache Flood Indizien für Memory Leaks Diverse Spezifikationsverletzungen

20 Robuste Implementierungen - Relevanz Industrie 4.0, IEC (DKE UK 931.1) IEC (Technical security requirements for IACS products) ISA Security Compliance Institute (ISCI) Embedded Device Security Assurance (EDSA) Profinet Security WG PN Security Certification Security Level 1 Tester

21 Ausblick Spezifikation eines Formats zur Beschreibung von Testfällen Spezifikation von Testfällen Einsatz eines HW-basierten Paketgenerators Exaktes Monitoring der Ethernet-Schnittstelle Auswertung der zeitkritischen RT Datenkommunikation Testunterstützung für weitere Ethernet-basierte Kommunikationssysteme Durchführung entwicklungsbegleitender Tests

22 Vielen Dank für Ihre Aufmerksamkeit!