Future{hacks}: SaaS im Kreuzverhör: Wenn dein teuerstes Tool der schwächste Punkt ist

Erst taucht die Washington Post auf Grund einer Sicherheitslücke in einer Erpressungskampagne auf. Kurz darauf meldet der japanische Medien-Gigant Nikkei, dem u.a. auch die Financial Times gehört, einen Datenleck-Vorfall, bei dem weit über zehntausend Personen betroffen sind.

Das sind keine Spezialfälle aus irgendeiner Security Konferenz, sondern Warnsignale für ganz normale Unternehmen. Denn betroffen sind nicht exotische Eigenbauten, sondern genau jene Systeme, bei denen viele „Enterprise grade“ abhaken und nicht weiter darüber nachdenken.

Genau dort beginnt die eigentliche Verwundbarkeit. Das Problem ist selten die Cloud an sich. Es ist die Art, wie wir Drittanbieter behandeln. Nämlich als Naturgesetz statt als Bausteine, die man verstehen, begrenzen und im Notfall ersetzen muss.

„Enterprise-grade“ als Einfallstor

In den aktuellen Fällen sieht man das gut.

Im Umfeld der Washington Post nutzen Angreifer eine bis dahin unbekannte Schwachstelle in Oracle E Business Suite, einer Software, die weltweit als Rückgrat für Finanz, HR und Logistik läuft. Laut Google und weiteren Analysen handelt es sich um eine groß angelegte Kampagne der Cl0p Gruppe, einer bekannten Ransomware und Erpressungsbande, die weltweit Unternehmen über Supply Chain Lücken angreift. Wer nicht zahlt, landet auf ihrer öffentlichen Leak Seite, auf der gestohlene Daten Stück für Stück veröffentlicht werden. Was wie ein einzelner Vorfall wirkt, ist in Wirklichkeit einer der schwereren Supply Chain Breaches der letzten Jahre.

Im Fall von Nikkei reicht ein kompromittiertes Privatgerät und ein gestohlener Login für Slack. Auf dem privaten Laptop eines Mitarbeiters landet Malware, die den Zugang zum Firmenworkspace mitliest. Mit diesen Zugangsdaten klinken sich Angreifer in den internen Slack ein. Laut den bisherigen Meldungen sind interne Chats, Kontakte und E Mail Adressen von über siebzehntausend Personen potenziell offengelegt.

Das Problem ist aber nicht nur der eine infizierte Rechner. Der eigentliche Schaden entsteht, weil Slack als zentraler Kommunikationskanal ohne doppeltes Netz genutzt wird. Wenn dort alles zusammenläuft und es keine saubere Trennung und keinen Backupweg gibt, wird ein einzelner Fehltritt am Privatgerät schnell zum Sicherheitsvorfall für das gesamte Unternehmen.

Gemeinsam ist beiden Fällen etwas anderes als die konkrete Software. Es sind Systeme, bei denen viele Unternehmen gedanklich einen Haken setzen. „Enterprise tool, passt schon.“ Ab da wird selten weitergefragt, welche Rolle dieses Tool im eigenen Geschehen wirklich spielt.

Warum „Enterprise Tool“ kein Sicherheitszertifikat ist

Die Erzählung geht oft so. Großer Vendor, tausende Kunden, Zertifizierungen, Referenzen. Klingt sicherer, als man je selbst bauen könnte.

In der Realität passiert Folgendes:

Wenn ein Fehler in so einem System auftaucht, trifft er nicht ein Unternehmen, sondern viele gleichzeitig. Das Patchtempo des Anbieters bestimmt, wie lange das Fenster offen bleibt. Die eigene Sicht auf Logs und Sicherheitsmechanismen ist begrenzt. Dazu kommen hausgemachte Schwächen. Zu breite Adminrechte, Zugänge von privaten Geräten, Integrationen, die niemand mehr dokumentiert.

Es ist also nicht die Frage, ob man den einen richtigen Anbieter findet. Es ist die Frage, wie viel Schaden entsteht, wenn einer dieser Bausteine stolpert. Genau hier kommt Architektur ins Spiel.

Die unsichtbare Schicht unter deinen Prozessen

Viele Risikobetrachtungen schauen noch auf Server, Netzwerke und ein paar Kernanwendungen. Darunter liegt aber längst eine zusätzliche Schicht, die leicht übersehen wird.

• ERP und Finanzsysteme
• HR und Bewerbermanagement
• Kollaborationstools wie Chat und Videokonferenzen
• CRM und Marketing Automation
• Identity und Single Sign on Dienste
• Security Tools, die selbst tief im Netzwerk sitzen

Wer verstehen will, wie verwundbar das eigene Unternehmen ist, sollte sich nicht zuerst die Toolliste anschauen, sondern zwei Wege:

Den Pfad des Geldes. Vom ersten Kontakt bis zum bezahlten Auftrag. Wo läuft das Angebot, wo wird es genehmigt, wo wird die Rechnung erzeugt, wo wird gezahlt.

Und den Pfad der sensiblen Daten. Von der ersten Bewerbung bis zum Arbeitsvertrag. Von der Kundenanfrage bis zum unterschriebenen Vertrag.

An jeder Stelle stellt sich dann die Frage. Liegt das auf einem System, das ich selbst betreibe und verstehe. Oder hängt es an einem Drittanbieter, den wir einmal ausgesucht und dann nie wieder hinterfragt haben.

Allein diese Übung zeigt meist zwei bis drei Namen, bei denen der Puls hochgeht.

Wie ein Plan B aussieht, wenn morgen ERP oder Slack fehlen

Die gute Nachricht. Ein Notfallplan muss nicht perfekt sein, er muss funktionieren. Ziel ist nicht, die komplette Suite doppelt zu bauen. Ziel ist, den Kern am Leben zu halten, wenn ein zentraler Dienst ausfällt oder kompromittiert ist.

Stellen wir uns drei Szenarien vor.

ERP wackelt

Wenn die große Suite nicht erreichbar ist, ist die größte Angst oft die Lohnverrechnung oder die Rechnungsstellung. Ein Plan B kann bedeuten. Export der wichtigsten Stammdaten in ein separates System, das regelmäßig aktualisiert wird. Klare Regeln, wie viele Lohnläufe oder Rechnungszyklen man im Notmodus manuell oder halbautomatisch durchziehen kann. Und ein definierter Prozess, wie man die Ergebnisse später wieder sauber ins Hauptsystem zurückführt.

Kollaborationstool wird kompromittiert

Wenn interne Chats als unsicher gelten, darf nicht das gesamte Unternehmen stummgeschaltet sein. Hier braucht es Alternativen. Klar definierte Kanäle für Krisenkommunikation. Eine E Mail Verteilerstruktur, die ohne Chat funktioniert. Vielleicht ein zweites, unabhängiges Tool für eng begrenzte Krisenteams. Und vor allem Integrationen, die bewusst reduziert sind, damit ein angreifbarer Chat nicht der Generalschlüssel zu allen anderen Systemen wird.

Identity Provider fällt aus

Viele Tools hängen heute an einem zentralen Login Dienst. Das ist bequem. Es bedeutet aber auch, dass dieser Dienst zum Single Point of Failure wird. Ein Plan B kann bedeuten. Für ausgewählte Systeme gibt es Lokalkonten, die im Notfall aktiviert werden. Zugänge für kritische Funktionen sind nicht ausschließlich an einen einzigen externen Identity Provider gebunden.

In allen Fällen geht es um dasselbe Prinzip. Kritische Prozesse so bauen, dass sie einen Teilausfall verkraften. Weniger perfekt, aber arbeitsfähig.

Third Party Governance, die nicht im Papier stecken bleibt

Damit das nicht nur als schöne Idee im Risikoregister landet, braucht es ein paar klare Linien im Alltag.

Zuerst die Frage, wer im Unternehmen überhaupt entscheiden darf, welches Dritttool für kritische Daten eingesetzt wird. Wenn jede Abteilung ihren Lieblingsdienst einkauft, entsteht Schatten IT mit direktem Zugang zu Kundendaten oder Finanzinformationen.

Dann die Rechtevergabe. Adminzugänge sollten selten und nachvollziehbar sein. Integrationen brauchen das Prinzip der kleinsten nötigen Berechtigung, nicht das volle Programm. Private Geräte mit beruflichen Logins brauchen klare Regeln, sonst genügt ein verlorenes Passwort und ein Trojaner auf dem Privat Laptop, um Unternehmensdaten offenzulegen.

Und schließlich die Überprüfung der wichtigsten Drittanbieter. Nicht nur beim Einkauf, sondern regelmäßig. Welche Sicherheitsvorfälle hatten sie. Wie transparent kommunizieren sie. Wie schnell patchen sie Schwachstellen. Was steht im Vertrag zu Support, Vorfällen und Datenrückgabe.

Digitale Souveränität bedeutet an dieser Stelle nicht, alles selbst zu hosten. Sie bedeutet, jederzeit zu wissen, was wo läuft, wie man es ersetzen könnte und wie man im Notfall sicher auf eine andere Arbeitsweise ausweichen kann.

Unser Future{hacks} Fazit

Die aktuellen Vorfälle bei großen Medienhäusern sind kein Exotenthema der IT, sondern ein Spiegel für viele Organisationen. Nicht der eigene Serverraum war der Einstieg, sondern ein Drittanbieter, dem man viel Verantwortung überlassen hat.

„Enterprise tool“ ist kein Freibrief. Es ist ein Baustein im eigenen System. Wer diesen Baustein weder kartiert noch absichern noch im Zweifel tauschen kann, hat kein Sicherheitsproblem, sondern ein Architekturproblem.

Souverän ist, wer seine wichtigsten Abhängigkeiten kennt, einen Plan B hat und im Ernstfall nicht den gesamten Betrieb an ein Ticket beim Provider delegieren muss. Genau dort beginnt digitale Souveränität im Alltag. Nicht in großen Reden, sondern in der nüchternen Frage. Was passiert, wenn dieses Tool morgen nicht mehr da ist.

Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.