Threat Modeling in der Praxis

00:00:00: ... dass man sich so kleine Evil-User-Stories überlegt.

00:00:02: Und wenn man daran rumrätselt, da fängt man gleich direkt an mit wer greift eigentlich an und warum greifte er an... ...und dann fängt mal das Gedanke zu machen wo im System kann er das eigentlich machen.

00:00:16: Okay

00:00:24: wir sitzen jetzt also in dem Raum alle haben sich versammelt die da sein sollen.

00:00:30: was ist der nächste Schritt?

00:00:31: Also man holt Stiftung Papier raus oder wie geht es weiter?

00:00:39: Ja, also je nachdem was man genau für eine Methode einsetzen will das ist ja schon ein bisschen offen.

00:00:45: Man kann es mit Stift und Papier machen die meisten Methoden kann da aber auch ganz toll vorbereitete Boards in irgendwelchen Tools benutzen.

00:00:54: Ich sag mal klassisches Werkzeug was jetzt so an Entwicklungsteams eingesetzt wird ist eine Datenflussanalyse.

00:00:59: das ist so ein technisches Werkzeug ... wo ich von der technischen Sicht draufschau und dann Probleme finde oder Risiken finde.

00:01:07: Was man da macht, praktisch dass man sich so einen Architekturdiagramm aufmalt mit allen relevanten Komponenten... Ich sage mal jetzt auf einer grob Architek-Tour-, oder grob Komponentensicht.

00:01:18: Man wird da nicht jede klasse Discodes einzeichnen.

00:01:22: Und dann fängt man an sich schrittweise Gedanken zu machen für jede einzelne Kompolente erstmal was für Assets liegen dort eigentlich?

00:01:30: Also vielleicht liegen in meiner Datenbank ja die Konten, also wenn ich jetzt eine Bank bin dann werde ich irgendwo ein Datenbank haben wo ich gespeichert habe.

00:01:37: Emanuel Sims hat jetzt fünf Euro hier auf diesem Konto zu liegen und da hab' ich jetzt einen Asset.

00:01:45: Ein Asset könnte aber auch sein das hier ist jetzt das System von dem aus meine Fräse gesteuert wird... ...und die bewegt sich und die hat vielleicht tatsächlich auch so Unfallschutzrisiken oder so daran.

00:01:56: Genau, wenn man sich das vielleicht mal bildlich vorstellen will.

00:01:58: Also man hat so Knoten... Das kann zum Beispiel die Datenbank sein und dann der Server und die Klientanwendung.

00:02:03: also ist die Webseite Und wir reden die miteinander welche Daten werden zwischen denen ausgetauscht was es hängt da vielleicht noch andere Systeme dran wie zb einen Geoinformationssystem oder Irgendeine irgendeine andere Anwendung genau und da zeichnet man schöne Pfeile und schöne Knotens und schreibt auch schlaue Sachen daran.

00:02:21: und das ist die Übersicht auf die man drauf guckt.

00:02:23: Ja und bei manchen findet man vielleicht raus, hier werden gar keine wirklich wichtigen Daten übermittelt.

00:02:28: Also vielleicht hat man irgendwas wo eine Anreicherung stattfindet an der UI, wo irgendwie noch so Zusatzinformationen angezeigt werden das holt man vielleicht sogar direkt von irgendeiner Suchmaschine ab oder so... ...und da werden gar keinen Nutzerdaten, keine persönlichen Daten und auch sonst keine sicherheitsrelevanten Daten übermittelte Und es ist aus der Anwendung irgendwie klar dass das was von extern generiertes ist ... sich vielleicht nicht hundert Prozent drauf verlassen kann, dann... ... kann man auch sagen naja muss ich vielleicht das nicht?

00:02:54: die größten Sicherungsmaßen am Treffen.

00:02:57: Okay also als erstes ist es wichtig,... ... man hat etwas so rüber man reden kann worauf man alles drauf gucken kann was eine Hilfestimmung gibt und das Datenflussdiagramm ist quasi eins dieser Tools.

00:03:08: Gibt's noch neben dem Datenflüssmodell andere Modelle oder wo man quasi so Gesprächsobjekte nenn ich jetzt mal kreieren kann?

00:03:20: Ja klar, also kann es andere Methoden.

00:03:24: Ich habe gesagt das ist eher so eine technische Sicht die Datumflussanalyse.

00:03:29: Andere Klassiker sind Angriffsbäume, das ist eigentlich eine fachliche Sicht auch wenn die... Also bei diesem Baum geht man dann immer weiter ins Detail.

00:03:36: Man kommt von der ganz abstrakten Szenario bis zu einem ganz speziellen, wenn man dem ins Letzte treibt und im Speziellen ist das natürlich immer wieder alles hochtechnisch.

00:03:45: aber das Vorgehen ist eher ein fachliches

00:03:48: Genau, man geht vom Allgemeinen wie so was wie Angreifer stehlen wichtige persönliche Daten aus unserem System.

00:03:56: Das wäre der Anfangsknoten vielleicht oder so je nachdem wo man anfängt.

00:03:59: und dann baut man die Baume immer weiter auf und schaut wie schaffen sie das eigentlich?

00:04:02: Welche Voraussetzungen müssen dafür erfüllt sein?

00:04:05: genau

00:04:06: Ja es ist ganz spannend weil Angriffsbäume auch ein klassisches Werkzeug für Angreifers sind Die sich überlegen möchte dieses Ziel erreichen und jetzt analysieren?

00:04:15: Was habe ich denn für Möglichkeiten um das zu erreichen?

00:04:17: ja Ich will jetzt vielleicht die Adresse von Emanuel aus der Datenbank oder möchte ich irgendwie stehlen.

00:04:23: Jetzt überlege ich mir, wo könnte ich sie abgreifen?

00:04:25: Ich könnte vielleicht einbrechen ins Rechenzentrum, die Festplatte mit der Datenbank steheln... ...oder ich könnte versuchen irgendwelche Kommunikationen abzufangen und das daraus zu klauen.

00:04:35: Man kann sich relativ abstrakt Dinge überlegen bis man dazu kommt, wenn nicht in das Rechencentrum einbreche!

00:04:42: Den Schlüssel, den muss ich mir als erstes besorgen.

00:04:44: Das mache ich auch folgendem Wege und so weiter und sofort und dann hat man... Also man kann es bis zu einem konkreten Angriff treiben.

00:04:51: ist.

00:04:51: würde ich jetzt in so einer Bedrohungsanalyse der Artenweise wie wir jetzt übersprechen würde ich nicht soweit das Detail gehen.

00:04:57: aber man kann tatsächlich soweite gehen wie man glaubt dass es hilfreich für eines.

00:05:02: Okay, d.h.

00:05:02: also Datenflussdiagramm ihr einen technischen Ansatz Angriffsbäume, dann eher die aus Angreifersicht.

00:05:17: Was ich bei Angriffsbäumen auch mag ist dass man sich Gedanken darüber macht wer... Wer möchte hier schaden anrichten?

00:05:22: was sind denn tatsächlich die leute, die mich potenziell bedrohen und was haben die für interessen?

00:05:27: weil dadurch hat man eine priorisierung.

00:05:28: Die man reinkriegt.

00:05:29: also ist eine

00:05:31: gute überleitung zu den user stories.

00:05:33: das finde ich auch noch einen ganz guten ansatz dass es vielleicht eher was begleiten ist.

00:05:37: aber man kann jetzt vielleicht auch zum kern von seinem bedrohungsmodell macht dass man sich user stories ausdenkt.

00:05:42: also des user stories kennt man ja von der ... von der klassischen Anforderungsanalyse, Benutzer X möchte dies und das tun.

00:05:50: Und dafür muss er das und das machen usw.

00:05:52: Das System muss es dann halt leisten... ...und das denkt man aber jetzt quasi aus bösartiger Nutzersicht.

00:05:57: Also der bös-altige Nutzer oder Angreifer XY ... ...möchte gerne Folgendes tun und dafür macht er jenes und dann macht er das ... ...und dadurch entsteht der Schaden dass man sich so kleine Evil User Stories überlegt Wenn man daran rumrätselt, da fängt man gleich direkt an mit wer greift eigentlich an und warum greifte an.

00:06:16: Und dann fängt mal das Gedanken zu machen wo im System kann er das eigentlich machen?

00:06:19: Dazu habe ich tatsächlich noch eine Frage weil Evil User Stories klingt schon so der böse Angreifer der vor seinem Computer in den Dunkeln sitzt und uns angreift.

00:06:29: oder dementsprechend könnte man die auch nicht nutzen für Szenarien die vielleicht nicht unbedingt evil sind sondern einfach nur, wo Nutzer irgendwas falsch verstanden hat.

00:06:39: Hat ein paar Knöpfe falsch gedrückt und dann auf einmal gibt es eine DDoS-Attacke für der Kleint zu viele Anfragen aus und DDoSS das System ist ja auch ein anderes Faktor.

00:06:52: Der Nutzer muss ja nicht immer böswürdig sein.

00:06:54: Das System gibt das her, ne?

00:06:56: Genau!

00:06:56: Habe ich gerade erst eine Evil-User-Story geschrieben vor dem letzten Bedrohungsmodell und benutze halt die Aufgabe in einer relativ eintönige Aufgabe zu machen an einem System... ...und weil er halt clever ist schreibt er sich den Skript dafür.

00:07:07: ... um diese Aufgabe quasi automatisiert von seinem Computer machen zu lassen, ... ... um stundenlange unnötige Klickarbeiter sparen.

00:07:16: Aber das Skriptaten-Bug läuft am Möltidatenbank zur große Katastrophe.

00:07:21: Das wäre auch eine schöne Evil User Story... ... auch wenn der Nutzer nicht böse ist, sondern eigentlich sogar eher motiviert seine Arbeit schnell über die Bühne zu bringen!

00:07:30: In der heutigen Zeit ist es dann vielleicht sogar schon noch ein bisschen anders als ... ... fragt sein AI-Age, den er bei sich auf dem Computer hat, der einen Skrill... ... sich nicht mal ein Skript zu schreiben sondern also einfach für ihn zu machen.

00:07:45: Kriegt die nötigen Passwörter und... ... Schnittstellen und fängt dann an was zu machen ist natürlich jetzt auch noch mal ein anderes Vektor.

00:07:55: Ja klar!

00:07:57: Eines was ich auch schön fand... Methodisch, also wir haben jetzt so was macht man dann eigentlich?

00:08:04: und gerade wenn man nicht so viel Erfahrung hat gibt es da ganz einfache Hilfen die das auch ein bisschen gamifizieren.

00:08:10: Da gibt's einen Elevation of Privilege Spiel was man spielen kann und die Idee ist ja dass man so Bedrohungsanalysen immer wieder macht zum Beispiel so einmal im Jahr weil man entwickelt sich das Objekt entwickelt sich ja weiter.

00:08:23: damit ändern sich vielleicht auch die Bedrohrungen und dann kann man dann stückweise Erfahrungen immer besser werden.

00:08:28: ich glaube Frederik Du und ich weiß nicht, Thomas du auch.

00:08:31: Ich glaube ihr habt das mal gemacht bei euch im Team.

00:08:33: Ich habe das leider noch nicht praktisch durchführen können.

00:08:34: Ich hab das nur gesehen bisher.

00:08:36: Ja

00:08:37: genau, möchtest du zuerst?

00:08:39: Nee fang doch ruhig an!

00:08:41: Gut anfangen wir an.

00:08:43: Genau ich habe das ein bisschen mit in die Firma mit reingetragen weil als ich mich damit auseinander gesetzt habe ist es etwas von der OWASP.

00:08:53: Ich bin mir gerade nicht sicher wofür die ganzen Akronüme stehen aber halt... ... rausgebracht wurde und am Ende ist es ein Kartenspiel.

00:09:01: Das kann man sich auch als physisches Kartenspiele kaufen, wir haben's im heutigen Zeitalter mit Teams bräuchten... Ein

00:09:09: kurzer Korrektor ich glaube Oberspad hat nicht Elevation Flivage sondern Thread Dragon rausgebraucht.

00:09:14: das könnte man vielleicht auch noch mal in der Stelle erwähnen.

00:09:16: Das ist so einfach eine kleines Programm mit dem man sich diese Datenflussdiagramme zusammen klicken kann und da also Bedrohungen attributieren kann usw.

00:09:26: Genau, das Spiel stammt glaube ich von Microsoft.

00:09:30: Bestimmt!

00:09:31: Das ist ein White Paper von einem von Microsoft, der stammte.

00:09:34: Stimmt, stimmt.

00:09:35: Das hatte ich durcheinander gebracht.

00:09:37: Am Ende vom Tag... ...jede ist es nach dem Stride-Modell.

00:09:43: Das sind die fünf anderes Vektoren Spoofing Tempering Repudiation Information Disclosure Denial of Service und E ... ist der Namensgeber, Elevation of Privilege.

00:10:00: Und man hat im Prinzip Karten von zwei bis ass.

00:10:05: und ja das Spiel ist tatsächlich ganz interessant weil es

00:10:10: hat

00:10:11: den spielerischen Wert.

00:10:12: Man möchte auch gewinnen, man möchte die meisten Punkte sammeln.

00:10:14: Punkte gibt's wenn man in einer Runde die höchste Karte gelegt hat... ...und für jedes Thread die man gefunden hat.

00:10:23: Die auf den Karten stehen dann halt immer.

00:10:26: Bei Information Disclosure zum Beispiel, durch schwache Autorisierung konnte ein Nutzer auf Daten zugreifen.

00:10:36: Also fast schon wie die Evil User Stories geben sie halt nur Impulse und dann liegt es halt an den Spielenden daraus was zu machen.

00:10:45: Und mit den Karten die man hat die haben quasi Ideen geben zu gucken ob man die irgendwie... eigene projekt anwenden kann

00:10:50: genau und je höher die karte des zumindest in meinen augen.

00:10:54: also mehr punkt die kart gibt es zu gravieren da ist auch die.

00:10:58: Sicherheitslücke bei so zwei ist das meist so.

00:11:02: ja jemand kann ich weiß nicht, man kann einen lock lesen der ihm aber jetzt so direkt keine information bringt aber auf... Das Ass ist dann, du kannst dir selber was überlegen.

00:11:15: Also musst dir dann selbst was eigenes überlegen.

00:11:17: und beim König ist dann halt auch schon so bei Information Discouragerie man kann deine Daten mal rauslesen.

00:11:21: also es vielleicht nicht eins zu eins richtig.

00:11:25: aber vom Konzept her und ja das Karnspiel hat uns im Team wirklich geholfen wo uns gab's jetzt kein jahrelang Sicherheitsexperten Aber wir haben alle von Grund auf das Projekt begleitet und aufgebaut vom ersten Komet bis zur jetzigen Kommentierung.

00:11:45: Und das hat uns viel mitgebracht, die Nachbereitung war vor allem spannend weil wir viel mal hatten wir so... Wollt man das könnte man jetzt?

00:11:52: Das wäre was!

00:11:53: Und dann eine Nachbereitung, nee!

00:11:56: Zum Glück hat das Framework schon einen Schutz dagegen eingebaut aber das haben wir damit dokumentiert.

00:12:02: Das heißt wenn die Frage nochmal aufkommt können wir am Ende etwas.

00:12:08: Ja,

00:12:08: definitiv.

00:12:09: Aber das

00:12:09: heißt Dokumentation ist noch mal ein Thema was mir einfällt.

00:12:12: also zum Beispiel wenn man jetzt Thread Dragon benutzt es ist ja fällt am Ende der Datei raus wo man sag ich mal das Projekt abspeichern kann und da stehen dann Bedrohungen drin die auch irgendwie net in einem Diagramm verortet sind ... oder die Dokumentation ist mir tatsächlich wichtig, dass man die Risiken am Ende irgendwie aufschreibt.

00:12:29: Dass man sie nicht vergisst und dann vielleicht auch dran schreibt was macht man jetzt tatsächlich?

00:12:33: Und manchmal entstehen da tatsächlich Tickets wo man Dinge tun muss draus... Also nicht nur manchmal sondern das sollte passieren wenn er Probleme gefunden hat!

00:12:41: Ich kenne das als Klassiker, dass Man die Dokumentation in Jira macht.

00:12:45: Dann hat man Jira-Tickets für Bedrohungen und so.

00:12:47: Ich glaube es ist ein ganz wichtiger Punkt, ich glaube der spielt sogar manifest eine Rolle.

00:12:52: Das ist halt nicht reichen Bedrohrungsmodell zu erstellen, sondern dass daraus auch eine konkrete Folgen abgeleitet werden müssen und die auch umgesetzt werden müssen.

00:13:00: Und das es da einen Prozess gibt, um damit irgendwie umzugehen.

00:13:02: also idealerweise fallen natürlich irgendwelche Tickets daraus.

00:13:05: dazu muss man sich mit Drogen dann erstmal ein bisschen Medikation oder Lösungen überlegen und genau die müssen dann umgesetzt werde.

00:13:14: ich finde meine Erfahrung bei der Dokumentation ist auf jeden Fall... Man muss mich so ein bisschen vorstellen Schwachstellen gefunden.

00:13:23: Oft hat man auch schon irgendwie die Medikationen sich während dieses Bedrohungsmodellierungsprozesses ausgedacht und das ist aber natürlich so, dass eine Medikacion oder eine Behebung für verschiedene Bedrohhungen eine Lösung sein kann, sowas wie ein Backup machen, ne?

00:13:39: Ist eine medikation für vielleicht einen Dutzend von Bedrohrungsvektoren und deshalb würde ich das trennen.

00:13:45: Ich würde da quasi eine Liste von Schwachstellern haben, der Liste vom Medikations- und die würde man dann aufeinander ... beziehen und daraus dann irgendwelche ... ... Maßnahmen ableiten.

00:13:57: Und das muss natürlich der Product Owner dann entscheiden, welche Sachen ... ... er kauft zu nehmen bereit ist weil sind keine wichtigen Daten kann man in Kauf nehmen.

00:14:06: wie auch immer... ... es so aufwendig für den Nutzen oder ja muss unbedingt nächste Woche passieren?

00:14:11: Dazu natürlich auch mit dem Ranking und wo wann was ... umgesetzt wird, ist natürlich auch die Bedrohungseinschätzung... ... ganz wichtig.

00:14:22: Das heißt ich habe jetzt eine Bedrohnung gefunden wie gravierend es das?

00:14:27: Ich kenne das noch so über dass je eine Achse war, wie wahrscheinlich es kommt und die andere Achse ... ... war wenn es eintritt wie viel Schaden richtet es an.

00:14:39: Da würde ich mal eure Erfahrung nochmal anfragen wie ihr das macht, wie daran geht oder rangegangen seid.

00:14:47: Wir haben das tatsächlich selten oder nicht wirklich gemacht, so eine Gefahreneinschätzung.

00:14:51: Ich finde es aber eigentlich eine gute Sache.

00:14:53: Es ist ja nicht nur wie groß ist der Schaden und wie schwer die Sicherheitslücke auszunutzen, sondern auch wie viele Motivationen hat ein Angreifer?

00:15:02: Also das wird dann eine ganz zentrale Rolle kaputt machen.

00:15:04: Das ist immer einfach.

00:15:05: Aber was habe ich davon als Angreifer?

00:15:06: erstmal in vielen Fällen nichts?

00:15:08: Datenstellen ist schon viel attraktiver.

00:15:11: Genau!

00:15:11: Und dass man aus diesen verschiedenen Komponenten ... kreale Bedrohung ableitet, das ist glaube ich gar nicht so trivial.

00:15:18: Aber total wertvoll!

00:15:20: Risikomanagement hat ja einfach nur eine Risikoeintrittswahrscheinlichkeit und eine Schadenshöhe... ...und die werden dann multipliziert.

00:15:26: kann man letztlich eine Tabelle draus machen... ...dann kann man ablesen wie hoch die Priorität jetzt für dieses Risiko ist.

00:15:35: Genau die angreifermotivation dies ist total wichtig hiermit reinzubringen.

00:15:39: also man kann auch sagen die ist letztlich in der risikoeintrittswahrscheinlichkeit enthalten.

00:15:43: Aber es ist oft zu einfach zu sagen ja das ist wahrscheinlich technisch gesehen eher leicht oder sehr schwer auszunutzen, wenn man hat die technisch schwer aus zu nutzen ist wo keine große angreifer Motivation besteht dann sinkt damit das Risiko nochmal deutlich mehr.

00:16:00: Ist wahrscheinlich auch für den pio wichtig zu wissen eigentlich dass man dann sagen kann okay Wo priorisiere ich das hin?

00:16:06: Weil der P.O.

00:16:07: hat ja auch immer noch mal jemanden, den er zufrieden bestellen muss und dann das heißt... ...das muss jedes Finding was man hat, was man auch fixen muss,... ...war ich da natürlich in dem Featuren was man dann in dem Zeitraum halt nicht fixt oder nicht implementiert.

00:16:22: eher gesagt.

00:16:23: Genau ist auch wieder ein guter Punkt warum der Po mit dabei sein sollte um dann gleich auch den Entstehungsprozess mitzubeachten und Verständnis dafür zu bekommen welche Relevanz es für das aktuelle System eigentlich hat.

00:16:32: ... um nochmal auf dieses Elevation of Privilegspiel zurückzukommen.

00:16:36: Du hattest das Kartenspiel erwähnt, wir nutzen da die Online-Variante davon... Da hat sich jemand die Mühe gemacht, das Ganze mal in ein schönes quasi webbasiertes Kartenspiele zu gießen.

00:16:49: Da sollte man natürlich jetzt nicht irgendeinen... ... öffentlich gehostete Spielen nehmen und da seine ganzen Sicherheitslücken reinwerfen, sondern ich... Sondern das sollte man auf jeden Fall selbst hosten.

00:17:04: Das ist auch nicht so aufwendig.

00:17:07: Also dieses Online-Spiel ist ein bisschen Jahre gekommen.

00:17:10: wir haben uns da tatsächlich selber mal ran gesetzt und das wieder auf aktuellste Stand gebracht, sodass es auch mit den neuesten Schema, Datenschema von Threadraken zusammenspielt.

00:17:22: Man kann sich also das Red Tracking sein, Datenflussdiagramm zusammenstellen und dann in den Elevation of Privilege der Web-Anwendung das dann reinwerfen.

00:17:29: Und da die Taten ausspielen und den unterschiedlichen Komponenten zuordnen.

00:17:36: Wir haben einen Repository wo die aktuelle Version liegt.

00:17:39: Da kann man sich dann den Code unterlagen bzw.

00:17:43: einen Container runterziehen um es selbst zu hosten und durchzuführen.

00:17:48: Das vielleicht auch für unsere Zuhörer werden vielleicht Show Notes dann die verschiedenen Links reinpacken.

00:17:55: Von allen, also von den Zwerg-Dragg'n vom OWASP und vom Elevation auf Publisher und dem Repository, von dem du geredet hast.

00:18:03: Zum Spiel auch nochmal... Es macht zum einen Spaß für die Entwickler aber es hat bei uns beim Kunden tatsächlich sehr gut angekommen und sie haben das dann tatsächlich auch in andere Projekte übernommen ist auf sehr fruchtbaren Boden gestoßen und die Product Owner haben da auch eine Freude daran entwickelt, damit zu grübeln darüber mit nachzudenken.

00:18:20: Das ist schon sehr motivierend und bindet alle Beteiligten gut ein.

00:18:24: Wirkt ein bisschen merkwürdig das die Software-Sicherheit in dem Spiel zu machen aber es funktioniert tatsächlich ziemlich gut und ist sehr produktiv.

00:18:32: Es ist eigentlich die perfekte Überleitung.

00:18:34: auch zum nächsten Thema Der Kunde hat's gut gefunden.

00:18:43: Was waren denn so jetzt Probleme, Erfolge und Herausforderungen, die dabei entstanden sind?

00:18:51: Ja also das größte Problem ist der zeitliche Aufwand.

00:18:54: Der ist nicht zu unterschätzen.

00:18:56: wir haben bei besagten Kunden vielleicht ein halbes Dutzend Anwendungen für jede dieser Anwendung dann irgendwie so sechs sieben Leute für einen Tag oder einen halben Tag damit zu beschäftigen.

00:19:08: dass geht schon real ins Geld Vor allem wenn man das dann wiederholt machen will, meine Erfahrung ist auch dass sich das lohnt das wiederholen zu machen.

00:19:15: Wir haben das der Reihe nach verschiedenen Anwendungen gemacht und natürlich erinnern die sich alle weil es ein unglücklicher Tech-Stack ist.

00:19:21: aber wir haben dann mit jeder neuen Anwendung immer wieder neue Sachen gefunden die auch für die alten Sachen relevant sind.

00:19:29: also da passiert tatsächlich auch viel im Verlauf dieser Erfahrungsgewinn sind das immer wieder überdenkens.

00:19:35: ich finde das eigentlich sehr produktiv Aber das kostet Zeit und damit Geld.

00:19:40: Meine Erfahrung ist, dass es allerdings gleichzeitig auch in einem enormen Weiterbildungscharakter hat für alle Beteiligten.

00:19:47: Weil man sich eben so gegenseitig inspiriert wenn man sich gegenseitsich auf Ideen bekommt weil man diese Art zu denken lernt einfach gemeinsam.

00:19:54: Wenn man sich da alleine hinsetzt dann guckt man vielleicht mal irgendwelche Schwachstellenprobleme durch oder muss euch auf eine persönliche Erfahrung beziehen wovon man mal gehört hat was ein Problem sein könnte.

00:20:04: das ist einfach etwas ganz anderes ... vom Junior-Entwickler bis zum bald gedehnten Architekten alles zusammensitzen und alle so gemeinsam auf das System raufgucken.

00:20:15: Das ist im Prinzip wie eine große Weiterbildung in Security.

00:20:20: Bei Zeit fährt mir noch ein, dass man irgendwann auch ein bisschen lernt damit besser umzugehen oder sogar so diese Risikoverteinschätzungen.

00:20:26: wenn man da jetzt angeht.

00:20:27: Im Idealfall schätzt man ja den Wert dann in Euro ein oder sowas... vielen Leuten super schwer fällt.

00:20:33: und wenn man sich da eingroovt und merkt, ja ich gebe einfach auf einer Skala von eins bis fünf Punkte.

00:20:39: Und ich halte mich jetzt nicht an jedem hier ewig auf für stundenlange Diskussionen über den Risikowert.

00:20:44: Den kann man auch nochmal neu vergeben im nächsten Jahr.

00:20:46: Wenn man sich dann nicht einig wird, kommt man aber der Zeit schneller voran oder?

00:20:53: Ich denke das ist auch...wenn man es ein paar mal gemacht hat, ist deutlich besser.

00:20:56: Das flutscht immer mehr.

00:21:00: Wir haben das ja auch gespielt, beim ersten Mal sind wir jede Karte durchgegangen und... ...das ganz genau durchgelesen.

00:21:07: Was bedeutet diese Karte für unser System?

00:21:12: Beim zweiten mal weil wir halt auch einen gleichen Technologiestack überall in unsere Projekte haben... ...haben wir dann teilweise auch Threads die wir im Einprojekt im Z-Modell mit der Medikation hatten... ...rüberkupiert und dann gesagt okay das haben wir schonmal!

00:21:30: herausforderung zeit definitiv Erfolge auf jeden fall.

00:21:35: auch persönlich muss ich sagen nachdem wir es gespielt haben für Wir hatten halben tag fünf projekte also zweieinhalb tage Also zweieinander Arbeitstunde arbeitstage Und ich mich dann als nächstes ticket gesetzt habe uns programmieren Halt die diskussion immer noch so ein bisschen in meinem kopf nach und das tun sie immer wieder dass besonders energische Diskussionen, warum das eine Schwachstelle ist und dass es keine schwachstell ist.

00:22:05: Wenn man dann beim Programmieren wieder über solche Schematah kommt... ...hallen doch wieder nach und dann haben wir mal.

00:22:13: darüber muss ich nachdenken weil das hatten wir hier besprochen.

00:22:16: Also das finde ich persönlich jetzt ein sehr großen Erfolg.

00:22:20: Ich fände es ja spannend was man manchmal so raus findet in so Workshops.

00:22:24: also ich habe einen Mal gehabt.

00:22:26: das war damals nannte man noch nicht Bedrohungsmodellierung.

00:22:28: Da hatten wir damals mit den Fachexperten beim Kunden zu machen und Architekten.

00:22:33: Also waren schon ein paar Leute da, weil jetzt nicht ganz so.

00:22:36: die Entwickler waren ein bisschen weniger beteiligt aber... Wir haben da gesessen und unterschiedliche Sicherheitsanforderungen angeschaut sind das strukturiert durchgegangen Und dann kam am Ende raus also das ist halt ein Projekt was inhaltlich letztlichen Selbst ein Security Feature war.

00:22:52: und dann kam raus, dass manche Kern Security Features die wir eigentlich erwartet hatten viel weniger wichtig waren als Sachen wie Verfügbarkeit.

00:22:59: Ja verfügbarkeits total wichtig.

00:23:01: wenn das System weg ist Wenn hier einer reinkommt und uns ausraubt soviel kann er gar nicht ausrauben Wie wenn es Dinge ausfällt was das an Schaden verursacht.

00:23:10: Und das ist manchmal ganz spannend dass man doch bei solchen sachen rauskommt Die irgendwie unerwartet sind.

00:23:17: und eine andere Anekdote die mir gerade noch einfällt Zum thema zeit gar nicht wie viel zeit brauche ich dafür sondern wie viel Zeit haben die leute dafür?

00:23:27: wenn man die meine leute gerade so um stress erwischt dann.

00:23:30: Werden solche Aktivitäten manchmal als jetzt eigentlich weniger wichtig wahrgenommen.

00:23:34: Und dann haben die Leute keine Lust da zu sitzen und dann machen sie nicht gut mit.

00:23:37: Das ist vor allem relevant, das Threadmodel manifesto macht ganz stark dass man ein Threadmodel eigentlich erstellen muss bevor man anfängt Sachen zu entwickeln.

00:23:45: Das sieht natürlich ganz anders aus als bei dem fertigen System weil es natürlich noch alles viel abstrakter und generischer ist aber... Das stimmt total, aber gerade in dieser Phase nehmen sich die wenigsten Product Owner jetzt irgendwie die Zeit und das Geld in ihr Hand.

00:23:56: Um da zusätzlich zu... Also ein sauberes Architektormodell zu erstellen, ein sauberes Datenflussdiagramm und dann nochmal Bedrohung seiner Lese bevor man überhaupt die erste Zeile Code geschrieben hat.

00:24:05: Das muss man auch wollen!

00:24:08: Da sprichst du einen ganz interessanten Punkt an wenn man tatsächlich gerade dabei ist mit dem Kunden zusammen etwas auszuarbeiten eine Architekatur zu erstellt, den Technologiesteck zu ... setzen.

00:24:23: Wem liebt es?

00:24:24: Also Wessentjob ist es dann auch zu sagen, ah lass uns jetzt... ...auch das Thread-Model machen weil ich nehme mal an dass der Kunde wahrscheinlich nicht unbedingt immer der Erste sein wird.

00:24:32: Der mit dem Thread Modeling oder der Sicherheitsanalyser um die Ecke kommt,... ...sondern eher ich kenne das ja auch Minimal Valid Product,... ...dass wir mal das erste rausbringen wo man da schon mal rumspielen kann um Feedback zu bekommen.

00:24:46: Wann ist eigentlich der Zeitpunkt dann... ...das zum Kunden zu tragen?

00:24:49: und Wessendjob ist das dann?

00:24:50: Also

00:24:51: es hängt natürlich ein bisschen davon ab, was man jetzt genau vertraglich vereinbart hat mit dem Kunden.

00:24:55: Im Jahrfeld würde ich mir wünschen dass der Kunde von selbst auf die Idee kommt.

00:24:58: wenn er das aber nicht kommt dann sollte irgendwo ein Architekt oder so zumindest von alleine auf die idee kommen weil die Aufgabe des Architekten ist ja so nicht funktionale Anforderungen irgendwie zu erfüllen und Security ist letztlich eine nicht funktionelle Anforderung.

00:25:12: Unsere Erfahrungen waren, dass wir das als Entwicklerteam reingetragen haben beim Kunden.

00:25:17: Dass da aber so gut angekommen ist, dass sie das dann einfach selbstständig für alle ihre anderen oder einige oder viele ihrer anderen Projekte mit denen wir gar nichts zu tun haben mit reingetragen haben, sodass es sich schon ein bisschen von selbst verbreitet als Kultur beim Kunden.

00:25:31: Aber die Initialzündung kam schon von uns her

00:25:34: Und das ist schon echt mega, wenn es so gut ankommt dass der Kunde das gleich noch an anderen Stellen auch

00:25:38: machen will.

00:25:38: Ja da muss man dazu sagen, dass da auch Erfahrungen mit Sicherheitsproblemen eine Rolle spielen.

00:25:43: Das muss dann quasi ja... Der Kunde entweder auf die harte Tour lernen, dass das wichtig ist oder sich halt gut beraten lassen.

00:25:53: Ja aber spannend finde ich schon!

00:25:56: Ich bin mal in so einer Situation gewesen wo wir ein Projekt angefangen haben und dann wollten wir jetzt einen Thread-Model machen weil man macht das ja vorher Und tatsächlich da die Aufmerksamkeiten, die Energie dann dafür nicht da war.

00:26:06: Wir haben das dann durchgezogen und ich glaube ein Monat später werden hätten wir ein besseres Ergebnis bekommen.

00:26:11: Hätten immer noch Zeit gehabt irgendwie umzusteuern wenn man merkt wo das was wir hier architekturmäßig aufgemalt haben Das passt vielleicht nicht ganz so.

00:26:21: Eine Herausforderung auch?

00:26:22: Die Bones of Congress halt.

00:26:24: Was du ganz am Anfang angesprochen hast und da wollte ich jetzt nochmal darauf zurückkommen ist der Scope.

00:26:29: Was kommt alles ins Red Model, weil das gab große Diskussion bei uns im Team.

00:26:36: Wir müssen nicht alles aufschreiben was schon von.

00:26:39: ich meine unser Produkt läuft in der Microsoft Azure Cloud Umgebung.

00:26:44: die bringt natürlich verschiedenste Sicherheitsmechanismen mit sich z.B.

00:26:50: den Out of the Box DDoS Scope der vor jeder der Ressourcen hängt.

00:26:58: da war dann auch die Diskussion Tragen wir ein.

00:27:01: Ein Thread ist das D-Dorsen und wir haben den Azure D-DoS Schutz davor oder weil es auch nicht so muss, dass mit rein.

00:27:12: Es gab viele Diskussionen.

00:27:13: wo setzen wir jetzt den Schnitt?

00:27:15: Fast sogar mehr als was is in Thread Model.

00:27:18: also was ist eine Thread?

00:27:20: meistens die Threads die wir gefunden haben.

00:27:21: die waren eigentlich oh ja!

00:27:23: Das ist eins nur tragen wir's ein.

00:27:27: Also wenn man Dinge irgendwie auf dem Vertragspartner wie jetzt Microsoft in dem Fall überträgt.

00:27:33: Dann darf man sich schon darauf verlassen, dass er auch gewisse Dinge löst.

00:27:36: aber mal ein bisschen nachschauen schadet ja nicht.

00:27:38: also gerade bei DDoS habe ich denn wirklich den Schalter umgelegt das DDoSS Schutz hier aktiv ist?

00:27:44: die Frage darf man sie schon stellen was liegt in meinem eigenen Einflussbereich und umgekehrt solche Sachen wie... keine Einbricht bei denen im Rechenzentrum.

00:27:54: Da werde ich mich jetzt nicht in der Praxis drum kümmern, sondern dann werde ich gucken ob ich vertraglich entsprechend was Sinnvolles vereinbart habe und der Dienstleister vielleicht sagt er geht hier nach gewissen Standards vor und dann gibt es vielleicht sogar ein Zertifikat dafür oder irgendwas was mir glaubhaft macht dass er sich um die Sachen schon gut kümmert.

00:28:10: Genau wir hatten da auch die Erfahrung gemacht.

00:28:12: also das Scope ist wirklich eines der größten Probleme bei der Durchführung.

00:28:15: da gibt's ja noch viele Diskussionen viele unterschiedliche Vorstellungen wo man die Grenzen zieht.

00:28:20: Und gerade in unseren Fällen hatten wir auch viele andere Anwendungen, die damit unsere Anwendung spielen.

00:28:25: Verlässt man sich darauf dass ihre Inputs validieren das da kein Datenmüll reinkommt, dass sie uns nicht irgendwie lahm legen mit zu viel Anfragen und so weiter wieviel Vertrauen setzt man in die anderen Anwendungs von den anderen Entwicklungsteams?

00:28:37: Und wo zieht man da die Grenze ist total schwer zu beantworten.

00:28:41: ich würde auch sagen um Zweifelsfall lieber ein bisschen weiter gucken als zu kurz aber muss auf jeden Fall irgendwo eine Grenze ziehen.

00:28:46: Und da hatten wir aber auch schon interessante Erfahrungen.

00:28:48: Also du hattest Jeff schon angesprochen bei euch?

00:28:51: Wir haben die selbe Situation, dass wir gar nicht verantwortlich sind.

00:28:54: Das läuft in dem Kubernetes-Cluster das wird von unserem Kunden gehostet... ...das ist alles gar nicht unser Bier!

00:29:00: Aber dann ist es aufgefallen, na ja moment unsere Anwendung hat aber spezielle Anforderungen an den Cluster,... ...die andere Anwendungen nicht haben.

00:29:08: und wer hat das jetzt auf den Schirm?

00:29:12: Die Clusterbetreiber Machen halt quasi die könnten das auch auf dem Schirm haben, dass sich Speziale Sonderfälle irgendwie auch sicher abgedeckt sind.

00:29:20: Aber im Zweifelsfall übersehen sie das auch weil die haben natürlich eine Unmengen an Anwendungen die Sie da irgendwie betreuen müssen und dafür machen sie sicherlich vielleicht auch gute Betrugungsanalyse.

00:29:30: aber gerade so Sonderlocken wie wir sie dann haben wollen machen ganz neue Probleme auf und da finde ich schon dass wir ja auch die Verantwortung haben die zu finden Vorschläge zu arbeiten wie man die löst, auch wenn wir selbst sie gar nicht lösen können weil es natürlich dann technisch nur beim DevOps Team umgesetzt werden kann.

00:29:52: Also das waren ganz konkrete Erfahrungen aus unseren Betrugungsmodellen.

00:29:56: Es lohnt sich schon mal ein kleines bisschen über den logischen Scope Runt hinaus zu gucken ohne dass er sich darin verliert.

00:30:03: Dabei fällt natürlich noch eine Frage ab hat sich's gelohnt?

00:30:07: also jetzt Auserfahrung bei euch in den Projekten ... habt ihr was gefunden, wo ihr gesagt habt.

00:30:12: Oh ja also... ... wir müssen natürlich jetzt nicht sagen welche Sicherheitslücke hier bei euren Projekten gefunden haben aber so allgemein gesprochen.

00:30:21: Habt ihr tatsächlich auch wurde die fündig oder?

00:30:25: Also ich kann mich nicht erinnern dass wir irgendwo mal eine Eklantante ... ... Sicherheitslücke gefunden haben.

00:30:30: Aber wir haben viele Sachen gefunden wo wir gesagt haben oh hier können wir besser werden das lohnt sich auch.

00:30:34: das wäre sinnvoll.

00:30:36: Wo man merkt dass man vorher vielleicht nicht mehr ganz zeitgemäß unterwegs war

00:30:41: Eklatante Sachen haben wir auch nicht gefunden, aber schon eine Reihe von Sachen wo man sagt okay das ist eigentlich nicht schön.

00:30:47: Das sollte man auf jeden Fall besser machen Vor allem auch Sachen die wir schon irgendwie kannten, aber nie so ausbuchstabiert haben.

00:30:54: Wo wir immer schon gesagt haben okay warum reden wir über diesem Trittsystem eigentlich mit... ...unauthentifiziert?

00:31:00: müsste man dann nicht irgendwann mal irgendwie was machen und so weiter?

00:31:03: Das wird dann einfach mal verschriftlicht und da steht dann auch klar dar und dann wird das nicht vergessen und dann ist es wie so eine Mahnung.

00:31:08: quasi immer hat man das vor Augen Und was ich außerdem sehr lohnenswert fand vor allem auch für den Produkt owner zum Gefühl der Sicherheit nämlich Wir haben uns mal alles angeguckt und wir haben eine gute Vorstellung davon, wie sicher das System ist.

00:31:22: Klar man kann immer was übersehen aber... ...das ist einfach ganz anders wenn man so Betrugungsmodell vor sich liegen hat und dann so ein bisschen weiß, was sich für Gedanken gemacht wurden?

00:31:31: Und bei diesem Gedankenprozess sind die Produkte auch idealerweise dabei als wenn man sagt naja wir haben da ein System es wird schon hoffentlich irgendwie zusammenhalten.

00:31:38: aber so richtig sicher bin ich mir nicht.

00:31:41: Wenn ihr euch jetzt das mal kurz Was überlegen müsstet was wäre denn ein gutes feinling?

00:31:47: also abgesehen jetzt natürlich die kunde hat die sicherheit das sichheitsgefühl man konnte vielleicht sehen, was man hier und da ein bisschen besser machen kann.

00:31:57: aber wenn man jetzt durchführt nach was sucht man.

00:32:01: Also was wäre dann ein gutes was?

00:32:03: ein beispiel für den gutes feining was wir dann hinterher umkommen?

00:32:06: doch zusätzlich.

00:32:07: Klassiker dem man in fremden bin ich jetzt so aktiv war finde Vier T-Klocken um Einsatz in den Projekten, in der letzten Jahren.

00:32:16: Klassiker, den man findet ist ja es gibt ja irgendwie Tokens und die validieren wir und wir vertrauen denen.

00:32:21: und dann stellt man fest Ja da ist aber irgendwie noch ein Hash Algorithmus eigentlich erinnern ... Signaturalgorithmus eingestellt, der jetzt vielleicht nicht mehr ganz so modern ist.

00:32:30: Also die klassischen RSA basierten die ganzen, glaube ich bei KeyClub immer noch default und man muss dann aktiv was machen um auf ECDSA vorwärts zu kommen.

00:32:38: Das ist so ein Klassiker und das ist einfach eine Verbesserung, die man dabei findet... Man macht sich halt Gedanken, ah!

00:32:42: Ich habe hier diese Tokens- und diesen Zentral für irgendwie Vertrauen zwischen meinen Anwendungen zu schaffen.

00:32:48: Es geht technisch schon ziemlich in die Tiefe kommt aber relativ schnell von diesem abstrakten Datum, was man findet, was dahin und her geschickt wird.

00:32:55: Also wir haben auch einige interessante Sachen gefunden, die vor allem mit so Denial of Service Lücken zu tun haben.

00:33:01: Wie kann man das System so überlasten dass es nicht sinnvoll benutzt werden kann?

00:33:06: Gerade wenn man sich nie Gedanken darüber gemacht hat wie viel oder wie große Inhalte man so an Schnittstellen zulässt.

00:33:13: Dann kann das nämlich sein, dass da irgendeine Stelle mit Gigabyte großen Datenpaketen lahmgelegt wird und dann einfach nichts passiert und man nicht so richtig weiß warum.

00:33:19: Das kann auf ganz verschiedene Weise passieren.

00:33:21: Es können zum Beispiel auch riesige Headers sein oder irgendwelche Sachen, die man nicht unmittelbar denkt.

00:33:30: Am interessantesten fand ich aber ein Finding wo wir festgestellt haben ja okay hier könnte ... Interestsystem durch unser System lahmgelegt werden, wenn man das gezielt und geschickt ausnutzt.

00:33:44: Also unser System wäre gar nicht so bedroht gewesen aber im Zweifelsfall wäre dann ein Interestssystem voll bemüllt worden.

00:33:49: Wenn man das weiß... Und wenn man dafür irgendeine Motivation hat könnte ich mir jetzt gerade unmittelbar keine Ausdenken für.

00:33:57: Aber das ist schon interessant zu schauen welche Rolle spielt meine Anwendung im Ökosystem aller anderen Anwendungen.

00:34:03: wie kann es vielleicht auch andere Anwendungs betreffen und bedrohen?

00:34:07: Das stimmt.

00:34:09: Für mich war es mir total hilfreich, am Ende hat man viel über so Priorisierung gelernt.

00:34:13: wo sind Sachen wichtiger?

00:34:14: Wo sind Sachen weniger wichtig?

00:34:16: und dann guckt man also wirklich genauer hin bei den Sachen wo man weiß ah hier hier sind meine kritischen Daten Und ganz oft kommen auch so wenn Sachen, sag ich mal ein bisschen hemsärmlich aufgesetzt sind, kommen einfach so Standard-Fragen wie Hier ist meine Verbindung zu der Datenbank, hier gehen diese ganzen wichtigen Daten drüber werden die dann im Klartext übermittelt?

00:34:35: Oh, die werden im Klartext übermittelt.

00:34:37: Ich müsste mal Datenbankverschlüsselung... also die Transport-Verschlüsselungen hier einschalten.

00:34:42: Das sind so Klassiker.

00:34:43: Gerade wenn Sachen hemmendlich schnell aufgesetzt werden wird man da auf jeden Fall nochmal drauf gestoßen das zu machen.

00:34:53: Ist eigentlich was einem nicht passieren sollt aber es bringt einen noch einmal aktiv ins Nachdenken.

00:34:57: Jetzt haben wir unser Bedrohungsmodell.

00:34:59: alle sind glücklich weil wie geht's weiter?

00:35:04: Sozusagen also was war man jetzt ein Jahr und macht das Ganze nochmal oder.

00:35:10: Wann ist der richtige Punkt, dass noch mal anzusetzen ist vielleicht nach den nächsten großen Umbaum-Aktionen weil sich die Infrastruktur geändert hat?

00:35:18: Oder

00:35:19: es gibt ja zwei Szenarien des.

00:35:21: eines ist einfach so langsame Projektentwicklung wo sich so vielleicht gar nicht mal substanziell was ändert.

00:35:26: Vielleicht entwickelt man ganzes Jahr lang nur an den Farben des Themes im schlimmsten Fall.

00:35:33: Okay, für andere Leute ist das vielleicht der schönste Fall.

00:35:35: Ich weiß es nicht.

00:35:35: Wenn ich persönlich nicht mein Ding nichts gegen Farmen fliegt... ...das ist schon auch wichtig.

00:35:39: aber an dieser Stelle muss man vielleicht nicht sofort wieder eine entsprechende Threat-Modelling Workshop machen,... ...aber vielleicht mache ich zwei Monate später gleich einen großen Architektur im Bau und dann sollte ich mir da eigentlich auch gleich wieder Gedanken machen finde ich.

00:35:53: Es gibt ja noch ein drittes Szenario nämlich dass sich die Bedrohungslage verändert.

00:35:58: Wir haben jetzt zum Beispiel Also irgendwann war dann plötzlich diese Supply Chain.

00:36:03: Angriffe waren plötzlich relevant.

00:36:04: Es ist glaube ich gar nicht so lange her, dass man festgestellt hat wir verlassen uns ja ganz viel auf fremde Software.

00:36:10: Man schreibt ja nicht alles von null auf hundert hoch sondern benutzt natürlich viele Komponenten Bibliotheken die andere Leute geschrieben haben Die gut abgehangen sind die von vielen Leuten genutzt werden.

00:36:19: und da stellt sich plötzlich raus Da ist leider Mailware drin gewesen oder da sind kritische Sicherheitslücken drin gewesen.

00:36:24: Wie verhindert man das?

00:36:25: ... clevere, bösartige Art und Weise diese Abhängigkeiten auszunutzen indem man da Pakete austauscht in dem irgendwelche Open Source Projekte plötzlich von böseartigen Akteuren übernommen werden.

00:36:36: Da gab es so einige... ... Erfahrungen mit.

00:36:39: dann hat das plötzlich eine viel hohe Rolle gespielt.

00:36:40: wenn man das vorher nicht auf den Schirm hat macht das schon Sinn dann nochmal über die Projekten drüber zu gucken oder zumindest in dem Fall überall seine Projekty gemeinsam weil der Entwicklungsprozess ist ja meistens ziemlich ähnlich.

00:36:49: jetzt haben wir zum Beispiel die KI Geschichten.

00:36:51: viel mehr Entwicklerinnen und Entwickler verlassen sich auf ... das was die KI ihn so erzählt und da gibt es auch schon wieder ganz ... ... cleverere Angriffsmöglichkeiten, dass ... ... genau, dass man sich von der KI dann irgendwelche bösartige ... ... Software unterjubeln lässt, irgendwelchen Abhängigkeiten... ... die man dann einbindet.

00:37:11: Genau also ich kann mir schon vorstellen, dass das ein guter Grund ist auch mal wieder auf ältere Bedrohungspurtele drauf zu gucken.

00:37:16: wie guckt man davon heute darauf?

00:37:19: Und dann gibt's noch einen weiteren Aspekt nämlich an sich veränderte ... Anforderungen, also es gibt jetzt schon eine gesellschaftliche Sensibilität für ... ... Cybersecurity würde ich sagen gerade für kritische Infrastruktur.

00:37:35: Da müssen viele Protagonisten drüber nachdenken, ... ... müssen neue gesetzliche Vorgaben erfüllen und müssen deshalb noch mal mit sich ins Reine gehen... ... und für ihre Software sicherer machen oder so klassische Zertifizierungen wie die ISO-Central-Center-Certificierung, ... ... in den Vordergrund rückt bei Ausschreibungen, ... ... bei genauer Projektanforderungen,... ... wo sowas dann auch eine ganz wichtige Rolle spielt.

00:38:03: ISO-Siebundzwanzig Null eins?

00:38:05: Ja...

00:38:06: Was ist das nochmal?

00:38:08: Die ISO-siebundenzwanziger

00:38:10: Null Eins ist ... ... eine

00:38:12: Beschreibung für ein sogenanntes Informationssicherheitsmanagementsystem.

00:38:16: Letztlich heißt es eine Organisationsstruktur ... ... für IT-Sicherheit mit ... ... was ziemlich ins Detail geht.

00:38:25: Ich habe noch eins zur sich ändernen Bedrohungsgelage, da hab ich eine Praxisgeschichte erlebt.

00:38:30: also wir haben ja so öffentliche Dienstleister als Kunden und... Da gab es eine Stelle, da war Verfügbarkeit schon als wichtig eingestuft und man hat aber drauf geschaut und gesagt naja so viele Akteure gibt's eigentlich nicht die jetzt ein Interesse haben mir die Verfügbarheit runter zu spielen irgendwie uns zu dorsen oder so.

00:38:51: Und irgendwann im Kontext, damals war der Ukrainekrieg noch nicht neu ausgebrochen.

00:38:56: Das war vor der... Wann war das?

00:39:00: ...'s Jahr

00:39:00: zwanzig,

00:39:01: dreinzwanzig?

00:39:02: Ich glaub schon!

00:39:03: War noch davor aber relativ nah dran.

00:39:07: und dann kam plötzlich ein DDoS eingefreien.

00:39:11: Also wirklich wahnsinnig verteilt, relativ viel Datenrate mit unterschiedlich schlauen Requests.

00:39:19: also die waren eigentlich Das war ein klassisches Daten-Flooding, was dort stattfand.

00:39:24: Und da hatten wir damals tatsächlich keinen Schutz dagegen eingebaut, weil wir gedacht an Nährkosten nutzen.

00:39:29: mäßig ist das hier nicht sinnvoll und es hat sich dann tatsächlich geändert.

00:39:32: Also haben wir erstmal diesen speziellen Angriff gezielt abgewährt... ...und nachdem der zweite Angriff reinkam relativ bald strukturiert Schutz dagegen angeschafft.

00:39:45: Alles klar!

00:39:46: Vielen Dank, verdict Für eure Informationen und neue Kanäle.

00:39:53: Ciao!

00:39:53: Tschüss!