“Vergiftetes Trinkwasser!”: Security-Vorfälle im Wassersektor

Panikmache oder echte Probleme?

Sie erinnern sich bestimmt noch an den Oldsmar-Vorfall — im US-Bundesstaat Florida war es einem Hacker gelungen, Chemikaliendosierungen im Prozessleitsystem eines Trinkwasserversorgers zu verändern, mit denen das Trinkwasser ungenießbar geworden wäre (siehe HardHats-Briefing im März).

Nun, zu Oldsmar gab es offenbar “Vorwehen” — genauer gesagt einen weniger bekannt gewordenen Vorfall ein paar Wochen zuvor in der Nähe von San Francisco, ebenfalls USA (NBC News-Artikel). Auch in diesem Fall wurde angeblich das Vergiften eines Trinkwasserversorgers versucht — dazu kommen wir gleich.

Der Weg? Klassiker, könnte man sagen: TeamViewer-Account eines nicht mehr beschäftigten Mitarbeiters. Er hat sich allerdings im Vergleich zum Oldsmar-Hacker wie ein Elefant im Porzellanladen verhalten, nämlich nicht Sollwerte verändert, sondern einfach “Programme deinstalliert, die für die Wasserbehandlung notwendig waren”.
(Ob mit den “Programmen” ganze Applikationen oder Steuerungslogiken gemeint waren, wird nicht weiter spezifiziert).

Das “und dann?” wiederum ist ähnlich wie in Oldsmar: Die Veränderungen wurden schnell bemerkt und rückgängig gemacht, das Trinkwasser war zu keiner Zeit beeinträchtigt.

Wie bewertet man also die Berichte über solche Vorfälle? Panikmache oder Hinweis auf echte Probleme?
Wie immer hat die Medaille zwei Seiten.

Seite 1: Panikmache

“Der Wassersektor ist total blank in der Security…”

Ich wiederhole gern meine Bemerkung aus dem März: Diese Szenarien (Nutzung eines Remote-Zugriffs, Veränderung von Sollwerten oder Steuerungslogiken) hat jeder Wasserwerker auf dem Schirm, der sich auch nur halbwegs mit Security auseinandersetzt — und meist ist die Einschätzung: “Das würden wir ratzfatz merken, bevor irgendwas wirklich Schlimmes passiert”. Wie wir sehen: Äußerst korrekte Einschätzung.

“Jemand hätte fast das Trinkwasser vergiftet!”

Man kann an der Berichterstattung über den San-Francisco-Vorfall auch durchaus kritisieren, dass zwischen “ich lösche alle Programme” und “ich vergifte das Trinkwasser” noch einige Lichtjahre Interpretationsspielraum sind.
Selbst wenn der Hacker sich etwas weniger wie ein Elefant im Porzellanladen bewegt hätte, ist es ja auch nicht so, als würde Trinkwasser in Sekundenschnelle vom Wasserwerk zum Endverbraucher gelangen. Dazwischen liegen Stunden, manchmal Tage, und viele biochemische Kontrollen.

Seite 2: Berechtigte Sorgen

Leichtfertiger Umgang mit Fernzugriffslösungen

Auch wenn die beiden Hacker, weder in Florida noch in Kalifornien, wirklich dramatische Auswirkungen hervorrufen konnten: Nicht mehr genutzte TeamViewer-Accounts, die einem Angreifer alle Möglichkeiten zur Interaktion mit einem Leitsystem geben, sind trotzdem ein Spiel mit dem Feuer. In den Händen eines Hackers, der weiß, was er tut, wären schwerere Auswirkungen natürlich denkbar, und wir müssen vielleicht nicht unbedingt warten, bis wir auf all diese schlummernden Zeitbomben von mäßig fähigen Hackern mit der Nase gestoßen werden…

Oder, in den Worten von Jake Brodsky in seinem etwas emotionalen Blogpost zum Thema Fernzugriffe:

”I know, the glossy magazines say you should have remote access because it saves money. Yeah, Right. Show me the business case. Unless managing the plant without remote access is impossible, this is bad advice. Typically this advice comes from people with very little time under a hard-hat. They came from the world of consultants and their ideas are what I like to call Corporate Pornography.”

Der eine Ingenieur, der “das bisschen IT nebenbei mitmacht”

Der Punkt führt uns weg von Schlaglichtern wie den Vorfällen wie denen in Kalifornien und Florida und hin zu einem strukturellen Problem, und das wird unter anderem in einem Report ersichtlich, den eine Gruppe von Organisationen, unter anderem das US-amerikanische Water ISAC, im Juni veröffentlicht hat. (ISAC steht für Information Sharing and Analysis Center, ein in den USA häufig gebrauchter Terminus für Organisationen, die Security- und vor allem Bedrohungsinformationen für eine bestimmte Branche sammeln und teilen.)
In dem Bericht geht es um den Security-Status in der US-amerikanischen Wasserindustrie. Nicht alle Ergebnisse sind auf Deutschland übertragbar, aber eines ist sehr ähnlich: Wasserversorgung ist meist kommunal organisiert, und die meisten Wasserver- und -entsorger bedienen weniger als 250.000 Einwohner. Zur Erinnerung: Der Schwellwert für die KRITIS-Regulierung in Deutschland sind 500.000 versorgte Einwohner. All die kleinen, kommunalen Organisation der Wasserbranche unter diesem Schwellwert haben keine gesetzliche Pflicht, aber meist erst recht keine Ressourcen, um sich um Security zu kümmern.

Schon bei den “mittelgroßen” ist der Zuständige für die IT (nicht: IT-Security) die eine Person, die sich hobbymäßig sowieso mit Netzwerken befasst und bei der Rollenvergabe nicht bei drei auf dem Baum war (true story aus dem Beraterleben). Und diese Geschichte soll nicht zeigen, dass Wasserversorger alle provinziell und inkompetent besetzt sind, sondern, wie unwichtig IT (nicht: IT-Security)-Kompetenz in ihrem täglichen Betrieb war und meist noch ist. Das macht es nicht leichter, wenn man sich plötzlich mit IT-Security (nicht: “nur IT”) befassen muss.

Die Debatte hat aufgrund der beiden Vorfälle und des veröffentlichten Water ISAC-Reports in den USA im Juni einige Wellen geschlagen. Einen lesenswerten Artikel des Security-Journalisten Brian Krebs finden Sie hier, einen ebenso lesenswerten Twitter-Thread aus dem Wassersektor (von @h2onolan) hier.

Kleine Erinnerung zum Schluss: Ende April gab es auch eine Studie zum deutschen Wassersektor. Auch wenn Security dort nur am Rande ein Thema ist — interessante Vergleiche zum US-amerikanischen Bericht lassen sich trotzdem ziehen.

Dieser Beitrag ist auch im monatlichen “Security Briefing für Hard Hats” erschienen.

Friction generates heat — true for writing and engineering. Fluchsfriction generates writings on security engineering. Heated debates welcome! CTO@admeritia

Friction generates heat — true for writing and engineering. Fluchsfriction generates writings on security engineering. Heated debates welcome! CTO@admeritia