99% secure
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.
- 99 % Sicherheit, was soll das bedeuten?
- Der CCC ist mein Sicherheitscheck
- Hackerterrorcybercyberversicherungen und der Umgang mit Restrisiken
- 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 Sicherheitsprozess überhaupt nicht existiert.
Wie dem auch sei: Prozente sind bei Security ein schwieriges Maß. Ein kompromittiertes 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 muss.
Anders gesagt: “Unsere Systeme sind so konfiguriert, daß nicht jeder spaßorientierte Mensch auf Mate an einem langsamen Samstagabend in Quarantäne damit Karussell 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 Prozessreife in einer Organisation. Es ist statistisch eher ungewöhnlich, dass so konfigurierte Server mit sauberer und geplanter Software-Entwicklung von sicherheitskritischer Software korrelieren.
Bei Software, die sagen wir einmal Führerscheindaten verwaltet, wäre es aber schon wichtig zu wissen, daß ihr Entwicklungsprozess 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 Prozess, 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 Prozess, 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 Prozess ist wie jeder Prozess 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 Risiko-Managementprozess ist ein Prozess. Er unterliegt einer Evaluierung in der Retrospektive, 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 Prozessreife, etwa das Capability Maturity Modell, über das wir auch im obigen Pizzeria-Beispiel reden.
Und das bringt uns zu
Hackerterrorcybercyberversicherungen und der Umgang mit Restrisiken
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 Schutzlevel, “raising the bar” und wenn wir von Prozenten reden, dann eher mit Hinblick auf “wie viel Prozent von
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.