Podcast forThe Podcast for
Tech Enthusiasts

Robi, what could possibly go wrong? Hast du dich das auch schon mal gefragt?

Ja, ich hab mich gefragt, wenn der AI kaputt ist, wenn ich es wieder schaffe, normal mein, mein Arbeitsalltag und mein Leben auf die Reihe zu kriegen. Aber ich glaub, das meinst du nicht.

Nee, nee, genau, also diesen Satz 'What could possibly go wrong?' Wir haben den in der Softwareentwicklung früher mal benutzt, sozusagen als Mutprobe. Ja, komm, lass mal die point. Ja, nee, weiß nicht, ja, aber could possibly go wrong und los geht es, weißt du so. Und die Frage ist tatsächlich einfach im Grunde genommen, wenn man sie sich ernsthaft stellt, ist sie super wichtig. Ja, und genau in der, über dieses Thema wollen wir in einer heutigen Episode sprechen und zwar über das Thema Threat Modelling.

Sehr cool. Ich glaub, du weißt mehr als ich darüber. Ich bin sehr gespannt.

Genau, also willkommen bei Tobi hoch 2 doppelt Tobi Doppeltag, heute zum Thema Threat Modeling und vielleicht gleich mal vorweg Threat Modeling, also Threat mit T. Ja, es ist die Bedrohung und nicht der der Faden, über den wir reden. Und es geht um Bedrohungsmodellierung. Ja, und es geht um um Sicherheit. Es geht um, wie kann ich meine Software oder mein Projekt sicher machen? Ja, und was was bedeutet das alles? Ja, und wie kann man, wie kann man damit loslegen? bist du denn schon mit dem Thema mal in Berührung gekommen?

Ja, klar, wer nicht, glaub ich, oder man hat irgendwie Software zu Pentestern gegeben und hat sich dann darüber unterhalten, was die so alles gefunden haben. Was ich persönlich immer glaube, was zu zu kurz gekommen ist, ist ganz oft der Sinn und Verstand. Also dieses, was will ich denn überhaupt schützen? Ja, also welche Daten hab ich denn da so was auch immer für einer Software. Und blödes Beispiel, wenn ich jetzt eine Software habe, wo ich einen Mercedes bestellen kann oder ein anderes Auto, dann ist die Frage, muss ich da überhaupt was schützen in der Konfiguration? Weil am Ende ist ja wahrscheinlich eh alles irgendwie public, was ich da auswählen kann. Also die Frage ist, was kann mir da jetzt ein Angreifer am Ende klauen oder welche Daten will er vielleicht haben? Aber das war immer ganz ganz oft halt dieses Problem, wenn man über Security nachdenkt, dass das nicht immer so gesehen wurde, ne. Es wollte, wurde immer quasi so, wir bauen einfach 'n Zaun drum rum, in Anführungszeichen, und dann haben wir einfach alles geschützt. So, und da war ich jetzt nicht immer 'n Freund und hab gesagt, vielleicht müssen wir ja nicht alles schützen, ne. Also, der Schalterraum in der Bank, den muss ich jetzt vielleicht nicht so hoch absichern, ja, weil der Tresor, da ist eigentlich das Wichtige drin, in Anführungszeichen.

Ja, aber auch da, also du hast ja vorhin schon Pentesting oder Penetration Tests als Stichwort gegeben. Das ist eigentlich super, weil in der klassischen, also klassisch im Sinne von, so haben wir das früher immer gemacht, Ablauf ist ja, wir haben Entwickler, die entwickeln was und dann wird getestet und dann gibt es vielleicht Security Tests und am Ende gibt es noch ein bisschen Dokumentation und dann sind wir fertig. Das ganze Thema Threat Modeling setzt aber viel, viel früher im Prozess an und zwar ist die Idee, dass du Leute hast, die dieses System bauen. Also es ist eigentlich völlig egal, ob es der Tresor einer Tresor um einer Bank ist oder die Konfiguration eines Autoherstellers, ja, die stellen sich mal vors Whiteboard und überlegen sich, hm, wie kriegen wir unsere Software denn jetzt kaputt gespielt, ja, und genau das meinte ich auch am Anfang mit diesem Satz, what could possibly go wrong, weil das im Prinzip eine Gedankenübung ist von denjenigen, die es bauen, dass die einfach mal versuchen, eine andere Perspektive auf ihr eigenes Projekt einzunehmen und zu gucken, wie würde ich denn, wenn ich Angreifer wär, mit dem Wissen, was ich jetzt über diese korrekt habe, ja, wie würde ich daran gehen, um das Ganze kaputt zu machen, ja, oder was zu erbeuten und Tresorraum ist ein schönes Stichwort. Es gab ja vor einiger Zeit diesen Einbruch in in dieser einen Bank, wo die Leute einfach durch den Keller gekommen sind, einfach ein Loch in die Wand gebohrt haben. Ja, und das ist ein schönes Beispiel, die haben wahrscheinlich eine Tür gehabt, die war verschlossen, die haben wahrscheinlich eine dicke Tresortür gehabt. Also, wie du gerade gesagt hast, der Zaun sozusagen um das eigene Grundstück und damit kann nichts passieren, die Angreifer haben aber einfach ein anderen Weg gefunden, in den Raum zu kommen. Ja, und das Ganze war halt ein dicker Boa und genau also diese Frage, what could possibly go wrong, versucht man halt mit Threatmodeling systematisch und und frühzeitig zu erkennen, ja, was schiefgehen könnte. Und das ist die ganze Idee, dass man das Ganze sehr, sehr frühzeitig im Prozess hat. Also Shift-Left ist hier wieder das Thema Shift-Left-Security und dass man versucht, von Anfang an an Security zu denken, eine Perspektive eines Angreifers einzunehmen und sich auch überlegt, was kann ich denn erbeuten. Ja, also der beim Tresorraum ist es ziemlich offensichtlich, das was im Tresorraum gelagert ist, aber wie du schon gesagt hast, die Konfiguration eines Autoherstellers oder so, da könnten Identitäten drin sein, da könnten Sachen drin sein, die vielleicht schon im Konfigurator, aber noch nicht auf dem Markt sind. da könnten Sondereditionen drin sein, da könnte man vielleicht was bestellen, was es gar nicht gibt in der Kombination. Also da gibt es schon genug Schabernack, den man anstellen könnt. Und ja, Teil der Denksportaufgabe, sich diese Frage zu stellen, absolut, das ist Teil der Denksportaufgabe. Ja, was, was könnte man denn damit machen und vor allen Dingen, ja, was, was kann ich erbeuten, was kann ich kaputt machen und da ist halt auch einfach auch relevant für für alle Entwickler und auch nicht nur für Security Experten, weil wir kennen kenn das ja ganz typischerweise auch von Bugs, je früher etwas erkannt wird, desto preiswerter ist es halt zu fixen. Ja, das was für Defekte gilt, gilt halt natürlich auch für Security und wenn man ein Security Problem frühzeitig erkennt, ist es vielleicht einfacher, als wenn man die gesamte Architektur auf links drehen muss.

Ja, also du meinst, bleiben wir bei der Bank, ich sollte jetzt nicht ein Gebäude bauen mit einem Stararchitekten für Design und dann, wenn das Gebäude da ist, sich mir darüber Gedanken machen, wie baue ich denn jetzt noch Sicherheit ein, sondern vielleicht von Anfang an, was wollen wir schützen, wie bauen wir das und wie müssen wir vielleicht ein sicheres Gebäude und wie könnten Angreifer da reinkommen et cetera uns überlegen und dann entsprechend uns halt absichern, um das dann auch richtig sicher zu machen.

Spannend. Auch bei dem Bankbeispiel ist einfach, ich sag mal, der Keller wurde ja an sich als sicher definiert, weil da ist die Erde drumherum oder da ist ja ein Kellergewölbe drumherum. Also da kann ja gar nichts passieren und auch da haben wir gesehen, hm, es kann ja anscheinend doch was passieren. Genau, aber reden wir mal drüber, was Threat Modeling eigentlich ist. Also noch mal die 2 Worte, Threat Bedrohung und Modeling ist halt die Modellierung von einer Bedrohung und ja, es ist halt eine, wie wir schon gesagt haben, eine Denksportaufgabe und man kann das im Prinzip relativ einfach machen. Also man kann sich ans Whiteboard stellen, vielleicht auch in als regelmäßige Übung und einfach mal überlegen, was kann man denn tun, wie kriegen wir es denn kaputt gespielt, sozusagen. Und man kann das Ganze aber auch strukturiert machen und strukturieren im Sinne der der Modellierung wär eine Zeichnung und man macht das typischerweise so, dass man ein Datenflussdiagramm macht. Also man hat vielleicht eine 3 t Architektur in der Softwareentwicklung und hat die womöglich auf verschiedenen Systemen laufen, vielleicht sonst vielleicht haben wir eine Datenbank als vielleicht Past Service am Ende und dann haben wir ein Kubernetes in der Mitte und und vorne haben wir ein Frontend drauf und dann hat man natürlich die Datenflüsse und dann vielleicht noch sowas wie so ein Active Directory, wo es dann den weiteren Authentifizierungsfluss gibt und so weiter. Und letztendlich hat man halt immer einen Bruch der Stelle, wo ein Datenfluss von einem System aufs andere übergeht. Ja, das ist so eine so eine typische Bruchstelle und da kann man sich überlegen, was kann denn da schief gelaufen an der Stelle. Also Nehmen wir mal ein ganz einfaches Beispiel, wenn wir zwischen Browser und Backend nicht verschlüsseln, was kann denn da schiefgehen?

Man in the Middle, jemand fängt alles ab, jemand könnte sogar Informationen austauschen, jemand kann mitlesen, mitlesen. Genau, also eine Menge.

Genau, und das ist auch nichts, was ganz abstrakt nur in der Softwareentwicklung relevant ist. Das ist ja auch für normale Altersgegenstände extrem relevant. Also nehmen wir mal den Schlüssel, diesen Funkschlüssel, der dein Auto womöglich entsperrt. Ja, was würde denn passieren, wenn das nicht verschlüsselt ist oder wenn da jemand ein Man-in-the-Middle-Angriff macht und auf einmal dein Auto aufmachen kann? Ja, da kann natürlich folgen, da kann natürlich Inhalt des Autos klauen, da kann das Auto womöglich gestartet werden, womöglich wegfahren und also da merkt man einfach, wenn man das so ein bisschen abstrahiert und einfach auch auf Prozesse in der realen Welt abbildet, wie die Sicherheitsprüfung am Flughafen oder das eigene Auto, ja, oder Ampelsteuerung oder sowas, da kann man halt immer, wenn man sich fragt, what could possibly go wrong relativ viele Beispiele finden, wo ganz schnell ganz viele Sachen falsch laufen.

Ja, das stimmt, wobei man oft auch nicht immer an alles denkt, das ist ja auch so ein sieht man jetzt ja auch in der jetzigen Zeit oder mit A.I., ne. Also vieles, was früher irgendwie so nach dem Motto, ha, das wird keiner machen, weil da musst du irgendwie 4 Wochen sitzen und da irgendwie keine Ahnung was ausprobieren, macht halt irgendwie so 'n A.I. Agent in Minuten, halben Stunden, was auch immer. Und auf einmal sind Szenarien möglich, die waren früher eher unwahrscheinlich.

Ja, umso wichtiger ist, dass man sowas wie Threatmodeling macht und sich überlegt, wie das hier aus, wie das aussehen könnte, weil es geht ja am Ende auch immer nur darum, die Hürde für die Angreifer möglichst hoch zu legen. Ja, also dass die Angriffe möglichst möglichst teuer werden und teuer kann ja heißen, das kostet extrem viel Geld oder kostet extrem viel Tokens oder was auch immer. Aber kommen wir noch mal zu der Modellierung zurück. Wir machen uns Gedanken darüber, was potenziell schief gehen kann. Also es gibt so ein paar zentrale Fragen. Also, Frage 1 was bauen wir überhaupt? Also, wir haben, wir haben eine Systemarchitektur, wo ich schon gerade als Beispiel gesagt hab, wir haben beispielsweise eine 3 t Architektur, vielleicht noch mit einem Active Directory, vielleicht noch mit ein paar anderen Systemen drumrum, Caching, was auch immer, und haben erstmal eine Architektur des aktuellen Systems und überlegen uns, wo fließen denn überhaupt die Daten zwischen diesen einzelnen Bereichen. So, und was kann da schief gehen? Das ist schon Frage 2. Ja, kommen wir gleich dazu, es gibt eine Klassifizierung von Bedrohung, die nennt sich Stride im Threatmodeling, da steht jeder Buchstabe steht für eine Bedrohung und man kann sich halt überlegen, was kann da an an jeder Stelle schief gehen und das hilft natürlich auch, wenn man die Bedrohung klassifiziert hat, eine entsprechende Gegenmaßnahme zu finden und das ist schon die Frage 3. was Was machen wir da dagegen als Gegenmaßnahme? Und in dem Moment, wo wir eine Klassifizierung haben, ich hab ja gerade das Beispiel gegeben, wo ist der oder wo ist das Problem, wenn zwischen Frontend und Backend die Verbindung nicht verschlüsselt ist, dass jemand mitlesen kann. Das ist die Bedrohung, die Gegenmaßnahme ist natürlich hier Verschlüsselung einführen oder S. S. L. oder sowas. Ja, und dann natürlich am Ende idealerweise auch noch mal, wenn man das in einer Form validieren kann, ist die vierte Frage, haben wir das denn eigentlich richtig gemacht? wie gesagt, das findet man überall in der realen Welt, das findet man also, was mir immer prominent einfällt, ist die ist die Schlange am Flughafen, wo ganz klar ist, sozusagen, wie der in diesem Fall nicht Datenfluss, sondern der Menschenfluss durch die Schlangen ist, was da genau passiert, dass man irgendwie seinen Rucksack aufmachen muss und sein Laptop rausholen muss und so weiter. Und da werden die Ingenieure, die das Ganze gebaut haben, was ganz, ganz Ähnliches gemacht haben.

Und wenn man das jetzt baut, dann überlegt man sich quasi, O. K., wir müssen zum Beispiel jetzt S. S. L. einsetzen oder halt irgendwie Encryption und also es geht da drum, quasi schon ein richtiges Design, eine richtige Architektur zu finden, um dann so, wie du gesagt hast, die Schwierigkeit zu erhöhen, für einen Angreifer Dinge zu tun.

Idealerweise muss man auch keine Architektur finden, idealerweise ist es ja die eigene Architektur und man versucht ja eigentlich auch nur noch die Schwachstelle zu finden. Also wir bauen ja jetzt nicht ein, ein, eine eigene Architektur für so ein Szenario auf, sondern haben eine bestehende Architektur und versuchen die auf auf Herz und Nieren zu prüfen, um mal zu gucken, was denn schief gehen kann in diesem Fall. Ja, und es gibt zum Beispiel auch noch so ein Konzept, das nennt sich Trust Boundaries. Ja, und die Idee ist, alles was innerhalb von einer Trust Boundary ist, vertraut sich. Ja, also schönes Beispiel wieder beim Flughafen, sobald du durch die Sicherheitskontrolle durch bist, kommt typischerweise keine zweite Sicherheitskontrolle. Also alles das, was da drin ist, dem wird vertraut, egal ob es ein Passagier ist, der durch die normale Schlange gekommen ist, oder ein Personal Mitarbeiter, der quasi über den Personaleingang reingekommen ist und auch gescannt wurde, oder der Mensch von der Sicherheitsfirma, der da arbeitet. Ja, das ist diese Idee in der Trust Boundary und in der Softwarearchitektur haben wir das auch, so dass wir sagen, zum Beispiel die Flüsse innerhalb der Datenbank betrachten wir nicht. Also man kann das ja im Prinzip von der Granularität immer und immer weiter aufdröseln, bis man in der Kommunikation zwischen beispielsweise Prozesse und Speicher wäre oder so. Aber das macht man typischerweise nicht, weil es einfach viel zu komplex ist, dass man am Ende sagt, es gibt Trust Boundaries und alles innerhalb dieser Trust Boundary dem vertraut. Ja, genau und immer dann, wenn es halt so eine quasi so eine in der Zeichnung ein Kreuz gibt, also ein Datenfluss, verlässt eine Trust Boundary oder kommt zu einer Trust Boundary an, dann ist das der Fall, wo man einfach gucken kann, was, was passiert denn da oder was könnte denn hier schiefgehen. Ja, ja, genau, auch das Beispiel zum Beispiel A.P.I.s ist extrem spannend. Es gibt ja immer diesen schönen Satz, man traut nichts, was aus dem U.I. kommt. Das heißt, der, das was hinten an der A.P.I. ankommt, kann ja von der vom U.I. kommen. Es kann aber auch von einer von einem Drittsystem kommen, was einfach nur diesen Request auslöst und diesen Request manipuliert. Ja, und genau, das ist das beste Beispiel, dass man einfach an jeder Stelle da validieren muss und auch das ist im Grunde genommen die Konsequenz von von Threat Modeling. Ja, und zur Klassifizierung, es gibt ein ganz bekanntes Framework, ich hab ja gerade schon den Namen gesagt, Strite heißt das und jeder Buchstabe steht ja für etwas. Also das S. steht für Spoofing, ja, das ist die Identitätsfälschung. Also ich geb mich für dich aus, beispielsweise, ja, oder ich, ich versuche vorzugeben, Admin zu sein oder in der realen Welt. gehe ich vielleicht als paketdienstleistender Fahrer in eine Firma rein und sag, ich hab hier ein Paket für Herrn Meyer oder irgendwie sowas. Ja, also das ist ja im Prinzip auch eine Identitätsfälschung, weil weil man wohl wirklich durchgelassen wird, weil man vorgibt, jemand anders zu sein. Ja, das T. Tempering, das ist die Datenmanipulation. Das heißt, die Daten, die durch das System fließen, sind nicht mehr in dem Zustand, wie sie eigentlich sein sollten. Also jemand anders hat was hinzugefügt, hat vielleicht einen anderen Payload, nimmt was mit, was er nicht nehmen darf, sowas entsprechend. Ja, das ist Tempering.

Aber es geht darum, wirklich dann Daten zu manipulieren oder sie auch einfach abzugreifen oder?

Abgreifen ist das I. tatsächlich, das ist Information Disclosure, das ist die Informations Preisgabe.

Aber ich könnt zum Beispiel jetzt irgendwie Daten, ja, mich auch wieder ausgeben als bin und irgendwie die Daten manipulieren. Oder ich könnte versuchen, meinen Kontostand höher zu machen und dann geht vielleicht die Überweisung noch durch oder irgendwie so ein Quatsch.

Also O. K., genau, oder du könntest versuchen, jemand anderen zu schaden, indem du sich als als diese andere Person ausgibst und irgendetwas in einem internen Chat schreibst, was vielleicht nicht zitierfähig ist.

O. K., O. K.

Ja, dann gibt es die Repudiation, das ist die Abstreitbarkeit, Rückbarkeit. Also die Frage ist ja immer, ob denn das, was du da, was du da machst, abgestritten werden kann. Also dass du quasi Spuren verwischst, sowas Entsprechendes, ja.

Also nicht Rückverfolgbarkeit und dass du halt einfach eine weiße Weste hast am Ende.

Eine weiße Weste, genau. Also du könntest ja auch Logging-Mechanismus versuchen auszuschalten oder Ähnliches, ja. Das wäre was Typisches.

Dass es keine keine Logs gibt, einfach auch vielleicht den Angriff gar nicht, dass er gar nicht so auffallen kann. Ja, ich greif an, mache irgendwas und versuche jetzt vielleicht nur gutartige Logs zu erzeugen und gar nicht irgendwas, wo jetzt dann steht, hm, da ist was komisch und dann kann ich vielleicht diesen Zugriff oder was auch immer ich da erbeute oder das länger nutzen. Das hört man ja auf, dass Hacker viel länger im Netzwerk waren, Als als es dann aufgefallen ist, ne? Also, dass die dann schon ein, 2 Monate da waren und sich quasi so Abstreitbarkeit oder Repudiation mäßig verhalten haben, um einfach nicht auffällig zu sein und dann quasi viel mehr Infos zu bekommen und rauszufinden, was können wir denn wirklich da erbeuten oder mitnehmen oder über die Zeit viel mehr mit zu leben zu können, ne? Und es gibt auch so Angriffe, die sind richtig, richtig krass, da haben Angreifer. ganz lange Zugriff auf deine Mailbox, aber sie nutzen das nicht. Sie warten quasi, und ich meine, mit AI ist das relativ einfach, ich meine, AI kann ja Kontext in E-Mails verstehen, also sie lesen immer deine Mailbox quasi mit, und wenn dann etwas kommt, wo sie merken, oh, jetzt lohnt es sich, dann geben sie sich zu erkennen und benutzen quasi den Zugriff auf deine Mailbox und fangen zum Beispiel diese Mails ab und fangen dann an, irgendwelche Verträge oder Kontonummern auszutauschen. Und auf einmal fragt jemand, hey, wo ist denn das Geld? Und da ist mir noch ein anderes Konto gegeben und das Geld ist weg. Und das ist gang und gäbe, das ist echt crazy. Also wieder Hinweis auf unsere Folge mit dem Passwort-Save. Benutzt Passkey am besten überall und labert nicht lange rum, dass das alles so schwierig und blöd ist.

Und also spannend, vielleicht nochmal als ganz konkretes Beispiel, ich hab die Tage, hab ich auf meinem privaten E-Mail-Account eine Spam E-Mail bekommen, wo der Absender vorgegeben hat, dass das mein Hoster wäre und ich müsste doch wegen einer NIST 2 Anpassung meine Domain noch mal verifizieren oder irgendwas. Ja, so die sah 1 zu 1 richtig gut aus. Ja, und ich musste also wenn man da drauf geklickt hat, ist man halt zu diesem Login gekommen, wo man halt also an der URL erkannt hat, das ist nicht letztendlich der Hoster, aber inhaltlich sah das absolut richtig aus. Ja, und man hätte dann das Passwort eingegeben, was wär denn da passiert oder was ist da passiert? Da hat man natürlich einerseits Identitätsdiebstahl begangen, so weil das Portal sah halt sehr, sehr ähnlich aus. Die hätten dann mit meinen Credentials sich angemeldet an dieser am Backend. Ja, und das hätt ich natürlich nicht abstreiten können, dass ich das dann womöglich gewesen wär hinterher, wenn sie das gehabt haben. Also ist tatsächlich einfach auch 'n gutes Beispiel, dass es auch mehrere Sachen natürlich hier betreffen.

Ja, können wir nachher noch diskutieren. Ich glaub, einer der Punkte ist halt, wie geh ich denn mit Usern um und ich glaub, das ist, glaub ich, der größte Angriffsvektor heutzutage, die die Faulheit oder die Bequemlichkeit von Menschen, ohne jetzt jemandem nahe zu treten zu wollen. Ja, aber glaub, das ist etwas, das ist das größte Problem aktuell, was wir so haben.

Aber gehen wir noch mal kurz weiter durch, wir waren ja beim S. T. und R. I. ist Information Disclosure, also Informationspreisgabe, das heißt, dass die Daten einfach abgezogen werden, dass sie dann womöglich einen neuen Preis bekommen im Darknet und dass einfach Leute diese Informationen haben, die sie nicht haben. Dann gibt es das D. im Strike, das ist Denial of Service, das ist die Dienstverweigerung. Also man kennt ja das als Stichwort Denial of Service Angriff, dass man beispielsweise so viele Requests an ein System schickt, dass das System da drunter unter dieser Last kollabiert. Genau, auch das könnte natürlich passieren in meinem Beispiel mit dieser 3 T. Architektur und Browser vorne dran, kann das natürlich sein, dass irgendjemand über so ein Botnetz zum Beispiel das Backend einfach angreift, ja, und da ganz viele Requests schickt. Was kann man da wiederum gegen machen? Man könnte natürlich ein Proxy davor schalten, man könnte ein Caching einschalten und so weiter. Und das ist halt auch wieder wieder genauso markiert als Denial of Service. Was tun wir dagegen? Entsprechend ein Mechanismus, wie zum Beispiel eine D.D.O.S. Firewall davor schalten, die so eine Attacke abwehrt. Und das letzte Elevation of Privilege, das ist die Rechteauswertung, also Ausweitung, sorry, also wenn ich es irgendwie schaffe, mehr Rechte zu bekommen, als ich eigentlich haben dürfte, ja, also sowas wie, ich sag einem Kollegen, gib mir mal bitte den Schlüssel für den Serverraum, ich muss da mal gerade was machen, ja, das ist ja sowas in einer typisch analogen Welt, ja, der Es darf natürlich nicht passieren, dass jemand, der einen bestimmten Schlüssel hat, den einfach so weitergibt. Oder halt entsprechend ein Recht im System, etwas zu ändern, was ich einfach gar nicht haben darf. Das kann ich natürlich auch von mir ruhig erbeuten. Und genau, es gibt für jedes einfach wahnsinnig plastische Beispiele in der echten Welt. Also wir haben ja vorhin über das Auto Keylers sozusagen gesprochen, also wenn jemand, der nicht das Recht hat, mit dem Schlüssel mein Auto zu öffnen, das darf, ist das natürlich auch schon wieder eine rechte Ausweitung, genauso wie es natürlich in der Softwareentwicklung, dass das ganz typisch ist. Ja, und sobald man das zusammen hat, also wir haben jetzt uns ein Modell aufgezeichnet, wir haben mit Strite Bedrohungen klassifiziert, das ist so der der Moment, wenn man das Ganze beispielsweise mit seinem Team am Whiteboard gemacht hat, wo man sich überlegen kann, hey, welchen Mechanismus führe ich denn jetzt ein um genau diese Bedrohung abzuwenden. Weil in dem Moment, wo man, sagen wir mal, wir haben System, wir haben 10 Bedrohungen identifiziert und hat gegen diese 10 Bedrohungen jetzt schon eine Gegenmaßnahme definiert und führt diese auch ein und setzt sie entsprechend um, dann ist es ja so, dass derjenige, der das System angreifen möchte, schon mal mindestens, ich sag mal, über diese 10 Hürden springen muss, um überhaupt die Hälfte zu finden, typischerweise.

Also ich erschwer es quasi, natürlich, genau, und es gibt keinen, 100 Prozent sicher. Das haben wir ja auch in unserer Passwort oder Passwortfolge genannt. Am Ende wird es halt immer schwieriger, aber es ist nicht die Garantie, dass es unmöglich wird. Das ist halt einfach so.

Genau. Und man weiß halt auch, warum man bestimmte Sachen einführt. Also, warum habe ich SSL, wenn ich eine Website betreibe, ja, damit einfach Tempering, also die Manipulation von Daten oder Information Disclosure einfach nicht passieren kann. ne, auch wenn das vielleicht nervig ist und auch wenn es vielleicht C.P.U. Zyklen kostet und aufwendig ist und man Zertifikate verlängern muss und so weiter, es gibt ein Grund, dass man das.

Oder Crosssite Origin, das ja so was viele sagen, ich mach da jetzt einfach mal das Sternchen rein, weil das zum Entwicklungszeitpunkt bin ich irgendwie genervt, dass ich jetzt von da nicht dahin darf und so weiter und der Browser quasi sagt, nö nö nö nö, aber ja, das hat auch seinen Grund, ne, dass halt quasi nicht jeder einfach dahin darf und es nur von einer bestimmten Domäne kommen darf et cetera. Also das sind meistens, glaube ich, auch Hürden. Du kannst jetzt, oder es gibt auch viele Sachen in Frameworks, die gut überlegt sind im Sinne von Security, aber wenn halt die, ja, Lazyness, Bequemlichkeit der Entwickler dann kommt und sie quasi zum Entwicklungsteil, ja, das machen wir dann später, wir machen es jetzt mal aus, ja, weil wir haben andere Sorgen und Nöte, wir müssen ja irgendwie was bauen und Features liefern und dann gerät das vielleicht sogar in Vergessenheit, dann ist es vielleicht cool, wenn ich so eine Liste habe, warum haben wir welches Feature und vielleicht auch diese Liste durchgehen kann und sagen kann, habe ich SSL, habe ich das richtig konfiguriert, habe ich das eingeschaltet? Lasst uns nochmal draufschauen und nicht im Glauben zu leben, wir haben das Beste gemacht, so nach dem Motto.

Ja. Und was wichtig ist, auch nochmal dieser Perspektivumkehr, also es gibt einfach einen Riesenunterschied, wie ein Ingenieur, der etwas implementiert, denkt und wie ein Angreifer denkt. Und der Ingenieur, der etwas entwickelt, der denkt typischerweise in Listen. Also sowas wie, ich implementier Feature A, dann mach ich Feature B, dann mach ich Feature C und dann hab ich vielleicht ein noch ein To-Do, ein Bugfix für Feature A und dann vielleicht noch mal was Neues, ein Feature D. und so weiter. Also für für die Personen, die immer etwas entwickeln, für die ist das immer so eine so eine lineare Liste, so eine so eine Abfolge. das als erstes mach ich das, dann mach ich das und damit ist es erst einmal erledigt. Ein Angreifer denkt in in Bäumen, ja, das nimmt man typischerweise Attack Trees, ja, und ein Attack Tree zeichnet einfach auf, wie man etwas erbeuten kann. Und wenn wir noch mal für dieses Beispiel mit dem mit dem Keyless Drive von einem Auto, wenn wir da noch mal drüber nachdenken würden, ist ja die erste Frage, wo parkt denn überhaupt ein Auto? So, wenn ich das rausgefunden hab, ist die Frage, wie komme ich denn überhaupt in die Nähe, wenn jemand das Auto auf oder abschließt, dass ich ein Funksignal abgreifen kann. So dann ist die Frage, welche Hardware brauche ich dafür, wie bin ich im richtigen Moment da, um genau das zu erbeuten. So, wann kann ich das Auto denn wiederum wegfahren, was kann ich mit diesem Schlüssel alles machen in dem Auto, wenn ich den erbeutet hab und so weiter. Also für die ist es halt eher so eine, ja so so eine Baumstruktur, die sich sozusagen auffächert oder eine Kette. wo man sagt, als erstes hab ich das eine bekommen und mit dem einen kann ich jetzt das nächste erreichen und mit dem nächsten kann ich jetzt wieder das dritte bekommen, um am Ende schlussendlich zu Punkt 4 zu kommen. Ja, und das ist halt der der Unterschied zwischen Menschen, die was entwickeln, völlig egal ob Software oder Hardware ist, die denken halt eher in Listen, Feature 1, Feature 2, Feature 3 und Hacker denken typischerweise in Ketten. Wenn ich 1 erbeutet hab, kann ich damit 2 machen, um zu 3 zu gelangen. Ja, und deshalb ist es auch so spannend, dass man sich einfach mal so eine Perspektivumkehr leistet und sagt, so, hey, was könnt ich denn nicht machen, wenn ich das erbeutet habe? Ja, und ja, was will ich denn eigentlich erreichen? Also, wenn ich jetzt ein Malicious Actor wär in meinem System, was ist denn da zu erbeuten, so, oder was sind da für Daten drin und welche Kette müsste ich denn aufbauen, um an diese Daten zu gelangen? Ja, und das ist, glaub ich, ist glaub ich, extrem spannend für jemanden, der sonst eher in so Feature-Listen denkt.

Ja, ja, das sieht man ja auch, wenn man sich so Angriffe dann anschaut, wie die das gemacht haben, denken sie, hm, das ist echt smart, teilweise, ne. Also ja, am Ende ist das so, so Kleinigkeiten oder so Schnipsel und viele Schnipsel geben dann 'n Puzzle, ja, gerade auch, wenn man so über so Social Engineering und sowas nachdenkt, dann ja, ist es echt krass, was man heutzutage tun kann, weiterzukommen, wenn man jemanden angreift.

Und in der Softwareentwicklung wird ja auch ganz viel immer über über Bugs gesprochen, also im Sinne von, da ist ein Fehler passiert. Aber es ist manchmal auch gar nicht so sehr ein Bug, es ist einfach etwas, was sich aus der Konsequenz von dieser Listen Darstellung von Features einfach ergibt. Ja, also wenn man, wenn man in der Reihenfolge Feature A. B. und C. implementiert, dann hat man halt nicht über den Zwischenraum zwischen Feature A. und B. nachgedacht. Ja, wenn man so ein Attack Tree aufmalt, dann macht man das womöglich neben neben Stride und Third Modeling gibt es noch ein paar weitere Frameworks. Ja, es gibt auch eine Framework, das nennt sich Pasta, das ist Process for Attack Simulation und Threat Analysis, hab ich ein bisschen mehr risikozentriert. Es gibt auch eine grafische Darstellung von Attack Trees oder typischerweise gibt es von OWASP so eine Top Ten von Bedrohung, die es im Web gibt. Also das ist typischerweise sowas wie SQL Injection drin, solche Themen Cross-Site Scripts Ding und so weiter und ja, letztendlich gibt es mehr als ein Framework, um dieses Mindset zu etablieren, mehr auf Sicherheit zu achten und entsprechend kann man halt gucken, was für den eigenen Softwareentwicklungs Lifecycle ideal ist und vielleicht sprechen wir noch mal kurz, wer wer beteiligt sein sollte. Also ich glaub bei so einer, bei so einem Threat Modelling ist es halt extrem spannend, verschiedene Rollen zu haben. Also dass man nicht nur, nicht nur Entwickler oder nicht nur einen Architekten hat, ja, sondern vielleicht auch jemanden aus der Security Abteilung, vielleicht ein ein Product Owner mit dabei, der Product Owner müsste einem ja sagen können, was man zum Beispiel erbeuten kann bei einem System und dass man einfach eine eine bunte Mischung an Leuten hat und einfach versucht mit mit diesen verschiedenen Rollen in so eine Analyse reinzugehen, um zu gucken, hey, was kann man denn da jetzt irgendwie herausfinden, wie wär sozusagen die Reihenfolge, wo kann man diese Kette denn auch brechen mit so einem typischen Datenflussdiagramm. Ja, und ja, dass man einfach eine möglichst breite Palette an Rollen da hat, die einfach alle versuchen, mal diesen Umkehrschluss zu tun und zu sagen, hey, lass uns doch mal gucken, was wir hier machen können. Ja, Tools, vielleicht noch mal ganz kurz, es gibt ein Threat-Modelling-Tool von Microsoft, es gibt auch diverse Open-Source-Tools. Ich glaube, es gibt eins von Ovors, das heißt, glaube ich, tracken, wenn ich das richtig im Kopf habe. Es gibt auch eine, wie heißt es, Three Three Child, das ist Thread Modeling, Three Agile, genau, schwer auszusprechen, Third Modeling as Code. Ja, das ist auch was, dass man quasi versucht, das Ganze mit mit Code abzudecken. Ja, aber entsprechend, ich find es eigentlich immer noch tatsächlich auch sehr gut, das Ganze an so einem, an so einem Whiteboard und so einem Datenflussdiagramm zu machen. oder einfach mal erst mal drauflos zu überlegen, ja, und dann das Ganze hinterher vielleicht in so ein Datenflussdiagramm zu überführen und dann auch regelmäßig mal das Ganze macht. Also, wenn man innerhalb eines Projektes das Ganze einmal macht, dann hat man vielleicht, na ja, einen kleinen Prozentsatz von dem, was möglich ist, abgedeckt. Aber ich glaub, es ist echt sinnvoll, weil so ein so ein Produkt ja auch einer Evolution unterliegt, das einfach regelmäßig zu machen. Ja, vielleicht so ein paar Tipps, kleinen Anfang, hab ich ja gerade schon gesagt. Ja, vielleicht gucken wir uns erstmal nur ein einzelnes Feature an oder eine A.P.I. als erstes Threadmodel. Ja, und dann langsam größer werden. Es muss auch gar nicht perfekt sein am Anfang. Also überhaupt ein Threadmodel zu haben ist besser als keins. Ich hab ja schon am Anfang gesagt, klassischerweise in der Softwareentwicklung wurde ja dieses ganze Thema Sicherheitstests oder Penetration Tests am Ende gemacht. Ja, und damit frühzeitig anzufangen, ein Threadmodel zu haben und das direkt in die Entwicklung mit rein zu geben, ist halt besser als gar keins zu haben und das wird am Ende auch einfach von der von den Kosten her preiswerter. Ja, regelmäßig wiederholen, besonders bei Architekturänderungen. Also wenn man sich jetzt überlegt, man ändert meinetwegen den Auth Provider, ja, ist das vielleicht eine gute Idee, das zu machen oder man ändert die Datenbank oder man ändert eine Zugriffsschicht oder man ändert hier was, was Größeres ist, definitiv regelmäßig wiederholen. Das Ganze auch in Form eines Teamworkshops machen. Also ich sag mal, mehr Augen, ja, sehen einfach auch mehr. Also als Einzelkämpfer so ein Third Model zu machen, da wird man, glaub ich, kommt man nicht weit. Und es erhöht natürlich auch die Akzeptanz im Entwicklerteam, da was zu machen. Dann wie immer Dokumentation pflegen und im Zweifelsfall vielleicht auch machen, A. A. I. Agenten nutzen. Ja, man kann sich ja auch ein Agenten bauen dafür und einfach auch mal den Agenten fragen, was denn hier schief gehen könnte. Ja, und vielleicht kommt der Agent ja auf noch weitere Ideen, die man gar nicht gesehen hat.

Ja, aber es gibt ja diesen Ansatz auch mit dem Red und Blue-Team, das rote Team will immer irgendwie einbrechen und das blaue muss es verhindern. Und während das passiert, beobachtet man, was sind denn Schwachstellen? Ah, SSL vergessen, keine Ahnung, irgendwas falsch konfiguriert. Und vielleicht kann man das ja heutzutage auch mit AI-Agents machen, dass man da jetzt nicht wirklich Teams feiern muss, sondern sagen kann, hier, du bist ein was auch immer, Hacker versuchen mal hier einzubrechen und ihn vielleicht guided, also hab ich, ist vielleicht auch ein Ansatz, den man, den man gehen kann, um einfach auch rauszufinden, ist gut oder ist nicht gut.

Vor allen Dingen, um vielleicht auch einen Attack Tree herauszufinden, auf den man selber nicht gekommen wäre.

Ja, genau, also quasi sagen, brecht da mal ein und gucken, welche Kreativität gibt es denn, ne, und dann einfach ja, wie du sagst, daraus den Baum zu bekommen und dann zu gucken, wie können wir das denn besser machen, wie können wir das denn besser absichern?

Ja, es gab ja grad dieses, vor wenigen Tagen ist ja dieses Open A. I. Thema durch die Presse gegangen, wo die, ich glaub, bei Huggingface eingebrochen sind mit dem Modell oder das Modell, das gemacht hat, ohne dass sie es eigentlich wollten. Und da hat das Modell ja im ersten Schritt auch das geschafft, die diese Sandbox zu überwinden und auf einen Server zu kommen, der Internetzugriff hat und das heißt ja, glaub ich, für eine Schwachstelle in NPM, irgendein Paket von NPM, glaub ich, gemacht oder so. Und das ist sicherlich etwas, wo die Leute, die das Sandbox-System designt haben, auch nicht im ersten Moment drauf gekommen sind, dass die A.I. genau das versucht. Ja, und so kann man natürlich auch womöglich einen neuen neuen Attack-Vektor finden.

Ich glaub, A.I. allgemein bringt stellt auch das tierisch auf den Kopf. auch wenn man jetzt so sieht, was da so möglich ist mit mit Packages et cetera. Ich mein, früher gab es ja so die sogenannten Script-Kiddies, das waren ja so Tools, die du runterladen konntest und die haben dann irgendwelche bekannten Schwachstellen einfach ausgenutzt, ja, und du musstest jetzt nicht mehr so viel wissen, in Anführungszeichen. Und ich glaub, mit DAI hat das halt das Script-Kiddy noch mal 'ne ganz andere Mächtigkeit, ne? Also, ich hab da so 'n Agent und erzähl dem lustig, was ich jetzt gerne hätte und Die Absicherung, die da drin steckt, ne, also manchmal hat man das ja, hey, ich kann das nicht machen, weil ne, oder ich, wir können das nicht tun, weil das ist ja alles nur trainiert, das ist ja, heißt ja nicht, dass das jetzt unbedingt 100% sicher ist, ich kann das ja dann trotzdem aushebeln, ne, also ich hab mal einfach, ich wollte mal wissen, ist es möglich mit A.I. mal eben was zu dekompilieren, ne, weil ganz viele auf LinkedIn auch sagen, hier, ich hab irgendein Spiel nachprogrammiert, hat irgendwie 24 Stunden war fertig, ne, und dann dachte ich mir, Wenn ich jetzt A.I. sag, ich hab hier irgendwie 'ne Exe und jetzt nicht irgendwie Java oder .net, wo irgendwie E.L. Code dazwischen ist, sondern wirklich C++ oder sowas, geht das denn, ne? Und der erste Zug der A.I. war: 'Ja, weißt du, das können wir ja gar nicht machen, das ist ja gar nicht dein Programm.' Das, das will ich nicht und dann hab ich einfach gesagt: 'Ja, weißt du, ist ein bisschen blöd, weil mein Source Code ist abhanden gekommen.' Du bist meine einzigste Chance, wieder an das Wissen zu kommen. Ja, OK, dann mach ich es. So, Also selbst wenn jetzt irgendwie in den Models und wenn das alles schwerer wird, quasi dann auszuführen, was man sich alles ausdenken kann, Sandboxes et cetera. Aber ich glaube, wenn jemand nicht ganz blöd ist, kann er mit Hilfe von A. I. eine Menge anstellen. Das war früher überhaupt nicht möglich, ne?

Ja, und auch da hilft halt am Ende Threat Modeling, um eine Idee zu bekommen, was denn überhaupt geht, was die anderen nutzen könnten, was passieren kann und so weiter. Ja, also das ist im Prinzip Wissen, was völlig egal, wie es mit A.I. weitergeht, wichtig ist im Kopf zu haben.

Ja, Security ist, glaube ich, in im Zeitalter von A.I. noch mal doppelt so wichtig.

Ja.

Und ich glaube auch, ich hab eine Mail bekommen von von meiner privaten Microsoft Account oder von dem Microsoft Account, da wurde mir gesagt, dass SMS und E-Mail, zweiter Faktor, wird abgekündigt und ich soll doch gefälligst einen Passkey machen. Und ich glaube und also ich finde das gut, ich glaub, viele werden jetzt auch wieder schimpfen und sagen, ah, nee, find ich blöd, aber Pask-Key ist so viel mächtiger, auch das, was du erzählt hast, ne, von diesem Hoster, ne, also du sollst dich da irgendwie einloggen und am Ende leiten das weiter und machen dann halt irgendwie was in einem Auftrag, mit Pask-Key funktioniert das einfach nicht, weil der Pask-Key ist auf diese Domain vom Hoster gebunden, das heißt, der Pask-Key würde da nie und nimmer landen bei dem, ne, die so, und deswegen, ja, User müssen auch ein bisschen Threat Bottling machen.

Und Fun Fact, die E-Mail wär auch, oder selbst wenn ich drauf reingefallen wäre, ich hab natürlich 2 Faktoren an, auch das hätte es natürlich am Ende nicht nichts gebracht, ne. Aber das Passwort wär schon mal in der Wildnis gewesen.

Genau, und wenn das jetzt noch woanders verwendet worden wär und so weiter, ne.

Genau, das tut es ja nicht mehr, da haben wir mit der Passwortepisode für gesorgt. Seitdem habe ich nur noch eindeutige Passwörter.

Ich glaube, was er vielleicht auch noch sagen kann, ist ja, dass Angreifer ganz oft auch auf diese Fear of missing out oder auf diesen, wenn du das jetzt nicht machst, dann geht die Welt unter, ja, Moment setzen. Und was Apple da ganz gut macht, also wenn die merken, dass du zu viel änderst in einer gewissen Zeit, dann sagen die auch, jetzt kannst du erst mal nichts mehr machen. Also komm vielleicht mal wieder in vier Stunden und dann können wir irgendwie weitermachen, ist vielleicht auch was für die Software, die man baut und wenn es echt schützenswert ist, dass man, ich meine, das ist unheimlich nervig, wenn du wirklich du bist, ja, und du willst das jetzt machen und das Ding sagt, ja, jetzt erst mal nicht, ja, komm einfach wieder in, wie lange auch immer die Zeit ist, aber ich glaube, für jemanden, der quasi durch Social Engineering oder wie auch immer das passiert, mit Phishing angegriffen wird, ist sowas natürlich einfach wunderbar, weil es einfach davor schützt, vielleicht auch diesen Moment der Pause und das Gehirn, und sein nicht mehr so viel Adrenalin fängt wieder an zu denken und man fragt sich eigentlich, was mach ich da eigentlich und ist nicht jetzt in dem Fluss und zieht das alles durch, was die so wollen. Also ja, ich glaub ja, und das ist in meinen Augen auch irgendwie etwas, was vielleicht in Threatmodelling rein muss, ne. Also wie schützen wir unsere User, selbst wenn die halt einfach ausgetrickst werden und so blöd sind, könnt man ja auch sagen, wenn der das macht, ist er selber schuld. Aber ich könnt auch sagen, wenn der sich ungewöhnlich verhält oder wenn der auf einmal irgendwie das Passwort und den zweiten Faktor ändern will und irgendwie noch eine Handynummer, dann sagen wir jetzt erst mal Stopp und verhindern das so ein bisschen.

Ja, wenn ihr mehr erfahren wollt, es gibt ein paar ganz tolle Bücher zum Thema Threat Modeling. Und zwar ist ein Autor, der Adam Shoustak, der hat ein Threat-Modeling-Buch geschrieben. Die zweite Edition kommt im Dezember, dann wohl mit AI-Security, also da bin ich auch schon mal sehr gespannt drauf. gibt es auch ein älteres Buch, das heißt auch Threat Modelling aus dem von Microsoft Press und wir packen das gerne hier in die in die Shownotes, den die Verweise auf die Bücher. Und dieser Adam Shoestek ist jemand, den man sich auf jeden Fall merken sollte. Der hat unter anderem ein Kartenspiel-Design, das nennt sich auch Avalation of Privileges. Und diese 4 Fragen, die ich am Anfang genannt habe, da gibt es halt auch entsprechend in seinem Repository Informationen dazu, also quasi dieses 4 Fragen Framework, ne, woran arbeiten wir, was könnte schiefgehen, was machen wir dagegen und haben wir einen guten Job gemacht, da gibt es halt entsprechend auch Informationen auf GitHub von Adam Shoustak und das ist derjenige, der letztendlich da sehr, sehr weit in dem Thema ist und sehr viel auch dazu publiziert und auch eine Beratungsfirma mittlerweile gegründet hat, ist ein Ex-Kollege von uns.

Ja, das war es von uns von heute von Tobi hoch 2. Es hat Spaß gemacht, dieses Thema mit euch zu teilen, Wenn ihr weitere Gedanken oder Fragen habt, schreibt uns doch eine Mail, gern auch wenn ihr Teamwünsche habt. Bis zum nächsten Mal bei Tobi hoch 2, wenn es wieder heißt: Doppel Tobi, Doppel Tech.

Ciao.

Ciao!