DET.5 Management von Schwachstellen

Detektion SOLLTE Verfahren und Regelungen zur Erkennung und Behandlung von Schwachstellen verankern.

Erläuterung

Relevant können hierbei verschiedene Arten von Schwachstellen sein (z.B. Physisch und im Netz, Orte, Adressbereiche, Anwendungen und Ports). Zur Erkennung können Schwachstellenscans, Pentests und ein Abgleich der eigenen Infrastruktur mit öffentlichen Schwachstellendatenbanken genutzt werden. Zur Beurteilung der Kritikalität können Scoring-Systeme wie CVSS oder Berichte der betroffenen Hersteller oder Dienstleister herangezogen werden. Zur Behandlung können z.B. Sicherheitspatches, die Deaktivierung betroffener (Teil-)Funktionen oder Komponenten oder die Isolierung betroffenen Systeme oder Anwendungen in Frage kommen. Für Details siehe ISO/IEC 30111.

Detektion SOLLTE Schwachstellen bei Entdeckung inklusive betroffener Komponenten, Kritikalität und Status dokumentieren.

Erläuterung

Da die Aktualität des Schwachstellenregisters von großer Bedeutung ist, ist die manuelle Pflege von Schwachstellen in einem Dokument nicht empfehlenswert. Stattdessen können automatisiert gepflegte Datenbanken oder spezielle Schwachstellenmanagement-Tools genutzt werden. Das Schwachstellenregister kann auch als verteiltes Register gepflegt werden (z.B. in Schwachstellenscannern, Patchmanagement-Servern, etc.), allerdings ist hierbei eine einheitliche Beurteilung und Priorisierung aufwändiger.

Detektion SOLLTE eine Vorgehensweise zum Scan nach Schwachstellen einschließlich deren Auswertung und Behandlung verankern.

Erläuterung

Über das Netz erreichbare Schwachstellen bergen das Risiko, dass hierüber Angriffe in IT-Systeme und Anwendungen eindringen, Daten auslesen oder sich über das Netz verbreiten. Schwachstellenscans finden solche Lücken, indem sie Anfragen zu bekannten Schwachstellen im Netz stellen und die Antworten auswerten. Regelmäßige Scans tragen dazu bei, dass Sicherheitslücken entdeckt werden, bevor sie ausgenutzt werden.

Detektion für IT-Systeme KANN die tatsächliche Abwehrfähigkeit nach [einer anerkannten Vorgehensweise] [regelmäßig] überprüfen.

Erläuterung

Ein Penetrationstest, oft auch als Pentest bezeichnet, ist eine von Sicherheitsexperten simulierte Cyberattacke, um Schwachstellen und Sicherheitslücken aufzudecken. Ziel ist es, komplexe Schwachstellen in konkreten Informationsumgebungen aufzuspüren, bevor sie von echten Angreifern ausgenutzt werden könnten. Dabei werden verschiedene Methoden und Techniken eingesetzt, die auch von Angreifern verwendet werden könnten, z.B. Informationssammlung, Scan und Ausnutzen von Schwachstellen, seitliches Ausbreiten über das Netz, sowie Versuche, durch Täuschung und Manipulation von Personen an Informationen oder Zugriff zu gelangen. Anerkannte Vorgehensweisen, die für Penetrationstests angewendet werden können, sind z.B. der BSI Praxis-Leitfaden für IS-Penetrationstests, OSSTMM, NIST SP 800-115, PTES (Penetration Testing Execution Standard), OWASP für Webanwendungen oder der Leitfaden für Penetrationstests von Large-Language-Modellen des Expertenkreises KI-Sicherheit. Pentests können von externen Dienstleistern oder internem Personal vorgenommen werden. Entscheidend für ein gutes Ergebnis ist hierbei neben einer standardisierten, strukturierten Vorgehensweise die Qualifikation der ausführenden Personen, da Penetrationstests die Ausforschung komplexer Angriffsmöglickeiten erfordern, die weit über den isolierten Einsatz einzelner Werkzeuge hinausgehen können. Pentesting von Außen enthält sowohl die Suche nach angreifbaren Schwachstellen aus dem Internet, als auch die vorhergehende Recherche, um angreifbare Informationen aufzuspüren (Open Source Intelligence). Zur konsequenten Überprüfung gehört auch, dass deren gefundene Schwachstellen im Rahmen des Schwachstellenmanagements zeitnah behandelt werden. Zweckmäßig ist es daher, gefundene Schwachstellen bestimmten zuständigen Personen oder Rollen zur Behebung zuzuweisen und diese innerhalb der Fristen des Schwachstellenmanagements zu schließen.

Detektion für IT-Systeme KANN die tatsächliche Abwehrfähigkeit [regelmäßig] durch unabhängig agierende Sicherheitsexperten überprüfen.

Erläuterung

Red Teaming ist ein strukturierter, realitätsnaher Sicherheitstest, bei dem ein sogenanntes Red Team – also ein unabhängiges, offensiv agierendes Expertenteam – versucht, unter realen Bedingungen in IT-Systeme, Netzwerke oder Anwendungen einzudringen, um Schwachstellen und Reaktionslücken aufzudecken. Dadurch wird nicht nur die technische Abwehr getestet, sondern auch organisatorische und menschliche Faktoren, etwa die Wirksamkeit von Incident-Response-Prozessen, Alarmierungsketten oder die Reaktion des Security Operations Center (SOC). Solche regelmäßigen Überprüfungen durch unabhängige Red Teams ermöglichen einen objektiven und unvoreingenommenen Blick auf die aktuellen Stärken und Schwächen der Sicherheitsmaßnahmen, wodurch Schwachstellen frühzeitig erkannt werden können. Unabhängig ist ein Red Team dabei, wenn es organisatorisch und personell getrennt vom Betriebspersonal und dessen Weisungshierarchie (Blue Team) agiert, sodass keine Interessenkonflikte die objektive Bewertung gefährden.

Detektion KANN den Informationsverbund durch Sicherheitsexperten auf Anzeichen für Angriffe [regelmäßig] überprüfen.

Erläuterung

Threat Hunting bezeichnet eine proaktive Suche nach Anzeichen für Sicherheitsvorfälle durch Analyseexperten, da fortschrittliche Angriffe durch automatisierte Systeme zur Angriffserkennung häufig nicht detektiert werden können. Im Unterschied zum Penetrationstest steht dabei nicht das Aufsuchen von Schwachstellen, sondern das Finden bereits erfolgreicher Angriffe oder Bedrohungen in den eigenen Systemen und Anwendungen im Vordergrund. In einem ersten Schritt werden Hypothesen, wo und wie sich Angreifer in Infrastrukturen eingeschlichen haben könnten, aufgestellt. Dabei kann man sich etwa auf den Kontext des Informationsverbunden und existierende Bedrohungsmodellierungen stützen. Anschließend werden einschlägige Zielobjekte ausgewählt und auf Anzeichen für verdächtige Aktivitäten untersucht, etwa IT-Systeme, die direkt aus dem Internet erreichbar sind, Jumphosts oder zentrale Hostsysteme. Die Ergebnisse der Überprüfung fließen dann in die regelmäßige Auswahl und Verbesserung von Schutzmaßnahmen mit ein.

Detektion KANN den Informationsverbund auf verdeckte Kommunikationskanäle [bei Sicherheitsvorfällen mit verdeckten Kanälen und regelmäßig] überprüfen.

Erläuterung

Ein verdeckter Kanal (Covert Channel) ist ein heimlicher Kommunikationskanal, mit dem Angreifer legitime Verbindungen ausnutzen, um verdeckt Daten zu übertragen. Die Analyse verdeckter Kanäle ist insbesondere dann sinnvoll, wenn die Gefahr eines unbefugten Informationsflusses über Sicherheitsdomänen hinweg besteht, beispielsweise bei Anwendungen an externen Netzanschlüssen oder bei IT-Systemen, auf denen Daten mit hoher Sicherheitseinstufung neben anderen Daten verarbeitet werden. Relevant sind dabei sowohl Speicherkanäle (Storage Channel) als auch Zeitkanäle (Timing Channel). Um potenzielle verdeckte Kanäle zu identifizieren bietet es sich an, auf Bedrohungsmodellierungen (Threat Modelling) oder die Sicherheitsarchitektur der betrachteten IT-Produkte zurückzugreifen. Entwickler oder erfahrene Penetrationstester sind am besten in der Lage, potenzielle Schwachstellen in IT-Systemen zu identifizieren, die zu verdeckten Kanälen führen könnten. Einige verdeckte Kanäle können durch darauf spezialisierte Erkennungswerkzeuge (sog. Warden) erkannt werden. Aufgrund der Vielzahl denkbarer verdeckter Kommunikationswege können solche Kanäle jedoch kaum vollständig verhindert werden. Daher ist es zweckmäßig, sich bei der Analyse auf diejenigen potenziellen verdeckte Kanäle zu konzentrieren, die eine bestimmte Bandbreitenschwelle überschreiten. Hierbei bietet sich ein gegenseitiger Abgleich mit existierenden Bedrohungsmodellierungen oder Risikoanalysen an. Auch ergänzende Maßnahmen wie Traffic Normalization können sinnvoll sein - dadurch kann verdeckte Kommunikation zwar nicht erkannt werden, jedoch kann man sie so ausbremsen oder unerkannt eliminieren.

Detektion SOLLTE verfügbare Informationen zu Bedrohungen, die für den Informationsverbund relevant sind, [regelmäßig] überprüfen.

Erläuterung

Bedrohungsaufklärung (Threat Intelligence) dient dem Sammeln und Analysieren von Informationen über bestehende oder aufkommende Bedrohungen, um fundierte Maßnahmen zur Verhinderung von Schäden zu ermöglichen und die Auswirkungen solcher Bedrohungen zu reduzieren. Sie kann in drei Schichten unterteilt werden: strategische Bedrohungsaufklärung (Austausch von Informationen auf hoher Ebene über die sich verändernde Bedrohungslandschaft), taktische Bedrohungsaufklärung (Informationen über Angreifermethoden, beteiligte Werkzeuge und Technologien) und operative Bedrohungsaufklärung (Details zu spezifischen Angriffen, einschließlich technischer Indikatoren). Die gesammelten Bedrohungsinformationen können analysiert und später genutzt werden, indem Prozesse implementiert werden können, um die aus Bedrohungsaufklärungsquellen gesammelten Informationen in die Risikomanagementprozesse einzubeziehen. Sie können als zusätzlicher Input für technische Präventiv- und Erkennungskontrollen wie Firewalls, Intrusion-Detection-Systeme oder Anti-Malware-Lösungen dienen sowie als Eingabe für die Testprozesse und -techniken der Informationssicherheit verwendet werden. Die Institution kann Bedrohungsinformationen auf gegenseitiger Basis mit anderen teilen, um die allgemeine Bedrohungsaufklärung zu verbessern. Dies kann einen kooperativen Ansatz zur Stärkung der gemeinsamen Sicherheitslage fördern.

Detektion SOLLTE eine Vorgehensweise zur Entgegennahme und Behandlung von externen Schwachstellenmeldungen verankern.

Erläuterung

Ohne klar geregelten Umgang könnte eine Institution wertvolle Hinweise übersehen oder verzögert reagieren, was die Wahrscheinlichkeit eines Angriffs auf ungepatchte Ziele erhöht. Denkbar sind etwa Szenarien, in denen eine unbekannte Schwachstelle in einer öffentlich erreichbaren Webanwendung durch Dritte entdeckt wird und die Institution zwar kontaktiert wird, aber ohne geregelten Prozess keine Reaktion erfolgt – was einen erfolgreichen Angriff begünstigen könnte. Eine Institution kann diese Anforderung umsetzen, indem sie z. B. eine leicht auffindbare Kontaktmöglichkeit für Schwachstellenmeldungen bereitstellt – etwa eine dedizierte E-Mail-Adresse wie security@…, ein webbasiertes Formular oder die Eintragung eines „Security.txt“-Hinweises im Webauftritt (nach IETF RFC 9116). Sinnvoll kann es sein, klare Erwartungshaltungen zu kommunizieren, etwa welche Informationen eine Meldung enthalten sollte oder wie Rückmeldungen an Hinweisgeber erfolgen können. Auch ein internes Verfahren zur Kategorisierung und Priorisierung der eingehenden Hinweise kann helfen, Meldungen effizient zu bearbeiten. Eine Institution kann zudem in Erwägung ziehen, standardisierte Rückmeldungen vorzubereiten, um zeitnah bestätigen zu können, dass eine Meldung eingegangen ist, selbst wenn die inhaltliche Analyse noch aussteht. Sinnvoll ist auch ein freiwilliger Verhaltenskodex (z. B. ein „Responsible Disclosure Policy“-Hinweis) auf der eigenen Website, um Hinweisgebern einen rechtlich sicheren Rahmen für ihre Meldungen zu verdeutlichen. So entsteht ein klarer, reproduzierbarer Prozess, der externe Informationen in die eigene Sicherheitsarbeit einbindet und das Risiko minimiert, dass relevante Hinweise verloren gehen oder ungenutzt bleiben. Für Details siehe ISO/IEC 29147.

Detektion SOLLTE ein zeitnahes Patchmanagement verankern.

Erläuterung

Patches (Updates oder Sicherheitsaktualisierungen) sind neue Versionen, die Sicherheitslücken schließen. Je nach Aufbau der betroffenen Assets kann es bei der Aktualisierung auch erforderlich sein, Abhängigkeiten (Bibliotheken, Upstream Software) ebenfalls zu aktualisieren. Dies kann durch automatisierte Installation oder nach einem Test umgesetzt werden. Die Umsetzung kann auch den schrittweisen Rollout von Patches vorsehen, sodass bei Fehlern im Patch nicht alle Systeme gleichzeitig betroffen sind und auch komplexe Fehlerbilder durch Rückmeldungen frühzeitig erkannt werden können. Dies kann zum Beispiel nach dem One-Many-All-Prinzip oder Blue-Green-Deployment erfolgen. Zur Beurteilung der Kritikalität von Patches kann die Krititikalität der mit dem Patch verbundenen Schwachstellen, das Risikoprofil der zu patchenden Assets oder eine Korrelation komplexer Angriffswege herangezogen werden.