Zeit der Unschuld ist für MSPs vorbei

Ganz ehrlich: So etwas kann jedem Softwareanbieter passieren. Blöd nur, wenn es jemandem passiert, von dem Tausende andere abhängig sind, die dann mit in das Schlamassel hineingezogen werden. Wie reagiert man dann richtig? Diese Frage beschäftigt aufgrund der Ransomware-Welle, die über Kaseya VSA verteilt wurde, derzeit viele IT-Dienstleister und Managed Service Provider. Nicht nur solche, die auf Kaseya als Basis ihres MSP-Angebots setzen, sondern auch jene, die andere Plattformen nutzen. Sie fragen sich: Was wäre, wenn das mir passiert wäre?

Die Anbieter halten sich jedoch vornehm zurück: Auf Anfrage wollten sich zum Beispiel weder Atera noch Barracuda MSP dazu äußern, welche Lehren MSPs aus dem Kaseya-Vorfall ziehen können. Auch ADN, langjähriger und wichtigster Distributionspartner von Kaseya in Deutschland, wollte sich vorerst nicht äußern. Die Zurückhaltung ist verständlich: Einerseits will man aus Fairness wohl nicht auf den Marktbegleiter eindreschen - vor allem, so lange nicht alle Details bekannt sind. Zum anderen schwingt sicher auch die Befürchtung mit, dass man sich zu weit aus dem Fenster lehnen könnte. Denn wie Sicherheitsexperten seit Jahren immer wieder betonen, gibt es hundertprozentige Sicherheit nicht und hätte es statt Kaseya auch jeden anderen Anbieter treffen können - sei es nun Connectwise, Datto, N-able oder eben die Genannten.

Dennoch ist Totschweigen keine Lösung. Deshalb hat ChannelPartner in der IT-Security-Branche nachgefragt, was der Vorfall für das Geschäftsmodell Managed Services bedeutet und wie Managed Service Provider sich und ihre Kunden darauf vorbereiten können, mit einem ähnlichen Vorfall in Zukunft umzugehen.

Angemessene Notfallreaktion von Kaseya

Die gute Nachricht: Kaseya hat die Cyberattacke verhältnismäßig schnell in den Griff bekommen. Entdeckt wurde sie am 2. Juli um 20 Uhr. Angreifbar war mit VSA eines von 27 Modulen der Produktsuite Kaseya IT Complete. Binnen einer Stunde wurde der Zugriff auf die zur Gefahr gewordene Software abgeschaltet. Von den mehr als 35.000 Kaseya-Kunden waren bis dahin etwa 50 betroffen. Allerdings sind einige davon Managed Service Provider, die vor allem kleine Unternehmen mit weniger als 30 Mitarbeitern betreuen. Über die Systeme der Kaseya-MSPs werden etwa 800.000 bis 1.000.000 Unternehmen verwaltet. Davon wurden laut Kaseya zwischen 800 und 1.500 erfolgreich angegriffen.

Auf Nachfrage teilte Kaseya ChannelPartner mit, dass in Europa acht Kunden betroffen sind. Einige davon müssen MSPs sein, denn laut BSI wurden alleine in Deutschland "mehrere Tausend IT-Geräte verschlüsselt" und sind auch hierzulande IT-Dienstleister betroffen.

"Obwohl jeder einzelne betroffene Kunde einer zu viel ist, hat sich gezeigt, dass die Auswirkungen dieses hochentwickelten Angriffs glücklicherweise stark überschätzt wurden", beschwichtigt Fred Voccola, CEO von Kaseya, die Gemüter. Dazu habe beigetragen, dass Anwender, wie von Kaseya empfohlen, die VSA-Server sofort abschalteten und die Anleitung zur Schadensbegrenzung befolgten. Voccola versichert zudem: "Wir verstehen, dass jede Sekunde, in der sie arbeitsunfähig sind, ihre Existenzgrundlage beeinträchtigt, deshalb arbeiten wir mit Hochdruck daran, dieses Problem zu beheben."

Extern bestätigt diese Aussagen eine Analyse von Palo Alto Networks. Demnach reduzierte sich die Anzahl der verwundbaren Kaseya-Server, die für Angreifer über das Internet sichtbar waren, von etwa 1.500 am 2. Juli auf 60 am 8. Juli. Der Hersteller beruft sich dabei auf Scans mit seiner Plattform Cortex Xpanse. Matt Kraning, Chief Technology Officer für Cortex bei Palo Alto Networks, erklärt daher, man sei "vorsichtig optimistisch, dass die Auswirkungen dieses Angriffs verringert wurden, weil Kaseya seinen Kunden schnell klare Ratschläge gegeben hat, wie sie diese Bedrohung abmildern können."

Diese gute Informationspolitik hat auch den betroffenen IT-Dienstleistern in Deutschland geholfen. Einer davon mit Sitz in Schleswig-Holstein hat seine Kunden zum Beispiel auch deshalb immer zeitnah über seine Webseite auf dem Laufenden halten können - und durch die schnelle und transparente Information sicher in einigen Fällen größeren Schaden durch hektische aber unsachgemäße Gegenmaßnahmen verhindern können.

"Im aktuellen Fall stehen wir mit einer Reihe Managed Service Providern in Kontakt, die am Freitagabend sofort reagierten und alle Systeme entsprechend abgesichert haben", erklärt Thomas Uhlemann, Security Specialist DACH bei Eset Deutschland. Auch aus seiner Sicht entscheidend: "Der Zeitpunkt des Ausbruchs und die schnelle Reaktion der MSP hat dafür gesorgt, dass sich der Schaden im deutschsprachigen Raum bei Kunden von Dienstleistern in Grenzen hält." Wünschen möchte man so eine Situation, in der alle Kunden gleichzeitig in Alarmzustand versetzt werden, trotzdem niemanden. Was kann also vorbeugend getan werden?

Mitarbeiter schulen und den Stecker ziehen reicht nicht

Norbert Pohlmann, Vorstand IT-Sicherheit im eco - Verband der Internetwirtschaft e. V., fordert in einer aktuellen Stellungnahme von der Politik insbesondere für mittelständische Unternehmen "größtmögliche Unterstützung bei der Abwehr von Attacken globaler Hacker-Netzwerke." Wie genau die aussehen soll und wie sie umgesetzt werden soll, lässt er offen.

Pohlman mahnt jedoch auch: "Unternehmen selbst müssen sich gleichzeitig die Gefahren bewusst machen und sich auf den Fall der Fälle vorbereiten. Hier wird nicht nur eine Risikoanalyse der einzelnen Geschäftsprozesse benötigt, sondern auch ein Notfallplan, der alle Prozesse abdeckt und anhand dessen die Mitarbeiter geschult werden, um auf solche Sicherheitsvorfälle vorbereitet zu sein und diesen erfolgreich begegnen zu können."

Das ist gut und richtig. Ob es in Firmen mit bis zu 30 Mitarbeitern, die im Fokus der Kaseya-MSPs stehen, auch immer ohne weiteres so umgesetzt werden kann, ist allerdings fraglich. Ulrich Mertz, Gründer und Geschäftsführer von Rangee, einem Hersteller von Thin Clients und Zero Clients aus Aachen, hat daher einen anderen Vorschlag. Ursache der Angriffe auf Kaseya, Solwarwinds und früher schon Teamviewer und ähnlicher Attacken waren ihm zufolge, "dass Unternehmen häufig sehr viel Wert darauf legen, dass sich ihre Systeme über die Cloud verwalten lassen. Das mag bequem sein, ist aber auch ein Sicherheitsrisiko. Fast jeder Hersteller bietet inzwischen für seine Systeme eigene Schnittstellen und eigene Protokolle für ein Remote-Management über die Cloud. So entstehen viele 'Bypässe', die die Sicherheitslösungen des Unternehmens umgehen."

Unternehmen seien daher gut beraten, "bei jedem Management-Dienst, der weltweit bereitgestellt wird, genau zu überlegen, ob er tatsächlich einen Mehrwert liefert - oder ob die Offline-Lösung mit denselben Funktionen nicht vielleicht doch wertvoller ist, weil sie passive Sicherheit bietet." Rangee habe sich deshalb explizit gegen ein Gateway in die Cloud entschieden. Administratoren können über ihren Remote-Desktop auf den Thin Client Management Server (TCMS) hinter der Firewall zugreifen, um die Endgeräte zu verwalten.

Das Vorgehen ist zweifellos geeignet, die Sicherheit zu erhöhen. Es steht aber dem Wunsch vieler Dienstleister entgegen, möglichst viele Aufgaben bei der Betreuung ihrer Kunden aus möglichst einer Oberfläche und zentral vornehmen zu können. Das ist nicht Bequemlichkeit, sondern entspringt dem Bedürfnis, der Nachfrage der Kunden und deren Preisvorstelllungen gerecht zu werden und nicht zuletzt die Arbeit für die eigenen Fachkräfte attraktiv zu gestalten. Denn schwer genug zu bekommen sind sie ja. Wie lässt sich also das Risiko minimieren?

Vertrauen ist gut, Kontrolle ist besser

"Kunden dürfen nicht davon ausgehen, dass sie die Gesamtverantwortung loswerden, nur weil sie bestimmte Aufgaben abgeben", mahnt Michael Kleist, Regional Director DACH bei CyberArk. "Man könnte als Dienstleister immer mehr machen. Die Frage ist aber, ob der Kunde das annimmt und dafür zu zahlen bereit ist." Generell empfiehlt Kleist Unternehmen aber, bei hoher Zentralisierung von Diensten - sei es nun in der Cloud oder bei einem MSP - sich noch einmal mehr Gedanken um den "Plan B" zu machen.

Problematisch ist aus Sicht von Kleist beim aktuellen Vorfall vor allem die hohe Vertrauensstellung, die der Kaseya-Software VSA eingeräumt wurde - und zwar völlig unabhängig davon, ob sie nun bei Unternehmen direkt oder bei einem MSP zum Einsatz kam. "Man muss immer davon ausgehen, dass etwas passieren kann. Dafür hat sich ja das Zero-Trust-Modell etabliert", sagt Kleist.

Gerade bei einer Software, die Remote Management mit Automatisierung und einer hohen Vertrauensstellung verbindet, müsse man davon ausgehen, dass sie für Angreifer interessant ist. Und genau deshalb müsse zwangsläufig eine zweite Verteidigungslinie eingezogen werden. Kleist empfiehlt hier nicht eine zweite, gleichartige Kontrollinstanz, sondern eine andere Art der Verteidigung - etwa den Endpoint Privilege Manager von CyberArk.

"Damit wäre der Angriff zwar genau so abgelaufen, wie er es jetzt ist, aber die Malware wäre auf den Endgeräten nicht zur Ausführung gekommen: Software, die versucht auf Dokumente zuzugreifen, für die sie keine Berechtigung hat, würde einfach blockiert." Als Beleg führt er die Solarwinds-Attacke an. Da habe die darüber verteilte Malware vor der Ausführung auf den Endgeräten geprüft, welche Sicherheitsmechanismen dort greifen und sei bei solchen, die zu ihrer Entdeckung geführt hätten - unter anderem den Lösungen von CyberArk -, erst gar nicht aktiv geworden. Die Angreifer wissen also sehr wohl schon, wie sich Unternehmen schützen könnten. Nun ist es an den Unternehmen, sich zumindest so aufzustellen, dass sie kein leichtes Opfer werden.

Auch für den Eset-Security-Spezialisten Uhlemann, ist "Zero Trust technisch gesehen das Gebot der Security-Stunde." Schutz könne zwar nie hundertprozentig sein, aber durchaus bestmöglich. "Das bedeutet, dass IT-Security für alle MSP zur Geschäftsgrundlage werden muss. Das erfordert ein konsequentes Umsetzen von Zero Trust sowohl in Richtung der Hard- und Software-Lieferanten und der Kunden als auch im eigenen Haus", fordert Uhlemann.

Den Worst Case als unvermeidbar akzeptieren und sich vorbereiten

Richard Werner, Business Consultant bei Trend Micro, denkt in dieselbe Richtung. "Die Verteidigung vieler Unternehmen ist überwiegend nach außen gerichtet. Deshalb fallen Angriffe wie dieser besonders auf. Bei einer Supply-Chain-Attacke werden die äußeren Verteidigungsmechanismen praktisch umgangen und der Angriff startet im Rechenzentrum des betroffenen Unternehmens." Werner weist darauf hin, dass der Angriff bei Kaseya - anders als bei Solarwinds, das tatsächlich "gehackt" wurde - über eine zu dem Zeitpunkt nicht gepatchte Sicherheitslücke kam. Das sei zwar selten, aber längst nicht unüblich.

"Eine effektive Verteidigung muss deshalb davon ausgehen, dass ein solcher Vorfall stattfinden kann", betont Werner. "Schutzkonzepte dagegen, dass benachbarte Systeme 'bösartig' werden, gibt es, seit es Cloud-Angebote gibt. Und Technologie, die sich mit ungewöhnlicher Netzwerkkommunikation und Anomaliedetektion auseinandersetzt, existiert auch schon ein paar Jahre." Ein Schutzkonzept wie das von Trend Micro verfolgte XDR (Extended Detection and Response) fasse beide Themenbereiche zusammen. "Doch nochmal: Es geht nicht darum, den Angriff zu verhindern, sondern den daraus entstehenden Schaden zu minimieren. Hier ist Umdenken gefragt", erinnert Werner.

Das gilt auch für Trend Micro, das nicht nur Lieferant für IT-Security ist, sondern selber eine Plattform für Managed Security Services anbietet. "Als Anbieter von Serviceleistungen inklusive Update-Funktionalitäten ist es uns bewusst, dass auch unsere Lösungen im Fokus eines potenziellen Angreifers stehen können. Die Verteidigungsmechanismen umfassen deshalb, neben den oben genannten Funktionen, auch Verschlüsselungen und andere Werkzeuge, mit denen wir die Integrität unserer Services sicherstellen", erklärt Werner dazu. Die Lösungen enthalten nicht nur eine Technologie, sondern auch mehrere, von unterschiedlichen Entwicklungsteams gepflegte Mechanismen, die unter die grobe Bezeichnung "Security" fallen.

"Unser Endpoint enthält beispielsweise mehr als 20 einzeln, teilweise optionale, Techniken, unter anderem verschiedene Arten künstlicher Intelligenz, Reputationschecks und Signaturlisten", beschreibt Werner. Er verweist zudem auf das seit 2016 von Trend Micro getragene Bug-Bounty-Programm "Zero Day Initiative", das auch die hauseigenen Produkte und Dienste regelmäßig auf Lücken untersucht. "Natürlich freut sich kein Hersteller darüber, dass über Lücken in seiner Software gesprochen wird. Als Sicherheitsunternehmen ist es für uns jedoch wichtiger, diese zu schließen, bevor sie anderweitig ausgenutzt werden können - auch wenn das die eine oder andere Nachricht in IT-Security-Publikationen bedeutet", betont Werner.

Doch nicht nur die Hersteller und Technologielieferanten müsse ihre Hausaufgaben machen. Oliver Tavakoli, CTO bei Vectra AI, gibt auch den Managed Service Providern einige auf: "Dieser Angriff wurde durch einige eindeutige Fehler ermöglicht - die VSA-Server von Kaseya wiesen einige Schwachstellen auf, die nach Informationen von Drittanbietern behoben wurden, und MSPs entschieden sich dafür, diese Server so bereitzustellen, dass sie nach der Entwicklung eines Exploits leicht erreichbar waren."

Tavakoli fordert daher: "Technologieanbieter von IT-Infrastruktursoftware - in diesem Fall Kaseya - müssen beim Auffinden und Patchen von Schwachstellen in ihrer Software unglaubliche Sorgfalt walten lassen und Best Practices für die Bereitstellung ihrer Software empfehlen - und möglicherweise durchsetzen." MSPs ihrerseits müssten ihre Angriffsfläche auf das absolute Minimum reduzieren - also ihren "Internet-Fußabdruck" reduzieren. Den notwendigen Zugriff auf solche Server über gehärtete Systeme mit MFA zu erzwingen, ist nach Auffassung von Tavakoli ein guter Anfang.

Ähnlich argumentiert auch Romain Lecoeuvre, CTO von YesWeHack: "Die Angreifer nutzen einen vertrauenswürdigen Verteilungsvektor innerhalb der Informationssysteme eines Unternehmens und seiner Partner oder Kunden, um massenhaft bösartigen Code zu verteilen." Um dieses Risiko zu reduzieren, empfiehlt er MFA zumindest für Administrations- oder Entwickleraktionen, insgesamt eine "starke Integritätskontrollstrategie, eine regelmäßige Überprüfung der einzelnen Komponenten des Gesamtsystems sowie die Berechtigungen und den Umfang von Code, der von Dritten stammt, so weit wie möglich zu reduzieren.

Schließlich empfiehlt auch Lecoevre ein Business Continuity Planning (BCP) oder ein Emergency Response Planning (ERP), um im Falle eines Falles schnell und effizient reagieren zu können. Da es mit einem Plan meist nicht getan ist, sondern der auch duch geeignete Technologien, Ressourcen und Personen umsetzbar gemacht werden muss, kommen dadurch auf alle Beteiligten zusätzliche Kosten zu. Möglicherwiese reift aber bei Unternehmen allmählich die Erkenntnis, dass sie sich durch Auslagern eines bestimmten Dienstes nicht der Gesamtverantwortung entziehen können und - wenn sie nicht selbst Vorkehrungen treffen wollen - die bei jemand anderem in Auftrag geben müssen.

Der Kaseya-Vorfall ist da längst nicht der erste Warnschuss. Auch der Datenverlust vieler Unternehmen beim Brand des OVH-Rechenzentrums hat gezeigt, dass Aufgaben wie Backup und Desaster Recovery eben nur dann vom Dienstleister mit übernommen werden, wenn er damit beauftragt wurde. MSPs sollten sich daher nicht scheuen, auch darauf hinzuweisen, was im Service-Paket nicht enthalten ist. Denn nur dann besteht auch die Chance, dass Kunden diese Bestandteile als zusätzlichen Service nachfragen.