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ß sie 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 das leichteste, 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 da vielleicht nicht so drin sind,

Opcodes, ja, 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.

Macht der dann diese Operation

und

da kann was schief gehen.

Philipp, vielleicht kannst du das noch ein bisschen

erklären, weil das irgendwie, klingt das 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

oder 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 Trostplaster

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.

Eine 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 in 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 einem 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 Leuten verwendet werden, haben ein Minuszeichen drin.

ISO 88591 oder 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 in 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 und 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 einen Zeg-Fault 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 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 irgend so eine 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

das, 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 so spannend 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 anders 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 ...

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.

Ah ja, 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 meine, 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.

Nein.

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

Atomkraftwerkstatt 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 schnell eine HTTP-Library und ich würde ja noch mal von der SSL, noch mal da drüben, Repository von GitHub, sowas ist bei aller halt eher nicht so an der Tagesordnung.

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, ja, das, 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, ähm, und 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 Bind.

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 eine 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

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 NC, 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 einen

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ürzt halt nicht ab

und die kann auch mit allen Benutzerangaben

umgehen. Und nicht mal nur von Angreifern,

sondern auch von Benutzern. Also ich hatte das beruflich

auch so. Wir haben, 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 viel 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 jetzt 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

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

Assertment-Statements in den Code schreiben einfach

und dann sagen, Assert, this should never happen

oder sowas. 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? Und jetzt gucken wir mal, wie mappen wir das alles aufeinander? 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.

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 jetzt mal an, was du so in Python oder auch in anderen Programmiersprachen alles programmiert hast.

Und das sind dann erfahrene Entwickler in 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 Benutzernamen 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.

Also 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 es 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 knall 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, bei einer Basis, und sage, 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, das ist schon ein bisschen gefährlich, weil eine Möglichkeit ist halt schon, wie bei einem Virenscanner, die Wald- und Wiesenattacken findet der sicherlich, was im Internet das Grundrauschen ist, das findet er 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 die 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. Und

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

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

Sequel-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

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 Quadrat Verbindungen

mindestens. Und

wenn du jetzt sagst, okay, das ist mir

zu unsicher, ich packe noch eins davor.

Dann hast du halt

etwas als Quadrat.

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, weiß nicht, 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 Zertifizierungen

oder die Prozesse, sondern

vielleicht mehr, wie lasse ich die entwickeln?

Wie sorge ich dafür, dass, wie gesagt,

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 nach sucht, die irgendwo drinstehen und das wird dann von den Leuten irgendwie geauditet und man fragt sich halt, okay, was machen die denn da eigentlich?

warum tun die das? Und das ist halt

vielleicht so ein, ja, das kriegt man glaube ich

gar nicht so gut in den Griff. Das ist halt wieder der Griff in Richtung

Product Security statt Process Security.

Die,

also ein prozesshafter Ansatz

und wir haben jetzt ja auch seit anderthalb Jahren,

doch seit ein bisschen mehr als anderthalb 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, ja, 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 eine ISO 27000, 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,

nein, die ISO sagt, du musst dich halt

um die für dich relevanten Normen und Vorschriften kümmern.

Das sagt die ISO 27000.

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 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... Ja, Strom ist zum Beispiel für die Availability

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. Na, 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 ist, was relevant 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 News eindringt.

Das Stromkabel, also das kann zum Beispiel passieren, wenn du deinen Prozess so 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 hat jetzt 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 wenn du dann halt sagst, naja, wenn da jemand ein richtiges Long Game spielt und sagt, ich habe hier drei Jahre Zeit, das ist nicht das Problem.

Ich will aber, dass diese NGO mal so richtig gegen die Wand fährt, dann fahre ich jetzt die Lücke und sage,

aha, ich habe 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 einen Drittel seiner Stromkabel durch meine mit dieser Schmelzsicherung zu ersetzen,

dann bin ich in drei Jahren so weit, 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 der 5-Dollar-

Entschlüsselungsmaschine?

XKCD, bitte nochmal einmal.

XKCD?

Comic.

Wo die Idee ist,

dass wir 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,

also wenn jetzt halt 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

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.

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 drauf haben.

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, Unique 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...

Hab ich nicht verfolgt, muss ich zugeben, ja.

War aber auch, glaube ich, nicht der erste Fall in Deutschland

und ich glaube, der dritte 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, ach, 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

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,

Deswegen, ja, 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 ein 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ären wir 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 10 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 den 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?

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

vielleicht so, ja, okay, wenn man die Backups noch hat, dann

ist halt nicht so schlimm und

das ist halt dann vielleicht der Worst Case und da muss man

sich halt Gedanken drüber machen, dass der nicht eintreten kann und der Rest

ist dann egal.

Also 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 das 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.

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

man kann nicht viel dran machen und das

ist natürlich schon irgendwie

irgendwie so, ja das ist

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, es 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. Und da musst du mir auch mal erklären, 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 wieder hergibt.

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 Hauptspeicherfragmentierung.

Das ist an sich ein Performance-Thema.

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

Zweierpotenzen oder so ein Kram.

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

dann sagt er als erstes, ich brauche 64

Mac und dann irgendwie, ja, jetzt hätte ich auch lieber

118, okay, also jetzt hätte ich

gerne einen Gigabyte und das kann manchmal schon so ein bisschen

unangenehm sein,

aber

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,

musst 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, Listen, 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, was 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 es 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,

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 zehn, 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 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

die Shell-Commandos

ausführen können. 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 Freud 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 doch 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 Eval durch. Das ist sozusagen

die interne Variante des

Shell-Out. Was ist denn ein Eval?

Achso, Eval, ja, okay, ja, Entschuldigung.

Ja, Funktion, ja. Eval ist

Evil. Ja, ja. 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 Eval haben wir sogar einen ganz, ganz

schlimmen Bug, und zwar da 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 einen kurzen, 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-Schwachstelle 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,

die halt, also da kann man halt

wenn man halt so Schwachstellen

verkettet, kann man das auch

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 dem,

dass sie, also es war ein Fehler, dass man

den Cache plötzlich sehen kann

und es war ein anderer Fehler, dass sie überhaupt

IWA verwendet haben, aber erst durch die Kombination

ist es halt eigentlich eine Schwachstelle gewesen.

Auch so ein klassischer 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