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

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.

Mehr als nur ein Versionsupdate: Die ISO/IEC 27001:2022

Im Oktober 2022 wurde die zentrale ISO-Norm zur Informationssicherheit aktualisiert. Die meisten Betroffenen haben sich vermutlich schon davor mit den Neuerungen beschäftigt. Aber nach einem Quartal in der Praxis ist eine erste Zwischenbilanz möglich. Zwei Neuerungen kristallisieren sich als typische Herausforderungen heraus: zum einen die Anforderung, die Bedrohungsentwicklung aktiv zu beobachten (Threat Intelligence), um auf strategischer, taktischer wie operativer Ebene reagieren zu können. Zum anderen bildet die jetzt nachzuweisende Cloud-Strategie für viele ebenfalls eine neue Challenge.

Die wichtigsten Änderungen: https://www.youtube.com/watch?v=53uwJY-mrIg

Cloud-Strategie: https://www.youtube.com/watch?v=nVlppw4EDuc

Keine Gaudi: Fast Super-Cloud-GAU bei Microsoft

Bei Microsoft ist eingetreten, wovor sich viele Cloud-Anbieter insgeheim fürchteten: Getroffen hat es Azure mit seiner Cosmos DB, einer beliebten NoSQL-Datenbank. Das Datenbankmanagement wird dabei ganz im Sinn von PaaS weitgehend von Microsoft übernommen.

Nun haben Sicherheitsforscher eine Schwachstelle in der Funktion Jupyter-Notebook entdeckt. Dieses Feature war erst im Februar diesen Jahres durch Microsoft aktiviert worden. Der Vorgang zeigt, wie wichtig es ist, die Konfiguration in allen genutzten Cloud-Diensten beständig im Blick zu behalten und gerade neue Features sicherheitstechnisch kritisch zu bewerten.

Die Entdecker WIZ Research haben zur Schwachstelle folgendes Video erstellt:

Eine Webseite mit Informationen zur Schwachstelle ist hier zu finden: https://chaosdb.wiz.io/

Laut Microsoft kam es glücklicherweise nicht zu einem aktiven Ausnutzen dieser Schwachstelle, siehe folgende Stellungnahme:

Positiv hervorzuheben ist, dass nur zwei Tage nach Meldung der Sicherheitslücke das betroffene Jupyter-Notebook-Feature durch Microsoft deaktiviert wurde, sowie der offene Umgang mit der Schwachstelle.

Fix Once, Secure Everywhere

Dies zeigt einen weiteren Vorteil der Cloud: Wenn eine Schwachstelle im Zuständigkeitsbereich des Cloud-Anbieters liegt, muss diese in der Regel nur durch den Cloud-Anbieter gefixt werden. Auf der anderen Seite ist dies auch ein Unterscheidungsmerkmal in Bezug auf Anbieterqualität: Nur ein Cloud-Anbieter, der schnell reagiert, bietet den Kundendaten entsprechenden Schutz.

CV? Neee…

Leider gibt es – anders als für Schwachstellen in Anwendungen und Betriebssystemen – keine dedizierte Datenbank für Schwachstellen in Cloud-Diensten. Denn CVE-Nummer werden nur vergeben, wenn die die Software durch den Kunden kontrollier- bzw. installierbar ist (https://cloudsecurityalliance.org/blog/2018/08/13/cve-cloud-services-part-1/).

Blitze-Wolke

HAFNIUM-Schwachstellen: Office 365/Microsoft 365/AD FS indirekt auch bedroht

[GTranslate]

Von Inés Atug, Markus Drenger und Daniel Jedecke.

Nach der Veröffentlichung des Out-of-Band-Patches für die als HAFNIUM bekannt gewordenen Schwachstellen in Exchange Servern haben viele Admins, die zuvor eine Migration nach Office 365 (jetzt Microsoft 365) durchgeführt hatten, aufgeatmet. Denn Microsoft zufolge ist Exchange Online von Hafnium nicht betroffen. Hiermit meint der Hersteller jedoch das Produkt an sich: Exchange Online ist weiterhin nicht direkt angreifbar. Aber Vorsicht: Es kann je nach Aufbau dennoch möglich sein, dass Angreifer auf den Cloud-Dienst durchgreifen können. 

In vielen Fällen ist in Unternehmen ein hybrider Aufbau etabliert, bei dem ein Exchange-Server weiterhin lokal betrieben wird. Sollte dieser Exchange-Server die HAFNIUM-Schwachstellen aufweisen, könnten Angreifer hierüber Zugriff auf das lokale Netzwerk erhalten (siehe Abbildung Schritt (1)) und sich dann über Lateral Movement im Netz weiterbewegen (Schritt (2)). Mittelbares Ziel des Angriffs ist in der Regel der Zugriff auf ein hochwertiges System wie beispielsweise das Active Directory oder die Active Directory Federation Services (AD FS) zu. Bei Zugriff auf letzteren können die Angreifer unter Umständen den geheimen Schlüssel entwenden (Schritt (3)), sich damit als jeder beliebige legitime Nutzer in der Cloud ausgeben (Schritt (4)) und somit Zugriff (lesen, verändern, löschen) auf alle in der Cloud gespeicherten Daten bekommen (Schritt (5)).

Angriff auf die Cloud/ADFS via HAFNIUM/ProxyLogon

Ob und wie leicht dies möglich ist, hängt stark davon ab, wie der lokale Aufbau umgesetzt ist. Wir erleben im Bereich der Forensik und Beratung hier gute wie auch ungünstige Umsetzungen. Prinzipiell sollte das Ziel immer sein, Lateral Movement in der On-Premise-Umgebung wie auch in der Cloud zu minimieren. Hierfür gibt es bewährte Verfahren, welche sich bei geeigneter Konfiguration dazu eignen, die Bewegungen der Angreifer im Netz zu erschweren:

  • Frühzeitiges Patchen von Sicherheitslücken: Die wichtigste Maßnahme, die auch bei Hafnium eine Kompromittierung mit hoher Wahrscheinlichkeit unterbunden hätte, ist das schnelle Patchen der Systeme. Hier herrscht bisweilen noch der Irrglaube, dass kritische Sicherheitslücken innerhalb von 30 Tagen zu patchen seien. Dies wurde und wird teilweise sogar noch von IT-Sicherheitsstandards vorgeschlagen. Sicherheitslücken, die mittels Fernzugriff automatisiert und unauthentifiziert ausgenutzt werden können, so wie dies bei Hafnium der Fall ist, zeigen jedoch deutlich, dass hier möglichst innerhalb von Stunden anstatt Tagen gepatcht werden sollte.
  • Administrative Trennung von Active Directory und Exchange Server: Eine weitere Maßnahme, die lokal umgesetzt werden sollte, ist die administrative Trennung zwischen Active Directory und Exchange. Oft sind die Systeme über Jahre gewachsen und eng miteinander verbunden. So trennt die Angreifer nach erfolgreicher Kompromittierung oft nur ein Powershell Kommando von der AD-Übernahme. Hier ist es wichtig, die 2017 von Microsoft im Rahmen der Konferenzen Blue Hat und Black Hat vorgestellten Probleme zu mitigieren. Hierfür eignet sich Split-Permissions (https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help und https://docs.microsoft.com/de-de/exchange/permissions/split-permissions/configure-exchange-for-split-permissions?view=exchserver-2019). Eine weitere Maßnahme ist die Verwendung der Local Administrator Password Solution (LAPS) von Microsoft. Hierbei wird auf jedem Host ein separates Admin-Passwort gesetzt, um so das Springen nach einem erfolgreichen Angriff (beispielsweise mittels Pass-the-Hash-Angriffsarten) zu erschweren.
  • Umsetzen des Konzepts administrativer Zonen: Da AD FS das Sprungbrett in die Cloud Welt ist, sollte dieser Zugang besonders gesichert werden. Hierzu empfiehlt Microsoft seit längeren einen Aufbau, in dem verschiedene administrative Sicherheitszonen (engl. tiers) voneinander getrennt werden sollten. Ein entsprechend gesicherter Exchange Server würde hier in Zone 1 stehen und ein Active Directory in Zone 0. Ein Sprung zwischen diesen Zonen soll mit den umzusetzenden Maßnahmen stark erschwert werden. Für den AD FS empfiehlt Microsoft ebenfalls den Aufbau in der Zone 0 (https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/design/best-practices-for-secure-planning-and-deployment-of-ad-fs).
  • Multifaktorauthentifizierung: Sowohl in der Cloud als auch in der lokalen IT-Umgebung sollten administrative Zugriffe mittels starker Multifaktorauthentifizierung abgesichert werden.
  • Protokollierung und Monitoring: Damit ein unberechtigter Zugriff möglichst schnell bemerkt wird, sollte ein feinmaschiges Monitoring- und Protokollierungskonzept etabliert sein. Insbesondere in der Cloud-Umgebung gehört das Monitoring neben der Zugriffssteuerung zu den wichtigsten Sicherheitsmaßnahmen. 
  • Datenklassifizierung: Sollte es doch zu einem Einbruch gekommen sein und die Angreifer möchten Daten exportieren, dann sollte mittels der Datenklassifizierung Sicherheitsmaßnahmen greifen, die zumindest die als vertraulich oder streng vertraulich klassifizierten Daten außerhalb der Cloud und des Kundennetzwerks unlesbar darstellen. 
  • Datensicherung: Sollte es zu einem Einbruch gekommen sein und es werden die Daten mittels Ransomware verschlüsselt, dann sollte man auf eine unveränderbare extern gespeicherte Datensicherung zurückgreifen können.

Die obigen Ausführungen zeigen, dass ein ganzheitliches und aktuelles Sicherheitskonzept notwendig ist, um möglichen Sicherheitslücken umfassend entgegenzuwirken. Überprüfen Sie daher regelmäßig Ihre Sicherheitsmaßnahmen und passen Sie diese ggfs. an geänderte Anforderungen an. Insbesondere, wenn Sie lokale Dienste von außen erreichbar konfigurieren oder Cloud-Dienste mit der lokalen IT-Umgebung koppeln, sollten das Sicherheitskonzept überprüft und nachgeschärft werden. Sprechen Sie uns gerne dazu an!  

Know Your Cloudnutzer – KYC für Cloud

An seinem letzten Amtstag hat Ex-US-Präsident Trump noch eine letzte Executive Order zur Cybersicherheit unterzeichnet. Nach dieser müssen US-Cloudprovider – gemeint sind vor allem IaaS-Anbieter – zukünftig ihre Kunden identifizieren (KYC – Know Your Customer), wie das im Bereich Banking bereits seit langer Zeit üblich ist. Das würde bedeuten, dass die Cloud-Dienste vielen ihrer Kunden die Accounts schließen müssten, bis diese Identitätsnachweise hochgeladen haben. Die Biden-Administration hat zumindest den Text des Dekrets sofort wieder von der Internetseite des Weißen Hauses getilgt.

https://www.whitehouse.gov/briefings-statements/text-letter-speaker-house-representatives-president-senate-011921/

Oh Autsch! OAuth-Phishing

Multi-Faktor-Authentisierung gehört inzwischen zum Stand der Technik und ist regelrecht ein Standard im stärker exponierten Cloud-Umfeld. Um ihren Erfolg beim Abgriff von Zugangsdaten weiterhin zu sichern, nutzen Angreifer nun Authentisierungstoken für Cloud-Apps, denn: Wurde eine Angreifer-App mit ausreichend Berechtigungen versehen, können darüber weitreichende Schäden in der gesamten IT-Umgebung verursacht werden. Inzwischen warnt Microsoft Unternehmenskunden vor dieser Angriffsmethode. Es gibt also genug Gründe, sich mal mit den methodischen Details auseinanderzusetzen.

Lesetipps August 2020

DEFCON Is Cancelled – Still Hackers Gonna Hack

2020 ist zum ersten Mal in der Geschichte der legendären Hackerkonferenz der Running Gag „DEFCON fällt aus“ beinahe wahr geworden: Unter dem Titel „Safe Mode“ fand auch die DEFCON dieses Jahr nur virtuell statt. Neben Vorträgen zum Hacking von Lichtanlagen im Straßenverkehr und Geldautomaten erfreute sich insbesondere der Vortrag „Hacking the Hybrid Cloud“ von Sean Metcalf großer Beliebtheit. Oder mit den Worten des Vortragenden gesprochen: „How bad can this get?“ – „Don’t want all my eggs in one basket… So now eggs are in all baskets.“

Why, oh, why, PyPI?

Fipptehler treten auf, binsedonsere dort, wo Menschen Dinge über Tostatüren einbegen können. Das Potenzial von Supply-Chain-Angriffen via Benutzerfehleingaben hat der Sicherheitsforscher William Bengtson genauer betrachtet und gezielt knapp falsch benannte Pakete wie „pythonjsonlogger“ erstellt, die irrtümlich statt des korrekten „python-json-logger“ installiert werden sollen. Bösartige Pakete könnten an dieser Stelle Schadcode einschleusen und z. B. Zugangsdaten abgreifen. Details und Geschichten, die er mit seinem Engagement für die Python-Community erlebt hat, finden Sie unter:

https://medium.com/@williambengtson/python-typosquatting-for-fun-not-profit-99869579c35d

Lesetipps Juni 2020

Erhört

Die Cloud hat ihre eigene Sprache. Da hilft ein mehrsprachiges Wörterbuch mit Übersetzung in die On-Prem-Welt:

https://www.managedsentinel.com/on-prem-vs-cloud/


Erfahren

Security-Urgestein Ross Anderson, Professor am berühmten „Computer Laboratory“ in Cambridge, England, arbeitet an der Neuauflage seines bekannten Buches „Security Engineering“. Das hat den Vorteil, dass das Manuskript momentan frei verfügbar ist:

https://www.cl.cam.ac.uk/~rja14/book.html

Der Aufruf seiner spartanischen Website verbraucht übrigens nur 0.07g CO2 verglichen mit 2g für eine typische Business-Website.

https://www.websitecarbon.com

(www.hisolutions.com gehört immerhin zu den besten 25%) 
 


Korrelational

Korrelationen spielen auch in der Security eine Rolle – etwa im Risikomanagement. Wie täuschend diese scheinbaren Zusammenhänge oft sein können, zeigt eindrucksvoll:

https://www.tylervigen.com/spurious-correlations

Die Grenzen der Elastizität: Auch die Cloud skaliert nicht immer

Das Heilsversprechen der Cloud – instantane, unbegrenzte Skalierbarkeit – wurde zuletzt auf eine harte Probe gestellt. Viele große Anbieter gingen aufgrund des Ansturms zeitweise in die Knie oder mussten ihr Angebot einschränken. Dabei ist das Problem bei kleinen Anbietern oder bei DIY nicht geringer: Nicht jede Firma kann plötzliche Nachfrageänderungen um mehrere Größenordnungen so passabel abfedern wie große Cloud-Provider. Häufig fallen den Akteuren ganz profane Probleme auf die Füße: zu wenige Server (z. B. Terminalserver), VPN-untaugliche Fachanwendungen, fehlende VPN-Lizenzen bzw. unterdimensionierte VPN-Gateways, mangelnde Brandbreite vor allem im Upload oder auch schlicht: fehlende Laptops, die nicht immer sofort beschafft werden können.

Azure: https://www.theregister.co.uk/2020/03/24/azure_seems_to_be_full/ 

O365: https://www.zdnet.com/article/microsoft-throttles-some-office-365-services-to-continue-to-meet-demand/ 

GCP: https://www.theregister.co.uk/2020/03/26/google_gsuite_outage/ 

Laptop-Mangel: https://www.telegraph.co.uk/technology/2020/03/12/surge-home-working-threatens-laptop-shortage-warns-computacenter/