So many things to unpack.

Also:

1. 99%, LOL.
2. Der CCC ist mein Sicherheitscheck.
3. Wir werden sowieso gehackt, Aufgeben ist eine Option
4. Hackerterrorcybercyberversicherungen!!11elf!eins!

Aber der Reihe nach:
1. 99%, LOL.

pluspora.com/posts/6bd0e460…

"Sicherheit ist relativ", "perfekte Sicherheit gibt es nicht".

Stimmt.

Aber es gibt... besser und schlechter konfigurierte Systeme. Und bei digital-enabling.eu und esatus.com gab es eher... weniger gute.
bsi.bund.de/SharedDocs/Dow…

Es gibt 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".
Da stehen dann so aufregende Sachen drin wie SYS.1.1.A2 "Benutzerauthentisierung an Servern", SYS.1.1.A6 "Deaktivierung nicht benötigter Dienste"

Die stehen im Kapitel 3.1 "Basis-Anforderungen", Die [...] Anforderungen MÜSSEN [...] vorrangig erfüllt werden.
Waren sie eher nicht, "99%" sind das also eher nicht.

"Prozente" sind auch schwierig bei Security. Ein kompromittiertes System ist ja nicht 43% gehackt, sondern 100% im Eimer.

Ein besseres Bild: Raising the bar.
"Unsere Systeme sind so konfiguriert, daß nicht jeder spaßorientierte Mensch auf Mate damit an einem langsamen Samstagabend in Quarantäne damit Karussell fahren kann." wär schon mal ein guter Anfang.
So was in der Produktion im Öffentlichen Internet sagt ja auch was über den Rest des Ladens.

Also, es ist statistisch eher ungewöhntlich, dass so konfigurierte Server mit sauberer und geplanter Software-Entwicklung korrellieren.
Bei Software, die sagen wir mal Führerscheindaten verwaltet wäre es aber schon wichtig zu wissen, was da an Komponenten drin sind, und wer da wann warum welche Änderungen mit welchem Ziel vorgenommen hat, um dann an Tests zu sehen, daß das funktioniert hat.
"99% Sicherheit" würde 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 die Kiste dennoch 100% am Boden.

Nur, um die Diskussion mal zu kalibrieren.
2. Der CCC ist mein Sicherheitscheck.

Ist er nicht.

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 ersetzt kein Sicherheitskonzept.
Ein Sicherheitskonzept würde

- ein organisatorisches und inhaltliches Konzept für die Anwendung haben
- und einen Prozeß, der das dann in der Entwicklung umsetzt und testet
- ein ebensolches Konzept für den Betrieb
- und einen Prozeß der das...

und ganz wichtig:
- einen Plan, der umgesetzt wird, wenn es dann doch schief geht.

Das ist so selbstverständlich, daß uns das zum Punkt bringt:
4. Hackerterrorcybercyberversicherungen!!1!elf!1eins

(ja, die 3 kommt noch)

Wenn Du eine solcher HTCCV haben willst, dann wird der Versicherer nach den oa Plänen fragen, einen langen, strengen Blick drauf 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 einen Klick in der Leitung ist das eher nicht der Fall (siehe Portscan oben).
Der Versicherer wird also eher nach den oa Konzepten Fragen und dann seine Auditoren los schicken, je nach Risiko auch jährlich neu oder so, und die werden dann prüfen, je nach Risiko auch gerne tiefer.

Dann hat man den von mir oben geforderten Test, den Audit.
Meiner persönlichen Erfahrung nach findet ein Audit solche verschnarchten Setups wie das Eingangs in den ersten 15 Sekunden.

Das deutet darauf hin, daß eine solche HTCCV für dieses Projekt eher nicht bestand.
3. Wir werden sowieso gehackt, Aufgeben ist eine Option

Der Satz "hundertprozentige Sicherheit gibt es nicht" wird gerne als erster Halbsatz in der Aussage verwendet "und darum brauchen wir uns auch gar nicht anzustrengen".

Siehe den Clip ganz am Anfang.
Auf dem Laien ist intuitiv klar, daß das haltloser Dummlall ist, und ich habe hier versucht zu erklären, warum diese 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 <Grundmenge> wären denn in der Lage, einen ernstzunehmenden Angriff zu stagen?"

Also, wieviel Ausbildung, Zeit und Kapital braucht ein Angreifer, um mehr als <spock-eyebrow-raise.gif> zu aktivieren?
Wenn es also in der Gemeinschaft von technikaffinen Personen auf Mate Vorbehalte gegen dieses Führerscheinding gibt und Widersproch gegen Herrn Pohlmann oben, dann deswegen.
@threadreaderapp unroll wie immer, danke.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Kristian Köhntopp (but spooky)

Kristian Köhntopp (but spooky) Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @isotopp

1 Oct
Der @hikhvar schneidet hier ein weiteres sehr unangenehmes Thema an:

Wenn man mit mehreren externen Dienstleistern arbeitet, dann ist es auf viele Weisen schwieriger einen Projekterfolg zu haben.
Denn der Dienstleister arbeitet nicht für den Projekterfolg, sondern primär für den Vertrag.

Er muß das tun, um sich abzusichern, siehe @hikhvar.
Ändern sich die Anforderungen des Projekts oder sind in Teilprojektphasen Learnings aufgetaucht, die man in den folgenden Projektphasen einfließen lassen möchte, dann ist das alles schwierig.
Read 40 tweets
29 Sep
“Im DIDCOM v1 Protokoll wurde bisher das Problem von MitM-Attacken nicht ausreichend berücksichtigt, was der SSI-Community scheinbar bekannt ist und wofür es auch noch keine Lösung im Standard gibt.”
Der Angriff ist auf DIDCOMM 1 selbst, und entspricht demselben Angriff, den IMSI Catcher verwenden um das Mobilfunknetz zu kompromittieren, indem sie sich als Basisstation ausgeben, ohne es zu sein.

Lilith Wittmann und Flüpke haben einen IMSI Catcher für Ausweise gebaut.
Das ganze Projekt und sein Ablauf sind noch ein Hinweia auf weitere Dinge:

Dies ist ein Projekt des Bundeskanzleramtes mit der Bundesdruckerei, externen Dienstleistern, darunter Esatus und weiteren Stakeholdern, darunter Endanwender (ohne Repräsentation im Projekt).
Read 38 tweets
28 Sep
@HonkHase Das braucht wesentlich mehr Kontext.

Intel stellt zur Zeit eine sehr kleine einstellige Anzahl Millionen Xeon CPUs her. Davon gehen 85% an weniger als 10 Kunden - Hyperscaler in den USA und China.
@HonkHase 12% oder so gehen an ca. 150 Kunden, die zwischen messbare Stückzahlen der Produktion aufkaufen und der Rest ist Kleinscheiß an Kasperkunden.
@HonkHase Das ist eine sehr ungesunde Marktstruktur, und Intel hasst diese Position wie die Pest, schon bevor Apple mit ARM los ging und AMD mit dem EPYC auf den Markt kam. Diese beiden Ereignisse haben die Situation aber noch verkompliziert.
Read 20 tweets
27 Sep
Nachdem vor einigen Tagen der Supersichere Sovereign Identity Führerschein online ging wurden ja einige Probleme im Setup, in der App, in den Operations und in der Qualität des Hostings gefunden.

Die gesamte Webpräsenz des Security-Spezialisten esatus.com ist weg.
Als Security Spezialist haben die garantiert ein Incident Management am Start, das auch Krisenkommunikation abdeckt und Notfallpläne bereit hat.

Wo kommuniziert deren Krisen-PR-Mensch denn gerade und wie handhabt esatus.com den Notfall nach eigener Aussage gerade?
Es gibt zur Zeit einen Haufen Gerüchte, aber keine belastbaren Aussagen.

"Offener Name Server, offener Metrik Server, vermutlich fliegen keys zu wildcard Zertifikaten frei rum" ist halt eine tall order für einen Security Spezialisten und würde gern irgendwo deren Aussage sehen.
Read 4 tweets
27 Sep
Mal eine Beispielaufgabe (hier Seniro DBA/SRE Kontext):

Es ist 2010 und Booking hat eine Datenbankstruktur, bei der je 5 Frontend-Zellen mit einer Datenbank reden.

Writes und Reads sind bereits getrennt: Writes gehen zum Primary, dann Replikation. Image
Reads gehen zum festen Replica der Zelle.

Leider ist das wenig effektiv: Es gibt 10 Zellen in einem RZ, aber wenn eine Zelle ihre DB überlädt kann sie nicht auf Kapazität anderer Zellen ausweichen.

Außerdem ist das RZ nicht redundant.
Wir wollen:

1. Datenbank queries load balancen.
2. Die Replikationshierarchie auf 2-3 Rechenzentren (oder AZs) aufbohren

und optional

3. gehen Ausfall von Datenbanken, oder ganzen AZs resilient sein.
Read 15 tweets
27 Sep
Ich drehe in der Firma also gerade mal wieder Interview-Runden, und da ist ein ganz seltsames Pattern drin, in den Kandidaten.

Interview 2, "Systems Design" für SRE, das Interview nach dem Coding-IV. Es geht darum, irgendein PoC auf Produktion zu bürsten.
Das ist ein guter Teil Skalierung ("Wie viel Instanzen wird das fressen, bei der Load?"), ein guter Teil Resiliency ("Finde und identifiziere alle SPoF, und was sind gängige Patterns, die zu vermeiden?") und ein Teil Monitoring/Fehlersuche/Incident Analyse.
Das scheitert oft schon an grundlegenden Fragen.

"Hier ist ein System, das im Test auf dieser Instanzgröße lief und 5000 Requests/s geschafft hat. Wir wollen 250.000 Requests/s schaffen, und die Meßdaten 6 Monate halten."
Read 33 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(