ISO 27002Kapitel 8.8 Handhabung von technischen Schwachstellen

Worum geht es?

IT-Landschaften sind oftmals recht komplex. Insbesondere bei gewachsenen Beständen sind teils viele Systeme vorhanden und untereinander vernetzt. Solche Strukturen bieten möglicherweise Angriffsmöglichkeiten, gegen die besondere Schutzmaßnahmen ergriffen werden müssen.

Die Herausforderungen hierbei sind, mögliche Schwachstellen erst einmal bereits proaktiv zu erkennen, die hiermit verbundenen Risiken dann zu bewerten und diesen schließlich durch geeignete Maßnahmen entgegenzuwirken.

Was empfiehlt die ISO 27002?

Die speziellen Empfehlungen der Norm in Kapitel 8.8 setzen als Grundvoraussetzung voraus, dass ein aktuelles und vollständiges Bestandsverzeichnis von IT-Komponenten existiert. Ohne exakte Kenntnis, welche Software in welcher Version auf welchen Systemen installiert ist, wird es nicht möglich sein, ein erfolgreiches Schwachstellen-Management aufzubauen.

Unser Tipp: Nutzen Sie dafür ein softwaregestütztes Asset-Management, wie es etwa unsere ISMS-Software activeMind.cloud bietet.

Sofern ein solches Verzeichnis besteht, schlägt die Norm die folgenden Gesichtspunkte vor, die sich grob in drei Abschnitte teilen lassen:

Aufdeckung von Schwachstellen

• Wie in vielen anderen Bereichen auch, sollten Rollen und Zuständigkeiten auch im hier relevanten Zusammenhang vorab definiert und zugewiesen sein. Organisationen sollten daher konkret festlegen, wer sich etwa um die Überwachung von Schwachstellen, die Risikobeurteilung und die Nachverfolgung von Werten kümmert.
• Eine der zentralen Hürden besteht insbesondere darin, innerhalb der Organisation überhaupt einen Prozess zu etablieren, der verlässlich dafür sorgt, dass Schwachstellen überhaupt bekannt werden und das dann auch angemessen auf sie reagiert wird.
• Für die gesamte im Bestandsverzeichnis erfasste Soft- und Hardware sollten vertrauenswürdige Quellen genutzt werden, um jederzeit aktuelle Informationen über bestehende Schwachstellen zu erhalten und auch hinsichtlich neuerer Entwicklungen auf dem Laufenden zu bleiben. Neben den Informationen, die Hersteller und Anbieter von Lösungen selbst bereitstellen, können auch die Veröffentlichungen von unabhängigen oder öffentlichen Stellen hilfreich sein, beispielsweise aus dem Fachjournalismus oder Einrichtungen wie dem Bundesamt für Sicherheit in der Informationstechnik (BSI).
• Es ist in diesem Zusammenhang durchaus sinnvoll, die eigenen Lieferanten und Dienstleister auch vertraglich dazu zu verpflichten, unverzüglich und aktiv über Schwachstellen zu informieren und Hinweise zur Behandlung zu geben.
• Überhaupt ist es meist sinnvoll, in den aktiven Dialog einzutreten und beispielsweise eine Kontaktadresse bereitzustellen, über die externe Meldungen über mögliche Schwachstellen an die Organisation gerichtet werden können, und im Gegenzug auch eigene Erkenntnisse mit den entsprechenden Kreisen zu teilen.
• Über „Bug Bounties“ oder ähnliche Auslobungen können externe Personen gegebenenfalls noch besonders motiviert werden, die Organisation über Schwachstellen zu informieren.
• Ergänzend sollten auch Tools zum Scan auf Schwachstellen eingesetzt werden, um bislang unentdeckte Probleme zu finden, aber auch zur Überprüfung, ob bereits bekannte Lücken auch tatsächlich geschlossen wurden. Verschiedene Angebote solcher Lösungen sind in der Lage, solche Scans auch übergreifend für mehrere Hersteller durchzuführen und ggf. verfügbare Updates zu installieren.
• Hilfreich kann auch sein, die eigene Umgebung regelmäßig oder wenigstens punktuell – etwa nach relevanten Änderungen – mittels detaillierteren und gründlicheren Pentests zu überprüfen. Solche Tests sollten nur professionell durchgeführt werden, um nicht versehentlich weitere Verschlechterungen der Systemsicherheit herbeizuführen.
• Soweit im Rahmen eigener Softwareentwicklung relevant, sollten auch Schwachstellen verwendeter Bibliotheken und fremden Quellcodes laufend beobachtet werden.

Beurteilung von Schwachstellen

• Nach Erhalt eines Hinweises auf eine Schwachstelle, gilt es diese zu analysieren und zu bewerten. Das Risiko muss bestimmt werden, um dann mit der richtigen Priorisierung passend zu reagieren. Handelt es sich um eine Schwachstelle, die unter unwahrscheinlichen Rahmenbedingungen zum Ausfall eines nicht sonderlich wichtigen Dienstes oder zum Absturz eines Systems ohne hohe Verfügbarkeitsanforderungen führen kann? Oder aber besteht die realistische Gefahr, dass sich ein Angreifer weitreichend Herrschaft über kritische Systeme verschafft?
• In Abhängigkeit dieser Analyse müssen die geeigneten Schritte ergriffen werden.

Beseitigung der Schwachstellen

• Auf jede bekannt gewordene Schwachstelle muss angemessen reagiert werden.
• Es sollte eine entsprechende Planung bestehen, die auch zeitliche Vorgaben macht, wie auf Schwachstellen in Abhängigkeit des verbundenen Risikos reagiert werden muss. Je höher das Risiko und je weitreichender die Auswirkungen sein können, desto dringlicher ist die korrekte Reaktion.
• Bei besonders hoher Kritikalität einer Schwachstelle sollten gegebenenfalls die Mechanismen in Kraft treten, die für Informationssicherheitsvorfälle entwickelt wurden; auch wenn dieser Vorfall bislang ausgeblieben ist.
• Trotz der gebotenen Eile muss bei der Behebung von Schwachstellen besondere Aufmerksamkeit darauf gelegt werden, dass sich die Situation im Zuge der Verbesserungsversuche nicht verschlimmert. Jegliche Aktualisierung von Software darf ausschließlich erfolgen, wenn diese aus einer vertrauenswürdigen Quelle stammt und geprüft wurde. Zudem muss ausgeschlossen sein, dass die Installation andere Risiken und Nebenwirkungen erzeugt. Hierzu muss gegebenenfalls auch betrachtet werden, welche Fernwirkungen eine punktuelle Veränderung im Gesamtsystem entfalten kann. Es könnte sonst möglich sein, dass durch übereilte Veränderungen an einer Stelle, das Zusammenspiel mehrerer Dienste nicht mehr funktioniert; eventuell benötigt ein anderer kritischer Dienst eben die Version einer Software, die es gerade zu ersetzen gilt.
• Im eben gerade genannten Zusammenhang ist es auch dringend notwendig, nach jeder Abhilfemaßnahme nicht nur zu verifizieren, dass sie wirksam war, sondern auch, dass sie keine ungewollten Auswirkungen hatte.
• Möglicherweise ist es sinnvoll und möglich, den von einer Schwachstelle betroffenen Bereich vorübergehend oder sogar dauerhaft zu deaktivieren, statt eine möglicherweise übereilte Behebungsmaßnahme zu ergreifen.
• Sollte es weder möglich sein, die Schwachstellen zu schließen, noch den betroffenen Dienst zu deaktivieren, muss über eine Isolierung des betroffenen Systems nachgedacht werden. In diesen Fällen wird dann einfach nach Möglichkeit der Angreifer von der Schwachstelle ferngehalten.

Selbstverständlich sind alle hier beschriebenen Schritte nachvollziehbar zu dokumentieren. Die Wirksamkeit des Prozesses muss zudem überwacht und bewertet werden.

Fazit

Der hier beschriebene Bereich stellt bereits kleinere Organisationen vor gewaltige Herausforderungen. Je größer die IT-Landschaft ist, desto mehr steigen diese Herausforderungen noch. Wenn nun noch größere Verflechtungen mit anderen Unternehmen bestehen, Shared Services oder Cloud Dienste genutzt werden, wird es noch unübersichtlicher und kniffliger und bereits das eingangs genannte Bestandsverzeichnis wird zur fast unlösbaren Aufgabe.

Viele Organisationen behelfen sich mit nicht wirklich geeigneten Maßnahmen. Auf der einen Seite wird das Thema ignoriert und man hofft auf einen guten Ausgang. Auf der anderen Seite werden wahllos vermeintliche Sicherheitsfeatures und Auto-Update-Mechanismen aktiviert, die in ihrer nicht aufeinander abgestimmten Gesamtheit dann auch zu einigermaßen überraschenden Ergebnissen führen können.

Angesichts der Tatsache, dass die im Beitrag genannten Tools zum Scan auf Schwachstellen auch böswilligen Parteien zur Verfügung stehen, sollte keine Organisation, sei sie auch noch so klein – das Thema vernachlässigen. Wenn eine Schwachstelle aus dem Internet erreichbar ist, wird sie irgendwann ausgenutzt werden.