Penetration Tests bei Unternehmen mit wesentlicher Betriebstechnik (OT, ICS)

Was Penetration Tests sind und wie diese Ihr Unternehmen schützen

Warum ist das Thema überhaupt relevant?   

Regelmäßige Sicherheitsaudits durch „White Hat“ Hacker oder Penetrationstester gehören inzwischen zum Daily Business vieler CIOs und zum Standardangebot vieler IT-Dienstleister. Mit der steigenden Bedrohungslage von industriellen Unternehmen, z.B. durch Ransomware, gerät aber auch der Schutz der „Industrie 4.0“-Betriebstechnik und von vernetzten Geräten in den Fokus.

Das gilt gleichermaßen für Anlagenbauer oder Hersteller von „Smart Devices“, deren Produkte bei Kunden ans Netz gehen, wie für die eigene Produktion und Gebäudetechnik von z.B. Autozulieferern, Chemiefabriken, Versorgern oder Pharmaunternehmen. Die Prüfung von Software-Code gehört ebenso dazu wie Schwachstellentests von Hardware und Netzwerkkonfigurationen. 

Was kann ein Penetration Test leisten, was nicht, und wie passen diese in die Sicherheitsstrategie?  

Der technische Fokus von Penetration Tests ohne Social Engineering Aspekten liegt auf dem Versuch, über offene bzw. ungehärtete Schnittstellen in das Ziel-Netzwerk einzudringen.  
Sie eignen sich z.B. nicht zur Überprüfung des generellen Sicherheitsmanagements oder speziell der Wiederherstellungsfähigkeiten nach einem Angriff.  
Penetration Tests stellen eine unabhängige Validierung vieler Sicherheitsmaßnahmen dar. 
Sie können insbesondere zur Aufdeckung von kritischen Sicherheitslücken dienen. 
Beispielsweise sind sie auch im Rahmen der IEC 62443 für Komponentenhersteller, Systemintegratoren und Betreiber von industriellen Anlagen gefordert. 

Was ist an Penetration Tests für OT unterschiedlich zu Penetration Tests für reine IT-Umgebungen?   

Viele Methoden und Vorgehensweisen sind gleich wie bei Organisationen mit reiner Büro-IT (oder wenn man die Betriebs- und Automatisierungstechnik einfach außer Acht lässt).  

Beispielsweise werden spezialisierte Betriebssysteme inkl. Repertoire wie Kali oder Parrot Linux genutzt, oder Applikationen, wie bspw. Wireshark zum Aufzeichnen von Datenverkehr.  

Allerdings gibt es auch wesentliche Unterschiede: 

  • Der Ausfall oder die Störung von cyberphysischen Systemen kann wesentliche Konsequenzen bis hin zu Personenschäden nach sich ziehen. Die Implikation: „Einfach mal Ausprobieren“ ist meistens keine gute Strategie. Tatsächlich muss meist viel Zeit darauf verwendet werden, die zugrundeliegenden Prozesse und Abläufe zu verstehen.  
  • Echtzeitsysteme, der Einbezug von Betriebstechnik über mehrere Ebenen, sowie Feldbusprotokolle wie z.B. ProfiBus, BACnet, Modbus/TCP, DNP3 oder HART und proprietäre Steuerungen vergrößern die Spielwiese und die Komplexität enorm. Etwas polemisch ausgedrückt: Penetration Tests von reinen Büro-IT-Architekturen sind wie Mühle, Penetration Tests von Verbundarchitekturen mit OT und vernetzten Geräten bei Kunden wie Schach.  
  • Netzwerk- und Schwachstellenscanner wie NMap oder Nessus (u.a. zur Suche nach Default Passwörtern) sollten sehr vorsichtig eingesetzt werden – selbst auf Ebene 3 (typischerweise ja Windows-Maschinen oder Linux-Server) können Störungen nicht ausgeschlossen werden. Einige SPS verlieren automatisch ihre Garantie, „stürzen ab“ (DoS-Status) oder triggern z.B. Firmware-Updates, wenn ein Standard-Portscan angewendet wird. Redundante Systeme sind oft nicht 100% identisch – das bedeutet beispielsweise, der Scan des Standby-Servers kann problemlos durchgeführt werden, aber der Scan des aktiven Servers führt zum Crash. Selbst einfache Powershell-Scripts oder zusätzlich abgespeicherte Log-Dateien stellen Systemveränderungen dar, die zu unvorhergesehenen Störungen führen können. Trotzdem müssen Scans natürlich durchgeführt werden – gewusst wie und wann ist das Kern Know-How dabei. 
  • Es gibt mehr Stakeholder zur Abstimmung: Natürlich müssen z.B. Produktionsverantwortliche informiert und eingebunden werden, Prozessingenieure und Anlagenbediener sind fester Bestandteil des erweiterten Teams. 

Was sollte ich als Kunde beachten, um aus dem Penetration Test „das Optimum herauszuholen“? 

Ja, es ist immer alles fallabhängig. Aber grosso modo kristallisieren sich ein paar Handlungsempfehlungen als meistens richtig heraus: 

  • Natürlich nicht den IT-Dienstleister beauftragen, welcher auch für Security zuständig ist, um eine unabhängige Kontrollfunktion zu gewährleisten. Sollte eigentlich selbstverständlich sein, ist es aber nicht. Interessanter Ansatz dabei: Zwei Dienstleister parallel oder nacheinander beauftragen und Ergebnisse vergleichen. 
  • Ziele ehrlich definieren. Was wollen wir wirklich erreichen? Wissen wir nicht eigentlich schon, was wir erstmal erledigen sollten? Solange Anlagen von uns z.B. mit offenem Telnet-Port über Shodan erreichbar sind und mein Netzwerk flacher ist als ein Pfannkuchen, kann ich mir den Penetration Test sparen. 
  • White Box ist im Allgemeinen wesentlich effizienter als Black Box: Wenn die Penetration Tester erst viel Zeit mit Informationssuche verbringen, wird der Spaß eben teurer. Natürlich kann es sein, dass echte Angreifer nur schwieriger an die Informationen zu Netzwerkaufbau und Organisation kommen, und im Best Case den Aufwand scheuen. Aber wenn wir schon Geld ausgeben, dann doch nicht, um den Best Case zu simulieren und uns anschließend selbst zu gratulieren, dass wir schon super geschützt sind. 
  • Dazu sollten im Vorfeld Netzwerkpläne aktualisiert werden, und im Idealfall Schemata für die Kommunikationspfade zwischen IT und OT 
  • Übersichten der Benutzerrechte, insbesondere für Fernzugriffe auf OT-Systeme der Ebenen 1-3, sollten greifbar sein 
  • Wissensträger müssen ausreichend Zeit für Briefings einplanen 
  • Corona hat gezeigt, dass die meisten Penetration Tests und Security Assessments sehr wohl und in ausreichender Tiefenschärfe remote durchgeführt werden können (Ausnahmen bestätigen die Regel).  

Welche Schwachstellen werden typischerweise gefunden, und welche sollten priorisiert behoben werden? 

Wie immer gilt: Der nächste Euro, den ich nach dem Penetration Test ausgebe, sollte mein Risiko am meisten mindern. 

Am besten macht der Penetration Test Partner einen Vorschlag dazu als Diskussionsgrundlage (ansonsten muss man eben die Wäscheliste an Schwachstellen nehmen, und mit dem Anbieter zum Thema Priorisierung in das Gespräch einsteigen). 

Gefundene Schwachstellen ziehen sich natürlich entlang des kompletten NIST-Frameworks. 

Meistens haben Unternehmen, die auch die Produktionsumgebung einem Test unterziehen, aber davor Hausaufgaben in wesentlichen Aspekten gemacht (z.B. Asset und Software Inventarisierung zumindest für Ebene 2 und darüber, oder die Umsetzung von Passwortrichtlinien). 

  • Anlaufpläne: Es mangelt beispielsweise oft an klaren Wiederanlaufplänen (über einen ersten Reaktionsplan hinaus) für den Ausfall von einzelnen Systemen. Wie lange kann ich mir erlauben, dass ein System ausfällt? Das kann extrem unterschiedlich sein. Zu den üblichen Findings in Fabriken gehören natürlich auch veraltete Betriebssysteme (Windows NT, Windows 7 etc.), für die nicht klar ist, was im Fall eines Absturzes passiert (Stichpunkte: Prinzip Hoffnung / single point of failure). 
  • 2FA: Oder es gibt keine Multifaktorauthentifizierung für übergeordnete Bedieneinheiten. In der Tat stimmen fast alle Penetration Tester in diesem Punkt überein: Flächendeckende Zweifaktorauthentifizierung erschwert Hackern den Zugriff so deutlich, dass nur noch extrem motivierte Angreifer den Aufwand in Kauf nehmen.  
  • Netzwerkarchitektur: Funktionieren die „demilitarisierten Zonen (DMZ)“ und Netzwerksegmentierungen? Offenkundig nicht, falls beim Netzwerk-Sniffen im Enterprise-IT-Netz Datenverkehr auf Industrieprotokollbasis bemerkt werden kann. 

Oder falls über Terminals in der DMZ Schreibzugriff besteht. Die Nutzung derselben physischen Netzwerk-Switches für IT und OT stellt ebenfalls eine große Schwachstelle dar. Und Cloud-Anbindung von ICS-Systemen ist heute oft notwendig, aber meist nicht ausreichend gegen Angriffe abgesichert. 

  • Ein realistisches (priorisiertes) Patch-Management fehlt häufig in OT-Umgebungen. Dabei gilt generell: Priorität auf Patch-Management von IPC, SPS, SCADA und Servern auf Purdue Ebenen 3 und 2. Die Sensoren, Aktuatoren, Controller und meisten Industrieprotokolle darunter sind normalerweise inhärent unsicher und Software-Patches mit hohem Aufwand für Systemtests verbunden. Pragmatische Methoden zur Priorisierung stellt z.B. Dale Peterson hier  und unter ICS-Patch  zur Verfügung.  

Vor Kurzem ist zu dem Thema auch ein interessantes Interview  mit SANS Instructor und langjährigem Profi Justin Searle erschienen. 

Darin weist er noch auf einige Tipps und Kniffe zum besseren Schutz der OT hin: Beispielsweise, zwei separierte Identitätsmanagementsysteme für IT und OT zu haben, sowie die möglichen Verbindungen (inkl. tatsächlich existierender Seitenkanäle) zwischen IT und OT aufzulisten. Und, klar, oft fehlt es an Fachpersonal, um die identifizierten Maßnahmen zeitnah umzusetzen. 

Wie sieht es mit automatisierten Lösungen aus? 

Anbieter von automatisierten Penetration Tests werben natürlich damit, dass der manuelle Zeitaufwand (typischerweise mehrere Tage oder Wochen) mit einer Softwarelösung auf wenige Stunden reduziert werden kann. Die Preise sind attraktiv – besonders, wenn man Schwachstellen-Tests vielleicht öfter als nur einmal jedes Schaltjahr durchführen möchte.  

Und auch wenn herkömmliche Beratungen zu Recht darauf hinweisen, dass menschliche Kreativität nicht ersetzt werden kann: Klar ist auch, dass automatisierte Abläufe auf Basis aktueller Datenbanken gründlicher prüfen können, als ein einzelner Mensch oder ein kleines Team. Das gilt insbesondere für globale Organisationen. Wir alle kennen die Geschichte von Schach oder Go – erst war der Mensch der Maschine überlegen, dann ein Mensch mit Computerunterstützung der Gewinner, und heute haben selbst Großmeister keine Chance mehr gegen die KI-Algorithmen.  

Auch manuelle Penetration Test-Teams (und echte Angreifer) setzen natürlich weitestgehend auf automatisierte Tools, um Schwachstellen zu finden. 

Wahrscheinlich ist die Frage also eher: Wie hoch ist der Automatisierungsgrad, und wie viel des Test-Aufwands können die eigenen Mitarbeiter übernehmen? Zumindest in industriellen Umgebungen sieht es aktuell noch eher so aus, dass ein vollautomatisierter Penetration Test ohne Team deutlich weniger Erkenntnisse über mögliche Angriffe bietet. Das mag sich im Laufe der Zeit natürlich ändern.  

Welche Anbieter sind empfehlenswert? 

Eine Google Suche nach „Penetration Test“ liefert je nach Tagesform mehr als 100 Tausend Treffer. 
Und logisch, alle Anbieter werben mit Kundenreferenzen. 
Wen soll man jetzt nehmen? Wie immer ist die pauschale Antwort „it depends“. 

Hier ein paar Fragen, die zusätzlich zu einem strukturierten Ausschreibungsprozess vielleicht bei der Auswahl helfen: 

  • Werden Lebensläufe der Teammitglieder zur Verfügung gestellt, die die Tests tatsächlich durchführen? 
  • Mit welchen Industriesteuerungen, Firmwarelösungen, Protokollen und RT-Betriebssystemen hat das spezifische Team des Anbieters wirklich Erfahrung? 
  • Werden eigenentwickelte Tools genutzt, und falls ja, zu welchem Zweck (normalerweise ein gutes Zeichen)? 

Übrigens: Der Artikel spiegelt unseren aktuellen Wissensstand wider – aber auch wir lernen jeden Tag dazu. Fehlen aus Ihrer Sicht wesentliche Aspekte, oder haben Sie eine andere Perspektive auf das Thema? Gerne diskutieren wir mit Ihnen und weiteren Experten in Ihrem Hause die gegenwärtigen Entwicklungen vertiefend und freuen uns über Ihr Feedback sowie Anfragen zu einem Austausch.

Und zuletzt noch: Nennungen (oder die fehlende Nennung) von Anbietern stellt keine Empfehlung seitens CyberCompare dar. Empfehlungen sind immer abhängig von der kundenindividuellen Situation.