Dale Peterson [Teil 1/2]
Dale Peterson ist der Co-Founder und Managing Director der Digital Bond Inc. Er hat langjährige Erfahrung im Bereich der IT-Sicherheit und ist Creator und Program Chair von S4 Events, der weltweit größten Konferenz für industrielle Cybersecurity.
Hallo Dale, wir freuen uns sehr, Dich heute hier begrüßen zu dürfen. Du blickst inzwischen auf eine 37-jährige Erfahrung mit allen möglichen Sicherheitsthemen zurück. Du hast Deine Karriere bei der NSA begonnen und unterstützt nun seit über 20 Jahren die Sicherheits-Community der Wirtschaft. Viele unserer Leser kennen Dich und sind auch Fans Deines Podcasts oder lesen Deinen wöchentlichen Newsletter. Kannst Du unsere Zuschauer an einigen besonders denkwürdigen Momenten Deiner Karriere teilhaben lassen?
Nun ja, 37 Jahre, das ist eine lange Zeit, aber ich würde sagen, dass die meisten besonders denkwürdigen Momente einfach so passiert sind und dass ich einfach Glück hatte, darüber zu stolpern. Ich stoße immer auf Dinge, die mein Interesse wecken, und stürze mich darauf, egal, ob es aus geschäftlicher Sicht profitabel ist.
Ein Beispiel: Ich habe in Illinois studiert und hatte vor, 1984 meinen Abschluss in Finanzen zu machen. Ich wollte Versicherungsmathematiker werden. Ich hatte aber diesen Artikel gelesen, dass das Außenministerium einen wirklich spannenden Test zur Eignung für den diplomatischen Dienst durchführte. Also wollte ich mich dafür anmelden, weil es viel aufregender klang als die Ausbildung zum Versicherungsmathematiker. Dort hieß es dann aber, ich sei zu spät; die Anmeldefrist sei bereits verstrichen. Es gebe aber noch eine andere Behörde, die National Security Agency, die auch einen Eignungstest durchführe. Ob ich nicht vielleicht daran teilnehmen wolle. Damals, 1984, wusste niemand ganz genau, wer oder was die NSA war. Also zuckte ich mit den Schultern und sagte: „Klar, warum nicht?“ Ich nahm an dem Test teil und schnitt letztendlich so gut ab, dass ich mich für die Position eines Kryptoanalysten qualifizierte. Ich hatte also die nötigen Kompetenzen, ein „Codeknacker“ zu sein, und bekam eine Stelle dafür.
Nicht vergessen, das war 1984. Mein Vater fragte mich damals, was ich denn mit diesen Fähigkeiten anfangen wolle. Niemand schere sich um Security! Das sei doch eine Sackgasse und ich solle an meinem ursprünglichen Plan, Versicherungsmathematiker zu werden, festhalten, denn das sei ja eine sichere Sache. Das und nichts anderes solle ich tun. Ich aber fand, dass der NSA-Job sehr spannend und interessant klang. Also habe ich mich dafür entschieden. Inzwischen wissen wir alle, dass Sicherheit ein wichtiger Bereich ist, und so hat sich das alles für mich sehr gut gefügt.
Mit ICS [Anm. d. Red.: Industrial Control Systems, also industrielle Steuerungssysteme] war es ganz ähnlich. Im Jahr 2000 waren wir ein kleines Unternehmen: Vier Leute arbeiteten als Sicherheitsberater und irgendwie wurde ein Wasserversorgungsunternehmen draußen im Mittleren Westen auf uns aufmerksam und kontaktierte uns. Ich weiß immer noch nicht, warum. Wir sollten das SCADA-System beurteilen. Klar! Ich wusste nicht einmal, was SCADA war. Aber wir brauchten den Auftrag, und da ich ja Berater war, sagte ich zu.
Am Ende mussten wir uns gegen IBM behaupten und schafften es irgendwie, den Zuschlag zu erhalten. Und je mehr ich mich mit der Materie beschäftigte, desto mehr begeisterte mich dieses Gebiet. Ich meine, statt in einem Rechenzentrum zu hocken, waren wir wirklich vor Ort und sahen uns Pumpwerke und solche Dinge an. Und da war mir klar: Das war genau das, was ich machen wollte. Wohlgemerkt, damals im Jahr 2000 war ICS-Sicherheit noch kein sonderlich zukunftsträchtiges Geschäft. Es gab eigentlich niemanden, den das wirklich interessierte. Ich war überrascht, dass sich diese Leute überhaupt damit beschäftigten und bin da quasi hineingestolpert.
Ich kann auch gar nicht sagen, dass alles von Erfolg gekrönt war. Ich bin auch in Bereiche hineingestolpert, die mir überhaupt nicht gefielen, zum Beispiel Sicherheitssysteme für Banken. Ende der Neunziger versuchten wir, ein Produkt für Online-Broker zu entwickeln, was sich aber als Flop erwies. Ich würde sagen, dass viele der besonderen Momente meiner Karriere aus Dingen entstanden sind, die ich wirklich gerne mache und spannend finde.
Welche Personen würdest Du als Mentoren bezeichnen, die Dich auf Deinem Weg vorangebracht haben?
Das ist schwierig, weil es nicht viele gab, die in meinem Bereich aktiv waren. Oft leistete ich mehr oder weniger Pionierarbeit. Die meisten „Mentoren“ waren eigentlich keine Personen, sondern vielmehr Bücher und Redner und Konzepte. Als ich mich dem Thema ICS-Sicherheit zuwendete, stützte ich mich stark auf Tom Peters, der damals einer der ersten war, der das „Brand you“-Konzept vorantrieb. Und er sprach darüber, wie man eine persönliche Marke entwickelt. Also kaufte ich sein Buch und fand heraus, dass man 50 unterschiedliche Dinge tun konnte, um sich in diesem Bereich einen Namen zu machen. Es sind also eher solche Leute, von denen ich gelernt habe oder die mir auf meinem Weg geholfen haben.
Was war eine der größten technischen Herausforderungen, die Dir in Deinem Tätigkeitsfeld begegnet ist, und wie seid Ihr im Team damit umgegangen?
Nun, wenn es konkret um technische Herausforderungen geht, dann hatten wir 2006 eine besonders harte Nuss zu knacken. Wir schlossen einen Forschungsvertrag mit dem Department of Homeland Security ab, um signaturbasierte Angriffserkennungsmethoden für ICS-Protokolle zu entwickeln. Einige der Protokolle wie DNP3 und Ethernet/IP erforderten Präprozessoren, um Pakete zu verarbeiten, die auf mehrere Pakete aufgeteilt und auf mehreren Ebenen des Stacks involviert waren.
Also stellte ich Daniel Peck ein, der extrem clever und erfahren war. Er versuchte ein oder zwei Monate lang, das Rätsel zu lösen, aber es gelang ihm einfach nicht. Wir waren aber in der Pflicht; wir mussten liefern. Also versuchten wir es immer und immer wieder. Vergeblich.
Schließlich beschlossen wir, jemanden an Bord zu holen, der zuvor einen der komplexesten Präprozessoren entwickelt hatte, und stellten ihn als Berater ein. Das erste, was er sagte: „Oh je, die gesamte Dokumentation ist ja falsch.“
Und er hatte Recht. Auch Jahre danach, also in den Jahren 2011 und 2012, war die Doku immer noch völlig falsch. Wenn man sich genau an die Vorgaben der Dokumentation gehalten hätte, wäre man gescheitert, aber der neue Berater sagte uns, wie es wirklich funktioniert. Daniel war nach einer Woche fertig.
Das war jetzt ein ganz konkretes Beispiel, aber es gibt noch eine ganz allgemeine technische Herausforderung, die jeden Anlagenverantwortlichen (Asset Owner) betrifft: Wir haben nur begrenzte Ressourcen und es gibt so viele Dinge, die wir tun könnten. Worauf konzentrieren wir uns?
Das Kriterium, das ich immer anwende, ist eine effiziente Risikominderung. Wo können wir mit jedem weiteren Dollar, den wir ausgeben, oder jeder weiteren Stunde, die wir darauf verwenden, das Risiko am stärksten senken? Ich halte das für ein sehr interessantes Problem. Und es erfordert auch ein gewisses Umdenken, denn meistens sind es nicht die Bereiche, von denen man automatisch ausgeht, sondern ganz andere. Das ist in jedem Unternehmen eine Herausforderung.
Wie gehst Du konkret vor, um Risiken zu bestimmen, z.B. gemeinsam mit Euren Kunden?
Der Schlüssel ist, sich gezielt auf die Konsequenzen zu konzentrieren. Wenn man so viel zu tun hat, ist es wichtig, sich zu fragen: „Kann ich, wenn ich diese funktionierende Sicherheitsmaßnahme umsetze, meine Risiken tatsächlich mindern? Und das weiß man erst, wenn man die Konsequenzen eines Angriffs kennt und weiß, ob eine Maßnahme die Wahrscheinlichkeit oder die Folgen eines Angriffs mindern würde. Und man muss natürlich Prioritäten setzen.
Wir beobachten derzeit immer mehr Cyberrisiko-Analysen [sogenannte Cyber-PHAs, Process Hazard Analyses]. Ich glaube also, dass die Industrie sich langsam damit zurechtfindet.
Welche aktuellen Entwicklungen bei industrieller Cybersicherheit findest Du besonders interessant?
Nun, das ist mein Metier. Unser S4-Event befasst sich mit diesen Dingen, sucht nach Innovationen und richtet den Blick darauf, was die Zukunft so bringen wird. Unser Slogan lautet sogar: „Create the future”. Ich verbringe inzwischen nur noch ca. ein Drittel meiner Zeit mit Beratung. Ich könnte also eine lange Liste herunterrattern, aber ich denke, für Eure Leser sind neue Sicherheitsentwicklungen von Level 1 am interessantesten – also SPS und Controller – es geht also um das, was jetzt verfügbar ist und um das, womit wir in ein bis drei Jahren rechnen können.
Wenn man darüber nachdenkt, dann ist eine der größten Herausforderungen der Schutz des eigenen Systems vor Angreifern, die sich bereits innerhalb des Systems befinden und so direkt Level 1 angreifen können. Wenn diese über die nötigen technischen und Automatisierungsfähigkeiten verfügen, haben sie freie Hand, weil diese Systeme per se vom Design her unsicher sind.
Alles, was man als Angreifer braucht, ist ein dokumentiertes Feature. Wenn man neue Firmware hochladen will, reicht der Befehl zum Hochladen von Firmware. Wer ein Programm ändern will, muss nur nach dem entsprechenden Befehl suchen. Man muss nichts hacken.
Wenn man diese Probleme kennt und löst, hat man einen großen Schritt hin zu einem besseren Schutz des Systems gemacht. Einige der führenden Anbieter bieten inzwischen signierte Firmware. Ein Riesenschritt! Damit packt man das Problem an der Wurzel: Keine Angreifer mehr, die schlechte Firmware entwickeln, hochladen und Geräte stören oder zerstören! Wenn man also nur noch vom Anbieter signierte Firmware hochladen kann, ist das eine enorme Verbesserung in puncto Sicherheit. Das sind Dinge, die jetzt für viele Systeme eingeführt werden können.
Und wir sehen inzwischen auch immer mehr verschlüsselte und authentifizierte Protokolle, z.B. Modbus Secure, PROFINET mit TLS-Verschlüsselung. Endlich sind wir dort angelangt, was wirklich toll ist.
Was mich längerfristig sogar noch mehr begeistert, ist die Idee einer Virtualisierung von Level 1. Alles außer IO ist virtuell. Wenn wir erst einmal so weit sind, lässt sich alles innerhalb von Minuten statt Monaten zerlegen und neu zusammensetzen. Das ist dann etwas ganz anderes.
Das Gleiche gilt für Level-1-Geräte, die im Grunde Computer sind. Emerson beispielsweise hat einen virtualisierten Controller. Aus Gründen der Sicherheit, Zuverlässigkeit, Wartbarkeit und Leistungsfähigkeit wird man künftig mehr davon sehen. In den USA sind die meisten größeren Kontrollsysteme, die eingesetzt werden, eigentlich virtuelle Plattformen auf Level 2. Und das wird sich in Richtung Level 1 entwickeln.
Viele unserer Klienten kontaktieren uns mit Fragen zur Cloud-Konnektivität und wie das sicher umgesetzt werden kann. Was denkst Du darüber?
Das ist in der Tat ein Thema, mit dem ich mich derzeit viel beschäftige. Am besten hat es Bryan Owen während unseres S4-Events im Jahr 2019 erklärt. Er unterschied in Open Loop und Closed Loop, weil dies die Sprache ist, die das Automatisierungsumfeld am besten versteht. Er sagt, dass man bei Open-Loop-Cloud-Services im Grunde Daten an die Cloud schickt, die dort verarbeitet, aber dann nicht mehr zurück an‘s Kontrollsystem geschickt werden.
Einblick in die bearbeiteten Daten erhält man vielleicht über ein Online-Portal; oder über regelmäßige Berichte oder Ähnliches. Man nutzt nur ein Einweggerät, die Datendiode, ein unidirektionales Gateway. Die gute Nachricht: Die Preise dafür fallen stark. Die waren lange Zeit sehr hoch. Ein solches Gerät mit ein paar Protokollen kostete früher mehrere Hunderttausend Dollar. Ich glaube, ich habe letztens eins entdeckt, das nur Tausend Dollar für eine kleine Anlage kostete.
Im Grunde ist das ein Kinderspiel. Jeder will Cloud-Services. Jeder will vorausschauende Wartung, Effizienz, Qualitätsanalysen, solche Dinge. Was keiner will, sind Risiken für die verfügbarkeit der Kontrollsysteme. Dann installiert man einfach so ein Einweggerät und fertig.
Schwieriger wird es beim Closed Loop. Angenommen, man möchte, dass der Cloud-Anbieter Informationen oder Befehle zurück an das Kontrollsystem sendet, um Prozesse zu optimieren oder zu regeln. Hier habe ich noch keine gute Lösung gesehen. Ich glaube, ich weiß, wie eine sichere Lösung aussehen könnte, aber bisher habe ich noch keine gesehen.
Was wir beachten müssen, wenn wir uns beispielsweise AWS oder Azure ansehen: Es gibt Edge-Devices, die die Kommunikation an die Cloud, die Authentifizierung, die Verschlüsselung, die Rechte in der Cloud etc. kontrollieren. So ein Edge-Device ist absolut notwendig. Es überrascht mich wirklich, wie häufig diese Closed-Loop-Cloud-Services heutzutage ohne Edge-Devices angeboten werden. Die bieten letztlich VPN mit einer Kommunikation von einem Server zum anderen. Und dann wird behauptet, man könne ihnen vertrauen. Das ist die eine Hälfte der Lösung. Die andere, die aber im selben Edge-Device stecken kann, ist eine Deep-Packet-Inspection-Firewall oder ein Gateway, wie Tofino oder M-Guard. Das haben schon einige. So ein Gerät kann buchstäblich vorgeben, was rein darf und was nicht.
Wichtig ist, dass die Anlagenverantwortlichen solche Funktionen aktiv einfordern. Das scheint meistens noch nicht der Fall zu sein.
Hier geht es zum zweiten Teil des Interviews mit Dale Peterson
Ü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.
