Von der Flickenjacke zur Cyberresilienz: Wie schaffen wir es, Schwachstellen sexy zu machen?

Michael: Herzlich willkommen zu einer neuen Ausgabe von Cybersecurity Basement, dem Podcast für Security Content. Heute reden wir über ein Thema, das in fast jedem Security Report irgendwie auftaucht. Und trotzdem in der Praxis, ja, ich will nicht sagen stiefmütterlich, aber nicht immer mit der notwendigen Ernsthaftigkeit vielleicht behandelt wird. Es dreht sich alles um Schwachstellen. Warum wird es gefühlt so behandelt? Gar nicht, weil die Leute es nicht wissen, dass es Schwachstellen gibt. Es gibt, glaube ich, sehr, sehr viele Systeme, die dir mitteilen, dass es Schwachstellen gibt. Laut BSI gibt es 119 neue Schwachstellen pro Tag. Das macht über 40.000 neue Schwachstellen im Jahr, Software-Schwachstellen. Und da muss man ja erst mal Herr der Lage werden. Hinzu kommt jetzt noch die KI, die damit wirbt, dass Schwachstellen noch schneller erkannt und auch ausgenutzt werden können. In beide Richtungen verändert das Spiel so ein bisschen. Und darüber wollen wir jetzt sprechen. Und da ich immer zu wenig Ahnung von der Materie habe, habe ich mir einen Gast eingeladen, der mir alle Fragen rund um dieses Thema beantworten kann. Ich sage: Herzlich willkommen, Jan-Philipp Küsters. Einen wunderschönen guten Morgen! Jan-Philipp Küsters: Michael, guten Morgen! Grüß dich! Michael: Das waren schon Fake News. Es ist gar nicht Morgen. Es ist schon 12:00 Uhr. Müssen wir direkt zurückziehen. Jan-Philipp, du warst schon mal da bei uns im Podcast. Ich erinnere mich daran. Es war eine sehr, sehr schöne, spannende Folge. Heute bist du wieder zu Gast. Ich freue mich sehr. Da unsere Zuhörerinnen und Zuhörer dich aber wahrscheinlich nicht mehr auf dem Schirm haben: Stell dich doch mal ganz kurz vor. Sag, wer du bist und warum du vielleicht zum Thema Schwachstellen besonders aussagekräftig bist. Jan-Philipp Küsters: Ja, wie gesagt, mein Name ist Jan-Philipp Küsters. Ich bin 27 Jahre alt und bin mittlerweile schon das ein oder andere Jahr in der IT beschäftigt, im Bankensektor, und kümmere mich da primär um das Thema Schwachstellenmanagement. Bei uns durfte ich das mit aufbauen und mich mit dem Thema jetzt strategisch beschäftigen. Ich beschäftige mich auch relativ viel privat damit. Tatsächlich also so eine kleine Berufung. Michael: Oh, das ist spannend. Jan-Philipp Küsters: Genau. Michael: Zur Passion ist es geworden, sich mit Schwachstellen zu beschäftigen. Jan-Philipp Küsters: Ja, doch. Also ich sag mal, dieses tägliche Gucken, was so Neues auf dem Markt verfügbar ist an Schwachstellen, das ist irgendwie zur Routine geworden. Also auch wenn ich dann mal nicht im Dienst bin, dann schaue ich doch schon mal rein, was es vielleicht so Neues gibt. Michael: Ja, klingt spannend. Auch ein bisschen nerdy. Jan-Philipp Küsters: Tatsächlich, muss sein. Michael: Also ich habe mir auch schon mal die Datenbanken angeschaut, CVE-Datenbanken und Co. Es wirkt schon sehr nerdy. Wenn du dir allein die Übersichtsseite anguckst und dann nach „Was ist die kritischste?“ suchst und dann klickst du rein und es wird immer nerdier. Aber jedem seine Passion. Finde ich ja super. Dann wollen wir auch direkt mal ins Thema einsteigen. Ich habe im Intro so ein bisschen gesagt: Ja, das Thema wird irgendwie so ein bisschen stiefmütterlich behandelt in manchen Unternehmen. Also alle Unternehmen wissen, glaube ich, dass sie eben Schwachstellen haben. Aber nicht jede Schwachstelle ist irgendwie direkt es wert, angeschaut und betrachtet zu werden. Vielleicht kannst du direkt mal da so ein bisschen einsteigen und sagen: Wie wird das denn in der Praxis wirklich irgendwie gehandhabt? Also wann ist es wirklich so, dass man eingreifen muss? Wie geht man so ein Management von Schwachstellen denn an? Jan-Philipp Küsters: Ja, also zuerst sollte man auf jeden Fall eine gute Übersicht haben, was man so für Assets im Unternehmen betreibt. Und das ist so das A und O. Man kann nur das schützen, wovon man auch Kenntnis hat. Das gilt ja für viele Bereiche in der IT-Security, jetzt nicht nur für Schwachstellenmanagement. Und das ist so die Basis im Endeffekt, dass ich weiß, was für Assets habe ich im Unternehmen und wie kritisch sind die auch für mein Business? Das ist auch noch ganz, ganz wichtig. Klar, so ein grobes Inhaltsverzeichnis ist super, aber man sollte seine Kronjuwelen, wird ja oft verwendet, der Begriff, die sollte man auf dem Schirm haben, denn die sind ja besonders schützenswert. Wenn man diese Basis eben geschaffen hat, dann muss man sich überlegen: Alles klar, wie komme ich da jetzt eigentlich in diesen Modus, nach Schwachstellen zu suchen? Wie mache ich das? Da gibt es Techniken, wie man das manuell machen kann. Es gibt aber natürlich auch automatisierte Methoden, um das zu machen, mit Schwachstellenscannern. Genau, die erleichtern das natürlich zu prüfen: Bin ich jetzt von einer Schwachstelle betroffen oder bin ich es eben nicht? Weil die Schwachstellenscanner, die finden in der Regel fast nur Schwachstellen, wovon man natürlich auch betroffen ist. Genau, das ist so der Anfang. Michael: Das heißt, da wird es auch direkt an der Stelle schon so ein bisschen technisch. Du hast gerade was Wichtiges gesagt. Du hast gesagt, bevor ich mich mit dem Thema auseinandersetzen kann, bevor das Sinn macht, brauche ich eine Übersicht über meine Assets. Richtig? So in der Praxis: Ist das ein Hygienebaustein oder ist es eher so, dass Unternehmen das in der Regel manchmal auch gar nicht wissen? Das heißt, bevor ich mich mit Schwachstellen auseinandersetzen kann, baue ich erst ein Vorprojekt, wo ich mich dann mit meinen schützenswerten Assets auseinandersetzen muss. Jan-Philipp Küsters: Richtig. Genau. Also wie gesagt, das ist das A und O. Das ist sicherlich nicht everybody’s darling, so ein Asset Inventory zu führen. Es ist halt Fleißarbeit und es ist vor allem auch keine einmalige Aktion. Es ist jetzt kein Projekt, sondern es ist ein fortlaufender Prozess. Denn Assets im Unternehmen, die können sich ja verändern. Gerade bei größeren Unternehmen ist das quasi an der Tagesordnung. Das heißt, Assets kommen dazu, Assets gehen aber auch wieder und das muss man auf jeden Fall im Blick behalten. Michael: Vielleicht mal so ein paar Beispiele: Was sind Assets, die da so reinfallen? Ist es jetzt mein Firmencomputer oder sind das in der Regel einfach neue Applikationen? Oder ist es beides? Oder ist es alles? Jan-Philipp Küsters: Ja, das kann von A bis Z alles sein. Also klar, die IT-Systeme sollten ja auf jeden Fall da drin sein. Server, Clients, Netzwerkkomponenten etc. Software kann da auch eine Rolle spielen. Wobei man fairerweise sagen muss, wenn man jetzt auch Schwachstellen scannt, dann scannt man ja in der Regel erst mal die IT-Systeme, worauf sich dann Software befindet. Wenn man dann in die Cloud geht, dann sieht das schon ein bisschen anders aus. Da kennt man ja nicht die IT-Systeme, ich sage jetzt mal von Microsoft, sondern es kann dann über Apps, Cloud-Konfigurationen gehen. Michael: Okay, warum muss ich mich überhaupt mit Schwachstellen auseinandersetzen? Denn ich hole mir einfach Arbeit ins Haus. Richtig? Jan-Philipp Küsters: Ja, Schwachstellen, das ist auf jeden Fall sehr viel Arbeit. Je nachdem, wie groß auch die eigene IT ist, wie viel man hat. Warum macht man das? Klar, um sich gegen Cyberangriffe zu wappnen. Du nutzt ja auch immer gerne das Allianzbarometer: Geschäftsrisiko Nummer eins, Cyberangriffe. Und ja, man sollte einfach auch schon aus dem Aspekt, um seine Assets zu schützen, das machen. Aber natürlich gibt es da auch regulatorische Anforderungen, gerade im Bankensektor. Wir haben in der ersten Folge darüber gesprochen, die DORA, der Digital Operational Resilience Act, der einfach vorschreibt, dass Banken oder generell Unternehmen im Finanzsektor ihre Systeme resilient gestalten sollen. Da ist auch ein ganz großer Punkt eben das Thema Schwachstellenmanagement. Dann, wenn man mit anderen Unternehmen zusammenarbeitet, wird ja oft auf Zertifizierungen geachtet. Die ISO 27001 zum Beispiel. Da steht ja auch drin geschrieben, wie man ein Schwachstellenmanagement zu gestalten hat. Also das sind diverse Aspekte, die dann eine Rolle spielen. Manche sind auf freiwilliger Basis, manche sind aber halt auch wie die DORA einfach eine Verordnung, wo man sich dran halten muss. Michael: Jetzt gibt es doch auch seit einiger Zeit schon dieses Security by Design. Also wenn ich mir was überlege, ein Produkt, das entwickle, Code, was auch immer, dann sollte ich Security schon bei der Entwicklung berücksichtigen. Warum gibt es eigentlich immer wieder neue Schwachstellen? Also ich habe ja gerade gesagt, es sind über 40.000, die allein das BSI registriert pro Jahr, neue Schwachstellen zu den schon bestehenden. Das ist ja, wie man früher bei ProSieben Galileo gesagt hätte, ein Fass ohne Boden. Jan-Philipp Küsters: Definitiv, ja. Es gibt natürlich fleißige Menschen, die sich damit beschäftigen, die es dann als Hobby haben, Schwachstellen zu suchen. In Produkten zum Beispiel, die Sicherheitsforscher, die da das eine oder andere Produkt dann gerne etwas in die Mangel nehmen. Alte Produkte, alte Softwareprodukte, Legacysysteme, wo dann einfach auch nicht mehr aktiv nachgeschaut wird und wo dann einfach Schwachstellen nach und nach ans Tageslicht kommen. Das soll ja auch, du hattest das ja gerade gesagt, das Security by Design, das soll ja der Cyber Resilience Act jetzt auch verhindern, dass quasi digitale Produkte einfach schon von Haus aus sicher gemacht werden und dass es da noch ein, zwei weitere Rahmenwerke bzw. Regeln gibt, die dann begünstigen, dass solche digitalen Produkte einfach sicher gehalten werden. Aktives Schwachstellenmanagement auch bei denen. Genau, das hat halt unterschiedliche Gründe, warum es so viele Schwachstellen gibt. Ich erinnere mich an eine Zeit im Google Chrome, da hatten die Sicherheitsforscher den Chrome ganz schön im Visier und da kam gefühlt täglich eine Schwachstelle nach der anderen. Und da war bei uns im Team dann auch schon irgendwann: Ja, wir patchen jetzt einfach nicht mehr, weil es auch nicht die Lösung ist. Michael: Aber lass uns doch mal eintauchen in so einen Lebenszyklus von einer Schwachstelle. Die wird ja irgendwie entdeckt, identifiziert, ins Leben gerufen. Da bekommt die eine Nummer. Sie wird veröffentlicht, dann werden Schwachstellen-Enthusiasten wie du darauf aufmerksam. Und wie geht es dann weiter? Gibt es in der Datenbank schon Lösungsansätze? Diskutiert die Community? Und wie löst man dann dieses Schwachstellenproblem eigentlich überhaupt? Jan-Philipp Küsters: Ja, also nachdem die Schwachstellen dann veröffentlicht worden sind unter dieser einheitlichen Nummer, CVE-Nummer, die sich ja zusammensetzt quasi aus dem Baustein, dann dem Jahr, in dem sie gefunden worden ist, und dann laufende Nummer darunter, kann man im Endeffekt erst mal so grobe Infos sich anschauen. Also diese Nummer ist eindeutig für genau diese Schwachstelle. Die kann man dann einfach bei Google zum Beispiel eingeben und da sieht man dann vielleicht das Security Advisory vom Hersteller, Einschätzungen von diversen Behörden, ob sie jetzt aus Deutschland kommen oder auch aus anderen Ländern dieser Welt. Und da steht dann oft erst mal so grob drin: Was ist das Problem und wie lässt sich das beheben? Also ganz platt: Wir haben hier eine Remote Code Execution, die vielleicht grundsätzlich möglich ist. Und die lässt sich beheben, indem man auf den aktuellen Patch die Software updatet oder das System updatet. Und damit man aber so ein bisschen in diesen Zyklus kommt. Du sagtest ja, es sind sehr, sehr viele Schwachstellen, die täglich auftauchen. Wie behandele ich die, in welcher Reihenfolge? Da muss man irgendwie ein Mittel finden, um die Schwachstellen zu priorisieren. Und da gibt es viele verschiedene Metriken oder Scoring-Systeme, die das halt ermöglichen. Und da muss man dann erst mal schauen, dass man sich da einen geeigneten Weg aussucht. Michael: Du hast gerade schon angesprochen, das Thema des Patches. Also es wird eine Schwachstelle erkannt. Das heißt, es gibt da irgendwie ein irgendwie geartetes Problem und dann wird so ein Patch drauf gemacht. Ein Patch heißt, glaube ich, flicken, übersetzt. Ein Flickenteppich stellt man sich nicht als etwas sehr Robustes vor. Ich stelle mir vor, wenn du so viele Flicken zum Beispiel auf eine Jacke machst, irgendwann sieht das Ding halt auch scheiße aus. Also ist es immer so, ich nehme einen Patch, packe den drauf und dann habe ich halt irgendwann einen Haufen von Patches auf diese Lösung gepackt und trotzdem habe ich da das Gefühl als Schwachstellen-Enthusiast: So, das ist trotzdem noch eine saubere Angelegenheit. Damit kann ich gut arbeiten. Jan-Philipp Küsters: Es kommt so ein bisschen darauf an, wie man da vorgeht. Es gibt so zwei zentrale Begriffe: die Remediation und die Mitigation. Und die unterscheiden sich halt. Die Remediation, da sagt man dann, ist die Schwachstelle vollständig behandelt. Also es gibt quasi kein Risiko mehr. Und die Mitigation, das sind eher so risikominimierende Maßnahmen. Also ich sage jetzt mal in der Analogie der Jacke, wenn ich da jetzt ein Loch drin habe, dann klebe ich da einen Patch drüber und das hilft dann für eine gewisse Zeit, bis auch dieser Patch dann irgendwann wieder abfällt. Das kommt dann so ein bisschen darauf an, wie man diese Schwachstelle behandelt. Bei Patches, die von Herstellern dann veröffentlicht werden, das ist ja was ganz Normales in so einem Software-Lebenszyklus. Da würde ich schon sagen: Okay, das gehört dazu und der Hersteller wird wissen, was er da tut. Nicht alle, aber viele. Das ist ganz normal. Aber wenn man mal ein System aufsetzt, wo man immer wieder Workarounds einspielt, vielleicht auch Workarounds, die nicht unbedingt durch den Hersteller supported sind, dann bastelt man sich da irgendwann so eine Jacke zusammen und das System sieht dann am Ende schon ziemlich blöd aus. Ja, die Sicherheit mit obendrein. Michael: So, jetzt stellen wir uns das Ganze noch mal vor. Wir haben jetzt schon drei Parts: Wir haben das Asset Management. Wir haben das Schwachstellenmanagement. Dann haben wir auch dann hintergelagert noch das Patchmanagement, also diese drei Arbeitsblöcke, Bereiche, die irgendwie ja zueinander gehören. Und du hast eben schon gesagt, ich muss irgendein System finden, irgendeine Methodik finden, wie ich an Schwachstellen herangehe. Ist es klassisch: Ich schaue mir die kritischsten an und löse sie dann? Weil Fakt ist natürlich, wenn 119 neue Schwachstellen auftauchen, klar, ich habe jetzt nicht alle Systeme irgendwie im Einsatz, aber keine Ahnung, ob es jetzt 50 sind, dann kann ich ja die nicht an einem Tag dann irgendwie bearbeiten und auch gleichzeitig noch patchen. Stelle ich mir zumindest so vor. Also welcher Tools, welcher Methodiken, welcher Frameworks kann ich mich da irgendwie bedienen, um der Lage Herr zu werden? Jan-Philipp Küsters: Das ist eine gute Frage. Es gibt sehr, sehr viele. In der Vergangenheit hat sich, glaube ich, das Common Vulnerability Scoring System sehr bewährt. Das ist ein einheitliches System zur Bewertung von Schwachstellen. Da wird einfach der Schweregrad der Schwachstelle bewertet. Und wenn man so eine CVE-Nummer dann bei Google eingibt, dann wird man auch relativ schnell immer so einen CVSS Base Score finden. Und dieser Base Score, der wird entweder von einem Hersteller berechnet oder von Cybersicherheitsbehörden berechnet und der gibt so grob erst mal an: Okay, wie schwer wiegt denn diese Schwachstelle jetzt im allgemeinen Kontext? Und anhand dieses Base Scores kann man dann erst mal eine Priorisierung zur eigentlichen Bewertung dieser Schwachstelle vornehmen. Das heißt alles, was ich sage mal initial durch Dritte als kritisch eingestuft wurde, das sollte ich mir vielleicht dann auch schon mal für meine Systeme anschauen bzw. diese Schwachstellen priorisiert bewerten und alles, was dann darunter liegt, das kann dann nachgelagert erfolgen. Es empfiehlt sich auf jeden Fall auch, für diese Priorisierung SLAs zu definieren, dass man jetzt kritische Schwachstellen, also initial kritisch bewertete Schwachstellen, dass man die jetzt vielleicht sich zügig anschaut und Schwachstellen, die vielleicht halt niedrigere Schweregrade haben, dann etwas später. Michael: Ja, jetzt ist „sehr zügig“ natürlich kein richtiges SLA, weil zügig kann ja bei einem sehr langsamen Menschen auch anders definiert sein als das sehr schnell ist. Das heißt, gibt es irgendwie eine Empfehlung, dass du sagst, keine Ahnung, also eine kritische Schwachstelle müsste eigentlich irgendwie innerhalb von 48 Stunden erkannt, behoben, gepatcht worden sein und getestet? Jan-Philipp Küsters: Das kommt so ein bisschen auf die internen Prozesse an im Unternehmen. Also bewertet werden für die eigene Infrastruktur sollte sie definitiv innerhalb von wenigen Stunden, am gleichen Business Tag. Die Behebung, das sollte ja gemeinsam mit einem größeren Team besprochen werden. Es gibt ja in vielen Unternehmen dann Security-Teams, die aus einem Leiter bestehen, aus einem SOC bestehen oder aus einem ISB, je nachdem, aus dem Leiter vom IT-Bereich etc. Und dieser Personenkreis, der sollte sich dann zusammensetzen, nachdem identifiziert worden ist, dass diese Schwachstelle auch für uns intern kritisch ist. Und dann muss das gemeinsame Vorgehen besprochen werden. Es könnte ja zum Beispiel auch ein Vorgehen sein, dass man dann sagt: Okay, wir können nicht direkt patchen, weil die Business-Kritikalität dahinter gerade zu hoch ist. Aber wir leiten risikominimierende Maßnahmen ein. Wir stellen das System in ein eigenes Netzwerksegment oder wir schalten gewisse Schnittstellen ab, die diesen Angriff auf diese Schwachstelle begünstigen. Michael: Jetzt hast du noch was Wichtiges gesagt, was so ein bisschen untergegangen ist, glaube ich. Deshalb habe ich es mir kurz notiert und hole es noch mal raus. Du hast nämlich gesagt, dass du die Kritikalität einer Schwachstelle auf deine eigene Infrastruktur prüfen musst. Das heißt, nur weil sie jetzt laut CVE einen hohen Score hat, laut CVE selber, muss es nicht unbedingt heißen, dass ich das gemünzt auf meine Infrastruktur auch so eine Kritikalität haben muss. Jan-Philipp Küsters: Richtig. Michael: Genau. Okay, perfekt. Jan-Philipp Küsters: Das ist ganz wichtig. Das gibt auch zum Teil das Common Vulnerability Scoring System her. Da gibt es noch zwei andere Metriken oder zwei andere Bereiche. Einmal den Temporal Score und den Environmental Score. Und der Temporal Score, der sagt erst mal so ein bisschen: Okay, wie schwer wiegt diese Schwachstelle jetzt im zeitlichen Kontext? Gibt es einen Patch, gibt es Exploits und wie wahrscheinlich ist das überhaupt, dass diese Schwachstelle existiert? Also hat das ein Hersteller jetzt zum Beispiel rausgegeben in seinem Security Advisory oder ist das bei Reddit aufgetaucht? Das sind ja schon mal zwei unterschiedliche Voraussetzungen. Und im Environmental Score, da geht man dann eben darauf ein, welche Auswirkungen die Schwachstelle auf die eigene Umgebung hat. Also ist das System, wo die Schwachstelle drauf ist, hängt das am Internet dran? Welchen Schutzbedarf hat das System, wo die Schwachstelle drauf gefunden worden ist? Aber auch da wichtig: CVSS ist wirklich eher ein Mittel für den Schweregrad und nicht für das Risiko. Das sind ja zwei unterschiedliche Paar Schuhe. Für das Risiko gibt es dann wieder weitere Scoring-Systeme. Michael: Okay, bevor wir jetzt da einsteigen, lass uns wieder den Faden aufnehmen. Wie werden wir der Lage Herr? Jetzt leben wir ja im Jahr 2026 und ich stelle mir jetzt natürlich die Frage: Das muss doch auch irgendwie automatisiert vonstattengehen. Jan-Philipp Küsters: Definitiv. Michael: Also ich sage einem System, welche Assets ich habe. Dieses System prüft dann immer die Datenbank gegen meine Infrastruktur und sagt mir dann ganz genau täglich: Hey, du hast jetzt die und die drei Top-Priority-Topics und an denen musst du arbeiten. Hast du mit diesen Schwachstellenscannern, sei es Qualys, Rapid7, gibt es noch zig andere, hast du damit Erfahrung gesammelt? Wie gut sind diese Plattformen? Und vielleicht kannst du auch sagen: Also wann hört dieser automatisierte Prozess auf, wann musst du einsteigen? Gib uns mal ein paar Insights dazu. Jan-Philipp Küsters: Ja, also wir selber arbeiten natürlich auch mit Schwachstellenscannern. Das sieht auch zum Beispiel die DORA so vor und die sind super. Man muss halt wissen, welche Assets man hat. Und diese Assets müssen dann in die jeweiligen Scans eingepflegt werden. Da muss man dann auch schauen: Kann jedes System überhaupt bei uns gescannt werden? Drucker zum Beispiel, relativ schwierig, ehrlicherweise. Wir hatten mal einen Fall, da haben wir dann angefangen, die Drucker zu scannen, und der Drucker hat aber tatsächlich jeden Befehl, den der Schwachstellenscanner an diesen Drucker geschickt hat, ausgedruckt. Du kannst dir vorstellen, das war dann mehr als ein Roman, der dann aus dem Drucker rausgekommen ist. Und da muss man so ein Feingefühl entwickeln, auch gerade wann man die Systeme scannt. Aber grundsätzlich ist das super, weil im Endeffekt spuckt dieser Schwachstellenscanner alles das aus, wovon du auch wirklich betroffen bist erst mal. Sonst hätte er ja die Schwachstellen nicht identifizieren können. Klar, da gibt es auch False Positives, aber genau da ist im Endeffekt dieser Cut. Der Schwachstellenscanner, der gibt dir alles aus, was er quasi in so einer Schwachstellendatenbank finden konnte, was auf deinem System vorhanden ist. Und dann bist du an der Reihe, das zu organisieren, wie du das abarbeitest. Und das fängt dann eben mit der Priorisierung der Bewertung an und geht dann weiter zur internen Bewertung. Michael: Das heißt, ab diesem Moment, wo der Scanner eine relevante Schwachstelle übermittelt, bin ich auf mich allein gestellt, muss also mein eigenes Hirn anstrengen, um mich mit dieser Schwachstelle dann auseinanderzusetzen. Es gibt keinen Knopf: Patch mir das. Jan-Philipp Küsters: Die wird es sicherlich geben, aber auch da: Also ich habe damit noch keine Erfahrungen gemacht, einfach aus dem Grund, dass so ein Schwachstellenscanner ja erst mal doof ist. Der prüft ja erst mal einfach nur ganz platt: Bist du betroffen oder bist du nicht betroffen? Und dann sollte es schon Menschen geben, die sich das genau anschauen, wie man da jetzt betroffen ist. Und das Patchen, da hängt ja viel mehr dran, als einfach jetzt den Knopf zu drücken und zu sagen: Update. Wenn ich jetzt ein System update, was für mich hochkritisch ist im Betrieb und was über den Tag eher nicht ausfallen darf und am nächsten Tag auch wieder zur Verfügung stehen muss, dann sollte ich mir fünfmal überlegen, ob ich so ein System gerade in der Produktion update oder ob ich dafür auch ein Testsystem brauche, um das zu überprüfen. Das heißt, da hängt im Endeffekt viel mehr dran als so ein einfaches Klick und dann ist die Welt wieder in Ordnung. Michael: Den Punkt hast du natürlich. Bei kritischen Systemen wäre es schlecht, wenn einfach was gepatcht würde. Dennoch mag es ja vielleicht Bereiche geben, die vielleicht nicht so kritisch sind, wo ich mir dann ja einen Bereich quasi durchautomatisieren könnte. Anschlussfrage: Inwieweit müssen wir natürlich auch ansprechen an der Stelle. Klar, inwieweit helfen solche KI-Agenten dann? Können die helfen, können die Arbeitsschritte übernehmen, sodass ich meine Schwachstellenlast auch vollautomatisiert reduzieren kann? In diesen Bereichen ist ja auch auf dem Weg im SOC vieles wegautomatisiert, weil eben nicht so kritisch. Wieso ist das noch nicht so möglich oder ist es möglich? Jan-Philipp Küsters: Also ich kann nur aus meiner Erfahrung sprechen, dass das aktuell in unserem Sektor nicht genutzt wird. Ich glaube einfach deswegen, weil zu viele Entscheidungen da noch dranhängen und zu viele Verantwortlichkeiten. Nehmen wir jetzt mal einfach das Beispiel aus dem SOC. Wenn jetzt ein User sich auf einmal von einer ganz anderen IP anmeldet und diese IP vielleicht halt irgendwie schon als schadhaft, boshaft hinterlegt ist, dann ist ja die Sache relativ klar, dass dann vielleicht dahinter der User gesperrt wird. Aber wenn ich jetzt einfach anfange, Systeme zu patchen, hat das grundsätzlich ja auch erst mal Auswirkungen auf den Betrieb. Klar, beim Chrome, da hat man vielleicht immer noch den Edge und das dauert jetzt auch nicht mehr lange. Aber es gibt ja durchaus Updates, die halt einfach komplexer sind. Also ich denke da jetzt gerade an Linux-Systeme, da ist das jetzt vielleicht nicht mal eben gemacht. Genau aus dem Grund nutzen wir das auch noch nicht. Aber wir nutzen KI, um Informationen anzureichern. So eine Schwachstelle für sich, die ist erst mal für sich. Aber es gibt ja auch durchaus, nennt man dann wohl einfach Schwachstellen, die aneinandergereiht böswillig werden können. Also die können dann vielleicht alle drei mittel bewertet sein, aber sind dann in Kombi, wenn sie ausgenutzt werden, nicht mehr ganz so mittel. Und da hilft halt eben KI. Das können die Schwachstellenscanner nicht so gut: Schwachstellen miteinander zu verknüpfen und quasi einen Angriff herzustellen. Michael: Verstehe, verstehe. Das ist quasi Stand heute, 2026. Was denkst du, wo sind wir in drei Jahren? Provokante These: In drei Jahren, also wenn ich eine KI mit allen Informationen füttere, die dir jetzt auch zur Verfügung stehen, macht die das dann nicht irgendwann besser oder genauso gut? Jan-Philipp Küsters: Das kann man sicherlich beantworten mit Cloud Mythos. Da ist ja schon was Gutes auf dem Weg, was ja grundsätzlich erst mal für die Verteidigerseite helfen soll. Hoffen wir mal, dass es so bleibt. Ich denke, in drei Jahren wird es ja sicherlich Mittel und Wege geben. Und klar kann man sich das auch jetzt schon selber basteln. Es funktioniert alles. Also in der IT sind die Möglichkeiten grenzenlos. Es ist halt immer nur die Frage, was für ein Risiko möchte ich eingehen und wie weit möchte ich mich von irgendwas abhängig machen? Ich denke schon, dass wir in drei Jahren da deutlich weiter sind, aber immer abhängig von der Business-Kritikalität. Das ist das, was die Scanner eben halt nicht so gut einschätzen können. Da gibt es auch Mittel und Wege, das KI gerne schon mitzugeben oder vielleicht im System, wo ich meine Schwachstellen drin manage. Aber auch da bin ich immer noch der Verfechter: Da sollte immer noch jemand einfach einmal draufschauen. Michael: Der berühmte Human in the Loop. Jan-Philipp Küsters: Genau. Michael: Sehr gut. Jetzt lass uns mal ein bisschen die Perspektive wechseln. Du hast schon gesagt: Ja, du bist Schwachstellen-Enthusiast. Das habe ich jetzt einfach mal erfunden. Aber du beschäftigst dich ja auch strategisch mit dem Thema und du wirst ja sicherlich auch mal in den Genuss gekommen sein, das Thema Schwachstellen zu reporten in irgendeiner Art und Weise. Was sind so deine Erfahrungen? Was findet das Management da überhaupt spannend? Interessieren die sich für die Anzahl? Interessieren sie sich einfach nur für die Entwicklung? Habe ich mehr oder weniger als letzte Woche? Was kannst du uns da mitgeben? Jan-Philipp Küsters: Ja, also grundsätzlich interessiert das Management eigentlich relativ wenig so das Technische, sondern eher: Was für Auswirkungen hat das auf mein Unternehmen? Und da dann auch nicht Momentaufnahmen, sondern auch eher Trends. Also wie performen wir gerade im Schwachstellenmanagement? Haben wir super viele Schwachstellen offen? Wobei das auch eigentlich nichts sagt. Michael: Kein gutes KPI ist. Jan-Philipp Küsters: Genau, ohne dann das entsprechende Risiko mitzugeben. Es geht vielleicht auch darum, wie entwickelt sich das Gesamtrisiko der Schwachstellen. Also habe ich dann im ersten Quartal weniger Risiken, die durch Schwachstellen resultieren, und dann im zweiten Quartal schnellt das auf einmal in die Höhe. Da könnte man dann schon aus Managementsicht sagen: Okay, jetzt habe ich ja hier diverse Risiken, die ich tragen muss, wo ich vielleicht auch Kapital hinterlegen muss. Wie kann das sein? Und da gibt es dann halt diverse Möglichkeiten gegenzusteuern. Man kann sagen, man verkürzt die Patchzyklen. Die SLAs müssen ein bisschen enger geschnürt werden. Vielleicht gibt es aber auch Produkte, die man im Unternehmen einsetzt, wo die Hersteller einfach nicht so zuverlässig sind und Patches nicht schnell genug bereitstellen, sodass man dann die internen SLA reißt. Da gibt es viele Dinge, die da so einen Vorstand oder die Geschäftsführung generell interessieren können. Halten wir uns an die eigenen SLAs? Also haben wir auch genug Leute, die sich um die Themen kümmern? Das ist auch noch mal so ein Thema. Michael: Wenn ich jetzt richtig verstanden habe, dann geht das ja in so eine Richtung, sage ich mal Business Continuity Management. Das heißt, ich habe meine Risiken aus der gesamtunternehmerischen Betrachtung im Blick. Und das Schwachstellenmanagement trägt seinen Teil dazu bei, dass wir eben Risiken minimieren in zum Beispiel Produktionsstätten oder so, dass die nicht ausfallen, dass wir da Verfügbarkeit gewährleisten können usw. Also das sind Dinge, die dann auch im Management vorgestellt werden. Jan-Philipp Küsters: Definitiv, klar. Also besonders dann, wenn die nicht behoben sind. Also wenn wir jetzt Schwachstellen haben und die sind über ihre eigentliche Frist, dann schaut man schon mal genauer hin: Okay, was haben wir da jetzt für ein Risiko? Und wenn diese Risiken dann auch nicht gerade klein sind, dann muss man das dem Vorstand reporten und der möchte natürlich dann auch wissen, was man dagegen tut. Michael: Ein kleines Experiment: Wir malen uns mal so eine grüne Wiese. Du bist jetzt in einem Unternehmen und du kannst das Tool für das Thema Management einmal komplett neu aufsetzen. Was sind für dich essenzielle Tools, die du auf jeden Fall brauchst, um es abzubilden? Jan-Philipp Küsters: Definitiv ein funktionierendes Asset Management als Basis. Ohne das geht gar nichts. Dann sollte man auf jeden Fall über einen Schwachstellenscanner nachdenken. Denn das Ganze manuell alles zu prüfen, das ist sehr mühselig. Die Datenbanken sind groß, es kommen jeden Tag neue Sachen rein. So ein Schwachstellenscanner, der erleichtert da auf jeden Fall die Arbeit. Der prüft ja auch nicht nur, sind die Schwachstellen jetzt vorhanden, sondern sind sie auch wieder weg. Das ist ja auch vielleicht was Angenehmes. Also mit jedem Scan entdecke ich neue Schwachstellen und mit dem Scannen kann ich aber auch prüfen, ob diese Schwachstellen behoben worden sind. Dann sollte man gucken, wo man sich weitere Informationen beschafft. Es wird immer Systeme geben, die man nicht scannen kann. Auch die müssen in das Schwachstellenmanagement mit eingebunden werden, allerdings dann eher manuell. Da muss man Mittel und Wege finden. Man sollte sich ein super Team aufbauen, also Strukturen im Unternehmen etablieren. Welche Stelle bewertet die Schwachstellen? Welche Stellen patchen die Schwachstellen? Und auf welcher Basis passiert das? Und was mache ich aus diesen gewonnenen Ereignissen bzw. aus diesen gewonnenen Informationen, wenn es gerade nicht so gut läuft oder gut läuft? Also wie handhabe ich meine KPIs, also quasi dieses Plan-Do-Check-Act? Michael: Das klingt nach einem sehr vernünftigen Setup. Wir haben jetzt oft darüber gesprochen, dass man Schwachstellen irgendwie identifizieren, erkennen muss und dann patchen. Jetzt haben wir aber auch schon die Legacy-Systeme angesprochen. Wie gehen wir mit Schwachstellen um, die wir eigentlich gar nicht mehr gepatcht bekommen? Also ich denke mal an auch wieder produzierende Industrie. Ich habe Produktionsmaschinen aus den 70er- und 80er-Jahren, die laufen aber noch. Der Hersteller ist aber gar nicht mehr existent. Das heißt, für meine Maschine kriege ich auch keinen Patch mehr. Was mache ich dann wirklich? Das mit einem Verband ein oder direkt in Gips? Was mache ich da? Jan-Philipp Küsters: Ja, auf jeden Fall erst mal das Risiko betrachten. Also welche Eintrittswahrscheinlichkeit habe ich überhaupt, dass mir da was passieren kann? Und welche Schadenshöhe resultiert daraus? Das wäre mal als Erstes zu betrachten. Wenn ich eine geringe Eintrittswahrscheinlichkeit und eine geringe Schadenshöhe habe, dann lohnt es sich da vielleicht gar nicht groß, ich sage jetzt mal, was in Bewegung zu setzen. Wenn ich jetzt aber ein großes Risiko habe, dann sollte ich mir schon Gedanken machen: Wie minimiere ich dieses Risiko? Also stelle ich dieses System in ein Netzwerksegment, was auch besonders abgesichert ist. Oder das ist zum Beispiel im Bankensektor so: Wenn ich ein Legacy-System betreibe, muss ich prüfen, ob ich dieses System nicht durch ein anderes System ersetzen kann, was halt in Wartung ist. Das ist immer so eine wirtschaftliche Entscheidung sicherlich. Auch wenn diese neue Anschaffung jetzt 5 Millionen € kostet und der wirtschaftliche Schaden, der da resultieren kann, wenn die Schwachstelle ausgenutzt wird, 1 Million € beträgt, ist das eine Entscheidung, die die Geschäftsführung treffen muss. Das ist leider immer so ein bisschen, wo man dann als ITler so dazwischenhängt. Man weiß ja: Okay, diese Schwachstelle, wenn die ausgenutzt werden würde, das wäre schon so semi gut. Wenn dann aber die Geschäftsführung halt sagt: Ja nee, so eine neue Maschine kostet uns dann 5 Millionen € und du sagst mir, 1 Million € wäre das Schadensausmaß, wenn deine Schwachstelle ausgenutzt wird, dann wird sich jede Geschäftsführung wahrscheinlich dafür entscheiden: Ja, dann nehme ich das Risiko in Kauf. Michael: Okay, du hast eben noch gesagt, als du deinen Schwachstellenapparat skizziert hast: Du brauchst natürlich auch Personal. Ja, jetzt wissen wir aber alle mit dem Personal, den Fachkräften im Security-Bereich: Das ist jetzt nicht so, dass du heute eine Stellenanzeige schaltest und morgen hast du jemanden, der sich dem da auch annimmt. Wie ist deine Einschätzung zum Thema Einbindung von Dienstleistern, Partnern, MSP in diesem Prozess? Ist das etwas, was man auch outsourcen kann? Oder sagst du: Nee, nee, nee, Moment mal, dafür brauchst du eigentlich zu viel internes Wissen, um dann auch die richtigen Dinge zur richtigen Zeit zu tun. Jan-Philipp Küsters: Ja, da bin ich immer ein bisschen zwiegespalten. Wenn ich in einem dritten Unternehmen meine Schwachstellen offenlege, dann habe ich ja diese Informationen schon wieder an einen weiteren Ort verlagert. Auch daraus kann grundsätzlich ja eine Gefahr resultieren. Dieses interne Wissen, ich glaube, das lässt sich alles, soweit es nötig ist, dokumentieren. Aber gerade eben aus dieser Thematik, dass das ja schon sensible Daten sind, die man da an Dritte weitergibt, bin ich der Meinung, dass das im eigenen Hause betrieben werden sollte. Gerade auch, weil die Schnittstellen zu anderen Bereichen sehr, sehr kurz sind. Aber auch da lohnt es sich sicherlich für manche Mittelständler oder kleinere Unternehmen nicht, so was Eigenes aufzubauen. Und dann sind natürlich Dienstleister, die sich darauf spezialisiert haben, ein absolut gutes Mittel. Michael: Verstehe ich gut. Jetzt haben wir viel über Schwachstellen gelernt heute. Und ich sagte ja eingangs schon, Schwachstellen werden manchmal stiefmütterlich behandelt oder vielleicht sogar in der Regel. Irgendwie hat das Ganze ein schlechtes Image. Wie schaffen wir es, Schwachstellen sexy zu machen? Also dass man sagt: Wow, da habe ich aber jetzt richtig, richtig Bock drauf. Wie werden wir alle Schwachstellen-Enthusiasten, so wie du es bist? Jan-Philipp Küsters: Ja, man würde ja vermutlich auch irgendwie nicht zu Hause die Haustür so lassen, wie sie ist, wenn man wüsste, dass das Schloss vielleicht defekt ist und dass man damit mit jedem beliebigen Schlüssel reinkommt. Insofern muss man sich vielleicht einfach der Gefahr bewusst werden, dass eine gute Schwachstellenhygiene mittlerweile dazugehört. Und klar ist das an der einen oder anderen Stelle super nervig. Bei uns wird das auch verglichen so ein bisschen wie mit Mathe früher in der Schule. Da hatte auch niemand so richtig Lust drauf, aber es musste irgendwie gemacht werden. So würde ich das mit den Schwachstellen auch handhaben. Und so schlimm ist es im Endeffekt gar nicht, denn man lernt ja auch relativ viel und es ist nun mal die Basis für diverse Sicherheitsaspekte im Unternehmen. Und wenn man halt nicht offen gegenüber Cyberangriffen sein will, dann sollte man schauen, dass man seine Systeme sicher hält. Ich finde, das zählt auch im privaten Bereich einfach mittlerweile dazu, dass man seine Systeme regelmäßig updatet, sein Handy regelmäßig updatet. Auch da gab es ja jetzt kürzlich in älteren Apple-Betriebssystemen Schwachstellen, wo es jetzt nicht so super schwer war, dass die ausgenutzt werden können. Und ich glaube, das gehört zum digitalen Zeitalter einfach dazu und man muss da vielleicht auch erst mal so ein bisschen reinwachsen. Also wenn man einmal dabei ist, dann ist das auch nur noch halb so schlimm, dann macht das echt Spaß. Schwer vorzustellen. Michael: Es war ein schönes Plädoyer für das Thema Schwachstellen. Danke dafür. Jan-Philipp Küsters: Gerne. Michael: Nehmt euch das mit. Ja, macht aus euren Schwächen wieder Stärken und dann geht ihr mit einer gesunden Cyberresilienz in die nächsten Jahre. Ja, ich würde sagen, wir machen die Folge zu. Ich danke dir, dass du deine Expertise mit uns geteilt hast. Jan-Philipp Küsters: Ich danke dir! Michael: Wenn es noch Fragen gibt, liebe Zuhörerinnen und Zuhörer, dann gerne reinschicken. Wir leiten das auch gerne an Jan weiter. Jan-Philipp Küsters: Jawoll! Michael: In diesem Sinne: Bleibt sicher und gesund. Wir sagen auf Wiedersehen. Danke. Tschüss. Jan-Philipp Küsters: Macht’s gut. Ciao.