Linus Neumann zitiert Prof. Norbert Pohlmann:

Ich glaube, das ist so. Diese 100%ige Sicherheit wird es nicht geben, und wenn der Chaos Computer Bild was findet, dann findet er das, und dann sagen wir, das ist gut. Und dann überlegen wir uns, wie wir das wieder schließen können und dann ist es wieder besser. Und dann können sie auch weiter suchen.

Also, ich glaube, wir brauchen auch eine andere Grundhaltung und es geht nicht immer um 100%, sondern die 99%, die reichen und wir müssen mit den Restrisiken umgehen. Neben ganz schnell reagieren auch natürlich auch Versicherungen oder wer übernimmt die Verantwortung, wenn was passiert. Das kennen wir ja alles.

Das ist eine ganze Menge Stoff zum Entpacken und ich habe das auf Twitter mal getan. Dies ist die Volltextversion dieses Threads.

  1. 99% Sicherheit, was soll das bedeuten?
  2. Der CCC ist mein Sicherheitscheck
  3. Hackerterrorcybercyberversicherungen und der Umgang mit Restrisiken
  4. Wir werden sowieso gehackt, Aufgeben ist eine Option.

Aber der Reihe nach:

99% Sicherheit, was soll das bedeuten?

Auf Pluspora hat Rainer Sokoll einen Portscan von www.digital-enabling.eu veröffentlicht, bevor der Server panisch vom Netz genommen worden ist:

~$ nmap -sT www.digital-enabling.eu.
Starting Nmap 7.92 ( https://nmap.org ) at 2021-09-25 14:24 CEST
Nmap scan report for www.digital-enabling.eu. (213.133.104.155)
Host is up (0.037s latency).
rDNS record for 213.133.104.155: www155.your-server.de
Not shown: 935 filtered tcp ports (no-response), 51 closed tcp ports (conn-refused)
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
25/tcp   open  smtp
80/tcp   open  http
110/tcp  open  pop3
143/tcp  open  imap
222/tcp  open  rsh-spx
443/tcp  open  https
465/tcp  open  smtps
587/tcp  open  submission
993/tcp  open  imaps
995/tcp  open  pop3s
3306/tcp open  mysql
5432/tcp open  postgresql

Nmap done: 1 IP address (1 host up) scanned in 55.71 seconds

Wir sehen einen Server, der mehr Dienste produktiv ins Internet raushängt als ein übertrieben konfigurierter Honeypot, darunter ftp, mysql und postgresql. Das ist, wie man mir in der Kundenkommunikationsschulung beigebracht hat zu sagen, “keine empfohlene oder unterstützte Konfiguration”.

Wenn wir also sagen, “Sicherheit ist relativ” und “perfekte Sicherheit gibt es nicht”, dann ist es doch so, daß man da differenzieren kann. Es gibt eben besser und schlechter konfigurierte Systeme.

Und es gibt sogar dokumentierte und allgemein anerkannte Best Practices, in englischer und deutscher Sprache. Von denen wird erwartet, daß man sie umsetzt.

Das nennt die deutsche Rechtsprechung nicht ohne Grund “Grundschutz” und “Stand der Technik”. Der Grundschutz, wie vom “Bundesamt für Sicherheit in der Informationstechnik” (BSI) veröffentlicht, hat viele Spezialhandbücher für besondere Anwendungszwecke. Der Grund-Grundschutz ist definiert in “SYS.1.1: Allgemeiner Server”.

Wie grundlegend ist der?

Der Baustein “SYS.1.1 Allgemeiner Server” ist für alle Server-IT-Systeme mit beliebigem Betriebssystem anzuwenden.

Das ist Amtsdeutsch für “Wenn Du das nicht machst, dann brauchst Du gar nicht weiter zu spielen”.

Im Grund-Grundschutz SYS.1.1 gibt es Grund-Grund-Grundschutzanforderungen, im Kapitel 3.1 “Basis-Anforderungen”. Dort wird in SYS.1.1.A2 “Benutzerauthentisierung an Servern”, gleich nach der geeigneten Aufstellung des Gerätes, gefordert:

Für die Anmeldung von Benutzern und Diensten am Server MÜSSEN Authentisierungsverfahren eingesetzt werden, die dem Schutzbedarf der Server angemessen sind.

Das ist Amtsdeutsch für “Benutzeraccounts ohne Passworte darf es nicht geben”.

Danach kommen ein paar Anforderungen aus früheren Versionen des Dokumentes und eine, die für Angriffe nicht relevant ist, und dann gleich als nächstes SYS.1.1.A6 “Deaktivierung nicht benötigter Dienste”:

Alle nicht benötigten Dienste und Anwendungen MÜSSEN deaktiviert oder deinstalliert werden, vor allem Netzdienste.

Wir müssen den Portscan da oben im Licht dieser grundlegenden Grundanforderungen vom allergrundlegensten ersten Kapitel des Grundschutzes lesen, von dem es einleitend heißt

Die folgenden Anforderungen MÜSSEN für den Baustein SYS.1.1 Allgemeiner Server vorrangig erfüllt werden.

Das war nicht der Fall.

Damit ist auch die 99%-Latte gerissen. Es geht stattdessen darum, dass überhaupt die allerersten grundlegenden Basisanforderungen nicht erfüllt werden, die man braucht, um überhaupt ernsthaft Security angehen zu können.

Es ist üblicherweise nicht möglich eine Maschine in der von Rainer Sokoll dokumentierten Konfiguration produktiv zu betreiben, wenn irgendein Auditor einmal auch nur oberflächlich über eine Systemkonfiguration geguckt hat. Wir können damit ausschließen, daß für dieses System und seine Betreiberorganisation ein Security Review stattgefunden hat, und es ist wahrscheinlich, daß ein Sicherheitsprozeß überhaupt nicht existiert.

Wie dem auch sei: Prozente sind bei Security ein schwieriges Maß. Ein kompromittierties System ist ja nicht 43% gehackt, sondern 100% im Eimer.

Ein besseres Bild: Raising the bar.

“Raising the bar” im Security-Sinne bedeutet üblicherweise, daß man den Personenkreis möglicher Angreifer verkleinern will, indem man versucht die Anforderungen höher zu schrauben, die ein erfolgreicher Angreifer an Ausbildung, finanzieller Ausstattung und Zeitaufwand mitbringen muß.

Anders gesagt: “Unsere Systeme sind so konfiguriert, daß nicht jeder spaßorientierte Mensch auf Mate an einem langsamen Samstagabend in Quarantäne damit Karussel fahren kann.” wäre schon einmal ein guter Anfang.

“99% Sicherheit” würde in dieser Interpretation also bedeuten, daß 99% der Population nicht in der Lage sind, die Installation im Vorübergehen mit dem Arsch einzureißen. Aber wenn einer vom 1% das tut, liegt das System dennoch 100% am Boden. Das ist eine wichtige Beobachtung, über die wir weiter unten noch einmal reden müssen.

So eine Konfiguration in der Produktion im öffentlichen Internet sagt aber auch etwas über die allgemeine Prozeßreife in einer Organisation. Es ist statistisch eher ungewöhnlich, dass so konfigurierte Server mit sauberer und geplanter Software-Entwicklung von sicherheitskritischer Software korrellieren.

Bei Software, die sagen wir einmal Führerscheindaten verwaltet, wäre es aber schon wichtig zu wissen, daß ihr Entwicklungsprozeß Anforderungen genügt, die es erlauben, Aussagen über die Software bezüglich Verhalten, Sicherheit und dergleichen zu machen. Man will mindestens erst einmal nachvollziehen können, was da an Komponenten drin ist, und wer da wann warum welche Änderungen mit welchem Ziel vorgenommen hat, um dann an Tests zu sehen, daß das funktioniert hat.

Der CCC ist mein Sicherheitscheck

Der CCC ist kein Sicherheitsdienstleister.

Als ich zuletzt nachgesehen habe war der CCC eine Vereinigung von Leuten mit dem Ziel, Spaß am Gerät zu haben. Das kann auch Dein Gerät sein, aber das ist dann eher schlecht für Dich.

Auf keinen Fall ersetzt das ein Sicherheitskonzept. Ein Sicherheitskonzept würde

  • ein organisatorisches und inhaltliches Konzept für die Anwendung haben,
  • und dann einen Prozeß, der dies in der Entwicklung umsetzt und dokumentiert, daß die Anforderungen erfüllt werden.
  • Dann hätte man ein ebensolches Konzept für den Betrieb
  • und einen Prozeß, der dies im Betrieb umsetzt und dokumentiert, daß die Anforderungen erfüllt werden.

Und ganz wichtig:

  • einen Plan, der umgesetzt wird, wenn es dann doch schief geht.

Denn es wird doch schief gehen - das sind dann die von Prof. Pohlmann angesprochenen Restrisiken. Hier sind ein paar Slides von Harald Wagener, basierend auf Ideen von Harald und ein paar noch älteren Slides von mir.

Ein Risiko Management Prozeß ist wie jeder Prozeß eine Schleife, bei denen man Angreifer und Angriffe identifiziert, Risiken bewertet, Maßnahmen gegen die Risiken definiert und umsetzt, und dann wiederholt. Die Maßnahmen können wir nicht beliebig weit treiben, denn betriebliche Notwendigkeiten setzen uns Grenzen: “Die Server abschalten und im Marianengraben versenken” ist keine Option. Damit bleiben uns Restrisiken, die eventuell versicherbar sind.

Der Riskiko Management Prozess ist ein Prozess. Er unterliegt einer Evaluierung in der Retroperspektive, und dann Anpassungen. Ich habe das am Beispiel einer Pizzeria anderswo schon einmal ausführlicher diskutiert.

Und während es super schwer ist, Security zu messen, gibt es immerhin Maße für Prozeßreife, etwa das Capability Maturity Modell, über das wir auch im obigen Pizzeria-Beispiel reden.

Und das bringt uns zu

Hackerterrorcybercyberversicherungen und der Umgang mit Restrisken

Ich sagte weiter oben

Aber wenn einer vom 1% das tut, liegt das System dennoch 100% am Boden. Das ist eine wichtige Beobachtung, über die wir weiter unten noch einmal reden müssen.

Das ist hier.

Eine HTCCV ist eine Versicherung, die Du abschließen kannst, um Schäden abzudecken, die auftreten, wenn Du dann doch gehackt wirst. Der Versicherer übernimmt dann die Kosten aus Forderungen gegen Dich, die im Nachgang zu so einem Hack auftreten.

Wenn Du so eine HTCCV haben willst, dann wird der Versicherer in der Regel seinen Taschenrechner anwerfen und Dir einen Tarif machen, der auf der Einschätzung Deiner Sicherheit durch einen von ihm beauftragten Auditor basiert.

Das heißt, der Anbieter wird Dich nach den oben erwähnten Plänen für ein Risiko Management fragen, einen langen, strengen Blick auf die Pläne und ihre Umsetzung werfen, und danach die Prämie bemessen. Wenn er die Risiken für versicherbar hält.

Wenn man nach dem Anruf beim Versicherer ein paar Tastendrücke hört, ein irres Kichern und dann einen Klick in der Leitung, dann ist das eher nicht der Fall - siehe den Portscan ganz oben.

Als Inhaber einer HTCCV wird man also regelmäßig, meist jährlich oder im jährlichen Wechsel mit einer Datenschutz-Prüfung die Auditoren im Haus haben. Sie werden jedes Mal einen grundlegenden Überblick haben wollen und jedes Jahr ein anderes Thema zur besonderen Vertiefung auswählen.

Damit hat man auch den von mir oben geforderten Test mit Audit als Teil der Versicherungsauflagen. Meiner persönlichen Erfahrung mit solchen Auditoren nach finden sie solche verscharchten Setups wie das ganz oben in weniger als 15 Sekunden. Das deutet darauf hin, daß auch eine HTCCV für dieses Projekt eher nicht bestand.

Wir werden sowieso gehackt, Aufgeben ist eine Option.

Der Satz “Hundertprozentige Sicherheit gibt es nicht” wird gerne als erster Halbsatz der Aussage verwendet, die mit “und darum brauchen wir uns gar nicht anzustrengen.” endet. Das ist auch der Tenor von Prof. Pohlmann oben.

Hope is not a strategy” ist nicht nur ein beliebtes Zitat, sondern auch ein gerne von Google SREs verwendetes Motto.

Auch dem Laien ist intuitiv klar, dass “Aufgeben” keine skalierbare Strategie ist. Ich habe hier versucht zu erklären, warum die Laien-Intuition genau auf den Punkt ist.

Darum reden wir von Schutzleveln, “raising the bar” und wenn wir von Prozenten reden, dann eher mit Hinblick auf “wieviel Prozent von wären denn in der Lage, einen ernstzunehmenden Angriff vorzutragen?" Also wieviel Zeit, Kapital und Ausbildung braucht ein Angreifer, um uns gefährlich werden zu können?

Wenn es also in der Gemeinschaft von technikaffinen Personen auf Mate Vorbehalte gegen dieses Führerschein ID-Wallet gibt, und Widerspruch gegen die Haltung von Prof. Pohlmann, dann deswegen.