Justin Searle
Gemeinsam mit Justin Searle haben wir über den Ablauf und die Herausforderungen bei der Durchführung realer Pentests im industriellen Umfeld sowie für IoT-Produkte gesprochen. Zudem spricht er über konkrete Trends und Technologien für Cybersicherheit. Justing Searle ist der Director of ICS Security bei InGuardians und Senior Instructor für das SANS Institute.
Hallo Justin, vielen Dank, dass Du Dir heute die Zeit genommen hast, mit uns zu sprechen. Du blickst auf mehr als 20 Jahre Erfahrung im Bereich Cybersicherheit zurück. Könntest Du unseren Lesern kurz mehr über deinen Hintergrund und Deine derzeitige Rolle bei InGuardians und SANS erzählen?
Ich besetze mehrere Rollen – meistens widme ich meine Zeit ganz unterschiedlichen Aufgaben und Zielen. Zurzeit bin ich Director of Industrial Security bei InGuardians. Wir führen hauptsächlich Pentests und Sicherheitsbeurteilungen für industrielle Steuersysteme und IIoT-Geräte durch. Zudem sind wir intensiv im IT-Umfeld tätig, mit starkem Fokus auf Cloud-Sicherheit. Einer der führenden Researcher von Kubernetes gehört zu unserem Team. Einen Teil meiner Zeit widme ich unterschiedlichen Recherchen zu Protokollen oder Angriffstechniken oder experimentiere mit neuen Ideen. Außerdem bin ich seit über 14 Jahren Trainer bei Black Hat und seit 12 Jahren auch beim SANS Institute.
Gibt es eine Anekdote oder Geschichte über Dich, die noch nie (oder nicht oft genug) erzählt wurde?
Ich hatte meine allererste Vollzeitstelle bei einem Ingenieursunternehmen, das Schaltschränke baute, unter anderem für Wasseraufbereitungsanlagen. In der Sicherheits-Community ist das ziemlich bekannt.
Nicht bekannt jedoch ist Folgendes: Ich erinnere mich gerne daran zurück, wie ich in diesen Schränken Kilometer um Kilometer Kabel verdrahtete. Die Zusammenarbeit mit Ingenieuren, um Fehler im System aufzudecken, oder eigene Fehler bei der Verdrahtung des Systems waren zuweilen eine sehr schmerzhafte Erfahrung. Einmal, ich tauschte gerade ein paar Drähte aus, ließ ich den Schraubenzieher fallen… ich konnte ihn noch fangen, habe mir aber die Knöchel an Dutzenden der spannungsführenden Steckerteilen gestoßen. Und genau das Gleiche ist mir dann 15 Minuten später nochmal passiert :-).
Wie sieht ein typischer Arbeitstag für dich aus?
Das ist eine schwierige Frage. Meine Woche ist oft auf verschiedene Aufgaben und Ziele aufgeteilt. Manchmal verbringe ich eine ganze Woche mit Kursen, die ich leite, z.B. für Black Hat oder SANS. Und manchmal erledige ich den Schriftverkehr nach diesen Kursen, z.B. per E-Mail.
Natürlich reserviere ich auch einen Teil meiner Zeit für meine Arbeit bei InGuardians. Manchmal unterstütze ich unser Vertriebsteam, da die Kunden oft nicht wissen, was sie brauchen – sie wissen zwar, dass sie Unterstützung benötigen – allerdings nicht genau wobei. Häufig bin ich in irgendeiner Form in Pentests involviert. Ich beschäftige mich nicht mehr in Vollzeit damit, bin aber in die meisten Pentests eingebunden. Das ist der Vorteil, wenn man Chef ist: Man kann sich seine Tätigkeiten selbst aussuchen und muss keine Berichte mehr schreiben.
Ohne Namen zu nennen: Kannst Du uns einen realen Pentest in einem industriellen Umfeld beschreiben?
Zuerst einmal sollten wir zwischen den unterschiedlichen Arten von Pentests unterscheiden, die wir durchführen. Eine Art von Pentest wäre zum Beispiel die Suche nach Angriffspunkten in einem Produktionsnetz, beispielsweise in einem Werk oder an einem bestimmten Standort.
Pentests in ICS-Umgebungen unterscheiden sich deutlich von Tests einer Office-IT. Wir achten sehr genau darauf, wie wir mit dem System interagieren. Wir testen die Perimeter, aber sobald wir in das System vordringen, lassen wir größere Vorsicht walten; viele der Prozesssysteme fassen wir nicht an. Wir verbringen mehr Zeit mit der Überwachung, dringen aber normalerweise nicht in die Produktionszellen vor und versuchen auch nicht, uns Zugang zu den Prozesskomponenten zu verschaffen, da sie i.A. nicht nach Security-Gesichtspunkten konzipiert wurden.
Ein jüngstes Beispiel liegt etwa 3 Wochen zurück, als wir das Produktionssystem eines Lebensmittelproduzenten mit über 20 Standorten untersuchten und beurteilten. Wir gingen in zwei Schritten vor: Zunächst mussten wir den Perimeter des Unternehmensnetzwerks bis hinunter zur ICS-Infrastruktur testen. In einem zweiten Schritt prüften wir den Überwachungsgrad und die operativen Anlagen an einem der größeren Standorte.
Was war in diesem Fall die größte Herausforderung?
In der Woche bevor wir anfingen, sprachen wir mit mehreren Ingenieuren. Einer von ihnen sagte, es gäbe keinen Schutz und keinen Perimeter, und dass er im Übrigen nicht wirklich damit einverstanden sei, dass wir die Systeme am Standort untersuchten.
Als wir die Arbeiten durchführten, haben wir uns remote mit dem Standort verbunden. Aber auf Grund der klaren Ansage dieses Ingenieurs waren weder Ping Sweeps noch Portscanning möglich. Dadurch waren unsere Möglichkeiten deutlich eingeschränkt.
Selbst nach mehrfachen Anpassungen des Arbeitsumfangs gab es noch Unstimmigkeiten darüber, was genau zu unserer Arbeit gehört und wie wir fortfahren sollten, ohne Unterbrechungen zu verursachen. In erster Linie identifizierten wir die Unternehmenssysteme, die Informationen an die ICS-Systeme weiterleiteten, und prüften daher nur Angriffsflächen in den übergeordneten Systemen.
Das ist vielleicht ein ganz gutes Beispiel dafür, dass man unbedingt bereits im Vorfeld den Umfang und die Anforderungen klären sollte.
Kannst Du uns mehr über einen Test für ein IoT-Produkt sagen?
Ja genau, das ist die andere Art von Tests, die wir durchführen. Sie kommt eher für Labore in Frage, wo wir Produkttests zu unterschiedlichen Komponenten durchführen. Und da gehen wir deutlich aggressiver vor.
Etwa vor 5 bis 6 Wochen haben wir einen Produkttest für eine neue Sensorlösung durchgeführt. Dieses Gerät hatte eine Internetschnittstelle auf einem Aggregator, damit die Sensorsignale Daten über eine Mobilfunkverbindung senden konnten. Unser Team hat sich diese Schnittstelle genau angesehen und festgestellt, dass sie mit einer sehr alten CGI-Connection entwickelt worden war. Wir fanden eine Command-Injection-Schwachstelle und konnten so das CGI als Root ausführen. Die Architekturmethode, die auf dem Backend genutzt wurde, entsprach noch den Standards von vor 20 Jahren, obwohl das restliche eingebettete Betriebssystem vom Design her deutlich moderner war. Wir sind es wirklich gewohnt, Schwachstellen aufzuspüren, aber in diesem konkreten Fall haben uns die Design-Bugs doch überrascht.
Wie hat Euer Kunde Prioritäten bei den Gegenmaßnahmen gesetzt?
Wir wissen oft nicht, welche Maßnahmen unsere Kunden ergreifen. In diesem Fall haben wir im Auftrag des Anbieters gehandelt, der ein neues Produkt entwickeln wollte. Wir hoffen natürlich, dass der Kunde das Sicherheitsdesign vor der Markteinführung auf den neuesten Stand bringt, aber so genau wissen wir das natürlich nicht.
Kannst Du uns ein Beispiel für eine besonders herausfordernde technische Situation für Dich und Dein Team beschreiben?
Das ist einer der Gründe, warum ich ICS so mag – oft existieren noch keine guten oder vollständigen Lösungen. Man kann sich ICS als aus mehreren Schichten unterschiedlicher Technologielösungen zusammengesetzte Architekturen vorstellen.
Also verbringe ich einen Teil meiner Zeit damit, Tools zu entwickeln, um den verschiedenen Schichten auf den Grund zu gehen und Schwachstellen aufzudecken. Eine Herausforderung, vor der wir immer stehen: Es gibt nicht nur allgemeine, sondern auch individuelle oder proprietäre Protokolle.
Das ist beispielsweise der Grund, warum ich ctserial selbst entwickelt habe, damit ich Rohdaten verschicken und empfangen und mit vielen unterschiedlichen Systemen interagieren, eigene Pakete erstellen und die Rückläufe analysieren kann. Das ist auch das, was wir in meinen Black-Hat-Kursen machen: Wir versuchen uns an Reverse Engineering von Serienprotokollen. Wir schicken unseren Kursteilnehmern eine SPS (eine Velocio Ace 1600) und bringen ihnen bei, wie sie Zugang erlangen und ihr eigenes Test-Equipment für diese Schnittstelle entwickeln können.
Einige unserer Kunden fragen uns inzwischen nach automatischen Pentest-Lösungen. Was denkst Du darüber?
Ich glaube, dafür müssen wir zunächst einmal definieren, was „automatisierbar“ überhaupt bedeutet. Wenn automatisiert bedeutet, dass man ein Tool mit einem großen grünen Knopf kauft, es an das System hält und den Knopf drückt und dass das System dann seine Schwachstellen offenbart, dann ist das kein Pentest. Das Ausführen von Nessus ist kein Pentest.
Aber: Wir nutzen während eines Pentests viele automatische Tools, um effizienter zu werden. Eines der Hauptprobleme, die wir mit automatischen Tools bei ICS haben, ist, dass die meisten davon nicht genügend Informationen nutzen und nicht „intelligent“ genug sind, um sichere Prüfungen durchzuführen. Das hängt stark vom System ab, das man testet. Für unterschiedliche Szenarien müssen unterschiedliche Technologien genutzt werden.
Ist das Produktionsnetz derzeit abgeschaltet oder läuft es? In puncto Security macht das einen riesigen Unterschied.
Für Tests von IoT-Produkten in Laborumgebungen kann man häufiger automatische Tools verwenden und muss sich nicht so viele Gedanken darum machen, dass man etwas kaputtmacht. Andererseits führt man aber auch verstärkt manuelle Reverse-Engineering-Tätigkeiten durch, um Zero-Day-Exploits zu erkennen. Automatische Tools finden in der Regel nur bereits bekannte Schwachstellen.
In der IT-Welt haben automatische Tools die Produktivität von Pentestern gesteigert. Aber in einem industriellen Umfeld gibt es eine lange Liste mit Technologien, die (noch) keine automatischen Lösungen bieten, um bei der Untersuchung und Einschätzung von Sicherheitslücken zu helfen. Die meisten automatischen Tools dienen eher zum Erfassen von Informationen als für die Erkennung von Schwachstellen. Wir suchen nach ungewöhnlichen Problemen.
Es gibt unzählige Möglichkeiten, Fehler zu machen. Abstrahierung erleichtert Engineering und Programmierung, macht Security aber deutlich komplizierter.
Hast Du in letzter Zeit von Angriffen auf mittelständische Unternehmen gehört, die durch Cybersicherheitsmaßnahmen hätten verhindert werden können?
Ja, es gibt ständig Kunden, die von Cryptolocker und anderer Ransomware betroffen sind. Die meisten Verstöße und Angriffe sind auf einen schwachen Perimeter und fehlende Einschränkungen durch ACL oder Firewalls zwischen Subnetzen zurückzuführen. Schlechte Entscheidungen über die Gestaltung von Fernzugriffsmöglichkeiten sind eine weitere Schwäche.
Übrigens gibt es aus meiner Sicht gar keine reinen OT-Sicherheitsmaßnahmen. Fast alle unserer OT-Sicherheitstools basieren auf den gleichen Techniken, die wir für IT-Sicherheitstools nutzen, und in vielen Fällen kann das sogar ein und dasselbe Tool sein. OT-spezifische Tools „wissen“ in der Regel einfach ein bisschen mehr, z.B. über ICS-Protokolle. Das bedeutet: Wir können von dem in der IT vorhandenen Wissensfundus und den bestehenden Tools profitieren. Für Patch-Management empfehle ich z.B. normalerweise die Nutzung derselben Tools wie in der IT (aber mit 2 unterschiedlichen Deployments und 2 verschiedenen Teams, die diese steuern). Die Kompetenzen lassen sich also übertragen.
Welche Fehleinschätzungen oder (teilweise) falsche Annahmen kommen Dir häufig über OT- oder IoT-Sicherheit zu Ohren?
Eine ganze Menge. Hier ein paar besonders interessante Fehleinschätzungen:
- „Wir brauchen kein separates Active Directory für OT” (Problem: Anmeldedaten für OT-Systeme werden auf allen AD-Servern des Unternehmens gespeichert und gecacht. Eine Verletzung des AD Controllers bedeutet eine Verletzung aller Anmeldeinformationen für OT.)
- „Es ist okay, OT-Netzwerkgeräte (Switches, Router, WLAN) vom IT-Netzwerk aus zu steuern” (Probleme: Konfigurationen und Firewall-Regeln könnten sich verändern, Malware könnte auf Level 2 und untergeordnete Ebenen gelangen. Das Ethernet-WLAN könnte gehijackt werden.)
- „Eine umfassende VPN-Lösung für den Remote-Zugang zur OT ist sicher” (Problem: Möglichkeit für Remote-Nutzer, all ihre Daten zu übermitteln, statt die DMZ als Puffer zu nutzen und dann Anlagensteuerungen über einen Jump Host zugänglich zu machen.)
Ein weiterer Irrtum bei Level 3 (gemäß dem Purdue Reference Model) besteht darin, alle Server in dasselbe Subnetz zu „werfen“. Stattdessen sollten sie auch weiter in Subnetze oder VLANs unterteilt werden.
Welche konkreten neuen Trends oder Technologien für Cybersicherheit findest Du interessant?
Permanente Cloud-Verbindungen industrieller Komponenten und Systeme. Im Allgemeinen Cloud-basierte Lösungen, z.B. Management mehrerer Sensoren/Aktoren, oder für Datensammlung und -analyse. Im Transportsektor beispielsweise gibt es oft GPS-Einheiten und andere Sensoren, die Daten zu Motoren und Bremsen sammeln. Auch Pharmahersteller sammeln enorme Datenmengen zu ihren Prozessen und Abläufen.
Publisher-Subscriber IoT-Protokolle tauchen vermehrt im ICS-Umfeld auf, ebenso Containertechnologien. Für mich ist das eine progressive Fortsetzung – egal, was in der IT entwickelt wird: Wir nutzen es in der Regel einige Jahre später.
Wenn Du allen CIOs auf der Welt eine E-Mail schicken könnten: Was wäre Deine Kernbotschaft?
IT-/OT-Konvergenz ist nicht das Gleiche wie IT-/OT-Assimilierung.
Der Vorstand möchte bei der OT die gleichen Vorteile sehen wie bei der IT. Aber die Risiken sind ganz anders gelagert; unterschiedliche Sicherheitsmaßnahmen werden benötigt. Und dafür wird eine spezielle Abteilung oder ein dediziertes Team gebraucht. Weil es eben viele Ähnlichkeiten, aber auch Unterschiede beim Deployment gibt. Wir müssen die Nuancen verstehen und sie dem Topmanagement plausibel und verständlich erläutern.
Wir sollten versuchen, möglichst viele derselben Tools einzusetzen, um von den Mengenrabatten von Anbietern zu profitieren und Komplexität einzugrenzen. Trotzdem sollten wir diese Umgebungen weiterhin trennen und spezielle Teams bilden, die ausschließlich die Cybersicherheitsinfrastruktur in der OT unterstützen.
Die Risiken für die OT unterscheiden sich deutlich von den Risiken für die IT. Die OT ist viel anfälliger, viel „sensibler“ als die IT. Die Mitarbeiter müssen lernen, wie diese Unterschiede ihre tägliche Arbeit beeinflussen, und, was noch viel wichtiger ist: Sie müssen vertrauensvolle Beziehungen zu Technikern und Anlagenbedienern aufbauen, indem sie tagtäglich mit ihnen zusammenarbeiten. Das ist IT-/OT-Konvergenz. Es geht darum, die Umgebungen in ähnlicher Art und Weise zu betreiben, und zwar mit ähnlichen Tools und Governance-Programmen. Es geht aber NICHT darum zu versuchen, alles genau gleich und mit genau den gleichen Leuten zu machen.
Ü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.
