Was ist Threat Modeling?

00:00:00: Im Großen und Ganzen geht es darum, den Modell zu erstellen.

00:00:01: Wie der Name schon sagt über alle möglichen Denkbahnen oder beziehungsweise die Angriffsrichtungen, die man so entdeckt hat, über die man nachgegrübelt hat, die mal aufzuschlüsseln gegen Maßnahmen auszubuchstabieren und die Umsetzung davon zu planen.

00:00:16: Und das idealerweise nicht nur einmal sondern immer wieder weil sich die Gefahrenlage natürlich ändert, weil sich ... Die Software verändert im Laufe des Entwicklungsprozesses.

00:00:41: Das Thema heute ist Thread Modeling.

00:00:43: Ich bin Fredrik Struß, ich bin seit acht Jahren Entwickler bei der TechEd-Spray Fullstack und habe zwei meiner Kollegen dabei.

00:00:50: Könne ich gerne vorstellen?

00:00:52: Ja hallo!

00:00:53: Ich bin Thomas Popp, auch Fullstacks Entwickler, schon seit vielen Jahren bei der techEd Spray und war jetzt in diversen Projekten bei der Einführung und Durchführungen von Threadmodels oder Bedrohungsmodellen dabei.

00:01:07: Hallo und ich bin Immanuel Simms, auch schon lange bei der ThechEd Sprays Leite hier das Kompetenzzentrum für Zuverlässigkeit und Sicherheit.

00:01:15: Und da passt es natürlich voll rein, das Thema habe auch in der Praxis schon einige Threadmodelle mitgestaltet über die letzten Jahre hin.

00:01:23: Ja, herzlich willkommen!

00:01:25: Joa ich würde sagen dann steigen wir auch schon gleich ein... ...natürlich die initielle Frage, die man sich natürlich stellt ist was ist Threadmodeling?

00:01:33: Und woher braucht man das?

00:01:34: Die Geschichte vom ThreadModeling nach zu zeichnen ist nicht so einfach weil natürlich seit Software entwickelt wird ... gucken sich Softwareentwickler an.

00:01:41: Wo sind irgendwie Probleme?

00:01:44: Wo kann die kaputt gehen, wo kann die Kaputt gemacht werden?

00:01:46: Was sind so Angriffswektoren?

00:01:48: und der Begriff Threadmodeling ist aber glaube ich ein bisschen jünger.

00:01:53: Der spuckt zwar auch schon eine ganze Weile durch die Geschichte der Softwareentwickelung... ...aber ich würde sagen so ein bisschen der Kick-off war das Thread Modeling Manifesto was vor ein paar Jahren veröffentlicht wurde von ein paar... ...Softversicherheitsarchitekten.

00:02:10: Die haben sich zusammengesetzt in so einer Reihe von Workshops und haben da dieses Manifest zusammengeschrieben.

00:02:16: Das Manifests kann man sich online anschauen, aber danach sucht findet man das schnell... ...und ist erstaunlich kurz und erstauntlich allgemein.

00:02:24: Deshalb ist es immer noch schwierig, das genau abzugrenzen... ...von so eine Allgemeinsuche nach Gefahrenquellen- und Angriffsmöglichkeiten

00:02:32: sicherheitslücken.".

00:02:35: Ja ich kenne... Faltmodeling, als ich mich angefangen habe damit zu beschäftigen.

00:02:39: Ist mir das eingeführt worden?

00:02:41: Das ist klassisch aus dem Bereich von Sicherheitsbehörden militär und so kommt weil die haben sich ja auch quasi deren Aufgabe sich damit zu Beschäftigen wie beschütze ich was wovor muss ich das beschützen?

00:02:50: usw.

00:02:51: Und sofort... ...das fällt mir noch als Kontext ein.

00:02:53: also tatsächlich die Historie dass man sich so gedankend übermacht und auch manche von den Methoden sind tatsächlich richtig alt.

00:02:59: aber in der Software ist natürlich schon nochmal ne ganz andere Geschichte.

00:03:04: okay und... Da haben wir ganz kurz geredet und es ist noch weiter schwierig, aber was gehört denn da jetzt zu?

00:03:14: Also ich stelle mir das vor.

00:03:16: Ich setze mich jetzt hin und gucke mir meine Software an und entscheide, was ich finde.

00:03:22: und wie genau machen wir

00:03:23: das?

00:03:24: Genau also im Großen und Ganzen geht's darum ein Modell zu erstellen, wie der Name schon sagt über alle möglichen Denkbahnen oder beziehungsweise die Angriffs Richtungen die man so entdeckt hat, über die man nachgegrübelt hat.

00:03:36: Die mal aufzuschlüsseln gegen Maßnahmen auszubuchstabieren und die Umsetzung davon zu planen.

00:03:43: Genau das idealerweise nicht nur einmal sondern immer wieder weil sich die Gefahrenlage natürlich ändert, weil sich... ...die Software verändert im Laufe des Entwicklungsprozesses genau.

00:03:53: und dieses Red Modeling Model Dieses Manifesto selbst gibt sehr wenig vor, das ist sehr abstrakt.

00:04:00: Da stehen vor allem eher so handwerkliche allgemeinen Zielstellungen und wird fast von der Philosophie reden.

00:04:11: Genau!

00:04:12: Und da gehören eine ganze Reihe von Punkten dazu.

00:04:14: Also zum Beispiel dass es wichtig ist, dass sich das ganze Entwicklungsteam damit beschäftigt Im Gegensatz zu dem wie es vielleicht vorher gelebt wurde das ist so ein Experten oder den Expertin gab, die sich dann immer die Security angeguckt hat oder sogar noch out gesourzt war und irgendjemand anderes dann immer sich die Security angeschaut hat.

00:04:31: So dass die Entwicklerinnen und Entwickler halt Fehler gemacht haben diese nicht machen wenn sie sich stärker beschäftigen würden und dass das ein gemeinsamer Prozess ist.

00:04:39: das zum Beispiel so ein ganz wichtiger Punkt in diesem Manifest.

00:04:42: Ja, dem finde ich wahnsinnig wichtig weil ich das auch schon erlebt habe dass dann Security von Leuten die eigentlich relativ weit weg vom Projekt waren gemacht wurden.

00:04:49: Und sie haben auch gesagt Sie machen Bedrohungsanalyse und... ...die haben sich natürlich Gedanken gemacht woher können Bedrohrungen kommen?

00:04:54: aber der Rückfluss in den Projektalltag war derart gering.

00:04:58: Dass der Mehrwert.

00:05:00: manchmal hatte ich das Gefühl eher so auf Papier am Ende endete und nicht tatsächlich in der Software.

00:05:06: Papier ist ein gutes Stichwort.

00:05:08: eine andere Art an Security heranzugehen ist diese Ich nenne sie mal Checkbox Compliance, also dass man quasi so eine Liste von Sachen hat die man abhakt und dann ist es oft eher offiziell sicher.

00:05:18: Es ist auch ne Art und Weise wie lange da rangegangen wird und immer noch angegangen wird.

00:05:22: ich will das auch gar nicht schlechtreden weil das hilft eine Übersicht zu haben, das hilft irgendwie Sachen nicht hinten runterfallen zu lassen die man vielleicht nicht umschirm hat.

00:05:29: Es artet aber in so einer Bürokratie aus die dann wenig freiraum lässt für... so ein kreativen Problemfindungsprozess, weil wenn man sich anguckt wie Hecken funktioniert das hat mal ganz viel mit Kreativität und Spielen zu tun.

00:05:42: Also wo findet man Komponenten?

00:05:44: Wo findet man Teile des Systems die nicht genauso funktionieren wie sie streng genommen funktionieren müssen?

00:05:48: Wie kann man das aufhebeln?

00:05:49: Wie kann Man Sachen nutzen für Zwecke für die Sie überhaupt nicht gedacht sind um irgendwie Die Sicherheit von dem System zu kompromittieren?

00:05:57: Und als Sicherheitsforscher oder Forscherin oder als Entwickler muss man natürlich genau ... so ähnlich denken, um genau diese Angriffs-, ... ... diese Einfallstore zu finden und zu beheben.

00:06:06: Und ähm... ... genau deshalb ist es glaube ich auch ein starkes Anliegen von diesem Manifest, ... ... zu sagen weg vom Abhaken von Sachen und hin zum kreativen gemeinsamen Prozess.

00:06:18: Ich fand das ganz interessant wie du gerade gesagt hast.

00:06:21: die Angreifer haben diese kreative Freiheit ... ... und können da aus dem Vollen schöpfen und das klingt ja fast als würde man sich quasi künstlich limitieren, wenn man sich da auf total starre Prozesse einlässt.

00:06:33: Das finde ich einen interessanten Gedanken.

00:06:38: Ich kenne ja auch noch so diese Welt wo das plötzlich aufkam.

00:06:41: IT-Sicherheit ist irgendwie wichtig.

00:06:43: Wir haben gemerkt es gibt also gab's so IT Angriffe die total dumm gelaufen sind Also jetzt nicht für den Angreifer sondern für die Betroffene und für die Opfer.

00:06:52: Und dann musste man irgendwie so IT Sicherheiten machen.

00:06:55: Aber wussten Leute auch nicht so gar nicht so richtig, was sie machen und haben sich einfach mal irgendwo TLS eingeschaltet oder irgendwo ein Passwort gemacht.

00:07:02: Oder so aber haben sich nicht systematisch Gedanken macht Was kann denn eigentlich schief gehen?

00:07:06: Und dann hatte man auf dem Papier IT Sicherheit aber oft nicht da wo man es brauchte dafür dann an anderer Stelle.

00:07:12: und ich glaube da hilft das schon wenn man sich so ein bisschen Gedanken macht auch von der Fachlichkeit her also... ...was habe ich denn eigentlich für Werte wo andere Leute daran interessiert sein könnten hier und die muss ich dann vielleicht schützen.

00:07:26: Ich muss vielleicht andere Sachen nicht so sehr schützen.

00:07:29: Genau, Fachlichkeiten sind auch so eine wichtige Sache und im Sinne des Manifests, dass man möglichst alle relevanten Stakeholder mit anbindet in diese Bedrohungsfindungsanalyse.

00:07:40: also natürlich jetzt nicht alle Nutzer oder so.

00:07:43: aber... ... die Entwickler haben halt eine sehr technische Perspektive auf das Problem.

00:07:48: Die wissen im Zweifel, weil nicht welche Benutzer Gruppen arbeiten überhaupt mit dem System?

00:07:51: Was könnten Motivationen von denen sein?

00:07:53: auch manchmal ganz dumme Motivations wie Faulheit oder sowas?

00:07:57: Also ein System nicht so zu benutzen wie es gedacht ist, weil... Es ist halt Arbeit und man macht lieber anders und dadurch öffnen sich vielleicht ganz neue Angriffswektoren oder Datenschutzproblematiken,... ...die man sonst nicht auf den Schirm hat.

00:08:09: Genau!

00:08:10: Und deshalb ist es total wichtig da möglichst verschiedene Perspektiven ganz ruhig fachlicher und technischer.

00:08:15: Genau.

00:08:16: Ist das dann auch ein Punkt für den sweatmodeling Ansatz im Gegensatz mit dem Team, im gegensatz zu den Experten?

00:08:25: Dass man halt mehr... Sache viele Hände schnelles Ende gibt es ja den Spruch dass man halt das Wissen von allen einsammelt.

00:08:36: ich kann mir vorstellen, dass mit dem Security-Expertenansatz dann das dann vielleicht auch wegfällt, dass er nur sich das Projekt anguckt Dann seine Expertise natürlich Waltennest und auch glaube ich mehr wert bringt.

00:08:49: aber.

00:08:51: Wie gesagt auch den Lerneffekt ist ja wahrscheinlich nicht wegzudenken, wenn man sich damit beschäftigt.

00:08:57: Ich weiß nicht ob ich sagen würde vieler händeschnelles Ende.

00:09:00: Wenn man sich ein großer Wunder zusammensetzt, es ist in Personenstunden schon gerechnet das vielleicht nicht billiger... Aber anderseits hat halt jede Person die an dem Projekt arbeitet Möglichkeiten fachlich oder technisch neue Sicherheitslücken einzubauen.

00:09:14: Also ich rede jetzt nicht von dem absichtlichen Fall, sondern einfach indem man Fehler macht.

00:09:19: Und das ist schon gut dass Leute anfangen sich aktiv Gedanken darüber zu machen und so... ...so sich dann alle mal zusammensetzen.

00:09:26: es hilft schon dabei auch einfach... ...sich gedanklich auf einen zu

00:09:29: stimmen.".

00:09:31: Okay!

00:09:32: Dann fällt mir natürlich noch ein jetzt wo du sagst, es ist wichtig mich sicherlich, dass sie mit sich viele beschäftigen.

00:09:37: Vor allem natürlich auch die verschiedenen Aspekte von so einem Softwareprojekt ein nämlich auch des DevOps.

00:09:46: Thema also die ganze nicht nur die Infrastruktur an sich, also nicht nur das Software an sich sondern die Infrastrukturen der Cloudfalls notwendig oder auf den Servern bzw auch wie kriegen wir beziehungsweise auch das Deployment?

00:10:03: Wie es ist denn da gibt's da auch.

00:10:04: nutzt man jetzt auch sweatmodeling oder?

00:10:09: Ja ich denke schon.

00:10:10: Also für mich ist das threat modeling sollte eigentlich alles umfassen was das System hat.

00:10:16: jetzt ist es oft so, dass man vertragliche Situationen hat wo vielleicht eine Firma hier sich um den Bereich geht mit einer anderen sich um die anderen.

00:10:23: Aber wenn man das so kompat mentalisiert dann fehlt irgendwo ein übergreifender Schirm.

00:10:28: also meiner Meinung nach brauchst du es von der Fachlichkeit in also product owner ... sollten auf jeden Fall beim Threat-Modeling mit dabei sein, weil die können ganz einfache fachliche Sicherheitslücken bauen.

00:10:39: Da bist du technisch wasserdicht.

00:10:40: aber wenn ich Überweisung mache so mache das sich nur den Empfänger eingeben muss und den Absender... ...und ich mich nicht authentisieren muss und ich das unbedingt zu haben will dann ist es halt nicht sicher.

00:10:51: also da kann ich halt fremder Leute Geld überweisen.

00:10:53: Und genauso bis runter zum DevOps.

00:10:56: wenn dann jeder auf die Infrastruktur drauf kommt habe ich auch ein Problem müssen eigentlich irgendwie alle eingebunden sein.

00:11:03: Okay, das ist natürlich der technische Gedanke.

00:11:11: Du hast natürlich auch Fachlichkeit vorhin schon mal angesprochen.

00:11:16: Man muss natürlich auch gucken dass Bedrohungen durch menschliches Versagen kommen kann.

00:11:22: also wo spielt der Mensch mit eine Rolle in Interaktion mit dem System?

00:11:26: Genau sowohl was Angriffe angeht es kennt man ja so ganz klassisch auf den links geklickt Als auch was ich interessant fand, also es geht schon schwerpunktmäßig um Angriffe von quasi bösartigen Akteuren.

00:11:39: Aber was Threadmodel Manifesto auch mitdenkt ist einfach so ein bisschen auch Fehler-Anfälligkeit von einem System.

00:11:46: Also wie könnte jetzt einen User durch einfach nicht bösortiges aber fahrlässiges Verhalten halt ganz viel kaputt machen?

00:11:54: Wie sichert man das System dagegen ab?

00:11:55: Ist ein bisschen eine andere Fragestellung... ...aber ganz viel ist natürlich auch gerade die Maßnahmen, die man da gegeneinander greift sind da ganz Äh ähnlich gelagert.

00:12:04: Ja, so gerade bei der Verfügbarkeitssache dann geht das auch manchmal in den Bereich von Disastern und so die passieren können.

00:12:09: das Rechenzentrum brennt ab... ...und irgendwie habe ich jetzt eine disaster recovery Strategie die damit umgehen kann oder so weil verfügbarkeit für mich auch sicherheitstechnisch sehr wichtig sein kann.

00:12:19: Da gibt's ja manchmal so Überlappungen, wo das dann auch nicht hundert Prozent klar ist.

00:12:22: Genau

00:12:23: und nicht genau klar, wo es reinfällt ist glaube ich eh so ein großes Ding bei SWAT Modeling oder bei so bedrohungsanalysen weil man irgendwann durch die Grenze ziehen will.

00:12:31: Man muss jetzt nicht den Asteroid-Einschlag mit rücksichtigen aber wenn man die zu eng zieht, die Grenzen hat natürlich das Problem dass das dann irgendwo... rausfällt, ja genau.

00:12:42: Also da können wir vielleicht wieder einmal dazu kommen wo der Scope also das große Schlagwort Scope wie man da gut umgeht beim Side-Modeling mit.

00:12:52: Eine Sache die jetzt gerade angesprochen wurde, die ich ganz interessant fand... Wir haben schon darüber geredet halt die Bedrohungen zu analysieren halt zu finden was wie wer kann was und unsere Software machen.

00:13:06: aber gehört nicht auch dazu zu sagen was können wir dagegen machen zu den bedrohnen?

00:13:13: also es ist auch teil davon oder.

00:13:16: Genau das kann man entweder machen indem man diese schwachstellen einfach komplett abschafft ja, also das ist durchaus machbar.

00:13:23: häufig läuft aber dann auch das hinaus was wir halt medikation nennen also sie So weit einzuängen und so schwer ausnutzbar zu machen.

00:13:32: Und selbst wenn sie ausgenutzt werden damit dann so wenig Schaden anrichten zu können, dass man mit dem Risiko leben kann ist ein klassisches Beispiel wäre okay.

00:13:40: wir können nicht tausendprozentig ausschließen das irgendein... Mitarbeiter bestochen wird um irgendwelche unser Datenbank zu löschen oder sowas als sabotage.

00:13:50: aber was machen können sind backups so und wenn diese backups dann nicht überschreibbar sind, wenn die sicher gelagert sind.

00:13:54: Wenn die oft genug gemacht werden kann man so ein risiko quasi... ...innehmen also Risiken die man nicht hundertprozentig ausschließen kann.

00:14:04: Ich glaube Risiken ist auch ein gutes Stichwort, man findet beim Thread Modeling nicht ein.

00:14:08: Ich bin von CVE Nummer-Zweitausendsechsundzwanzig sieben acht sechs eins betroffen und jetzt behebe ich das sondern es ist ja eher... Naja hier könnte man vielleicht grob mit so einem Mechanismus an folgende Sachen rankommen oder was machen?

00:14:21: Und das Risiko gibt's jetzt noch zu überlegen.

00:14:23: was kann man machen um die Wahrscheinlichkeit des Risikos?

00:14:26: zumindest ganz klassisches Risiko Management was auch jeder Projektmanager kennt letztlich.

00:14:31: Und manchmal gibt's ja auch so Sachen dass das Risico Technisch gesehen vielleicht hoch ist aber fachlich gesehen total gering ist also.

00:14:39: Vielleicht kommen wir da später noch mal zu.

00:14:40: aber dieses wer hat denn eigentlich ein Interesse mir diesen Schaden zuzufügen oder für sich selbst dort Profit rauszuholen?

00:14:47: dies manchmal auch ganz interessant.

00:14:49: hast du zwar was wo technisch irgendwie viel entstehen könnte was interessiert niemanden.

00:14:54: Du hattest den po erwähnt und.

00:14:58: Du warst den Kunden und den wirklichen wer.

00:15:03: Das waren jetzt sehr viele Leute, wer muss oder wer sollte denn am Ende... ...in dem Raum sitzen um das Thread Modeling zu machen?

00:15:09: und wie viel Zeit sollte man einplanen?

00:15:12: Wie viel Zeit?

00:15:13: könnte man ein planen und wieviel sollte man einen Plan für ein gutes Thread Model nehmen.

00:15:17: Ja genau also das letzte natürlich so allgemein nicht beantwortet und das ist je nach Kontext ganz unterschiedlich.

00:15:22: ich kann aber sagen wir es machen in den Projekten wo wir das bisher angewendet haben wo wir als Team die Software ... also die Software selbst oder unsere Controller haben, dann hat er quasi vom Kunden noch irgendwie einen DevOps-Team gibt und außerdem noch den Product Owner usw.

00:15:39: Wir haben die Betrungsmedelle erstellt mit dem Entwicklerteam, mit dem ganzen Scrum Team.

00:15:44: das waren so jener Projekt drei bis sechs Leute... ...und dazu waren dann ein zwei Leute von den Product Owners dabei und noch jemand vom DevOps-Team.

00:15:53: oder es war auch zum Beispiel mal jemand dabei der sich für die Sicherheit verantwortlich fühlt im Kundenunternehmen.

00:15:59: Und das kam auch schon mal vor, dass dann Leute dabei waren von dem Trittsystem oder sowas wichtig war für unsere Anwendung.

00:16:05: Dass man da Fragen stellen konnte, dass man da so ein bisschen ja genau vielleicht die Zuständigkeiten noch klären kann, während man diese Bedrohungsmodelle erstellt Genau.

00:16:16: aber das kann natürlich ganz anders aussehen wenn man zum Beispiel jetzt mit Hardware arbeitet Wenn man jetzt sehr komplexes Geflecht von Anwendungen hat und so weiter ... produktiv ist, das glaube ich eher so in der Größenordnung.

00:16:29: Fünf bis zehn Leute und zeitlich da kann man... Das hängt auch ganz von Konzept ab!

00:16:36: Wir haben uns dafür eher so... Ich sag mal einen halben bis einen Tag genommen.

00:16:44: Das ist glaub ich schon auch ein bisschen das Minimum aber es kann glaube ich durchaus vielversprechend sein sich auch mehr Zeit zu nehmen.

00:16:54: In meiner Erfahrung ist schon dass dass man relativ schnell Mehrwert generieren kann, umfassend zu sein braucht man natürlich schon auch Zeit.

00:17:01: Also ich glaube wenn wir einmal anfangen können das richtig machen.

00:17:06: Mir fährt noch ein, dass es so ein paar Schlüsselrollen gibt die auf jeden Fall dabei sein sollten.

00:17:09: also ich finde Product Owner ist wichtig Architekt ist wichtig.

00:17:12: falls man sowas wie eine Rolle wie sonst Security Hero hat oder so der oder die sollte dann auch auf jeden fall dabei sein.

00:17:19: im Idealfall aber schon das ganze Entwicklungsteam Wobei das halt den war ist, wenn man eine Struktur hat wo dann plötzlich vierzig Leute im Raum sitzen.

00:17:25: Das funktioniert auch nicht mehr.