<\/p>\n\n\n\n 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\u00fcck. K\u00f6nntest Du unseren Lesern kurz mehr \u00fcber deinen Hintergrund und Deine derzeitige Rolle bei InGuardians und SANS erz\u00e4hlen?<\/strong><\/strong><\/strong><\/p>\n\n\n\n Ich besetze mehrere Rollen \u2013 meistens widme ich meine Zeit ganz unterschiedlichen Aufgaben und Zielen. Zurzeit bin ich Director of Industrial Security bei InGuardians. Wir f\u00fchren haupts\u00e4chlich Pentests und Sicherheitsbeurteilungen f\u00fcr industrielle Steuersysteme und IIoT-Ger\u00e4te durch. Zudem sind wir intensiv im IT-Umfeld t\u00e4tig, mit starkem Fokus auf Cloud-Sicherheit. Einer der f\u00fchrenden Researcher von Kubernetes geh\u00f6rt zu unserem Team. Einen Teil meiner Zeit widme ich unterschiedlichen Recherchen zu Protokollen oder Angriffstechniken oder experimentiere mit neuen Ideen. Au\u00dferdem bin ich seit \u00fcber 14 Jahren Trainer bei Black Hat und seit 12 Jahren auch beim SANS Institute.<\/p>\n\n\n\n <\/p>\n\n\n\n Gibt es eine Anekdote oder Geschichte \u00fcber Dich, die noch nie (oder nicht oft genug) erz\u00e4hlt wurde?<\/strong><\/strong><\/strong><\/p>\n\n\n\n Ich hatte meine allererste Vollzeitstelle bei einem Ingenieursunternehmen, das Schaltschr\u00e4nke baute, unter anderem f\u00fcr Wasseraufbereitungsanlagen. In der Sicherheits-Community ist das ziemlich bekannt.<\/p>\n\n\n\n Nicht bekannt jedoch ist Folgendes: Ich erinnere mich gerne daran zur\u00fcck, wie ich in diesen Schr\u00e4nken 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\u00e4hte aus, lie\u00df ich den Schraubenzieher fallen… ich konnte ihn noch fangen, habe mir aber die Kn\u00f6chel an Dutzenden der spannungsf\u00fchrenden Steckerteilen gesto\u00dfen. Und genau das Gleiche ist mir dann 15 Minuten sp\u00e4ter nochmal passiert :-).<\/p>\n\n\n\n <\/p>\n\n\n\n Wie sieht ein typischer Arbeitstag f\u00fcr dich aus? <\/strong><\/strong><\/strong><\/p>\n\n\n\n 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\u00fcr Black Hat oder SANS. Und manchmal erledige ich den Schriftverkehr nach diesen Kursen, z.B. per E-Mail.<\/p>\n\n\n\n Nat\u00fcrlich reserviere ich auch einen Teil meiner Zeit f\u00fcr meine Arbeit bei InGuardians. Manchmal unterst\u00fctze ich unser Vertriebsteam, da die Kunden oft nicht wissen, was sie brauchen \u2013 sie wissen zwar, dass sie Unterst\u00fctzung ben\u00f6tigen – allerdings nicht genau wobei. H\u00e4ufig bin ich in irgendeiner Form in Pentests involviert. Ich besch\u00e4ftige 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\u00e4tigkeiten selbst aussuchen und muss keine Berichte mehr schreiben.<\/p>\n\n\n\n <\/p>\n\n\n\n Ohne Namen zu nennen: Kannst Du uns einen realen Pentest in einem industriellen Umfeld beschreiben?<\/strong><\/strong><\/strong><\/p>\n\n\n\n Zuerst einmal sollten wir zwischen den unterschiedlichen Arten von Pentests unterscheiden, die wir durchf\u00fchren. Eine Art von Pentest w\u00e4re zum Beispiel die Suche nach Angriffspunkten in einem Produktionsnetz, beispielsweise in einem Werk oder an einem bestimmten Standort.<\/p>\n\n\n\n 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\u00f6\u00dfere Vorsicht walten; viele der Prozesssysteme fassen wir nicht an. Wir verbringen mehr Zeit mit der \u00dcberwachung, 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.<\/p>\n\n\n\n Ein j\u00fcngstes Beispiel liegt etwa 3 Wochen zur\u00fcck, als wir das Produktionssystem eines Lebensmittelproduzenten mit \u00fcber 20 Standorten untersuchten und beurteilten. Wir gingen in zwei Schritten vor: Zun\u00e4chst mussten wir den Perimeter des Unternehmensnetzwerks bis hinunter zur ICS-Infrastruktur testen. In einem zweiten Schritt pr\u00fcften wir den \u00dcberwachungsgrad und die operativen Anlagen an einem der gr\u00f6\u00dferen Standorte.<\/p>\n\n\n\n <\/p>\n\n\n\n Was war in diesem Fall die gr\u00f6\u00dfte Herausforderung?<\/strong><\/strong><\/strong><\/p>\n\n\n\n In der Woche bevor wir anfingen, sprachen wir mit mehreren Ingenieuren. Einer von ihnen sagte, es g\u00e4be keinen Schutz und keinen Perimeter, und dass er im \u00dcbrigen nicht wirklich damit einverstanden sei, dass wir die Systeme am Standort untersuchten.<\/p>\n\n\n\n Als wir die Arbeiten durchf\u00fchrten, haben wir uns remote mit dem Standort verbunden. Aber auf Grund der klaren Ansage dieses Ingenieurs waren weder Ping Sweeps noch Portscanning m\u00f6glich. Dadurch waren unsere M\u00f6glichkeiten deutlich eingeschr\u00e4nkt.<\/p>\n\n\n\n Selbst nach mehrfachen Anpassungen des Arbeitsumfangs gab es noch Unstimmigkeiten dar\u00fcber, was genau zu unserer Arbeit geh\u00f6rt 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\u00fcften daher nur Angriffsfl\u00e4chen in den \u00fcbergeordneten Systemen.<\/p>\n\n\n\n Das ist vielleicht ein ganz gutes Beispiel daf\u00fcr, dass man unbedingt bereits im Vorfeld den Umfang und die Anforderungen kl\u00e4ren sollte. <\/p>\n\n\n\n <\/p>\n\n\n\n Kannst Du uns mehr \u00fcber einen Test f\u00fcr ein IoT-Produkt sagen?<\/strong><\/strong><\/strong><\/p>\n\n\n\n Ja genau, das ist die andere Art von Tests, die wir durchf\u00fchren. Sie kommt eher f\u00fcr Labore in Frage, wo wir Produkttests zu unterschiedlichen Komponenten durchf\u00fchren. Und da gehen wir deutlich aggressiver vor.<\/p>\n\n\n\n Etwa vor 5 bis 6 Wochen haben wir einen Produkttest f\u00fcr eine neue Sensorl\u00f6sung durchgef\u00fchrt. Dieses Ger\u00e4t hatte eine Internetschnittstelle auf einem Aggregator, damit die Sensorsignale Daten \u00fcber 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\u00fchren. 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\u00fcren, aber in diesem konkreten Fall haben uns die Design-Bugs doch \u00fcberrascht.<\/p>\n\n\n\n <\/p>\n\n\n\n![\"\"](\"https:\/\/cybercompare.com\/wp-content\/uploads\/2023\/09\/Justin-Searle_new-scaled-1-819x1024.jpg\")
![\"\"](\"https:\/\/cybercompare.com\/wp-content\/uploads\/2023\/09\/image-920x361-1.png\")
<\/figure>\n\n\n\n