Kategorie: Allgemein

Allgemein, Risikomanagement, Schwachstelle, Supply Chain

Drohende Abschaltung der CVE-Datenbank und mögliche Alternativen

Kurz vor Ostern schreckte eine Nachricht des CVE-Teams die Sicherheitswelt auf. Die Finanzierung des CVE-Programms stand auf der Kippe und im Extremfall wäre einen Tag später bereits Schluss gewesen. Der Aufschrei war zu Recht groß und so konnte der Betreiber MITRE eine Vertragsverlängerung bis Anfang nächsten Jahres erreichen. Aber was kommt dann?  

In diesem Blogpost wollen wir mit etwas Abstand zu den Ereignissen zusammenfassen, welche Alternativen in der Diskussion um eine mögliche CVE-Abschaltung oft genannt wurden und ob sie tatsächlich in die Fußstapfen von CVE treten könnten.  

Anwendungsfälle

Zuerst wollen wir uns kurz anschauen, wo wir und viele unserer Kunden Berührungspunkte mit CVE haben. Es gibt darüber hinaus weitere Anwendungsfälle, aber für diese häufigen Nutzungen wollen wir uns im Folgenden die Alternativen anschauen. 

Risikomanagement im ISMS 

Beim Thema Informationssicherheit denken viele Laien als Erstes an die Sicherheitsupdates, die ihre Geräte regelmäßig von ihnen fordern. Im professionellen ISMS kommt noch dazu, dass einige Updates nur mit einer Betriebsunterbrechung eingespielt werden können oder unerwünschte Nebenwirkungen haben. Es muss also eine bewusste Entscheidung zwischen dem neu hinzugekommenen Sicherheitsrisiko und den betrieblichen Einschränkungen getroffen werden. Wenn eine Sicherheitslücke bereits bekannt ist, aber noch kein Patch verfügbar ist, wird die Entscheidung zwischen Abschalten und Risikoakzeptanz noch herausfordernder. 

Die reinen CVE-Nummern können in dem Anwendungsfall bei der weitergehenden Recherche helfen oder teilweise den Abgleich von verschiedenen Prüfformen ermöglichen (z.B. ob die im Pentest erkannten Lücken, bereits aus einem anderen Audit adressiert werden). 

Meist nutzt man jedoch auf CVE-basierte Datenbanken wie die National Vulnerability Database (NVD) der US-Regierung oder Ableitungen davon, die bereits eine allgemeine Risikobewertung mitbringen. Damit können bereits erkannte Risiken schneller und ressourcensparsam vorbewertet werden. Das konkrete Risiko für die jeweilige Betriebssituation muss man dennoch individuell bewerten (z.B. ob die betroffene Funktion überhaupt genutzt wird). 

Außerdem nutzen viele Informationsdienste und Vulnerability-Management-Tools CVE-basierte Datenbanken, um auf neu bekanntgewordene Schwachstellen hinzuweisen. Im besten Fall wählt man als Betreiber alle genutzten Softwareprodukte aus und wird dann aktiv auf neue Schwachstellen hingewiesen. 

Schwachstellenscan für Container 

Für Betreiber von containerisierten Services ist das Scannen von Containern bzw. Container-Scanning ist ein weiterer Anwendungsfall für die Nutzung von CVEs.  

Dabei werden Container-Images auf Sicherheitslücken überprüft. Zuerst wird analysiert, welche OS-Pakete, Dependencies und weitere Software in dem zu scannenden Image benutzt werden, z.B. openssl. Anschließend werden die Findings (Name der Komponente sowie Versionsnummer/-stand) mit den gängigen CVE-basierten Datenbanken wie NVD abgeglichen. Sollten bekannte Schwachstellen identifiziert werden, wird dies an das Scanning-Tool zurückgemeldet und das Tool erstellt auf Basis dieser Informationen einen Bericht. 

Der Bericht enthält dann. welche CVE gefunden wurde, wie schwerwiegend diese ist bzw. wie hoch ihr CVSS-Score ist, wo im Image die Schwachstelle gefunden wurde, und es werden in den meisten Fällen auch direkt Mitigationsmaßnahmen empfohlen. Diese Maßnahmen beziehen sich entweder auf ein Update/Upgrade der verwendeten Version auf die nächste sichere Version oder auf geeignete Konfigurationen, um die Sicherheitslücke zu schließen. 

Gängige Tools, die man für Scanning verwenden kann, sind u.a. die OpenSource Tools Trivy sowie Clair. Kommerzielle Tools, die z.B. auch einen erweiterten Support zur Verfügung stellen können oder weitere Funktionen haben, sind Snyk sowie JFrog.

Verwendet man Container-Scanning in seiner Infrastruktur, hat man den großen Vorteil, dass Schwachstellen noch vor dem Deployment entdeckt werden können. Auch ist das Container-Scanning in CI/CD-Pipelines automatisierbar und bietet so eine weitere Dosis Sicherheit. 

Software Supply Chain 

Nicht nur Betreiber, sondern auch Softwareanbieter benötigen ein Risikomanagement. Sicherheitsrelevante Fehler in genutzten Komponenten, Bibliotheken und Hilfstools können sich auch auf die ausgelieferte Software übertragen. Angriffe, die gezielt auf diese Vererbung der Sicherheitslücken abzielen, werden Software-Supply-Chain-Angriff genannt. 

Die reinen CVE-Nummern helfen den Softwareanbietern bei der Kommunikation. In ihren Release-Notes können sie ihren Kunden eindeutig aufzeigen, welche Schwachstellen (eigene und von Drittkomponenten geerbte) beseitigt wurden. Die Kunden können die Information dann mit ihrem eigenen Risikomanagement aus Betriebssicht abgleichen. Die CVE-Nummer kann aber auch gut genutzt werden, um aufzuzeigen, dass die eigene Software von einer konkreten Lücke nicht betroffen ist. So forderten beispielsweise bei der Log4Shell-Schwachstelle in der Log4j-Bibliothek viele große IT-Organisationen von ihren Zulieferern Negativbescheide, dass ihre Produkte von dieser Lücke nicht betroffen waren. 

Ähnlich wie die Scanner für Container gibt es auch Scantools, die über die Versionsstände von eingebundenen Dependencies ermitteln, ob eine neue Schwachstelle bekannt wurde. Nutzt man zum Verwalten der Abhängigkeiten einen Registry-basierten Ansatz (z.B. mit NPM), erhält man so leicht die notwendigen Informationen. Für händisch hinzugefügte Abhängigkeiten (z.B. JAR-Archiv, Binärbibliothek, JavaScript) gibt es ebenfalls Scanner, die teilweise Heuristiken einsetzen müssen, um den eindeutigen Namen der Bibliothek und die Versionsnummer zu bestimmen (z.B. RetireJS, Trivy). 

Exploits/Lücken nachvollziehen im Pentest / in der Incident Response 

Im Bereich von Penetrationstests, technischen Audits und Incident Response werden CVEs regelmäßig verwendet. Durch die eindeutige Benennung sprechen sowohl Kunden als auch Sicherheitsberatende über dieselbe Sicherheitslücke. Kunden erlaubt dies beispielsweise einfacher einzuschätzen, in welchen Versionen eine Sicherheitslücke eines eingesetzten Systemes vom Hersteller behoben wurde, da Changelogs der Hersteller und externe Quellen die CVEs zu betroffenen Versionen mappen. 

Ebenso werden anhand der CVE z.B. weiterführende Recherchen, sei es über Suchmaschinen, auf GitHub oder in dedizierten Vulnerability Databases, erleichtert. Es kann z.B. besser eingeschätzt werden, ob bereits öffentlich verfügbare Write-Ups, Exploits oder Proof-of-Concept Code existiert, der durch Angreifende verwendet werden kann. Im Incident Response kann dies als Indiz für die Ausgereiftheit der Angreifenden herangezogen werden. 

Gefundene Schwachstelle melden 

Bei der Meldung von Schwachstellen wird die gefundene Sicherheitslücke im Rahmen von Responsible Disclosure häufig bei einer CVE Numbering Authority (CNA) eingereicht, um für diese Lücke eine CVE zugewiesen zu bekommen. Da während des Prozesses der Meldung viele Parteien beteiligt sein können, z.B. die Entdeckenden der Lücke, die Herstellenden des Systems, die Personen, die das System einsetzen, oder auch Vermittelnde wie ein CERT, soll eine CVE dabei sicherstellen, dass von der gleichen Lücke gesprochen wird. Außerdem können alle Beteiligten den Fortschritt während des Prozesses der Responsible Disclosure effektiver verfolgen. Nach der Behebung einer Sicherheitslücke erlaubt eine veröffentlichte CVE der Öffentlichkeit, z.B. betroffenen Firmen, den Einfluss der Sicherheitslücke auf die eigenen Systeme zu beurteilen und ggf. Maßnahmen zu ergreifen. 

Alternativen 

Für diese Anwendungsfälle wollen wir uns jetzt mögliche Alternativen anschauen. Wir haben dabei die Ansätze ausgewählt, die in den Tagen um die drohende CVE-Abschaltung am breitesten diskutiert wurden. Einige der Ansätze sind aktuell noch nicht praktisch nutzbar oder zielen auch auf ein ganz anderes Anwendungsfeld ab. Wenn sie dennoch in der Diskussion Raum eingenommen haben, haben wir sie hier aufgegriffen. 

Das Original: MITRE CVE 

Betrieben von der Non-Government-Organization (NGO) MITRE Corporation, gilt das Common Vulnerabilities and Exposures (CVE) System als die Referenz in der Welt der IT-Sicherheit für Sicherheitslücken und Schwachstellen. Durch die Vereinheitlichung der Nummerierung von Sicherheitslücken ist jederzeit eindeutig, auf welcher Sicherheitslücke man sich bezieht.  

Dadurch ist das Kürzel “CVE” für einige auch schon zum Synonym für “Sicherheitslücke” geworden und wird meist auch mit den detaillierten Einträgen in CVE-basierten Datenbanken wie der NVD gleichgesetzt. Die CVE-Datenbank selbst enthält allerdings nur sehr wenige Informationen zur Lücke. Grundsätzlich gerade so viele Informationen, um die Lücke wiedererkennen zu können. Das Datenbankformat erlaubt auch Risikoeinschätzungen und andere Informationen, diese sind aber optional.  

Besondere Aufmerksamkeit bekam dieses System, nachdem die US-Regierung unter Trump im April 2025 die Finanzierung stoppte. Dieses System wird vom US-Heimschatzuministerium (DHS) sowie der untergeordneten Cybersecurity and Infrastructure Security Agency (CISA) unterstützt. Durch das Ziehen einer Optionsklausel im Vertrag der Förderung durch die US-Regierung, bleibt das MITRE CVE System bis 16.03.2026 am Start. Was danach passiert, kann niemand abschätzen. 

Dadurch, dass dieses System seit 1999 im Einsatz ist, hat es sich zum Standard entwickelt. Es ist daher die derzeit aktuellste, kompatibelste und vollständigste Lösung. 

Neu aufgedeckte Schwachstellen werden von den CVE Numbering Authorities (CNA) eingepflegt, nummeriert und verwaltet. Die Meldung erfolgt u.a. über ein eigenes Portal. Es können jedoch auch vorgefertigte sowie selbst programmierte Clients verwendet werden. Eine CVE kann bereits vor der Veröffentlichung beantragt werden, und für die Zuweisung erfolgt meist nur eine grobe Prüfung. Eine zugewiesene CVE bedeutet also nicht automatisch, dass ein tatsächliches Risiko besteht. Zu vielen CVEs werden keine Lücken veröffentlicht – so wurden z.B. 2023 ca. 40.000 CVEs reserviert, aber nur ca. 29.000 veröffentlicht. 

Die reinen CVE-Nummern bilden nur einen Teil der Anwendungsfälle ab, insbesondere liefern sie nicht unbedingt eine Risikobewertung. Sie bilden aber die Basis für viele darauf aufbauende Datenbanken wie die NVD. 

Wird oft mit CVE verwechselt: NIST National Vulnerability Database (NVD) 

Die National Vulnerability Database (NVD) wird von der US-Behörde NIST betrieben und oft mit CVE verwechselt. Beide sind auch eng miteinander verknüpft – für jede CVE im Zustand “veröffentlicht” wird automatisch ein Eintrag in der NVD erzeugt. Während die CVE-Datenbank nur rudimentäre Informationen zur Lücke enthält, wird der Eintrag in der NVD noch um weitere Informationen wie einen Risikoscore nach dem Industriestandard Common Vulnerability Scoring System (CVSS) oder Links zu weiteren Informationen ergänzt. 

Diese Informationen werden teilweise manuell ergänzt. Im Frühjahr 2024 kam es dabei zu einer Überlastung des zuständigen Teams, und es wurden für mehrere Monate keine Ergänzungen insbesondere auch keine Risikobewertungen eingepflegt. Durch den Einsatz von externen Partnern konnte der Stau aufgelöst und das System resilienter gemacht werden, aber wie bei CVE zeigt der Vorfall, wie stark die NVD vom amerikanischen Bundeshaushalt abhängt. 

Die NVD-Daten stehen auch als strukturierte Daten im Security Content Automation Protocol (SCAP) Format zur Verfügung und können ohne Einschränkungen verwendet werden. Daher setzen viele Tools und auch Schwachstellen-Webseiten die NVD-Daten direkt ein oder nutzen sie als Basisdatensatz, der durch eigene Erkenntnisse ergänzt wird. Da die NVD nicht zwingend genannt werden muss, ist der Zusammenhang nicht immer direkt erkennbar. 

Fast alle unserer Anwendungsfälle kann die NVD bedienen. Lediglich neue Lücken können nicht direkt bei der NVD gemeldet werden – hier muss eine CVE beantragt werden und damit entsteht automatisch auch der NVD-Eintrag. 

CVE Foundation 

Die Meldung, dass die US-Regierung die Förderung von MITRE CVE einstellen will, sorgte berechtigterweise für eine Menge Wirbel in der globalen Cybersecurity Szene. Angetrieben durch dieses Ereignis sowie dem schon länger existierenden Wunsch noch neutraler und nachhaltiger auftreten zu können (und nicht an eine Regierung gebunden zu sein) entschieden sich diverse Vorstandsmitglieder des CVE-Systems ihre eigene (non-profit) Stiftung zu gründen, um die Finanzierung des MITRE Programms zu realisieren. 

Die CVE Foundation ist daher keine Alternative zu bestehenden Programmen und will es nach unserem Kenntnisstand auch gar nicht werden. Aktuell befindet sich die Stiftung noch im Aufbau – Informationen dazu wie es weitergeht und was die nächsten Schritte sein werden, sind daher rar. In ihren eigenen FAQs werden lediglich einige Fragen zum Auftrag sowie einige der baldigen Vorstände benannt. 

Unsere Anwendungsfälle wären bei einer CVE-Stiftung genauso abgedeckt wie bisher. Wenn die Stiftung die bestehende Datenbank und Nummerierung übernehmen würde, gäbe es auch keinen Umstellungsaufwand. 

Common Security Advisory Framework (CSAF)

Ein weiterer Name, der in diesen Zusammenhängen immer wieder genannt wurde, ist das Common Security Advisory Framework (CSAF). Dahinter verbirgt sich eine technische Spezifikation für einen verteilten Ansatz. Eine vertrauenswürdige Instanz wie aktuell beispielsweise das Bundesamt für Sicherheit in der Informationstechnik (BSI) pflegt eine Liste von Organisationen, die Sicherheitslücken dokumentieren. Diese wiederum veröffentlichen die Sicherheitslücken in einem strukturierten Format (JSON). 

Laut der eigenen FAQ sieht sich CSAF nicht als CVE-Ersatz. Der Standard bietet ein optionales Feld für die CVE-Nummer an, und in der Technischen Richtlinie TR-03191 des BSI ist die CVE-Nummer sogar verpflichtend. In CSAF geht es eher um die Details zu jeder Lücke, man kann CSAF also eher als eine dezentrale Alternative zur NVD-Datenbank betrachten. 

Die Anwendungsfälle, in denen die Eindeutigkeit der CVE-Nummer im Vordergrund steht – z.B. als Ordnungsmerkmal im Risikomanagement oder als eindeutige Kennung in der Software Supply Chain – können von CSAF nicht abgebildet werden. CSAF-Dokumente haben zwar eindeutige Kennungen, aber zwei Dokumente können sich auf die gleiche Lücke beziehen. 

Als Informationsbasis und insbesondere als Datenbasis für Scan-Tools eignen sich die CSAF-Dokumente dagegen gut. Die CSAF-Seite verzeichnet direkt einige passende Tools. Es gibt jedoch keinen Automatismus wie bei der NVD, der für jede veröffentlichte CVE zumindest einen rudimentären Eintrag erzeugt. 

Global CVE Allocation System (GCVE)

Das Global CVE Allocation System (GCVE) ist ein neuer Ansatz vom Computer Incident Response Center Luxembourg (CIRCL), bei dem statt einer zentralen Instanz wie MITRE die Vergabe von IDs für Sicherheitslücken dezentral stattfinden soll. Zwar gibt es im traditionellen CVE-System auch verschiedene Vergabestellen für CVEs – sogenannte CVE Numbering Authorities (CNAs) – jedoch müssen die Vorgaben von MITRE eingehalten werden, und die Vergabe von eindeutigen IDs wird durch die zentrale Instanz gesteuert. Im GCVE wird die ID dazu im Format „GCVE-<GNA ID>-<YEAR>-<UNIQUE ID>“ vergeben. Jeder teilnehmenden Organisation wird eine sogenannte GNA ID zugeteilt, sodass die Organisationen ihren eigenen ID-Bereich unabhängig vergeben können, ohne Überschneidungen hervorzurufen. Es bleibt abzuwarten, ob die Anzahl der aktuell acht teilnehmenden Organisationen steigt und sich auch bekannte Größen dem im Aufbau befindlichen System anschließen. 

Für die oben definierten Anwendungsfälle ist es aktuell kaum nutzbar. Nur die vom CIRCL betriebene Datenbank Vulnerability Lookup benutzt derzeit das Schema.  

Da die Teilbereiche unabhängig verwaltet werden, wird es Lücken geben, die mehrere GCVE-Nummern von unterschiedlichen GNA erhalten werden. Die GCVE eignet sich dann nicht als eindeutiges Ordnungsmerkmal im Risikomanagement oder in der Software Supply Chain. 

European Vulnerability Database (EUVD) 

Eigentlich noch im Probebetrieb wurde die europäische Antwort auf die NVD im Zuge der drohenden CVE-Abschaltung kurzerhand öffentlich verfügbar gemacht. Die Datenbank ist noch in der Beta-Phase und soll vor allem die Korrelation aus verschiedenen Datenquellen ermöglichen.  

Da so auch Sicherheitslücken aufgenommen werden, die nicht bei der CVE gemeldet wurden, vergibt die European Network and Information Security Agency (ENISA) eigene Nummern, die mit EUVD starten. Aktuell ist das System auf eine Ko-Existenz und eine Abbildung auf CVEs ausgelegt, könnte aber bei einer CVE-Abschaltung auch problemlos weiterbetrieben werden. 

Während einzelne neuere Einträge bereits sehr viele Informationen aufweisen, konnten wir in Stichproben immer wieder Einträge finden, die entweder nur die Basis-Daten aus der CVE-Datenbank enthielten oder die im Vergleich zum korrespondierenden NVD-Eintrag viel weniger Details hatten. 

Die EUVD ist so ausgelegt, dass alle unsere oben beschriebenen Anwendungsfälle langfristig bedient werden können. Aktuell ist die Datenqualität noch nicht vergleichbar mit der NVD, und nur wenige Tools nutzen die EUVD als Datenbasis. Beides kann sich aber mit der Zeit noch ändern.  

Ob die EUVD-Nummern die etablierten CVE-Nummern als eindeutige Kennung ersetzen können, ist noch offen. Da die EUVD Teil der NIS2-Richtlinie der EU ist und von den europäischen Informationssicherheitsbehörden gemeinsam genutzt wird, stehen die Chancen aber zumindest für Europa nicht schlecht. 

Single Reporting Platform (SRP) des europäischen Cyber Resilience Act (CRA) 

Neben der NIS-2-Richtlinie, die vor allem auf den sicheren IT-Betrieb abzielt, macht die EU im Cyber Resilience Act (CRA) Informationssicherheitsvorgaben für Produkte. Darin sind auch Vorgaben wie Schwachstellen veröffentlicht werden sollen und welche Meldewege die Hersteller ermöglichen müssen. 

Eine neue geschaffene Single Reporting Platform (SRP) soll dabei eine zentrale Rolle spielen. Die Erstellung der Plattform wird gerade ausgeschrieben. Daher kann es noch keine konkrete Einschätzung geben, wie sich die SRP auf die Anwendungsfälle auswirkt. Bisher bekannt ist lediglich die Arbeitsteilung zwischen SRP und EUVD: Während die SRP auch unveröffentlichte Schwachstellen für einen beschränkten Empfängerkreis bereitstellen soll, sollen veröffentlichte Schwachstellen aus der SRP direkt in die EUVD aufgenommen werden. 

Was müssen Anwender jetzt tun? 

Bis März 2026 kann erstmal alles wie bisher bleiben. Es ist jedoch ratsam, sich bereits auf mögliche Alternativszenarien nach dem Datum vorzubereiten. 

Für die Nutzung der CVE als eindeutige Kennung (im Risikomanagement, als Hersteller, als Entdecker), kann man bereits jetzt anfangen, zusätzlich eine der alternativen Kennungen wie die EUVD-Nummer zu dokumentieren. Idealerweise spricht man mit Kunden und Lieferanten über die Alternativen und findet vielleicht eine gemeinsame Alternative. 

Bei den Scan-Tools und Informationsdiensten (fürs ISMS, Container, Software) sollte man rechtzeitig prüfen, auf welchen Daten sie basieren. Nutzen sie einfach die NVD oder binden sie bereits heute verschiedene Datenbanken (die nicht nur Kopien der NVD sind) an? Möglicherweise müssen Tools und damit die daran hängenden Prozesse ausgetauscht werden, um mehr Datenquellen nutzen zu können. 

Allgemein

HiGuide: EU CER RICHTLINIE (EU) 2022/2557

EU CER RICHTLINIE (EU) 2022/2557 des Europäischen Parlaments und des Rates über die Resilienz kritischer Einrichtungen und zur Aufhebung der Richtlinie 2008/114/EG des Rates.

EU Critical Entities Resilience (CER) Richtlinie vom 14. Dezember 202211

Die EU Critical Entities Resilience (CER) Direktive (EU) 2022/2557, die am zwanzigsten Tag (16. Januar 2023) nach ihrer Veröffentlichung im Amtsblatt der Europäischen Union (27. Dezember 2022) in Kraft getreten ist, richtet sich an alle EU-Mitgliedstaaten. Diese sind dazu verpflichtet, zur Resilienz von kritischen Einrichtungen bestimmte Maßnahmen zu ergreifen, damit sichergestellt werden kann, dass wichtige Dienste für die Aufrechterhaltung lebenswichtiger gesellschaftlicher Funktionen im Binnenmarkt ungehindert erbracht werden.

Die EU CER-Richtlinie wird in Deutschland als Gesetz zur Umsetzung der Richtlinie (EU) 2022/2557 und zur Stärkung der Resilienz kritischer Anlagen (Kritis-Dachgesetz, KritisDG) umgesetzt. Der aktuelle Gesetzesentwurf2 ist vom 27. November 2024.

Der Schwerpunkt der EU Richtlinie liegt auf verschiedene Sektoren und Teilsektoren. Des Weiteren werden die Kategorien der Einrichtungen berücksichtigt. Im Energie- und Verkehrssektor wurden bereits sektorspezifische Rechtsakte der EU geregelt. Die wichtigen Aspekte der Resilienz wurden aber nicht ausreichend in Betracht gezogen und um die Resilienz der kritischen Einrichtungen zu untersuchen, wurde diese EU-Richtlinie als ein allumfassender Rahmen geschaffen. Der Fokus liegt dabei stark auf alle natürlichen oder vom Menschen verursachten, unfallbedingten oder vorsätzlichen Gefahren.

Aufhebung der EU Richtlinie 2008/114/EG 

Das Verfahren in der aufgehobenen EU-Richtlinie 2008/114/EG über die Ermittlung und Ausweisung europäischer kritischer Infrastrukturen und die Bewertung der Notwendigkeit, ihren Schutz zu verbessern, adressierte die europäischen kritischen Infrastrukturen im Energie- und Verkehrssektor. Denn Störungen in den Sektoren hätten erhebliche Auswirkungen in mindestens zwei EU-Mitgliedstaaten bewirken können. In einer Evaluierung im Jahr 2019 wurde festgestellt, dass aufgrund von zunehmender grenzüberschreitender Nutzung von kritischen Infrastrukturen, Schutzmaßnahmen für einzelne Bereiche nicht allein ausreichen, um alle Störungen abwehren zu können. Daher wurde ein Ansatz genutzt, bei dem Risiken allumfassend berücksichtigt werden. Deshalb sollen die Aufgaben und Pflichten der kritischen Einrichtungen als Anbieter von Diensten genauer festgelegt werden und kohärent sein. Das ermöglicht den kritischen Einrichtungen, ihre Fähigkeiten und Kenntnisse zu stärken. Dies insbesondere in Bezug auf Erkennung von Sicherheitsvorfällen und das schützen, verhindern, abwehren, bewältigen und die Erholung von solchen Ereignissen.

Einige Maßnahmen wurden bereits auf EU- und nationaler Ebene berücksichtigt und umgesetzt. Dennoch sollte mehr getan werden, damit die Einrichtungen besser in der Lage sind, Risiken zu erkennen und zu handeln. Es wird von einer dynamischen Bedrohungslage ausgegangen, die sowohl hybride als auch terroristische Gefahren und hohe physische Risiken durch Naturereignisse und den Klimawandel umfasst. Die EU-Mitgliedstaaten haben die bisherige EU-Richtlinie nicht ausreichend umgesetzt, weshalb die EU dann aktiv wurde. Die EU CER-Richtlinie soll daher ein einheitliches Niveau schaffen, was die Einstufung der Sektoren angeht. Die bisherige Richtlinie 2008/114/EG war daher unzureichend, um die Ziele zu erreichen und wurde am 18. Oktober 2024 mit Einführung der EU CER-Richtlinie aufgehoben.

ANWENDUNGSBEREICH DER EU CER

Durch die Einführung der EU CER-Richtlinie erhalten die EU-Mitgliedstaaten Vorgaben zur Gewährleistung der Erbringung von Diensten im Binnenmarkt. Das ist insbesondere für die Aufrechterhaltung wichtiger gesellschaftlicher Funktionen oder wirtschaftlicher Tätigkeiten erforderlich. Zusätzlich müssen sie die relevanten kritischen Einrichtungen ermitteln und bei der Umsetzung der EU CER Vorgaben unterstützen.

Die EU-Mitgliedstaaten geben die Beaufsichtigung kritischer Einrichtungen, die Durchsetzungsmaßnahmen, die Ermittlung kritischer Einrichtungen und die Beratungsmissionen zur Bewertung der Maßnahmen vor. Es werden gemeinsame Verfahren für die Zusammenarbeit und Berichterstattung festgelegt. Ausgeschlossen von der Bereitstellung von Informationen der EU-Mitgliedstaaten sind die Bereiche der nationalen Sicherheit, der öffentlichen Sicherheit und die Verteidigung.

STRATEGIEN FÜR DIE RESILIENZ KRITISCHER EINRICHTUNGEN

Die EU-Mitgliedstaaten haben eine zeitliche Frist bis zum 17. Januar 2026, um eine Strategie zur Verbesserung der Resilienz kritischer Einrichtungen zu verabschieden. Die Inhalte der Strategie soll Ziele und politische Maßnahmen umfassen, um ein hohes Resilienzniveau von kritischen Einrichtungen zu festigen und aufrechtzuhalten.

Grundsätzlich enthält jede Strategie wesentliche Elemente, die umgesetzt werden müssen. Zunächst sollen strategische Ziele und Prioritäten zur Verbesserung der Gesamtresilienz kritischer Einrichtungen etabliert werden, unter der Berücksichtigung grenzüberschreitender und sektorübergreifender Abhängigkeiten sowie gegenseitiger Abhängigkeiten. Darüber hinaus sollen Steuerungsrahmen der EU-Mitgliedstaaten festgelegt werden, um die strategischen Ziele und Prioritäten zu verwirklichen. Die Beschreibung der Maßnahmen und des Verfahrens zur Ermittlung der kritischen Einrichtungen ist ebenfalls umzusetzen.

Die jeweiligen Behörden haben Aufgaben und Zuständigkeiten, die beschrieben werden sollen. Das gilt ebenfalls für die kritischen Einrichtungen und die an der Strategie beteiligten Akteure. Zusätzlich sollen die Maßnahmen beschrieben werden, die dazu beitragen, die Gesamtresilienz zu verbessern. Dazu zählt auch das Beschreiben der Verfahren zur Ermittlung kritischer Einrichtungen sowie die Beschreibung der Prozesse zur Unterstützung kritischer Einrichtungen. Maßnahmen zur Verbesserung der Zusammenarbeit zwischen dem öffentlichen Sektor und dem privaten Sektor sind weitere Punkte, die umgesetzt werden sollen.

Eine Dokumentation der wichtigsten Behörden und entsprechenden Interessenvertreter, die an der Umsetzung der Strategie beteiligt sind, soll geführt werden. Zwischen den Behörden der EU CER und den Behörden der EU NIS-2 Richtlinie (EU) 2022/2555 soll es einen politischen Rahmen für die Zwecke des Informationsaustauschs über Cybersicherheitsrisiken, Cyberbedrohungen und nicht cyberbezogene Risiken geben.

Die EU-Mitgliedstaaten sind verpflichtet ihre Strategie alle vier Jahre zu aktualisieren und der EU-Kommission diese Strategien und die Aktualisierungen innerhalb von drei Monaten nach Verabschiedung mitzuteilen.

RESILIENZ UND RESILIENZMASSNAHMEN KRITISCHER EINRICHTUNGEN

Um zu erkennen, welche Risiken die wesentlichen Dienste stören könnten, sollen die kritischen Einrichtungen mindestens alle vier Jahre eine Risikobewertung durchführen. Bei einer bereits vorhandenen Risikobewertung kann diese für die Erfüllung der Anforderungen der EU CER-Richtlinie verwendet werden. Um den Anforderungen der EU CER-Richtlinie gerecht zu werden, haben die zuständigen Behörden die Aufgabe, zu prüfen und zu bestätigen, dass die bereits vorhandene Risikobewertung die gegebenen Anforderungen erfüllt. Bei erfolgreicher Erfüllung der Anforderungen, kann die zuständige Behörde offiziell anerkennen, ob die Vorgaben ganz oder teilweise umgesetzt wurden. Die Maßnahmen zur Gewährleistung der Resilienz der kritischen Einrichtungen soll geeignet, verhältnismäßig, technisch, sicherheitsbezogen und organisatorisch sein. In dem sogenannten Resilienzplan sollen die Maßnahmen beschrieben und angewendet werden. Die kritischen Einrichtungen sollen einen Verbindungsbeauftragten als Ansprechperson für die zuständigen Behörden benennen, während die EU-Kommission Beratungsmissionen organisiert, um die kritischen Einrichtungen zu unterstützen. Außerdem erlässt die EU-Kommission unverbindliche Leitlinien, in denen technische, sicherheitsbezogene und organisatorische Maßnahmen festgelegt sind.

MELDUNG VON SICHERHEITSVORFÄLLEN

Nach einem Sicherheitsvorfall müssen die EU-Mitgliedstaaten sicherstellen, dass die kritischen Einrichtungen der zuständigen Behörde rechtzeitig den Vorfall melden. Die erste Meldung soll spätestens 24 Stunden nach dem Auftreten und Bemerken des Sicherheitsvorfalls übermittelt werden.

Nach einem Monat soll es einen ausführlichen Bericht über den Sicherheitsvorfall geben. Dabei soll die Anzahl der von der Störung betroffenen Nutzenden, die Dauer der Störung und das betroffene geografische Gebiet der Störung berücksichtigt werden. Im Fall, dass der Sicherheitsvorfall in mehr als sechs EU-Mitgliedstaaten erhebliche Auswirkungen hatte, wird der Sicherheitsvorfall von den zuständigen Behörden der EU-Kommission gemeldet.

Die Meldung des Sicherheitsvorfalls muss entsprechende Informationen enthalten, so dass die zuständige Behörde über die Art, Ursache und die möglichen Folgen nachvollziehen und ermitteln kann. Darüber hinaus muss sie auch Informationen enthalten, die insbesondere für die Bestimmung erforderlich sind, ob der Vorfall grenzüberschreitende Auswirkungen hat. „Solche Meldungen begründen keine höhere Haftung der betreffenden kritischen Einrichtungen.“3 

Die betroffenen kritischen Einrichtungen werden nach der Meldung des Vorfalls von den zuständigen Behörden über sachdienliche
Folgeinformationen informiert, damit sie unterstützt werden. Die zentralen Anlaufstellen tragen die Verantwortung für die Sicherheit der Informationen, indem sie sich an das Unionsrecht halten oder die Informationen nach nationalem Recht behandeln.

1 https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32022L2557
2 https://dserver.bundestag.de/btd/20/139/2013961.pdf
3 EU CER Richtlinie 2022/2557 vom 14.Dezember 2022 (Art.15 Abs.2 S.2)

Allgemein, Penetrationstest, Risikomanagement

USB-Schnittstellen unter Windows absichern

Im Rahmen von Windows Client Audits untersuchen wir, ob Härtungsmaßnahmen gegen typische Angriffe über USB-Schnittstellen umgesetzt wurden. Grundsätzlich kann ein Angreifer ungeschützte USB-Schnittstellen zum Ausleiten von Daten (Exfiltration) oder zum Einleiten/Ausführen von Daten bzw. Code missbrauchen.

Das Ausleiten von Daten über USB (TA0010) geschieht typischerweise durch den Anschluss eines Wechselmediengeräts, wie z. B. Speichersticks oder externe Festplatten (T1052). Jedoch können ebenso eher untypische Geräte wie externe CD/DVD-Laufwerke angeschlossen werden, die zur Exfiltration von Daten missbraucht werden können.

Externe Hardware birgt gleichwohl die Gefahr, dass darüber Daten bzw. Schadcode auf das Client-System gelangt und dort ausgeführt wird (TA0002). In der Praxis kann dies bspw. ein mit Malware präparierter USB-Speicherstick sein, welcher von unachtsamen Mitarbeitern angeschlossen und dessen Inhalt anschließend ausgeführt wird (T1059). Alternativ kann der Angriff über ein „BadUSB“-Device erfolgen (T1204). Ein typischer Vertreter dieser Gattung ist der sogenannte RubberDucky. Dabei handelt es sich um eine als USB-Speicherstick getarnte Tastatur, welche in der Lage ist, vorprogrammierte Tastatureingaben automatisiert und in schneller Abfolge auszuführen. Die Größe der Daten, die mittels RubberDucky auf das System „übertragen“ werden können, ist zwar beschränkt. Es ist jedoch problemlos möglich, Schadcode aus dem Internet nachzuladen und diesen auf dem Client zur Ausführung zu bringen.

Um den Risiken der Datenaus- und -einleitung zu begegnen, bietet Windows verschiedene Möglichkeiten, welche nachfolgend vorgestellt werden.

  1. Lese- und Schreibe-/Schreibzugriff auf Wechselmedien einschränken: Nutzer können zwar Wechselmedien-Geräte anschließen jedoch wird der Lese- oder/und Schreibzugriff auf Medien beschränkt.
  2. Installation von Wechselmedien-Geräten beschränken: Die Installation von Gerätetreibern bestimmter Wechselmedien-Geräteklassen, bspw. WPD-Geräte (Smartphones), wird unterbunden. Dadurch ist keine Nutzung dieser mehr möglich.
  3. Installation von Tastaturen beschränken: Die Installation von Gerätetreibern für unbekannte Tastaturen wird unterbunden. Angriffe durch BadUSB-Geräte, welche Tastaturen simulieren, ist dadurch nicht mehr möglich.

Die folgende Grafik stellt den Zusammenhang zwischen Angriffstaktiken bzw. -techniken und den passenden Maßnahmen noch einmal visuell dar:

Ausnutzung des Angriffsvektors "USB-Schnittstelle" und Schutzmaßnahmen

In diesem Artikel erfahren Sie, welche Einstellungen Sie vornehmen müssen, um die genannten Beschränkungen über Active-Directory-Gruppenrichtlinien unternehmensweit auszurollen.

1. Lese- und Schreibe-/Schreibzugriff auf Wechselmedien einschränken

Beim Begriff „Wechselmedium“ denkt man meist als erstes an USB-Speichersticks oder externe Festplatten. Tatsächlich sind diese in der Windows-Welt jedoch nur zwei Vertreter der Wechselmedienklasse „Wechseldatenträger“. Windows unterscheidet insgesamt zwischen diesen fünf Wechselmedienklassen:

  1. CD und DVD
  2. Diskettenlaufwerke
  3. Wechseldatenträger (z. B. USB-Sticks, externe Festplatten)
  4. Bandlaufwerke
  5. WPD-Geräte (z. B. MTP-fähige Geräte wie Smartphones)

In Penetrationstests stellen wir häufig fest, dass Kunden nur den Zugriff auf die offensichtliche Wechselmedienklasse „Wechseldatenträger“ eingeschränkt haben. Dadurch lassen sich zwar keine Daten von USB-Sticks transferieren, jedoch ist es weiterhin möglich, bspw. externe CD- und DVD-Laufwerke anzuschließen, um darüber Daten auszutauschen.

Wenn Sie den Lese- oder Schreibzugriff auf Wechselmedienklassen hinreichend beschränken wollen, müssen Sie dies für alle (ihren Unternehmensrichtlinien entsprechenden) Wechselmedienklassen tun. Folgen Sie den nachfolgenden Schritten, um Lese- und Schreibzugriffe auf Wechselmedien über Active-Directory-Gruppenrichtlinien zu verwalten:

  1. Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
  2. Navigieren Sie zum Pfad:
    Computerkonfiguration -> Administrative Vorlagen -> System -> Wechselmedienzugriff
  3. Die sicherste Methode ist es, den Lese- und Schreibzugriff auf alle Wechselmedienklassen zu unterbinden. Aktivieren Sie dazu die Einstellung „Alle Wechselmedienklassen: Jeglichen Zugriff verweigern“:
  • Möchten Sie lediglich Schreiboperationen auf Wechselmedien verhindern, aktivieren Sie stattdessen die Option „Alle Wechselmedienklassen: Schreibzugriff verweigern“.

Überprüfen Sie den Zugriff auf ein Wechselmedium Ihrer Wahl, z. B. einen USB-Speicherstick, in dem Sie diesen an den Windows Client anschließen und versuchen, Daten zu schreiben und zu lesen.

Häufig stehen Administratoren allerdings vor dem Dilemma, dass zwar der Anschluss von beliebigen Wechselmedien unterbunden werden soll, es jedoch Ausnahmen geben muss. Eine typische Anforderung ist, dass der Windows Client den Anschluss beliebiger Wechselmedien unterbinden muss, es sei denn, es handelt sich um einen USB-Speicherstick der Marke / des Modells „XYZ“.

Um dies umzusetzen, muss die Gerätetreiber-Installation von Wechselmedienklassen beschränkt werden. Mehr dazu im folgenden Abschnitt.

2. Installation von Wechselmedien-Geräten beschränken

Falls Sie den Anschluss von unerlaubten Wechselmedien verhindern möchten, bietet es sich an, die Gerätetreiber-Installation unbekannter Wechselmedien-Geräte zu deaktivieren. Dadurch werden diese nicht mehr vom Windows gemountet und können folglich nicht geschrieben oder gelesen werden. Lediglich Geräte, deren Hardware-ID hinterlegt wurde, können noch angeschlossen und verwendet werden (Whitelisting-Ansatz). Die hinterlegte Hardware-ID kann sich z. B. auf ein bestimmtes Gerät, ein Model oder einen Hersteller beziehen.

Gehen Sie dazu wie folgt vor:

  1. Bestimmen Sie die Hardware-ID des Wechselmediengeräts, deren Installation Sie zulassen möchten.
    Schließen Sie bspw. den USB-Speicherstick an einen Windows Client an, und öffnen Sie den Gerätemanager (devmgmt.msc). Suchen Sie den USB-Speicherstick unter dem Reiter „Laufwerke“. Öffnen Sie dessen Eigenschaften. Wechseln Sie zu Details -> Hardware-IDs und notieren Sie eine der IDs.
    Im folgenden Beispiel haben wir uns für USBSTOR\DiskJetFlash entschieden, da wir alle Modelle des USB-Speichersticks freigeben wollen, auch die mit einer anderen Speichergröße als 8 GB:
  1. Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
  2. Navigieren Sie zum Pfad:
    Computerkonfiguration -> Administrative Vorlagen -> System -> Geräteinstallation -> Einschränkungen bei der Geräteinstallation
  3. Aktivieren Sie die Option „Anwenden einer übergeordneten Reihenfolge für Zulassen und Verhindern-Geräteinstallationsrichtlinien für alle Geräteübereinstimmungskriterien“. Regulär wird zunächst die Installation von Geräten verboten und dann erlaubt (deny, allow). Durch die Aktivierung dieser Eigenschaft wird die Reihenfolge auf „allow, deny“ umgekehrt.
  4. Aktivieren Sie die Option „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die folgenden GUID-Werte, einschließlich der geschweiften Klammern, ein (GUID-Übersicht):
    • {4d36e965-e325-11ce-bfc1-08002be10318} (CD- und DVD-Laufwerke)
    • {4d36e980-e325-11ce-bfc1-08002be10318} (Diskettenlaufwerke)
    • {4d36e967-e325-11ce-bfc1-08002be10318} (Laufwerke für Wechseldatenträger, wie z. B. USB-Speichersticks oder externe Festplatten)
    • {6d807884-7d21-11cf-801c-08002be10318} (Bandlaufwerke)
    • {eec5ad98-8080-425f-922a-dabf3de3f69a} (WPD-Geräte, wie z. B. Smartphones)

Hinweis: Wechselmedien-Geräte die vor dem Aktivieren der Einstellung installiert wurden, können auch danach weiter genutzt werden. Wenn Sie dies verhindern möchten, aktivieren Sie die Einstellung „Auch auf übereinstimmende Geräte anwenden, die bereits installiert sind“. Wir empfehlen diese Einstellungen nur mit Vorsicht zu verwenden, da dies dazu führen kann, das bestehenden Verbindungen zu wichtigen externen Datenträgern nicht mehr funktionieren!

Hinweis 2: Die Empfehlung aus der offiziellen Microsoft-Dokumentation nur die GUIDs {36fc9e60-c465-11cf-8056-444553540000} (USB-Host-Controller und USB-Hubs) und {88BAE032-5A81-49f0-BC3D-A4FF138216D6} (USB-Geräte die nicht zu einer anderen Klasse gehören) hier einzutragen, ist unvollständig. Dadurch können bspw. weiterhin WPD-Geräte, wie Smartphones, angeschlossen werden. Wir empfehlen daher die oben genannten Geräteklassen-GUIDs zu verwenden.

  1. Aktivieren Sie die Option „Installation von Geräten mit diesen Geräte-IDs zulassen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die Hardware-ID(s) ein, welche Sie zulassen möchten (siehe Schritt 1):

Die finale Konfiguration sollten nun wie folgt aussehen:

Prüfen Sie, ob die Einstellung Wirkung zeigt, in dem Sie einen zweiten USB-Speicherstick (mit abweichender Hardware-ID) anschließen, den Sie zuvor noch nie an das System angeschlossen haben. Das Gerät sollte daraufhin nicht installiert werden.

Sollten sich der Speicherstick wider Erwarten installieren lassen, öffnen Sie den Geräte-Manager und suchen Sie den angeschlossene Speicherstick unter „Laufwerke“. Klicken Sie mit der rechten Maustaste auf den Eintrag und wählen Sie „Gerät deinstallieren“:

Dadurch wird der gerade installierte Treiber wieder deinstalliert. Danach können Sie das Gerät abziehen.

Prüfen Sie anschließend Ihre vorgenommenen Einstellungen auf Korrektheit und probieren Sie erneut, den Speicherstick anzuschließen.

3. Installation von Tastaturen beschränken

Geräte die sich als USB-Tastaturen ausgeben, wie der allseits bekannte RubberDucky, um dadurch bösartige Eingaben durchzuführen und Code nachzuladen, stellen ebenfalls ein Risiko dar. Bei diesen „BadUSB“-Angriffen handelt es sich um einen Seitenkanal-Angriff, bei dem die Fähigkeiten von Keyboard-Devices dazu missbraucht werden, Daten und Code auf dem Zielgerät zu platzieren bzw. zur Ausführung zu bringen.

Vor dem Anschluss von BadUSB-Geräten kann man sich schützen, indem man wie im vorigen Kapitel auch, eine Liste für den Anschluss zugelassener Tastaturen im Windows hinterlegt (Whitelisting) und den Anschluss anderer Tastaturen verbietet.

Um den Anschluss von Tastatur-Geräten einzuschränken, gehen Sie wie folgt vor:

  1. Bestimmen Sie die Hardware-ID der Tastatur, deren Installation Sie zulassen möchten.
    Öffnen Sie den Gerätemanager (devmgmt.msc). Suchen Sie die angeschlossene Tastatur unter dem Reiter „Tastaturen“. Öffnen Sie deren Eigenschaften. Wechseln Sie zu „Details -> Hardware-IDs“ und notieren Sie sich die Hardware-IDs der Tastaturen, die sie freigeben möchten. In der folgenden Abbildung ist dies ID HID\VID_046A&UP:0001_U:0006, was einer beliebigen Cherry-Tastatur entspricht. Um die Installation von beliebigen Logitech-Tastaturen zu erlauben, müsste bspw. die ID HID\VID_046D&UP:0001_U:0006 (mit einem „D“  statt einem „A“) freigegeben werden:
  1. Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
  2. Navigieren Sie zum Pfad:
    Computerkonfiguration -> Administrative Vorlagen -> System -> Geräteinstallation -> Einschränkungen bei der Geräteinstallation
  3. Aktivieren Sie die Option „Anwenden einer übergeordneten Reihenfolge für Zulassen und Verhindern-Geräteinstallationsrichtlinien für alle Geräteübereinstimmungskriterien“. Regulär wird zunächst die Installation von Geräten verboten und dann erlaubt (deny, allow). Durch die Aktivierung dieser Eigenschaft wird die Reihenfolge auf „allow, deny“ umgekehrt.
  4. Aktivieren Sie die Option „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier den Wert {4D36E96B-E325-11CE-BFC1-08002BE10318} ein. Dieser entspricht die GUID der Geräteklassen „Tastaturen“ (GUID-Übersicht).

Hinweis: Tastaturen, die vor dem Aktivieren der Einstellung installiert wurden, können auch danach weiter genutzt werden. Wenn Sie dies verhindern möchten, aktivieren Sie die Einstellung „Auch auf übereinstimmende Geräte anwenden, die bereits installiert sind“. Wir empfehlen diese Einstellungen nur mit Vorsicht zu verwenden, da dies dazu führen kann, dass bspw. auch integrierte Laptop-Tastaturen nicht mehr verwendet werden können!

  1. Aktivieren Sie die Option „Installation von Geräten mit diesen Geräte-IDs zulassen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die Hardware-ID(s) ein, welche Sie zulassen möchten (siehe Schritt 1):

Prüfen Sie, ob die Konfiguration Wirkung zeigt, in dem Sie eine von ihrer Hardware-ID abweichende Tastatur (oder einen RubberDucky) anschließen, die Sie zuvor noch nie an das System angeschlossen haben. Das Gerät sollte nicht installiert werden.

Sollte sich die Tastatur dennoch anschließen und bedienen lassen, gehen Sie wie am Ende von Kapitel „Installation von Wechselmedien beschränken“ beschrieben vor, um den Gerätetreiber wieder zu deinstallieren.

Quellen:

Anleitung zur Beschränkungen von USB-Schnittstellen:

Taktiken und Techniken aus dem MITRE ATT&CK Framework:

Hak5 RubberDucky:

WPD und MTP:

Hardware-IDs:

Geräteklassen-GUIDs:

Allgemein, Forensics

Wie funktioniert eigentlich Malware auf Handys?

Dass einige Staaten unliebsame Journalisten und Oppositionelle über Mobilgeräte überwachen, ist mittlerweile keine große Neuigkeit mehr. Oftmals wird die israelische Firma Cellebrite in dem Kontext genannt. Wie genau dieser Prozess abläuft, wird von Amnestys SecurityLab [1] am Beispiel NoviSpy beschrieben. Neben den technischen Details, die natürlich für die IT-Security Community spannend sind, ist insbesondere die Art der initialen Kompromittierung fundamental für die Entwicklung des eigenen Threat Models.

Werden Mobilgeräte (oder überhaupt technische Geräte) durch einen Dritten in einen anderen Raum geschafft, beispielsweise bei einer Grenzkontrolle, so kann man davon ausgehen, dass diese Geräte möglicherweise kompromittiert sind. Erst nach ausreichender Untersuchung sollten solche Geräte wiederverwendet werden. Warum diese Untersuchungen nicht durch Hersteller wie Apple angeboten werden, kann man auf techcrunch [2] nachlesen.

Bei IT-Sicherheit wird oft als Erstes an Windows-Clients, Firewalls und Ransomware gedacht. Aber unsere kleinen Taschencomputer haben einen oft unterschätzten Anteil an unserem täglichen Leben, sei es privat oder bei der Arbeit. Auch dort sollte das Thema Sicherheit bedacht werden.

[1] https://securitylab.amnesty.org/latest/2024/12/serbia-a-digital-prison-spyware-and-cellebrite-used-on-journalists-and-activists/

[2] https://techcrunch.com/2024/12/20/why-apple-sends-spyware-victims-to-this-nonprofit-security-l

Allgemein

Lageberichte und Erkenntnisse aus dem Jahr 2024

Wie jedes Jahr beglücken uns das BSI und ähnliche Organisationen mit ihren Lageberichten und Erkenntnissen. Welche Defekte in diesem Jahr besonders häufig in Software festgestellt wurden, kann man der Top 25 CWE (Common Weakness Enumeration) von MITRE entnehmen.

Ein beunruhigender Trend ist die ungewöhnlich häufige Nutzung von 0-day-Schwachstellen durch Ransomware-Gruppen. So kommt nun zu der mittlerweile hoffentlich bekannten Empfehlung, Patches zeitnah einzuspielen, die Frage hinzu, wie man mit 0-days umgeht. Eine Lösung: Security by Design. Auch wenn es sich dabei meist um sicheres Architekturdesign im Software Engineering handelt, kann und sollte dieses Prinzip beim Thema Netzwerkarchitektur ebenfalls bedacht werden. Im Rahmen einer Risikoanalyse werden für jede Komponente die Gefahr einer Kompromittierung und weiteren Bewegung möglicher Angreifer erörtert und entsprechende Maßnahmen getroffen. Oftmals hört man in diesem Kontext Begriffe wie „Zero Trust“ und „Defense-in-Depth“. Die so erreichte Resilienz schützt auch gegen bisher unbekannte Lücken in vielfältig ausgenutzten Komponenten wie z. B. VPN-Zugängen.

Gerade in Deutschland konnten wir auch erleben, welche Auswirkungen diese Angriffe auf die Supply-Chain und Dienstleister haben. Der Vorfall bei der Südwestfalen-IT ist zwar nicht der erste seiner Art, mit circa 1,7 Millionen Betroffenen aber einer der Größeren. Mit der zunehmenden Digitalisierung wächst auch die Abhängigkeit und damit die mögliche Auswirkung solcher Angriffe. Nicht umsonst möchte der Gesetzgeber mit NIS-2 gegensteuern.

Es bleibt abzuwarten, ob sich diese Trends im Jahr 2025 fortsetzen werden, oder ob uns etwas ganz Neues überraschen wird. Klar ist, dass IT-Sicherheit auch im nächsten Jahr ein wichtiges Thema bleibt.

https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Lageberichte/Lagebericht2024.pdf?__blob=publicationFile&v=5

Allgemein

SAP auf Allzeithoch Drängt Kunden in die Cloud 

Von Lorenz Müller, HiSolutions AG 

SAP strukturiert weiterhin massiv um: Für die SAP Business Suite ist die Nachfolgerin SAP S/4HANA längst da. Das Ende der Mainstream-Wartung naht, die Migration scheint unausweichlich. Und mit der Fokussierung auf die Cloud stellt sich SAP selbst neu auf. 

Die Dynamik, mit der SAP seine Konzern- und Produktpolitik betreibt, beeindruckt. On-Premise-Angebote wurden drastisch verteuert – auch, um SAP-Kunden in die Cloud zu drängen. Mit dem Private Cloud-Komplettpaket RISE with SAP und mit Grow with SAP für Public Cloud bietet SAP eine neue Form der Cloud-Transformation an. Das Subskriptionsmodell bringt Kunden in eine Dauerabhängigkeit und generiert SAP beständig profitable Umsätze. Das flexiblere Lizenzmodell stellt Cloud- gegenüber On-Premise-Kunden deutlich besser. Dabei sind die Vertragsmodelle wie auch die Transformation selbst hochkomplex und bieten viele Risiken und Nebenwirkungen – bis hin zum notwendigen IT-Umbau. 

Die Ankündigung, Innovationen wie die Nutzung künstlicher Intelligenz und Nachhaltigkeitsreporting nur noch in den SAP-eigenen Cloudangeboten gegen Mehrpreis zur Verfügung zu stellen, düpierte und verunsicherte Kunden wie Partner. Die Folge: Noch mehr Druck, den Wechsel in die SAP-Cloud anzugehen. 

Offenbar sind bisher weniger zu SAP S/4HANA migriert als geplant. Die Cloud-Angebote wurden nicht im erwünschten Umfang angenommen. Bereits getätigte Investitionen in On-Premise-Software wurden nicht angerechnet, bis Anfang 2024 der nächste Schachzug in Form eines neuen Bonus- und Rabattprogramms folgte: Mit „RISE with SAP Migration and Modernization“ sollen Kunden eingeladen werden, eine Cloud First-Geschäftsstrategie auf SAP-Basis zu entwickeln.

Unaufhaltsam verstärkt SAP weiter den Druck: Bereits seit September letzten Jahres erhalten viele Kunden über die Standardrabatte hinaus nicht mehr die in der Vergangenheit regelmäßig gewährten zusätzlichen Rabatte. SAP will mit dieser De-Facto-Verteuerung Bestandkunden den Erwerb benötigter On-Premise-Lizenzen zusätzlich vergällen und zum Umstieg auf SAP RISE Cloudlösungen bewegen – und damit den Profit erhöhen. Neukunden wurde der Erwerb von On-Premise-Lizenzen mit Hinweis auf die Cloudangebote bereits mehrfach verwehrt. 

Inzwischen hat SAP das RISE-Umstiegsprogramm durch Verlängerung des Eilzuschlags noch attraktiver gestaltet: Bei Abschluss eines entsprechenden Vertrags bis Ende September 2024 gibt es zusätzlich zu den 45 % für ECC-Kunden (max. 3 Mio. €) bzw. 60 % für S/4-Kunden (max. 6 Mio. €) Migration Credit als Gutschriften, weitere 25 % Turbo-Uplift – was im Einzelfall sehr viel Geld sein kann!  Dazu kommen oft noch hohe Subventionen der Hyperscaler. Über 5.200 Kunden haben nach aktuellen Angaben von SAP bereits Private-Cloud -SAP-Verträge abgeschlossen. 

Wenn Sie noch nicht in fortgeschrittenen Gesprächen mit SAP sind, ist ein Vertragsabschluss bis September 2024 kaum realistisch. Wir empfehlen Ihnen dennoch unbedingt, sich kurzfristig mit RISE/GROW with SAP auseinanderzusetzen, um mögliche wirtschaftliche und strategische Nachteile für Ihr Unternehmen zu vermeiden – zumal das Programm bis Ende 2024 begrenzt ist. 

Der SAP-CEO Christian Klein betreibt seit mehr als einem Jahr auch die Umgestaltung des Unternehmens – hin zu mehr Public Cloud, zu KI – und zum Abbau von 10.000 „Altjobs“. Primär, um den Börsenwert von SAP signifikant zu erhöhen, und um seinen Job zu retten. Denn die Unzufriedenheit der Beschäftigten von SAP steigt: Fast die Hälfte traut Klein laut aktueller Befragung nicht mehr zu, SAP in die Zukunft zu führen. 
Dafür gibt es mehrere Gründe: Der Vorstandschef führt autoritär, beordert die Belegschaft zurück ins Büro und will ein Bewertungssystem einsetzen, um Low Performer zu identifizieren. SAP steckt in der Transformation. All das kannten die erfolgsverwöhnten SAP´ler bislang so nicht.  

10.000 langjährig SAP-erfahrene (und vermutlich kritische) Mitarbeiter freizusetzen zugunsten günstigerer, unerfahrener und loyaler Mitarbeiter – wie wird das SAP verändern? Wo es doch bereits heute für Kunden schwierig ist, qualifizierten Support und Weiterentwicklung der Software zu erhalten, da erfahrene Ressourcen fehlen. 

Ab 2025 rechnet SAP mit rund 200 Millionen Euro weniger Kosten als bisher geplant. Dadurch soll auch das Ergebnis vor Zinsen und Steuern (Ebit) entsprechend steigen: SAP plant nun mit 10,2 Milliarden Euro, bislang waren es 10,0 Milliarden. 

Die Produktstrategie von Christian Klein ist klar: In aktuellen Präsentationen wird immer mit Grow with SAP die Public Cloud als Ziel gesetzt, RISE with SAP als Übergang, sofern Grow (noch) nicht möglich ist. Und dazu KI. 

Die Börse hat dies alles und auch die euphorischen Quartalsergebnisse des 2. Quartals honoriert (das operative Ergebnis stieg um 33 % auf 1,94 Milliarden Euro – ein Plus von 33 %). Analysten hatten lediglich mit einem Anstieg um 24 % gerechnet: der Börsenkurs ist in den letzten 12 Monaten um fast 60 % auf nahezu 200 € pro Aktie gestiegen.  

SAP-Cloud oder passendere Alternativen? Prüfen Sie zeitnah! 

Vor dem neuen Programm gab es beim Abschluss von Cloud-Verträgen nie Anrechnungen für getätigte On-Premise-Lizenzkäufe – daher verändert dies das Momentum nun nochmal deutlich zugunsten von RISE with SAP. 

Die SAP SAM-Experten von HiSolutions haben in den letzten Jahren viele Unternehmen beim Wechsel in die SAP-Cloud begleitet. Andererseits erwies sich bei einer mindestens ebenso großen Zahl von Kunden die SAP-Cloud als nicht wirtschaftlich oder unpassend. Daraufhin wurden gemeinsam zukunftsfähige Alternativen gesucht, gefunden, bewertet und auf den Weg gebracht. 
Dies ist hochkomplex. Es berührt die elementaren Grundlagen Ihrer IT und Ihres Unternehmens. Es geht dabei um Millionen. Die meisten Unternehmen haben für diese einmalige Transaktion nicht die erforderliche Erfahrung und Expertise.  Darum ist Rat und Unterstützung von seriösen und erfahrenen SAP Lizenz- und -Vertragsberatern einzuholen. 
Sprechen Sie gerne mit uns: kostenfrei, unverbindlich – und ohne Risiken und Nebenwirkungen. 

Lorenz Müller 

– Principal ITM – 

____________________________________________ 

HiSolutions AG | Schloßstraße 1 | 12163 Berlin            

Fon: +49 30 533 289-0 | Fax: +49 30 533 289-900 I Mobil: +49 173 3756895 

lmueller@hisolutions.com| https://www.hisolutions.com            

Mindestinformationen im geschäftlichen E-Mail-Verkehr nach § 80 AktG: 

Sitz der Gesellschaft / registered office: HiSolutions AG, Schloßstraße 1, 12163 Berlin 

Handelsregistereintrag / Commercial register: Amtsgericht Berlin Charlottenburg – HRB 80155 

Vorstand / Management Board: Torsten Heinrich, Prof. Timo Kob, Michael Langhoff 

Vorsitzender des Aufsichtsrates / Chairman of the supervisory board: Dr. Andreas Resch

Allgemein

Sind 17 Jahre noch Echtzeit?

Linux und Echtzeit – für einige ist das ein Widerspruch, während andere schon seit Jahren die Real-Time-Linux-Patches nutzen. Hintergrund ist, dass der Hauptzweig des Linux-Kernel über die Jahre zwar viele Änderungen für Echtzeitfähigkeit erfahren hat, aber ohne die separat gepflegte Patch-Sammlung harte Echtzeitanforderungen nicht garantiert werden konnten. Im September ist jetzt ein großer Teil dieser Patches in den Hauptzweig übernommen worden und damit ein viele Jahre währender Prozess nah ans Ziel gekommen.

Es gibt allerdings immer noch Spezialfälle, in denen nicht garantiert werden kann, dass der Kernel alles stehen und liegen lässt, um auf ein Ereignis innerhalb der vorgegebenen Zeit reagieren zu können. Es stehen also noch weitere Entwicklungsaufwände an, die vor allem durch eine fehlende Finanzierung ausgebremst werden. Denn obwohl schon jetzt viele Hersteller Echtzeit-Linux in ihren Geräten nutzen, kommt nicht genug Geld bei den Entwicklern an.

Diese Diskrepanz zwischen der Wertschöpfung der Nutzer von Open-Source-Software und der Finanzierung der Entwicklung ist eine grundsätzliche Herausforderung für das Open-Source-Ökosystem. Mit Stiftungen wie der Linux Fundation wird dagegen gesteuert. Mit dem Sovereign Tech Fund gibt es in Deutschland sogar ein staatlich finanziertes Unterstützungsangebot, das auch die Verbesserung der Sicherheit zum Ziel hat. Dabei gibt es verschiedene Angebote von Bug-Bounty-Programmen bis zu Stipendien für Entwickler.

Die „Contribute Back Challenge“ richtet sich an Open-Source-Software einsetzende Firmen, die ihren Mitarbeitern Zeit für die Weiterentwicklung einräumen. Das lohnt sich natürlich vor allem, wenn man ohnehin eine eigene Entwicklungsabteilung unterhält. Aber unabhängig von der Challenge kann man auch schon mit kleinen Beiträgen etwas zurückgeben: vom Ausprobieren von Testversionen bis hin zur aktiven Teilnahme in den Online-Communities.

Haben Sie sich schon einmal in Ihrem Unternehmen umgeschaut, ob Sie in der Open-Source-Community aktive Kollegen haben?

P.S.: Eine Reaktion nach 17 Jahren kann übrigens nach der formalen Definition Echtzeit sein, etwa wenn die garantierte Reaktionszeit 20 Jahre war.

Advisories, Allgemein, Penetrationstest, Schwachstelle

Schwachstelle öffnet Türen in mehr als 3.000 Hotels

Es mag bequem klingen: Die Zimmertür im Hotel lässt sich ganz ohne Schlüssel oder Karte vom Smartphone aus entriegeln. Doch was passiert, wenn die Logik eines solchen Systems nicht ausreichend abgesichert ist?

Zimmertüren von Hotels aus über 25 Ländern ließen sich mit einer neu entdeckten Schwachstelle öffnen. Bequem? Ja, über das Internet und ohne Zugangsdaten. Dazu konnten sämtliche Reservierungsinformationen (u. a. Name, E-Mail, Reservierungszeitraum und Raumnummer) eingesehen werden. Doch wie kam es dazu?

Zusammenfassung

Die Firma straiv ist ein innovativer und digitaler Begleiter für Hotelbranchen. Als solcher bieten sie unter anderem Online-Check-ins und digitale Türöffnungen an. Was den Sicherheitsforschern Björn Brauer, Deniz Adrian und David Mathiszik bei einem Hotelbesuch jedoch auffiel: Angreifenden wäre es dank einer fehlerhaften Zugangskontrolle in der API möglich, den Check-in und das Öffnen von Türen auch ohne Autorisierung über das Internet zu bedienen.

Im Rahmen einer vertraulichen Offenlegung (engl. Responsible Disclosure oder auch Coordinated Vulnerability Disclosure – CVD) wurden die technischen Details daraufhin direkt an den Hersteller übermittelt. straiv reagierte zeitnah und behob die Sicherheitslücke in ihrer Anwendung umgehend.

Dank ihres Software-as-a-Service-Ansatzes konnte das Unternehmen das Sicherheitsrisiko zeitgleich für alle Kunden mitigieren. Es wird daher auch keine CVE-ID für diese Schwachstelle vergeben. Die Veröffentlichung der Schwachstelle erfolgt in Abstimmung mit dem Hersteller frühestens einen Monat nach der erfolgreichen Behebung.

Die Ursache: Broken Access Control

Broken Access Control belegt aktuell Platz 1 unter den beliebtesten (lies: häufigsten) Schwachstellen in Webanwendungen (siehe: A01:2021 – OWASP Top 10). Auch hier war eine fehlerhafte Zugriffskontrolle die Ursache.

Für gewöhnlich erhalten Gäste eine E-Mail mit einem Link zu ihrer Reservierung. Über diesen werden sie auf die Webanwendung von straiv weitergeleitet. Dort können Buchungsinformationen, die Reisedaten und alle Begleiterprofile eingesehen werden. Ein weiterer Menüreiter führt zu den digitalen Zimmerschlüsseln. Darüber kann die Zimmertür während des eigenen Buchungszeitraums gesteuert werden. Dies geschieht über die API von straiv.io.

Normale API-Anfragen schienen mindestens durch einen HTTP-Header (X-Token), einen Code (cryptcode) und die Reservierungsnummer (reservation) geschützt zu werden. Wurde auch nur einer der Werte verändert, so wurde der Zugriff erwartungsgemäß verwehrt. Fehlten jedoch alle Werte gleichzeitig, wurde nur noch die Reservierungsnummer interpretiert.

In der folgenden beispielhaften Anfrage wurden sämtliche Authentifizierungsparameter, bis auf die Reservierungsnummer, leer gelassen und die API antwortete dennoch mit Informationen zur Reservierung.

POST /api/v2/auth HTTP/2
Host: start.straiv.io
X-Token:
X-Code:
X-Version: 12.3.0
Content-Type: application/json
{
    "cryptcode":"",
    "platform":"linux",
    "browser":"Firefox",
    "version":"115.0",
    "tokens":[],
    "reservation":"3XXXXX"
}

Das Ergebnis enthielt neben anderen Informationen auch einen validen token, der für weitere API-Anfragen genutzt werden konnte.

So lieferte der folgende API-Aufruf noch mehr Kundendetails:

GET /api/v2/vblo/pms/reservation?reservation_id= HTTP/2
Host: start.straiv.io
Accept: application/json, text/plain, */
X-Token: sXXXXXXXXXXXXXXXXXXXh
X-Code: XXXX
X-Version: 12.3.0

Statt die API zu verwenden, kann auch die remote_url aus der Antwort der ersten API-Anfrage verwendet werden, um bequem über die Webanwendung auf die Reservierung zuzugreifen:

HiSolutions hat keine Enumeration von Nutzerdaten durchgeführt und über das Abschätzen der Auswirkungen dieser Schwachstelle hinaus nicht mit der API oder den Buchungen interagiert. Prinzipiell standen alle Funktionalitäten des legitimen Benutzers uneingeschränkt zur Verfügung.

Mitigation

Für die Kunden von straiv bestand kein weiterer Handlungsbedarf. Die Sicherheitslücke wurde von den Entwicklern ernst genommen und umgehend geschlossen.

Grundsätzlich lassen sich Fehler dieser Art durch folgende allgemeine Empfehlungen verhindern:

  • Vertrauen Sie keinen Nutzereingaben – validieren Sie diese.
    Verlassen Sie sich nie auf die Gültigkeit von jeglichen Werten, die von den Endbenutzern beeinflusst werden können. Dazu gehören auch Cookie-Werte, Anfragenparameter und HTTP-Header. Auch auf serverseitig gespeicherte Informationen sollte nich blind in allen Kontexten vertraut werden.
  • Überprüfen Sie Gültigkeit aller Werte serverseitig. Weisen Sie leere oder ungültige Authentifizierungsinformationen zurück. Achten Sie bei der Implementierung von Tests auf eine vollständige Abdeckung aller Randszenarien (ein, mehrere oder auch alle Werte sind unerwartet, NULL, nicht definiert, vom falschen Typ, etc.).
  • Verwenden Sie starke Authentifizierungsmethoden.
    Implementationen sind stets abhängig von der Anwendung und dem Kontext. Greifen Sie, wenn möglich, auf bewährte und praxiserprobte Bibliotheken und Authentifizierungslösungen zurück. Verwenden Sie besonders in Bezug auf sensitive Informationen Zwei-Faktor-Authentifizierung. Stellen Sie zudem sicher, dass alle automatisch generierten Schlüssel, Codes und Token nicht leicht zu erraten und somit vor Brute-Force-Angriffen geschützt sind (vgl. UUID v4).
  • Durchsatzbegrenzung (engl. Rate Limiting) der API-Anfragen:
    Begrenzen Sie die mögliche Anzahl der Anfragen von einzelnen Systemen, um dem Missbrauch, wie der schnellen Enumeration von gültigen Reservierungen, vorzubeugen.

In ihrem Update hat straiv mindestens eine Anfragenbegrenzung aktiviert und Reservierungsnummern auf ein nicht-erratbares Format geändert.

Wie HiSolutions helfen kann

HiSolutions bietet spezialisierte Penetrationstests für Webanwendungen und Infrastrukturen an. Hierbei greifen wir auf langjährige Erfahrung zurück und kombinieren die Fähigkeiten modernster Scantechnologien mit manuellen Prüfverfahren, um die bestmögliche Testabdeckung zu gewährleisten.

Stellen Sie sicher, dass Schwachstellen gefunden und behoben werden, bevor Sie ausgenutzt werden können und kontaktieren Sie uns unter +49 30 533 289 0 oder dem Kontakformular für ein kostenloses Erstgespräch.

Koordinierte Veröffentlichung

  • 22.05.2024 HiSolutions sammelt Details zur Schwachstelle.
    Finder: Björn Brauer, Deniz Adrian & David Mathiszik
  • 23.05.2024 HiSolutions informiert betroffene Hotelkette und wird an straiv weitergeleitet.
  • 25.05.2024 straiv vereinbart einen Termin für die Übermittlung aller Details.
  • 04.06.2024 HiSolutions teilt alle Details mit straiv.
  • 06.06.2024 straiv veröffentlicht ein Update und HiSolutions bestätigt den Fix.
Allgemein, Digital Workplace, ITSM

Wofür braucht es XLA’s am Digital Workplace? 

Für Digital Workplace Leader besteht die Aufgabe, die optimale Arbeitsumgebung für Mitarbeiter zu schaffen. XLA’s sind eine Möglichkeit, die täglichen Anforderungen des Mitarbeiterteams besser nachzuvollziehen.  

Der Wassermelonen-Effekt 
Doch was tun, wenn die SLA-Kennzahlen grün leuchten, aber die Mitarbeiter dennoch mit den IT-Diensten am Arbeitsplatz unzufrieden sind? Dieses Phänomen wird als „Wassermelonen-Effekt“ bezeichnet: Auf der Oberfläche scheint alles in Ordnung zu sein – Hardware und Software sind ausreichend vorhanden, die Kennzahlen zeigen Erfolg, die Tools passen – aber in Wahrheit fühlen sich Mitarbeiter durch Ihren Arbeitsplatz unmotiviert und frustriert. Vor allem dann, wenn sie nicht wissen, wie sie ihre Unzufriedenheit bei den üblichen SLA-Umfragen im Unternehmen ausdrücken sollen. Von der Technik her scheint doch alles zu passen? 

Die Problematik der negativen Employee Experience ist, dass sie einen tieferen Ursprung hat als SLAs dies messbar machen. Erfüllte KPIs (Key Performance Indicators), die hinter den SLAs stehen, messen die allgemeine IT-Leistung.  Darunter zählt unter anderem die Verfügbarkeit der IT-Systeme, die Reaktionszeit des Service Desk etc. Durch die Vorgehensweise der SLAs werden nur Kennzahlen dar geben, somit können keine subjektiven Eindrücke der Mitarbeiter im Arbeitsalltag widergespiegelt werden. Um den qualitativen Eindruck aus Mitarbeitersicht messbar zu machen, bieten XLAs (Experience Level Agreements) den nächsten Baustein zu den bestehenden SLAs.  

Anwender vs. Anforderungen 

Was sich in SLAs nicht abbilden lässt, ist die Frustration oder Begeisterung am Arbeitsplatz:  


Office 2016, ein bereits veraltetes Softwarepaket, wird im Unternehmen genutzt. Mitarbeiter verwenden dieses und konzipieren zusammen mit dem Kunden eine PowerPoint-Folie. Zeittechnisch halten die Mitarbeiter Deadlines ein, schicken dem Kunden neue Entwürfe und sehen den Arbeitsfortschritt positiv. Schon bald ruft der Kunde jedoch an und beschwert sich darüber, dass seine Kommentare in zurückgeschickten Entwürfen nicht abgearbeitet werden, während er mit weiteren Entwürfen überflutet wird.   
 
Der Kunde besaß im Gegensatz zu den Mitarbeitern des Unternehmens das neueste Office 2023. Die Kommentare des Kunden im zurückgeschickten Entwurf wurden auf der alten Version aus 2016 im Layout nicht sichtbar angezeigt. Eine peinliche Situation, die an fehlendem Innovationsmanagement im Unternehmen gebunden war. In halbjährlichen SLA-Umfragen ist so ein Einzelfall aufgrund des quantitativen Messverfahrens gar nicht erst messbar. Also bleibt es bei den 10 Punkten Zufriedenheit unter „Programmverfügbarkeit am Arbeitsplatz“. Das Programm war jederzeit nach SLA-Anforderungen abrufbar; welche Qualität in der User-Experience lag, ist daran nicht abbildbar. 

 
Das Beispiel ist an SLAs die sich auf die Reaktionszeit der IT beziehen gespiegelt anwendbar. Häufig sieht das Unternehmen die Einhaltung von SLAs der internen IT kritischer, als es diese ist. Das bedeutet das Unternehmen steckt Unmengen an Geld in die interne IT welche blitzschnelle Reaktionszeiten auf Tickets und Notfälle aufweist. Das aufgrund einer Menge bereitstehendem Personal. 

Erstmal ist das definitiv eine positive Eigenschaft, jedoch stellt sich schnell die Frage, ob das bei einer internen IT überhaupt nötig ist. Bei externen Service Desks von Mobilfunkanbietern, Versicherungen oder Banken besteht, vor allem bei Security Incidents, die Prämisse immer IT-Personal auf Bereitschaft zu haben. Dort ist das Interesse und die Nachfrage danach nachvollziehbar groß, da diese auch mit dem Verkaufsfaktor der Dienstleistung verknüpft ist. 

Doch eine IT, die sich um Softwareausfälle und kaputte Hardware innerhalb des Büros kümmert, blüht im Unternehmen auch schon bei einem Level von “es klappt schon” auf. Wenn diese dann auch mal ein größeres Problem löst, steigt sie in den Augen des Büros schnell vom Underdog zum Helden auf.  

Ein weiterer Psychologischer Effekt ist die falsche Erwartungshaltung, die sich daraus bildet, dass die IT auf jedes kleine Problem ad hoc innerhalb kürzester Zeit reagiert. “Die haben jetzt aber schnell reagiert!” – und wenn das mal nicht der Fall ist, dann Ernüchterung doppelt so groß und die Beschwerden ebenso.  

Diese beiden Beispiele zeigen eine klare Problematik auf, wie findet man das Maß an Anforderung der Mitarbeiter? 

Was sind XLA’s? 

Um solche noch harmlosen Vorfälle zu verhindern, muss man schnell erkennen, welche Unzufriedenheiten sich in Ecken von Unternehmen breit machen. Dabei dienen die qualitativen Messverfahren der XLAs als Ansatzpunkt für Führungskräfte.  

XLA’s (Experience Level Agreements) sind Vereinbarungen, die die Benutzerzufriedenheit nach qualitativen Messverfahren analysieren und optimieren. Während SLA (Service Level Agreements) sich auf technische und betriebliche Leistungsmetriken konzentrieren sowie vertraglich Verfügbarkeitszeiten von Services festlegen. XLA’s den Fokus auf die Wahrnehmung und das Erlebnis des Endbenutzers, um ein umfassenderes Bild der Servicequalität zu bieten. Sie berücksichtigen die emotionale Reaktion der Benutzer auf die erbrachten Dienstleistungen.   

Die Verknüpfung zu den vorher bestehenden SLA’s am Arbeitsplatz besteht darin, dass XLA die Erweiterung oder Ergänzung zu SLA’s darstellen und durch die XLA-Auswertungen auch Anpassungen an den SLA und KPIs resultieren können und sollten.  

Was heißt qualitativ messen 

XLAs und SLAs arbeiten zusammen. SLAs legen vertraglich fest, inwiefern technische Services im Unternehmen verfügbar sein müssen. Dazu zählt die Erreichbarkeit des Ticket System der IT und die durch SLAs festgelegten Rückmeldezeiten der IT beim User. Durch SLAs wird sichergestellt, dass eine Dienstleistung in einem gegebenen Rahmen vorhanden ist und erfüllt wird.  

XLAs wiederum beschäftigen sich mit der Erfahrung rund um die Dienstleistung, der Employee-Experience (Mitarbeitererfahrung) in unsrem Beispiel des Digital Workplace. Darauf baut die Abschätzung zukünftiger Bedürfnisse auf, welche dazu dient, die positive Arbeitserfahrung am Arbeitsplatz zu fördern. Im Beispiel der IT und des gelösten Tickets spielt der Fokus nicht, wie schnell wurde das Problem durch die IT gelöst, sondern wie fühlte sich der User? Wurden im Alternativen in der Arbeitsweise bereitgelegt? Wie nahm er den Umgang mit seinem Problem durch die IT auf? 

Um XLAs in der Organisation effektiv anzuwenden, gibt es unterschiedliche Herangehensweisen. Im Falle der Employee-Experience kann ähnlich wie bei halbjährlichen SLA-Umfragen ein separater XLA-Bogen verteilt werden, bei dem auf die subjektiven Erfahrungen der Mitarbeiter rund um den Arbeitsplatz eingegangen wird. Dazu gehört auch die vorherige Abschätzung von neu aufkommenden Bedürfnissen in der Belegschaft. Beispielhaft sollte instinktiv gefragt werden:  

  • Braucht Ihr Guides für eure neuen oder auch alten Tools?   
  • Wie hätten wir das Onboarding besser gestalten können?  
  • Welches Programm fehlt euch im Unternehmen?  
  • Welche noch nicht bestehenden Funktionen wünscht ihr euch?  
  • Welches Projekt lief eurer Meinung nicht gut, obwohl es erfolgreich war?   

Hierbei ist nicht nur die klassische, häufig übersprungene Frage: „Sonstiges?“ Im Fragebogen gleichzusetzen. Es muss sich in die Lage der User versetzt werden, noch besser: Key User werden in der Konzipierung des Abfragemodells einbezogen.  

Wie funktionieren XLA im Unternehmen?  

Mechanismen wie der CES (Customer Effort Score), welcher die Anstrengung für die Erreichung eines Ziels durch den User beschreibt, oder der CSAT (Customer Satifaction) welcher die Zufriedenheit mit einer Dienstleistung misst, sind mögliche Ansatzpunkte, um XLAs einzubinden. Diese können quantitativ (Skalen oder Rangordnung fokussierte Fragebögen) sowie qualitativ (Textfeld Antworten welche komplexe, subjektive und detaillierte Begründungen zu spezifischen Fragen ermöglichen) gemessen werden. Hierbei setzen die Rahmenbedingungen um die Messung den Fokus auf individuelle Erfahrungen der Mitarbeiter. Dabei gibt es beispielsweise folgende Umsetzungsmöglichkeiten:  

Post-Interaction-Surveys: Nach jeder Interaktion zwischen IT und Mitarbeitern gibt es eine Befragung per Fragebogen, dessen Fragen sich an den Beispielen aus dem Kapitel „Was heißt qualitativ messen“ orientieren. In der Entwicklung des Surveys ist es von oberster Wichtigkeit, sich in die Lage der Mitarbeiter zu versetzen – noch besser, diese gleich bei der Entwicklung des Fragebogens einzubinden. Somit entwickeln sich Fragestellungen, die subjektiven Erfahrungen messbar machen und möglichen Beschwerden entgegenkommen.  

Interview in Fokusgruppen: Mitarbeiter und IT nehmen sich in Gruppen den eigenen Digital Workplace vor und analysieren diesen nach Ihren jeweiligen Vorstellungen, Anforderungen und Erfahrungen. Somit bildet sich ein gegenseitiges Verständnis im Arbeitsalltag bei Problembewältigung der IT. Dazu gelingt die konkrete Umsetzung von Wünschen bei Mitarbeitern durch den direkten Kontakt mit der IT leichter.  

Dies sind nur zwei beispielhafte Möglichkeiten. Für die konkrete Verwendung von XLAs zum Fördern des Digital Workplace und Förderung der Employee Experience sollte man nicht mit Kanonen auf Spatzen schießen. Das heißt, die eigene IT sowie die Mitarbeiter müssen an den Prozess, der Beantwortung von subjektiven Erfahrungen langsam herangeführt werden. Die Entwicklung der nötigen Strukturen für eine Befragung der Employee Experience selbst braucht eine eigene Instanz im Unternehmen. Der nötige Arbeitsaufwand kann nicht nebenbei zu täglichen Geschäftsprozessen von einem Team bewältigt werden.  Das liegt daran, dass der Fokus auf einzelne Bereiche im Unternehmen hin und her schwanken kann. Ebenso die spezifischen Fragestellungen immer angepasst werden müssen und sich stetig ändernde Technologien das Mitarbeiterumfeld prägen.  

Die nötigen internen SLAs zwischen IT und den Mitarbeiterteams müssen dazu auch bereits bestehen, das Service Design ausgearbeitet und die Strukturen der Teams im Unternehmen und deren Beziehung zur IT einsehbar sein.  Touchpoints an verschiedenen Stellen im Unternehmen wie am Headdesk, dem Service Desk, dem Onboarding und der IT selbst sind Brennpunkte für XLA-Befragungen, da genau dort die meisten subjektiven Erfahrungen zustande kommen.  

 
XLA an Touchpoints 

Um XLA’s im Arbeitsalltag anzuwenden, muss man sich langsam an die Thematik herantasten und Stück für Stück umsetzen. Nach einer Analyse des Unternehmens und dessen Geschäftsprozesse, kann festgehalten werden, welche Touchpoints Mitarbeiter intern am häufigsten haben. Bei Ticketschließungen, Onboardings und Restrukturierungen in der Organisation braucht es ein System, welches in kurzer Zeit Schlüsselerfahrungen der Mitarbeiter festhält.   

Kurzabfragen nach Ticketschließung, persönliche Gespräche, Feedbackrunden, individualisierte Emails – all das bietet die Chance, neues über Mitarbeiterbedürfnisse zu erfahren. Von gewünschten Tools, Ablaufänderungen, Problemlösungsvorschläge und Lob, die Outcomes sind genauso vielfältig wie die Möglichkeiten Mitarbeiter abzufragen.  

Wichtig ist, dass hierbei nicht nur die Regelmäßigkeit mit den Touchpoints eine Rolle spielt, sondern viel mehr auch die Kritikalität in der Mitarbeitererfahrung mit diesen. Verstehen kann man das in einem Vergleich: Der Ausfall einer viel genutzten Software im Unternehmen trifft die Mitarbeiter im Arbeitsalltag und Arbeitsvorschritt schwerer als der leere Obstkorb im Pausenraum. Beides wird eine negative Erfahrung für Mitarbeiter darstellen, doch die erstere hat breitere Auswirkungen. Genau während und nach solchen Krisen lohnt es sich in der Organisation zu fragen: „Wie nehmt Ihr die Situation um die Lösung des Softwareausfalls wahr? Findet Ihr Alternativen in der Arbeitsweise?“ Schlussendlich geht es bei der Mitarbeitererfahrung nur um eines, die stetige Verbesserung dieser. 

Unser Bezug 

Bei der nötigen Definition und Entwicklung von SLAs und der Schaffung einer Grundstruktur in der IT des Unternehmens bietet HiSolutions drei Jahrzehnte Erfahrung an. Dies dient als idealer Grundbaustein für die folgende Förderung der Employee Experience durch die Implementierung von XLAs – ohne in diesem zeitaufwendigen Prozess die interne IT zu strapazieren.

Allgemein, Incidents, Risikomanagement, Security Engineering

Wie ITSM die NIS2 Compliance unterstützt 

Mit der Einführung der NIS2-Richtlinie, die eine Umsetzung in nationales Recht bis zum 18.10.2024 vorsieht, werden Unternehmen dazu verpflichtet, angemessene Maßnahmen zur Gewährleistung der Cybersicherheit zu ergreifen. Im Rahmen des IT Service Managements (ITSM) sind verschiedene Aspekte von NIS2 von Bedeutung, um die Compliance sicherzustellen und die Cybersicherheit zu stärken. 

Die Umsetzung der EU-Richtlinie in deutsches Recht wird aktuell immer weiter verschoben. Im aktuell öffentlichen Entwurf des deutschen NIS2-Umsetzungsgesetzes steht zwar weiterhin der 01.10.2024 als Beginn der Umsetzungspflicht, aber aktuelle Gerüchte weisen darauf hin, dass die Verabschiedung des Gesetzes sich auch über dieses Datum hinaus verzögern könnte.  

Über drei Jahrzehnte Erfahrung von HiSolutions in der IT-Management- und Informationssicherheitsberatung zeigen, dass die in NIS2 geforderten Maßnahmen und deren wirksame Umsetzung sehr zeitaufwändig sein können. Unsere Empfehlung bleibt deshalb, sofort auf Basis der bereits jetzt verfügbaren Informationen wie den jetzigen EU-Vorgaben, dem aktuellen Entwurf des deutschen Umsetzungsgesetzes sowie gängigen Standards und BSI-Vorgaben zu handeln. 


Mit diesem Übersichtsartikel bauen wir einen Leitfaden auf. Dieser soll auch Unternehmen, die zum ersten Mal regulatorisch erfasst werden, eine Einführung in die Best Practices im IT Service Management bieten. Zukünftige Artikel zur Vertiefung behandeln folgende NIS2-relevante Handlungsfelder: 

  1. Behandlung von Sicherheitsvorfällen 

Unternehmen müssen Prozesse zur Erkennung, Meldung und Behandlung von Sicherheitsvorfällen implementieren. NIS2 legt fest, dass Organisationen Sicherheitsvorfälle innerhalb bestimmter Fristen melden und angemessene Maßnahmen zur Eindämmung und Behebung ergreifen müssen. Daher müssen Unternehmen entsprechende Incident Management Prozesse etablieren, um Sicherheitsvorfälle effektiv zu bearbeiten und die Auswirkungen auf ihre IT-Dienste zu minimieren.  

Aus Sicht des IT-Service Managements sind hier der Service Desk, bei dem Endanwender mit Meldungen zu Sicherheitsvorfällen ankommen, der Incident Management Prozess, der eng mit dem Security Incident Prozess verzahnt sein sollte sowie die Maßnahmen rund um das Logging und Monitoring von Systemen involviert. 

  1. Business Continuity 

NIS2 fordert von Unternehmen die Entwicklung von Business-Continuity-Plänen, um die Verfügbarkeit kritischer Dienste auch während und nach Sicherheitsvorfällen sicherzustellen. Im IT Service Management werden aus dem Business Continuity Management (BCM) die entsprechenden IT Service Continuity Management (ITSCM) Maßnahmen abgeleitet. Das ITSCM ist wiederum eng mit dem Availability und dem Capacity Management verbunden. Um ein ITSCM effektiv zu gestalten, sind Grundlagen aus dem Service Configuration Management notwendig. 

  1. Auslagerungsmanagement 

Unternehmen, die kritische Dienste an externe Dienstleister auslagern, müssen sicherstellen, dass diese Dienstleister angemessene Sicherheitsmaßnahmen implementieren. NIS2 legt fest, dass Unternehmen die Verantwortung für die Sicherheit ihrer ausgelagerten Dienste nicht delegieren können. Im ITSM bedeutet dies, dass Unternehmen geeignete Mechanismen für das Auslagerungsmanagement etablieren müssen, um sicherzustellen, dass externe Dienstleister die Anforderungen an die Cybersicherheit erfüllen. Die entsprechenden Maßnahmen werden im Supplier sowie im Service Level Management definiert. 

  1. Security Awareness 

Die Sensibilisierung der Mitarbeiter für Cybersicherheit ist ein zentraler Bestandteil der NIS2-Compliance. Unternehmen müssen Schulungsprogramme zur Sicherheitsaufklärung durchführen, um das Bewusstsein und Verständnis für Sicherheitsrisiken zu fördern. Im ITSM ist es wichtig, Security Awareness Trainings in die laufenden Schulungsaktivitäten zu integrieren, um sicherzustellen, dass Mitarbeiter die Bedeutung von Cybersicherheit verstehen und entsprechend handeln. Dabei hat der Service Desk eine Nähe zu den Anwendern und das Relationship Management zu den Kunden, was für die Etablierung und Durchführung von Security Awareness Maßnahmen genutzt werden kann. 

  1. Risikoanalyse 

Eine kontinuierliche Risikoanalyse ist entscheidend für die Identifizierung und Bewertung von Sicherheitsrisiken gemäß den NIS2-Anforderungen. Unternehmen müssen Risikomanagementprozesse implementieren, um potenzielle Bedrohungen zu erkennen und geeignete Gegenmaßnahmen zu ergreifen. Im ITSM sollten Unternehmen regelmäßige Risikobewertungen durchführen und angemessene Sicherheitskontrollen implementieren, um Risiken zu minimieren und die Compliance sicherzustellen. Dies geschieht im Bereich Risk Management. 

  1. Übergreifende Practices 

NIS2 hat weitreichende Auswirkungen auf verschiedene Aspekte des ITSM und erfordert eine integrierte Herangehensweise an die Cybersicherheit. Dies geschieht durch die Best Practices im Information Security Management und wird durch das Infrastructure and Plattform Management gestützt. Unternehmen müssen sicherstellen, dass ihre ITSM-Prozesse und -Praktiken die Anforderungen von NIS2 erfüllen und eng mit anderen Compliance-Richtlinien und -Standards wie z. B. ISO 27001 abgestimmt sind. Durch eine ganzheitliche Herangehensweise können Unternehmen die Cybersicherheit stärken und die Einhaltung der Vorschriften im IT Asset/Deployment Management sicherstellen. Das dafür notwendige Change Management wiederum bezieht sich auf bewährte Prozesse und Methoden zur systematischen Planung, Steuerung und Umsetzung von Veränderungen in IT Systemen und Services. Ziel ist es, Änderungen kontrolliert und effektiv zu verwalten, um Risiken zu reduzieren und die Zuverlässigkeit der IT Services zu erhöhen. 

NIS kommt: Wir unterstützen Sie bei der Umsetzung. 
Der neue NIS2-Kompass von HiSolutions zeigt Ihnen in einer schnellen Selbstauskunft, ob Ihre Organisation von NIS2 betroffen ist und was Sie tun müssen.