Detection Engineering aus CTI

Elias: Heute starten wir rein mit dem was Jan letzte Woche zum Schluss gesagt hat. Heute machen wir aus Angreiferverhalten Regeln. Und da habe ich mich, ja, habe ich ein bisschen vorgearbeitet mit einem kleinen Experiment. Ich habe mir einen öffentlichen Report zu Akira genommen, die uns letzte Woche ja auch, beziehungsweise letzte Folge auch schon mehrmals über den Weg gelaufen sind und wollte mal selbst ausprobieren, wie aus so einem Report grundsätzlich Detection werden kann. Also habe ich mir natürlich das einfachste, Hash genommen, den Hash der Ransomware-Binärdatei und habe darauf eine Sigma-Regel geschrieben. Ein Feld war ein Wert, es lief sauber durch. Sigma, kurze Side Note, ist ein offenes Format für Detectioning, das ist egal welches Theme du hinten dran hast. Ich jagte es durch, durch das offizielle Tool und raus kommt eine funktionierende Query. Kein Syntaxfehler, gar nichts, läuft durch und damit war ich im ersten Schritt auch erstmal ganz zufrieden. Ja und dann habe ich das ganze getestet, nicht mehr einfach nur auf dem Papier, sondern tatsächlich gegen echte Telemetrie mit so einem kleinen Test-Framework, dass die Technik dann wirklich ausführt und schaut, ob die Regel anspringt und natürlich, was musste passieren, wunderbare Regel feuert nicht, kein einziges Mal. Und daneben habe ich dann testweise mal eine uralte, muss man sagen, uralte Community-Regel daneben gelegt. Wahnsinnig hässliches Ding. 2010 oder sowas und die schaut natürlich nicht auf mein Hash, die schaut nur auf Kommandozeile, WSS, Admin, Delete Shadows war drin und was habe ich sie feuert sofort.
Jan Dubs: Ich lasse das mal einen Moment stehen, Elias.
Elias: Ja, Und das Ganze hat mich dann natürlich beschäftigt und das ist auch Thema heute unserer Folge. Was bei mir war, meine Regel war, blindaktisch, makelos muss man sagen, ja, große Leistung. Die alte, hässliche Regel guckt gefühlt auch eigentlich nur auf was Banales, was Dummes, eine reine Textzeile. Und die Frage ist da natürlich, warum ist die dumme alte Regel besser als meine neue, so wunderschöne?
Jan Dubs: Das ist die Frage, die sich heute die ganze Folge dreht und die Antwort hat nichts mit deinem Miamal zu tun und alles damit, wie tief du angesetzt hast. Bleib dran, Todsregeln nehmen wir gleich, Zeile für Zeile auseinander. Am Ende weißt du nicht nur,
Elias: ja.
Jan Dubs: warum sie tot ist, sondern auf welcher Ebene sie hätten sitzen müssen, zweierang zu leben, ohne dir deinen Detections Tag zuzumüllen.
Elias: Ja und damit willkommen bei Zwei-Jungs-CTI. Wie immer mit uns beiden Jan und mir Elias. Heute schauen wir uns an wie aus einem Threat Report Detection wird. Wir haben es jetzt schon erwähnt. Wichtiges Detail. Detection, die nicht nach fünf Tagen schon wieder tot ist oder auch noch schneller. Gar nicht funktioniert wie bei mir. Und ja ich freue mich sehr. hast es schon angekündigt jetzt gleich zu hören wie du mein kleines Experiment zerreißt. Ich habe dir natürlich gut Angriffsfläche gegeben damit. Dafür ist es da. Ja, damit würde ich sagen, fangen wir bei meiner toten Regel an. Wir haben es jetzt schon gesagt, das war natürlich Low Effort das Ganze. Aber wir haben ein klasse Musterbeispiel und können mit dem ersten Missverständnis reinstarten, was man glaube ich einfach hat. Und zwar wenn es nicht der Hash ist, den ich meine Detection matche, worauf dann? Weil der Report gibt mir klassischerweise genau diesen Hash aus, der steht ganz fett und schön gedruckt als IOC mit drin, als Indicator of Compromise. Und mein erster Reflex ist, es ist doch genau das, was ich auch blocken soll.
Jan Dubs: Das ist sogar ein sehr guter Reflex, aber er ist auch gleichzeitig die Falle. Denn der Report gibt ja grundsätzlich zwei verschiedene Sorten an Informationen und die meisten Menschen lesen halt nur die eine. Es gibt die Sorte, die sind IOCs, die konkreten Werte, Hashes, IP-Adressen, diese Nomains etc. Die andere Seite ist das Verhalten, also das Muster, was der Angreifer tut, sein Ziel zu erreichen. Denn Hash beschreibt eine einzige Datei. Das Verhalten beschreibt einen Schritt, den der Angreifer machen muss, egal welche Datei er dafür mitbringt.
Elias: Und ich glaube, ist der Unterschied. Und hier ist vielleicht auch eben direkt das erste Problem im Report. Und zwar steht nicht getrennt da. Also die Frage wäre, wie komme ich von hier ist ein Hasch hier ist das Verhalten dazu.
Jan Dubs: Eigentlich zu einer Art Übersetzungsketten und das ist dann eigentlich schon auch eine ganze Berufsgruppierung, da da siehst. Du hast beispielsweise bei deiner Akira-Researcher gesehen, dass die Ransomware am Ende die Schattenkopien aus den Shadow-Copies löscht und damit das Opfer nicht mehr einfach zurückrollen kann, was jetzt passiert ist. Das ist Technik. In der großen öffentlichen Matrix der Angreifertechniken der Maitre-Attack hat die sogar eine eigene Nummer, die T1400 Wiederherstellung verhindern. Und jetzt kommt der erste ähnliche Schritt. Du fragst dich, welchen Hash matche ich? Das ist nicht unbedingt die Frage, sondern die Frage sollte sein, welches Ergebnis auf dem System muss ich überhaupt mitschreiben, das zu sehen?
Elias: Und wie wäre die Antwort bei Shadow Copies löschen?
Jan Dubs: Grundsätzlich könnte das so aussehen. Ein Prozess wird gestartet. Auf Windows ist das ein ganz konkretes Ereignis. Prozesserstellung mit einem Zeitstempel, einem Parent-Prozess. Und das ist das Gold der kompletten Kommandozeile. Das ist deine Data Source, deine Datenquelle. Ohne dass du diese Ereignisse logst, ist die Regel grundsätzlich blind. Und erst wenn du die Datenquelle hast, kommt die eigentliche Denkarbeit. Welcher Teil dieses Ergebnisses ist unveränderlich? Was kann der Angreifer nicht weglassen, ohne sein Ziel zu verfehlen?
Elias: Und beim Shadow-Copies löschen ist dann dieses unveränderliche Ereignis welches...
Jan Dubs: Die Kommandozeile selber ist da das unveränderliche Moment und zwar er will ja die Schattenkopien weg haben. Dafür ruft man meist das bordeigene Windows Werkzeug, das VSS Admin auf und sagt delete shadows. Er kann die Binärdatei umbenennen, er kann sie packen, kann ihren Hash bei jedem Bild ändern, das ist alles kein Problem für ihn. Aber wenn er die Schattenkopien wirklich löschen will, muss dieses Werkzeug mit diesem Befehl laufen. Genau darauf schaut die hässliche Regel und genau das hat deine Übersehen.
Elias: Das heißt, meine Regel war, vor Anfang an chancenlos, weil sie auf den einen Teil schaut, den der Angreifer, wie wir auch schon in unseren vorherigen Folgen festgeschnitten haben, am billigsten wegwerfen kann.
Jan Dubs: Ich sag's nur ungern, aber ja, und ganz ehrlich, das war auch mein erster Fehler, als ich meine erste Rule beschrieben habe. Der Hash, das ist die Fußnote im Report, oder es sollte die Fußnote sein, das Verhalten ist dann die Regel, die man schaut. Und das ist keine Meinung, das ist genau die Pyramid of Pain, über die wir auch schon diverse Male geredet haben. Ganz unten die flüchtigen Werte, Hash, IP, da wo der Angreifer nur mit den Schultern zuckt und den Wirt austauscht. Ganz oben aber die Verhaltensweise. wo er sein ganzes Vorgehen, sein Vorhaben umbauen müsste, etwas verändern zu können. Eine Regel saß auf dem Boden der Pyramide, die alte saß zwei Etagen höher und deshalb lebt sie noch.
Elias: Dann lass sie uns nebeneinander legen. Lass uns den Unterschied ganz genau machen und schauen, wo im Text sitzt.
Jan Dubs: Und es ist fast schon unspektakulär für heute, wie klein der Unterschied auf dem Papier dann wirklich ist. Deine Regel sagt sinngemäß, fällt Hash gleich dieser lange Wert. Fertig. Ein einziger Wert und die alte Regel sagt, fällt Kommandozeile, enthält VSS-Admin und enthält Delete und enthält Shadows. Auch nicht kompliziert. Aber der Unterschied ist einfach und das ist auch der ganze Unterschied dann schon. Deine Regel beschreibt eine Ransomware Version aus einem Report und die Alte beschreibt, jeder Ransomware tun muss oder in diesem TTP tun muss, die Schattenkopien entsprechend zu löschen. Akira Lockbit, das auch immer nächste Woche kommt, Sie alle machen es mit diesem einfachen TTP.
Elias: Und nach diesem Prinzip produziert dann das ganze Detection Engineering wirklich nachhaltigen Wert, mehr Wert, weil, wie man gesehen hat, die alte Regel fängt damit auch Sachen, die noch gar nicht existiert haben zu dem Zeitpunkt, als sie geschrieben wurde.
Jan Dubs: Das ist der Punkt an dem es schon fast unheimlich wird, Eine Verhaltensregel alertet kaum. Die Regel von 2019 fängt heute frische Akira Intrusions auf, weil sich das Verhalten nicht geändert hat. Nur die Datei. Deine Hashregel wäre in dem Moment tot gewesen, in dem der nächste Bild der Ransomware ausgekommen ist. Und der C2-Median, also ein Wert, der uns kurz zerschüttert. Wir haben das diverse Mal mit Cobalt-Strike-Schraubern auch so durchgerechnet. So ein Wert lebt Tage und nicht Monate. Oder wie eben deine Detection Rule über mehrere Jahre.
Elias: Gut, bevor wir jetzt höher klettern, mal eine praktische Sache noch. Und ich hatte es eingangs schon erwähnt, vor allem das jetzt beim Bauen auch noch verwirrt. Ich habe die Regel einmal geschrieben, auch wenn sie jetzt nicht besonders
Jan Dubs: Mhm.
Elias: gut war und einmal konvertiert. Aber wir haben ja bei unseren Mandanten ganz verschiedene Stacks. Der eine fällt alles über Microsoft, der nächste als Blank, der dritte über Elastic, was auch immer. Und genau da kommt eben Sigma ins Spiel korrekt.
Jan Dubs: Genau, das ist der ganze Charme von Sigma. Du schreibst die Riegel einmal, du schreibst quasi eine Riegelgerüst hier steuerneutral in einem liessbaren Format und dann gibt es ein Konvertierungswerkzeug, das dir daraus die passenden Queries für deine Zielsiehe baut. Der gleiche herum führt zum Beispiel zu Microsoft KQL, zu Splunk SPL, den zwei Abfragesprachen zur Elastic Query, ein Body, viele Backends und das ist das Schöne für uns im Dachraum. Das läuft lokal auf deinem Rechner, kostet keinen Franken und es gibt Kein einziges Pied, deine Regel, dass sie in einer fremden Cloud landen.
Elias: Das tatsächlich auch das, was ich benutzt habe, also das offizielle Kommando-Zeilenwerkzeug. Es gibt aber auch so einen Browser-Converter, oder?
Jan Dubs: Es gibt beides ja und beides ist oftmals auch gratis. Es gibt das offizielle lokale Werkzeug, das ist die Saubröfe, Produktion, weil nichts hochgeladen wird, die SGVO konform etc. Und es gibt dann auch die browserbasierten Converter, die auf dutzenden Zielsprachen übersetzen, praktisch zum schnellen Ausprobieren. Für einen Mandanten unter Datenschutz-Aflagen nimmst du das lokale, aber egal welches, die Kette dahinter ist gleich. Du hast einen Rumpf, einen Aufbau, eine Verarbeitungspipeline, die dir dann die fällt Namen auf die echten Log-Schematate des Ziels im Smapt und hinten kommt dann Query raus. Merkt ihr das Wort Pipeline? An dem hängt gleich die halbe Vogel.
Elias: Normalerweise muss man auch sagen, fängt man ja eigentlich nicht bei Null an, weil es gibt ja unfassbar viele öffentliche verfügbare Regeln.
Jan Dubs: Genau, es gibt mehrere tausend öffentliche Community gepflegte Regeln für Windows, M365, Oktav, AWS. Also deine hässliche VSS-Admin-Regel ist nur eine von... Das heißt, für die häufigen Techniken musst du gar nichts neu erfinden. Du liest einfach die bestehenden Regeln, verstehst das warum, sie auf etwas schauen, wo sie hinschauen und passt sie dann für deinen Stack an. Und genau das ist übrigens, was wir damals mit der Cobalt Strike Beginning-Regel gemacht haben. die wir Zeile für Zeile aufgebaut haben, die schaut auf das Muster, die Frequenz, den Fingerabdruck der Verbindung und das war schon so eine Verhaltensregel, nur haben wir das damals nicht in die Klammerdruckung gebaut, die heute dran ist.
Elias: Okay, dann lass uns jetzt mal zur nächsten Frage kommen. Wir haben schon von der Pyramid of Pain gesprochen. Motiviert wie ich jetzt bin, könnte ich bei der nächsten Regel hergehen und denken, umso höher ich ansetze, umso besser wird meine Regel.
Jan Dubs: Du hast Blut geleckt.
Elias: Ich habe Blut geleckt, ich wäre jetzt heiß und will natürlich ganz oben rein. Heißt das für mich dann in der nächsten Konsequenz, dass ich auf meine Hashtrege eigentlich komplett verzichten kann oder wie sieht das für die aus?
Jan Dubs: Tritt mal schnell auf die Bremse. Genau jetzt kommt der nächste Fehler. ambitionierten Menschen machen. Höher auf der Pyramide ist stets besser. Das ist bisher ein Bauchgefühl. Die Pyramid of Pain sagt dir grob, das Verhalten teurer ist als ein Hasch im Austausch. Aber sie gibt dir keine Skala, mit der du zwei Verhaltensregeln vergleichen kannst. Die gibt es inzwischen und die brauchst du aber auch.
Elias: Und wie kann ich mir diese Skala dann so vorstellen?
Jan Dubs: Schau es mal in Stufen an. Genauer gesagt in 5 Stufen für Host-Regeln. Und je höher, desto teurer wird es für einen Angreifer an deiner Regel vorbeizukommen. Ganz unten, Stufe 1, die Flüchtigenwerte. Hash IP, ein spezifisches String. Da wo deine tote Regel wohnt. Der Angreifer ändert einen Wert und du bist raus. Eine Etage höher, zielst du auf das Werkzeug, das der Angreifer mitbringt.
Elias: Und darüber noch...
Jan Dubs: Darüber wird es interessant und das ist auch zwangsweise so, weil du ziehst dann auf die bordeigenen Werkzeuge, die auf dem System ohnehin schon rumliegen. Die sogenannten LOL-Bins. Da sitzt die hässliche VSS-Adminregel. Sie schaut auf ein Windows-Bordmittel, das der Angreifer nicht ersetzen kann, wenn er sein Ziel will. Und ganz oben, die Stufe oben drauf, die Stufe 5, zielt auf das fundamentale Verhalten selbst, den Kern der Technik. Da müsstet der Angreifer die Technik grundsätzlich anders machen, dir entsprechen zu können.
Elias: Ok, also die alte Regel sitzt auf Stufe 3, meiner dementsprechend ganz unten auf Stufe 1 und das hat dann hier auch genau den Unterschied gemacht, korrekt?
Jan Dubs: Das ist der ganze Unterschied. Und jetzt kommt die zweite Bremse, die wichtigere und die vielleicht auch überraschendere für die meisten. Höher ist nicht automatisch besser bei der Pyramid of Pain. Wenn du blind alles auf Stufe 5 schreibst, baust du dir ein anderes Problem, das schlimmer sein kann als eine Tote-Regel. Und das zeige ich dir am besten, indem du dich in genau diese Falle begibst, in die du gerade laufen willst.
Elias: Jawoll, lass mich reinlaufen, ich nehme mir einen richtig hohen
Jan Dubs: los geht's.
Elias: Fall aus der App-Pyramid. Persistence nach einem Konto-Diebstahl, sowas habe ich die Woche auch in der Vorbereitung gesehen. Ein Angreifer klaut sich seine Credentials und statt sich immer wieder neu anzumelden, sichert er sich dann dauerhaften Zugriff auf beispielsweise ein Postfach, in dem er sich selbst die Rechte auf eine fremde Mailbox gibt.
Jan Dubs: Mh.
Elias: Vollzugriff oder als Senden als In den Audit Logs von Microsoft 365 sieht man, dass ein Add Mailbox Permission reinflattert. Erster Reflex wäre dementsprechend, dass es ein klares Verhalten ist und ich das einfach blockieren kann. Sitzt hoch in der Pyramide, jetzt schreibe ich für die Regel dazu, jemand vergibt Postfachrechte und dann gibt es einen Alarm.
Jan Dubs: sauber gedacht. Der Hintergrund ist auch real, du da nennst. Genau diese Sorte Persistence sind wir häufig bei staatlichen Angreifern. Es gibt oder es gab einen Fall gegen den Vorstand einer deutschen Partei, ein Zero-Click-Loch in Outlook, wo allein das Ankommen einer entsprechend präparierten Nachricht schon einen Hash abgegriffen hat, ohne dass jemand klicken musste. Die Attribution auf einen staatlichen Akter kam später von der deutschen Regierungssite, also ja, Persistence nach Kontodiebstahl ist ein Verhalten, das zählt.
Elias: Mmh.
Jan Dubs: Aber jetzt lass uns deine Regel gegen die Realität eines Mandanten laufen. Denk an eine deutsche Bank. Alle Maul-Look den ganzen Tag.
Elias: Ja, würde sagen,
Jan Dubs: Das
Elias: kommt jeder hinter der ACM auf jeden Fall ordentlich was zu tun. Du hast
Jan Dubs: Das ist so.
Elias: die Assistenz, irgendjemand hat Zugriff auf das Postfach vom Chef, dann teilt sich vielleicht noch ein Team, ein Funktionpostfach, die IT, migriert gerade, mailboxen, vergibt dabei Laufen und Band, irgendwelche Rechte.
Jan Dubs: Hmmmm
Elias: Also meine Regel würde wirklich wahnsinnig viel zum Muld auslösen.
Jan Dubs: Und seid ihr eine Zahl dran. In so einer Umgebung feuert eine solche Regel nicht einmal. Sie feuert vielleicht 200-300 Mal am Tag. 190 davon sind vermutlich Assistenzen, Funktionspostfächer, eine Migration. Das ist das Scheitern und es ist ein schlimmes Scheitern. Und viel schlimmer noch als deine tote Hechschregel, weil die Todsregel hat einfach nichts getan. Diese hier tut aktiv Schaden.
Elias: Der Schaden entsteht dann beim Anrissen.
Jan Dubs: Genau, sie zerstört deine Analysten, die liefert dir false positives und Fehlanarme. Das sind heute die Detection-Probleme Nummer eins. Und es wird immer schlimmer, nicht besser. Die grosse Mehrheit der Teams nennt Fehlanarme als ihre grösste Herausforderung.
Elias: Das kann einem verständlicherweise gut auf den Senkel gehen und ich könnte mir auch vorstellen, das macht dann mit dir als Person auch irgendwann bestimmt was, oder deine Art und Weise, wie du arbeitest grundsätzlich.
Jan Dubs: Das macht sogar was sehr Menschliches, wenn fast die Hälfte oder noch mehr aller Alarme, Fehlalarme sind und deine Analysten jeden Tag durch Tausende von solchen Alerts warten müssen, dann entsprechend was zu finden und dann passiert etwas Menschliches, du stumpfst ab. Und am Tag, dem dann der unter 99. harmlose Alert da war und der echte, 200, der dann dazwischen liegt, klickt er ihn genauso weg wie die anderen, weil war er bisher immer nur Müll. Eine laute Regel, die desensibilisiert ein Team ist, gefällt ihr aus einer Tote, weil sie dir vorgaukelt, du hättest Detections, während sie in Tat und Wahrheit eine echte Detection unter Noise, also Lärm, begrebt.
Elias: Also habe ich mit meinem ambitionierten Versuch der Stufe 5-Regel genau das Gegenteil von dem erreichte was ich wollte. Dann bleibt ein Stück weit die Frage offen, was ist die Konsequenz daraus? Wieder zurück zur Hash-Regel, sicherlich jetzt auch nicht. Also was ist der Sweet Spot?
Jan Dubs: Der sweet spot ist der Moment, Detection Engineering von Handwerk zur Kunst wird. Und die Regeln wegwerfen wäre genauso falsch, wie sie so laut zu lassen. Du härtest deine Regel, du optimierst sie und die Anleitung dafür steckt genau in der Skala, die ich dir eben gezeigt habe. Der entscheidende Schritt heisst sinngemäß, bau deine Ausschlüsse über Felder, die der Angreifer nicht leicht fälschen kann.
Elias: Also nicht ignoriere die Assistenz Frau Müller, weil morgen kann der Angreifer auch unsere gute Frau Müller sein.
Jan Dubs: Exakter Denkfehler, den du damit vermeidest. Genau. Wenn du auf einen Namen oder wenn du einen Namen ausschließt, umgeht der Angreifer dich, indem er diesen Namen benutzt. Also fragst du, was an einer legitimen Delegation strukturell anders als an einer bösartigen und zwar an einer Stelle, die der Angreifer nicht frei wählen kann. Bei der Bank legitime Delegation kommt fast immer von Administrations- oder Servicekonten im Rahmen bekannter Prozesse.
Elias: Und da sitzt unser Angreifer höchstwahrscheinlich eben nicht.
Jan Dubs: Genau, das ist jetzt woanders. Der gerade ein normales Nutzerkonto gekapert hat, eben kein Admin, also hat kein Adminkonto, also vorher nur, wenn der Aktor beispielsweise ein Nicht-Adminkonto ist. Und nur, wenn die Delegation neu ist, frisch, nicht seit Jahren besteht, und besonders, der Zeitprinzipal ungewöhnlich ist, ein extern anmutendes oder gerade erst angelegtes Konto beispielsweise.
Elias: Genau und die drei Bedingungen, so wie du sie jetzt genannt hast, sind natürlich zusammen schwer zu fälschen, weil der Angeifer sein gekapert ist, konnte halt nicht plötzlich, außer natürlich hat er dafür auch noch was zum Atmen machen kann, ohne dann halt selbst wieder laut zu werden und vielleicht andere Rules zu checken.
Jan Dubs: Genau, unterliegt auch die Schönheit. Aus 200 Alarm am Tag werden vielleicht zwei in einer Woche. Die Regel ist immer noch eine Verhaltensregel. Sie sitzt immer noch hoch in der Pyramide, aber sie ist jetzt tragbar. Der Angreifer kann sie nur umgehen, indem er sich beispielsweise ein entsprechendes Adminkonto besorgt hat. Und das entsprechend zu machen ist sehr teuer und laut. Und das ist auch die Antwort auf die Frage vorhin. So hoch wie möglich ist nicht unbedingt das Ziel, sondern... so hoch wie in deinem Stack tragbar. Also Präzision zur Vollständigkeit, wenn du kein unendliches Analystenbüßchen hast. Und das hat vermutlich niemand hier.
Elias: Gut, damit haben wir jetzt zwei gehärtete, recht hoch angesiedelte Regeln. Die Frage, die man sich jetzt dann halt stellen kann, vielleicht noch nicht unbedingt bei zwei Regeln, aber ganz grundsätzlich ist, ab wann reicht es? Ich meine, gegen einen Actor wie Akira, wie viele Regeln bräuchte es da, bis ich alles abdenke, was da vielleicht auf mich zukommen kann?
Jan Dubs: Das ist eine sehr berechtigte Frage und ich denke die Antwort tut extrem weh, weil das weißt du nicht, solange du es nicht misst. Und die meisten wissen es nicht und glauben sie wüssten es. Es gibt Werkzeuge, die dir gegen die grossen Technikmatrixen eine Hitmap malen. Grüne Kacheln, wo du was siehst, rote wo du blind bist, sieh zu, brauche ein Board Meeting und diese grünen Kacheln sind eine extrem gefährliche Lüge, die du da präsentierst.
Elias: Wieso Lüge? Also es klingt ja erstmal schlüssig an sich.
Jan Dubs: Klar, grün heißt du hast eine Regel hinterlegt, das heißt nicht, dass sie feuert, das heißt nicht, dass sie getunt ist und erinnerst du dich an deine tote Regel von vorhin? Die hätte in so einer Heatmap eine schöne grüne Kachel gemacht. Technik T1490 gedeckt, Häckchen und die Wahrheit, das Ding feuert nie. Man hätte das mal über 100 echte Produktionssims gemessen mit über 13.000 Regeln und jede Acht davon feuert nie. falsch konfigurierte Quellen, fehlende Felder, nicht konfigurierte Logs etc., Pipelines nicht angepasst. Jede davon eine grüne Kachel, die entsprechend lügt. Sorry, tut mir leid, aber das ist die Realität.
Elias: Okay, also man kann mich quasi gut fürs Board Meeting einsetzen. Ich mache ganz viele
Jan Dubs: Genau.
Elias: grüne Felder. Okay, schwarz-weißeite,
Jan Dubs: Genau.
Elias: ich meine, das ist wirklich heftig. Jeder achte die Todes- und das Schlimme. Dabei eigentlich, es bekommt halt einfach keiner mit.
Jan Dubs: Ja, es kommt noch ein bisschen schlimmer. Die gleiche Messung zeigt auch, die durchschnittliche Siebenumgebung deckt rund 21 % der bekannten Angriffstechniken überhaupt ab. Also fast vier von fünf Techniken haben gar keine Regel. Und diese Lücke wird größer, nicht kleiner Jahr für Jahr, weil neue Techniken schneller dazukommen. Denk an KI, denk an die ganzen Entwicklungen, die Verfügbarkeit von solchen Tools. Und das kommt schneller, als die Teamsregeln bauen können. Das heißt, wenn du nur auf Wenn grüne Heatmap schaust, glaubst du, du bist gut aufgestellt, während die Wahrheit, die große Minderheit an Rangelsfläche unbewacht ist. Und ich finde das Wahnsinn, weil ich habe bisher jeden Wender gesehen mit 100 % Miterabdeckung. Ja, 100 %
Elias: Mhm.
Jan Dubs: grüne Kachen ist toll, du siehst was, aber du wirst ziemlich sicher nicht das sehen, was eben da ist. Deshalb ist wie beim Darkweb Thema Qualität und ... Qualität, man messen sollte.
Elias: Ich meine das wird wahrscheinlich... Ja, Nicht Quantität einfach, ja. Du kommst nicht hinterher und mittlerweile bei dem Tempo was vorgelegt ist... hast du wahrscheinlich selbst auf deiner Heatmap noch Flecken, nicht grün sind, geschweige denn oder geschweige das und das ist nicht funktioniert. Die Frage ist natürlich trotzdem, was macht man draus? Irgendwie musst du die Lücken erkennen und für mich ist der erste Punkt natürlich wie immer ein schönes Tool, dass mir die Lücken anzeigt und ehrlich aufzeigt, gibt es denn sowas in dem Fall? das Tool diesmal tatsächlich vielleicht eine Lösung?
Jan Dubs: Es gibt was und das macht genau eine Unterscheidung, die den meisten Leuten nicht klar wird, auf die es wirklich ankommt. Es trennt Visibility von Detection. Zwei völlig unterschiedliche Fragen. Visibility heißt, habe ich überhaupt die Daten, diese Technik zu sehen? Logge ich das richtige Ereignis? Und Detection heißt, habe ich eine Regel, die auf diesen Daten feuert, die ich habe? Die meisten kippen die beiden zusammen und merken nicht, dass eine fehlende Kacheln zwei völlig unterschiedliche Krankheiten.
Elias: Wollen wir ein Beispiel nehmen, wollen wir es vielleicht gleich mit dem Post-WARF machen?
Jan Dubs: Nimm mir deine Postfachdelegation.
Elias: Ja.
Jan Dubs: Du sammelst M365 Auditlogs. Beispielsweise gar nicht. Dann ist das ein Visibility Problem. Du bist blind. Keine
Elias: Mhm.
Jan Dubs: Regel dir. Welt hilft dir damit, weil die Daten nicht da sind, die es bräuchte. Das heißt, erst musst du entsprechend dieses Login konfigurieren oder an deinen Datentopf senden. Wenn du die Log schon hast, aber keine Regel darauf, dann ist es eine Detection-Lücke, also ein Detection-Problem. Die Daten liegen zwar da, du guckst nur nicht hin und das ist dann eine komplett andere Handhabe. Beim einen musst du eine Log-Konfiguration vornehmen, beim anderen schreibst du eine Regel. Wer das nicht trennt, schreibt Regeln für Daten, er gar nicht hat und wundert sich, warum sie nicht feuern.
Elias: Also das war meine tote Regel im Großen sozusagen. Ich habe eine Detection gebaut, in Wahrheit die Datenquelle noch nicht mal connectiert war.
Jan Dubs: Genau dein Fall, eine Etage höher gedacht und deshalb mahlst du dir über dein Top Actor Profil, sagen wir das aktuelle Akira-Verhalten, ein ähnliches Bild. Für jede Technik, die Akira braucht, fragst du dich zuerst, sehe ich die überhaupt? Und erst dann fange ich sie überhaupt oder habe ich eine Möglichkeit, sie aufzuspüren und
Elias: Mhm.
Jan Dubs: plötzlich ist deine grüne Wohlfühl-Hitmap eine echt ehrliche Landkarte mit roten Löchern. Mit zwei Sorten roten Löchern.
Elias: Gut, ich hake jetzt noch einmal bei meinem Beispiel nach. Mein eigenes Werkzeug
Jan Dubs: Du gibst nicht auf.
Elias: hat mir gesagt, meine Regel ist spitze, valide Query, nichts mehr kann.
Jan Dubs: Mhm.
Elias: Trotzdem war die Regel tot. Wie habe ich jetzt die Möglichkeit, genau solche Sachen, vielleicht natürlich bei komplexeren Regeln, die man schreibt, vorher festzustellen, ob sie denn funktionieren, ohne dass die Ransomware erst bei einem unserer Mandanten durchrutschen muss.
Jan Dubs: Heute bin ich glaube ich ein bisschen fies, weil es kommt noch eine sehr harte Lektion von der Folge. Und deshalb kommt sie auch hier. Konvertiert Zauber ist nicht unbedingt dasselbe wie feuert. Dein Converter prüft nur, die Query grammatikalisch, also vom Syntag sehr korrekt ist. Er prüft
Elias: Mhm.
Jan Dubs: nicht, ob die Feldnamen in deinem Regel zu den echten Feldnamen in deinem Log passen. Wenn dein Regel beispielsweise Command Line sagt und dein Log das Feld Process Command Line nennt, die Pipeline das nicht übersetzt. Dann ist dein Queer perfekt und sucht nach einem Feld, das es in deinem Garten gar nicht gibt. Syntaktisch völlig tadellos, aber praktisch blind.
Elias: Ja, so kann man ganz grundsätzlich sagen, der Regel, solange ich sie nicht vernünftig getestet habe, bleibt erstmal nur eine Behauptung.
Jan Dubs: Das ist die ganze Wahrheit in einem Satz, ja und den merke ich mir, weil ich finde den echt fehl. Eine ungetestete Regel ist eine Behauptung, kein Schutz und du hast heute effektiv, zufällig genau das Richtige getan. Du hast sie ausgeführt. Es gibt dieses kleine Test-Framework, das die Technik wirklich macht. Es löst oder es löscht tatsächlich die Schattenkopien auf dem Testsystem. Harnlos kontrolliert und dann schaust du, ist deine konvertierte Query dabei angesprungen? Ja oder nein? Feuert sie gegen echte Telemetrie, nicht gegen ausgedachte Daten und nur die Ausführung selber beweist es. Alles davor ist aus meiner Sicht lediglich Hoffnung.
Elias: Und wenn ich das jetzt nicht nur einmal für mich machen will, sondern sauber für ein ganzes Team...
Jan Dubs: Dann behandelst du deine Regeln wie Code und nicht wie Konfigurationen. Jede deiner Regel liegt in einem Git Repository. Eine Änderung geht nicht direkt in Produktion, sondern über dein Pull Request beispielsweise, den dein Kollege gegenliest. Und bevor du sie durchlässt, läuft automatisch dieser
Elias: Mhm.
Jan Dubs: Ausführungstest. Also folge die Regeln im Test nicht, block das Gate, sie kommt sie gar nicht erst raus. Das ist Detection as Code und das ist genau die Klammer, die bei deiner Regel heute Vormittag gefilmt hätte. Sie wäre am Gate hangengeblieben, statt als schöne grüne Leiche im Seam zu landen.
Elias: Okay, also das dreht dann die ganze Logik einmal Erst der Beweis, dass sie feuert, dann packen wir sie live in den Betrieb.
Jan Dubs: Genau, das ist der Reifvergradunterschied zwischen einem Sock, das Regeln sammelt. Auch sehr häufig schon gesehen, je mehr Detektionen, je mehr IOCs, desto besser und einem effektiven, Detections betreibt. Das eine hat einfach eine grüne Heatmap und eine Schublade voll der Behauptungen und das andere hat eine klare, kleinere, ehrlichere Heatmap, die getestet ist, die in jeder grünen Kacheln beweisen kann, dass das, was drin ist, Feuer und Flamme... evident bleibt. Ich nehme persönlich die kleinere, ehrlichere jeden Tag hervor und belächle manchmal etwas den grossen Sammler. Aber das ist...
Elias: Die großen Sammler produzieren halt die tollen Schlagzeilen und großen Marketingzahlen. ist halt ein Stück weit der Kampf, den wir immer führen. Ja, genau,
Jan Dubs: Genau. Genau. Wir kämpfen, wir sind die Kleinen, dagegen ankämpfen. Genau.
Elias: ich wollte es gern sagen. Das ist ja unser Thema ein Stück weit fast jeden Tag. Gut, jetzt haben wir uns die ganze Zeit beschäftigt mit dem Beispiel Akira. Wir wollen eigentlich das Ganze immer zu uns im Dachkontext holen. Wollen wir Beispiel nochmal durchgehen bei uns hier im Dachraum, wo eine Verhaltensregel einen Unterschied gemacht hätte?
Jan Dubs: Ja, lass uns was Bitteres nehmen, die Jungs von der Südwestfalen-IT. Ich finde den relativ bitter, weil der vor allem real und
Elias: Klassik.
Jan Dubs: öffentlich ist, kommunaler IT-Dienstleister, der entsprechend mit Akira verschlüsselt worden ist. Ich gehe nicht mehr in die Details, wir haben das schon mehrmals gemacht.
Elias: Ja, ja.
Jan Dubs: Und ich erzähle dir bewusst nur den einen Detection-Handgriff, die ganze forensische Rekonstruktion Tag für Tag, die geben wir uns für eine andere Folge auf. Hier wirklich nur... Heute nur die Schwelle.
Elias: Ok, neulich, was war der Einstieg?
Jan Dubs: Der Initial Access, der kam über Cisco VPN ohne MFA. Welche Schwachstelle genau das ist, ist bis heute nur vermutet nicht bewiesen aus meinem Kenntnisstand. Und doch am selben Tag sieht man in den Logs eine ganze Serie viel geschlagener, anonymer Anmeldeversuche über das Dateifreigabe-Protokoll. Reihenweise viel Versuche. Das ist kein Hash, das ist kein IOC, das ist ein Verhalten mit Zahl dran. Und genau Zahlen... den Zeinstempel, das ganze Protokoll, das gehört in die IR-Folge und nicht hierher.
Elias: Und genau darauf könnte aber eine Verhaltensregel schauen. Also eine Schwelle,
Jan Dubs: Richtig.
Elias: ein Threshort, und so viele Fehlversuche pro Stunde von einer Quelle, dann gleich einen Alarm schießen.
Jan Dubs: Genau die Sorte Regel, die wir hier in den ganzen Minuten schon gebaut haben, nur halt angewandt. So eine Brute Force-Schwelle gegen einen VPN oder gegen in diesem Fall die Dateifreigaben braucht kein einziges IOC. Sie produziert im Gegenteil IOCs. Wer macht das?
Elias: Mhm.
Jan Dubs: Das produziert man mit der Detection bereits wieder Intel. Sie schaut eigentlich nur auf ein Muster. Viele Fehlversuche, kurze Zeit, eine Quelle. Und das bitterste ist zwischen diesem Einstieg und der eigentlichen Verschlüsselung lagen ungefähr 11 Tage. 11 Tage in denen der Angreifer im Netz war, sich umgesehen hat, die Systeme abgeklopft hat, wie breit die Verschlüsselung am Ende getroffen hat und in welcher Nacht die ganze Rekonstruktion eben für die Eierfolge auch wie schon gesagt. Heute zählt nur die eine Zahl 11 Tage Vorwarnung die in den Logs stand.
Elias: 11 Tage Vorwarnung, die vor allem einfach verschenkt werden, weil niemand auf diesen von uns erwähnten Threshout schaut. Obwohl, du sagst es selbst grundsätzlich, all das Material in den Logs da gewesen wäre.
Jan Dubs: Genau, es geht nicht das Bashing. Ich denke wirklich auch, die Aufarbeitung
Elias: Nein,
Jan Dubs: war extrem mustergültig. Es geht einfach die ganze Lektion dieser Folge in einem echten Fall. Die Daten waren da. Es fehlte keine exotische Technologie. Es war jetzt nicht irgendwie das Agentsock, das alle wollen und niemand bauen kann, weil es einfach nicht möglich ist oder nicht möglich
Elias: Mhm.
Jan Dubs: sein sollte, dass man das dem LLM überlässt. Es fehlt eine einzige Verhaltensregel, die auf einen Muster schaut, statt auf ein Wirt. Und ein Analyst, den... den sie feuert, ohne dass er im Lärm ertrinkt. Und genau darum haben wir vorhin die Regeln gehärtet, statt sie laut zu lassen. Eine laute Schwellenregel hätte in diesem Netz vielleicht auch gefeuert, wäre aber völlig im Rauschen untergegangen. Und mehr
Elias: Mhm.
Jan Dubs: gesagt hätte ich heute nicht zu dem Fall, weil sonst nehmen wir uns das, was wir zur nächsten Folge bereits hier drauf. Es geht einfach darum, sind die Daten da als Quelle? Hab ich eine Regel da oder habe ich eine grüne Leiche im Keller meiner Siebe?
Elias: Ja, ja, ist richtig. Es geht nicht Bashing, aber es ist natürlich für uns heute hier genau eigentlich das richtige Beispiel, das anzuführen, einfach die Wirkung dessen zeigen zu können, was eine Regel vielleicht hätte verhindern können.
Jan Dubs: F
Elias: Wir können das Ganze jetzt mal zu einem echten Stack zusammenziehen. Ich habe mir aufgeschrieben, wir nehmen eine fiktive Bank. Wir können das Ganze Microsoft-lastig gestalten. Das ist ja bei fast allen so. Und nehmen das aktuelle Akira-Verhalten. Wo ist die blind, Bank und ist das ein Visibility oder ein Detection Loch, wie würde es das sein?
Jan Dubs: Genau das machst du dir mit so einem Layerfile aus und es fällt fast immer in dieselben drei Sorten Lücken. Jede mit entsprechend anderen Krankheiten. Der erste Einstieg über das VPN, die Brute Force Schwelle, die wir gerade hatten. Bei vielen Häusern ist das ein Visibility-Loch. Die VPN-Locks landen gar nicht erst im Seam. Da
Elias: Mhm.
Jan Dubs: hilft auch keine Regel, da musst du erst die Locks entsprechend anbinden.
Elias: Und die zweite Sorte.
Jan Dubs: Das wäre dann das Aussperren des Netzes, wenn der Angreifer nach Domainadmin sucht und Systeme abklopft, da hast du die Prozess-Logs meist schon. Das ist dann ein reines Detection-Loch eigentlich, dir fehlt die Regel auf dieses entsprechend verrätrische Kommando-Zeilenverhalten. Und die dritte, die fast überall klafft, ist die eigene Fachanwendung. Beispielsweise ein SAP, das protokolliert oft in seine eigene Welt, die nie jemand in Siem holt, ein Visibilitätsloch so gross, dass man es sehr sehr gerne verdrängt.
Elias: Okay, also wir haben drei rote Kacheln, aber die Antwort ist jedes Mal eine andere. Einmal Logs anschalten, einmal die Regel schreiben und einmal ein theoretisch ganzes System erstmal sichtbar machen.
Jan Dubs: Ja, und das ist so bisschen die Ernüchterung, wenn wir jetzt über die Textion Engineering sprechen im Grundsatz. ist eine relativ ehrliche Langkarte, die viel wertvoller ist als die grüne Wohlfühl-Hitmap. Sie sagt dir nicht,
Elias: Mhm.
Jan Dubs: wo du blind bist, sondern welche Sorte Blindheit und damit auch welche Handgriffe du morgen früh machst.
Elias: bleibt die Frage, die gerade im Dachmittelstand immer kommt, was kostet das, wenn man das diszipliniert durchziehen will, weil erstmal klingt das nach einem ziemlichen Enterprise Tooling Werkzeugkasten.
Jan Dubs: Die Antwort ist relativ erfreulich einfach nichts. Alles was wir heute angefasst haben ist kostenlos und läuft lokal. Das Konvertierungswerkzeug, der Cortus mit den mehreren tausend fertigen Regeln, das Framework, das die Technik zum Testen ausführt, das Werkzeug für die eheliche Coverage-Landkarte, kein sechsstelliges Abo, kein Zehner-Team, ein bisschen Disziplin, Sysman-Logging auf den Windows-Kisten und der Kopf, Umverhalten, Stativierte zu denken.
Elias: Und für die Kritishörer ist das, was du jetzt beschrieben hast, ja nicht mal mehr freiwillig, oder?
Jan Dubs: für die Detektionspflicht. Für Betreiber kritischer Infrastrukturen schreibt die Regulation vor, dass konkrete Werkzeuge der Angriffserkennung bereitgestellt werden müssen, beziehungsweise mit einem Katalog, was zu protokollieren ist. Mit Zentralisierung und Automatisierung, das genaue Inkrafttreten der nächsten Stufe verschiebt sich zwar dauernd, aber die Richtung ist eindeutig und heute schon binden. Das Schöne daran, die Werkzeuge, die das regulatorische Muster füllen, kosten keinen Franken, kein Euro, kein Cent. Das ist so eine Haltbarheit. Natürlich brauchen wir Menschen dazu. Natürlich brauchen wir jemanden, der sich darum
Elias: Ja, ja, ja.
Jan Dubs: kümmert. Die Frage ist nie das Budget, es ist einfach mehrheitlich die Disziplin dazu und das Erkennen im Management, dass solche Ressourcen extrem wertvoll werden. Wertvoller als jedes C-Mobo.
Elias: Ja, das ist so. es braucht natürlich Kapazitäten. Wenn man das diszipliniert machen möchte, brauchst du... Stand heute Menschen, auch wenn es natürlich viele versuchen
Jan Dubs: Gute Uhr.
Elias: mit AI zu ersetzen.
Jan Dubs: Ich kann dir helfen, am Ende des Tages, wir sehen uns ja selber immer wieder, dass du vorrinnen ein Meeting
Elias: Ja, Man kommt auf die im Best Case berühmt berüchtigten 80 Prozent. Manchmal
Jan Dubs: Ja.
Elias: sind es auch eher 60, aber dann sollte man sich spätestens ran setzen und nachbessern.
Jan Dubs: Und immer ist es einfach der Mitarbeiter frisst keine Token, der hat gerne sein Gehalt am Ende des Monats.
Elias: Das ist auch korrekt. So teuer wie es manchmal ist, ist es vielleicht auch wirtschaftlich schlau einfach mal wieder ein Junior einzustellen, Freunde.
Jan Dubs: Richtig, liebe Juniors, wir heirnen. Kommt auf uns zu.
Elias: Letzte Frage für heute. Ist schon die letzte tatsächlich. die bezieht sich aufs...
Jan Dubs: Heute sind wir schnell.
Elias: Ja, wir kommen gut durch. Wir kommen jetzt nochmal zum Tempo. Wir haben jetzt die ganze Zeit Regeln gebaut, die auf Verhalten schauen statt auf die Hashes. Das ist erstmal gut prinzipiell. Jetzt ist die Frage, was wir noch gar nicht beantwortet haben, wie schnell muss so eine Regel eigentlich sein, damit sie wirklich Impact hat, damit sie was ändern kann.
Jan Dubs: Stell die Frage nochmal in zwei Wochen, dann bin ich vielleicht drüber weg. Es gibt eine Zahl aus der großen Vorfallauswertung dieses Jahres, die auf über einer halben Million Stunden Untersuchungsarbeit aus 25 beruht. Und die Zahl lautet, die mittlere Zeit zwischen dem Erstzugang und der Übergabe an den nächsten Akteur liegt bei 22 Sekunden. Belegt im Mendiant Amtrans Report.
Elias: Okay, aus 20,25, 22 Sekunden und wie sah es vorher aus?
Jan Dubs: 22 waren es über 8 Stunden. 8 Stunden auf 22 Sekunden, das ist kein Trend, sondern das ist ein Zusammenbruch. Und der Grund ist unspektakulär, das ist die Industrialisierung. Der Zugang wird nicht mehr von Handweite gereicht, sondern automatisiert übergeben, sobald er da ist.
Elias: Okay, aber das macht ja meine schöne Verhaltensregel auf Erstzugang eigentlich wertlos,
Jan Dubs: Für den Zweck, für den du sie gebaut hast, ja. Wir haben 40 Minuten darüber geredet, wie man eine Regel baut, die zuverlässig feuert. Wenn sie auf den Erstzugang zielt und 3 Minuten später feuert, was in jedem realen Betrieb relativ schnell wäre, weil denkt daran, sie im grossen Datentopf, Indexierung etc.
Elias: Mhm.
Jan Dubs: Häufig ist die 7. Flaschenhaus bzw. die Ressource darunter, ist der Zugang längst bei jedem andermalst. alarmierst auf ein Ergebnis, dessen Folge schon eingetreten ist.
Elias: Und die zweite Zeit, die du vorhin noch erwähnt hattest.
Jan Dubs: Die passt ebenfalls ins selbe Bild. Der zweithäufigste Weg hinein war 25 nicht mehr eine Mail, sondern das Telefon. Stark, interaktives Wishing, also jemand ruft an, 11 % aller untersuchten Einbrüche. Für einen Anruf schreibe ich dir keine Sigma-Regel, da feuert nichts, weil im Log der ersten Minuten nichts steht, was verdächtig wäre. Es steht drin, dass sich jemand erfolgreich angemeldet hat.
Elias: stehen unsere letzten 40 Minuten jetzt gerade irgendwie bisschen wackelig, oder?
Jan Dubs: Ja, da war alles für die Katze. Nee, im Gegenteil. Aber das Ziel verschiebt sich. Und das ist die ehrlichste Fassung. Detection Engineering kauft dir keine Zeit an der Tür. Die Tür ist 22 Sekunden und dann durch. Was es dir kauft, ist die Zeit in der Mitte. Der zweite Akteur muss danach Dinge tun, die dauern und die sichtbar sind. Sich festsetzen, sich umschauen, Rechte ausweiten. sich lateral bewegen, Sicherungen wegräumen etc. Und genau da sitzt eine hässliche alte Regel auf der Kommandozeile des Bohrmittels. Das ist nicht trotz, sondern genau wegen dieser Zahl richtig gebaut.
Elias: Und was heißt das für die Cancer, an der ich meine Regel messen muss?
Jan Dubs: Das feuert sie. Die falsche Frage allein ist. Die zweite Frage ist, wie lange von feuern bis handeln haben wir? Eine Regel, die korrekt feuert und deren allein beispielsweise 40 Minuten in einer Warteschlange liegt, ist gegen den Ablauf, der in Sekunden übergibt, eine Dokumentationsmassnahme, du so willst. Die gute Nachricht aus derselben Auswirtung. 52 Prozent der Organisationen haben Aktivitäten 2025 zuerst selbst bemerkt. gegen 43 Prozent im Jahr davor. Das wird besser, eben nicht an der Tür. Also beim Eintrittspunkt müssen wir anders arbeiten.
Elias: Und der ein bisschen unangenehme Gedanke, den du vorhin auch schon angedeutet hattest mit der Theater.
Jan Dubs: Er ist noch nicht sauber belegt, deshalb sage ich ausdrücklich, das ist meine persönliche Meinung und nicht deine Studie. Viele Betriebe lassen sich inzwischen ein Sprachmodell, die erste Sichtung machen, also die ganzen LLMs übernehmen, da die Agents, die Agentics, SoC, Triage oder wie auch immer das heißen soll.
Elias: Mh mh mh.
Jan Dubs: Die schließen dann automatisch Fehlanarme, bevor ein Mensch sie sieht und jetzt denkt zu Ende, was dein Angreifer damit anfangen kann. Er schreibt in dein Log-File nicht als Angriff, sondern als Nebenprodukt, eine Dateinnahme, ein Prozessargument, einen Feldinhalt.
Elias: Also neuer Angriffsvektor, der Text landet dann da.
Jan Dubs: Genau. Dieser Text landet danach als Eingabe in deinem Modell, das entscheiden soll, ob der relevant ist oder nicht. Wir hatten ja in Abschnitt 5 gesagt, die grüne Kachel lügt, dass sie dies Lektion einfach ein Stockwerk hört. Sie lügt eben auch die ganze Instanz, die die Kachel entsprechend bewertet, wenn da entsprechendes Material in den Sexzeilen vorkommt.
Elias: Klingt doch schwitzenmäßig.
Jan Dubs: Bevor wir Schluss machen, der schnelle Faktencheckt wie immer. Elias, du fragst dich, ich antworte in einem Satz. Aber diesmal dreh es Du antwortest, ich will hören, ob sitzt. Warum war deine
Elias: Komm' amachen!
Jan Dubs: perfekte Regel von heute Vormittag tot?
Elias: Ja, sie hat auf einen Hasch geschaut, also das flüchtigste von allen ganz unten in unserer Feder erwähnten Pyramid und dementsprechend war beim nächsten Bild der Ransom Vers schon wieder ein anderer.
Jan Dubs: Genau, und warum lebt die hässliche alte Regel?
Elias: Warum lebt die hässliche Alte? Ja, nee nee
Jan Dubs: Ich hätte jetzt anderes gesagt, aber jetzt nicht Jugendfreude nehmen, Disclaimer, 18+.
Elias: nee nee. Das passt schon. Sie schaut halt auf die Kommandozeile, also ein schon vorhandenes Bordmittel, ein Verhalten, das der Angreifer nicht einfach weglassen kann, wenn er die Shadow Copies wirklich löschen möchte.
Jan Dubs: Was ist der Unterschied zwischen Visibility und Detection?
Elias: Visibility heißt, ich habe die Daten gesammelt, die Technik theoretisch sehen zu können. Und Detection heißt es dann, ich habe eine Regel, die darauf feuert, eine fehlende Kachel kann theoretisch beides sein. Und jedes Mal ist die Behebung dessen eine andere. Also du musst was anderes tun.
Jan Dubs: Jetzt die Königsdisziplin. Der eine Satz, du dir aus der ganzen Folge merkst.
Elias: Auf jeden Fall, dass sauber konvertiert nicht gleich feuern ist. Und das meintest du vor allem, da warst du scharf drauf. Eine ungetestete Regel ist nur eine Behauptung und noch kein Schutz.
Jan Dubs: Und wenn du das mitnimmst, hast du die Folge heute verstanden. Ein Handgriff für Montag, nur einer. Nimm eine bestehende Produktionsregel und teste sie wirklich. Führ die Technik aus, ich wette mit dir mindestens eine für heute nicht. Alles Weitere, die Ebenen-Einordnung und die ehrliche Landkarte, das schauen wir nachher an.
Elias: Ja, können wir so machen. Gibt's von dir noch einen Satz zur Folge?
Jan Dubs: Wenn auch du all diese Fragen mit Ja beantworten konntest, schreib uns ein Mail hello at cics.ca. Wir suchen immer wieder fähige Mitarbeiter. Ne, ganz klar,
Elias: Das ist so.
Jan Dubs: auch der strategische Satz zum Schluss, wie die Folge endet, nicht in einem Programm, sondern sie endet mit einer aufgedeckten Lücke. Trend dabei stets die zwei Sortenlöcher, existieren, die fehlende Sicht und die fehlende Regel. Das ist das ehrliche, viel ehrlicher als jede grüne Kachel, wie sie heute steht. Und das weißt du auch, wo diese Lücke wenigsten wehtut an der tür die ist ohnehin 22 sekunden durch
Elias: Ja und vielleicht noch die Brücke zum nächsten Mal. Wir haben jetzt die ganze Zeit über Regeln geredet, die feuern müssen, ohne den Analysten zu ertränken an irgendwelchen False Positives. Aber es gibt doch Verhaltensweisen auch, die sind einfach zu breit, sie so detektieren zu können. Wir haben das heute auch schon mal. Da wollen wir ansetzen, oder?
Jan Dubs: Genau, das setzen wir nächstes Mal an. Deine 200-mal am Tag-Regel, bevor sie gehärtet wurde, war zu breit,
Elias: Ja.
Jan Dubs: sie feuern zu lassen, aber zu wichtig, sie zu ignorieren. Was macht man mit so einer? Man lässt sie nicht als alarmlos, man jagt sie von Hand. Dieselbe Verhaltenslogik, aber mit mehr Toleranz für Fehlanarme und ein Menschen, triagiert. Nächstes Mal Threadhunting mit der CTI-Brille. Ich freue mich extrem auf diese Folge.
Elias: Ciao, denn.
Jan Dubs: nämlich was nicht aus Riegel und Feuer darf, jagst du von Hand.
Elias: Okay, ich würde sagen, das ist der Schlusssatz und von mir dann, wer uns unterstützen möchte, kann ein Newsletter abonnieren, uns folgen, uns weiterempfehlen, eine Bewertung hinterlassen, all diese wunderbaren Dinge und dann sehen wir uns in der nächsten Folge.
Jan Dubs: Bis dann geschüttelt und nicht gerührt.