Sollten wir die Ausnahmeregelung für NIS2-Patches auf SAP-Altsysteme anwenden?

Autor : Thierry Julien, CEO & Gründer, TJC Group

Am 17. Oktober hat die Europäische Kommission einen zusätzlichen Abschnitt, den sogenannten „Anhang“, zu ihrer Durchführungsverordnung zur Umsetzung der Richtlinie (EU) 2022/2555 veröffentlicht. NIS2 ist ein Gesetz der Europäischen Union (EU), das die Cybersicherheit in der Region verbessern soll. Die Abkürzung steht für Network and Information Systems Directive 2. Vereinfacht ausgedrückt, müssen sich Unternehmen wie Cloud-Service-Anbieter an die aktualisierten Anforderungen der überarbeiteten NIS2-Richtlinie halten.

Die NIS2 gilt für öffentliche und private Einrichtungen, die bestimmte kritische Dienstleistungen oder kritische Infrastrukturen bereitstellen, die als mittlere oder große Unternehmen gelten und die ihre Dienstleistungen innerhalb der EU erbringen oder ihre Tätigkeiten innerhalb der EU ausüben.

In Absatz 6.6 des oben erwähnten Anhangs geht es um die Verwaltung von Sicherheitspatches. Es überrascht nicht, dass in Absatz 6.6.1 erwähnt wird, dass diese Patches, wenn sie verfügbar sind, angemessen schnell, aus vertrauenswürdigen Quellen und mit vorherigen Tests angewendet werden sollten. Wenn sie nicht verfügbar sind, sollten Umgehungslösungen angewendet werden. Interessant ist der zweite Absatz (6.6.2), den ich wortwörtlich zitiere:

„Abweichend von Punkt 6.6.1. (a) können die betreffenden Einrichtungen beschließen, nicht

Sicherheits-Patches anwenden, wenn die Nachteile der Anwendung der Sicherheits-Patches

den Nutzen für die Cybersicherheit überwiegen. Die betreffenden Stellen dokumentieren ordnungsgemäß und

die Gründe für eine solche Entscheidung zu begründen..“

Wann kann diese Ausnahmeregelung gelten?

Einige argumentieren, dass die Kontinuität des Dienstes im Rahmen des NIS2-Risikomanagements ein Argument sein könnte. In Absatz 6.6.1 wird jedoch kein sofortiger Patch gefordert, sondern ein einigermaßen schnelles Vorgehen mit Tests. Daher sollte die Kontinuität des Dienstes keine Ausnahmeregelung erfordern.

Andere gehen von kritischen Systemabhängigkeiten aus, bei denen ein Patch in einem System größere Auswirkungen haben kann (denken Sie an die Energie-, Gesundheits- und Transportbranche). Ein gutes Beispiel ist die Meltdown-Schwachstelle von 2018 (CVE-2017-5754), die CPUs betrifft. Der Grund für das Nicht-Patching war ein erheblicher Leistungsabfall (5 bis 30 %) in einigen Anwendungen (z. B. in der Forschung oder im Finanzwesen). Wir könnten auch an das Windows 10 Update (KB4524244) im Jahr 2020 denken.

Ein weiteres Beispiel, von dem die meisten von uns gehört haben, ist die Unfähigkeit von Windows XP, unzählige medizinische Geräte zu patchen. Obwohl Microsoft den Support für Windows XP im Jahr 2014 offiziell eingestellt hat, blieben viele dieser Geräte aufgrund ihrer hohen Kosten und der langen Austauschzyklen in Betrieb. Nicht nur, dass das Patchen dieser Systeme dazu führen kann, dass sie nicht mehr funktionieren (was ein potenzielles Lebensrisiko für die Patienten darstellt), sondern das Patchen könnte auch die behördlichen Zertifizierungen ungültig machen.

Ist dies eine offene Bar für Schwachstellen?

Es ist nicht schwer, eine Liste von Datenschutzverletzungen zu erstellen, die auf fehlende Patches zurückzuführen sind oder zumindest teilweise darauf zurückzuführen sind. Ein berühmter Fall ist die Datenpanne bei Equifax, die am 12. Mai 2017 begann, als Equifax seine Website für Kreditstreitigkeiten noch nicht mit der neuen Version von Struts aktualisiert hatte.

Die Möglichkeit einer Ausnahmeregelung ist kein Freifahrtschein, sondern ein strukturierter Ansatz, bei dem Unternehmen ihre Entscheidungen, bestimmte Patches nicht anzuwenden, bewerten, dokumentieren und begründen müssen.

Außerdem ist NIS2 nicht die einzige Vorschrift, die es zu beachten gilt. Nehmen wir ein einzelnes Beispiel: DSGVO schreibt zwar nicht vor, dass Unternehmen jeden Patch anwenden müssen, setzt aber einen hohen Standard für den Schutz personenbezogener Daten durch. Unter DSGVO kann das Versäumnis, einen Patch aufzuspielen, zu einem Datenschutzverstoß führen, der für das Unternehmen rechtliche Konsequenzen hat. Die Aufsichtsbehörden könnten das Versäumnis, kritische Schwachstellen zu patchen – insbesondere wenn sie bekannt waren und nicht behoben wurden – als Verstoß gegen die Pflicht zum Schutz personenbezogener Daten (Artikel 32 – Sicherheit der Verarbeitung) interpretieren.

Gilt dies auch für SAP-Altsysteme?

Ja, das mag eine seltsame Frage sein, denn SAP ERP-Systeme waren und sind immer noch das Herzstück der integrierten IT-Systeme für die meisten der größten Unternehmen weltweit.

Erstens müssen die SAP-Altsysteme aus Gründen der Steuerprüfung beibehalten werden, selbst wenn der Übergang zu S/4HANA durch eine „Lift-and-Shift“-Migration (Brownfield) erfolgt. Darüber hinaus kann die Bewahrung detaillierter historischer Geschäftsdaten wertvoll sein, da sie wichtiges Material für KI-Modelle liefern. Dennoch sind viele SAP-Systeme ungepatchte Altsysteme. Wieso den? Ich habe alle möglichen Begründungen gehört, wie zum Beispiel…

Ja, aber es ist eine alte Version.

Ja, aber es läuft auf einer virtuellen Maschine, also kein Problem.

Ja, Legacies sind ungepatched, aber unser aktuelles System ist gepatcht.

Ja, aber es ist von unserem externen Netzwerk getrennt (als ob die Mitarbeiter nie ihre eigene Firma gehackt hätten).

Zum Zeitpunkt der Ausmusterung enthält ein altes ERP-System in der Regel eine Fülle sensibler Daten: detaillierte Informationen über Kunden und Lieferanten, Mitarbeiterdaten, Vermögenswerte, Projektdetails, Produktnamen, Verkaufsdetails und sogar geschützte Informationen wie Stücklisten, Arbeitspläne, Produktkosten und Gewinnmargen. Diese Daten stellen ein hohes Sicherheitsrisiko dar, selbst wenn sie zwei bis fünf Jahre alt sind. Wenn Sie die Anwendung der Ausnahmeregelung 6.6.1 in Erwägung ziehen, finden Sie hier einige Gründe, die als „ordnungsgemäß dokumentierte“ Begründung für den Verzicht auf Patches dienen könnten:

Ich habe das System nicht gepatcht, bevor ich es außer Betrieb gesetzt habe.

Wartungsgebühren werden nicht mehr gezahlt, so dass Patches nicht mehr möglich waren. Auch die Datenbankwartung wurde eingestellt, die ein mittelgroßes Unternehmen jährlich bis zu einer Viertelmillion Dollar kosten kann.

… Sie können der Liste gerne weitere hinzufügen.

Ja, es ist billiger, die Systeme ungepatcht und ungesichert zu lassen und die Datenschutzbestimmungen nicht anzuwenden, als sich an die gesetzlichen Vorschriften zu halten. Aber Artikel 6.6.1 schlägt vor, dass Sie keine Patches aufspielen, wenn „die Nachteile der Anwendung der Sicherheitspatches

die Vorteile der Cybersicherheit überwiegen“ … Es heißt nicht ‚überwiegen die Kosten‘.

Ich vermute also, dass es für Unternehmen schwierig sein wird, die Nicht-Patchbarkeit von SAP-Legacy-Systemen zu dokumentieren, insbesondere jetzt, da es Lösungen für die Stilllegung gibt. Schauen Sie sich zum Beispiel Enterprise Legacy System Application an.

Fazit

Zusammenfassend lässt sich sagen, dass Abschnitt 6 Absatz 6.6.2 anerkennt, dass ein einheitlicher Ansatz für das Patchen in bestimmten Kontexten unpraktisch oder kontraproduktiv sein kann, aber kein Ausweg aus der verantwortungsvollen Cyber-Hygiene ist. Er steht im Einklang mit dem Ziel von NIS2, die allgemeine Widerstandsfähigkeit zu verbessern, ohne starre Anforderungen zu stellen, die unbeabsichtigt kritische Dienste gefährden könnten. Es ist definitiv kein Freifahrtschein aus dem Gefängnis.