6.000 Rechner, 380 Filialen, eine Frozen Zone: Wie Thalia MXDR ausgerollt hat

Thalia ist kein mittelständisches Haus – rund 6.500 Beschäftigte, etwa 380 Buchhandlungen, Onlineshop, App, ein hybrides Rechenzentrum. Wir greifen die Fallstudie trotzdem auf, die G DATA zur Einführung von MXDR bei Thalia veröffentlicht hat, weil die beiden Probleme, die darin gelöst werden, keine Konzernprobleme sind: Wie führt man eine Angriffserkennung ein, ohne das Geschäft zu stören? Und wie bringt man Updates an viele Standorte, ohne die Leitungen zu belasten? Beides stellt sich bei zehn Filialen genauso wie bei 380. Zitate sind wörtlich aus der Fallstudie übernommen.

Die Anforderung: ein Team, nicht nur Technik

Nach der Fallstudie erkannten die Verantwortlichen bei Thalia früh, „dass eine reine technologische Aufstockung nicht zum gewünschten Ziel führt“. Die Anforderung war ein Managed-Security-Service mit einem Team, das sieben Tage die Woche rund um die Uhr überwacht, um bei Verdachtsfällen direkt reagieren zu können. Moundji Merabet, Senior Manager Retail IT bei Thalia, wird so zitiert: „Wir orientieren uns sehr stark am BSI-Grundschutz und der ISO 27001, um den Schutz unserer Daten und Prozesse zu gewährleisten. Um unsere IT jedoch dauerhaft abzusichern, haben wir entschieden, mit einem erfahrenen IT-Security-Unternehmen zusammenzuarbeiten, das auch entsprechende Ressourcen für uns vorhält.“

Der Satz enthält die Einsicht, die auch kleinere Häuser treffen: Grundschutz und Norm sagen, was zu tun ist. Wer es nachts tut, sagen sie nicht. Thalia setzte seit über zwanzig Jahren Sicherheitslösungen von G DATA ein und fragte deshalb zuerst dort an; die Fallstudie nennt als Grund neben dem Vertrauensverhältnis, dass die Ansprechpersonen „mit den Besonderheiten des Netzwerkes vertraut“ waren.

Die Frozen Zone als Planungsfenster

Im Handel gibt es eine Zeit, in der an der IT nichts geändert wird: die Wochen des Weihnachtsgeschäfts. Thalia nimmt laut Fallstudie zwischen November und Januar nur geringe Änderungen vor, um Verfügbarkeit und Leistung der Systeme zu sichern. Statt diese Zeit zu verlieren, wurde sie zur Projektplanung genutzt – Konzeption und Vorbereitung des Rollouts fanden statt, während die Systeme eingefroren waren, und der Rollout selbst begann unmittelbar danach.

Für ein mittelständisches Haus ist die Lehre übertragbar: Jeder Betrieb hat eine Frozen Zone – Monatsabschluss, Inventur, Saisonspitze –, und sie ist nicht die Zeit, einen Agenten auszurollen. Sie ist die Zeit, Ausnahmen zu definieren, die Rufkette festzulegen und zu klären, welche Systeme isoliert werden dürfen. Das Onboarding braucht Köpfe, nicht Leitungen.

Das technische Problem: Updates für 6.000 Agenten

Ein Agent auf jedem Rechner holt sich normalerweise seine Updates – Programm, Signaturen, Regeln – direkt von den Servern des Herstellers. Bei 6.000 Rechnern, deren Kommunikation über gesicherte Verbindungen zu den Läden läuft, hätte das die Leitungen belastet, über die auch Kassen und Onlineshop arbeiten. Die Vorgabe war deshalb eine ressourcenschonende Verteilung.

Die Lösung nutzte, was Thalia schon hatte: einen bestehenden Caching-Prozess für die Verteilung von Updates, für den dedizierte Server bereitgestellt wurden. Jedes Update wird nur einmal in das Rechenzentrum von Thalia geladen; die Agenten fragen eine festgelegte interne Quelle an, die den größten Teil der Anfragen aus dem Cache beantwortet. Nur was dort noch nicht liegt, wird vom Hersteller geholt. Grundlage ist laut Fallstudie die Open-Source-Software HAProxy, und G DATA hat die alternative Quelle in den Agenten hinterlegt. Merabet: „G DATA hat unseren Wunsch sofort umgesetzt.“

Das Muster – ein interner Zwischenspeicher, der die Außenverbindung entlastet – ist bei zehn Standorten mit schmalen Anbindungen genauso sinnvoll wie bei 380. Es kostet einen Server und eine Konfiguration, und es verhindert, dass die Sicherheitslösung am Montagmorgen die Leitung belegt, über die die Kasse arbeitet.

Der Rollout: erst prüfen, dann installieren

Der Rollout auf mehr als 6.000 Clients gelang laut Fallstudie „ohne größere Probleme“. Als Grund wird ein Implementierungsprozess genannt, bei dem G DATA ein Skript bereitstellt, das die Kompatibilität der Systeme mit dem Agenten prüft – unter anderem, ob der Rechner einen festgelegten Patch-Stand hat. Auf diesem Weg wurden alle Systeme mit alten Windows-Patchständen identifiziert, bevor der Agent installiert wurde.

Das ist ein Nebeneffekt, der in vielen Einführungen der eigentliche Gewinn ist: Die Prüfung vor dem Rollout macht sichtbar, was im Bestand nicht in Ordnung ist. Ein Rechner, der den Patch-Stand nicht erreicht, ist nicht nur ein Rollout-Problem – er ist eine Lücke, die vorher niemand gesehen hat.

Das Fazit nach sechs Monaten

Sechs Monate nach dem Rollout fällt das Fazit laut Fallstudie positiv aus: Die Systeme werden rund um die Uhr von einem Expertenteam überwacht, das „bereits bei geringen Verdachtsfällen umgehend“ reagiert und verdächtige Systeme vom Netz trennt. Wo Mithilfe nötig ist, erhält Thalia „klare Handlungsanweisungen“. Merabet: „Das Security-Team von G DATA nimmt uns sehr viel Arbeit ab. Wir können uns auf wesentliche IT-Aufgaben konzentrieren und wissen, dass ein versierter Partner für die IT-Sicherheit sorgt.“

Als großen Pluspunkt nennt die Fallstudie den direkten Kontakt zum Support-Team in Bochum: „Gerade in stressigen Situationen stört keine Sprachbarriere den Austausch.“ Die Lösung ist inzwischen auch in Österreich im Einsatz; der Rollout in der Schweiz war zum Zeitpunkt der Fallstudie geplant.

Was davon für siebzig Beschäftigte gilt

Verwandte Themen: Wer hier weiterdenkt, liest bei Angriffserkennung ohne eigenes Team, Angriffserkennung und Vertragsprüfung Sicherheit weiter.