Mit <kes>+ lesen

Ganzheitliches Schwachstellen-Management

Schwachstellenmanagement darf nicht erst bei der Wartung von IT-Systemen anfangen – bestimmte Prinzipien sollte man bereits bei der Beschaffung von Software und Hardware beachten und zudem eine Mentalität etablieren, die Schwachstellen vermeiden hilft und an ihren Ursachen ansetzt. Dieser Beitrag beschreibt einen Lösungsweg für ein leistungsfähiges prozessorientiertes Schwachstellenmanagement – aber auch dessen Grenzen.

Security-Management
Lesezeit 18 Min.

Von Bastian Angerstein, Besigheim

Der hier vorgestellte Prozess zum Schwachstellenmanagement hat die Reduktion Schwachstellen-induzierter Risiken sowie die Vermeidung unnötiger Risiken zum Ziel. Erreicht wird das entlang von vier Phasen durch kontinuierlichen Erkenntnisgewinn, Analyse, Prüfung, Begegnung und Weiterentwicklung der betriebsgeführten IT-Landschaft und anhängiger Prozesse – ein besonderes Augenmerk liegt dabei auf der kontinuierlichen Verbesserung.

Erkenntnisgewinn

Ein umfassender und zielgerichteter Erkenntnisgewinn ist entscheidend für die qualitative Zielerreichung des gesamten Prozesses. Neben den Grundvoraussetzungen eines jeden Prozesses – wie Definition von Verantwortlichkeiten, Dokumentation von Aufgaben, Protokollierung von Arbeitsergebnissen sowie Definition sinnhafter Metriken – gilt es hier, Quellen und Mittel zu definieren, die Erkenntnisse zu Schwachstellen liefern. Dabei hat sich eine gewisse Redundanz im Sinne inhaltlicher Überschneidungen der Quellen in der Praxis als dringend empfehlenswert erwiesen – Stand heute ist keine Quelle verfügbar, die alleine die volle Bandbreite an Schwachstellen in IT-Komponenten abdecken würde.

Allgemeine Quellen

Typische Quellen, die Beachtung finden sollten, sind öffentliche und/oder kommerzielle Schwachstellendatenbanken, Kanäle von Herstellern und Zulieferern (z. B. über die Produktunterstützung), Informationen von Anbietern sowie die einschlägige Presse.

Um alle relevanten Quellen zu identifizieren, ist es zwingend notwendig, eine vollumfängliche Liste von Zulieferern, Anbietern und Produkten (Hard- und Software) vorliegen zu haben. Ohne eine solche Informationsbasis ist ein effektives Schwachstellenmanagement faktisch unmöglich umzusetzen. Normen der Informationssicherheit und im Bereich des Lizenzmanagements fordern ebenfalls derartige Stücklisten (Bill of Material, BOM) oder Softwareverzeichnisse (Software Bill of Material, SBOM) – diese Informationen sollten also bereits verfügbar oder kurzfristig zu erheben sein. Weitere Stellen, die man dabei hinzuziehen kann, sind etwa Asset- und Vertrags-Management, Bestellwesen und interne Dokumentation. Gern übersehen werden dabei Treibersuiten, BIOS/UEFI und sonstige Firmware, aber auch Hardware-Komponenten an sich.

Schwachstellen-Definition

Eine Schwachstelle ist eine bekannte oder unbekannte Eigenschaft von Hardware oder Software, die es ermöglicht, eine bei der Entwicklung oder dem Einsatz der Komponente möglicherweise nicht vorhergesehene, nicht erwartete oder auch in ihrer Kritikalität unterschätzte Aktion durchzuführen. Schwächen können im Ablauf, der Konfiguration, der Logik, der Koordination, der Übertragung, der zeitlichen Koordinierung, der Datenevaluierung, der Validierung, der Zustandsbewertung, der Bewertung von Verlässlichkeit und Vertrauenswürdigkeit etc. entstehen. Bei aller Vielfalt haben sie doch eines gemeinsam: Alle stellen potenzielle Risiken dar.

Spezifische Quellen

Prüfungen, Sicherheitsanalysen und Penetrationstests stellen weitere Erkenntnisquellen dar. Diese Maßnahmen sollten in angemessener Häufigkeit und Umfang umgesetzt werden, auch wenn sie in vielen Fällen mit zusätzlichen Kosten und/oder erheblichem Aufwand verbunden sind.

Prüfungen können beispielsweise Maßnahmen wie statische und dynamische Quellcodeanalyse umfassen, die Analyse von Abhängigkeiten oder eine automatisierte Analyse ganzer Softwarearchive, laufender Systeme und Rechenzentren per Schwachstellenscanner.

Sicherheitsanalysen, etwa die Bedrohungs- und Risikoanalyse, unterstützen bei der Erkennung möglicher Angriffspfade und der Identifizierung besonders kritischer Bestandteile, Daten und Funktionen, die bei der Bewertung der Kritikalität von Schwachstellen eine wertvolle Informationsbasis bilden können. Hier sind diverse, teilweise standardisierte Methoden verfügbar, die sich von der Fehlermöglichkeits- und Einflussanalyse (Failure Mode and Effects Analysis, FMEA) ableiten.

Zusätzlich sollte man Benutzerrückmeldungen zu Produktfehlern und Schwächen berücksichtigen. Daher stellen auch das Vorfalls- und Sicherheitsvorfalls-Management wichtige Quellen dar. Diese sollten im kontinuierlichen Verbesserungsprozess (KVP – engl.: Continual Improvement Process, CIP) als „Lessons Learned“ Beachtung finden. Bei einer technikaffinen oder ausreichend diversen Benutzerbasis sind Ansätze wie Bugbounty-Programme und die Gamifizierung der Schwachstellenidentifikation ebenfalls betrachtenswerte Optionen.

Bei der Beschaffung sollte man bereits ein Augenmerk auf das Vorliegen prompter und umfassender Nutzerinformation durch den Hersteller oder Anbieter legen. Idealerweise ist zu ergründen, welche Maßnahmen der Anbieter selbst zur frühzeitigen Erkennung und Behandlung von Schwachstellen getroffen hat und wie Informationen an die Nutzerbasis erfolgen.

Nutzung der Informationskanäle

Nach der Auswahl der Quellen sind die Kommunikationskanäle einzurichten: Hier ist ein Push-Verfahren grundsätzlich einem Pull-Verfahren vorzuziehen, da Informationen so in kürzester Zeit vorliegen. In der Praxis wird sich allerdings oft aufgrund der Vielfältigkeit der Quellen eine Mischung nicht vermeiden lassen. Wo Pull-Verfahren unumgänglich sind, sollte man die Bedienung des Informationskanals prozessual definieren und Verantwortlichkeiten verankern, um eine angemessene Bedienung sicherzustellen.

Man kann auch über eine Automation der Informationsbeschaffung nachdenken: Einige namhafte Schwachstellendatenbanken bieten mehr oder minder umfangreiche programmatische Schnittstellen (API) zu diesem Zweck an, mit denen jedoch teilweise weitere Kosten verbunden sind (etwa für „Credits“ oder Abonnements).

Die Regelmäßigkeit der Durchführung von Maßnahmen zum Erkenntnisgewinn hängt stark von Art, Umfang und Kritikalität der verwalteten IT ab. Im Normalfall sollte bei einem angestrebten mittleren Sicherheitsniveau eine werktäglich garantierte Erfassung ein hinreichendes Maß an Aktualität gewährleisten.

Das Ergebnis der Phase „Erkenntnisgewinn“ ist die Meldungsaufnahme, beispielsweise über Ticketing-Systeme, und damit die Überführung in die interne Verwaltung.

Triage & Analyse

Das Volumen entstehender Meldungen steuerbar zu halten und zu kanalisieren ist Aufgabe der Triage. Ein Kriterium ist dabei auch die Verlässlichkeit der Erkenntnisse, die aus den Erfahrungen der Organisation heraus ermittelt werden muss: Kommerzielle Schwachstellendatenbanken stellen meist qualitativ hochwertige Quellen dar – Erkenntnisse aus Benutzerrückmeldungen, Schwachstellenscanner, Qualitäts- und Sicherheitsüberprüfungen weisen demgegenüber gegebenenfalls eine geringe Qualität auf.

Die Kritikalität einer Schwachstelle hängt von einer Vielzahl an Faktoren ab, beispielsweise mögliche Angriffsvektoren, Angriffskomplexität und notwendige Voraussetzungen (z. B. die Art des benötigten Zugriffs: unprivilegiert/privilegiert, lokal/remote). Ein wesentlicher Faktor ist jedoch immer: Mit der Veröffentlichung der Schwachstelleninformation steigt das durch selbige induzierte Risiko sprunghaft und stark an – vor allem wenn die Publikation unkoordiniert oder in unverantwortlicher Weise geschieht, sehr detailliert erfolgt oder hohe Aufmerksamkeit erzielt.

Bei der initialen Analyse und Triage ist es das Ziel, die Kritikalität einer Schwachstelle auf betriebsgeführten Komponenten nach bestem Wissen und Gewissen und im standardisierten Verfahren zeitnah zu bewerten – beispielsweise auf dem Base-Score des Common-Vulnerability-Scoring-System (CVSS, siehe etwa www.first.org/cvss/) oder ähnlichen Systemen, die möglicherweise von Zulieferern eingesetzt werden, um Maßnahmen wohlkoordiniert umsetzen zu können. Setzen Zulieferer proprietäre Systeme zur Schwachstellenbewertung ein, sollte über eine Normalisierung der Daten nachgedacht werden, um eine einheitliche Bewertung zu erlangen, die das Risiko einer Fehleinschätzung größtmöglich reduziert. Im einfachsten Fall ist dies über ein Mapping der Kategorien möglich. Vor einer Umsetzung sollten jedoch Ursprungs- und Zielbewertungssystem analysiert sein, da es durchaus erhebliche Abweichungen geben kann.

Letztlich wird in dieser Phase entschieden, mit welcher Dringlichkeit weitere Maßnahmen im Rahmen von Prüfung, Evaluation und Begegnung umzusetzen sind. Die in der Triage und Analyse erhobenen Informationen sind dazu mit den Schwachstelleninformationen zu verknüpfen – beispielsweise indem man ein Master-Ticket um die in diesem Prozessschritt gewonnenen Informationen anreichert.

Prüfung & Evaluation

In der Evaluationsphase wird basierend auf vorliegenden Informationen zur Schwachstelle sowie Daten aus dem Asset- und Lizenzmanagement sowie der Softwareverwaltung eine Erhebung möglicherweise betroffener Komponenten durchgeführt. Auf Inventardaten basierende Auswertungen nennt man „kalte Analyse“ (Cold Scan).

Zusätzlich sollten umgebungsbezogene Faktoren zu der verantworteten IT vorgehalten werden. Wesentlich sind dabei etwa die direkte Exposition von Komponenten gegenüber internen und externen Zugriffen, die Kritikalität der betroffenen Funktionen für den Geschäftsprozess, die Sensibilität von Daten sowie gegebenenfalls Gefahren für Leib und Leben.

In der Praxis zeigt sich, dass oftmals ein Kontakt zu Anbietern oder Zulieferern notwendig ist, um Informationen zu konkretisieren oder zu komplettieren. Solange diese Kommunikation nicht abgeschlossen ist, sollte immer das Maximalprinzip des Risikomanagements Anwendung finden. Das bedeutet, immer anzunehmen, dass ein System durch eine Schwachstelle gefährdet ist und mindestens der im CVE-Advisory angegebene CVSS-Wert zugrunde gelegt werden sollte.

Ausschlaggebend für eine umgebungsbezogene Wertung ist vor allem die Kritikalität der bedrohten Daten (Sensibilität, Toxizität, Volumen). Ein Malus/Bonus-System, das auf den Basiswert von nach CVSS (3.1) bewerteten Schwachstellen aufsetzt, bietet sich als einfach umzusetzende Lösung an und ist auch bereits Bestandteil des Scoring-Systems. Nach einem solchen Schema wären beispielsweise hochkritische Systeme mit hohem Expositionsgrad in der Behandlung zu priorisieren.

Eine Alternative zu CVSS stellt die interne Kategorisierung von Schwachstellenerkenntnissen dar, wobei man eine Überspezifizierung vermeiden sollte: In der Regel sind 3–5 Kategorien hinreichend, für die man jeweils Prioritäten, Bearbeitungszeiträume und auch Kommunikationspläne definiert: beispielsweise einen Teilprozess für niedrig und gering priorisierte Schwachstellen mit einem CVSS unter 3 ohne Nutzer- und Managementinformation, einen Teilprozess für Schwachstellen mittlerer Priorität (CVSS 3–7) mit Hinweisen an Nutzer- und Management sowie einen Teilprozess für schwere und hochkritische Schwachstellen (ab CVSS 7) mit erweitertem Kommunikationsplan und begleitenden Maßnahmen (z. B. intensivierte Nachverfolgung).

Zudem fallen in diese Phase erweiterte technische Prüfungen, die beispielsweise Angriffe auf die zu behandelnde Schwachstelle testen oder simulieren – sogenannte „heiße Analysen“ (Hot Scan). Das hieraus gewonnene Wissen unterstützt bei Bewertung und Verständnis der durch die Schwachstelle eingebrachten Risiken und kann für die Planung begegnender Maßnahmen sehr hilfreich sein. Dabei unterstützen Informationen wie ein Proof of Concept (PoC) und Exploit-Codes, die immer häufiger Teil veröffentlichter Schwachstellenanalysen sind, sowie Schwachstellenscanner, aber auch andere einschlägige Werkzeuge. Letzten Endes dient diese Phase auch dazu, eine Angreifbarkeit gegenüber der spezifischen Schwachstelle umgebungsbezogen zu verifizieren.

Für Schwachstellen, die im Responsible-Coordinated-Disclosure-(RCD)-Verfahren veröffentlicht werden, liegen häufig bereits bei Veröffentlichung aktualisierte Softwarepakete bereit – teils implementieren Anbieter oder Hersteller Anpassungen stillschweigend schon zuvor. Wurde oder wird die aktualisierte Software im Regelverfahren ausgerollt, sind möglicherweise keine weiteren Maßnahmen zur Begegnung notwendig.

Auch die in diesem Arbeitsschritt erhobenen Informationen sind mit den bereits zuvor erlangten Informationen zu verknüpfen. Schwachstelleninformationen sind nun validiert, ihre Kritikalität ist transparent, Zuständigkeiten und Verantwortlichkeiten wurden identifiziert und unterstützende Informationen zur Schwachstelle und Begegnung erhoben – somit kann anschließend die Aufforderung zur Begegnung der Schwachstelle an die jeweiligen Verantwortlichen ergehen.

Begegnung & Validierung

Für die Begegnung von Schwachstellen stehen grundsätzlich drei strategische Optionen zur Verfügung, die aus dem Risikomanagement adaptiert wurden:

  • Akzeptanz: Diese Option bietet sich dort an, wo die Kosten-Nutzen-Analyse dies indiziert, geringe Auswirkungen auf das Betriebsrisiko identifiziert wurden (z. B. durch eine anstehende Aktualisierung, eine sehr geringe Eintrittswahrscheinlichkeit oder zu vernachlässigende Auswirkungen), bereits hinreichende abmildernde Maßnahmen oder Maßnahmen zur Vermeidung Umsetzung finden, die im spezifischen Fall greifen. Über die Akzeptanz einer Schwachstelle wird nicht auf der technischen Ebene entschieden: Dies muss, zumindest ab einem (idealweise im Risikomanagement) definierten Schwellwert, eine Stelle in der Organisation entscheiden, die das mit der Schwachstelle und dem IT-Betrieb verbundene Risiko tragen kann. Ansonsten besteht die Gefahr, dass Risiken unbekannt und somit auch organisatorisch unbehandelt bleiben. In der Praxis zeigt sich, dass der organisatorische Aufwand hierfür oft höher ist als die Behandlung der Schwachstelle im Regelprozess der IT-Pflege!
  • Abmildernde Maßnahmen (Mitigation): Dabei bleibt die Schwachstelle ebenfalls im System vorhanden, aber eine Ausnutzung wird erschwert oder deren Auswirkungen verringert. In der Praxis ist dies eventuell notwendig, wenn beispielsweise keine Aktualisierungen verfügbar sind oder sich deren Implementierung verzögert. Mitigationsmaßnahmen sind häufig Workarounds, beispielsweise in Form temporärer Einschränkungen: Dabei werden betroffene Funktionen einer Soft- oder Hardware außer Kraft gesetzt oder zusätzliche Sicherungsschichten etabliert (z. B. Zugriffskontrolle, Prozessüberwachung, Ausführungsbeschränkungen). Die Umsetzung dieser Maßnahmen erfolgt über das Change-Management. Selbstverständlich sollten die getroffenen Maßnahmen in Relation zur Schwachstelle stehen und zum Zweck der Nachverfolgbarkeit dokumentiert werden.
  • Vermeidung: Diese Option ist in aller Regel anzustreben. Das Risiko einer spezifischen Schwachstelle wird vermieden, indem man beispielsweise eine anfällige Komponente außer Betrieb nimmt oder durch eine andere Komponente (z. B. Softwareversion) ersetzt, die (mutmaßlich) nicht anfällig ist. Die Umsetzung dieser Maßnahmen erfolgt ebenfalls über das Change-Management.

In der Praxis ist häufig eine Verkettung von abmildernden Maßnahmen und Vermeidung zu beobachten. Dabei sind gängige Mittel der Mitigation entweder bereits Bestandteil der Systemlandschaft oder diese werden als schwachstellenspezifische Ad-hoc-Maßnahmen umgesetzt. Generische abmildernde Maßnahmen sind vielfältig: beispielsweise in Form von Zugangs-, Zugriffs-, Ausführungs- oder Funktionsbeschränkungen, Isolation oder sicherheitsspezifischer Überwachung.

Die Umsetzung von Mitigationsmaßnahmen und Maßnahmen der Vermeidung sollte in einer Art und Weise erfolgen, die dem Risiko der zu behandelnden Schwachstelle angemessenen ist – allem voran müssen Maßnahmen mit hinreichender Priorität und angemessenen Mitteln erfolgen. Hierzu sollte eine Ausspezifikation des Prozesses auf Basis der Bewertung/Kategorisierung bereits prinzipiell umgesetzt sein. Zudem gilt es, permanent Ressourcen vorzuhalten, um Reaktionsfähigkeit zu gewährleisten.

Nicht zuletzt sollte man prozessual sicherstellen, dass Risiken durch Schwachstellen Eingang in andere Managementprozesse finden, um Transparenz zu erzielen und Nachhaltigkeit zu gewährleisten – zumindest für Risiken/Schwachstellen, die nicht zeitnah und/oder umfänglich vermieden werden können. Im Risikomanagement sind hierbei die (Rest-)Risiken zu bewerten beziehungsweise dorthin zu überführen. Auch hier muss, wie im Fall der Akzeptanz, das Risiko dem jeweiligen Träger bekanntgemacht und von ihm akzeptiert werden – für schwerwiegende Fälle sollte ein rechtssicheres Verfahren zur Risikoübernahme vorliegen (z. B. Gegenzeichnung).

Erfolgskontrolle

Teil der Schwachstellenbegegnung sollte die Validierung sowohl der gewählten Strategie als auch deren Umsetzung sein: Ist die gewählte Strategie dem Risiko angemessen? Folgt sie der Unternehmensstrategie? Ist das Restrisiko tragbar? Sind angemessene Mittel und Prioritäten vorhanden? Hat die umgesetzte Maßnahme ihr Ziel erreicht? Ist also beispielsweise eine technische Schwachstelle beseitigt oder ihre Ausnutzung ausreichend erschwert worden?

Hierzu stellen (bei weniger kritischer IT oder Schwachstelle) stichprobenbasierte Verfahren, automatisierte Prüfungen auf Basis des Datenbestands der eingesetzten Hard- und Software (Cold Scans) oder automatisierte Tests auf Basis von Schwachstellenscannern (Hot Scans) akzeptable Lösungsansätze dar. Dabei ist allerdings anzumerken, dass die Fehlerrate von Hot Scans gegenüber einer Prüfung auf aktuellen und zuverlässigen Inventardaten in der Regel höher ausfällt – außerdem können Hot Scans produktive Systeme beeinträchtigen.

Für hoch-kritisch klassifizierte Komponenten, Systeme und Anwendungen bestehen gegebenenfalls spezielle Anforderungen an Umsetzungsplanung, Umsetzung, Benutzerinformation und Änderungsdokumentation sowie Qualitätssicherung (standardisierte Abnahmeverfahren) – teils gibt es spezifische regulative Anforderungen, die Beachtung finden müssen und die Umsetzungszeit beeinflussen können.

Kontinuierliche Verbesserung

Üblicherweise zeigt sich während der Nutzung eines Prozesses Optimierungspotenzial – egal ob technischer oder organisatorischer Natur. Die Möglichkeit der Weiterentwicklung und kontinuierlichen Verbesserung sollte daher im Rahmen des Prozesses institutionalisiert werden. Bereits bei der Planung ist davon auszugehen, dass der Schwachstellenmanagementprozess sehr intensiv genutzt wird – Einfachheit und Geschwindigkeit sollten deshalb eine hohe Priorität genießen. Ressourcen und Mittel für die Optimierung sollte man schon mit der Einführung einplanen. Eine Messbarkeit stellt die Basis für die Steuerbarkeit dar – sie lässt sich durch die Etablierung prozessspezifischer Metriken erzielen (Beispiele siehe Tab. 1). Die Optimierung des Prozesses sowie der Prozessmittel basiert neben Erkenntnissen aus den Metriken zudem auf Benutzerrückmeldungen und der Prozessfehlererkennung.

In der Praxis erweisen sich die Etablierung technischer Hilfsmittel und Schnittstellen sowie die Ressourcenplanung oft als herausfordernd: Technische Hilfsmittel von Schwachstellendatenbanken bis hin zu Analyse und Detektionswerkzeugen sind möglicherweise komplex in der Einführung und Integration. Der Zugriff auf Schnittstellen wie Asset-, Inventar-, Lizenz/Softwareverwaltung-, Risiko- und Problemmanagement kann aufwendig sein und durch organisatorische Silos erschwert werden.

Man sollte großen Wert darauf legen, den Reifegrad des Prozesses gezielt voranzutreiben. Schon in einer verhältnismäßig kleinen homogenen IT-Landschaft ist davon auszugehen, dass täglich mehrere neue Erkenntnisse zu Schwachstellen zu bearbeiten sind. Daher ist eine Optimierung in jedem Fall auch ein wirtschaftlich lohnendes Unterfangen.

Tabelle 1: Beispiele prozessspezifischer Metriken

Tabelle 1: Beispiele prozessspezifischer Metriken

Meldungsvolumen – gesamt

Summe davon aufgenommener Meldungen

Summe der Meldungen nach Bearbeitungsstatus

Bearbeitungsdauer (Arbeitsleistung)

Bearbeitungszeit (Bearbeitungszeitraum in/out)

Summe der bearbeiteten Meldungen pro Organisationseinheit

Meldungsvolumen nach Kritikalität

Meldungsvolumen nach Standardmaßnahmentyp (Akzeptanz, Mitigation, Vermeidung)

Volumen der Maßnahmen in Ausnahmeprozessen (z. B. verzögerte Bearbeitung, fehlende Updates)

Daten zur Informationsqualität (z. B. fehlerhafte Information, verzögerte Meldung, ungenügende Information)

Summe der Meldungen nach Produkt/Hersteller/Anbieter

Progressive Risiko-Entwicklung (nach Organisationseinheit)

Progressive Risiko-Entwicklung (nach Organisationseinheit)

Summe identifizierter Fehler (Rekursionen, Nicht-Bearbeitung, Identifikationsfehler etc.)

Volumen der Wirkbreite (Anzahl durch einen Fehler betroffener Systeme)

Volumen von Meldungen mit überschrittener Regel/Soll-Bearbeitungszeit

Volumen nicht zugewiesener Meldungen

Volumen erkannter fehlender oder fehlerhafter Prozessinformation (fehlende/falsche Inventardaten, nicht gelistete Softwarekomponenten, fehlende Verantwortlichkeiten etc.)

Herausforderungen und Grenzen

Ohne ein gutes und umfassendes Sicherheits- und Qualitätsbewusstsein in der Organisation in Bezug auf IT und IT-Dienste ist die Umsetzung all dieser Maßnahmen schwierig, da Kosten und Arbeitsaufwand dann auf Unverständnis stoßen können – mangelnde Akzeptanz und verzögerte Umsetzung sind die Konsequenz. Eine Institutionalisierung des Schwachstellenmanagements über klare Vorgaben und Regeln sowie das Erzeugen von Verständnis und Akzeptanz durch Maßnahmen zur Steigerung des Sicherheitsbewusstseins können helfen. Wichtig für die Akzeptanz ist dabei, die Wirkung der Maßnahmen aufzuzeigen – beispielsweise über Berichte zur Reduktion des Betriebsrisikos.

Das Thema Schwachstellenmanagement wird dort komplex, wo es um die Abschätzung von Risiken durch die Verkettung von Schwachstellen, technischen Schulden, prozessualen Schwächen, bekannten Fehlern, aber auch legitimen Funktionen geht. In der Regel ist dies nur mit umfänglichem komponentenbezogenem Fachwissen und damit kaum zentralisiert umsetzbar – eine enge Zusammenarbeit auf der technischen Ebene stellt hier ein ausgezeichnetes Mittel zum beidseitigen Knowledge-Transfer dar. Risiken durch derart komplexe Szenarien sind aber auch regelmäßig durch andere Maßnahmen zu identifizieren – beispielsweise Penetrationstests und Sicherheitsanalysen (z. B. „Attacktree“ und Threat-Modeling).

Auch die schiere Masse ist problematisch: 2021 wurden etwa 20.000 Schwachstellen gemeldet, bei jährlich rund 200 Arbeitstagen pro Person entspräche das 100 Schwachstellen pro Arbeitstag – anders ausgedrückt: bei 15 Minuten Zeit für die Meldungsaufnahme mindestens drei Vollzeitstellen nur für die Erfassung.

Bei diesem Volumen wird offensichtlich, dass ein effektives Schwachstellenmanagement ohne hilfreiche technische und organisatorische Mittel sehr schwierig ist und es hochoptimierte Prozesse und technische Automation bedarf, um dieses Volumen beherrschbar zu machen. Die Überführung der Behandlung in andere Standardprozesse (Problem-, Patch-, Change-, Risikomanagement etc.) ist zwingend erforderlich, um nicht in Backlog und technischen Schulden zu ersticken und eine Fokussierung auf das Kernthema (Informationsbeschaffung, Bewertung, Verbreitung, Validierung) des Prozesses zu bewahren.

Außerdem werden Erkenntnisse zu anfälligen Konfigurationen – im Sinne von Softwareeinstellungen – gegebenenfalls nicht durch das Schwachstellenmanagement und seine Regelmaßnahmen zum Erkenntnisgewinn abgedeckt, da diese (durchaus auch schwerwiegenden) Probleme in aller Regel nicht im Betrachtungsraum von CVE-Advisories liegen. Neben Maßnahmen wie Sicherheitsanalysen, Penetrationstests, Reviews und der Aufnahme von Benutzerfeedback sei hier vor allem auf eine Standardisierung von Konfigurationen („Principle of Fail-Safe Defaults“), Systemaudits, (automatisierte) System- und Compliance-Scanner sowie (mit Einschränkungen) auch Schwachstellenscanner verwiesen.

Proprietäre Produkte oder „Nicht-ganz“-Open-Source-Software stellen ebenfalls eine besondere Herausforderung dar: Selbst Anbieter, die sich Open Source auf die Fahne schreiben, hadern in der Praxis damit, offenzulegen, aus welchen Komponenten zugelieferte Hard- und Software besteht. Das betrifft besonders paketierte Hard- und Software in jeder Form, inklusive Appliances und Container-Images. Hier kann es auch bei schwerwiegenden Schwachstellen Wochen oder Monate dauern, bis Informationen oder Patches/Updates aus zugrunde liegenden Distributionen verfügbar und integriert werden – wenn das überhaupt geschieht. Der Umgang mit solchen Komponenten gestaltet sich schwierig – automatisierte Analysen mittels Schwachstellenscanner, dedizierte Tests (PoC/Exploit) oder manuelles „Reverse Engineering“ skalieren in der Praxis eher schlecht. Eine Offenlegung von Komponenten mittels BOM/SBOM (vgl. „Executive Order 14028“ des US-Präsidenten vom 12. Mai 2021) ermöglicht zumindest in Teilen eine Identifikation auf Basis von Komponentenlisten.

Besonders problematisch ist auch das allgemeine „Release-Chaos“: Paket-, Softwareversionen, Distributor-Paketierung, Hotfixes, Backports und Regressionen im Verbund mit unzureichenden Changelogs und vielfach anzutreffenden ungekennzeichneten Änderungen machen es oft sehr schwer, ohne technische Verifikation die (Nicht-)Betroffenheit einer Komponente mit hoher Zuverlässigkeit festzustellen. In solchen Fällen sollte man zumindest initial immer von einer Betroffenheit ausgehen. Eine Verifikation ist allerdings oft sehr aufwendig und deshalb in der Regel nur bei schweren und kritischen Schwachstellen sinnvoll.

Nicht-gewartete Software (z. B. Legacy Software und freie Software ohne Maintainer-Basis) sowie Eigenentwicklungen bringen Beschränkungen bei Maßnahmen des regelmäßigen Erkenntnisgewinns mit sich: Externe Informationen zu diesen Komponenten werden meist nur sehr eingeschränkt verfügbar sein (z. B. für Abhängigkeiten). Umso wichtiger ist es hier, alternative Maßnahmen im Entwicklungszyklus zu etablieren: angefangen bei konkreten Entwicklungs-Regelwerken über Qualifikationsmaßnahmen sowie statische und dynamische Code-Analysen bis hin zu Code-Reviews und regelmäßigen Prüfungen (Softwarequalität und Sicherheit).

Vermeidung & Reduktion

Die Mentalität der Organisation in Hinblick auf die Entwicklung, Beschaffung und Betriebsführung spielt eine zentrale Rolle im Themenkomplex „Umgang mit Schwachstellen“. Wie setzt die Organisation Änderungen an der Hardware und Softwarebasis um? Wie aktuell sind IT-Umgebungen und wie ist der Umgang mit Legacy-IT?

Ein etabliertes Mindset, das zur zeitnahen und umfassenden Adaption von Änderungen durch den gesamten Stack – vom Smartphone über Bibliotheken bis zur Server-Applikation – führt, wird in der Praxis viel Aufwand sparen, der ansonsten für die Verwaltung von Schwachstellen anfiele, weil neueste und beste Komponenten ja bereits im Einsatz sind. Kontinuierliche Integration, Softwarewartung, automatische Build-, Test- und Deployment-Prozesse, kurze Releasezyklen/Sprints, kurz gesagt alles, was dazu beiträgt, Komponenten so aktuell wie möglich zu halten, eliminiert automatisch und in ganz erheblichem Umfang auch Schwachstellen und hält die Angriffsfläche so klein wie möglich.

Auch die Diversitätsstreuung in der eingesetzten Soft- und Hardware spielt eine wesentliche Rolle, wenn es darum geht, das Volumen an Schwachstellen und damit die Angriffsfläche beherrschbar zu halten. Das fängt bei Hardwarestack sowie Infrastrukturkomponenten an und geht über Betriebssysteme, Server-Dienste und Middleware bis hin zu Abhängigkeiten, Applikationssoftware und Plug-ins. Vereinheitlichung sowohl bei zugekaufter als auch selbst-entwickelter Software, die darauf zielt, neben Aktualität auch das Volumen der Produkte und der Codebasis so weit wie möglich zu verringern, reduziert nicht nur den Aufwand in der Schwachstellenverwaltung: Minimale Basis- und Funktionssets reduzieren automatisch auch die Verletzlichkeit.

Moderne Werkzeuge zur Software-Entwicklung und -Verwaltung sowie stetige Weiterbildung der Mitarbeiter und die Umsetzung von „Security in Depth“ bedeuten zwar Aufwand, aber eben auch mehr Sicherheit. Zudem sollte IT auch mit Fokus auf den sicheren Betrieb beschafft bzw. entwickelt werden: vom Kommunikations- und Berechtigungskonzept bis hin zum Webapplikation-Firewall-Regelwerk, Quoten,-Security-Context-Constraints in Container-Umgebungen, AppArmor-, SE-Linux- und Seccomp-Profilen. Weitere Maßnahme wie die konsequente Anwendung kryptografischer Verfahren bieten sich im Rahmen einer Security-in-Depth-Strategie ebenfalls an.

Technische Schulden in Bezug auf den Einsatz von Legacy-Software und nicht länger mit Updates versorgten Programmen und Systemen bedürfen einer unabhängigen Verwaltung und Risikobetrachtung.

Nicht zuletzt stellt die Verteilung von Daten und Funktionen eine weitere Option dar, um die Wirkung von Informationssicherheitsvorfällen zu begrenzen. Auch dies sind allerdings Themen, die sich im Nachgang einer Beschaffung oder Entwicklung nur sehr schwer behandeln lassen – und daher bereits während der frühen Planungs- oder Designphase Berücksichtigung finden sollten.

Bastian Angerstein (T.I.S.P, ISO-27001-Lead-Auditor) ist ehemaliger Softwareentwickler und seit 2008 zunehmend im Bereich der Informationssicherheit und Risikoverwaltung tätig – heute im Cloud-Umfeld bei der Robert Bosch GmbH.

Diesen Beitrag teilen: