NIS2 rückt Patch-Management stärker in den Fokus

Welche Probleme Virtual Patching löst



Andreas Fuchs ist als Director Product Management bei DriveLock Experte für Endpoint Security, UEM, Produktentwicklung und -strategie. Der Forrester ZTX Strategist (ZTX-S) spricht regelmäßig zu verschiedenen Themen im Bereich IT-Security.
Martin Mangold ist als Vice President Cloud Operations für das weltweite Cloud Business der DriveLock SE verantwortlich. Zu seinem Aufgabenspektrum gehören der RZ-Betrieb, die technische Unterstützung von Sales, sowie die Beratung und Supervision von Produktmanagement und -entwicklung. Der Diplom-Informatiker hat mehr als 20 Jahre Erfahrung in der Beratung und Implementierung von Lösungen im Bereich Client und Service-Management. Seit 2011 liegt sein Fokus auf Cloud-basierten Lösungen.
Patch Management gilt als entscheidender Faktor zur Absicherung von IT-Systemen. Aber was, wenn es keine Patches gibt oder sich die Systeme aus Kompatibilitätsgründen nicht patchen lassen? Und wie ist das Thema im Kontext von NIS2 einzuordnen?
Bekannte Sicherheitslücken zu schließen ist eine seit langem immer wieder gegebene Empfehlung. Die NIS2-Direktive der EU erhöht den Druck. Da Patches in der Produktivumgebung aber nicht immer einfach anzuwenden sind, lohnt es sich, über Virtual Patching nachzudenken.
Bekannte Sicherheitslücken zu schließen ist eine seit langem immer wieder gegebene Empfehlung. Die NIS2-Direktive der EU erhöht den Druck. Da Patches in der Produktivumgebung aber nicht immer einfach anzuwenden sind, lohnt es sich, über Virtual Patching nachzudenken.
Foto: ValentinT - shutterstock.com

Patch Management gilt unter anderem als eines der essenziellen Elemente, um IT-Systeme vor Cyberangriffen zu schützen und die Systemfunktionalität durchgehend zu gewährleisten. Schwachstellen, Fehlkonfigurationen und anderen Schwächen mit hoher Priorität zu beheben, erfordert oft mehr als nur die Installation von Patches. Deshalb kann es vorkommen, dass es zum Beispiel für Software von Maschinen, die Teil einer umfangreichen IIoT-Struktur sind, keine Paches gibt.

Auch gibt es Systeme, die aus Garantie- oder Supportgründen gar nicht gepatcht werden dürfen, weil die Anwendung eines Patches mehr schaden als nützen kann; oder es bestehen Bedenken hinsichtlich der Empfindlichkeit des Systems. In solchen Fällen hilft es, den Fokus darauf zu lenken, welches Ziel mit dem Patch eines Systems erreicht werden soll.

Welches Ziel mit Patches erreicht werden soll

Gerade im Bereich der Kritischen Infrastrukturen verfolgt die Europäische Union das Ziel, über den KRITIS-Sektor hinaus auch weitere "wesentliche und wichtige Einrichtungen" künftig besser zu schützen und ein EU-weit einheitliches, hohes Niveau an Cybersicherheit zu etablieren. Dies soll eine effektivere Reaktion auf Sicherheitsvorfälle ermöglichen. Durch die Umsetzung der Risikomanagementmaßnahmen sollen Sicherheitsvorfälle vermieden oder zumindest in ihren Auswirkungen minimiert werden.

NIS2 verlangt, dass die Maßnahmen den "Stand der Technik" unter Berücksichtigung einschlägiger europäischer und internationaler Normen einhalten. Aktuell gibt es jedoch keine konkreten Vorgaben zu den erforderlichen Maßnahmen und Umsetzungsanleitungen. In dieser Übergangszeit können sich Unternehmen und Organisationen an anderen bewährten Regelwerken und Standards orientieren, darunter ISO/IEC 27001:2022.

Maßnahmen zum Risikomanagement bei NIS2

Eine Maßnahme als Teil des Risikomanagements laut NIS2 (Artikel 21 Abs. 2) ist "Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen". Diese Maßnahmen sind nicht nur wesentlich für die Risikominderung, sondern auch für die Offenlegung und das Management von Schwachstellen, was eine präventive und erkennende Funktion im Sicherheitskonzept einer Organisation einnimmt.

Die Norm ISO/IEC 27001, ein anerkannter Standard für Informationssicherheitsmanagementsysteme, bietet im Anhang A einen Katalog von Kontrollen, die als technische Leitplanken für Organisationen dienen können:

  • Control A 8.8 befasst sich mit dem Management technischer Schwachstellen. Hierbei wird betont, dass Organisationen Informationen über technische Schwachstellen der genutzten Informationssysteme einholen, das eigene Gefährdungspotenzial evaluieren und geeignete Maßnahmen zur Risikobewältigung ergreifen müssen.

  • Control A 8.7 zielt auf den Schutz vor Schadsoftware (Malware) ab. Dies umfasst die Implementierung von Schutzmaßnahmen, welche durch entsprechende Sensibilisierung der Nutzer unterstützt werden.

  • 5.7 Threat intelligence: Information relating to information security threats shall be collected and analysed to produce threat intelligence.

  • Control A 5.7 hebt die Bedeutung von Threat Intelligence hervor. Es verlangt die Sammlung und Analyse von Informationen über Bedrohungen der Informationssicherheit, um Erkenntnisse über Bedrohungen zu gewinnen.

Wie wir sehen, kann die Umsetzung dieser Maßnahmen komplex sein, doch das frühzeitige Erkennen von Schwachstellen und deren konsequente Behebung sind effektive Methoden, um den Schutz gegen alle Arten von Malware und Exploits zu gewährleisten.

Virtual Patching - Definition

Beim Patchen von Applikationen oder Betriebssystemen sind Fehlerbehebungen oder kleinere Funktionserweiterungen üblicherweise das Ziel. Letztere sind aus Sicht der Security irrelevant. Im ersten Fall bedeuten sie das Schließen einer Sicherheitslücke. Hier setzt auch Virtual Patching an. Eine Sicherheitslücke kann auf zweierlei Arten geschlossen werden:

  1. Beheben der Ursache: Der virtuelle Patch schließt die Sicherheitslücke durch Code-Optimierung, so dass die Vulnerability/Schwachstelle geschlossen wird.

  2. Beheben des Symptoms: Der virtuelle Patch verändert nicht die Applikation bzw. den Code. Vielmehr werden Sicherheitsregeln etabliert, die das Ausnützen der Sicherheitslücke verhindern.

Was virtuelles Patchen bringt

Es gibt eine Reihe von Gründen beziehungsweise Szenarien, in denen sich virtuelles Patching im Vergleich zu "echtem" Patchen anbietet - oder auch die einzige Option darstellt:

  • Für eine Applikation werden keine Patches mehr angeboten, da zum Beispiel der Wartungsvertrag abgelaufen ist, der Hersteller nicht mehr existiert oder die Software nicht mehr durch den Hersteller gepflegt wird.

  • Speziell im sogenannten OT-Umfeld sind Hersteller von Fertigungsanlagen sehr restriktiv im Hinblick auf Patches. Viele Hersteller testen ihre Software nur mit einem bestimmten Release-Stand. Ausschließlich für diesen bieten sie Support und Garantie. Wird hier ein Patch aufgebracht, verfallen unter Umständen Support- beziehungsweise Garantieansprüche.

  • Überbrücken der Zeit zwischen dem Erkennen einer Schwachstelle und ihrer Behebung mit Hilfe eines Patches.

  • Patchen - also die Veränderung einer Applikation beziehungsweise ihres Codes - birgt immer ein gewisses Risiko. Das heißt, Unternehmen müssen im Zuge des Patches regelmäßig testen, ob die Applikationen sich noch so verhalten, wie vor dem Patchen. Je nach Sicherheitsrelevanz der Applikation beziehungsweise dem Änderungsvolumen des Patches verändert sich das Risiko und der damit verbundene Patch-Aufwand. Gegebenenfalls steht dieser Aufwand nicht im Verhältnis beziehungsweise ist durch das Herstellerunternehmen nicht in angemessener Zeit zu stemmen.

So funktioniert Virtual Patching

Beim Patchen geht es in der Regel darum, Sicherheitslücken zu schließen. Das kann zum einen programmatisch erfolgen. Es kann aber auch dadurch erreicht werden, dass das Ausnutzen von Sicherheitslücken gezielt unterbunden wird.

Hierzu gibt es wiederum unterschiedliche Ansätze. Sie alle haben gemein, dass zunächst die Schwachstellen auf den zu sichernden Endgeräten erkannt werden müssen. Um dies zu erreichen, werden sogenannte Vulnerability Scanner eingesetzt, die eine Reihe von Tests durchführen, um die Sicherheitslücken zu erkennen. Diese sind in sogenannten CVEs (Common Vulnerabilities and Exposures) beschrieben. Hier finden sich in der Regel auch Informationen darüber, wie eine Sicherheitslücke zu schließen ist.

Wenn man bedenkt, dass auf typischen IT-Systemen in der Regel nur ein Teil der dort installierten Software/Funktionen genutzt wird, kann im einfachsten Fall durch den Einsatz von sogenannten Applikationskontrollen das Ausführen von betroffenen Applikationen unterbunden werden.

Je nach Intelligenz und Granularität der Applikationskontrolle kann das Beschneiden der Funktionalität auf ein Minimum reduziert werden. So kann zum Beispiel explizit die Verwendung von Subprozessen kontrolliert bzw. die Parametrisierung von Funktionsaufrufen überwacht werden. In der Regel sind Applikationen ja nicht grundsätzlich unsicher, vielmehr ist es häufig eine sehr spezielle Funktionalität oder deren Aufruf bzw. der Zeitpunkt, zu dem diese aufgerufen wird.

Virtuelles oder reguläres Patching?

Der eine oder andere Leser denkt jetzt sicherlich: Wenn virtuelles Patchen so einfach ist, warum betreiben Softwarehersteller und Unternehmen immer noch den Aufwand des "echten" Patchens? Virtual Patching darf nicht darüber hinwegtäuschen, dass die Ursache für eine Sicherheitslücke weiterhin besteht.

Im Medizinbereich wäre das in etwa vergleichbar damit, wenn lediglich die Schmerzen aber nicht deren Ursache therapiert werden. Dennoch sollte Virtual Patching als wichtige Ergänzung in der Sicherheitsstrategie von Unternehmen seinen Platz finden.

Zurück zu NIS2

Auch wenn die NIS2 Richtlinie keine konkreten Checklisten für Sicherheitsmaßnahmen liefert, bieten vorhandene Modelle wie der BSI IT-Grundschutz oder die ISO 27000 Normenreihe Best Practice Vorgaben, die entsprechende Security Controls enthalten, um das aus Schwachstellen resultierende Informationssicherheitsrisiko dauerhaft und nachweislich zu reduzieren.

Mehr zum Thema

Renaissance des Patch-Managements

Was "Stand der Technik" bei Cyber-Security bedeutet

Zur Startseite