Transcript: Security

Ja, hallo, liebe Hörerinnen und Hörer, willkommen beim Python-Podcast in der 26. Episode heute.

Heute ist das Thema Security, ein Thema, was ich persönlich sehr, sehr spannend finde.

Dazu haben wir natürlich auch wieder Gäste eingeladen, neben dem Jochen und mir, dem Dominik,

sind heute wieder dabei der Christian, der Toini und der Philipp. Hallo, Philipp!

Hallo!

Wie geht's euch? Stellt euch doch mal kurz vor, wer ihr denn seid, und dann erzählen wir ein bisschen was über die Folge.

Tja, wer fängt an? Also, ich bin der Jochen.

Wenn ihr diesen Podcast hört,

habt ihr mich wahrscheinlich schon einmal dabei gehabt.

Ja, okay. Also ich glaube,

das brauche ich gar nicht weiter ausführen.

Aber ich glaube, am interessantesten ist wahrscheinlich Philipp.

Der ist jetzt gerade zum ersten Mal dabei.

Genau. Ja, ich bin Philipp.

Ich habe bis vor kurzem noch

an der Uni Düsseldorf

studiert und nachher auch gelehrt

zum Thema unter anderem auch Security.

Also ich habe da die Vorlesung zur

Internetsicherheit, hieß die, glaube ich.

Oder wie haben wir sie genannt? Also intern hieß die einfach Security.

Die Security-Vorlesung

gehalten. Netzwerk haben wir sie genannt.

Also Netzwerksicherheit hieß sie offiziell.

Und bin jetzt

seit zweieinhalb Jahren arbeite ich

für die Firma Boxine in Düsseldorf.

Die ist wahrscheinlich bekannt durch ihr Produkt

die Toni-Box. Also wenn man kleine Kinder hat, dann kennt

man die Toni-Box. Und genau die läuft

auch mit Python. Vielleicht kommen wir da nochmal ein bisschen dazu.

Oh cool, da haben wir

letztens am Wochenende noch jemanden getroffen, der für die Firma arbeitet.

Ah, interessant. Ja, ja, ich habe mich jetzt

letztes Wochenende, genau mit Jens, den kennst du dann wahrscheinlich

auch lange unterhalten. Genau, der Jens ist auch in meinem Team.

Jens ist auch ein anderer, einer von den

Python-Entwicklern bei BoxCinema.

Ja, cool.

Ja, die Tony-Box ist super

beliebt. Ja, dass es ein Python-Projekt geworden ist.

Also ihr kennt ja bestimmt, das sind diese kleinen

Spielzeugfiguren, die man auf eine Box

stellt und dann spielen sie ein Hörspiel. Also für alle, die

keine Kinder haben.

Genau. Ja, schön.

Also heute das Thema Security. Wir wollen das so ein bisschen

aus mehreren Perspektiven beleuchten, die wir

noch gar nicht so genau festgelegt haben.

Ist wie immer, ich hab keine Ahnung, stell dumme Fragen

und die Jungs antworten ein bisschen.

Ja, fangen wir doch direkt an. Was ist denn Sicherheit, Security, was meint das denn? Also, dass niemand irgendwie einbricht und dann hat jemand irgendwie einen kaputten Pullover an und dann riecht er in so einem Rechner mit grüner Schrift und dunklem Monitor oder wie sieht das aus?

Das triffst du wahrscheinlich schon ziemlich gut. Du möchtest Systeme schützen vor irgendwelchen Angreifern. Das ist das grundsätzliche Prinzip der Sicherheit.

Du hast dann verschiedene Ziele. Ganz traditionell hat man die Intel gedreht, dass ich sagen möchte, niemand möchte etwas ändern.

Ich habe die Vertraulichkeit, dass ich sagen möchte, niemand soll herausfinden können, welche Daten meine Benutzer haben.

Zum Beispiel bei uns beruflich bei der Tonybox. Auf die kann man ja beliebige Audio-Teilen draufspielen.

Und es soll auf keinen Fall möglich sein, dass irgendjemand anders die Audio-Teilen von einem Kunden abrufen kann.

Also das wäre Vertraulichkeit.

Und dann haben wir noch Ziele, die werden manchmal so Zuverlässigkeit genannt oder Availability.

wo es halt darum geht, dass das System verfügbar ist die ganze Zeit.

Okay, also schon irgendwas, was einen auch privat betreffen kann natürlich

und vor dem man vielleicht geschützt werden möchte.

Ja, und wie macht man das in Python?

Ja, also ich würde jetzt so spontan sagen,

eigentlich hat man ja in Python schon mal ganz gute Karten,

weil ein großer Teil der wirklich bösen Fehler,

die einem da so begegnen können,

hat man jetzt in Python eigentlich gar nicht.

Also so mit Buffer-Warflows hat man eigentlich eher nicht so wirklich viel zu tun.

Obwohl, jetzt eigentlich schon wieder,

dem müsste ich erklären, was das ist.

Oh nein, das wollte ich schon.

Wir sind direkt eingeschrieben, du hast gesagt, man kann Fehler machen.

Und das bedeutet, dass Fehler zu Sicherheitslücken führen können,

die dann Angreifer ausnutzen können.

Ist vielleicht einer der Punkte, über die wir vielleicht reden,

welche Sicherheitslücken es denn gibt.

Aber was du sagst, heißt, es gibt Fehler, die jemand gemacht hat,

also ein Entwickler, eine Entwicklerin gemacht hat,

die dazu führen, dass es schwierig wird?

Genau, das Programm macht dann irgendwas,

was der Entwickler nicht gedacht hat.

Also der Entwickler dachte sich, okay, da kommen doch immer gute Daten.

Und dann hat jemand mit einem grünen Bildschirm und einem Kapuzenpulli nachher herausgefunden,

okay, wenn ich ganz bestimmte Daten sende, dann macht das Programm etwas, was der Entwickler nicht wollte

und erlaubt mir dann Zugriff auf irgendwelche geheimen Daten

oder im schlimmsten Fall erlaubt mir sogar Code auszuführen bei irgendjemand.

Genau, das wollen wir halt verhindern.

Und da gibt es halt eine ganze Menge Schwachstellen, je nachdem, auf welcher Plattform man ist.

Also zum Beispiel auch mit Python gibt es Unterschiede natürlich,

wenn ich einen Treiber schreibe, dann kann auch der erwähnte Buffer-Overflow vielleicht schon mal passieren.

wenn ich mit Python eher eine Web-Anwendung

schreibe, dann muss ich mir da halt typische

Sicherheitsblicken anschauen. Aber das ist eigentlich immer,

dass ich irgendwelche Eingaben des

Benutzers nicht richtig

interpretiere und dann plötzlich komische Sachen mache.

Benutzer-Eingabe, Speicher, also Buffer-Overflow, vielleicht noch mal

ganz kurz, dass irgendwie der Speicher läuft

voll und dann kommt man in Bereiche rein, die

das Programm gar nicht vorgesehen hat und dann

passieren komische, magische Dinge.

Das ist dann diese Blackbox der

Mensch mit dem kaputten Pullover.

Naja, also ganz, ganz kurz

irgendwie, ja, ist auch eine relativ spezielle Art

von Sicherheitsproblemen, aber das

war irgendwann, ich glaube, das war dann Mitte der 90er,

ich weiß nicht mehr so ganz genau, gab es einen Artikel

im Frag Magazine

von Aleph One

irgendwie, Smashing the Stack for Fun

and Profit und

es betrifft vor allen Dingen die

Programmiersprache C, die ist halt,

da sind Strings Nullpointer terminiert

und, naja,

Ach so. Genau.

Also da steht nicht

einem String vorher dran, der ist jetzt so und so

lang und dann liest man halt nur bis da,

sondern man liest halt so lange, bis halt ein Nullbyte

kommt und dann hört man halt auf damit

oder halt eben auch nicht, wenn man irgendwie das

falsch macht. Ah, das heißt, wenn man am Ende sagt, da sind

gar keine Nullbytes, sondern sein eigener Code, dann liest

ja gar nicht, liest das immer noch weiter. Genau,

wenn man zum Beispiel einen festen Buffer definiert hat

und aber nicht

überprüft, ob die Eingabe von dem Benutzer halt

vielleicht länger ist, dann kann man halt über den Buffer

hinwegschreiben unter Umständen

und dann halt auch, also was man

dann macht, man schreibt dann irgendwie eine Menge

ein NOPS, was ist das?

Irgendwas A oder so

rein, hofft dann, dass

beim Rücksprung aus der Funktion irgendwie

man in diesem Bereich landet und dann rutscht

es halt durch bis zu einem Shell-Code, den man mit reingeschrieben

hat. Und dann kann man also im besten Fall

irgendwie direkt das Programm

komplett übernehmen. Und

ja, das war

lange Zeit war das ganz,

viel Server-Software hatte

diese Fehler und man konnte das halt ausnutzen.

Obwohl, ich meine, heute spielt

das vielleicht auch immer noch eine Rolle, vielleicht eher

so bei Clients, ich glaube Server,

obwohl gibt es vielleicht immer noch, ich weiß es nicht mehr so genau,

ich habe auch lange nicht mehr drauf geguckt.

Ja, aber das ist halt so eine, das ist eigentlich genau

so das, was sich Leute vielleicht

vorstellen, wenn man

davon redet,

dass jetzt irgendwie irgendwelche

Server gehackt werden oder so.

Man gibt irgendwas ein oder führt ein Programm

aus und dann hat man eine Shell auf einem anderen System,

wo man einfach Code ausführen kann oder beliebige

Kommandos. Da kann man

auch tatsächlich sozusagen diese Perspektiven

von, man muss halt

da kann man nochmal einen ganzen Schritt zurückgehen, weil

im Prinzip das Thema Sicherheit

kann man noch weiter aufmachen

wenn ich halt

Philipp hatte gesagt

Anwenderinput, das ist so ein

das muss oder kann man noch weiter

abstrahieren, weil im Prinzip

sind Viren halt auch nichts anderes als

Anwenderinput

das ganze Thema von

Security lässt sich halt darauf

zurückführen, warum muss ich überhaupt darüber reden, warum

macht ein Programm überhaupt was, was man nicht will

lässt sich halt

stark darauf zurückführen, dass

wir halt eine sogenannte Verneumann-Architektur

haben. Ja, das geht halt zurück

auf die, was weiß ich jetzt, gar nicht mehr.

Mir wurde immer vorher geworfen, Opa redet

vom Krieg, aber da war ich nicht dabei.

60er, 70er,

irgendwo da, noch älter, 40er

Verneumann-Architektur, noch älter.

Das war vor dem

Zweiten Weltkrieg wahrscheinlich sogar.

Irgendwo da.

Also als es so richtig losging, gerade erst

mit den ganzen allgemeinen Rechenmaschinen.

Und die von Neumann-Architektur hat halt ein wichtiges Konzept

und das ist halt, dass der Programmspeicher

und der Datenspeicher eins sind.

Es gab früher Rechner-Architekturen,

da waren Daten von der Eingabe

und die Daten, die den Prozessor gesteuert haben,

also das Programm, komplett getrennt.

Macht halt das große Problem,

dass du nicht einfach irgendwie Programme als Daten runterladen und ausführen kannst.

Also der Effekt, den wir dadurch haben von der Neumann-Architektur ist ja,

ich kann ins Internet gehen, kann mir Daten runterladen und sie dann als Programm ausführen.

Das Problem ist aber, der Vorteil ist gleichzeitig der Nachteil.

Das heißt, auch Daten, die vielleicht gar nicht als Programm gedacht waren, werden als Programm ausgeführt.

Und das ist sozusagen die ganze Krux daran, dass die CPU schon nicht unterscheiden kann von,

sind die Bytes bei mir gerade gedacht für, ich soll mit ihnen rechnen

oder ich soll damit meinen Instruction-Pointer befüttern.

Und das kannst du halt, da gibt es ein,

dieses Grundproblem wird never ever jemals weggehen.

Das geht nie weg.

Na gut, also, moderne CPUs haben ja durchaus einige Verteidigungen dagegen.

Also, moderne CPUs haben einen Marker, wo dann drin steht,

okay, diese Speicherseite ist ausführbar oder nicht.

Und genau das geht ja dann schon in Richtung der konkurrierenden Harvard-Architektur ein bisschen,

dass man sagt, okay, das sind die Daten, das sind die Instruktionen.

Aber natürlich gibt es immer noch Tricks.

Also selbst bei den Buffer-Overflows

gibt es halt sehr, sehr viele Möglichkeiten,

wie man genau dann doch irgendwie noch ein Programm konstruieren kann,

das dann eigentlich nur aus Daten besteht.

Also wo du sagst, okay, das sind eigentlich nur Daten,

aber die auf komischen Stellen liegen

und dann trotzdem den Programmfluss irgendwie beeinflussen.

Das ist spannend, weil ich wollte eigentlich zu dieser Frage mit den,

was machen denn die CPUs dann da falsch,

ganz zum Schluss kommen, ihr habt ja jetzt damit den Einstieg gefunden,

Das ist die unterste Ebene, auf der wir jetzt anfangen.

Ich finde das aber sehr spannend, weil was du sagtest,

dass diese unterschiedlichen Architekturen,

also ich glaube, von Neumann nennt man auch irgendwie Princeton-Architektur.

Und ich glaube, es war irgendwie, ich habe gerade nachgeguckt,

1945, als sie rausgekommen ist.

Und diese Harvard-Architektur, die daneben liegt,

die macht halt diese Getrennung von Daten und Programmspeicher.

Und du sagst jetzt, es gibt auf dem CPU,

also der CPU benutzt für alle Menschen, die vielleicht nicht so drin sind,

Opcodes, also Operation Codes.

Das heißt, die sagen, was für eine Rechenoperation

der machen soll, der Kern.

Und dann macht der genau mit den Daten,

die ihm dazu geschickt werden,

in den einzelnen, was sind das, Decks?

Nein, Registern irgendwie,

macht der dann diese Operation.

Und da kann was schief gehen.

Philipp, vielleicht kannst du das

noch ein bisschen erklären,

weil das klingt ja sehr spannend.

Ja, weil wenn ich einen ganz klassischen

Buffer-Overflow habe, was dann halt passiert ist,

wie gesagt, der Benutzer,

der Benutzer in Anführungszeichen,

aber in Wirklichkeit ist das der Angreifer,

gibt halt irgendwie eine längere Datenfolge an

und wie wir eben schon erwähnt haben,

da könnten dann zum Beispiel verschiedene Instruktionen

wie Knob-Codes drin vorkommen

und das sieht aus wie ein normaler Text,

aber das ist halt genauso designt,

dass man das auch als Ob-Codes für die CPU interpretieren kann.

Und genau das ist das Problem dann nachher,

dass der Entwickler dachte, okay, da kommt einfach nur Text rein,

aber in Wirklichkeit hat der Angreifer den Text so geschickt konstruiert,

dass er ein gültiges Programm ist.

Und es ist sozusagen, wir können für die CPU, weil das konkret zu machen ist häufig sehr schwer so im Luftlernraum, aber weswegen ich schnell zur Neumann-Architektur gegangen bin, ist, das Problem ist ein ganz grundsätzliches Architekturproblem und die Features, die wir jetzt da oben drüberlegen, wie zum Beispiel non-executable pages und so ein Kram oder was dann halt auf anderen Ebenen kommt, Address Randomization und so ein Zeug.

Das sind alles bloß kleine Trostpflaster und man macht es den Angreifern schwerer und teilweise auch um Größenordnungen schwerer, dagegen anzukommen, aber das Restrisiko kann in der Architektur halt nie weggehen, sie wird nie weggehen.

Und die Effekte, die wir aber sehen, lassen sich auf anderen Ebenen genauso wieder erklären und ein Buffer-Overflow lässt sich gut vergleichen und das ist für viele Leute wieder einfacher vorstellbar, wie mit einer SQL-Injection.

Das ist genau das Gleiche.

Die SQL-Injection ist, gib hier bitte deinen Namen ein

und dann kommt das berühmte

Mein Name ist Bobby bla bla bla

Semikolon Drop Tables.

Und auch da ist es so,

das Programm hat gedacht,

ich habe eine Eingabe

und die Datenbank

haut dann aber einmal volle Kanne daneben

und sagt, na das ist doch jetzt die nächste Query hier.

Weil wir drücken ja alles als Text aus.

Der Name ist Text

und das Programmierstatement

für die SQL-Datenbank ist auch nur

Text und wird dann aber eben

als Programm interpretiert. Und wenn

ich das eben nicht richtig

escape an der Stelle,

dann finden solche Modusübergänge statt,

wo etwas, was eigentlich als Eingabe zu verarbeiten

gewesen wäre. Und der Trick ist ja eben der

von Neumann Architektur,

die SQL,

das SQL-Statement,

was ich an den Server drücke, ist ja aus

Server-Perspektive erstmal Daten,

die als Programm zu interpretieren

sind. Und wenn da drin halt Mist stattfindet,

dann geht da alles quer durcheinander.

Und das ist im Buffer-Overflow im Prinzip nichts anderes.

Also das Glas Milch, das zu voll ist und dann tropft das auf die Erde und dann hat man alles nass und denkt sich, oh nein.

Ja, genau.

Buffer-Overflow ist sozusagen die Variante von, das Glas ist zu voll.

Und auch Python schützt einen vor sowas im Prinzip erstmal nur im Sinne von, ja, Python selber gibt sich extrem viel Mühe, selber keinen Mist zu machen.

Wenn du aber, und ich habe mit sowas halt selber auch, also ich sage immer, ich fasse C nur dann an, wenn die anderen es verrissen haben.

Ich schreibe nie C-Code neu.

Ich habe den C-Code nur in der Hand,

wenn die anderen es völlig kaputt gemacht haben

und ich gerade so noch weiß, wie ich es wieder ganz mache.

Der Psycho-PG ist zum Beispiel halt im Datenbankumfeld.

Da merkt man so, dass die Leute halt eigentlich keine C-Programmierer sind,

wenn man den Code anguckt.

Und es hat lange gehalten.

Philipp macht genau das richtige Gesicht.

Das können jetzt die Podcast-Hörer nicht hören.

Aber wir haben so einen Corona-tauglichen Video-Back-Channel.

Und da ist es halt zum Beispiel so, nicht jeder Buffer-Overflow ist gleich halt als Security-Problem ausnutzbar.

Bevor ich halt sozusagen selber Code ausführen kann, kommen noch andere Fehlerklassen oder Effekte vorher.

Typischerweise ist das dann erstmal ein Denial of Service, also zum Beispiel, dass halt das Programm crasht.

Das ist erstmal noch nicht so dramatisch, das ist natürlich auch aus dem Thema Availability als eine der vier Sicherheitsperspektiven.

Nur die Recovery ist halt einfacher typischerweise.

Bei dem Crash starte ich im schlimmsten Fall, starte ich normalerweise die Anwendung einfach neu, dann geht es weiter.

Und beim Psycho war es zum Beispiel so, dass es im Postgres gibt Encoding-Namen.

Und die meisten Encoding-Namen, die von den Leuten verwendet werden, haben ein Minuszeichen drin.

ISO 88591 und so ein Kram.

Und im Psycho-PG ist es so, dass der Encoding-Buffer tatsächlich davon ausgeht, dass da ein Minus drin ist und sie meinten, es wäre eine gute Idee, sie müssen alles normieren und die Minusse rausnehmen.

Und das ist im Postgres auch okay, der hat die ganzen Encoding-Namen auch immer noch mit ohne Minus rumliegen und ein Kunde von uns kam aber dann damals auf die Idee, es gibt in Postgres einen Alias für UTF-8, der heißt Unicode.

So, und dann hat der Psycho halt gesagt, naja, jetzt kommt hier ein Encoding-Name, also streiche ich das Minus raus,

allozie einen neuen Buffer, der genau ein Byte kürzer ist und schreibt dann Unicode ohne Minus in einen statt, was haben es,

U-N-I-C-O-D-E, in einen sechs Byte langen Buffer statt in einen sieben Byte langen Buffer.

Und weil sie aber nicht einfach nur malloc benutzt haben, weil ganz kleine Objekte zu allociieren im Speicher halt ineffizient sein kann,

hat Python einen sogenannten Small Object Allocator.

Damit kann ich eine Page, die ist typischerweise ein K oder sowas, je nachdem, System kann ja auch ein Megabyte oder größer sein, aber gehen wir mal von einem K aus oder 4K, dann packt Python halt solche 6-Byte-Objekte alle zusammen in eine Page und dann brauche ich halt statt irgendwie, wenn wir kurz rechnen, 1066 sind 20, nee, 200, 200, dann brauche ich halt statt 200 Pages, also statt 200K nur 1K.

Die werden eng an eng hintereinander gepackt und was dann passiert ist, ist, dass der Server, der das hatte, so alle Woche mal gecrashed ist und ich habe das halt versucht rauszufinden und irgendwann habe ich da mit, ich glaube, ich habe mit Guido mal reingeguckt, ich habe mit Martin von Löwis reingeguckt, allmöglichen Leuten und irgendwann haben wir festgestellt, der schreibt dann halt manchmal genau auf den letzten Eintrag in dieser Page dieses eine Byte zu viel

Und das eine bei zu viel in einer sogenannten Arena im Small Object Allocator

ist der Pointer auf die nächste Arena.

Und der landet dann halt im Nirvana.

Und dann gibt es halt ein SegFault und dann sagt das Linux halt, so geht es hier nicht.

Und das ist ein typisches Beispiel für, da hat jemand dann einen zu kleinen Buffer alloziiert.

Das ist dann ein Buffer-Overflow.

Er schreibt mehr Daten rein, als da reingehören, weil er sich einfach bloß verrechnet hat.

Und der Effekt muss noch nicht sein, dass jemand Code ausführen kann.

Aber der Effekt ist halt typischerweise, dass das Programm anfängt Müll zu machen und dann haben wir, Philipp hat da ja auch genickt, schon mal die Availability, die Verfügbarkeit von der Anwendung reduziert und das ist ein Sicherheitsproblem tatsächlich auch.

Genau, es könnte ja auch dann sein, dass das nachher auf einem Server irgendwo läuft, wo dein Postgres läuft und das kann vielleicht auch jemand, den Server möchtest du für viele Kunden bereitstellen und dann ist es auch richtig kritisch, wobei hoffentlich niemand dein Encoding im Server steuern kann, das wäre wahrscheinlich eine andere Sicherheitslücke.

Ja, aber also Denial of Service ist halt, das ist böser, als die meisten Leute so zunächst vermuten würden. Ich meine, wir hatten ja jetzt auch letztens irgendwann in Düsseldorf an der Uniklinik ja auch so einen eher gemeinen Fall. Irgendwie so diese Ransomware-Geschichten, die es da gibt. Ich weiß nicht, das war irgendeine Remote-Verwaltungssoftware. Ich weiß nicht, den Namen wieder vergessen.

Citrix. Citrix, genau.

Ja, irgendeine uralte Version davon und dann

ist irgendjemand hingegangen und hat denen ihre Daten

verschlüsselt oder so und hat sie erpresst.

Und da ist, glaube ich, dann tatsächlich auch jemand bei gestorben oder so.

Das war irgendwie sehr unschön.

Ja.

Das ist dann auch der Teil,

den grenzt man in der Security manchmal ab.

Im Englischen ist es halt... Safety.

Ja, das ist im Deutschen

haben wir das sozusagen nicht getrennt.

Ich finde das eigentlich so ein schönes

Beispiel, dass

Konzepte mit

extra Begriffen in anderen Sprachen einem nochmal

einen neuen Blick liefern, dass

Sicherheit im Englischen halt mit Security und mit Safety

übersetzt werden kann und Safety

ist halt die auf Menschenleben

und körperliche Unversehrtheit bezogene

Perspektive von Sicherheit

und Security ist halt die Frage, ob das

Fahrrad noch da ist. Aber kannst

du das denn in der modernen Gesellschaft wirklich auseinanderhalten?

Ja, das ist halt sozusagen genau

das Thema, dass man

und damit machen wir jetzt einen schönen

nächsten Bogen, dass Security extrem

kontextspezifisch ist.

Also ich stelle mir gerade die Gesichtsbemalung vor, die dazu führt, dass die Kamera den Algorithmus verändert und ein anderes Gesicht immer in die Daten erkennen lässt und dann kann ich mich tarnen mit einer gewissen Schminke und als jemand anderes ausgeben. Weil der Algorithmus dadurch denkt, ich bin jemand anderes, weil ich einen anderen Gesichtshash bekomme oder so.

Das ist der Schwamm in dem ganzen Machine Learning Umfeld, dass du diese adversarial Models hast, dass du sozusagen auf der einen Seite ein Model haben kannst, was Dinge erkennt und jemand anderes weiß aber, wie er auf Basis eines Models Outputs generiert, die dieses Model dann wieder aus dem Takt bringen.

Ja, nur für seinen Social Score oder sowas kann man den dann hochhalten, obwohl man andere Sachen tun kann.

Die Ecke von Philipp fand ich jetzt nochmal wichtig und spannend, dass halt dieses Thema, ah, hier passiert ja nichts Schlimmes. Das Interessante ist eben, durch dieses Architekturproblem trifft es halt alle und jeden. Also jedes Stückchen Code, was du schreibst und mit dem großen Problem Dual Use, du weißt halt nie, wofür wird Code halt mal eingesetzt werden.

Den schreibt man jetzt und der ist da und ganz ehrlich, Leute, die Code finden, werden ihn benutzen. Er wird irgendwo benutzt werden und er wird für Dinge benutzt werden, die man sich nicht vorgestellt hat. Wobei ich da auch immer eine Lanze dafür breche, zu sagen, naja, der, der den Code in den Kontext einführt, hat die Verantwortung, sicherzustellen, dass er da was Sinnvolles tut.

Dann mach mal ein Projekt mit NPM-Paketen oder sowas.

Genau, ja, aber das ist deren Verantwortung.

Es ist nicht die Verantwortung von jemandem,

es gibt im Open-Source-Umfeld, kann man ja auch viel da nochmal drüber reden,

über die Motivation von Leuten, die halt so Open-Source-Packages maintainen,

die dann ein riesen Schwergewicht kriegen.

Ich finde, die Leute haben keine moralische Verpflichtung,

anderen gegenüber aus ihrem Freizeitprojekt, wo sie sagen,

da steckt einfach nur meine Lust und meine persönliche Motivation drin,

anderen Garantien auszusprechen, dass

sie damit jetzt einen Space Shuttle betreiben

können.

Das darf man so nicht umdrehen

und nichtsdestotrotz

ist es natürlich

ein

Das ist alles ein etwas zusammengeschimmertes

kleines Raumschiff, was immer droht auseinander

zu fallen, was auf der einen Seite mit Kohle und auf der

anderen Seite mit einem Handpedal betrieben wird

und keiner so genau weiß, wo denn jetzt

das nächste Leck entsteht.

Ja, ich hätte auch

große Bedenken, irgendwie so medizinische

Software für medizinische Geräte zu schreiben oder

irgendwelche Software, die Flugzeuge

steuert oder so, da hätte ich irgendwie

groß, würde ich wahrscheinlich eher lieber nicht.

Wahrscheinlich schon bei Bank-Transaktionsgeschichten

schon bedenken, aber...

Allein das zeichnet dich aber eigentlich schon aus

als jemand, der qualifiziert sein könnte,

das zu tun.

Zu viele

Leute gehen nämlich ohne

diese Vorsicht heran.

Also, man hat mal

früher gesagt, die Deutschen bauen die besten Nationenkraftwerke,

weil die so scheiß viel Angst davor haben.

und halt entsprechend in die

Sicherheit investieren.

Deswegen ist Siemens mit der

Atomkraftwerke so ein Exportschlager.

Andere haben halt weniger Angst

davor und machen dann halt

auch weniger Sicherheit.

Das ist so ein bisschen ein

wer sich halt auf dem Fahrrad sicher fühlt

und keinen Helm aufsetzt,

wer sich unsicher fühlt und einen Helm aufsetzt, ist am

Ende bei einer echten Kollision halt

feiner raus.

Ja, aber ich meine, das ist einfach

Ich glaube, also das, was mich da so unsicher fühlen lässt, ist halt einfach, es ist schwer überhaupt sicherzustellen, dass da nichts passieren kann. Es ist einfach, es kann so viel schief gehen.

Es geht auch nicht. Das ist dann der schöne Übergang zu dem Thema Security als Prozess halt. Man kann halt immer, ich glaube etwas, was lange in der Informatik gelehrt wurde, ist halt das Problem sozusagen Security als abstrakte mathematische Eigenschaft eines Systems.

Das wird an vielen Stellen auch noch verfolgt und da kommen interessante Sachen raus, gerade wenn wir gucken in Richtung strenger Typsysteme und all so ein Zeug. Also ADA zum Beispiel, dieses ganze Umfeld. Und da finde ich es auch spannend, dass die tatsächlich dort Engineering haben.

Und ich hatte ADA nur mal im Studium und muss sagen, also es ist halt, was die Garantien angeht, wirklich straff. Es ist auch ziemlich schnell. Ich habe aber nie irgendwas Sinnvolles damit programmieren können.

Kannst du vielleicht nochmal ganz kurz erklären, was ADA ist?

ADA ist eine Sprache, die ist extrem formal definiert und die wird hauptsächlich im militärischen Bereich eingesetzt. Also bei uns an der Uni ist die gelehrt worden und dann gab es halt gerne mal von der Eurocopter und von anderen Leuten Besuche, wo es dann darum ging, irgendwie Steuersysteme für Kampfhubschrauber und so ein Kram zu programmieren.

Und die ist halt, die zeichnet sich dadurch aus, dass sie ein sehr umfassendes Typsystem hat. Das heißt, da wo man in anderen Sprachen halt sagt, ich hatte hier gerne einen Integer, kannst du dem Ding halt sagen, ja, ich will hier einen Integer haben, der darf aber nur von 7 bis 9, 11, 13 und 12 sein.

Und der Compiler kann dir vorher über alle Operationen deines Programms schon sagen, ob die Verkettung der Operationen in Summe noch zu zulässigen Ergebnissen führt.

Oder ob du irgendwo deine Wertebereiche sprengen würdest. Und gleichzeitig, und das ist halt wirklich cool, die können halt Echtzeit und sie sind auch auf anderen Systemen sehr, sehr schnell in der Laufzeit nachher. Und das ist halt, das ist was wert.

Gleichzeitig ist es aber so, immer wenn es um I.O. geht, nämlich da, wo halt dieses Thema, da kommen Daten von draußen rein oder müssen wieder raus, da gucken sie so ein bisschen in die Luft und sagen, naja, das macht jemand anders.

Das ist dann halt immer, also da herzugehen und zu sagen, ich hätte jetzt hier gerne mal noch schnell eine HTTP-Library und ich würde hier nochmal eine SSL und nochmal da drüben ein Repository von GitHub, sowas ist bei aller halt eher nicht so an der Tagesordnung und du brauchst halt auch eine entsprechende Engineering-Menge und Genauigkeit, all die Kombinationen, mit denen du sozusagen konfrontiert wirst, dir so genau anzugucken, das lohnt sich halt auch eigentlich nur, wenn da wirklich Menschenleben dranhängen.

Wenn du sagst, es ist okay, wenn dieses kleine Programm jetzt zwei Millionen Euro kostet, wo jemand anders sagt, komm, da hack ich dir jetzt das Shell-Skript runter und dann ist es gut. Da muss man immer aufpassen, dass es halt kontextbezogen ist. Also die kommen halt aus dieser Ecke von einer mathematisch perfekten, idealisierten Variante von so, wir schreiben jetzt das Programm und das ist dann sicher. Und wenn du in ausreichend komplexe Systeme kommst, musst du aber eigentlich eher einen prozessorientierten Ansatz machen.

Genau, da würde ich nämlich jetzt auch gerade noch kurz einhaken und sagen, naja, das Blöde ist, dass einem halt auch diese Geschichten nicht unbedingt schützen vor wirklich fatalen Fehlern, wie zum Beispiel, ich weiß nicht, ob das der Jungfernflug von irgendeiner neuen Ariane-Version war, Ariane 5, Ariadne oder Ariane, Ariane, glaube ich, 5.

Ich glaube, auch die Steuerungssoftware dafür ist auch in ALA geschrieben oder so.

Und die ist sogar bewiesen, dass die tatsächlich das tut, was in der Spezifikation steht.

Nur das Problem ist halt, sie haben irgendwie die falsche Spezifikation verwendet.

Das war Wind.

Nee, die Spezifikation war halt für die alten Motoren irgendwie.

Und dann waren die Sensordaten für den Computer halt irgendwie so, nee, das kann nicht sein.

Aber es ist ja bewiesen, das ist richtig, daher muss ich defekt sein.

dann hat sich der erste Steuerungskomputer ausgeschaltet

und dann hat sich der zweite auch noch ausgeschaltet,

der den übernommen hat und dann war halt Schluss.

Und dann ist die Rakete halt abgestürzt.

Und ja, das ist ja auch sowas.

Ich meine, klar, man kann halt beweisen manchmal,

dass Programme das tun, was sie tun sollen,

aber dann muss man ja immer noch sicher sein können,

dass die Spezifikation richtig ist.

Aber irgendwie, man kommt da in so einen infiniten Regress

und selbst das hilft einem nicht.

Das war jetzt ein Fall, wo ein Hardware-Update dazu geführt hat,

dass das Ding nicht mehr lief.

Also keine Updates fahren, never touch a running system.

Aber auch in Python hat man ja nicht völlig verloren.

Also auch wenn Python solche strengen Garantien

nicht so direkt hat, man kann natürlich Assertions

einbauen und damit kann man so ein bisschen

in die Richtung gehen, was Ada auch kann.

Wenn ich sage, ich baue hier ein Assertion ein und sage,

okay, ich erwarte, dass die Eingabe nur so lang

ist oder ich erwarte, wie du eben als Beispiel gebracht

hast, Christian, dass halt nur irgendwelche bestimmten

Zahlen davor kommen, das kann ich auch in Python

machen. Das geht, das macht den Code

ein bisschen länger, da muss man sich ein paar Gedanken

machen, aber das ist ja sicherlich auch

ein Merkmal

von qualitativen Code, dass man sich halt immer Gedanken

macht, okay, was sind meine Eingangsbedingungen,

was sind meine Bedingungen,

die ich vielleicht rausgebe, dass ich auch schaue, okay, die Daten,

die ich nochmal rausgebe, die kann ich

in ein anderes Modul in meinem Programm, die kann ich auch nochmal

validieren, dass da alles in Ordnung ist, dass das zum Beispiel

irgendeinem Schema entspricht oder sowas.

Also das ist ja auch in Python nicht unmöglich

und es gibt natürlich auch in Python noch sehr viele

andere Sachen im Rahmen eines sicheren

Prozesses, die ich durchführen kann. Also das beginnt

ja bei ganz normalem Code Review.

Da guckt halt jemand anders drauf und sagt halt vielleicht, okay, der Code sieht komisch aus. Und dann kann ich halt sowohl Tests durchführen gegen den Source-Code, also dass ich mir den gesamten Source-Code nehme und ein automatisiertes Programm drüber laufen lasse, das mir halt sagt, okay, die Stelle sieht komisch aus. Hier machst du wahrscheinlich eine SQL-Injection oder ein C, ein Buffer-Overflow, das sieht irgendwie gefährlich aus.

Und dann kann ich natürlich auch sogenannte Blackbox-Tests fahren, wo ich sage, okay, ich starte meine Anwendung einfach mal und dann nehme ich mal so ein Hackertool und das probiert einfach mal aus, kann ich hier komische Sachen eingeben und crashen in das Programm oder macht das Programm irgendwas komisches. Also auch in Python ist das nicht verloren. Da kann man auch sehr sichere Anwendungen schreiben, was meistens das gleiche ist wie eine gute Anwendung zu schreiben, weil die stört es halt nicht ab und die kann auch mit allen Benutzerangaben umgehen, noch nicht mal nur von Angreifern, sondern auch von Benutzern.

Also ich hatte das beruflich auch so, wir dachten erst, wir hätten einen Angreifer, weil unsere Anwendung abgestürzt ist, aber hat sich herausgestellt, wir hatten ein ähnliches Problem wie beim Buffer-Overflow, wir hatten ein Datenbankfeld mit einer bestimmten Länge und die Länge war aber in Bytes und dann kamen halt User an und haben ihre kleine Tony-Figur mit ganz vielen Smileys genannt und dann passte das nachher nicht und führte zu einem Crash.

und auch sowas kann man natürlich auch vorher darauf achten

und entsprechend auch testen.

Das ist ja noch ein anderer Bestandteil eines sicheren Prozesses,

der sagen kann, ich schreibe vorher Tests

und ich überlege mir entweder manuell oder sogar automatisiert,

wie sehen komische Eingaben aus.

Bei Nummern sind das meistens Null oder sehr kleine Zahlen

oder sehr große Zahlen.

Typischerweise auch Zahlen,

die vielleicht über die 32 Bytes hinausgehen,

was in Python jetzt nicht so ein Problem ist

oder über die 64 Bits hinausgehen.

Also wenn ich da eine sehr große Zahl,

wenn ich 2 hoch 64 plus 1 schreibe,

dann in Python gar kein Problem.

Aber in vielen anderen Programmiersprachen

führt das halt zu einem Absturz

oder zu komischem Verhalten.

Und damit kann ich auch in Python, glaube ich,

sehr gut Sicherheit sichern.

Also du würdest tatsächlich in solchen kritischen Fällen,

wo du dir überlegst,

ah, ich weiß nicht so genau, was dabei rauskommt,

Assertment-Statements in den Code schreiben einfach

und dann sagen Asserts should never happen oder sowas

und dann... Genau, und

fliegt dann. Genau, auch vielleicht

auf Testen. Also bei dem Beispiel, was ich eben gebracht

habe, wo die Nutzer Emojis eingeben

haben oder andere komische Unicode-Zeichen,

haben wir halt einen Test gemacht. Und dieser Test,

also wir haben sowohl einen Unit-Test,

der also ganz normal in der Anwendung

läuft, wo wir halt mal ausprobieren, was passiert,

wenn ich nur Emojis eingebe oder andere

komische Strings. Und wir haben aber auch einen

End-to-End-Test, der das

gesamte System testet. Also zum Beispiel

hatten wir auch mal einen Bug, der

durch

den Reverse-Proxy vor unserer Anwendung

verursacht wurde, dass der halt Sachen falsch

macht. Und sowas kann man dann halt

nicht so richtig testen. Natürlich könnte man auch in

Nginx sagen, ich schreibe eine Art Unit-Test

für unsere Nginx-Konfiguration, aber

da ist dann praktisch halt wirklich ein End-to-End-Test zu schreiben,

der halt

wirklich eine echte Anfrage gegen das echte System

schickt oder gegen Prot, also da kann man sogar gegen sein

Production-System testen, aber natürlich testet

man das im Normalfall zuerst gegen Development

und sendet mal komische Anfragen

und schaut, okay, geht das?

Kommen hier ordentlich Ergebnisse raus und

meldet das System vielleicht auch

hinten drum schon, dass irgendwas umgefallen ist

und das kann man halt

damit schon ganz gut testen.

Ich finde das halt auch spannend

aus der Perspektive von

User lassen sich halt

mehr Dinge einfallen, als man selber halt

vorher konstruieren kann.

Tests sind an der Stelle immer natürlich auch super,

weil man, wenn man im Hinterkopf behält,

dass Tests halt eben nicht

dafür da sind, Beweise

zu ersetzen. Also ja,

Sie sind sogar eine Annäherung eines Beweises, aber sie können halt nie alle Fälle abdecken.

Das geht halt schon in dem Moment schief, wenn du halt ein kontinuierliches Wertesystem hast an der Stelle.

Und was da halt interessanterweise zum Tragen kommt, aus einer ganz anderen Ecke von Security,

ich weiß gerade nicht mehr, welcher amerikanische Militär das war, das kommt so aus dem Counterterrorism-Zeug,

Das ist Only Variety Can Match Variety.

Also das Problem von Terrorismus ist halt, dass Terroristen extrem variierte Inputs, also Angriffe fahren.

Also da geht es ja nicht um eine reguläre Kriegsführung nach irgendwie Genfer Konvention,

sondern die machen Dinge, gerade weil sie verboten sind und weil keiner damit rechnet, an Stellen, wo keiner damit rechnet.

Und die Amerikaner haben halt irgendwann rausgefunden, wir können dem halt nicht mit herkömmlichen Maßnahmen,

indem wir alle möglichen Fälle durchdeklinieren, entgegentreten,

sondern du brauchst halt kognitive Diversität, um auf diese absurden Ideen zu kommen.

Du brauchst tatsächlich Leute, die unterschiedlich ticken.

Und ganz ehrlich, keiner von uns, wenn ich hier in die Runde gucke,

wir haben halt vier mittelalte weiße Männer.

Und die Diversität ist auf der Ebene halt auch kognitiv dadurch mit dem Bias belegt.

Keiner von uns kommt auf die Idee in seinen Tests halt, Katzen-Emojis in den Input zu tragen.

Das macht halt von uns keiner.

Und an der Stelle ist Security als Prozess

halt tatsächlich auch von einer hohen Diversität,

also braucht eine hohe Diversität,

immer mit dem kleinen Zusatz von kognitiver Diversität,

die aber auch tatsächlich überlappt

mit kultureller und persönlicher Erfahrung etc.,

um halt das erzeugt zu kriegen,

dass man halt auf genügend Ideen kommt,

die dann mal so eine Baseline herstellt von,

okay, das ist jetzt hier nicht mehr scheiße.

Naja, das ist immer, ich finde das aus einem prozesshaften Ansatz gesehen und das ist halt das, wo ich dann, wenn Jochen, der halt sagt, Hilfe, ich will keinen Space Shuttle Code schreiben, aber Leute, die halt besser differenzieren können zwischen, ja, wie gut oder schlecht ist es denn versus ist es jetzt perfekt sicher oder ist es nicht perfekt sicher, weil das kenne ich halt aus vielen auch so Corporate-Umgebungen, wenn man Diskussionen führt, für die ist halt Sicherheit ein An- oder Ausknopf.

Entweder es ist sicher oder es ist nicht sicher, weil die müssen unter irgendeinem Produkt ihre Checkliste machen von, ja, dieses Produkt ist sicher, deswegen dürfen wir es einsetzen.

Da steht halt immer auf Rot die Lampe, wenn man ehrlich ist.

Ja, also ich habe halt schon Sachen gehabt, wo wir mit Institutionen aus dem Finanzumfeld, für die wir dann Sachen betreiben außerhalb der Kernrechenzentren, weil wir dann immer mit irgendwelchen jetzt so, oh, die Finanzwelt entdeckt, dass die Leute Apps wollen.

Aber nein, ihr dürft, die App darf nicht mit unserem Kernbanking-System reden. Und dann sind wir da häufig so ein Layer dazwischen, wo wir sagen, okay, wir betreiben für euch diese ganzen APIs und machen da den Kram dazwischen, dann sind wir so diese Pufferzone. Und wenn ich dann aber einen Excel-File kriege mit 5000 Einträgen, wo die ganzen Security-Anforderungen laut dieses Finanzinstituts drin sind und ich dann in Zeile 2327 sage, ja, wenn ich jetzt die Cipher, die ihr da vorgebt, raus ins Internet lasse, dann ist es von heute auf morgen kaputt.

Weil ihr habt das letzte Mal vor drei Jahren eure Cypher-Liste aktualisiert und für eure Rechenzentren, wo kein Internet reinkommt, mag das jetzt alles okay sein, aber wenn ich damit jetzt halt raus ins Internet gehe, dann ist es halt kaputt.

Und jetzt musst du ihnen klar machen, naja, im Internet wird ständig alles angegriffen und du kannst jetzt nicht mit mir einen Vertrag schließen, wo du reinschreibst, welcher Cypher da drin stehen soll, sondern du machst mit mir bitte einen Vertrag, wo du sagst, nach bestem Wissen und Gewissen haltet ihr euch informiert und kompetent und ihr aktualisiert das, so wie es halt nötig ist.

und jada, jada, jada.

Aber das war dann halt auch plötzlich

ein Kampf, wo die davor standen und sagten,

ich muss jetzt hier das Siegel drauf machen, obwohl ich

eigentlich in der Liste geschrieben habe,

Verstöß gegen unsere Sicherheitspolicy.

Ja, stimmt.

Das ist ein großes Problem. Das ist auch so ein Problem

mit so Zertifizierungen, die man ja sonst vielleicht

macht, wenn man jetzt irgendwie ein Auto fährt oder

keine Ahnung, wo das eigentlich herkommt,

Kirmesgeräte hat, auf denen Leute

rumfahren. Dann kommt der TÜV und sagt halt,

okay, ist noch nicht durchgerostet, alles klar,

das Siegel, das geht halt

bei Software nicht so gut, weil die muss man

ja ändern und eigentlich braucht man dann eine neue Zertifizierung,

aber das, ja genau,

das wäre, ja könnte man jetzt denken, dass das

die Lösung wäre. Ich habe das schon gemacht,

ich habe schon einen Software-Test.

Ja, ich habe

2003 oder 2004

haben wir damals mit Soap eine

Common Criteria Zertifizierung gemacht

und das war so ein Challenge,

da gab es einen Sponsor, der uns das bezahlt hat

und parallel

dazu hatte damals Red Hat den

J-Boss, glaube ich,

durch eine Common Criteria gejagt

und wir hatten im Prinzip

das gleiche Schutzniveau anzubieten.

War irgendwie eine ERP 3 Plus

oder ERP 4 oder so ein Kram.

Du hast jetzt gerade irgendwie ein kryptische...

Ich kann es nicht, ich kann auch nur

die humoristische Variante irgendwie so,

die unterste ist irgendwie, das Programm existiert

irgendwie, die nächste ist dann

irgendwie, ja, das Programm existiert und es gibt

Dokumentation dazu, dann die nächste

ist irgendwie, jemand hat mal geguckt, ob die Dokumentation

zum Programm passt und dann irgendwie

Die nächste ist dann irgendwie, es existiert

ein formaler Beweis, dass das Programm korrekt ist.

Wo dann irgendwie so ein Zwischenschritt fehlt,

das ist glaube ich diese Stufe 6

oder weiß ich nicht genau.

Ja, ERP 6 ist die formale Verifikation, genau.

Und, nee, nee, wir hatten

da schon ein relativ hohes Schutzniveau und

die Common Criteria als Framework,

um über Security nachzudenken,

inhaltlich, ist toll.

Weil du kriegst halt einen Katalog

von, also du hast zum einen einen Prozess,

der dir sagt, okay, mach dir mal Gedanken

über, wer sind denn deine Assets?

Wer sind deine Angreifer? Was haben die für Motivationen? Was haben die für Ressourcen? So, und jetzt gucken wir mal, wie mappen wir das alles aufeinander von, wie sind deine Assets mit was geschützt gegenüber welchen Angriffsszenarien und die haben auch noch einen tollen Implementationskatalog, wo sie sagen, okay, also wenn du folgendes countern möchtest, könnte man zum Beispiel Logging machen.

Wenn du Logging machst, dann musst du dir über die Integrität vom Log Gedanken machen, dann musst du dir über Zeitstempel Gedanken machen, dann musst du, das ist sozusagen, das ist so ein bisschen, da kannst du wie bei so einem Spinnennetz irgendwie reingreifen, erstmal was interessiert mich und dann kommen alle Sachen hinterher, von die du noch berücksichtigen musst. Das ist viel, aber es ist eigentlich erstmal auf der Ebene fachlich gar nicht schlecht gewesen.

Das große Problem ist, die Common Criteria kommt aus der Produktsicherheit und die gehen halt davon aus, dass ein Produkt eben, siehe ein Karussell auf dem Jahrmarkt, das Ding wird einmal gebaut und existiert jetzt und jetzt ist das ab und jetzt läuft das 30 Jahre, wenn du aber sowas wie einen Open Source Application Server hast, wo du exakt ein Release einmal verifizieren darfst und dann kommt aber in 23 Stunden das nächste raus.

Und du fängst die ganze Zertifizierung

wieder von vorne an, das geht dann halt schief.

Ja, also man muss

ja die Zertifizierung erstmal, also

es kann manchmal sehr gut sein, dass man sich

über alle Sachen Gedanken macht, aber man kann

ja auch ganz viele Sachen vermissen, also ich glaube

der viel besser

oder für viele Anwendungen besser

ist es, wenn man sagt, ich mache einen Pentest

und lasse ich einen Auftrag geben, bei einem

Pentest geht halt jemand anders hin und sagt

ich checke deine Software, also

entweder checke ich die von außen oder

ich schaue mir den Source Code an, ich schaue mir das mal an, was du so in Python oder auch in anderen Programmiersprachen alles programmiert hast.

Und da sind dann erfahren Entwickler in der genau der Programmiersprache und die können dann halt schon,

vielleicht auch mit automatischen Tools, sehr schnell kritische Stellen finden.

Also damit habe ich auch gute Erfahrungen gemacht.

Das ist natürlich eine ganz andere Herangehensweise, dass man sagt, okay, ich versuche nicht alles irgendwie,

den ganzen Prozess, ich schreibe kein Papier, sondern ich lasse im Wesentlichen Leute anfangen, uns zu coden.

Und das muss man natürlich auch regelmäßig wiederholen.

Das bringt natürlich nichts, wenn man vor zehn Jahren das mal gemacht hat.

Aber das ist auch sicherlich eine Methode,

mit der man seine Anwendung gut absichern kann.

Ja, du musst da seinen Angreiferhut aufsetzen und da draufhauen,

solange du bist, auseinanderfällt er.

Da brauchen wir halt gute Angreifer auch, die so ein bisschen ein paar Tricks kennen.

Und ich glaube, wenn man jetzt nur so Tools drauf loslässt, dann weiß ich nicht.

Genau, also wenn man nur ein Tool selber drauf loslässt,

hilft es wahrscheinlich nicht.

Aber wenn man halt jemanden beauftragt, der da wirklich Experte ist,

ich glaube, das ist eine ganz gute Möglichkeit,

um auch so einen Blick zu bekommen, wie schlimm ist denn mit unserer Anwendung?

Haben wir nur eine ganz kleine Schwachstelle oder ist unsere Admin-Oberfläche ohne Benutzername und Passwort irgendwie verfügbar und man kann beliebigen Code hochladen?

Und ich glaube, das ist noch ein bisschen eine andere Herangehensweise, aber ich glaube, das ist oftmals effektiver, vor allem für so kleinere Projekte.

Wenn man natürlich eine Zertifizierung braucht, dann braucht man sie, aber ich weiß nicht, ob das immer auch wirklich zu Sicherheit führt, wenn ich nur ganz viel Papier schreibe.

Also ich würde an der Stelle halt eine Lanze verbrechen für das, was wir jetzt zu Corona-Zeiten kennengelernt haben als irgendwie Schweizer Käse-Modell.

Aber du kannst halt, also für alle, die das noch nicht gehört hatten, ist sozusagen die ganzen Maßnahmen, alle Anti-Corona-Maßnahmen sind für sich genommen natürlich durchlöchert, wie so ein Schweizer Käse.

Aber wenn ich halt fünf Scheiben Schweizer Käse hintereinander lege, ist die Filtrationsrate dann doch relativ gut.

Dass also wirklich über fünf Schichten an der gleichen Stelle überall die Löcher sind, das passiert halt normalerweise nicht.

Und deswegen würde ich halt immer, also aus meiner dann längerfristigen Erfahrung, würde ich halt sagen, es kommt immer auf den Kontext drauf an.

Man muss immer erstmal gucken, was sind hier eigentlich die Assets gerade und wenn ich gerade hier in meinem Heimkeller irgendwie die Temperaturdaten von meinen Hubs aufschreibe, denke ich mir so, ja, egal, dann darf es halt auch mal, wenn ich für mich entschieden habe, die dürfen auch ins Internet purzeln, dann ist schon okay.

Aber tatsächlich diese Layer zu haben, auf der einen Seite Produktsicherheit tatsächlich sich anzugucken mit den, was sind hier eigentlich die technischen Maßnahmen und sowas wie eine Common Criteria im Hinterkopf zu haben, ist für mich inzwischen eher das Know-how von, das setze ich ein, während ich ein System aufbaue, um sozusagen schon vorher zu wissen, okay, wo ist denn die Checkliste, wo ich dann weiß, jetzt habe ich wenigstens nichts unnütz vergessen.

Während dann halt das Thema ist halt auch jemand zum Beispiel vom Pentest, da würde ich auch sagen, einige Leute, mit denen ich mich dann austausche, sagen, nee, dann machst du halt lieber auch noch gleichzeitig sozusagen eine externe Code-Review, die sozusagen über das, was du brauchst, dann nochmal im Whitebox drüber guckst und dann kannst du nochmal von draußen draufhauen und diese ganzen Schichten ergeben dann halt.

Und gleichzeitig kannst du dann an vielen Stellen ja auch, wenn man standardisierte Protokolle wie halt HTTP immer so dazwischen hat, dann gibt es da ja auch noch die Möglichkeit, immer nochmal so Schichten einzuziehen wie eine Web-Application-Firewall, die einem so bestimmte Sachen schon mal wegfängt.

Also ich habe zum Beispiel ein paar Kunden, denen gucke ich über die Schulter und da weiß ich dann so, okay, bei dir knalle ich da jetzt eine Waffe davor, weil ansonsten traue ich mich nicht, das ins Netz rauszulassen.

Du sagst mir, es muss raus ins Netz.

Das ist das gleiche Prinzip wie ein Virenscanner.

Also da habe ich irgendwie ein Muster, das ich suche.

Genau, ja, ja, ja.

Okay, wenn ich das Muster finde, dann mache ich irgendwas,

dann unterbinde ich die Anfrage oder schmeiße das Muster raus

oder mache irgendwas.

Genau, genau.

Das ist schon ein bisschen gefährlich,

weil eine Möglichkeit ist halt schon wie bei einem Virenscanner,

dass der, also die Wald- und Wiesenattacken findet der sicherlich.

So was im Internet das Grundrauschen ist,

das findest du auf jeden Fall.

Aber wenn dann wirklich jemand deine Firma angreifen will,

dann merkst du dich da vielleicht auch in falscher

Sicherheit, weil man halt dann doch immer

also du hast recht mit dem Schweizer

Käse-Modell, das macht es vielleicht ein bisschen besser

aber gleichzeitig kann ja so ein Waff auch

wieder ein Angriffsmodell sein, weil der muss ja auch wieder alles

interpretieren und ein Problem kann halt sein

dass mein Server davor und mein Server danach

sowieso schon unterschiedliche Details

anders interpretieren, also bei HTTP

zum Beispiel Junk Encoding oder

irgendwelche komischen HTTPS-Optionen

anders interpretieren und dass dann die Waff

sogar noch ein neues Problem aufmacht

dass sie plötzlich Sachen anders interpretiert

und dann vielleicht sogar eine Schwachstelle

an sich hat. Also auch die Waffe ist ja nur Code.

Ne, genau. Deswegen ist es auch für uns zum Beispiel

keine Maßnahme, die wir halt so Blanko überall drüber

gießen, sondern das ist halt, wir haben halt

dann Kunden, wo feststellen, also

die Waffe ist für uns mehr oder weniger dann

der erste Move. Also manchmal,

wie du sagst, will irgendwer einfach in seiner

Ausschreibung sehen, da muss eine Waffe davor.

Pack ich da eine Waffe davor.

Und wenn, das

muss er ja anbieten können erstmal in dem Moment, wenn er

das fragt. Und wenn der dann irgendwie nach zwei Monaten

fragt mit, warum ist das hier alles so doof, dann sage ich,

du wolltest eine Waffe haben, dann sagt der mir, jetzt machst du wieder aus,

dann mache ich es halt wieder aus.

Wo wir es häufiger als Werkzeug

tatsächlich sehen, ist,

dass tatsächlich diese Wald- und Wiesenscans

und Angriffe gerne

mal massiv für Last sorgen.

Und das ist halt,

wir sehen immer wieder Anwendungen,

wo Leute mit SQL-Injection

versuchen,

quer über so eine Anwendung drüber gießen

und die Anwendung dadurch in

Performance-Probleme gerät.

das ist halt tatsächlich, was das Filtern wird, dann damit

zum Beispiel vorne weg. Also jetzt hier haben wir die ganze

SQL-Kram, das hat da nichts drin zu suchen,

zack, weg, raus.

Ah, okay.

Ja, aber genau, also ich habe

auch schon mal von jemandem gehört, der so

Pentests macht, dass er

meinte, so ja, da war eine Bank, die hatte irgendwie

ein System vor den

Datenbanken und das sollte eigentlich aus

dem SQL irgendwie alles rausfiltern, was

und das hat dazu geführt, dass SQL-Injection wieder möglich

wurde, weil es halt

Dinge zu viel

rausgenommen hat.

Du hast

ja aus

Komplexitätsperspektive hast du immer das Problem

der Kombinatorik.

Das heißt, wenn du n Dinge hast,

die miteinander reden, dann hast du halt

n Quadratverbindungen mindestens.

Und wenn du jetzt sagst,

okay, das ist mir zu unsicher, ich packe noch eins

davor,

dann hast du noch mehr.

Das Problem ist, glaube ich,

an der Stelle auch, wer halt

irgendwie diese Architektur entscheidet

und so und wem man da vertrauen kann. Gerade wenn

Leute jetzt keine Ahnung haben von

Sicherheit oder von Computern allgemein, aber

irgendwie Software als Manager irgendwie bestellen

wollen. Die haben ja eine unheimliche Asymmetrie

gegenüber den auch Entwicklern und so

und die müssen halt vertrauen

auf das, was denen da erzählt wird und die

stellen sich dann meistens so ein Sammelsurium an

Angebot und Nachfrage

oder Best Practice oder irgendwas, was die

halt an Informationen saugen können zusammen.

Und das ist ja auch schon so eine Art

Baukasten und das ist ja nie ganzheitlich

irgendwie gedacht, was wird ja auch immer dann teuer und so,

muss ja auch dann wieder sparen und

wenn man das dann rauslässt, dann ist ja klar,

Fehler sind ja völlig vorprogrammiert

und sich da richtig vorzuschützen

ist fast eine unmögliche Aufgabe

und die Frage wäre vielleicht, wie man solchen

Menschen auch eine Möglichkeit geben kann,

Systeme in sicherer zu denken,

also ihr habt jetzt gesagt, so Prozesse von Anfang an

so ein bisschen, das würde ja wirklich bedeuten,

dass man sich, bevor man damit anfängt,

mit einem Systemarchitekten oder sowas

intensiv auseinandersetzen muss,

welche Tech-Stacks man benutzt oder so was

oder wie der Prozess halt aussehen muss

und wo man Sicherheits, ja, was ist das, Netze einzieht oder ...

Ja, die Frage ist halt, welche Angriffsmöglichkeiten

man irgendwie zur Verfügung stellen möchte.

Da gibt es ja unzählige.

Es ist ja nicht immer nur so diese Website,

die nach außen dann da das Aushängeschild ist,

wo man dann draufhauen kann.

Ja, die Versuchung ist ja nicht groß,

sich halt sozusagen als Feature, als Draufklopf anzukaufen,

also ein riesiges System, was aktuell existiert,

was in Wirklichkeit wahnsinnig unsicher ist

und dass man sagt, okay, ich mache jetzt einfach,

ich kaufe jetzt eine Waffe oder

irgendwas anderes, mache einmal

einen Pentest oder mache eine Sache

und hoffe dann, dass das damit okay ist,

dass ich halt so Sicherheit dazukaufen kann.

Ich glaube, es ist viel,

es entsteht viel bessere Software, nicht nur sichere,

sondern auch bugfreie Software,

wenn man die gesamte Software

direkt so anlegt, dass man sagt, okay, bei der Produktion

der Software, ich mache mir vielleicht vorher Gedanken,

ich würde nicht mal sagen, viel über die

eigentlichen Zertifizierung oder

die Prozesse, sondern vielleicht mehr

wie lasse ich die entwickeln?

Wie sorge ich dafür, dass das, wie ich eben

erwähnt hatte, Code Review, also

wie sorge ich dafür, dass das halt schon

bei der Entwicklung

direkt die Software sicher ist? Weil nachher das

draufzubauen ist immer schwieriger. Also nachher

mit dem Scanner zu suchen ist, glaube ich, schwieriger als

zu sagen, okay, ich habe Entwickler,

die sich direkt darüber Gedanken machen.

Das ist ja zum Beispiel total kaputt. Also ich

hatte jetzt irgendwie mal so die Situation, dass

so ein Konzern da war, die wollten

dann Software bereitstellen und dann haben sie

gesagt, nee, aber neue Software ist irgendwie komisch,

wir wollen die alle auditieren vorher, so persönlich,

also als Security-Team und haben dann so

ein Service dann rausgebracht, dann

jetzt im November und da war dann Django

1.10.4, weil das dann die sichere Version

war, das ist also LTS war 1.11, für alle, die es noch

wissen, das ist halt schon ein altes System und da

gibt es halt dann irgendwie schon jede Menge irgendwie Exploits,

wenn man irgendwie genug nachsucht, die irgendwo drinstehen

und das wird dann von den Leuten irgendwie

geauditet und man fragt sich halt so, okay, was machen

die denn da eigentlich, so, warum tun

die das? Und das ist halt vielleicht so ein, ja,

das kriegt man, glaube ich, gar nicht so gut in die Hüfte.

Das ist halt wieder der Griff in Richtung Product Security statt

Process Security.

Also

ein prozesshafter Ansatz und wir haben jetzt ja auch

seit eineinhalb Jahren, nee, seit, doch,

seit ein bisschen mehr als eineinhalb Jahren machen wir bei uns

ISO 27000 und

der Trick ist

halt bei vielen, die prozesshaften

Security-Sachen werden häufig missverstanden,

weil die Standards, die es

dazu gibt, wie eine Keule

aussehen, obwohl sie eigentlich gar nicht so schlimm sind.

Man muss da bloß, wenn man die Standards

interpretiert, immer unterscheiden zwischen

was fordert der Standard formal

und was ist im nächsten Satz schon nur noch die

Implementationsguideline,

wo man dann eigentlich

selber Hoheit hat. Also ich habe halt

auch jemanden,

der meinte, der ISO 27000,

seitdem müssen wir sämtliche

Stromkabel einmal im Jahr

irgendwie auf die Erdung

prüfen. Also

nee, musst du nicht, ich habe auch nur

27.000, aber dann müsst ihr das doch auch mal so, nee, müssen wir

nicht. Ja, aber, aber,

ja, nee, müssen wir nicht.

Und dann dreht man so eine Schleife mit,

die ISO sagt, du musst dich halt um die für dich

relevanten Normen und Vorschriften

kümmern, das sagt die ISO 27.000,

also macht man das

und die sagt aber auch, du musst sie

bewerten und musst

dann Schlussfolgerungen für dich daraus ziehen.

Und es ist völlig

legitim im Rahmen der ISO zu sagen, ja,

wir haben zur Kenntnis genommen, dass

ortsveränderliche elektrische Verbraucher

irgendwie alle zwei Jahre auf X geprüft werden

müssen.

Machen wir nicht.

Aber jetzt kannst du doch mal erklären, was für eine Lücke das

offen lassen könnte, warum man das

testen wollen möchte.

So, naja, ISO als Prozess,

die ISO als Informationssicherheitsprozess

ist extrem umfassend

und zwingt dich dazu,

den kompletten Wertschöpfungsprozess

von einem IT-System

zu betrachten. Da gehört halt dann unter anderem auch

dazu, dass

dass du eben rechtliche Rahmenbedingungen bewertest etc.,

weil du musst am Ende immer für alle deine Assets,

und Philipp hat das halt schon, die vier Grundsicherheitsaspekte,

also bei uns sind sie aufgeschlossen, manchmal wären es drei, manchmal wären es vier,

halt nach Vertraulichkeit, Confidentiality, nach Integrität, Integrity,

nach Authentizität und nach Availability zu schütten.

Und was hat das jetzt damit zu tun, dass da so ein Stromkabel ist, in das sich …

Strom ist zum Beispiel für die Availability relativ wichtig.

Okay, also Availability, okay.

Und du misst halt dann da quasi nur die Stromleitung,

um zu testen, ob das Ding irgendwann mal ausfällt.

Es ist halt eine deutsche Norm,

die kommt aus dem, ich weiß nicht, welches ist,

die schreibt halt vor,

dass halt alle ortsveränderlichen Verbraucher

auf Fehlerstrom zu prüfen sind, alle zwei Jahre halt so.

Und wenn die ISO halt sagt,

du musst halt alle für dich gültigen Rechtsnormen berücksichtigen

und überwachen etc., dann schlägt sowas halt auch zu.

Was die Leute aber eben häufig missverstehen, ist, dass in der ISO drinsteht, du sollst es bewerten.

Und du sollst für dich daraus ableiten, ob das jetzt was Relevantes ist oder nicht.

Du kannst als Geschäftsführer oder als CISO an der Stelle immer sagen, okay, ich habe da fünf Risiken gesehen, ich akzeptiere die.

Jetzt hast du aber meine Story kaputt gemacht.

Ich wollte eigentlich die Story hören, wie man durch das Stromkabel in den Rechner des CISOs einringt.

Das Stromkabel, also das kann zum Beispiel passieren, wenn du deinen Prozessor aufstellst und sagst, naja, Stromkabel sind für uns keine sicherheitsrelevanten Dinge, deswegen kaufen wir die aus der Grabbelkiste beim Euroshop nebenan.

Das heißt, dann verkaufen die dir plötzlich en masse Dinge, wo sie wissen, in einem halben Jahr geht da drinnen irgendwas kaputt und dann geht bei dir im Rechenzentrum mit einem Mal das Licht aus und dann ist deine Verfügbarkeit hin.

Und weil dein Redundanzkonzept natürlich davon ausging, dass dir niemand so ein Ding untergejubelt hat mit der Absicht, dass da ein kleiner Sollbruchkondensator oder irgendwas drin ist, der dann halt nach so und so viel schönen Laufzeit einfach eine Schmelzsicherung durchgehen lässt.

Also das ist glaube ich auch erstmal nur relevant für so Atomkraftwerke oder sowas, die halt dann vernünftige Kühlung brauchen.

Nein, das kommt auf deine Angreifer und die Motivation der Angreifer drauf an.

Also die Story da drumherum wäre zum Beispiel, jemand zu sagen, wir betreiben Dienste sehr, sehr lange, teilweise 10, 15 Jahre und länger.

Das heißt, wenn ich, und auch teilweise mit politischem Impact, also wir haben ein paar Systeme, die sind unter anderem zu uns gewandert, extra aus Amerika raus, von Non-Profits, die unter anderem im Nahen Osten halt aktiv sind.

Und die haben ein massives Sicherheitsbedürfnis um das Leben derer, deren Daten in dem Ding drin stehen, weil da halt Decknamen und so ein Zeug auftauchen.

Und die, wenn du dann halt sagst, naja, wenn da jemand ein richtiges Longgame spielt und sagt, ich hab hier drei Jahre Zeit, das ist nicht das Problem.

Ich will aber, dass diese NGO mal so richtig gegen die Wand fährt, dann farbe ich jetzt die Lücke und sage, aha, ich hab rausgefunden, deren Hoster kauft immer irgendwie aus der Grabbelkiste die Stromkabel.

das dauert jetzt, naja, der tauscht nur so und so oft

die Stromkabel aus, aber wenn

ich es schaffe, irgendwie ein Drittel

seiner Stromkabel durch meine mit dieser Schmelzsicherung

zu ersetzen, dann bin ich in drei Jahren

soweit, dass dann irgendwie bei dem das RZ

implodiert.

Das ist sozusagen

die, und da muss man immer

aufpassen,

da kommt dieser, welcher XKCD ist

das mit der hohen Verschlüsselung und dem

der 5-Dollar-Entschlüsselungsmaschine?

XKCD, bitte

nochmal einmal.

XKCD, Comic.

Wo die Idee ist,

dass du eine ganz, ganz teure Verschlüsselung

kaufen kannst, mit super zertifiziert

und dann kommt aber jemand

zu deinem Admin mit einem

5 Dollar Baseballschläger

und bedroht ihn dann und sagt, okay, gib mir das Passwort.

Wenn das für dich gibt, dann

hau ich dich mit dem Schläger und dann bringt

dir die beste Zertifizierung und die beste Sicherheit

nichts. Ja, tatsächlich, ja.

Und man sagt halt auch an der Stelle, weil häufig,

gerade dieses Thema Advanced

Persistent Threat, also

die typischerweise staatlich

finanzierte Organisationen

oder Teams, die irgendwo reingehen sollen,

man sagt halt auch so schön,

gegen den Mossad

schützt du dich

nicht, weil

der Mossad interessiert nicht,

was du für Security irgendwo in deinem RZ hast.

Der kommt zu dir nach Hause und nimmt

dich mit und dann reden

wir nochmal.

Und deswegen ist, wenn man das mal schluckt und sagt, okay, ich bin hier nicht der, der sich gegen den Mossad schützen muss, weil ich habe eh keine Chance, dann brauche ich aber auch nicht so tun, als wenn ich sozusagen alles auf dem Niveau machen müsste.

Oder du brauchst einen eigenen Geheimdienst.

Bitte?

Oder du brauchst einen eigenen Geheimdienst.

Ja, genau.

Aber das Fiese am Internet ist ja,

dass du immer mit den besten Angreifern kommunizierst.

Das heißt, vielleicht nicht mit dem Mossad,

aber vielleicht hast du irgendwelche russische Hacker,

die durchaus was draufhaben.

Und die installieren dann halt,

wie hier in der Uniklinik Düsseldorf,

deine Ransomware.

Und die sind auch fast auf dem Level

von so einem Advanced Persistent Threat.

Die haben vielleicht jetzt nicht so...

Also, die machen schon ein bisschen Streufeuer,

aber die haben durchaus das technische Know-how

und auch die Zeit.

Und die machen sich auch die Mühe, das an deine Architektur anzupassen.

Also vielleicht noch mal kurz, Uniklinik Düsseldorf, da gab es einen Vorfall, da sind die Server rausgefallen.

Und da das Netzwerk intern nicht geordnet war, konnte man durch den einen befallenen Rechner irgendwie mehrere OP-Säle ausknipsen, wenn ich das richtig verstanden habe.

Ja, ich weiß nicht genau, was da passiert ist, aber war ein bisschen nicht verfolgt, muss ich zugeben.

War aber auch, glaube ich, nicht der erste Fall in Deutschland und ich glaube, das hat es auch ein paar Mal so richtig erwischt.

Nee, natürlich. Also das ist halt ja jetzt erstmal, die Mossad-Beispiele kommen immer zu dem Thema, wenn man anfängt, die Physical Security halt extrem stark zu übertreiben. Und das ist aber dummerweise auch das, wo Leute gerne übertreiben, weil das können sie sich bildlich vorstellen.

Dann kommt halt immer noch ein, ja warum ist hier vor dem RZ keine Panzersperre und alle nur, ja, denkt dran, Panzersperre hilft dir nichts, weil in Deutschland hat die Feuerwehr, guck mal da draußen, siehst du diesen kleinen unauffälligen grauen Kasten? Da ist der Generalschlüssel für das ganze Haus drin.

Ja, wie? Na, das ist der Feuerwehrschlüsselkasten, da gibt es einen Feuerwehrschlüssel, den hat die Feuerwehr, die kann das Ding aufschließen, die kommt hier rein.

Also spar dir mal bitte deine Panzersperre.

Also deswegen, das ist immer so dieses für mich bloß abzugrenzen von, wenn du das Niveau hast, musst du dir nochmal um ganz andere Sachen Gedanken machen.

Und wenn man das aber mal so übertrieben hat, dann wird den Leuten schnell klar, dass Security halt eine Abwägung ist und eine kontextspezifische Abwägung.

Und immer nur auf 100% zu schalten, geht halt nicht.

Und damit macht man auch mehr kaputt.

Ich würde halt nochmal anknüpfen an den Punkt von

dieser Prozessempfehlung. Ich würde halt

immer versuchen, an allen Enden

weniger ist mehr zu machen.

Weniger Code, den du schreibst,

ist typischerweise weniger Architektur, über die

du nachdenken musst, ist weniger. Und damit

auch ein Team, was gerade erst anfängt, würde ich eben

nicht sagen, ihr fangt jetzt mal an, euch über Security

Gedanken zu machen. Auch bei uns

in der ISO ist es halt, in unserer

Umsetzung der ISO 27000 ist es halt auch

so, dass wir sagen, du willst irgendwie

neues Feature für die Plattform etc. entwickeln? Ja, mach halt.

Ja, mach halt.

Ja, und du kannst gern auch irgendwie deine

drei, vier Testmaschinen auf der Plattform halt

schon mal auf diese Branch umstellen.

Habe ich kein Problem mit. Aber,

bevor das dann halt in großen Einsatz kommt,

muss das halt mal durch eine

Vier-Augen-Review durch. Und dann musst du mal

irgendjemand anders erklärt haben, was du dir gedacht hast.

Und dann gibt es dort eine Checkliste

und die fragt, jetzt erklär mir mal, was du dir

für Security für Gedanken gemacht hast.

Und das ist im Prinzip, das ist bei uns

der komplette formale Prozess

für die Entwicklungssicherheit.

Also übertrieben jetzt ein bisschen,

aber im Prinzip ist sozusagen bei uns nur ein

ja komm, entwickle halt, da drüben

sind die zehn Guidelines, was man in welchen Situationen

so alles mal berücksichtigen könnte.

Und aber das Einzige, wozu wir dich zwingen, ist,

du musst in dem Pull-Request, wo dein

Feature in die General Availability geht,

musst du mir oder deinem

PR-Reviewer glaubhaft vermitteln,

dass du dir jetzt wirklich adäquat zu dem

Ding Gedanken gemacht hast.

Schreibt man das dann als Text in den

Pull-Request? Als Text in den Pull-Request rein.

Da gibt es zwei Fragen. Das eine ist, was sind hier die Sicherheitsanforderungen? Und B, wie habt ihr die erfüllt? Wo ist hier der Nachweis, dass die erfüllt wurden? Wie seid ihr zu der Frage gekommen von, was sind hier die relevanten Sicherheitsanforderungen? Und wie weist ihr nach, dass ihr das jetzt halt ordentlich umgesetzt habt?

Das hört sich so ein bisschen an, als sollte man die Angst weglassen und tatsächlich nur, also die Worst-Case-Szenarien, also was ist das Schlimmste, was passieren kann? Also bei dir wären zum Beispiel jetzt Daten weg gewesen, das wäre nicht so gut gewesen, weil die so sehr privat sein müssen. Und an anderer Stelle ist es vielleicht so, ja okay, wenn man die Backups noch hat, dann ist es halt nicht so schlimm. Und das ist halt dann vielleicht der Worst-Case und da muss man sich halt Gedanken darüber machen, dass der nicht eintreten kann und der Rest ist dann egal.

Auch bei uns ist es so, unser Auditor zum Beispiel sagt halt auch immer, ein Unternehmen, was hochsicher ist und aber am Markt kein Produkt platzieren kann, hilft halt nicht. Es geht halt nicht. Und dieses Angstthema ist da schon relevant, weil halt Angst ist, häufig wird Security, gerade wenn es eine eigene Abteilung ist, immer wahrgenommen als, das sind halt die, die halt nachher unterschrieben haben sollen mit, hier ist alles sicher und deswegen sagen sie per Default einfach nein.

Und für uns ist der Review-Prozess aber zum Beispiel auch umgedreht. Der Review-Prozess in einem PR bei uns ist halt immer nur ein, ja, man darf nicht alleine Zeug nach draußen prügeln, Sternchen, Fußnote, doch, es gibt Situationen, in denen man das darf, aber dann muss man noch mehr Dinge beachten, weil es gibt halt bei uns auch so Gefahr- und Verzugssituationen, dann muss ich handlungsfähig sein.

aber der Pull-Request ist halt,

wenn der gemerged wird, ist das halt nicht die Aussage

von dem Reviewer, dass er

seinen Erstgeborenen irgendwie

mit Blut unterschrieben dem Teufel

überantwortet, dass er

sagt, hier ist alles sicher,

sondern der Vier-Augen-Prozess ist

dafür da, dass ein zweiter Mensch

dem ersten nochmal in die Augen guckt

und sagt, also wenn

du jetzt nicht noch sagst, ich soll nach

irgendwas schauen, dann merge ich den Kram

jetzt. Also das ist aber dein Code,

den ich jetzt gleich merge.

Und das ist ganz spannend, weil das ist ein kognitiver Prozess, der halt einer Person, einem anderen Menschen, und da gehört Empathie eben mit dazu, gegenüberstellt und sagt, ich lasse das hier raus. Du hast jetzt gerade gesagt, du sagst mir, das ist das Beste an Arbeit, was du abzuliefern hast und ich gucke mit dir nochmal gemeinsam drüber, aber ich werde es nicht aufhalten.

Ich bin hier nur der, der deinem Gewissen nochmal auf die Sprünge hilft, zu sagen, na, hast du nicht doch abgekürzt? Bist du dir wirklich sicher? Ich lasse das jetzt raus. Und das macht einen ganz massiven Unterschied, weil dann, was passiert? Die Änderungseinheiten werden kleiner, klassisches agiles Thema, weil die Leute nicht mehr sagen, oh Gott, oh Gott, oh Gott, der Review-Prozess ist so aufwendig, dann muss er sich aber auch lohnen, sondern wir drehen es halt um und sagen, nee, der Review-Prozess ist erstmal freundlich und der Default ist, wir gucken da zusammen drüber.

und alle machen ihre Arbeit und reden drüber

und klären das und dann lassen wir es auch

raus und dann ist der in 5 Minuten erledigt.

Also wenn ich halt zum Beispiel nur

weiß ich, ein Pull-Request bei uns kann sein,

Paket-Update vom Nginx, weil

war ein CVE drin, kommt die nächste meiner Version.

Ein CVE ist ein Vulnerable, was?

Ja genau, also

war eine Vulnerability, die bekannt war,

die haben einen Patch bereitgestellt, wir spielen den Patch ein.

Dann ist der Diff bei uns auf der Plattform

typischerweise so zwei Zeilen lang,

also irgendwie Version vom Nginx

hochgedreht und den Hash halt angepasst.

und die Review dazu sieht dann so aus,

ja, ne, machen wir, oder?

Ja, was war da noch drin in der

Änderung? Ja, nix, war nur der CVE.

Und beim NGINX? Ja, auch nur

der CVE. Ja, jut, okay, was waren

hier die Anforderungen? Anforderung war, wir

müssen Updates machen, weil wir die Sicherheit

aufrechterhalten sollen. Nachweis,

naja, das ist jetzt die alte Version, war die, die neue ist

die, zack, fertig, raus damit, Ende.

That's it.

Das ist halt den Leuten

in den Prozessen das so an die Hand zu geben,

dass sie nicht jedes Mal vor so einer Checkliste stehen von,

du musst jetzt aber umhalten, damit dir nachher keiner den Kopf abbeißt.

Weil das ist ja dann alles immer nur noch Ass-Covering,

dass niemandem die Schuld zugeschoben werden kann.

Und das ist ja nicht der Prozess, um den es geht,

sondern der Prozess ist, dass Leute produktiv arbeiten können.

Und während dieser Arbeit, der Vektor der Änderung immer heißt,

mit jeder Änderung machen wir es erst mal potenziell sicherer und nicht unsicherer.

Und wenn man dann sagt, okay, wenn ich das für alle Änderungen sicherstellen kann,

dass alle Änderungen die richtigen Vektor haben,

ja, dann mache ich doch einfach mehr Änderungen

und werde halt immer sicherer.

Ja.

Ja, das ist interessant. Also was mir da gerade noch als Idee kommt,

es gibt da eigentlich ein Problem bei dieser Sache

mit den quasi Pull-Requests.

Wenn das jetzt nicht in so einer Firma ist, wo alle Leute da Ahnung haben

von dem, was sie tun, sondern wieder

den nicht ganz optimalen Fall angenommen,

dann kann sich jemand hinstellen,

kann sagen, er ist jetzt hier der Türsteher und der guckt sich das alles an.

Und

dann hat er

eine Existenzberechtigung, obwohl er eigentlich sonst gar nichts

tun muss. Und das kann dann

dieser Informationsasymmetrie

dann ausnutzen.

Für mich regelt das der Wettbewerb.

Eine Firma, die so drauf ist, wird halt

Schwierigkeiten haben, wirklich

innovativ nach vorne zu laufen.

Was ich halt noch spannend finde, ist, dass Python

natürlich, um mal die Schleife jetzt noch zu ziehen,

auch als

Sprache natürlich ein gutes Standing hat.

Ich hatte vorhin noch mal irgendwie durchgeguckt

und wenn man halt guckt,

wenn ich,

wir könnten jetzt sozusagen, also der

völlige Tiefschlag ist natürlich, wenn ich es gegen

PHP vergleiche.

Da habe ich halt das Problem, dass allein die

Laufzeitumgebung von PHP und die Sprache selber

ich hatte vorhin

geguckt, über die letzten 20 Jahre

über 600

CVEs eingesammelt haben.

Und die machen im Prinzip

in einigen Jahren das

Fünffache von dem, was Python über die

letzten 20 Jahre

insgesamt hat.

Also bei Python kamen irgendwie 20

CVS oder sowas raus über die letzten 20 Jahre.

Viel mehr kommt da einfach

nicht. Und

das ist halt auch schon mal was, wo man immer sagen kann,

okay, das ist was. Auf der einen

Seite die Sprache selber hat viele

Probleme nicht, sowas wie ein

Buffer-Overflow zum Beispiel, kannst du mit Python

erstmal so nicht erzeugen. Und es ist auch in der Community

ja so verankert, dass extrem viele

Bibliotheken, viele Frameworks

das ja auch als Thema für sich erklärt haben und

eben sagen, wir basteln

nicht nur um Security-Probleme rum, sondern versuchen

sie dann ordentlich zu fixen. Und es gab

auch in Python selber, also die Sachen, die es

gab, wenn ich halt schaue, das war mal

irgendwann ein libxml-Thema,

weil du halt zum Beispiel

libxml über

das externes Auflösen von Entities dann

irgendwie Code ausführen konntest und so ein Kram.

Aber

die wurden halt in der Community

immer sehr differenziert und schnell

diskutiert und auch

adäquat behoben.

Da

habe ich einfach eine völlig andere Basis, von der

ich ausgehe, als wenn ich praktisch

bei jeder Codezeile, die ich schreibe, da denke ich

dann eher so an C, tatsächlich

meinen Doktor-Kittel angezogen haben muss, um

ja, nicht daneben zu tappen.

Ja, dann hat, glaube ich, sowas wie Rust auch

deswegen gekommen, oder? Weil das genau das dann wieder

anders macht und

in den Griff kriegt, ja.

Ja, ja, also Rust ist auf jeden Fall,

also ich meine, es kommt halt

darauf an, was man jetzt,

ich glaube, eben vor Buffer-Overflow,

so muss man gar nicht so viel Angst haben, aber

wenn man jetzt Server betreibt,

die halt super viele Requests bearbeiten

oder so.

Was hat letztens in einem

Podcast irgendwie der

Entwickler von Flastia

Armin Ronacher gesagt? Er meinte so, Rust

ist halt für ihn schon

allein deswegen so viel netter, weil

Python hätte er ja auch irgendwie

sehr gerne gemacht, aber das liegt halt wie Sau.

Das ist halt, da kann man

nicht viel dran machen. Und das ist

natürlich schon irgendwie

so.

Das würde ich gerne verstehen, weil da geht mir

Philipp dreht den Kopf und ich

habe auch so ein kleines Messer, was mir in der Tasche aufgeht.

Ja, ja, klar. Also es ist

muss, aber ich kann

schon in gewisser Weise verstehen, was er

meint. Also ich meine, bei Rust kannst du dir halt

sicher sein, dass da nichts liegt,

wenn du es halt richtig machst.

Was meinst du denn damit da liegt was rum?

Naja, zum Beispiel,

dass halt

der Hauptspeicher immer weiter anwächst, ohne

dass du das eigentlich wolltest, ja,

sozusagen, ohne dass du wirklich den Hauptspeicher brauchst,

sondern dass halt Sachen nicht wieder

weggeräumt werden, die halt irgendwann mal angefallen sind.

Klar, also Python

nimmt dir das Memory-Management halt komplett

weg und

das ist tatsächlich Fluch

und Segen zugleich, logischerweise.

Also jede technische Entscheidung der Hinsicht hat

immer Trade-Offs und ein Aspekt

bei Python ist nun mal, dass Python

Speicher, den es mal gebraucht hat,

auch wenn es den Akut gerade nicht braucht,

nicht einfach mal so wiederhergibt.

Also wenn dein Prozess

mal irgendwie, keine Ahnung, ein Gig oder zwei Gig groß

ist, dann kann

es gut sein, dass der das jetzt für die nächste Zeit

mal behält, auch wenn du alle Objekte gelöscht hast

und wenn die Garbage Collection durch war,

weil es ist halt auch ein Trade-Off

zu sagen, naja, ständig

Mellocs groß und klein und

groß und klein zu machen, hat auch

Nachteile. Es hat Nachteile in der Hauptspeicher

Fragmentierung, das ist an sich ein Performance

Thema, jada jada jada jada

und Python als Universalsprache

in der Hinsicht, wo eben Memory Management als

ich kümmere mich drum, draufsteht,

verstehe ich, dass es in diese

Richtung neigt, eben eher diesen

universalen Ansatz da zu verfolgen. Und Rust

tritt nun mal an mit, du hast deinen

Speicher im Griff, dann müssen sie das auch abliefern.

Das ist klar.

Also nochmal ganz kurz, vielleicht, was

ein Melloc ist, also du alloziierst

irgendeinen Speicher, oder?

Genau, also wenn du

vom Betriebssystem halt Speicher haben möchtest,

dann ist es ja heutzutage

eh schon nur noch virtueller Speicher. Also

Also dass das in deinem Rechner irgendwie 8 Gig, 16 Gig oder halt mal ein halbes Tera oder ein Tera RAM drin ist, das weiß ja kein Programm.

Das guckt auch kein Programm so wirklich nach heutzutage, sondern ein Programm geht her und sagt, ey, du, könnte ich mal irgendwie Speicher im Wert von 3 Terabyte haben?

Und dann sagt normalerweise der Linux-Kern heutzutage, klar, kein Thema, hier hast du.

Und erst in dem Moment, wo es das dann auch anfängt zu beschreiben, sagt der Kern, ach, du willst es auch noch benutzen?

Na dann, dann teilt er ihm tatsächlich irgendwie diese Sachen zu.

Und deswegen gibt es einige Programme, MongoDB ist halt auch so ein Ding,

die alloziieren zum Beispiel immer bloß in Vielfachen von 2 oder in 2 Potenzen oder so ein Kram.

Also wenn der halt hergeht und sagt, ich brauche hier mal RAM,

dann sagt er als erstes, ich brauche 64 MB,

und dann irgendwie, ja jetzt hätte ich auch lieber 118 MB.

Okay, also jetzt hätte ich gerne 1 GB.

Und das kann manchmal schon so ein bisschen unangenehm sein,

aber der Vorteil ist halt, wenn der Speicher dann auch am Stück ausgeliefert wird,

dann hat das bestimmte andere charmante Aspekte,

weil dann bestimmte Overhead-Strukturen im Kernel dann halt reduziert werden können.

Der kann sogenannte Huge-Pages machen, das heißt, du musst dann halt nicht,

wenn du einen Gigabyte alloziierst, muss der Kernel halt nicht eine Million mal

eine 1-Kilobyte-Page irgendwo in seiner Tabelle abmarkern,

weil auch das kann plötzlich schon mal 2, 3, 4, 500 Millisekunden dauern,

sondern der sagt dann einfach nur noch, hier hast du das Gigabyte.

Und das sind so Sachen, wo Python dann eben auch häufig optimiert.

Und Python ist extrem erfolgreich, was diese Optimierung angeht.

Ein Beispiel dafür sind zum Beispiel Listen.

Listen haben eine, es gibt eine Operation bei Listen,

die ist unoffensichtlich O von 1,

nämlich ein, genau, ein Append an Listen bei Python ist, wie war denn das, ne, sind Listen nicht immer ein O von 1 Append?

Ja, sollte, wer weiß es, ich weiß es, da war, ne, es gab irgendeinen spezifischen Fall, also die Story drumherum grob ist die,

dass die Speicherallokation für Listen in Python auch immer nur verdoppelt.

Der alloziiert einen Buffer für das Array, um die Indizes zu verwalten

und alloziiert aber, wenn er dann sozusagen es größer machen muss,

nicht einfach sozusagen, dann muss er ja sozusagen das Ganze,

achso genau, das Problem ist, wenn du es dann größer machen willst,

musst du den Bestandsspeicher plus 1 nochmal neu alloziieren,

alles umkopieren und dann halt das neue reinschreiben.

Was Python aber macht ist, Python alloziiert immer dann das Doppelte von dem, was es vorher hatte,

kopiert das einmal um, dann sind die nächsten n gratis,

dann musst du wieder einmal verdoppeln, einmal kopieren und dann hast du wieder 2n gratis.

Und das sind so typische Sachen, die man in solchen Situationen halt hat,

was so Laufzeitumgebungen für einen automatisieren und machen

und weswegen sich dann hinten so ein bisschen komische Speichereffekte ergeben.

Und da habe ich lange, lange Zeit meines Lebens auch immer mit meinem Kopf kratzend davor gestanden

und konnte Leuten nicht erklären, warum es das jetzt gerade tut.

Und da muss man sich halt irgendwann sagen, kann man nicht erklären.

Warum es genau das jetzt gerade tut, kann ich dir nicht erklären.

Ich bin mir relativ sicher, dass es kein Leak ist, wenn du halt dann irgendwie mal sowas beobachtest

über eine Woche oder einen Monat, wenn du einen langlaufenden Prozess hast

und die Saisonalitäten findest und du was merkst wie, ah, okay,

frühmorgens haben die Leute ihren Kaffee getrunken, jetzt lesen sie alle irgendwie das,

auf deiner Webseite ist, dann geht ihr Speicherbedarf

irgendwie hoch, dann kommen abends

irgendwann die Cronjobs, dann geht er nochmal ein bisschen hoch,

dann passiert lange nichts und dann ist plötzlich,

gibt er mal wieder ein bisschen Speicher frei und dann ist es irgendwie gut.

Und wenn du dann

aber siehst, okay, über einen Monat ist das immer das Gleiche,

dann mag das zwar sein, dass er zu jedem einzelnen

Zeitpunkt mal einen Speicher hat, den er

jetzt gerade akut nicht braucht,

aber es liegt nicht.

Ja, ich weiß auch nicht,

was er damit genau gemeint hat.

Nee, ich verstehe das, dass er sagt, ich kann

zum Beispiel, in Python ist es schwierig,

kontrollierbar schlanke Prozesse zu bauen.

Das geht nicht so ohne

weiteres. Also das geht schnell, dass dein,

wenn du zum Beispiel

eine Datenverarbeitungspipeline hast mit

neun oder zehn Schritten und jeder

Schritt davon braucht irgendwie

einen Gigabyte RAM, dann kann das

schon sein, dass dein Python nachher zehn Gig frisst.

Weil er halt eben

den Speicher von vorher noch nicht freigegeben

hatte, der jetzt aber auch gerade nicht gepasst hat, um das

nächste Ding zu bearbeiten und

dann so. Das ist halt

das kriegst du unter Python halt nicht gut kontrolliert.

Ja, vor allem, weil alles so dynamisch ist,

weil ich also im Zweifel auch wirklich den Stack hochwandern

kann und schauen kann, was da rumliegt oder

ein Integer-Objekt als beliebiges Objekt sehen

kann, was halt in Rust ohne weiteres nicht möglich ist

und auch in anderen Poemischsprachen nicht geht.

Aber auch

ohne Speicherverwaltung kann ich ja in Python

durchaus noch andere Sicherheitslücken machen,

die also gar nichts mit dem Speicher zu tun haben,

mit dem, was wir jetzt die meiste Zeit

besprochen haben, sondern halt zum Beispiel, dass ich sage,

ich verwende den Subprozess

und öffne den Subprozess und

übergebe einen String

und habe diesen String halt

konstruiert aus Benutzerdaten und

jetzt habe ich plötzlich eine Command Injection,

dass man beliebige Shell-Commandos ausführen kann.

Das kann man

in jeder Programmiersprache

und in jeder Programmiersprache

die Shell-Commandos ausführen kann. Natürlich kannst du

dich auf den Standpunkt stellen, okay, man hat

das gefälligst nicht zu machen oder man hat

gefälligst immer Shell gleich freuds zu setzen

oder das ist ja der Standard, also dass man eine Liste

übergibt, aber

das sind die, also es gibt noch

zahlreiche andere Schwachstellen, glaube ich, die

in höheren, auf höherem

Level noch passieren können, die gar nichts mit dem Speicher direkt

zu tun haben.

Ja, absolut, genau, was habt

ihr, habt ihr schon mal böse Sachen gesehen,

die in Python schiefgegangen sind?

Ich weiß nicht, ich überlege

gerade, ob ich irgendwas mal

wirklich Schlimmes gesehen habe.

Django Rackaxe. Der Shellout,

den Philipp da nennt, das ist halt ganz klassisch.

Ja, das ist schon schlimm. Das ist ganz klassisch.

Auch sehr beliebt ist, wenn Leute

meinen, ich muss hier Flexibilität reinbringen

und jagen halt irgendwie User-Input einfach durch

einen E-Val durch. Das ist sozusagen

die interne Variante des Shell-Outs.

Was ist denn ein E-Val?

E-Val, ja, okay, Entschuldigung.

Ja, Funktion. E-Val ist Evil.

Aber das ist im Prinzip die

Oh ja, doch, Pickle.

Ei, ei, ei.

Ja, Pickle, nur trusted.

Da kann man sich

auch schon mit dem Fuß schießen.

Mit E-Val hat man sogar einen ganz, ganz schlimmen Bug.

Und zwar hat eine Anwendung auf die Idee gekommen,

dass man doch das cachen könnte.

Und man könnte doch den Code nehmen

und dann kann man sich so ein kurzes...

Also man nimmt irgendwelche Benutzerdaten,

die oftmals abgerufen werden.

Dann schreibt man dynamisch Python-Code,

der das ausführt.

Und dann kann man das cachen.

Und dann war aber das Problem,

dass sogar die noch eine Datenbank-Schwarstelle hatten,

dass man sehen konnte, was in der Datenbank lag

und da lagen deren Cache-Objekte.

Und dann lagen da plötzlich Benutzer-Passwörter

oder sonst irgendwelche Sachen.

Also da kann man halt, wenn man

Schwachstellen verkettet, kann man das

auf sehr krumme,

sehr fiese

Sachen, die man mit einer einzelnen Schwachstelle gar nicht machen

könnte. Also das war jetzt nicht

der Fehler von denen, dass sie, also es war

ein Fehler, dass man den Cache

plötzlich sehen kann. Und es war ein anderer Fehler,

dass sie überhaupt Eval verwendet haben.

Aber erst durch die Kombination ist es halt eigentlich eine

Schwachstelle gewesen.

Auch so ein klassisches Ding ist auch Directory Traversal.

Dass halt irgendwie

von außen sagen kannst, ich will XYZ

haben und dann wird halt nicht ordentlich

geguckt, ob du durch Punkt-Punkt-Slash

Kombinationen plötzlich dir dann irgendwie

ETC-Pass-Videos und so ein Kram halt auslesen lassen kannst

und das sind immer auch, das ist

tatsächlich, glaube ich, am wichtigsten

und deswegen ist dieses, das ist wieder

Variety matches Variety, deswegen

sagen wir, wir wollen so schnell so viele

Verbesserungen in der Security wie

möglich durch unsere Entwicklungspipeline jagen können,

weil

die eigentlichen Vektoren ist nachher, dass

du hast immer eine Vielzahl von

Vielzahl von potenziellen Schwachstellen,

die für sich genommen alle gar nicht so schlimm

sind. Und wenn du aber immer

nur auf der Suche nach dem einen großen Ding

bist, um alles zu reparieren,

dann vergisst man schnell, dass es halt eher um diese

Verkettung geht, wie Philipp sagt.

Da gibt es viele Kleinigkeiten, die das halt machen.

Also eben Directory Traversal, irgendwie Daten abzusaugen,

die dir dann einfach nur noch den Pointer geben für

ah, guck mal, da könntest du da drüben nochmal gucken.

Ein Klassiker, den ich mag,

sind Exceptions.

Exceptions sind für mich die sensibelsten

Daten, die dein System zur Laufzeit

eigentlich von sich gibt.

Weil das Problem ist ja folgendes.

Dein System ist in einem nicht bekannten Zustand

mit Daten, die du nicht kennst

und weißt nicht mehr, was es tun soll.

Und die Daten können halt alles sein.

Das können die Kreditkartendaten sein,

das können die was auch immer.

Und dann steht da irgendwie Value Error.

Hast du nicht gesehen?

Und du kannst den User nicht davon abhalten,

Daten ins falsche Feld zu schreiben.

Dann schreibt er seine Kreditkartendaten

halt das erste Mal irgendwie bei seinem Nachnamen aus Versehen

rein. Und deswegen diese

Bewertung von, was ist eigentlich sicher und was

ist unsicher, ist total schwer.

Das Paradigma sollte auch

eher sein, lieber ein bisschen

zu sensibel zu sein und sozusagen

dein Schutzniveau einmal grob

festzulegen und zu sagen, okay,

wir gehen ja mit Kreditkartendaten um.

Du musst davon ausgehen, dass irgendein

doofer User, nein, die User sind nicht doof.

Das Problem, es ist ein Usability-Problem.

Das Usability-Problem ist, dass wir halt ein Gehirn

haben, was bekloppt ist.

Da kommt dieses ganze Thema Cognitive Processing rein von, unser Gehirn will Energie sparen und deswegen reagiert es auf irgendeine Form von Challenge immer mit der billigstmöglichen Antwort, also Pattern Matching. Und das Pattern Matching von unserem Gehirn ist auch nicht Best Match, sondern First Match. Das heißt, du hast eine Seite vor dir, hast aus deinem Passwortmanager deine Kreditkartennummer kopiert, dein Kind will was von dir, ja bitte, ich muss nur noch, klick, klick, klick und dann hast du halt deine Kreditkartennummer in das falsche Feld eingetragen.

So, und das ist halt, wie man bei Microsoft damals, alle zwei Millionen Mal, ja, das ist bei uns halt nächsten Dienstag. Und sowas, und deswegen sagen wir auch, wenn wir Anwendungen dann mit Schutzniveaus belegen und sagen, was macht man hier, dann gucken wir eigentlich nur noch nach dem Worst Case und sagen so, jetzt müssen wir davon ausgehen, dass das ganze Ding mit dem Niveau geschützt werden muss.

Weiter differenzieren macht überhaupt keinen Sinn mehr, weil du kommst dann von Hölzchen zu Stöckchen und irgendwer greift eh daneben.

Und deswegen bin ich immer sensibel drum, wenn es darum geht, so Exceptions an externe Systeme weiterzuleiten,

weil im Prinzip übergibst du jemandem Externes alle deine Daten, weil du ja gar nicht weißt, was in der Exception drin ist.

Wenn du es gewusst hättest, hättest du halt schon irgendwas geschrieben, damit die nicht auftritt.

Wie bekommst du dann mit, wenn eine Exception passiert? Also an irgendein System muss das ja weitergeleitet werden.

Ja, internes System. Also ich meine, wir, also, ich habe mich hier heute jetzt noch nicht wieder vorgestellt, ich bin ja so ein bisschen Stammgast schon. Philipp und ich, wir kennen uns noch nicht, ja. Wir betreiben halt Systeme auf eigenen, wir sind ein eigener sozusagen Cloud-Anbieter in der Hinsicht und haben die Infrastruktur und wir machen das auch so, dass wir halt zwischen den unterschiedlichen Locations, die wir haben, halt entweder verschlüsselt Sachen weiterreichen oder eben lieber Dienste dezentral überall lokal nochmal vorhalten und dann musst du halt selber noch eine Greylock-Instanz da haben.

Und wenn man das heutzutage alles vernünftig ein bisschen automatisiert, dann lässt er halt noch eine Greylock-Instanz raus und kann sie dann da einfüttern.

Was ist Greylock, Christian?

Das ist ein Log-Aggregationssystem.

Also den kannst du mit Log-Daten befüttern und ihn dann nachher Parser drüber jagen lassen und dir automatisch Alerts schicken.

Das ist auch so ein Ding, da spielen wir gerade zum Beispiel mit rum für so Threat-Themen.

Der kann aus Log-Daten IP-Adressen rauspopeln.

und der technische Begriff für Parsen, und hatte halt dann wieder eine Anbindung an, daran abzugleichen, ob diese IPs assoziiert werden mit irgendeiner Form von, da kommen ständig Angriffe her.

Und dann kann ich die Auswertung dann wieder zurückfüttern auf meine Firewall vorne und kann sagen, so, und immer wenn irgendwie eine IP, die den Threat Indicator hat, irgendwie öfter als so und so oft pro Stunde vorkommt, dann wird die jetzt erstmal für drei Tage lahmgelegt.

Ah, das ist aber gefährlich. Es kann ja sein, dass jetzt irgendjemand auf die Idee kommt und sagt, okay, du hast einen ganz, ganz wichtigen Kunden, mit dem du immer kommunizierst und derjenige schafft es, irgendwie in das Netz reinzukommen von dieser IP und dann löst er diese Anfrage aus. Ich glaube, da gab es auch schon mal Virenscanner, die, sobald ein Paket kam, dann die gesamte IP geblockt haben und dann konnte man die lustig anschreiben von 8888, einem typischen DNS-Server und die haben gesagt, oh, das Paket sieht nach Virus aus, sofort blocken wir alles von diesem Rechner und dann geht nichts mehr.

Ja, genau. Da muss man immer mit vorsichtig sein und nichtsdestotrotz so ein bisschen mit so Sachen experimentieren, weil halt gerne mal rumzugucken, wie sie aussehen und dann willst du halt immer noch die Möglichkeit haben, nochmal durchgreifen zu können in dem Moment, klar.

Ja, aber ich meine, das ist, macht das auch solche Sachen wie, weil ich kenne das eigentlich eher so als, es gibt immer, entweder verwenden Leute diesen Kibana-Stack oft.

Kibana hört sich nach Kibakirsch-Banane an.

Ja, es schmeckt nicht so gut wie Kirsche oder Banane, leider. Aber klingt auch lustig, ja, nee, das ist so irgendwie Elasticsearch und also diese Richtung.

aber da werfen Leute auch Logdaten rein

oder halt eben Greylock oder

manche machen das auch mit Postgres oder

aber ich meine jetzt für Python

speziell, da gibt es dann irgendwie so

Sentry oder Bugsnack

oder so, wo die Tracebacks halt gesammelt

werden. Kann man sowas eigentlich auch

gut selber hosten, weil das habe ich jetzt tatsächlich

verwendet, aber ich kenne es auch immer nur, dass man

da externe Services verwendet.

Kein Problem, Sentry kann man ohne Problem, ist auch ein

Source-Projekt, kann man ganz normal selber hosten.

Kommt ja auch selber aus der Python-Ecke,

Ist, glaube ich, auch Django unten drunter oder so.

Ich bin mir gar nicht mehr sicher.

Ja, war es mal.

Aber stimmt, ist auch, genau.

Vielleicht nicht mehr.

Century ist ja relativ groß geworden tatsächlich, Armin und so.

Und die kannst du selber hosten tatsächlich an der Stelle.

Das würde ich dann auch immer empfehlen.

Wichtig ist sozusagen der Unterschied von der Log Aggregation

versus Exception Logging.

Exception Logging hat die große Aufgabe,

wenn du viel vom Gleichen

entgegenkriegst, weil irgendwie der eine

backt gerade 50.000 Mal im letzten

Tag auf, dann willst du, dass der dir die

schon normalisiert und sagt, hier, das Problem

gab es jetzt in 50.000 Instanzen,

hier sind die Parameter, die ich gesehen habe.

Logging macht natürlich immer nur,

hier ist der Hydrant, hier kommt

alles raus.

Ja, interessant.

Da gibt es also viele verschiedene Typen von

Angriffen, die man irgendwie mit verschiedenen

Typen von Verteidigungsmaßnahmen beantworten

möchte, können muss,

probieren kann.

Sollen wir uns mal

unbeliebt machen? Oder ich mach mich unbeliebt.

Wir, ein Scanner oder sowas.

Ich meine, was Leute immer so machen, wenn sie zu Hause,

ich meine, vielleicht,

sehr beliebt,

aber irgendwie glaube ich zum Beispiel,

das bringt alles nix.