Cybersecurity Basement – der Podcast für echten Security-Content
Herzlich Willkommen im Cybersecurity Basement. In unserem Podcast spricht Michael Döhmen alle 14 Tage mit spannenden Gästen über Themen aus dem Bereich Cybersecurity. Dabei legen wir großen Wert auf Objektivität gelegt. Kein suresecure-Feature-Fucking, sondern ein seriöser, authentischer und ehrlicher Austausch aus Theorie und Praxis.
Der Podcast richtet sich an IT- und Security-Entscheider und alle, die es mal werden wollen. Hier gibts kein Blabla, sondern Security als Handwerk. Ehrlich auf den Tisch. Dabei übersetzen die Protagonisten Security in Business-Sprache und umgekehrt.
Zudem werden auch Gäste eingeladen, um andere Blickwinkel oder auch Kundenstimmen einzufangen. So geht es noch mehr in die Praxis und der Podcast bewegt sich auf Augenhöhe mit dem Zielpublikum.
Cybersecurity Basement – der Podcast für echten Security-Content
Detection Rules im SOC: Ein Blick unter die Motorhaube
Was macht ein Detection Engineer, und warum reichen standardisierte SIEMs und vorgefertigte Detection Rules nicht aus? Michael & Georg Lauenstein, Senior Detection Engineer bei suresecure, werfen einen Blick unter die Motorhaube des Security Operations Centers (SOC) und zeigen, wie sich echte Bedrohungen aus der Masse an Logdaten filtern lassen.
Besonders spannend: Ein Live-Test mit ChatGPT. Kann KI eine Detection Rule für schädliche PowerShell-Befehle erstellen? Das ernüchternde Ergebnis zeigt, warum menschliche Expertise, tiefes IT-Verständnis und kontinuierliche Anpassung im Detection Engineering unverzichtbar sind.
Wir freuen uns auf dein Feedback!
Möchtest du mehr über unseren Podcast wissen? Dann wirf einen Blick in unser Media Kit. Dort findest du alles Wichtige:
Cybersecurity Basement - Media Kit
Du findest uns auch auf:
(2) suresecure GmbH: Ihr Unternehmen | LinkedIn
@suresecure_de • Instagram-Fotos und -Videos
suresecure (@suresecure_de) | TikTok
Herzlich willkommen im Cybers ecurity Basement. So würde sich die Begrüßung anhören, wenn wir einen normalen Podcast hätten. Doch bei uns gibt es kein suresecure-Feature-Fucking und auch kein Blabla, sondern echten Security-Content. Willkommen im Keller. Und nein, du kannst jetzt nicht wieder raus.
Georg Lauenstein:Wir haben uns - oder das ist auch meine persönliche Philosophie - Mein Ziel ist es, unternehmen vor Angriffen zu sichern.
Michael Döhmen:Herzlich willkommen zu einer neuen Ausgabe von Cybers ecurity Basement, dem Podcast für echten Security-Content. Und diesem Titel wollen wir heute wieder mal komplett gerecht werden, denn heute geht es ans Eingemachte. Heute wollen wir mal den Blick unter die Motorhaube unseres Security Operations Center werfen und schauen was macht denn eigentlich ein Detection Engineer? Was ist eine Detection Rule? Wofür braucht man das? Worum geht es dabei genau? Wir sprechen ja häufig von Cyber Resilienz. Das ist ja ein ganz großer Begriff, der vieles umfasst, und so viel kann ich vorwegnehmen. Das Erstellen von Detection Rules und Detection Engineering, das ist tatsächlich eine Schlüsselrolle, wenn man möchte, dass auch individuelle Dinge in den Infrastrukturen beleuchtet werden. Was könnt ihr also heute von diesem Podcast erwarten und mitnehmen?
Michael Döhmen:Auf jeden Fall Insights zum Detection Engineering. Dann wollen wir auch mal den Unterschied aufdröseln zwischen einem normalen und einem Custom-SIEM. Ich kann mir eine SIEM-Lösung, also ein Security Information and Event Management-Tool, einkaufen und in der Standardausführung betreiben. Das ist aber nicht so gut wie mit individuellen Detection Rules. Darüber möchte ich heute auch sprechen, im dritten Part, wo wir uns damit beschäftigen wie sieht das Ganze eigentlich in der Zukunft aus? Denn mittlerweile können die LLMs wie ChatGPT und Cloud ja Code programmieren. Ich habe letztens gesehen, da hat sich jemand mit einem Prompt das komplette Pac-Man-Spiel bauen lassen als Code. Das konnte er dann auch tatsächlich spielen. Also, diese Lösungen sind ja schon sehr gut und umfassend, also steht da vielleicht auch eine Ablösung durch die AI bevor. Wir werden darüber sprechen. Und da ich natürlich viel zu wenig Ahnung davon habe, habe ich mir wieder einen Gast eingeladen, diesmal wieder einen Kollegen aus dem suresecure-Kosmos. Ich sage herzlich willkommen, Georg.
Georg Lauenstein:Einen wunderschönen guten Morgen. Michael, freut mich, hier zu sein. Ich bin gespannt, was ich heute erleben darf.
Michael Döhmen:Ich freue mich, dass du der Einladung gefolgt bist. Wir haben im Vorgespräch schon gemerkt, es ist vielleicht nicht ganz so deine Komfortzone, aber man muss ja ab und zu auch einfach mal da raus, um neue Dinge zu erleben, die Grenzen zu verschieben, und deshalb bin ich sehr froh, dass du da bist. Georg, stell dich doch zu Beginn einmal kurz vor und erzähl uns so ein bisschen, was du bei uns machst. Wir werden gleich natürlich noch die Hälfte darüber sprechen. Vielleicht mal so kurz deine Vita. Die ist nämlich sehr spannend, das kann ich schon mal vorwegnehmen.
Georg Lauenstein:Ich bin junge 39. Ich bin jetzt seit knapp ich glaube, im Juli sind es wirklich fünf Jahre bei der suresecure, und bisher habe ich jeden Tag genossen. Meine Aufgabe ist eben, wie schon erwähnt, Detection Engineering. Das ist aber nur der große Überbegriff von dem, was man da so tun kann. Es ist auch wichtig, was im Hintergrund läuft. Also, Aufgabengebiet sind auch zum Beispiel das Beschäftigen mit Blocktypen, erstellen von spezifischen Configs für bestimmte Produkte, alles, was so auch anfällt aus dem Bereich SOC Engineering, das Aushelfen in anderen Bereichen, zum Beispiel in der internen Security, beraten, mentoren oder Traineraufgaben, je nach Bedarf, und ja, das würde es so grob zusammenfassen, was ich so hier tue.
Michael Döhmen:Sehr gut, du kommst aber ursprünglich gar nicht aus der Security, oder?
Georg Lauenstein:Ja, ich bin ein Quereinsteiger und, wie schon erwähnt, ich bereue keinen einzigen Tag, diesen Schritt gegangen zu sein.
Georg Lauenstein:Ich komme ursprünglich aus aus der Luftfahrt und habe im vorigen Leben oder Berufsleben, besser gesagt, eben dafür gesorgt, dass die Flugzeuge von A nach B fliegen, im Sinne von nicht als Fluglotse, sondern meine Aufgabe war es, Anflugverfahren zu bauen, was auch bei uns in der Security wichtig ist, das, was man tut, auch entsprechend zu validieren, zu reviewen, auf Qualität zu checken, und das war auch am Ende meine Hauptaufgabe, eben wirklich zu überprüfen, bevor das dann ins Flugzeug geht, dass das alles korrekt ist, und ein Stück weit. Die Sachen, die ich damals gemacht habe, sind auch im Bereich Detection Engineering sehr, sehr wichtig. Und den Quereinstieg oder den Wechsel zur Informationssicherheit ist eigentlich durch einen kleinen Zufall entstanden. Ich bin schon seit Anfang an im Bereich Kita auch im administrativen IT tätig und da gabs mal einen Sicherheitsvorfall. Und das was ich da vorgefunden habe, hat mich so fasziniert, dass ich relativ schnell gesagt habe, ich möchte wechseln und will lernen, was das bedeutet. Wie ist das passiert? Warum ist es passiert?
Michael Döhmen:Top, also wirklich mit intrinsisch getriebener Motivation in die Security gewechselt.
Georg Lauenstein:Sozusagen.
Michael Döhmen:Sehr, sehr schön. Ja, für uns natürlich ein Segen, dass du auch schon fünf Jahre hier bist. Absoluter Wahnsinn. der Bereich, in dem du arbeitest, hat sich auch brutal weiterentwickelt. Jetzt nochmal ein, zwei schnelle Fragen an dich. Hast du auch schon mal eine Regel geschrieben, die vielleicht ein bisschen zu gut funktioniert hat?
Georg Lauenstein:Wie würdest du zu gut definieren? Also bedeutet das, die hat sehr schnell was gesehen oder gefunden, was wirklich zu gut war, weil wir dann dadurch eben Angriff verhindert haben, oder wie ist das gemeint?
Michael Döhmen:Das ist eine gute Rückfrage. Ich habe mir schon gedacht, dass diese Fragen nicht so ganz glatt durchlaufen werden.
Georg Lauenstein:Nicht jede Detektion läuft glatt durch. Die ist immer mit Optimierung Von daher.
Michael Döhmen:Noch eine Frage, auch vielleicht nicht so ganz ernst gemeint Wie würdest du dich selber detekten, wenn du ein Angreifer wärst?
Georg Lauenstein:Puh, ist auch ne sehr gute Frage. Auch gar nicht so einfach. Ein Detection Engineer sollte nicht nur das Wissen über Detection Engineer besitzen. Ich besitze halt auch das Angreiferwissen, und es gibt, glaube ich, da nicht viele Wege, um Leute anzugreifen, die eben aus dem Bereich kommen. Und da ist wahrscheinlich der erste Anfang über E-Mail-Möglichkeit wie Phishing oder Social Engineering. Aber selbst dann ein geübter Detection Engineer oder auch eben ausgebildeter Penetration Tester zum Beispiel, der kennt natürlich auch die Angriffsvektoren, weil es auch eine Aufgabe ist, als Detection Engineer, sich damit zu befassen. Jeder Angriff ist unique. Es vergeht kein Tag, wo neue Angriffsmechanismen rauskommen. Es ist sehr, sehr wichtig, in dem Bereich immer up-to-date zu bleiben. Ich würde behaupten, es ist schwer, mich anzugreifen, weil ich auch viel dafür unternehme, eben so ein bisschen unter dem Radar zu bleiben. Und wenn doch ja, der Zuhörer kann sicherlich mit Suchmaschinen mal schauen nach Namen oder Informationen und dann es probieren, wenn er möchte.
Michael Döhmen:Ne, wir wollen keinen Aufruf starten, Georg besser nicht. Nee, nee,
Georg Lauenstein:Das war ohne Spaß gemeint aber es ist ein Angriffsvektor, den ich jetzt sofort sagen kann. Wie man mich angreifen kann, keine Ahnung. Ich würde wirklich sagen, also wenn ich es probieren würde, dann wäre es wirklich über ausgekügelte Social Engineering-Taktiken mit einer super fringierten E-Mail. Aber selbst dann durch mein Vorwissen, auch als ebener SOC-Analyst Forensiker und eben auch das Wissen über Angriffstechniken, das ist auch schwierig. Dann, Und wenn ich selber Angreifer wäre, würde ich wahrscheinlich auch sehr erweiterte Angriffsmöglichkeiten nutzen und nicht die Standardsachen.
Michael Döhmen:Das heißt aber auch, dass du zu Hause dein Heimnetzwerk quasi schon ordentlich abgesichert hast.
Georg Lauenstein:Ja, Ich würde behaupten ja, ja, also, ich investiere sehr viel Zeit und auch versuche natürlich auch, Familie, Freunde oder wenn da Fragen sind, auch beratend zur Seite zu stehen. Da beginnt es wie kann man den Account eben sicher machen, gute Passwörter verwenden, Passwortverwaltungstool verwenden, nicht Standardpasswörter A, b, c, 1, 2, 3 und vor allen Dingen auch nicht immer die gleichen Passwörter, Passwörter. Ich finde es auch wichtig, nicht nur ein Business Case, sondern eben auch im privaten Leben, weil wir haben ja vor 20 Jahren auch nicht einfach einen Brief aufgemacht, den wir nicht kennen, den Absender, sondern wir haben auch vorher geschaut kennen wir den Absender, und wenn ja, dann mache ich vielleicht die Post.
Michael Döhmen:Und haben ihn dann trotzdem geöffnet. Ja, das machen wir heute Immer, reglos weggeschmissen natürlich. Okay, dann lass uns mal einsteigen, weil es sind jetzt durch diese Fragen auch schon ein paar Fachbegriffe gefallen, und um das ganze Thema für die Zuhörerinnen und Zuhörer mal einzuordnen, gehen wir mal rein ins. Was ist eigentlich dieses Detection Engineering, und wofür brauche ich das? Was genau ist es? Georg, kannst du das vielleicht so erklären, als würdest du es Kindern erklären? Hast du deinen Kindern schon mal erklärt, was du tust?
Georg Lauenstein:Ich beantworte es, als meine Große gefragt hat stell dir einfach ein Buch mit ganz vielen Informationen, drin Zeilen, und dein Papa versucht eben, aus diesen Informationen das rauszu extrahieren, was wichtig ist, und wenn da was drin ist, was eben für einen gewissen anderen Bereich in Frage käme, baut er gewisse Regeln, um das zu erkennen. baut er gewisse Regeln, um das zu erkennen. Detection Engineering ist einfach der Oberbegriff, um aus vielen Informationen, aus verschiedenen Logs eben Dinge zu erkennen, die für einen Angriff in Frage kämen, kommen würden. Zum Beispiel ein Detection Engineer versucht eben frühzeitig aus der Fülle an Informationen Dinge rauszubekommen, um das, was das SOC dann eben analysieren soll, eben zu detekten und entsprechende Gegenmaßnahmen zu ergreifen.
Michael Döhmen:Einen Moment. ich glaube, wir müssen noch mal kurz was Zusätzliches erklären, und zwar du hast jetzt da die Begriffe SOC auch wieder ins Spiel gebracht, das Security Operation Center, wo eben ganz viele Log-Dateien ankommen, und dadurch entsteht einfach ein großer Wust an Informationen. Und deine Regeln, die du ja schreibst, die machen diese Daten dann am Ende wirklich zielführend nutzbar. Jetzt lass uns das mal kurz abgrenzen, damit es nochmal klar wird was unterscheidet ein Detection Engineer jetzt von einem klassischen SOC-Analysten?
Georg Lauenstein:Ich würde mal sagen, der SOC-Analyst konsumiert Detection Rules und zieht daraus. also, der SOC-Analyst hat ja die allgemeine Aufgabe eben an also die Alarme, die reinkommen in einem SIEM oder in einem Automatisierungssystem wie zum Beispiel in SOAR, die Angriffe anzunehmen, zu bearbeiten, zu analysieren und Schussbeugungen daraus zu ziehen, ob das jetzt ein Angriff ist, ob es erstmal nur eine Anomalie ist oder eben vielleicht ein Alarm, den ich erstmal melden möchte, weil der mir vielleicht komisch vorkommt, und der nutzt da natürlich dann eben diese Detection Rules, und wenn es die nicht geben würde, dann hätte er auch nicht die entsprechenden Alarme in seinem SIEM oder im SOAR. Ja, das wäre kurz knapp die Antwort
Michael Döhmen:Jetzt haben wir grad noch eine neue Abkürzung reinbekommen SOAR. Kannst du vielleicht auch noch mal kurz erklären? das SIEM habe ich jetzt vorhin schon mal kurz erwähnt, aber SOAR hatten wir noch nicht.
Georg Lauenstein:Ja, das hatten wir ja schon mal in anderen Podcasts vorhin. Das ist ja dieses Security Automation, Orchestration and Response. Da muss man sich vorstellen, früher war immer nur das SIEM, das Auffangbecken, würde ich sagen, von allen möglichen Logquellen, wo dann einfach nur mithilfe von SIEM den sogenannten Dashboards die ganzheitliche Informationen bereitgestellt wird. Und das heißt aber noch lange nicht, dass ich eben dann dafür Erkennungsregeln habe oder Detection-Words, die dann eben mögliche Anomalien detekten, sondern das SIEM ist ja nur Auffangb ecken. Mithilfe von Erkennungsregeln werden dann eben Alarmen erstellt, und mein SOAR bietet mir dann die Möglichkeit, eben auch auf diese Alarme zu reagieren, und zwar automatisiert mithilfe von Playbooks. Das muss man sich vorstellen, dass, wenn ein Alarm reinkommt von einem bestimmten Produkttyp, wie zum Beispiel EDR oder ein anderes Tool, gibt es im Hintergrund eben sogenannte Playbücher oder Spielbücher Kann man nicht so wirklich übersetzen, aber eigentlich wieder ein System, was dazu führt, dass man eben die Sachen automatisiert abarbeiten kann, um den Analysten im SOC oder CDC zu unterstützen.
Michael Döhmen:Ich glaube, das Playbook kennt man zum Beispiel auch von der NFL oder so. Die haben ja auch ihr Playbook beim Football. Das sind ja so einzelne Spielzüge, wenn das eine passiert, dann wissen alle genau okay, das ist der nächste Zug, das ist der nächste Zug, das ist der nächste Zug. Und bei diesen Playbooks, wenn ich das mal richtig verstanden habe, ist es doch quasi genauso. Also, es läuft immer ein gewisser Spielzug durch, so ähnlich ja, ich würde Spielzug durch, So ähnlich.
Georg Lauenstein:Ja, ich würde das. Aus dem Fußball hat man ja auch Checklisten oder Taktiklisten, was man jetzt vielleicht Playbook sagen kann, wo gewisse Züge drinstehen.
Michael Döhmen:Ja, das stimmt. Die Experten sprechen immer von den Automatismen, die greifen.
Georg Lauenstein:Automatismen! ja, genau Weil die Frage ist wenn da ein Alarm reinkommt, was mache ich damit? Gehe ich jetzt manuell weitersuchen? oder wenn ich schon weiß, da kommt was an, was eben maliziöse Bewegungen aufweist, kann ich das vielleicht automatisiert schon weiter zusammenarbeiten oder weiterverarbeiten, dass der Analyst nicht manuell suchen muss, sondern es gibt Systeme, die können das automatisiert, und das macht eben auch ein SOAR. Und wenn eben was erkannt wurde, wie schnell kann ich reagieren, bevor ich eben anrufe hey, du musst jetzt den User vielleicht vom System isolieren. das kann auch ein Automatisierungsgrad eben tun wie ein.
Georg Lauenstein:SOAR mithilfe von verschiedenen Techniken, die im Hintergrund da eine wichtige Rolle spielen.
Michael Döhmen:Okay, wenn ich dich richtig verstanden habe, was ist jetzt das übergeordnete Ziel des Detection Engineering?
Georg Lauenstein:Da geht es ja dann am Ende drum, eine Reaktionsfähigkeit herzustellen, Genau ich würde sagen, es ist eine Kombination aus Prävention, eine gewisse Transparenz und eben diese schnelle Reaktionsfähigkeit, frühzeitig auf gewisse möglichen Angriffen zu reagieren oder eben auch präventiv mögliche Anomalien zu erkennen und eben schnell zu handeln. Also ist die Anomalie wirklich ein Angriff, ist die Anomalie legitimes Verhalten, was aber Angreifer-Techniken nacheifert oder nachsimuliert, ist also ein bisschen wie ein Frühwarnsystem schaffen, um frühzeitig Bedrohungen zu identifizieren oder eben auch zu unterbinden und eben gesamtheitlichen Schaden im Unternehmen zu vermeiden.
Michael Döhmen:Das Detection Engineering ist da jetzt nichts, was Jedes Unternehmen hat, also nicht jedes Unternehmen hat ja einen Detection Engineer wie dich oder mehrere sogar davon. Und wie machen die das denn dann? Also, kommt man auch ohne Detection Engineering aus in seiner Sicherheitsstrategie, oder sagst du also ganz ehrlich, eigentlich ist es schon eher so ein Pflichtbestandteil.
Georg Lauenstein:Ich finde, es ist abhängig von Unternehmensstruktur, wie das Unternehmen welche Produkte hat oder verwaltet und wie wichtig ihre eigene IP ist oder das Interactive Property, was das Unternehmen eben bereitstellt. Für Konsumenten da draußen oder eben welcher Art auch immer Produkte, braucht man immer einen Detection Engineer. Für Konsumenten da draußen oder eben in welcher Art auch immer Produkte, braucht man immer einen Engineer. Jeder Engineer würde natürlich sagen klar, das machen wir halt, reichen ein normales, oder sagen wir es mal anders wir haben ein Unternehmen, was einen SIEM hat, egal welches Produkt, und dieses SIEM hat natürlich auch schon sogenannte Default Detection Rules. Also ich glaube, jeder Vendor da draußen irgendwelche Art auch eben standardisierte Erkennungsregeln, die man natürlich auch verwenden kann. Die Schwierigkeit ist halt die Standardregeln auf sein Unternehmen zu adaptieren. eben genau diese standardisierten Rules zu aktivieren, die dann mir auch als in dem Unternehmen helfen, gewisse Angriffe zu erkennen. Detection Engineering kann eben schnell individuell und komplex werden, und meiner Erfahrung nach reichen eben diese standardisierten Use Cases für den Anfang meistens aus.
Georg Lauenstein:Es ist aber wichtig, das zu überprüfen, weil man muss immer im Hinterkopf behalten, die Unternehmen, die auch eben die standardisierten Rules bauen für ihre SIEMs, nutzen zur Validierung meistens fiktive Angreifersysteme oder Strukturen und vergessen oft eben diesen realen Zustand, wenn man wirklich diese Detection Rules ausrollen würde beim kleinen Unternehmen, mittelständischen oder großen, weil es gibt halt eine Menge Rauschen im Hintergrund. Also mit Rauschen sind legitime Sachen, die halt laufen im Unternehmen, was normal ist. Und die Kunst ist jetzt eben, Detection-Rules zu bauen, die einerseits eben mögliche Angriffe zu erkennen oder frühzeitig erkennen, aber eben auch so gebaut sind, dass dieses Noise, was wir immer haben, das Rauschen ist ständig da eben relativ reduziert zu haben beziehungsweise die Rule wirklich nur dann in dem Fall triggert, wenn wirklich was ist. Und das ist nicht einfach, das ist sehr schwer, das ist die Kunst.
Georg Lauenstein:Und es gibt generalisierte Use Cases bei jedem SIEM-Anbieter nutzen auch andere Quellen, die auch Detection Engineers nutzen. Aber ich finde, individuell ist es nur machbar mit einem Detection Engineer, der das Unternehmen kennt oder die Unternehmen kennt, wenn man als MSSP zum Beispiel fungiert. Man muss die Umgebung kennen, um darauf eben dann auch entsprechend zu reagieren. Ich finde es schwer zu sagen,
Michael Döhmen:Und das Business wahrscheinlich auch, oder?
Michael Döhmen:Also man muss ja das Geschäft verstehen. Womit verdient das Unternehmen jetzt quasi sein Geld? was ist besonders schützenswert, um dort vielleicht auch nochmal verstärkt Detection Rules irgendwie einzusetzen, einzubauen, und die müssen dann natürlich irgendwie custom sein. Du hast es die Hersteller schon mal angesprochen. Dazu noch eine Rückfrage. Also ich habe es richtig verstanden, dass die Hersteller selber natürlich auch Detection Engineers haben. Die bauen Detection Rules, die sie aber eher als Standard Detection Rules dann deklarieren. Die bringt die Software quasi mit, die ich bei mir implementiere. Habe ich darauf Einflussnahme? Also kann ich auch beim Hersteller theoretisch Custom Detection Rules beantragen.
Georg Lauenstein:Meinst du mit Software zum Beispiel Produkte wie ein EDR, ein XDR Ja, oder auch Also Endpoint Detection Response oder auch ein SIEM? Also bei dem SIEM ist es so, dass da ist man relativ transparent Also die SIEMs Einstiege nahm wie in Splunk oder QRadar, da bieten da schon eine Möglichkeit, reinzuschauen und auch dann Selbständerung vornehmen zu können. Man kriegt auch Dokumentationen, da wird auch beschrieben, wie das funktioniert, und kann dann eben entsprechend auch Anfang selber individuell auf sein Unternehmen geschnitten eben Erkennungsregeln zu bauen. Die Frage ist, ohne Vorwissen im Bereich Detection Engineering ist es sehr schwer, glaube ich, erstmal eine Rule zu bauen, weil man muss sich mit dem Produkt auseinandersetzen, und nicht nur das, man muss das erstmal verstehen.
Georg Lauenstein:Also die Sprache hinter dem SIEM muss man verstehen, und eben auch, was man dann eben erkennen möchte, und eben auch, was man dann eben erkennen möchte. Im EDR-Bereich ist es so, dass das eben leider nicht so transparent ist. Man hat meistens nur einen Einblick, was für Rules gerade aktiv laufen, dass man da sieht, wie die einzelnen Vendoren Sachen detektieren, sondern eher, ich habe vielleicht die Möglichkeit, auch wieder eine Custom Detection Rule zu bauen mit deren Format in deren Format und in ihrer Technik, aber ich habe nicht die Möglichkeit zu hinterfragen hey, wie habt ihr das jetzt eigentlich gebaut, dass das eben jetzt so erkannt wird, was eben wichtig ist, weil wenn es eben viele falsche Alarme gibt im SOC, das hat Einfluss auf das tägliche Arbeiten, und wenn es da eben sehr, sagen wir mal, noisy Rules gibt so nennen wir das die sehr viele Alarme eben triggern, dann ist das eher hinderlich und nicht förderlich für den normalen SOC-operativen Betrieb. Da kommen wir wieder zu dem Eingangshin. Es ist wichtig, eine Detection Rule zu bauen. Sie hat ja die Aufgabe, was zu detekten, also einen möglichen Angriff, ein anderes Werkzeug, ein anderes Vektor oder eine Anomalie, die zu mehr führen könnte. Da ist es wirklich wichtig, die Unternehmen zu kennen, die Umgebung zu kennen, und es ist schlichtweg unmöglich, das nur mit einem, sagen wir Angriffs fiktiven Umgebungs-, Laborumgebung eben hinzubekommen, weil dort ist meistens immer nur die Frage hey, läuft meine Detection? Also, wenn ich jetzt einen Angriff ausführe, und ich nehme jetzt diese, die ich gebaut habe, sehe ich den Log-Eintrag Wahrscheinlich. Aber was ist drumherum? Also wie viel Rauschen, wie viel Falschalarme würde das auch noch produzieren? Und das ist wichtig, und das kann meiner Meinung nach der Vendor auch nicht, weil er kann ja nicht in jedem Unternehmen reingucken, vorher, bevor er diese Detection Rule veröffentlicht.
Georg Lauenstein:EDR und XDR. Es ist schwierig, in den standardisierten Rules reinzuschauen, bis gar nicht. Daher kommt es dann auch vor, dass wir dann halt sagen okay, wir haben hier zwar einen guten EDR-Produkt, aber die Detection Rules, da würde ich schon gerne wissen, was da gerade passiert. Und wenn wir so eine Fälle haben, dann versuchen wir auch zu kommunizieren, zu fragen hey, was ist da drin? Könnt ihr das vielleicht auch anpassen, dass es eben nicht so viel Alarme? oder welche Möglichkeiten habe ich mit eurem Tool, mit eurem Produkt bei uns diese Falschalarme zu reduzieren?
Michael Döhmen:Verstehe ich?
Michael Döhmen:Das heißt also EDR, XDR-Hersteller, hat man wenig Transparenz über das, was dort eigentlich passiert. In den einzelnen Rules Im SIEM/SOAR-Bereich bin ich etwas flexibler, aber habt ihr auch richtig verstanden jedes SIEM/SOAR hat quasi eine eigene Sprache, in der ich diese Regeln auch anlegen muss. Das ist natürlich auch schon mal ich sag mal unvorteilhaft.
Michael Döhmen:Da musst du sich immer
Georg Lauenstein:Es ist wie eine neue Sprache, die man lernen muss,
Michael Döhmen:immer neu reindenken.
Michael Döhmen:Wir werden später mal versuchen, so eine Detection-Rule mit ChatGPD zu bauen. Da kommen wir später noch zu sprechen.
Georg Lauenstein:Klingt interessant.
Michael Döhmen:Was ich mich Frage als Detection-Engineer jetzt nehmen wir mal so eine normale Arbeitswoche. Wie viel von den fünf Tagen bist du beschäftigt mit der Entwicklung von Detection-Rules? Also, gibt es du hast ja gesagt, das sind ja immer spezielle Cases für ein Unternehmen Gibt es da so viele Anforderungen, dass du quasi durchgehend Custom Detection Rules baust? oder ist auch viel Testing gefragt, überprüfen? Nimm uns mal so ein bisschen mit in deiner Arbeitswoche.
Georg Lauenstein:Also die erste Frage ist wir haben uns mal das Ziel vorgenommen, wenn wir Rules bauen, dann soll wenn möglich jeder Partner bei uns davon profitieren. Also, das bedeutet, es hat nicht jeder Partner Custom Rules. Wenn wir oder wenn ich Detection Rules baue, dann profitieren alle Partner, Weil es kommt auch ein bisschen darauf an, in welchem Bereich die Partner zugegen sind, ob das weit international gestreut ist. Da gibt es durchaus Unterschiede im Angreiferraum, dass, wenn die Angriffe im Bereich USA, Russland oder Östlicherseits sind, die sogenannten Angreifer oder Sweat-Aktoren anders als vielleicht in Europa oder so, Und je nach ich sage jetzt mal Partnerpalette, also wie viel Customer ein Unternehmen vielleicht noch als MSSP verwaltet, muss man entsprechend auch sein Detection Engineering aus, wie sagt man, ausrichten.
Georg Lauenstein:und wir haben uns, oder das ist auch meine persönliche Philosophie, mein Ziel ist es eben ja, Unternehmen vor Angriffen zu sichern, und bei Bedarf ja kann man Custom Rules bauen. Das ist zum Beispiel je nach Spezifik. gibt es halt zum Beispiel einen Partner, der hat ein ganz spezielles Produkt, und der möchte maßgeschneiderte Erkennungsregeln dafür haben, Dann ist das natürlich möglich. Aber meine Philosophie ist wenn ich was baue, dann profitiert jeder davon. Also, ich mache da keinen Abstrich. Das können wir da erkennen, und das ist auch wichtig. und damit das funktioniert, muss man auch eine gewisse Baseline eben haben, damit es eben auch allgemein zusammenwirkt, sozusagen.
Michael Döhmen:Und das heißt, du schreibst eine Detection-Rule für ein neues Angriffsszenario, wie auch immer, und diese Rule übertragen wir direkt auf alle Partner in unserem SOC, sozusagen. Ja, es fließt quasi in unser suresecure Detection-Rule Deck ein ja, und dann ist da eine neue Regel drin. Genau Okay, das kann mal von dir selbst kommen, weil du was entdeckt hast, was gesehen hast, oder aber auch von einem Partner, der eine Anforderung stellt. Du setzt die um in einer Detektionsschule, und dann profitieren auch wieder alle davon.
Georg Lauenstein:Also auf die Eingangsfrage zurückzukommen wie sieht ein normaler Tag aus? also viel, viel lesen, sich mit der Aktualität beschäftigen. Was ist gerade in der weiten Welt der Security los? gibt es vielleicht gerade eine aktive Fachstelle, da man sich mit den Partnern ja auseinandersetzt? also während des Onboardings lernt man die Umgebung kennen, weiß ich natürlich auch, was die Partner da draußen so für Tooling haben, so insbesondere und das kommt mit der Zeit als SOC-Analyst oder als Forensiker weiß man irgendwann, was da halt normal durch die Gegend läuft als Produkt. Und wenn man jetzt halt Anhaltspunkte in der Nachrichtenwelt für Cyber, gewisse Schwachstellen für ein Produkt X findet und weiß im Hinterkopf ah okay, das könnte jemand von uns haben, dann ist man natürlich dann auch damit beschäftigt zu überlegen kann ich das detektieren? Hat das Einfluss auf unser Unternehmen? Also, wenn es zum Beispiel uns betrifft, gibt es da was, was wir sofort umsetzen müssen, also sehr schnell reagieren müssen Im Sinne du musst innerhalb von einer halben Stunde jetzt eine Rule bauen, dann wird das überall ausgerollt, und vielleicht nach den ersten zehn Minuten gibt es dann schon ein Event, und wir sehen ah okay, der ist wirklich betroffen.
Georg Lauenstein:Oder man sagt auch wir gehen weiter, wir gehen nach gewissen Sachen, jagen oder handeln Das ist halt ein anderer Begriff wieder Threat Hunting Hunting dass wir mithilfe der Informationen, die wir rausfinden oder insbesondere ich brauchen wir dann spezifische Suchen, wie du auch schon gesagt hast. Das ist in jedem Sinne eine andere Sprache, und wir suchen nach diesen Indikatoren in jedem dieser Partnerumgebungen. Oder wir nutzen diese Suche, packen die in unser SOAR, und das sucht automatisch nach diesen Sachen, um frühzeitig eben zu erkennen, ob da jetzt auch diese Schwachstelle der Partner betroffen ist, zum Beispiel Wir haben das ja auch in der Vergangenheit mal gemacht dass wir das dann auch auf dem Blog vielleicht veröffentlicht haben, wenn irgendwas Großes ist.
Georg Lauenstein:Das entscheiden wir je nach Situation und wie gefährlich das ist, wie wir je nach Situation, und wie gefährlich das ist, wie damals eben bei jeder hat das schon mal gehört Lock4J Schwachstelle, wo jeder da draußen ja schnell reagieren musste, um gewisse Maßnahmen zu ergreifen.
Georg Lauenstein:Also, mein Tag beschäftigt es ja mir, recherche zu schauen, wie die Informationen, die ich dort finde, gesammelt, ich vielleicht in eine Detection Rule packen kann oder bereits verschiedene Detection Rules optimieren kann, weiter. Es vergeht eigentlich auch kein Tag, wo ich mal nicht eine Detection Rule anfasse und die entsprechend optimiere, oder vielleicht die Informationen, die ich auch durch die anderen Bereiche, wie der SOC, wie unseren Forensiker, einem Incident Response die geben mir natürlich auch Informationen aus bestehenden aktiven Cases oder eben Vorfällen, die ich damit reinbringen kann. Oder eben das größte Thema ist eben dieses Rauschen, was jedes Unternehmen hat, und es ist auch so, dass Falschalarme vorkommen, und da ist es halt wichtig, schnell zu reagieren und eben auch diese Falschalarme eben zu reduzieren, indem man vielleicht die Ruhe so anpasst, dass sie entweder unter anderen Umständen erst regert, oder man packt eben Filter rein, damit es erst gar nicht auftritt, weil ich eben weiß, das ist ein legitimes.
Michael Döhmen:Verhalten. Kannst du uns mal so ein typisches Beispiel für eine Falschmeldung geben? Was ist sowas, das dir immer wieder begegnet?
Georg Lauenstein:Ja, wenn du den Rechner anmachst oder auch ich, gibt es ja immer Programme, die im Hintergrund immer starten, also sogenannte Autostartprogramme, die immer da sind. Das kann der PDF-Client sein, den wir brauchen, um Sachen zu drucken virtuell oder eben Sachen im PDF-Format zu öffnen. Das kann ein Tooling sein, was bei jedem Autostart, also bei jedem Starten des Rechners eben neu gestartet wird, und das passiert automatisch, weil du brauchst es, um zu arbeiten. Wir nennen es eben Autostartprogramme.
Georg Lauenstein:Und da gibt es in jedem Unternehmen bestimmte Skripte, die immer laufen, und die sind natürlich noisy, weil je größer das Unternehmen, desto mehr Skripte laufen parallel, und manchmal haben diese Skripte eben Angreifervektoren drin oder Ähnlichkeiten zu normalen Angriffswerkzeugen, und das sind Dinge, die immer sehr noisy sind, und da muss man frühzeitig das machen wir bereits im Onboarding aber auch wenn der Partner schon eine lange Zeit bei uns ist, kann es vorkommen, dass dann wieder neuere Tools reinkommen, und die muss man natürlich filtern, weil sonst hat man eben Falschmeldungen, die man einfach nicht haben will Ein Haufen Alarme, die du nicht brauchst, weil der Autostart von einem PDF-Client der ist ja ein legitimer Start, wie du sagst brauche ich zum.
Georg Lauenstein:Arbeiten, kann aber eben auch als Angreiferwerkzeug von einem Angriff genutzt werden, weil ich als Angreifer will ja auf dem System bleiben und versuche dann eben, meine maliziösen PDF-Dokumente oder eben Software dann eben auch via Autostart zu verteilen.
Michael Döhmen:Die Rule dahinter. Die kann quasi identifizieren, ob es jetzt ein valider, legitimer PDF-Kleinstart ist oder ein malizöser. Würde das unterscheiden können.
Georg Lauenstein:Ich würde sagen, die Antwort wäre, ob es eine legitime Anwendung für dieses Unternehmen ist. Also ist das legitim für dieses Unternehmen? X? Jedes Unternehmen hat andere Programme, und sowohl die SOC-Anlysten als auch wir oder ich im Detection Engineering kennen irgendwann genau diese Standard-Verhaltensmuster, und man sieht sehr schnell, wenn das von dem normalen Verhalten abweicht, und dafür gibt es dann entsprechende Rules
Michael Döhmen:Wie komplex können so Rules denn werden?
Michael Döhmen:Also ich glaube, ja, ich habe dir jetzt interessiert zugehört aber mitunter werden diese Rules, wenn es dann nur um ganz spezielle Use Cases in verschiedenen Programmen oder Prozesse sind, die dann in Abhängigkeit zu was anderem widerstehen, dann kann so eine Kette auch relativ komplex werden. Ja, Es gibt so ein Case, wo es sagt boah, ich hatte hier mal so eine Detection Rule, keine Ahnung, da saß ich sieben Wochen dran, weil das war so ein Berg an Verkettungen und Zusammenhängen.
Georg Lauenstein:Also es gibt bei uns auch Detection Rules, die einen kompletten Angriff nicht von A bis Z, aber gewisse Stationen eines Angriffs simulieren. Also, wenn ich als Angreifer auf ein System komme, tue ich Dinge, anschließend tue ich etwas anderes, was auch wieder ein Angriffswerkzeug darstellt, und das geht so weiter, Und man kann solche Stationen oder Stages, wie wir das nennen, auch als Detection-Rule darstellen, Und dann wird so eine Detection-Rule natürlich sehr komplex. Man definiert meistens zwischen einer ich habe eine Signatur, die ich gerne erkennen will wie ein Angriffstool. Zum Beispiel wir nennen es jetzt einfach mal Mimikatz, das ist ein Hacker-Tool als Beispiel, und da kann ich sehr schnell eben eine Rule bauen, um das zu detektieren. Vorausgesetzt, der Angeleifer unternimmt keine Möglichkeiten, eben diese Standardsignaturen zu verschleiern, Dann würde mir eine signaturbasierte Detection Rule nicht mehr helfen, weil der Angreifer so schlau war, die Signatur zu fälschen, zu ändern und dann hilft dir die signaturbasierte Detection Rule einfach nicht mehr. Und dann gibt es eben sogenannte Multi Event Management Detection Rule, die dann nicht nur auf eine Rule schauen, sondern auf mehrere.
Georg Lauenstein:Also als Beispiel, ich log mich einfach auf einem System ein wie ein Windows, das kann vor dem Bildschirm sein, das kann via Cloud, via dem Active Directory, was ja sehr wichtig ist bei jedem Unternehmen. Und anschließend möchte ich wissen, was der User danach tut. Nach dem Einloggen startet er vielleicht ein bestimmtes Programm oder lädt irgendwas hoch. Ich kann für all diese Stationen eine gewisse Detection-Rule bauen, das kombinieren und daraus eine Korrelierung also ist das eine Behavior-orientierte, eher eine Anomalie-Kette erkennen, und das führt dann dazu, dass, wenn solch ein Alarm triggert, dann ist da definitiv irgendwas komisch. Kann auch nur eine Anomalie sein, dass ein Admin Dinge tut die er nicht machen soll.
Georg Lauenstein:Vielleicht Sonntagnachts um drei hat er irgendein Problem festgestellt. Es gibt eine Ruhe, wirkt für uns im SOC Sock oh Gott, da ist jetzt irgendwas. Aber nein, es stellt sich dann nach einem kurzen Telefonat raus ja, er macht wirklich Wartung, und das ist auch schon mal in der Vergangenheit passiert. Aber ja es gibt solche Detection Rules bei uns, die genau auf solchen Verhalten oder Anomalien schauen und dann eben bei Bedarf eben auch triggern.
Michael Döhmen:Danke für die kleine Reise durch die Komplexität von Detection Rules. Meine Frage im Zeitalter von künstlichen Intelligenzen und unterstützenden Systemen, nutzt ihr auch KI als unterstützende Technologie in der Erstellung von Detection Rules oder bei der Analyse?
Georg Lauenstein:Ich würde sagen, jeder sollte KI nutzen. Man muss eben nur genau definieren, für welche Tätigkeit das sinnvoll ist. Im Bereich Detection Engineering kann ich die KI als Unterstützungswerkzeug nehmen, gerade so, wenn es darum geht. Such mir mal Informationen über ein bestimmtes Angreifer-Tool raus. Ich habe vielleicht ein Report und kann nicht ganz alles so schnell verstehen, weil ich möchte gerne eine Zusammenfassung haben. Dann ist es auch mal so, dass ich die AI nutze, um mir eine Zusammenfassung zu geben von sogenannten Attack-Vektoren, und daraus basierend baue ich dann entsprechende Detection-Rules, je nachdem, ob ich sie jetzt bei allen unseren Partnern als mögliches Angreiferwerkzeug erkenne oder nicht oder einsetzen würde, und versuche dann natürlich, entsprechende Gegenmaßnahmen zu ergreifen. Und fo lgende Rule Man kann die AI nutzen, um die Basisstruktur einer Rule zu bekommen. Es wird niemals ausreichen, um eine fundierte Detection-Rule daraus generieren zu können, weil erstens ist das Format immer unterschiedlich.
Georg Lauenstein:Die KI weiß auch nicht wirklich, wie das Format in deinem SIEM jetzt aussieht, was du für Sachen nutzt, für Felder und so weiter. Das kann die KI von vornherein nicht machen. Es ist da auf jeden Fall wichtig. So viel Information. Und da sind wir ja beim wichtigen Punkt wie viel Information darf ich mit dieser KI eigentlich teilen, damit ich eine Detection-Rule machen soll? Es kommt auch mal vor, dass Detection-Rules gebaut werden aus Grund von sensiblen Informationen Die weiß nur der Engineer, und darauf basiert bis jetzt eine Detection-Welt entstanden. Ich muss mir also wirklich bewusst sein, wenn ich da was reinpacke, weiß ja jeder, dann wird das auch weiterverwendet für das Maschinenmodell in der KI und wird weiter für den Lernprozess genommen. Aus meiner Erfahrung ist es nützlich zu nehmen für sogenannte Metadaten-Discretion-Beschreibung von Detection-Rules. Es gibt mehr Informationen, mögliche Falschalarme. Das kann man dann auch schön vergleichen mit realen Umgebungen. Aber ich würde nicht behaupten, dass mir die KI dabei hilft, eine komplette Detection Rule zu erstellen, die genau das macht, was ich haben will.
Michael Döhmen:So da, an dem Punkt sind wir jetzt angekommen. Jetzt schreibe ich eine live im Podcast. Und zwar habe ich mir im Vorfeld überlegt ich mache was relativ Simples. Ich lasse mir eine Detection-Rule schreiben zum Thema Erkennung von schädlichen PowerShell-Befehlen Das ist was, was ich schon häufiger in Incidents gehört habe, PowerShell-befehle, nix gut Und ich lasse mir das jetzt schreiben in der Sprache für den Vendors blank, und ich lasse mir das jetzt schreiben in der Sprache für den Vendors blank, und es ist schon fertig. Ich würde dir jetzt schicken, und du sagst mir jetzt mal, wieso das so einfach nicht ist. Also als Zuhörerin und Zuhörer könnt ihr das natürlich jetzt nicht sehen, aber hier steht Index gleich Windows, source, type und so weiter. Also ich kann es überhaupt nicht verstehen. Search Invoke, mimikatz or App, mp, preference or Download String. Georg, sag mir mal bitte, was hältst du jetzt von dieser Detection Rule? Warum kann ich die so nicht einfach in meinem Splunk einsetzen?
Georg Lauenstein:Ja, also die ist im ersten Anblick, wenn ich das sehe, zu breit gebaut, sagen wir im Detection-Engineering. Also sie ist zu generalisiert. Wenn ich das so implementieren würde, gibt es viel zu viel falsche Rahmen.
Georg Lauenstein:Denn es gibt ganz, ganz viele Tools da draußen, die, wie schon mehrmals erwähnt, auch ähnliches Kommandozeilenbegriffe nutzen, um Sachen zu tun. Also wenn ich ein Tool habe, was Dinge aus dem Internet runterlädt das ist zum Beispiel dieses Download-String dann lade ich, was runter. Also dieses Download-String ist, wenn ich das so, das ist ja ein OR-Statement, also nach den ersten drei in InvokeMimikatz oder in AdMPPreference. Das ist eine Ausnahme für ein EDR-Tool, und Download-String ist zu breit, also zu grob, zu generalisiert. Die Höhle muss viel feiner sein, damit man was detecten kann.
Michael Döhmen:Das heißt, er würde jetzt bei jedem Download, den ich anstoße würde, diese Detection-Rule sagen Alarm,
Georg Lauenstein:ja genau, es würde eben sofort alarmiert werden, wenn dieses Download-String irgendwo vorkommt. Und da haben wir mehrere Beispiele Kommt immer auf den Partner an. Es gibt Partner, die haben sehr viel Skriptsprache, wie PowerShell, wie du gerade schon gesagt hast. Es gibt Partner, die verwenden das nicht so oft. Hast du aber einen zum Beispiel im Bereich Engineering-Unternehmen oder diese auch sehr technisch versierte Sachen, die haben ganz viele Skripte im Einsatz. das würde zu ganz viel Fehlalarm kommen, und ich würde innerhalb von Minuten ja auf den Deckel bekommen vom CDC, und sie dann sagen da musst du sofort irgendwie ran und was versuchen zu tunen.
Georg Lauenstein:Das ist der erste Punkt. Der zweite Punkt ist ChatGPT oder auch generell KI weiß nicht, wie diese Indexe definiert sind in deiner Umgebung. Wenn du ein SIEM hast, und du hast einen ganz anderen Index, dann vielleicht ist Index gleich Windows gar nicht der richtige Index, den man braucht. Also, man muss eben genau auch aufpassen. man kann das nicht eins zu eins übernehmen. vielleicht gibt er gar nichts zurück, weil der Index falsch ist. Auch der Source-Type kann anders sein.
Georg Lauenstein:Der Event-Code, das kann ein anderes Feldnamen in einem anderen System bedeuten. 4.1.0.4, ja, ist natürlich ein bestimmter Event-Code im Bereich Windows, der genau auf dieses PowerShell-Tooling absieht. Aber das ist nur eine Log-Source. Also in diesem Beispiel wird nur genau auf PowerShell-Logs geschaut. Es gibt aber noch andere Logs, die genau das ähnliche Verhalten haben. Der ist hier gar nicht mehr drin in deiner Suche. Das heißt, wenn ich Angreifer bin, und ich nutze gar kein PowerShell, sondern nur die Kommandozeile, dann würdest du gar nichts sehen, weil es ist hier nicht drin in der Detection-Rule. Sprich auch viel zu breit, nicht feinfühlig gebaut, wenn ich es mal so, auch wenn es feinfühlig ein bisschen komisch klingt. Es würde aber nicht die Log-Sourcen abdecken, wo dieses Angreifer-Szenario aus Erfahrung selbst als leidenschaftliche Ecke, natürlich immer im legalen Sinn von früher oder eben auch aktiv im Lab würde nicht alles abdecken können. Das ist schlichtweg eine schlechte Rule.
Michael Döhmen:Also, ich habe zwar was gebaut, aber diese Rule ist anscheinend dermaßen unspezifisch und könnte auch unpassend sein für meine Umgebung. Deshalb lieber die Experten ranlassen, und ich glaube, von deiner Expertise haben wir heute einen sehr schönen Eindruck bekommen. Ich sage ganz lieben Dank, dass du im Podcast warst. Danke auch, und ich habe heute eine Menge gelernt. Wenn euch da draußen jetzt irgendwie in euch der Wunsch entfacht, ich will auch Detection Engineer werden, was kann man tun, Georg
Georg Lauenstein:Boar,
Georg Lauenstein:ganz wichtig ist man muss sehr viel lesen, man muss bereit sein, sich schnell Dinge einlesen zu können und auch zu verstehen. Man muss eine hohe Frustration mitbringen, weil es kann auch mal sein, dass man, wie du auch schon mal gesagt hast, lange braucht, bis man mit der Ruh zufrieden ist, die man gerade gebaut hat und die dann auch das tut, was sie machen soll. Es ist auch nicht so, dass jede Ruh perfekt ist. Es wird falsche Rahmen geben. Wichtig ist dann nur, eben Dinge zu haben, dass es eben schnell unterbunden wird oder die Ruh eben entsprechend optimiert ist.
Georg Lauenstein:Man muss Spaß an der Sache haben, man muss eine gewisse Passion mitbringen, wobei ich denke, wenn man im Bereich Cybersecurity, muss man sowieso eine gewisse Passion oder Leidenschaft mitbringen, damit man das, was man tut, auch das gewünschte Ziel rausbringt, weil unser Ziel ist ja, unternehmen da draußen zu schützen, und wenn man jemanden hat, der sich da auch mit identifiziert, spaß dabei hat, rules zu bauen. und es ist so, dass ich gerne Detection Rules baue und auch viel neben meiner normalen Arbeit mich damit befasse, weil es mir einfach eine Freude bereitet, und das ist auch der Grund, warum ich das jeden Tag gerne touren
Michael Döhmen:Top.
Michael Döhmen:Deine Leidenschaft haben wir auf jeden Fall mitbekommen. Für das Thema Ja nochmal ganz lieben Dank. Ganz wichtig greift Georg nicht an, das geht wahrscheinlich nach hinten los. Vielen Dank für deine Zeit Und vielen Dank an alle Zuhörerinnen und Zuhörer fürs.
Michael Döhmen:Zuhören.
Michael Döhmen:Wir hören uns in der nächsten Ausgabe wieder vom Cybersecurity Basement. Bis dahin bleibt sicher und gesund.
Annika Gamerad:Das war's aus dem Cybersecurity Basement. Check die Shownotes. Folg uns auf Social Media und abonniere den Podcast. Stay safe da draußen.