# Pentaradio vom 24. August 2021
# Titel: "Fruchtbarer Föderalismus"

Der Warntag letztes Jahr sowie die Flut dieses Jahr haben uns vor Augen geführt, dass nicht jedes technische System so resilient ist, wie wir es gerne hätten. Deswegen blicken wir diesmal darauf, wie man Resilienz erreicht, und woran es in der Praxis hakt. Außerdem gibt es News aus Technik und Netzpolitik.

## News

* [iOS-Geräte von US-Kunden scannen ab Herbst Bilder automatisch nach bekanntem CSAM (Child Sexual Abuse Material)](https://www.apple.com/child-safety/)
    * Betroffen sind alle Apple-Geräte ab iOS 15, watchOS 8 und macOS Monterey.
    * Wir empfehlen dringend die exzellente Besprechung des Themas in [Folge 403 von Logbuch Netzpolitik](https://logbuch-netzpolitik.de/lnp403-leichte-schlaege-auf-den-hinterkopf).
    * Kritik (1): ["Even if Apple’s heart is in the right place, my confidence that its philosophy will be able to withstand the future desires of law enforcement agencies and authoritarian governments is not as high as I want it to be."](https://www.macworld.com/article/353003)
    * Kritik (2): [Einschätzungen von einem Betreiber eines Imagehosters](https://www.hackerfactor.com/blog/index.php?/archives/929-One-Bad-Apple.html)
* [TPM security defeated in 30 minutes, no soldering required](https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-network-intrusion-in-30-minutes/)
    * "A pre-equipped attacker can perform this entire attack chain in less than 30 minutes with no soldering, simple and relatively cheap hardware, and publicly available tools, a process that places it squarely into Evil-Maid territory."
* Sammelklage: [Zoom stimmt Zahlung von 85 Mio. USD Entschädigung zu](https://arstechnica.com/tech-policy/2021/08/zoom-to-pay-85m-for-lying-about-encryption-and-sending-data-to-facebook-and-google/)
    * pro betroffenem Kunden etwa 15-25 USD
    * Problem Nr. 1: Zoom hatte behauptet, Ende-zu-Ende-Verschlüsselung zu haben (insb. für den Telemedizin-Markt), hatte aber nur Transportverschlüsselung (TLS).
    * Problem Nr. 2: Zoom hatte behauptet, keine Daten an Dritte weiterzugeben, hatte aber in der Web-App das Facebook-SDK sowie Google Firebase Analytics eingebunden.
    * Problem Nr. 3: Zoom hatte nicht hinreichend technische Vorrichtungen eingebaut, um Zoombombing zu verhindern (zum Beispiel einen Knopf für den Gastgeber, um einen unerwünschten Gast zu kicken).
* [Youtube-Uploadfilter: Tippgeräusche sind eine Urheberrechtsverletzung](https://twitter.com/marcan42/status/1420807961518088194)

Fundstücke:

* [Lisp-Interpreter in Malbolge](https://github.com/kspalaiologos/malbolge-lisp)
    * "Malbolge is a public domain esoteric programming language. It was specifically designed to be almost impossible to use, via a counter-intuitive 'crazy operation', trinary arithmetic, and self-modifying code. [...] The most complex programs made in Malbolge, to date, include an adder, a "99 bottles of beer" program, and a "Hello, world!" program (originally generated by a Lisp program utilizing a genetic algorithm)."
    * [Kommentar des Autors](https://news.ycombinator.com/item?id=28065573): "It's easy to program assembly, it's hard to write a compiler that targets good assembly. As humans we've been striving to make good compilers for ages, yet still we're not even close. So, I'd say, the fact that I made it _using_ a toolchain makes it even more impressive."
    * siehe auch: [Galerie aus Malbolge-Programmen](http://c0d3.attorney/)

Termine:

* 17.-19. September: [Datenspuren](https://datenspuren.de/2021/); Einreichungsfrist läuft noch!
* 26. September: Bundestagswahl
    * in Dresden ist [Briefwahl ab Montag, 30. August möglich](https://www.dresden.de/de/rathaus/politik/wahlen/bund/briefwahl.php), woanders evtl. abweichend
    * siehe dazu [Pentacast 55 über den Wahlprozess](https://c3d2.de/news/pentacast-55-wahl.html)

## Musik

* <https://freemusicarchive.org/music/Cara_Leigh_Produced_by_Cornelius_Julius/Resilience/Cara_Leigh_Produced_by_Cornelius_Julius_-_Resilience_-_01_House_Of_Cards>

## Thema: Resilienz

Nach dem katastrophalen Resultat des Warntags letztes Jahr haben wir jetzt noch einmal live gesehen, dass unsere Warninfrastruktur (mit schlecht gewarteten Sirenennetzen und einem Dschungel aus Warn-Apps) alles andere als **resilient** ist.

Laut [Wiktionary](https://de.wiktionary.org/w/index.php?title=Resilienz&oldid=8050016) ist Resilienz die...

> Fähigkeit von Lebewesen, ökonomischen oder sonstigen Systemen, sich gegen erheblichen Druck von außen selbst zu behaupten, äußeren Störungen standzuhalten.

Manchmal wird Resilienz auch definiert als Widerstandsfähigkeit gegen unerwartete Probleme (in Abgrenzung zu **Robustheit**, der Widerstandsfähigkeit gegen erwartete Probleme). Wir fassen im Folgenden beides unter dem Begriff Resilienz. Relativ synonym wäre "Fehlertoleranz".

Wie erreicht man ein resilientes System?

* Redundanz: mehrere Wege zum Ziel
    * z.B. Internet oder Stromnetz: Bei Ausfall einer Verbindung können andere Leitungen übernehmen.
    * z.B. Stellvertretung: Ist eine Person verhindert, kann ihre Vertreterin einspringen.
    * z.B. Bargeld plus Karte: Bei Netzausfall geht Bargeld noch. Bei Kontaktinfektionsgefahr wiederum ist Bargeld vielleicht keine gute Idee, aber kontaktloses Bezahlen geht noch.
    * z.B. 2-Faktor-Authentifizierung: Ein Dieb kann mein Token stehlen, aber nicht mein Passwort. Beim Hacker andersherum.
* Selbstheilung/Selbstmoderation
    * z.B. [Primärregelung im Stromnetz](https://de.wikipedia.org/wiki/Regelleistung_(Stromnetz)#Prim%C3%A4rregelung): Wird mehr Strom abgenommen als eingespeist wird, sinkt die Stromfrequenz, da den Turbinen in den Kraftwerken Rotationsenergie entzogen wird (Energieerhaltung!). Dies erkennen Sensoren in den Kraftwerken und fahren (in einem bestimmten Rahmen) selbsttätig die Kraftwerksleistung herauf, ohne das explizite Koordination mit dem Netzbetreiber erforderlich ist. (Und umgekehrt bei Einspeisungsüberschuss.)
    * z.B. [Sinuslauf von Eisenbahn-Radsätzen](https://de.wikipedia.org/wiki/Sinuslauf): Die Räder sind konisch (kegelförmig) geschliffen und verjüngen sich nach außen. Bewegt sich der Radsatz aus der Mittelstellung, ist die Lauffläche auf beiden Seiten unterschiedlich groß, wodurch der Radsatz eine Kurve vollzieht und sich wieder in Richtung der Mittelstellung zurückbewegt. Insgesamt ergibt sich eine Undulation um die Mittelstellung. Der Vorteil der ganzen Sache ist, dass die Spurkränze nicht ständig an den Gleisinnenseiten reiben, was zu einer höheren Laufruhe beiträgt und Verschleiß verringert.
    * oftmals Resultat von Redundanz: Ausnutzung redundant vorhandener Teile, um Probleme in einzelnen Teilen proaktiv zu erkennen und zu beheben
    * z.B. verteilte Speichersysteme (Ceph, Swift, etc.): Jede Datei wird mehrfach abgelegt (siehe oben). Wird eine Kopie beschädigt (etwa durch einen Schaden an einer Festplatte), kann dies erkannt und anhand der heilen Replikas behoben werden.
    * z.B. Container-Orchestrierung (Kubernetes, etc.): Von einem Programm (etwa einem Webdienst) werden mehrere Kopien gleichzeitig in getrennten Umgebungen (Containern) betrieben, deren Verhalten regelmäßig anhand von automatisierten Tests geprüft wird. Wenn sich eine Kopie daneben benimmt, wird sie gelöscht und ein Ersatz hochgefahren.
* Schadensbegrenzung
    * z.B. [Schotten](https://de.wikipedia.org/wiki/Schott#Schiffbau) (durchgehende Wände in einem Schiffsrumpf): Im Falle eines Lecks wird nur eine Sektion geflutet. Der Rest des Schiffes gibt noch Auftrieb und das Schiff sinkt [hoffentlich](https://de.wikipedia.org/wiki/RMS_Titanic) nicht.
    * z.B. sämtliche Systeme zur Zugsicherung in Eisenbahnbetrieben: Blocksignale, Zugbeeinflussung, Achszähler, usw.
    * z.B. [Netzwerksegmentierung, Firewalls](https://de.wikipedia.org/wiki/Firewall): Auch wenn der Angreifer sich Zugriff zu einem Computer im internen Netz verschaffen kann, kommt er nicht in den Rest des Netzwerkes.
    * z.B. [Sandboxing](http://blog.fefe.de/?ts=a332c5b4): Ein Programm deklariert im Vornherein, welche Systemfunktionen es benötigt, auf welche Dateien es zugreifen will usw. Falls ein Angreifer das Programm übernehmen kann, ist er dadurch in seinem Handlungsspielraum beschränkt.

Wir wissen also, wie es geht. Warum haben wir trotzdem so viele Systeme, die nicht resilient sind?

* falsches Mindset in der Designphase: Konzentration auf den Normalfall, siehe [Planungsfehlschluss (*planning fallacy*)](https://de.wikipedia.org/wiki/Planungsfehlschluss)
* Druck vom Chef: keine Zeit, um es ordentlich zu machen (oder [nicht genug Budget](https://www.landtag.nrw.de/portal/WWW/dokumentenarchiv/Dokument/MMD17-8437.pdf))
* fehlende Fehlerkultur: Sündenböcke suchen statt ehrlicher Problemanalyse
* gerade in der IT: ständiges Umbauen von Systemen gemäß den aktuellen Trends
    * z.B. Warn-App statt Cell Broadcast, weil Apps viel moderner sind und außerdem machen auch alle anderen jetzt Apps
    * "Wir bauen auf und reißen nieder, so haben wir Arbeit immer wieder."
* zu hohe Komplexität, dadurch mehr mögliche Fehler
    * Abwägung: Resilientes Design erfordert selbst zusätzliche Komplexität (z.B. für Aufbau von Redundanz). Es kommt darauf an, ob die zusätzliche Komplexität aus guten Gründen da ist.

Die folgenden anderen Podcasts wurden im Gespräch erwähnt:

* [CRE 171: Die Eisenbahn](https://cre.fm/cre171-die-eisenbahn)
* [WRINT 1264: Hochwasser-Risikomanagement](https://wrint.de/2021/08/10/wr1264-hochwasser-risikomanagement/)