Einblicke in Threat Modeling

Voiceover: Hallo und herzlich willkommen bei Digital Future, dem Podcast zur Technologie

Voiceover: und Unternehmenskultur.

Voiceover: Mein Name ist Wolfgang Schoch und ich bin Agile Coach bei InnoVex.

Voiceover: Ich habe aber auch schon ein paar andere Sachen gemacht und so die IT-Branche

Voiceover: aus verschiedenen Blickwinkeln kennengelernt.

Voiceover: Zum Beispiel als Softwareentwickler, als Experte für Suchtechnologie oder im Vertrieb.

Voiceover: Ich freue mich, euch in jeder Folge des Podcasts eine Kollegin oder einen Kollegen

Voiceover: vorzustellen und mit ihr oder ihm über das jeweilige Fachgebiet zu sprechen.

Voiceover: So bekommt ihr einen Einblick in unseren technologischen und unternehmenskulturellen Alltag.

Voiceover: In der heutigen Folge spreche ich mit meinem Kollegen Clemens Hübner über das Thema Threat Modeling.

Voiceover: Clemens ist Security Engineer und er beschäftigt sich viel mit diesem Thema.

Voiceover: Beim Threat Modeling geht es darum, sich Gedanken über mögliche Bedrohungsszenarien

Voiceover: zu machen, um angemessen darauf vorbereitet zu sein.

Voiceover: Man spielt also hypothetische Szenarien durch und prüft, wie gefährlich diese

Voiceover: für das eigene System sind. In unserem Gespräch unterhalten wir uns darüber,

Voiceover: wie so etwas generell funktioniert und mit welchen methodischen Ansätzen in

Voiceover: der Praxis gearbeitet wird.

Voiceover: Und jetzt wünsche ich euch viel Spaß beim Zuhören.

Wolfgang: Hallo Clemens, ich freue mich, dass wir uns heute schon zum zweiten Mal hier

Wolfgang: im Podcast unterhalten, oder? Ich glaube, ich habe Bericht mitgezählt.

Gast: Ja, ich war einmal schon da, genau.

Wolfgang: Genau. Das Thema ist immer noch relevant bzw. der Themenkomplex.

Wolfgang: Es geht um Security. Das ist immer noch ein sehr, sehr wichtiges Thema.

Wolfgang: Bevor wir uns aber mit Security beschäftigen, würde ich mich erstmal gern mit dir beschäftigen.

Wolfgang: Clemens, kannst du dich mal ganz kurz vorstellen, wer bist du,

Wolfgang: was machst du bei InnoVex, wie lange bist du schon bei InnoVex?

Gast: Ja, gerne. Hallo Wolfgang. Ich bin Clemens. Ich bin jetzt seit fast sechseinhalb Jahren bei InnoVex.

Gast: Ich bin hier als Software Security Engineer.

Gast: Das heißt, ich begleite unsere Entwicklungsprojekte, all die unterschiedlichen

Gast: Sachen, die wir für unsere Kunden bauen und betreiben und schaue,

Gast: dass das immer angemessen sicher ist.

Gast: Inzwischen gar nicht mehr so viel in entwickelnden Rollen, sondern mehr in beratenden

Gast: und ausbildenden Rollen bei unseren Kunden, teilweise auch die,

Gast: die sich dafür interessieren, wie können denn unsere eigenen Teams irgendwie

Gast: sichere Software entwickeln.

Gast: Und ja, das mache ich so den ganzen Tag.

Wolfgang: Klingt sehr spannend. Genauso spannend klingt natürlich auch unser heutiges

Wolfgang: Thema und zwar Threat Modeling.

Wolfgang: Ich muss ehrlich sein, das ist ein Begriff, den ich schon ab und an mal gelesen habe.

Wolfgang: Also wenn man so Technik News liest, Technik Nachrichten, dann sieht man den immer wieder mal.

Wolfgang: Aber ich würde mich freuen, wenn du den vielleicht mal vernünftig definieren könntest.

Wolfgang: Was bedeutet eigentlich Threat Modeling?

Gast: Ja, das ist ein Begriff, den sieht man immer wieder. Das ist jetzt auch nichts

Gast: Neues, nicht so brandneuer,

Gast: geiler Scheiß, den du ja sonst oft im Podcast hast, sondern eigentlich etwas,

Gast: was schon sehr etabliert ist, aber das in den letzten Jahren immer wichtiger

Gast: wird und immer öfter auch wieder Relevanz erlangt.

Gast: Deswegen glaube ich, es ist ganz praktisch, wenn wir da heute mal drüber sprechen.

Gast: Ja, was ist Thread Modeling? Also Thread Modeling, ganz wichtig, Thread mit T.

Gast: Es geht um Threads, um Gefahren.

Wolfgang: Nicht um die Fäden.

Gast: Nein, also genau. Keine Strickmaschinen heute.

Wolfgang: Schade, schade.

Gast: Sondern genau, es geht um Gefahren und also Bedrohungsanalyse,

Gast: Bedrohungsmodellierung wäre so die beste deutsche Übersetzung.

Gast: Und der Gedanke dahinter ist, ich baue irgendwie eine Software,

Gast: ich baue irgendein System und ich möchte das angemessen sicher machen.

Gast: Und um zu wissen, was angemessene Sicherheit überhaupt bedeutet,

Gast: muss ich mir halt irgendwie Gedanken machen, was kann denn überhaupt aus Security-Sicht passieren?

Gast: Was sind überhaupt die Gefahren, die Angreifer, die Probleme,

Gast: die aus einer Security-Perspektive auftreten können?

Gast: Und sich quasi aus dieser Bedrohungssicht zu nähern und zu überlegen,

Gast: gegen was muss ich mich genau schützen und mache ich das schon ausreichend oder

Gast: habe ich dann noch irgendwie ein Delta, das ich abdecken muss?

Gast: Das versteht man unter Threat-Modeling.

Wolfgang: Okay, das bedeutet, ich habe ein System und ich versetze mich jetzt in die Rolle

Wolfgang: von irgendwelchen potenziellen Angreifern und überlege mir, okay,

Wolfgang: was könnte ich hier machen?

Wolfgang: Wo könnte ich vielleicht mal ansetzen, um so ein System irgendwie zu stören

Wolfgang: oder zu kompromittieren und überprüfe dann, ob mein System fit genug ist,

Wolfgang: um so einer Gefahr oder so einem Angriff irgendwie standzuhalten.

Gast: Ganz genau. Und dann kann man halt auch die passenden Security-Aktivitäten,

Gast: Maßnahmen, Tools auswählen, die dann auf die entsprechenden Bedrohungen abgestimmt

Gast: sind und genau das verhindern, was man eben verhindern möchte.

Wolfgang: Der Begriff, der wird ja in letzter Zeit häufiger verwendet,

Wolfgang: das habe ich ja gerade schon gesagt, also ich habe ihn häufiger wahrgenommen

Wolfgang: irgendwo, aber ich glaube, so ein Prinzip ist doch sicherlich schon ein bisschen älter, oder?

Gast: Ja, das ist schon relativ alt. Ich glaube, in den 70ern gab es da die ersten

Gast: Methoden, die so in die Richtung vom Threadmodeling gingen.

Gast: Richtig groß wurde das dann, glaube ich, so in den 90ern, Ende der 90er, Anfang 2000er.

Gast: Viel so aus dem Microsoft-Umfeld. Die haben da viel auch so Methodiken und Frameworks

Gast: publiziert, die auch heute noch viel benutzt werden, wo wir nachher bestimmt drüber reden wollen.

Gast: Und seitdem ist das einfach eine etablierte Methodik, die erstmal unabhängig

Gast: ist davon, was baue ich jetzt genau.

Gast: Das kannst du genauso einwenden, wenn du irgendwie eine Web-Anwendung baust,

Gast: wie wenn du irgendwie einen Mikrocontroller baust und da irgendwie Software drauf schreibst.

Gast: Also es ist eigentlich für jede Art von Software oder sogar System irgendwie

Gast: nutzbar, deswegen auch schon immer relevant und in den letzten Jahren eben durch

Gast: die steigende Bedrohungslage generell und das steigende Bewusstsein dafür,

Gast: dass Security was ist, was man von Anfang an am besten im Entwicklungsprozess

Gast: macht und was man nicht am Ende reintesten kann, wird Threadmodeling halt auch

Gast: wieder interessanter, weil es eben eine proaktive Aktivität ist.

Gast: Das heißt, ich kann das machen, bevor ich die erste Zeile Code überhaupt geschrieben

Gast: habe, so quasi während der Architektur, während dem Design von meinem System,

Gast: aber natürlich auch währenddessen oder später, um zu schauen,

Gast: was habe ich schon, wie passt das auf die Bedrohung.

Gast: Aber der grundsätzliche Gedanke ist, wir wollen quasi schneller sein als der

Gast: Angreifer oder wir wollen antizipieren, was ein Angreifer machen kann und uns

Gast: gegen die Bedrohungen, die daraus resultieren, eben vorherrschen.

Wolfgang: Das geht ja dann auch ein bisschen so in die Richtung von so einer klassischen Risikoanalyse, oder?

Gast: Genau, Risikoanalyse wäre so, dass quasi, wenn man es über reine Security Threats

Gast: hinaus erweitern würde und wenn du irgendwie auch Risiken betrachtest,

Gast: wie meine Entwicklermannschaft kündigt, alle gesammelt, das wäre dann eher so

Gast: ein klassisches IT-Risiko, Organisationsrisiko,

Gast: das jetzt nicht unbedingt was mit einem Security-Angreifer zu tun hat,

Gast: aber die Ansätze sind ganz ähnlich, genau.

Gast: Ich mache mir Gedanken, was kann passieren, was habe ich für Risiken,

Gast: für Threats, wie bewerte ich die, was haben die für einen Einfluss,

Gast: für eine Auswirkung und was kann ich passendes dagegen machen.

Wolfgang: Du hast es gerade schon erwähnt, dass es da etablierte Methoden gibt,

Wolfgang: wie man an sowas herangeht.

Wolfgang: Das wäre jetzt auch meine Frage gewesen, denn letztendlich hat man vielleicht

Wolfgang: so die Kreativität, um sich jetzt hineinzuversetzen in irgendwelche böswilligen Angreifer.

Wolfgang: Aber sowas kann ja nicht nur abhängig sein von der individuellen Kreativität

Wolfgang: oder Vorstellungskraft, denn wenn man jetzt eine vernünftige,

Wolfgang: in Anführungszeichen, Sicherheit erreichen möchte für sein System,

Wolfgang: dann ist natürlich eine Methodik sicherlich sehr, sehr hilfreich.

Wolfgang: Wie kann man sich dann sowas vorstellen, so eine Herangehensweise?

Gast: Ja, genau. Das versucht Threat Modeling eben auch, dass man wegkommt von so

Gast: einem Bauchgefühl oder von so einem Best-Effort-Security und so einen systematischen

Gast: Ansatz hat, der eben versucht,

Gast: Gesamtes System und alle möglichen Bedrohungen, an die man irgendwie so denken kann, abzudecken,

Gast: auch damit man als EntwicklerIn am Ende oder als insgesamt am Projekt Beteiligte

Gast: am Ende auch so ein bisschen so ein Peace of Mind hat, dass man so ein gutes

Gast: Gefühl hat, man hat jetzt auch wirklich das systematisch betrachtet, an alles gedacht,

Gast: was man eben gerade so bedenken kann und jetzt dann auch irgendwie einen Stand,

Gast: mit dem man gut arbeiten kann.

Gast: Und dafür gibt es so ein paar Frameworks, sage ich mal, die einem helfen,

Gast: dass man da so eine gewisse Vollständigkeit betrachtet.

Gast: Aber so das ganz grundsätzliche Prinzip von Threat Modeling,

Gast: da gibt es ein berühmtes Four-Question-Framework, also super simple,

Gast: sind vier Fragen, die eben so den ganz klassischen normalen Threat Modeling-Prozess abdecken.

Gast: Geht los mit was bauen wir eigentlich also dass man sich noch

Gast: mal vergegenwärtigt ja was wie schaut unser

Gast: system überhaupt aus was machen wir hier eigentlich genau was für

Gast: beteiligte komponenten haben wir das vielleicht mal aufmalt und sich gedanken

Gast: macht wo fließen da irgendwie daten von a nach b wer wer kümmert sich um was

Gast: wo sind vielleicht auch trust boundaries also wo sachen irgendwie innerhalb

Gast: unserer verantwortung sind und sachen die außerhalb unserer verantwortung sind,

Gast: also ein Frontend, das beim Nutzer läuft zum Beispiel, hat eine andere Stellung

Gast: als irgendwas, was bei uns auf unserer Maschine im Rechenzentrum läuft.

Gast: Also das sich mal zu vergegenwärtigen, was haben wir für Komponenten,

Gast: wie arbeiten die zusammen, das ist so der erste Schritt.

Gast: Der zweite Schritt ist dann so die eigentliche Bedrohungsanalyse,

Gast: also sich zu überlegen, was kann denn jetzt genau passieren,

Gast: also was sind die Bedrohungen, die möglichen Angriffe auf diesen Komponenten.

Gast: Und wenn man das vorher schon mal so ein bisschen runtergebrochen hat und nicht

Gast: mehr noch eine große Blackbox hat, sondern schon so ein bisschen die einzelnen

Gast: Komponenten, dann kann man sich für jede Komponente eben überlegen,

Gast: was gibt es da für Bedrohungen.

Gast: Da gibt es auch ein Framework für, das machen wir gleich. Ich mache mal noch

Gast: kurz die vier Fragen zu Ende.

Gast: Wenn man die Bedrohungen dann einmal hat und das ist eigentlich auch so der

Gast: kniffligste Teil, dann wird es schon fast einfach, weil wenn ich weiß,

Gast: gegen was ich mich schützen will, dann kann ich mir in der dritten Frage dann

Gast: eben überlegen, was mache ich jetzt dagegen?

Gast: Und wenn man eigentlich das Problem mal verstanden hat, dann ist die Lösung

Gast: eigentlich relativ einfach.

Gast: Das heißt, da kann man dann die passgenauen Lösungen finden.

Gast: Und der vierte Schritt oder die vierte Frage in diesem klassischen Framework

Gast: ist dann der Blick zurück.

Gast: Did we do a decent job? Also sich zu überlegen, was haben wir jetzt gemacht?

Gast: Hatte das eine positive Auswirkung auf unsere Security-Oberfläche?

Gast: Und wie können wir jetzt hier weitermachen? selten ist man dann einfach wirklich

Gast: fertig und hat alles überlegt, sondern man überlegt sich dann ja,

Gast: wann muss man uns das vielleicht das nächste Mal wieder anschauen oder wann

Gast: ändert sich da vielleicht was? Das sind so die vier klassischen Fragen.

Wolfgang: Okay, das heißt mit diesem Four-Question-Framework verschaffst du dir erstmal einen Überblick.

Wolfgang: Du verschaffst den Überblick über dein System, schaust, was es da für Komponenten

Wolfgang: gibt, was es da für Schnittstellen vielleicht gibt,

Wolfgang: Etc. Und du analysierst auch oder listest irgendwo auf,

Wolfgang: wo potenzielle Gefahren auftreten können oder was potenzielle Gefahren sind,

Wolfgang: um auf Basis von dem dann Maßnahmen zu treffen oder Entscheidungen zu treffen,

Wolfgang: wie man dagegen vorgehen kann oder wie man sich da schützen kann.

Wolfgang: Genau.

Wolfgang: Das und das und das und das passieren, das weiß man ja, wenn man sich damit auskennt.

Wolfgang: Und jemand anderes, der diese spezielle Expertise vielleicht nicht mitbringt,

Wolfgang: würde vielleicht ein paar andere Sachen sagen und manche nicht sagen oder nicht

Wolfgang: dran denken, weil er oder sie das halt einfach nicht im Kopf hat.

Gast: Ja, absolut. Das ist schon auch so der kritischste Punkt, so diese zweite Frage,

Gast: was kann denn jetzt genau passieren? Das ist auch das, wo oft irgendwie so ein

Gast: bisschen die Erfahrung oder die Expertise in den Teams fehlt und wo es dann

Gast: wertvoll ist, wenn da jemand mit dabei ist, der die Perspektive ein bisschen geben kann.

Gast: Es gibt aber so ein paar Hilfsmittel, wie man das zumindest ein bisschen runterbrechen

Gast: kann oder vereinfachen kann. Und eins davon ist zum Beispiel das Stride-Framework, S-T-R-I-D-E.

Gast: Also es sind sechs Buchstaben, ein Akronym. Und jeder von diesen sechs Buchstaben

Gast: im Wort Stride steht für eine Klasse von Angriffen, die man sich dann eben überlegen kann.

Gast: Also zum Beispiel das S steht für Spoofing. Also immer dann,

Gast: wenn quasi ein Angreifer irgendwie die Identität von jemand anderem annehmen

Gast: kann oder sich als jemand anderes ausgeben kann.

Wolfgang: Hast du da ein Beispiel dafür?

Gast: Ja, zum Beispiel irgendwie schaffe es, mich unter deinem Login irgendwie auf

Gast: einer Webseite anzumelden, weil ich dein Passwort zum Beispiel irgendwie erraten

Gast: habe, weil du ein zu leichtes Passwort gesetzt hast, weil die Webseite dich

Gast: nicht gezwungen hat, ein sicheres Passwort zu setzen zum Beispiel.

Gast: Das wäre so eine Möglichkeit für einen Angriff, der jetzt eben in diese Spoofing-Kategorie fällt.

Gast: Das heißt, man kann sich überlegen, an welcher Stelle glauben wir dann irgendwie

Gast: an eine Identität oder irgendwie an eine Authentifizierung von einem Nutzer

Gast: und was kann da jeweils passieren?

Gast: Also vielleicht, wenn man das sogar nochmal ein bisschen leichter macht,

Gast: haben wir irgendwie eine API, die überhaupt nicht authentifiziert ist,

Gast: wo wir einfach jedem glauben, der da hinkommt, dass er das darf und so.

Gast: Dann wäre das so ein ganz klassischer Spoofing-Angriff, wo ein Angreifer sich

Gast: eben nicht mal als jemand anders ausgeben kann, sondern einfach als jeder ausgeben kann.

Gast: Und das wäre dann sowas, was man dann eben in seinem System identifizieren kann.

Wolfgang: Ja, dann lass uns doch mal durch die ganzen restlichen Buchstaben durchgehen.

Wolfgang: Das heißt Stride, das nächste wäre das T.

Gast: Gerne, ja. Das T steht für Tampering, also für das Manipulieren von Daten,

Gast: das Verfälschen von Daten.

Gast: Also das ist immer dann relevant, wenn man irgendwie eine Datensenke hat zum

Gast: Beispiel, wo man irgendwie Daten speichert, eine Datenbank zum Beispiel.

Gast: Dass man sich überlegt, wie stellen wir dann sicher, dass die Daten da nicht

Gast: irgendwie ungerechtfertigt verändert werden oder auch unterwegs zwischen unserem

Gast: Freundin und unserem Backend.

Gast: Und wie stellen wir sicher, dass sich da niemand einklingt und die Daten irgendwie

Gast: verändert, was man dann zum Beispiel mit HTTPS irgendwie erlösen würde.

Gast: Aber das kann man sich dann quasi auch für die einzelnen Komponenten überlegen.

Gast: Wo haben wir hier irgendwie Daten?

Gast: Wo wir darauf vertrauen, dass die nicht geändert werden? Und was hat denn Angreifer

Gast: hier für Möglichkeiten, die doch zu verändern?

Wolfgang: Also wenn ich, keine Ahnung, beispielsweise einen Online-Shop habe,

Wolfgang: ich wähle einen Artikel aus und ich möchte den hinzufügen zum Warenkorb,

Wolfgang: dass jetzt nicht über die API auch noch der Preis durchgegeben wird und ich

Wolfgang: den jetzt im Browser manipulieren könnte und sagen könnte, ah,

Wolfgang: das neue Laptop kostet jetzt minus 100 Euro und ich dann noch eine Gutschrift bekomme.

Gast: Ja, auch ein schönes Beispiel, genau. Noch ein bisschen spezifischer,

Gast: wo man dann auch ein bisschen die Kreativität mit reinbringen kann,

Gast: dass man solche Sachen denkt. Aber genau solche Sachen können da auch mit reinfallen.

Wolfgang: Dann hätten wir R wie Richard.

Gast: Richard, genau. Oder R wie Repudiation, ein schwieriges Wort.

Wolfgang: Kannst du es nochmal kurz sagen, bitte?

Gast: Repudiation.

Wolfgang: Ab jetzt nicht mehr. Ich werde es nicht versuchen, weil ich bin sicher,

Wolfgang: ich werde auch daran scheitern. Was bedeutet das?

Gast: Repudiation steht quasi für Abstreitbarkeit. Also ein Angreifer kann,

Gast: wenn man jetzt zum Beispiel bei deinem Webshop-Szenario bleibt,

Gast: irgendwie später abstreiten, dass er eine Sache überhaupt gekauft hat oder dass

Gast: etwas mit in seinem Warenkorb war, als er bestellen geklickt hat zum Beispiel.

Gast: Kann aber auch irgendwie allgemeinere Sachen sein, dass man später nicht nachvollziehen

Gast: kann, was ein Angreifer genau im System gemacht hat oder dass man nicht weiß,

Gast: wo sind denn diese Datenbankzeilen hingekommen, die da irgendwie weg sind.

Gast: Also was dann oft an irgendwie fehlendem Logging oder so liegt.

Wolfgang: Also das ist das.

Gast: Was unter dem R wie Repudiation letztes Mal steht.

Wolfgang: Ja, und da wäre dann gerade sowas wie Logging oder so ein Audit-Log das Mittel

Wolfgang: der Wahl, um da die Sicherheit zu bekommen darüber, was im System passiert.

Gast: Das wäre so eine klassische Gegenmaßnahme, genau, ja.

Wolfgang: Dann hätten wir noch das I wie IGL.

Gast: I wie Information Disclosure.

Wolfgang: Oder so. Genau.

Gast: Also Information Disclosure, glaube ich, ist recht offensichtlich.

Gast: Irgendwie Informationen werden öffentlich oder kommen, werden irgendwelchen

Gast: Leuten zugänglich, die da nicht drauf zugreifen dürfen.

Gast: Also Verletzung der Vertraulichkeit von Informationen.

Gast: Jemand darf Daten lesen, Informationen lesen, die er nicht lesen kann.

Gast: Also zum Beispiel, du kannst sehen, was ein anderer Nutzer für Bestellungen

Gast: in dem Webshop gemacht hat.

Wolfgang: Ja, ich glaube, da gab es mal vor einigen Jahren so einen Fall.

Wolfgang: Ich weiß nicht mal, welcher Dienstleister das war.

Wolfgang: Aber da konnte man sich auch so

Wolfgang: Bestellbestätigung oder so Tracking-Informationen im Internet anschauen.

Wolfgang: Und ich glaube, diese Links hatten irgendwo so eine fortlaufende Nummer.

Wolfgang: Man konnte halt sehr, sehr leicht erraten, was jetzt der nächste gültige Link

Wolfgang: ist und konnte dann Adressdaten abgreifen etc.

Gast: Ja, klassisches Beispiel dafür, genau. Das heißt, man überlegt sich halt,

Gast: wo haben wir irgendwie Daten, die relevant sind, Daten, die vielleicht auch

Gast: sensibel sind und wie stellen wir eigentlich sicher, dass dann nur derjenige

Gast: darauf zugreifen kann, der dazu berechtigt ist.

Wolfgang: Das nächste ist D wie wahrscheinlich Data oder Data.

Gast: Nee, Denial of Service versteckt sich dahinter als Threat, genau.

Gast: Also ja, die Einschränkung der Verfügbarkeit.

Gast: Jetzt in unserem Webshop-Beispiel zum Beispiel, man kann überhaupt keine Sachen

Gast: mehr bestellen, weil der Service, der sich um den Bezahlvorgang kümmert,

Gast: komplett überlastet ist.

Gast: Also das ist dann das, ja, was zum Beispiel irgendwie durch DDoS-Attacken zum

Gast: Beispiel irgendwie passieren kann.

Gast: Kann aber auch vielleicht im kleineren Rahmen passieren, dass irgendwie einfach

Gast: die Verteilung der Ressourcen in meinem Cluster so schlecht gewählt ist, dass das quasi,

Gast: dass das nicht zusammenpasst und wenn da viele Nutzer kommen und dann gibt es

Gast: doch irgendwie ein Bottleneck beim Zugriff auf die Datenbank,

Gast: dessen Angreifer dann außen nutzen kann, dann wäre das sowas,

Gast: was man sich bei der Kategorie überlegen könnte.

Wolfgang: Und last but not least hätten wir noch E wie Elevation of Privilege.

Gast: Ui, genau. Also der Angreifer schafft es, irgendwie mehr Rechte zu erlangen

Gast: oder mehr Aktionen zu machen, als er eigentlich berechtigt ist.

Gast: Das heißt, er hat vielleicht eine bestimmte Rolle oder vielleicht hat er auch

Gast: noch keine Rolle, aber er schafft es irgendwie, eine Autorisierung zu umgehen

Gast: und irgendwelche Aktionen durchzuführen, die er nicht darf.

Gast: Zum Beispiel irgendwie auf eine Admin-Oberfläche zuzugreifen,

Gast: obwohl er kein Admin ist, weil wir die nur hinbekommen.

Gast: Hinter der URL slash Admin versteckt haben, in der Hoffnung,

Gast: dass sie da schon niemand findet.

Wolfgang: Also es ist auch sehr unwahrscheinlich, dass da jemand draufkommt.

Wolfgang: Aber vielleicht können wir gerade mal das E nochmal als weiterführendes Beispiel nehmen.

Wolfgang: Du hast gesagt, es geht um die Bedrohung, dass jemand jetzt irgendwelche Rechte

Wolfgang: erlangt in einem System, die ihm nicht zustehen.

Wolfgang: Wenn ich jetzt so dran denke, ich bin der Entwickler und ich mache vielleicht

Wolfgang: so einen Check und habe dann vielleicht sowas wie diese Admin-Oberfläche,

Wolfgang: die jetzt einfach so erreichbar ist, wenn man die URL kennt.

Wolfgang: Ich glaube, das ist so naheliegend, aber es kann im System ja auch irgendwelche

Wolfgang: anderen Möglichkeiten geben, wo ich mit meinem Login dann irgendwas mache,

Wolfgang: mit dem ich dann vielleicht so ein Admin-Privileg irgendwie bekomme.

Wolfgang: Und das ist doch schon ganz schön kompliziert, da drauf zu kommen, oder?

Wolfgang: Also wenn ich jetzt so der Security-Profi bin, was ich nicht bin,

Wolfgang: aber einer sitzt ja gegenüber von mir.

Wolfgang: Ich frage mich, ich habe dieses Akronym, dieses Stride und das gibt mir einen

Wolfgang: ganz guten Pointer und ich habe jetzt irgendwie meine zwölf Komponenten von

Wolfgang: meinem System und ich schaue mir jede Komponente an.

Wolfgang: Ich spreche mit meinen Kollegen, sage, hey, was habt ihr da vielleicht noch

Wolfgang: für Ideen oder seht ihr da ein Risiko?

Wolfgang: Wir finden wahrscheinlich viel, aber ich glaube,

Wolfgang: manche Sachen, da braucht man halt dann doch diese Erfahrung vielleicht aus

Wolfgang: einem alten Projekt oder vielleicht aus einer bekannten Sicherheitslücke,

Wolfgang: wo man sich mit beschäftigt hat, um drauf zu kommen, dass man sagt, hey,

Wolfgang: wenn wir hier im Login noch irgendwie ein bisschen SQL-Code mit reingeben und

Wolfgang: machen eine SQL-Injection, dann schaffen wir es vielleicht oder so.

Wolfgang: Also wie schafft man es, dorthin zu kommen?

Gast: Ja, guter Punkt, genau. Also Stride hilft schon so ein bisschen,

Gast: dass man ein bisschen mehr Anhaltspunkte hat als nur, was kann denn jetzt hier

Gast: so passieren, indem es ein bisschen aufteilt. Aber wenn man noch nie von SQL

Gast: Injection gehört hat zum Beispiel, dann wird es schwierig, da dran zu denken.

Gast: Selbst wenn man jetzt irgendwie weiß, ich muss mich hier irgendwie um.

Gast: Irgendwelche Rechte und Rollen irgendwie kümmern, was man mit einer SQL Injection

Gast: vielleicht umgehen könnte und so.

Gast: Das stimmt, das ist schwierig. Das ist zum einen dann was, was mit der Erfahrung

Gast: kommt oder wo es dann halt doch hilft, wenn man jemanden mit dabei hat,

Gast: der vielleicht das schon ein paar Mal gemacht hat oder ein bisschen Security-Hintergrund hat.

Gast: Auch hilft, um so ein bisschen, ja, Ansatzpunkte zu geben, was für Threads gibt es.

Gast: Es gibt eine Reihe von schönen Thread-Modeling-Kartenspielen, die.

Gast: Eins heißt zum Beispiel Elevation of Privilege, eben weil es aus dem Umfeld

Gast: kommt, die dann auf jeder Karte quasi eine konkrete Thread haben,

Gast: zum Beispiel ein Angreifer kann SQL-Code einschmuggeln, um irgendwie einen Login

Gast: zu umgehen zum Beispiel.

Gast: Die gibt es für für unterschiedlichste Arten und Systeme.

Gast: Es gibt auch noch eins, das extra irgendwie für Cloud-Infrastrukturen gedacht ist.

Gast: Ovasp Cumulus heißt es. Es gibt eins, das ist extra für Web-Anwendungen.

Gast: Auch von der Ovasp Chronokopia heißt es.

Gast: Und das ist zum einen ganz nett, weil man das Ganze ein bisschen spielerischer

Gast: angehen kann. Man hat da so ein kleines Kartenspiel drumherum,

Gast: das man im Team gemeinsam spielen kann.

Gast: Vor allem sind das aber dann halt ganz konkrete Threads pro Karte,

Gast: die man dann ganz genau überlegen kann. Also das ist so ein Ansatz,

Gast: der hilft, wenn einem die Vorstellung fehlt.

Gast: Wenn man aber noch völlig blank ist, sage ich mal, und noch überhaupt keine

Gast: Ahnung hat und das Team überhaupt keine eigene Security-Expertise ist,

Gast: dann würde ich einfach mal schauen, ob ich vielleicht im Nachbarteam oder irgendwie

Gast: bei jemandem, den ich kenne,

Gast: irgendwie noch einen Security-Experten, eine Security-Expertin irgendwie finde,

Gast: die mich da unterstützen kann. Sonst wird es, glaube ich, schwierig.

Wolfgang: Benutzt du solche Kartenspiele für deine Projekte, für deine Arbeit?

Gast: Ja, hin und wieder spielen wir das mal.

Gast: Oft dann eher so im Rahmen von einem Team-Tag oder einem Team-Event,

Gast: wenn man mal ein bisschen Zeit hat, mal auch andere Sachen auszuprobieren.

Gast: Jetzt so auf einer regelmäßigen Basis nicht, aber dafür haben meine Teams ja

Gast: auch zum Beispiel mich mit drin, dass wir auf andere Art und Weise Threat-Modeling machen können.

Gast: Aber ja, das macht durchaus Sinn, das mal auszuprobieren und einfach mal einen

Gast: anderen Aufhänger zu haben für das Thema.

Gast: Gerade wenn man jetzt Threadmodeling öfter macht und sich immer wieder damit

Gast: beschäftigt, dann kommt man ja doch immer mal wieder in so wiederholende Fragen

Gast: oder man überlegt sich dann nur noch für die paar Sachen, die sich vielleicht verändert haben,

Gast: was jetzt die veränderte Bedrohungslage ist.

Gast: Und dann hilft es, wenn man mal einfach einen ganz anderen Blick drauf wirft.

Gast: Und dafür sind diese Kartenspiele auch ganz nett.

Wolfgang: Ja, das kann ich mir gut vorstellen. Das sind halt einfach dann auch so schöne

Wolfgang: Impulse, die dich dann vielleicht auch ein bisschen rausholen aus deinem Alltag

Wolfgang: und dir dann einfach vielleicht mal den einen oder anderen neuen Gedanken geben,

Wolfgang: wo du mal drüber nachdenken kannst.

Wolfgang: Und manche sind ja vielleicht dann auch einfach irrelevant, also irgendwelche

Wolfgang: SQL-Geschichten, wenn du keine Datenbank hast, aber andere bringen dich dann

Wolfgang: ja vielleicht auch zum Nachdenken und dann hat es ja auch einen positiven Effekt.

Gast: Total.

Wolfgang: Clemens, du hast ja schon viel erzählt über Teams, mit denen du arbeitest oder

Wolfgang: in denen du arbeitest, wo du mit deiner Security-Expertise einfach mithilfst,

Wolfgang: dass die Dinge sicherer und besser werden in der Hinsicht.

Wolfgang: Wie kann ich mir so diesen Arbeitsalltag in deiner Rolle als Security-Engineer

Wolfgang: oder als Threat-Modeler denn vorstellen?

Wolfgang: Du hast ganz am Anfang gesagt, man sollte sich diese Gedanken schon machen,

Wolfgang: bevor man vielleicht irgendwie eine Implementierung anfertigt.

Wolfgang: Aber wenn du mal vielleicht ein bisschen beschreiben könntest aus den letzten

Wolfgang: Projekten, die du hattest, wahrscheinlich an manche Anfang an angefangen,

Wolfgang: vielleicht wurden andere Dinge einfach weiterentwickelt.

Wolfgang: Welche Rolle hat denn da Threat Modeling gespielt und wie bist du denn da so vorgegangen?

Gast: Ja, also das ist natürlich manchmal auch so ein bisschen Wunschdenken,

Gast: dass man das wirklich von Anfang an macht.

Gast: Oft, gerade wenn man irgendwie einen MVP entwickelt oder so,

Gast: liegt da die Priorität am Anfang doch irgendwie auf anderen Sachen und man startet

Gast: dann vielleicht doch nicht ganz auf der grünen Wiese.

Gast: Aber das ist auch okay, ist trotzdem immer noch wertvoll.

Gast: Third Modeling ist halt eine Aktivität im Entwicklungsprozess und die hat so

Gast: zwei ganz wichtige Komponenten.

Gast: Das eine ist so, was wir jetzt gerade gemacht haben, die Teams beschäftigen

Gast: sich wirklich mal mit den konkreten Bedrohungen, die für sich relevant sind

Gast: und überlegen, was davon haben sie schon abgedeckt und was nicht.

Gast: Das andere ist aber auch, dass es halt einfach eine super Möglichkeit ist,

Gast: sich überhaupt mal irgendwie über Security zu unterhalten und auch einen Austausch im Team zu haben.

Gast: Also wenn ich das mit Teams mache, dann versuche ich da immer möglichst das

Gast: ganze Team und vielleicht auch noch irgendwie den Product Owner,

Gast: der sonst gar nicht so viel mit denen abhängt, mit reinzuholen.

Gast: Vielleicht auch noch irgendwelche anderen Stakeholder, damit einfach mal alle

Gast: zusammen an einem Tisch sitzen und mal ein gemeinsames Bild irgendwie darauf

Gast: haben, was glauben wir denn überhaupt, was sind zum Beispiel Angreifer,

Gast: gegen wen müssen wir uns denn eigentlich schützen? Was ist denn genau unser Business-Modell?

Gast: Mit was verdienen wir denn unser Geld? Was würde uns denn wehtun,

Gast: wenn das irgendwie nicht mehr funktioniert oder so?

Gast: Und die Entwickler halt auch mal sich untereinander austauschen.

Gast: Ja, was haben wir denn vielleicht schon? Wie funktioniert das denn?

Gast: Unsere Authentifizierung, das steht irgendwie von Anfang an,

Gast: da habe ich noch nie mitgearbeitet. Wie funktioniert das denn,

Gast: dass man da so einen Austausch hat?

Gast: Also es hat schon auch viel einfach Wissensweitergabe-Funktion und einen Austausch zur Security.

Gast: Wenn ich das jetzt gerade bei dem einen Kunden, den ich gerade betreue,

Gast: da versuchen wir gerade die vielen Entwicklungsprojekte, die da existieren,

Gast: auf den gemeinsamen Stand zu bringen und gemeinsame Aktivitäten einzuführen,

Gast: auch so den gesamten Entwicklungsprozess abzudecken, dann ist das,

Gast: wenn man halt quasi in der Designphase von so einem Entwicklungsprozess ist,

Gast: halt eine sehr gute Möglichkeit, um das aus der sehr praktischen Sicht schon

Gast: zu verankern, wenn man sich irgendwie neue Features überlegt,

Gast: dass man dafür dann vielleicht auch noch, man muss nicht immer gleich das ganze

Gast: System-Thread-Modeln, sondern vielleicht auch nur eine einzelne Story,

Gast: ein einzelnes Feature, das als nächstes kommt, sich dafür zu überlegen.

Gast: Also das ist auch so eine Stelle, wo ich das dann versuche zu platzieren.

Wolfgang: Also würdest du sagen, so einen klassischen Entwicklungsprozess,

Wolfgang: der ja oftmals irgendwie auch so iterativ erfolgt bei uns in der Softwarebranche,

Wolfgang: dass das dann auch Teil von so einem Sprint oder von so einer Feature-Entwicklung

Wolfgang: sein kann, dass man, oder sollte vielleicht auch, Fragezeichen,

Wolfgang: dass man sich da auch diese Fragen stellt, wenn man was verändert oder was hinzufügt,

Wolfgang: wie es denn da jetzt spezifisch aussieht?

Gast: Ja, total. Also wenn man das so im Kleinen macht für eine Story,

Gast: dann muss man jetzt nicht groß ganzes Stride durchexerzieren vielleicht und

Gast: nicht nochmal alles neu aufmalen, sondern sich halt genau für das überlegen,

Gast: was kann denn da jetzt schief gehen und gerade wenn man schon ein bisschen Erfahrung

Gast: gesammelt hat damit und schon weiß, für jede neue Funktion brauchen wir irgendwie eine neue Rolle.

Gast: Und dann müssen wir damit sicherstellen, dass wir die hier auch mit bedenken

Gast: oder so, dass man das da schon mit reinbekommt.

Gast: Dann, genau, kann man das auch sehr gut für iterative Entwicklung benutzen.

Gast: Man muss da halt so ein bisschen aufpassen, dass man dann nicht trotzdem mal

Gast: das große Ganze aus den Augen verliert.

Gast: Also wenn man immer nur die kleinen Storys irgendwie betrachtet und sich überlegt, was da passiert,

Gast: dann ist vielleicht dann am Ende das Zusammenspiel von mehreren Features oder

Gast: vielleicht auch von mehreren Teams, wenn man irgendwie an einem größeren System

Gast: arbeitet, was irgendwie gerade dann Angriffe möglich macht.

Gast: Das heißt, da hilft es dann, wenn man auch immer mal wieder sich das Gesamtsystem

Gast: anschaut und vielleicht doch mal so eine Gesamt-Threat-Modeling-Session macht.

Gast: Also es gibt da so unterschiedliche Ansätze, ob man quasi nach jedem Sprint

Gast: oder vielleicht auch nur nach jedem zweiten, dritten, vierten,

Gast: wie auch immer, eine kleine Session macht und aufbauend auf dem.

Gast: Man muss ja nicht jedes Mal wieder alles neu malen und von neu anfangen,

Gast: aber sich da nochmal weiter dran arbeiten.

Gast: Aber halt auch so auf dieser Story-Ebene finde ich das auch ganz wertvoll,

Gast: wenn man sich das halt so im Kleinen überlegt und dann ergänzt sich das ganz gut.

Wolfgang: Das klingt für mich aber schon so, als ob man dann in so einem Projekt auch

Wolfgang: mehr oder weniger zwingend jemanden bräuchte mit der nötigen Expertise,

Wolfgang: weil ich habe hier bei mir auf dem Zettel noch so ein paar Fragen an dich,

Wolfgang: weil es natürlich ein spannendes Thema ist und eine Frage wäre,

Wolfgang: wie kann man denn so diese, ich weiß nicht, diese Erfahrung oder vielleicht

Wolfgang: auch diese Verantwortung denn am besten in so einem Team unterbringen?

Wolfgang: Also du bist jetzt ein Security Engineer, du hast die Expertise,

Wolfgang: du kannst sie mit reinbringen, aber wie stark sollte die denn idealerweise auch

Wolfgang: bei den einzelnen Leuten stecken, die sich jetzt einfach um die Entwicklung kümmern?

Gast: Ja, das ist noch kein komplett gelöstes Problem.

Gast: Man hat lange Zeit versucht, diese fehlende Schnittstelle zwischen dem einen

Gast: Security-Experten oder der Security-Abteilung in einem Unternehmen und den Entwicklungsteams

Gast: durch Konzepte wie zum Beispiel Security-Champions zu lösen.

Gast: Also, dass man in jedem Team einen sogenannten Security Champion hat.

Gast: Der hat dann so einen virtuellen Hut auf quasi und hat dann irgendwie die Verantwortung

Gast: in dem Team, immer mal wieder Threat Modeling zu machen.

Gast: Dann schulen wir den vielleicht noch ein bisschen öfter oder bringen den zusammen,

Gast: dass er sich mit den anderen Security Champions austauscht und haben dann so

Gast: einen halben Experten quasi in jedem Team.

Gast: Das kann schon auch funktionieren. Ich sehe aber schon auch Unternehmen,

Gast: wo das nicht so gut klappt und höre auch davon, dass das nicht überall funktioniert.

Gast: Insbesondere dann, wenn halt zu viel an einer einzelnen Person hängt und sich

Gast: das nicht so in das Team rein multipliziert, wie man sich das eigentlich erhofft.

Gast: Also wenn es dann am Ende nur den einen gibt, der im Team quasi so alibimäßig

Gast: den Security-Hut aufhabt und die anderen denken, ja, das macht schon der eine,

Gast: wir brauchen uns da nicht drum kümmern, dann funktioniert das halt nicht.

Gast: Also am Ende muss Security halt schon irgendwie so eine Shared Responsibility im Team sein.

Gast: Das heißt nicht, dass jeder jetzt der Security-Experte werden muss,

Gast: aber dass man zumindest alle in der Lage hat,

Gast: dass sie zumindest grundlegende Sachen verstehen oder im Zweifel halt auch nur

Gast: erkennen, das ist jetzt halt so relevant, dass man vielleicht externe Hilfe dazu holen muss.

Gast: Das wäre eigentlich schon was, was man erreichen muss. Wenn man das über Security

Gast: Champions quasi als Multiplikatoren schafft in die Teams, dann kann das,

Gast: glaube ich, schon funktionieren.

Gast: Aber man darf sich da jetzt nicht zu sehr darauf verlassen, dass es quasi einen

Gast: gibt, der löst das schon und dann ist man da fein raus.

Wolfgang: Also ich finde den Punkt halt super spannend, weil ich habe ja auch schon so

Wolfgang: das ein oder andere Projekt miterlebt.

Wolfgang: Vielleicht eher das beides eine und das andere.

Wolfgang: Und solche Themen, die waren da ehrlich gesagt oft relativ stiefmütterlich.

Wolfgang: Manchmal gab es in Projekten Leute, die da dediziert irgendwie,

Wolfgang: ich weiß nicht unbedingt die Rolle hatten, aber vielleicht die Leidenschaft

Wolfgang: oder die Expertise hatten und dann da einfach stark drauf gepocht haben,

Wolfgang: dass da mehr passiert und man da sauergefältiger ist und das war unterm Strich eine gute Sache.

Wolfgang: Aber ich habe es doch auch oft erlebt, dass eben die Leute in der Entwicklung

Wolfgang: eher so diese Entwickler-Entwicklerinnen-Rolle inne hatten und da ging es halt

Wolfgang: darum, dass man Software entwickelt und so diese.

Wolfgang: Ich sage mal so diese Sonderaspekte vielleicht, sowas wie Security,

Wolfgang: dann oftmals eher ein bisschen außen vor waren.

Wolfgang: Jetzt nicht, weil man es blöd fand oder unnötig fand, sondern ich glaube eher,

Wolfgang: weil vielleicht die Expertise da einfach gefehlt hat, weil man vielleicht nicht

Wolfgang: genau wusste, wie man es jetzt angeht.

Wolfgang: Und was du jetzt sagst, finde ich sehr spannend. Also ich glaube auch,

Wolfgang: in einem Team sollte jeder die Awareness haben für so ein Thema wie Security,

Wolfgang: aber auch viele andere Themen wie jetzt Dokumentation, das ist das böse Wort

Wolfgang: in der Softwareentwicklung,

Wolfgang: aber so dieses Gefühl, warum ist es wichtig, in welchem Maße ist es wichtig

Wolfgang: und natürlich kannst du ja unterschiedliche Schwerpunkte haben.

Wolfgang: Du kannst ja eine Person haben, die sich da mega auskennt und da auch super

Wolfgang: begeistert und motiviert ist und das vielleicht ein bisschen stärker vorantreibt.

Wolfgang: Kann natürlich auch andere Leute geben, wo vielleicht sagen,

Wolfgang: boah, kenne ich mich nicht so aus, aber ich bin super gut, was so Entwicklung an sich angeht oder so.

Wolfgang: Also es ist im Team ja auch cool, wenn das Team an sich die Leistung erbringen kann.

Wolfgang: Ich frage mich trotzdem, wie man es denn dann in einem Unternehmen sicherstellen kann,

Wolfgang: dass so diese Security-Komponente auch in jedem Team, wo Software entwickelt

Wolfgang: wird, auch stark genug irgendwo gestreut ist und dass es nicht so dieser Zufall

Wolfgang: ist, ich habe jetzt jemanden im Team, das sich damit auskennt oder die sich damit auskennt, super,

Wolfgang: mir fehlt die Person jetzt nicht super.

Gast: Ja, das ist ein ganz wichtiger Punkt.

Gast: Es geht jetzt nicht darum, dass jeder der Experte in allem werden muss,

Gast: sondern halt einfach nur um eine Kultur der geteilten Verantwortung.

Gast: Also wie es ja beim DevOps-Prinzip auch irgendwie ganz ähnlich ist.

Gast: Also dass man, es muss jetzt nicht jeder auf dem Kubernetes-Cluster selber groß

Gast: der Experte sein, aber so dieses Künstliche, die einen bauen,

Gast: die anderen betreiben es dann, das will man halt aufheben und genauso muss es

Gast: bei Security irgendwie auch sein. auch sein.

Gast: Wie kriegt man das jetzt in einem Unternehmen verankert? Also,

Gast: ich glaube, es gibt da so mehrere Möglichkeiten, an die man da denken kann.

Gast: Eins ist irgendwie über Prozesse. Also, wir machen das jetzt einfach irgendwie

Gast: verpflichtend und wir haben,

Gast: Nachweispflichten, dass ihr Threat Modeling gemacht habt und die werden dann

Gast: bei uns gesammelt abgelegt und wir haben irgendwie Vorgaben,

Gast: wie oft ihr Threat Modeling wie lange machen müsst und so.

Gast: Also das kann in manchen Unternehmen wahrscheinlich schon funktionieren,

Gast: wenn man da eh schon so eine Kultur hat von, ja, wir brauchen klare Vorgaben

Gast: an die Entwicklung, wie was gemacht wird und dann wird das genauso gemacht.

Gast: In manchen Unternehmen, glaube ich, klappt das damit nicht, weil da sind dann

Gast: EntwicklerInnen auch oft einfach zu schlau, als dass sie, wenn sie das nicht

Gast: verstehen, warum sie das machen sollen und den Sinn dahinter nicht verstehen,

Gast: das dann halt entweder halbherzig machen oder es halt irgendwie faken am Ende

Gast: oder halt auf jeden Fall so machen, dass es am Ende nicht den Mehrwert hat.

Gast: Das heißt, dann muss man halt mehr einen organisatorischen, kulturellen Ansatz

Gast: irgendwie wählen und halt sich überlegen, ja,

Gast: wie schaffen wir das denn erstmal quasi, dass überall dieses Verständnis für

Gast: Security und das Verständnis,

Gast: warum das so wichtig ist für uns als Unternehmen oder als Organisation zu verankern

Gast: und von dort dann irgendwie dahin zu kommen,

Gast: dass jeder das als Teil seiner Arbeit und seiner guten Arbeit,

Gast: die ja eigentlich jeder irgendwie bringen möchte,

Gast: versteht, die Sachen auch sicher zu entwickeln.

Wolfgang: Glaubst du, dass es als leichtgewichtigen Ansatz helfen könnte,

Wolfgang: wenn man, wir sind wieder im agilen Umfeld, sowas wie eine Definition of Done

Wolfgang: hat, wo vielleicht solche Aspekte auch irgendwie mal,

Wolfgang: drauf verankert sind, sodass man die zumindest sichtbar hat,

Wolfgang: dass man diese Sichtbarkeit schafft, dass man sich vielleicht im Rahmen von

Wolfgang: so einer Checkliste bei jedem Feature wenigstens fragen kann,

Wolfgang: mal so als Ansatz, hey, haben wir uns hier Gedanken gemacht zu dem Thema?

Gast: Ja, also für dieses auf Story Ebene, dass man sich da irgendwie,

Gast: wenn eine Definition of Done Werkzeug ist, mit dem man irgendwie gut arbeiten

Gast: kann, irgendwie, und das eh schon genutzt

Gast: wird, dann ist das eine super Möglichkeit, das da zu platzieren und,

Gast: dann am besten ein bisschen konkreter als jetzt nur Thread-Modeling gemacht,

Gast: Fragezeichen, halt irgendwie...

Wolfgang: Ja, nein, weiß nicht.

Gast: Genau. Die Sachen, wo man vielleicht eh Schmerzen hat, ich bin eigentlich immer

Gast: ein Fan davon, wenn die Definition of Done jetzt nicht super aufgebläht ist,

Gast: sondern wenn da halt die Sachen drinstehen, die in der Vergangenheit irgendwie

Gast: Probleme gemacht haben.

Gast: Also wenn man irgendwie gemerkt hat, wir haben hier alten Code angefasst und

Gast: haben nicht verstanden, was da ist, weil er war nicht dokumentiert,

Gast: dann sollten wir vielleicht ab jetzt in unsere Definition of Done reinschreiben,

Gast: Es wurde irgendwie die Schnittstelle dokumentiert oder so und genauso auch bei

Gast: Security, wenn man irgendwie mal gemerkt hat, oh,

Gast: wir haben ja schon wieder einen Endpunkt, der irgendwie mit den falschen Rechten

Gast: ausgestattet war oder so,

Gast: dann müssen wir uns halt irgendwas überlegen, dass wir sicherstellen,

Gast: dass jeder Endpunkt irgendwie mit der passenden Autorisierung versehen ist.

Gast: Und das wäre dann zum Beispiel was, was man gut auch in der Definition of Done

Gast: packen kann, wenn man irgendwie sich ein Threat-Modeling als Dokumentation gebaut hat.

Gast: Also irgendwie, wir haben unser System als zum Beispiel Dataflow-Diagram,

Gast: wo man so gut sieht, wo fließen Daten irgendwie von A nach B,

Gast: weil das ist irgendwie ganz wertvoll, weil oft irgendwie mit Daten was schief

Gast: geht, so aus einer Security-Perspektive.

Gast: Wir haben das irgendwo abgelegt und wir haben da auch so unsere Threads mit

Gast: drangeschrieben und so und auch wie wir die behandeln wollen und wenn wir ein

Gast: neues Feature einbauen, dann schauen wir, dass wir das up-to-date halten oder

Gast: so, dann wäre das auch was, was man super in so eine Definition of Data,

Gast: packen muss. Aber das kann natürlich auch nur klappen, wenn das Team grundsätzlich

Gast: schon verstanden hat, warum das wertvoll ist und das dann auch irgendwie verfolgt und.

Gast: Am Ende, glaube ich, ist eine Definition of Done vor allem dann wertvoll,

Gast: wenn sie halt vom Team selber geschrieben ist und verfolgt wird und das kann,

Gast: glaube ich, nicht sein, was irgendwie, ja, von oben irgendwie kommt und hier

Gast: ist eure Definition of Done jetzt übrigens für alle Teams macht ihr jetzt bitte diese 300 Schritte.

Gast: Da müsste man dann anders rangehen.

Wolfgang: Ja, ich glaube, Das ist immer so, wenn es dir vorgesetzt wird,

Wolfgang: ist es immer viel, viel schwieriger, dann auch was vernünftig umzusetzen,

Wolfgang: als wenn du da selbst draufkommst und auch den Nutzen darin siehst,

Wolfgang: beziehungsweise mit den Leuten in deinem Team halt erarbeitet hast.

Gast: Sagt man aber auch nicht, denken quasi, die Leute, die verstehen alle nicht,

Gast: warum Security wichtig ist oder das wird ihnen nicht.

Gast: Oft sind das ja auch irgendwie Priorisierungsprobleme. Also oft wollen EntwicklerInnen

Gast: ja irgendwie gerne mehr Security oder allgemein nicht funktionale Requirements erfüllen.

Gast: Aber sie kriegen halt die ganze Zeit neue Features irgendwie vorgelegt und kommen

Gast: da schon nicht hinterher.

Gast: Das heißt, es muss auch halt vorgelebt werden, dass Security den Wert hat und

Gast: der bemisst sich halt dann in einem Projekt oft auch dafür, dass halt irgendwie

Gast: Zeit dafür da ist, sich um diese Sachen zu kümmern.

Gast: Und dann muss man halt im Zweifel auch mal vielleicht ein Feature streichen

Gast: oder so, damit man sich auch darum kümmern kann, Sachen sicher zu entwickeln.

Wolfgang: Ja, absolut. Ich meine, heute ist es doch so, wenn eine Firma oder ein Kunde

Wolfgang: viel Geld investiert in die Entwicklung von der Software, dann muss man schon

Wolfgang: auch klar machen, die Software ist nur wertvoll, wenn sie auch gut ist.

Wolfgang: Das heißt, wenn sie sicher ist und wenn sie keine Fehler hat.

Wolfgang: Also ich kann mich noch an Zeiten erinnern, vielleicht vor so 12, 13, 14, 15 Jahren.

Wolfgang: Da musste man teilweise in Kundengesprächen sehr hart diskutieren,

Wolfgang: dass Aufwände, die man für Testing braucht, dass die halt damit drin sind in

Wolfgang: der Entwicklung, dass das nichts

Wolfgang: Optionales ist. Und ich kann mich auch an Gespräche mit Kunden erinnern.

Wolfgang: Da wurde gesagt, also Entschuldigung, wir erwarten ja, dass Sie Experten sind,

Wolfgang: da passieren doch keine Fehler.

Wolfgang: Und solche Gespräche hatte ich jetzt so, keine Ahnung, die letzten zehn Jahre

Wolfgang: nicht mehr, aber solche Gespräche gab es früher. Und ich glaube,

Wolfgang: Security ist ja auch so ein Ding.

Wolfgang: Also es ist ja einfach eine Maßnahme, mit der du deine Investition auch einfach sichern kannst.

Wolfgang: Und wenn du jetzt irgendwie eine

Wolfgang: große Website hast, ein großes Angebot im Internet mit vielen Kunden etc.

Wolfgang: Und da ist vielleicht ein großes Security Problem drin, dann kann ich das als

Wolfgang: Unternehmen ja auch ruinieren, wenn deine Reputation kaputt ist,

Wolfgang: weil irgendwo so ein Data Breach oder so irgendwo auftaucht.

Wolfgang: Aber ja, ich glaube, das ist sicherlich auch eines der Themen,

Wolfgang: wo man trotzdem noch viel sensibilisieren muss, viel erklären muss und wo sicherlich

Wolfgang: auch noch ein Weg gegangen werden muss, bis man das so irgendwie im Griff hat.

Gast: Auf jeden Fall.

Wolfgang: Sag mal, hast du dann vielleicht auch für dich selbst irgendwo so eine Sammlung

Wolfgang: mit irgendwelchen Security-Themen, die du dann auch immer so Checkpunkt oder

Wolfgang: so Checklisten mäßig dann durchgehst, wenn du sagst, okay,

Wolfgang: ich weiß jetzt, wenn wir nochmal beim Stride bleiben für STR und so weiter,

Wolfgang: da habe ich immer meine Top 20 Sachen, die ganz häufig auftreten und die nehme

Wolfgang: ich mir immer mal mit, wenn es jetzt irgendwie hier ein neues Projekt gibt und

Wolfgang: check da einfach mal, ob das soweit passt.

Gast: Also es gibt da, ja, fertige Listen, die man da zurate ziehen kann.

Gast: Ich arbeite da manchmal auch mit, es ist schwierig, die irgendwie Teams an die

Gast: Hand zu geben, weil wir vorhin auch darüber sprachen, wie können Teams sich

Gast: da irgendwie daran orientieren.

Gast: Das klappt nicht so gut, weil dafür ist jede Anwendung irgendwie zu spezifisch.

Gast: Also man muss sich dann schon immer genau überlegen, ist das jetzt hier relevant

Gast: und man möchte sich ja auch nicht zu viel mit irgendwie Bedrohungen beschäftigen,

Gast: die für einen nicht relevant sind.

Gast: Was ich gerade noch ganz spannend finde, da probiere ich gerade ein bisschen dran rum, ist,

Gast: was Gen.AI da leisten kann, weil das ist ja jetzt gerade die Lösung,

Gast: die wir auf jedes Problem werfen, deswegen versuche ich die gerade auch mal

Gast: auf Threat Modeling zu werfen und probiere gerade mal aus,

Gast: quasi inwiefern ein LLM unterstützen kann, wenn ich dem sage,

Gast: schau mal, ich baue hier diese Anwendung, die macht grob das und das sind meine

Gast: Komponenten, gib mir doch mal bitte eine Liste von Gefahren, an die ich denken kann.

Gast: Und das klappt tatsächlich, soweit ich das jetzt gerade sehe,

Gast: relativ gut, weil die Wissensbasis ist da und grundsätzlich das technische Verständnis

Gast: auch und irgendwie Inhalte generieren, das können die Teile ja eh gut.

Gast: Am Ende muss ich natürlich selber noch überprüfen, wie passend ist das jetzt

Gast: und kann da natürlich auch nicht auf irgendwie Korrektheit und Vollständigkeit

Gast: irgendwie mich verlassen.

Gast: Aber gerade so diese Inspiration, um die mal zuzubekommen, dafür kann das ganz nett sein.

Wolfgang: Wie gehst du da vor? Beschreibst du da nur die Anwendung mit Text oder nimmst

Wolfgang: du auch irgendwie Source-Code und steckst den rein und sagst,

Wolfgang: hey, schau mal, das ist die Code-Base, mach mir hier eine Analyse?

Gast: Ne, das wäre zu umfangreich. Also jetzt gerade mache ich es auf textueller Beschreibung hauptsächlich.

Gast: Wollte jetzt demnächst mal versuchen, quasi mal auch so ein Diagramm reinzufüttern.

Gast: Die Bilderkennung ist da ja auch besser geworden und damit mal zu schauen,

Gast: was er da schon rausziehen kann.

Gast: Dann spart man sich vielleicht so das textuell Beschreiben auch noch so ein bisschen.

Gast: Aber ja, man möchte schon so auf so einer grundsätzlichen architekturellen Ebene bleiben.

Gast: Also was für grobe Komponenten habe ich und dann nicht zu tief in irgendwie

Gast: einen Quellcode reingehen.

Wolfgang: Und hast du da bei deinen Versuchen oder Experimenten auch schon Überraschungen festgestellt?

Wolfgang: Also kam da auch schon mal was raus, wo du dachtest, ui, da habe ich gar nicht

Wolfgang: dran gedacht, aber ja, okay, macht Sinn?

Gast: Nee, aber ich habe es jetzt auch noch nicht so viel für wirklich,

Gast: als Ersatz für eine echte Threat Modeling Session in einem produktiven Projekt angewendet.

Gast: Also das, ja, so richtige Überraschungen habe ich da bisher noch nicht gesehen.

Wolfgang: Okay, das heißt, die LLM ist noch

Wolfgang: kein digitaler Clemens, den man jetzt irgendwie im Projekt nutzen kann?

Gast: Nee, und ich versuche auch, dass das ein bisschen so bleibt.

Wolfgang: Ganz uneigennützig.

Gast: Ganz uneigennützig. Nein, aber ich kann mich ja auch nicht zerteilen.

Gast: Und wenn das irgendwie was ist, was man, wenn die Teams mal die Methodik und

Gast: das grundsätzliche Prinzip verstanden haben, zu Hilfe nehmen können,

Gast: um einfach ein bisschen schneller zu sein oder Inspiration zu bekommen,

Gast: dann freut mich das natürlich auch, weil dann die Methode besser funktioniert.

Gast: Aber gerade bin ich mir noch nicht so sicher, wie schnell das da dazu kommt.

Gast: Das ist alles noch Proof of Concept gerade.

Wolfgang: Ja, aber es ist spannend, so etwas einfach mal auszuprobieren,

Wolfgang: denn keine Ahnung, vielleicht ist das ja mal so eine Art digitaler Sparing-Partner,

Wolfgang: wo du einfach mal deine eigenen Gedanken einfach mal abklären kannst oder auch

Wolfgang: eine Inspiration bekommst.

Wolfgang: Und wenn es nur in einem Fall irgendwo hilfreich ist, dann kann es sich ja auch

Wolfgang: schon ordentlich lohnen.

Gast: Absolut.

Wolfgang: Ja, sag mal Clemens, wenn man jetzt mit Threat Modeling noch so gar nichts am

Wolfgang: Hut hat und sich jetzt so überlegt und denkt, okay,

Wolfgang: wir haben ja auch Software und wir machen hier irgendwas mit Daten und haben

Wolfgang: vielleicht Kundendaten oder unser Business hängt von so einer Software ab und

Wolfgang: das wäre ja total ungünstig,

Wolfgang: wenn die jetzt kaputt wäre oder wenn da irgendwelche Hacker uns die Daten klauen.

Wolfgang: Vielleicht sollten wir da mal ein bisschen mehr mit so Security machen oder mit anfangen.

Wolfgang: Threat Modeling könnte da ja vielleicht so eine ganz gute Idee sein.

Wolfgang: Wie kann man denn mit sowas anfangen? Ich meine, die einfachste Möglichkeit

Wolfgang: ist natürlich bei Inovex anzurufen und einen Termin mit Clemens hier auszumachen.

Gast: Das klappt immer, genau.

Wolfgang: Das klappt immer. Du kommst vorbei, schaust dir es an, analysierst es und zeigst

Wolfgang: dann schwarz auf weiß was Sache ist und wo man vielleicht ran muss.

Gast: Und macht das vor allem mit dem Team. Also es macht jetzt keinen Sinn,

Gast: wenn ich das für mich mache und danach irgendwie eine Liste von Gefahren,

Gast: weil wahrscheinlich habe ich die Hälfte eh nicht richtig verstanden,

Gast: was da funktioniert oder an die Hälfte der Sachen wurde schon gedacht,

Gast: sondern es soll ja mit dem Team passieren und die sollen ja auch die Methode

Gast: lernen und vor allem kennen die das System am besten und können dann mit mir

Gast: direkt diskutieren, was da relevant ist.

Gast: Genau, das wäre eine Lösung, aber du meinst, was gibt es natürlich sonst noch für Möglichkeiten?

Wolfgang: Also es wäre wahrscheinlich die beste Lösung für alle. Aber genau,

Wolfgang: wenn man jetzt eben keinen Clemens hat und sich einfach dem Thema mal nähern möchte, sei es jetzt,

Wolfgang: man ist vielleicht jetzt, keine Ahnung, du bist Entwickler in einem Projekt

Wolfgang: oder Softwareentwickler und interessierst dich dafür oder du bist vielleicht

Wolfgang: auch irgendwie Projektleiter und denkst, oh, das wäre vielleicht mal was Spannendes.

Wolfgang: Was sind so Wege, sich dem Thema zu nähern und da vielleicht selbst irgendwie

Wolfgang: ein bisschen besser reinzukommen?

Gast: Also ich glaube, wenn man dieses 4-Question-Framework mal hernimmt und damit

Gast: einfach mal anfängt, damit sollte man eigentlich schon gut zurechtkommen.

Gast: Also sich die Sachen mal zu überlegen, auch einfach mal mit einem weißen Blatt

Gast: Papier oder einem Whiteboard oder einem Miro-Board, je nachdem anzufangen, das genügt vollkommen.

Gast: Ich bin jetzt kein Fan davon, gleich irgendwie eine fancy Software zu benutzen.

Gast: Da gibt es auch welche, aber das geht so ein bisschen an dem kommunikativen

Gast: Sinn der Sache vorbei und ist für den Anfang auch nicht notwendig.

Gast: Also da kann man auch einfach leichtgewichtig anfangen.

Gast: Ich habe im Frühjahr, glaube ich, mal einen Blogpost geschrieben mit einer Kollegin

Gast: zu Threat Modeling für AI-Anwendungen.

Gast: Den packen wir mal in die Shownotes. Da wird so die grundsätzliche Methode nochmal

Gast: ganz gut beschrieben, auch wenn quasi dann die Beispiele alle aus so dem AI-Umfeld

Gast: kommen, wird die dann ganz gut klar.

Gast: Es gibt ein Klassikerbuch von Adam Shostak der auch dieses 4Question Framework,

Gast: etabliert hat zu Threat Modeling, das können wir auf jeden Fall auch mal verlinken,

Gast: wer lieber ein Buch liest und dann natürlich die Kartenspiele,

Gast: die ich erwähnt habe die ich ganz cool finde, wenn man einen ganz leicht gewichtigen

Gast: Ansatz sucht und einen spielerischen Ansatz dann kann man eben hier Elevation

Gast: of Privilege Kornokopia,

Gast: Cumulus die mal ausprobieren und quasi so losgelöst von den,

Gast: dem 4Question-Framework einfach auf einer ganz spielerischen Art das mal ausprobieren.

Wolfgang: Gibt es da auch spannende Fachkonferenzen, wo es um solche Themen geht,

Wolfgang: jetzt hier in Deutschland, die empfehlenswert sind?

Gast: Also es gibt auch Konferenzen, die sich extra mit Threadmodeling beschäftigen.

Gast: In Deutschland glaube ich allerdings nicht.

Gast: Die sind dann eher international.

Gast: In Deutschland gibt es ein paar Konferenzen, die sich mit sicherer Softwareentwicklung beschäftigen.

Gast: Die Heise DevSec zum Beispiel bin ich jedes Jahr gerne. Da wird auch Threat

Gast: Modeling immer besprochen.

Gast: Der German Overspeed ist jetzt in zwei, drei Wochen in Leipzig.

Gast: Da wird es auch wieder was zu Threat Modeling geben.

Gast: Also es gibt so ein paar Konferenzen, wo das Thema auch besprochen wird, auf jeden Fall.

Wolfgang: Und vielleicht last but not least, was ist in deiner Meinung nach so das eine

Wolfgang: gute Argument, das man immer mal vorbringen kann,

Wolfgang: wenn vielleicht so ein Manager sagt, ah, Thread Modeling, das kostet viel Geld,

Wolfgang: da brauchen wir jetzt irgendwie noch neue Leute oder Weiterbildung.

Wolfgang: Na, ihr seid doch auch so gut.

Wolfgang: Ihr könnt doch auch so gut Software entwickeln, das brauchen wir nicht.

Gast: Also es ist halt eine Methode, die kostet erstmal nicht viel Geld.

Gast: Man muss kein extra Tool oder Lizenzen oder sonst was ranschaffen,

Gast: sondern das kann erstmal jeder Entwickler, jede Entwicklerin selber gut machen,

Gast: wenn man ihr halt ein bisschen Zeit gibt.

Gast: Man kriegt auch mit kleinsten Einheiten schon mal gute Ergebnisse.

Gast: Also selbst wenn man sich mal nur zwei Stunden irgendwie hinsetzt,

Gast: habe ich bisher noch keine Threadmodeling-Session gesehen, wo nicht trotzdem

Gast: irgendwelche Sachen rauskamen, wo man sich gedacht hat, ach ja,

Gast: das müsste man uns eigentlich nochmal anschauen. Aber da sind wir uns jetzt

Gast: gerade nicht mehr so sicher, ob das noch so sicher ist.

Gast: Also man findet da eigentlich immer irgendwas, wenn man damit anfängt.

Gast: Und das ist halt auch einfach eine super Möglichkeit für den Austausch untereinander

Gast: und für die Kommunikation zwischen Junioren, Senioren, fachlichen,

Gast: nicht fachlichen Stakeholdern.

Gast: Das sollte eigentlich auch immer ein Grund sein, warum man das macht.

Wolfgang: Das klingt auf jeden Fall richtig, richtig gut. Und Clemens,

Wolfgang: es war mir ein Vergnügen, mit dir über dieses spannende Thema zu sprechen.

Wolfgang: Und ich hoffe, dass wir in naher Zukunft vielleicht mal wieder über ein weiteres

Wolfgang: Security-Thema quatschen können.

Wolfgang: Denn Security geht uns alle an. Und ich glaube, in einer Welt,

Wolfgang: die immer digitaler wird, da spielt Security auch immer eine größere Rolle.

Gast: Ich komme gerne wieder vorbei. Danke dir, Wolfgang.

Voiceover: Das war das Gespräch mit Clemens. Ich hoffe, es hat euch Spaß gemacht.

Voiceover: Wenn ihr Feedback habt, dann erreicht ihr mich per E-Mail unter podcast.innovex.de.

Voiceover: Wir hören uns in der nächsten Folge wieder. Bis dahin wünsche ich euch viel Spaß und eine gute Zeit.