Threat- and Vulnerability-Management (TVM) : Der Weg zum agilen TVM – und dann?

Von Marco Rottigni, Mailand (IT)

Derzeit zeigt sich leider mit beeindruckender Klarheit, wie unterschiedlich und teils wenig ausgereift nach wie vor die Fähigkeiten und Ressourcen vieler Unternehmen sind, wenn es um die rechtzeitige Reaktion auf einen Cybervorfall geht. Während manche Organisationen immer noch Utopien wie Totalprävention oder gar Totaloffensive nachjagen, haben viele CISOs bereits begonnen, Fähigkeiten rund um das Konzept der Resilienz aufzubauen (s. a. S. 22) und verlagern den Fokus von der reinen Gefahrenabwehr auf die Minimierung der Angriffsfläche. Außerdem stärken sie Fähigkeiten wie einen guten Blick auf die gesamte „digitale“ Umgebung und die bedarfsgerechte Erkennung von Bedrohungen und Schwachstellen.

Die Idee dahinter: Je kleiner die Angriffsfläche, desto präziser die Erkennung, desto geringer die Zahl signifikanter Ereignisse, die untersucht werden müssen, und desto kleiner folglich der Bedarf an teuren, hochqualifizierten und spezialisierten Mitarbeitern. Doch so einleuchtend dieses Konzept auch klingen mag, tatsächlich durchgesetzt hat es sich bislang noch nicht.

Zu viele Unternehmen betrachten die Schwachstellenanalyse immer noch als einen zyklischen Prozess, der einmal im Monat durchgeführt wird, um festzustellen, welche Vulnerabilities von den Anwendungsverantwortlichen behoben werden müssen. Der Patchzyklus wird dann vorwiegend durch Berichte vorangetrieben, die Problembehebung mehr schlecht als recht priorisiert – anhand der Perimeter, innerhalb derer sich wichtige Ressourcen befinden, anhand von CVSS-Indikatoren, dem „objektiven“ Schweregrad einer Schwachstelle und sonstigen Metriken. Dabei wird der Prozess der Schwachstellen-Analyse hauptsächlich als taktische Aktivität betrachtet. Man könnte diesen Ansatz mit dem sogenannten Wasserfallmodell linearer, aufeinanderfolgender Projektphasen vergleichen, das heute in der Softwareentwicklung weitgehend aufgegeben und durch agilere Ansätze (etwa Scrum) ersetzt wird.

Managament statt Analyse

Die Notwendigkeit für ein agiles Vorgehen hat viele CISOs dazu bewogen, von reinen Analysen zum Schwachstellen-Management überzugehen, Schwachstellen also zu verwalten und langfristig zu verfolgen: Berichte dienen dann dazu, um Mängel in den Business-As-Usual-(BAU)-Prozessen zu erkennen, die Angriffsfläche wird mithilfe dynamischer Dashboards in Echtzeit oder nahezu Echtzeit überwacht. Zu Schwachstellen wird jeweils auch Kontext geliefert, um den SecOps- oder Patchmanagement-Teams Informationen an die Hand zu geben, die ihnen die Priorisierung erleichtern.

Der Nutzen des Schwachstellenmanagements liegt dabei weniger im taktischen als mehr im operativen Bereich. Und mittlerweile veranlasst eben jene Agilität fortschrittliche CISOs dazu, das reine Schwachstellenmanagement zum Bedrohungs- und Schwachstellenmanagement (Threat- and Vulnerability-Management, TVM) weiterzuentwickeln: Dieser Prozess macht es erforderlich, agile Informationsflüsse über verschiedene Prozesse hinweg zu etablieren, bestehende Barrieren abzubauen, geschlossene Strukturen aufzulösen und Silos zu durchbrechen.

Threat- and Vulnerability-Management (TVM)

Als Basis dienen dabei grundlegende Konzepte wie die Implementierung einer transparenten und übergreifenden Orchestrierung, die Möglichkeit zu direkten Abfragen der überwachten digitalen Umgebung, die Operationalisierung von Informationen zu Cyberbedrohungen, um eine vereinfachte Abstraktionsschicht zu schaffen, und die Harmonisierung der Anforderungen verschiedener Akteure im Unternehmen, um ihnen den Zugriff auf dieselben Daten aus ihrer jeweiligen Perspektive und im benutzerfreundlichsten Format zu ermöglichen.

Im Einzelnen geht es bei der transparenten Orchestrierung darum, die von verschiedenen Systemen bereitgestellten APIs zu nutzen, um sichere Informationsflüsse zu schaffen, die Effizienz zu verbessern und menschliche Fehler zu reduzieren. So könnten beispielsweise die Resultate einer Angriffsflächenanalyse an eine Service-Management-Anwendung weitergeleitet werden, die den Anwendungsverantwortlichen informiert, die Problembehebung überwacht und, sobald die Schwachstelle als beseitigt gilt, die Schwachstellenanalyse erneut aktiviert, um zu prüfen, ob das Problem tatsächlich gelöst ist. Gegebenenfalls werden die Informationen in ein dynamisches Dashboard eingepflegt, um sie zu verfolgen und dem Management demonstrieren zu können, wie sich die Effektivität des TVM-Prozesses entwickelt.

Bei den direkten Abfragen geht es darum, „Augen“ zu haben, wo immer sie in der digitalen Umgebung sinnvoll sind – unabhängig davon, wie komplex diese auch sein mag. Diese Augen haben die Aufgabe, Informationen zu sammeln und sie an eine zentrale Stelle zu leiten, wo sie indexiert, verarbeitet, aggregiert und so zusammengestellt werden, dass sie von Menschen auf einer modernen Benutzeroberfläche und von der Technik über ein Application-Programming-Interface (API) genutzt werden können. Dies gewährleistet im Idealfall, dass die Antwort auf alle wesentlichen Fragen bereits in den indexierten Daten vorhanden ist – man kann binnen Sekunden darauf zugreifen, um Entscheidungen auf taktischer, operativer und strategischer Ebene leichter zu treffen.

Operationalisierung von Erkenntnissen zu Cyberbedrohungen bedeutet, die Informationen verwertbar zu machen, Daten in einem Feed zu verarbeiten und so eine Abstraktionsebene zu schaffen, die man sofort für komplexe Fragen nutzen kann. Wenn eine Bedrohung oder neue Angriffstechnik auftritt, lässt sich dank dieser Abstraktion beispielsweise sofort feststellen, wie viele Assets in der eigenen IT-Landschaft betroffen sind. Dabei können diese Daten wahlweise zu taktischen Zwecken (d. h. die Asset-Liste samt Details einsehen) oder zu operativen Zwecken dargestellt werden – dann mit vertieften Informationen zu Bedrohungen, die helfen können, die Abwehr und Resilienz zu stärken.

Die Harmonisierung der Anforderungen verschiedener Akteure zielt darauf ab, die bereits erwähnten Fähigkeiten zur einheitlichen Datenverarbeitung zu nutzen, um jeder Zielgruppe nur denjenigen Teil der vorliegenden Daten bereitzustellen, den sie benötigt. Bei einem Server könnte etwa die IT-Abteilung über die installierte Software, die Hardware, fehlende Patches, Geolokalisierung et cetera Bescheid wissen wollen – Sicherheitsteams könnten hingegen an Bedrohungsindikatoren, Software Anfälligkeiten und Anomalien interessiert sein. Und die Compliance-Verantwortlichen könnten daran interessiert sein, ob der Server bestimmte Controls einhält, die das Framework für den Perimeter definiert, in dem sich der Server befindet.

Wenn Unternehmen die beschriebenen Fähigkeiten richtig implementieren, entstehen reibungslose Informationsflüsse, die von Menschen, Prozessen und Technik getragen werden. Sie heben das TVM auf eine strategische Ebene – gleichzeitig bleiben die operativen Vorteile des Schwachstellenmanagements und der taktische Nutzen einer präzisen Schwachstellenanalyse erhalten.

Bei der Betrachtung des eigenen Hauses sollte man sich nun verschiedene Fragen stellen: Wie würde man vor dem hier skizzierten Hintergrund den eigenen Reifegrad einschätzen? Können Prozesse als TVM bezeichnet werden? Wird das Schwachstellenmanagement aktuell weiterentwickelt oder befindet man sich immer noch auf dem Level der Schwachstellenanalysen und schlägt sich nach dem Wasserfallmodell durch?

Wie weiter?

Hat eine Organisation das TVM-Level bereits erreicht, wird es zudem Zeit, Verschiebungen vorzunehmen: Left-Shift, Right-Shift, Up-Shift und Down-Shift!

Ein Left-Shift ist als Verschiebung nach „links“, hin zur Software-Development-Life-Cycle-(SDLC)- und CI/CD-Pipeline, anzusehen: Der Reifegrad muss hier hoch genug sein, um den Sicherheitsprozess dorthin zu erweitern, wo die Angriffsflächen ihren Ursprung haben. Höchstwahrscheinlich werden in solchen Umgebungen bereits agile Methoden eingesetzt, um mit Entwicklerteams, die Scrum-Prinzipien auf hocheffiziente Weise anwenden, die Sprints zu durchlaufen. Ein Beispiel: In den verwendeten SDLC-Tools (wie Jenkins oder Bamboo) lösen API-basierte Plug-ins jedes Mal dynamische Tests aus, wenn Code in die Vorproduktion geht.

Eine Verschiebung nach „rechts“ im Lebensablauf von Software (Right-Shift) dient der Unterstützung des Patchmanagements: Herrscht bereits Klarheit darüber, was TVM bedeutet, und hat man Wissen über den notwendigen Kontext mit unterschiedlichen Abstraktionsebenen, ist es eine gute Idee, dieses Wissen zu erweitern und Workflows aufzubauen, welche die Problembehebung bestmöglich operationalisieren. Auf diese Weise lässt sich die Effektivität und Effizienz steigern und gleichzeitig kann man Key-Performance-Indicators (KPIs) wie die „Mean Time to Repair“ (MTTR) minimieren. Das Einspielen von Patches sollte unter Berücksichtigung von Anpassungen geplant werden, die ersetzt wurden oder veraltet sind. Die Anwendung der Patches, ihre Ergebnisse und KPIs sollten Management und Wissen Threat- and Vulnerability-Management (TVM) verfolgt und der Neustart nach einer Patch-Installation, der immer noch einer der unwägbarsten Aspekte dieses Prozesses ist, sollte überwacht werden.

Ein Up-Shift kann hin zu Cloud-Umgebungen und Containern wirken: Die Reife des TVMs muss hierzu durch die Verbesserung der Sichtbarkeit erweitert werden, wo sich die Perimeter auflösen. So kann man Beziehungen zwischen Ressourcen in Multicloud-Umgebungen bewerten und Fehlkonfigurationen aufspüren. Merkwürdigerweise zählen Fehlkonfigurationen zu den Hauptursachen für die Entstehung von Datenlecks bei Cloud-Initiativen – in Publikationen wie „The Treacherous Twelve“ wird das gut beschrieben (siehe https://downloads.cloudsecurityalliance.org/assets/research/top-threats/Treacherous-12_Cloud-Computing_Top-Threats.pdf).

Zudem sind die Herausforderungen von Containerisierungs-Initiativen zu bewältigen, welche die gesamte Vorstellung von IT radikal verändern: mit extremen Konzepten wie Serverless Computing, Container-as-a-Service- (CaaS)-Plattformen und föderierter Orchestrierung zur Ressourcenoptimierung. Diese jüngste Evolution der IT-Umgebung macht es erforderlich, Funktionen zur Erfassung von Daten stark zu spezialisieren, um klassischen organisatorischen Anforderungen (etwa der Compliance) gerecht zu werden. Das ist nicht nur eine technische Herausforderung, sondern sollte auch bei der Anbieterauswahl berücksichtigt werden: Anbieter, die den zugrunde liegenden Workflow verstehen, sollte man bevorzugen.

Und last, but not least gibt es den Down-Shift hin zum IT-Asset-Management: Dieser Prozess ist in vielen Unternehmen – mehr oder weniger effizient – schon etabliert. Er muss jedoch modernisiert werden, um die benötigte „Single Source of Truth“ für sämtliche Assets zu schaffen – und das in einer digitalen Umgebung, die sich ständig verändert und im Lauf der Zeit skaliert. Wichtige Kriterien sind hier Erkennung, Normalisierung, Strukturierung und Klassifizierung – ein Zyklus, der so automatisiert und kontinuierlich wie nur möglich ablaufen sollte. Zugleich sollte er mit Configuration-Management-Database-(CMDB)-Systemen synchronisiert werden, um einen konsistenten IT-Asset-Management-(ITAM)-Prozess zu gewährleisten, unabhängig davon, wer die Erkennung durchführt.

Da heute kein Prozess mehr isoliert und ausschließlich taktisch orientiert sein kann, sollte diese „Single Source of Truth“ zum Bezugspunkt für BAU, SecOps, DevOps und andere Prozesse werden. Oder um es auf einen Nenner zu bringen: Es ist ein schwieriger Weg … manche nennen ihn digitale Transformation.

Marco Rottigni ist Chief Technology Security Officer (CTSO) EMEA bei Qualys.