SolarWinds-CISO im Interview: Angriff auf Software-Lieferkette

Ende letzten Jahres gelang es Cybergangstern, die sich vermutlich in der russischen Gang Nobelium (APT29) organisieren (siehe auch: Die gefährlichsten Hackergruppen), die Update-Software für die Netzwerk-Monitoring-Plattform “Orion” von SolarWinds zu kompromittieren und für den Transport von Malware zu missbrauchen. Fast 100 Kunden waren davon betroffen, darunter auch US-Regierungsbehörden, Microsoft und das Cybersicherheits-Unternehmen FireEye.

Foto: SolarWinds/CSOonline.com

Den Angreifern war es gelungen, sich Zugang zur IT-Infrastruktur von SolarWinds zu verschaffen, um mit einem Trojaner kontaminierte Updates für die Orion-Software zu erstellen. FireEye, das diesen Angriff auf die Softwarelieferkette zuerst entdeckte, wies auf die sorgfältige Planung und die manuelle Interaktion der Cybergangster hin.

SolarWinds holte sich sofort Hilfe

IT-Sicherheitsexperten fanden nicht nur den Angriff bemerkenswert, sondern auch die Reaktion von SolarWinds. Das Unternehmen holte sich sofort kompetente Hilfe von außen – nicht nur um die unmittelbare Krise zu bewältigen, sondern auch um seine internen Sicherheitsabläufe zu überprüfen und eine Strategie zu entwickeln, die einen besseren Schutz vor künftigen Angriffen bietet. SolarWinds hat sein Wissen über den Vorfall und die Schritte, die zur Verbesserung der eigenen Sicherheitslage unternommen wurden, offen kommuniziert.

CSO sprach mit Tim Brown, CISO und Vice President of Security bei SolarWinds, darüber, wie der Vorfall den Sicherheitsansatz des Unternehmens verändert hat. Brown ist sowohl für die Produkt- als auch für die interne Sicherheit verantwortlich.

SolarWinds-CISO Tim Brown im Gespräch

Wie hat sich Ihre Rolle als CISO seit dem Angriff verändert?

Brown: Vor dem Angriff habe ich mich nicht unbedingt als CISO bezeichnet, weil ich mich nicht nur um die Sicherheitsabläufe, sondern auch um die Produktsicherheit konzentriert hatte. Mein Ziel war immer eine Mischung aus Produkt- und Betriebssicherheit. In einer Produktentwicklungs-Umgebung ist es wichtig, diese Mischung zu haben.

Wie haben Sie, nachdem sich der Nebel nach dem Vorfall gelichtet hatte, entschieden, wie es weitergehen soll?

Brown: Der erste Schritt war, dass wir CrowdStrike für Makro-Inspektionen hinzugezogen haben, um alles genauestens zu analysieren. Die haben etwa fünf Monate lang mit uns zusammengearbeitet und wirklich alles im Detail untersucht, jede Workstation und jeden Server. Gleichzeitig haben wir das forensische Team von KPMG gebeten, sich die Technik- und Entwicklungsumgebungen mit entsprechenden Mikro-Inspektionen vorzunehmen.

Um die Effizienz zu steigern, konzentrierte sich CrowdStrike also auf die Makro- und KPMG auf die Mikroebene. In den ersten ein bis zwei Monaten trafen wir uns täglich mit ihnen und erhielten eine Punch-Liste mit der Auflistung über die Dinge, die wir uns genauer ansehen sollten. Es zeigte sich, dass wir einen noch besseren Überblick über die gesamte Umgebung brauchten. Vor dem Vorfall hatten wir unser eigenes Security Operations Center (SOC) betrieben, ein durchaus brauchbares SOC übrigens, mit einer ausgezeichneten Abdeckung. Jetzt überwachen wir die Workstations und Server mit CrowdStrike Falcon.

SecureWorks übernimmt unsere AWS-, Firewall-, Azure-, Microsoft-365- und alle Workstation- und Server-Informationen von CrowdStrike. Die Sichtbarkeit hat sich erhöht, aus einem SOC sind im Grunde drei geworden – und zwar 7×24. Diese Sichtbarkeit hat dazu geführt, dass wir einen viel detaillierteren Einblick haben.

Eine weitere Änderung war, dass unser Red-Team jetzt nicht mehr Teilzeit, sondern Vollzeit eingesetzt wird. Dadurch konnten wir mehrere Rollen einrichten, das interne Red Teaming der Infrastruktur etwa oder das regelmäßige Testen aller Kontrollmechanismen, die wir eingerichtet haben, um sicherzustellen, dass unser SOC die richtigen Dinge abfängt. Wir führen in regelmäßigen Abständen interne Pen-Tests für jede Lösung durch und machen auch externe Pen-Tests. Außerdem arbeiten wir eng mit den Software-Engineers zusammen, die ihre eigenen internen Sicherheitstests durchführen.

“Jemand ist in unser Haus eingebrochen”

Wie hat sich der Mindset im Unternehmen in Bezug auf Sicherheitsthemen verändert?

Brown: Meine Leute haben mir früher immer gesagt, es sei nicht einfach Entwickler dazu zu bringen, ihr Verhalten zu ändern und über Sicherheit nachzudenken. Bei diesem Vorfall war das anders, unsere Entwickler waren besonders aufgebracht. Jemand ist in ihr Haus eingebrochen und hat ihre Umgebung verändert. Für uns ist es wichtig, dass die Entwickler bei allem, was wir tun, ganz vorne mit dabei sind. Sie sind mit dem Thema Sicherheit heute bestens vertraut.

Eine unserer Säulen für den Ansatz Security by Design sind die Menschen, es geht darum, eine Kultur der Sicherheit zu schaffen. Das ist ein kontinuierlicher Prozess. Wir führen Schulungen durch, fördern die Berichterstattung und beziehen alle Kolleginnen und Kollegen ein. Ich glaube nicht, dass Sudhakar Ramakrishna, unser CEO, ein Meeting mit allen Mitarbeitern abhält, ohne über Sicherheit zu sprechen.

Genauso wichtig ist das Thema heute für unser Vertriebsteam, dessen Mentalität sich geändert hat. Für unsere Kunden ist Sicherheit im Moment das wichtigste. Damit ist sie für uns keine interne Angelegenheit, sondern ein wichtiger Business Enabler.

Sie sind nicht die einzigen: Softwareunternehmen, auch außerhalb der Sicherheitsbranche, thematisieren vermehrt ihre Sicherheitsfunktionen.

Brown: Ganz genau. Wir stellen fest, dass unsere Kunden immer komplexere und detailliertere Fragen zu unseren Sicherheitsprozessen stellen. Das ist gut so. Sie bringen so die Sicherheitsunternehmen oder sonstigen Softwareunternehmen auf den richtigen Weg.

Welche Anleitungen oder Tools geben Sie Ihren Kunden an die Hand, um Bedrohungen in der Lieferkette zu entschärfen?

Brown: Wir hatten Informationen zu den Sicherheitseinstellungen von Konfigurationen früher an mehreren verschiedenen Stellen gelagert. Nach dem Vorfall haben wir sie in einem Dokument zusammengefasst, und können nun sagen: Das ist der Weg zu einer sicheren Implementierung!

Vor allem bei den On-premises-Lösungen ist eine enge Zusammenarbeit mit den Kunden wichtig. Wir brauchen ihre Mitarbeit, um die richtigen Maßnahmen zu ergreifen und optimal zu konfigurieren. Leider bekommen wir nicht immer einen detaillierten Einblick, wie die Kunden selbst ihre Einstellungen vorgenommen haben. Manchmal sprechen die gar nicht mit uns darüber, sie nehmen dann einfach das Produkt und installieren es. Es ist aber wichtig, dass Kunden wissen, wie sie die Plattform angemessen und sicher konfigurieren, überwachen und verwalten.

Bieten Sie Ihren Kunden heute mehr Einblick in Ihr gesamtes Ökosystem und die von Ihnen genutzten Dienste?

Brown: Wir legen offen, welche Tools wir verwenden. Wir sagen: “Kunde, wir verwenden Checkmarx für die statische Codeanalyse und WhiteSource, um Open Source zu prüfen.” Wir werden künftig auch mehr über unseren SDL-Prozess (Secure Development Lifecycle) sprechen und über die Sicherheitsvorkehrungen, die wir dort einbauen.

Ehrlich gesagt waren wir vor dem Vorfall ziemlich vage in unseren Aussagen, weil es sich um ein On-Premises-Produkt handelt. Damals haben wir uns gesagt: was interessiert es die Kunden, wie wir entwickeln und schützen. Da sind wir inzwischen sehr viel weiter. Ich spreche mit vielen anderen CISOs, und alle bestätigen, dass sie genauer nachfragen. Ihre Fragebögen werden immer größer, die Informationen, die sie anfordern, sind nicht immer leicht anzubringen. Die CISO erwarten eine offene Kommunikation, und das ist gut für die Branche.

Einige Dinge haben Sie noch nicht implementiert, planen dies aber – zum Beispiel das Least-privileged-Access-Modell für den Zugang zu Produkten oder interens Auditing. Haben Sie einen Zeitplan dafür?

Brown: Interne Audits für alles, also von der Codezeile bis hin zum Produkt, werden voraussichtlich im ersten Quartal 2022 eingeführt. Das Least-privileged-Modell für Produkte hat bereits mit der Dokumentation und der ersten Implementierung begonnen.

Das ist erst der Anfang. Wir haben bereits Änderungen in Bezug auf Agenten und andere Dinge vorgenommen, um den Leuten zu vermitteln, wie sie konfigurieren sollten, wenn sie Daten von diesem Agenten sammeln. Wir haben das so umgesetzt, dass das Alert-System unter einem anderen Account läuft, für dessen Zugang es eine besondere Berechtigung braucht.

Der nächste Schritt ist die Integration mit Systemen für das Berechtigungsmanagement, so dass wir nicht keine Passwörter innerhalb unseres Produkts für verschiedene Berechtigungen benötigen. Wir können diese Berechtigungen dann aus einem genehmigten Passwortverwaltungs-System herausholen. All diese Maßnahmen zielen darauf ab, dass wir die erforderlichen minimalen Zugangsberechtigungen haben, aber dennoch in der Lage sind, alle angebotenen Funktionen auszuführen.

Und das würde Kunden unterstützen, die vielleicht nicht so strenge Zugangskontrollen eingerichtet haben, wie sie sollten?

Brown: Ganz genau. Es würde Sicherheitsvorkehrungen automatisch auf die richtige Ebene bringen. Während des Vorfalls haben wir das Orion Assistance Program für unsere Partner eingeführt. Sie haben den Kunden nicht nur bei ihren Upgrades sondern auch mit der Überprüfung der Konfiguration geholfen.

Incident-Response-Prozess regelmäßig prüfen

Was sollte die Softwarebranche tun, um alle Beteiligten besser vor Angriffen auf die Lieferkette zu schützen?

Brown: Jedes Unternehmen sollte sicherstellen, dass sein eigenes Haus in Ordnung ist. Sie müssen darauf vorbereitet sein, dass diese Angreifer auch in ihre Umgebung eindringen können. Halten Sie einen Plan für den Fall bereit, dass es dazu kommt. Und prüfen Sie Ihren Incident-Response-Prozess regelmäßig.

Zweitens sollten Softwareanbieter ihre Produkte so gestalten, dass sie gegen unsachgemäße Konfiguration und Angriffe gut gewappnet sind. Konfigurationsanleitungen und -Tools helfen den Kunden beim Einrichten ihrer Umgebung, so dass diese widerstandsfähig wird.

Insgesamt muss die Softwarebranche mehr Mut zu Transparenz zeigen. (…) Sie sollte die Grundlagen schaffen und dazu beitragen, dass Entwicklungs-Frameworks und Informationen über die Entwicklungszyklen offenliegen. Das wird zur Sicherheit der Umgebung beitragen und sie widerstandsfähig gegen Angriffe machen.

Was empfehlen Sie anderen CISOs, die ihr Unternehmen vor Angreifern schützen müssen?

Brown: Zunächst mal sollte man sich darüber klar werden, dass es sich nicht um irgendwelche Angreifer handeln muss, sondern das ein ganzer Nationalstaat mit seiner Infrastruktur dahinterstecken kann. Und solche hochprofessionellen Akteure sind geduldig, äußerst umsichtig und unauffällig. Sie befinden sich auf einer Mission. Die Gegner, mit denen wir es immer mehr zu tun bekommen, vereinen all diese Eigenschaften auf sich. Wir reden hier zunehmend von organisiertem Verbrechen.

Wenn man nicht versteht, worauf die Gegner eigentlich aus sind, sollte man sich mit der eigenen Umgebung beschäftigen. Was könnte für Angreifer interessant sein? Es geht also darum, die Visibilität in der eigenen Umgebung zu erhöhen, um jederzeit alles beobachten zu können und die Kontrolle zu haben.

Aus der Entwicklungsperspektive sollten Unternehmen sicherstellen, dass sie die bekannten Schwachstellen managen und dafür einen geeigneten Prozess etabliert haben. Natürlich sollte man die Reaktion auf Vorfälle üben, aber jeder Angriff sieht am Ende anders aus. Wenn etwas von größerem Ausmaß passiert, muss man mit seinen Prozessen und Verfahren bereit sein. Wir waren zwei Wochen lang jeden Morgen bis zwei Uhr morgens im Einsatz, einfach weil es so viel zu tun gab.

Wichtig ist auch, die richtigen Leute auf Kurzwahl zu haben, man kann nicht alles selbst machen. Ziehen Sie Profis hinzu, die so etwas schon einmal gemacht haben. Kommunikation, Response, Investigation – all diese Dinge erfordern es, erfahrene Leute hinzuziehen, die so etwas schon einmal erlebt haben.

Ungefähr ein Jahr vor dem Vorfall bei uns haben wir einen Prozess eingeführt, der vorsieht, dass für jeden Bug – egal ob extern, in unserer Organisation oder in unseren Produkten aufgetaucht – wie bei einem normalen Bug ein Jira-Ticket aufgenommen wird, allerdings versehen mit einem Sicherheits-Tag und einem CVSS-Score. Mein Sicherheitsteam wacht darüber. Wenn wir das Problem mit unseren internen SLAs nicht lösen können, durchläuft der Vorfall unseren RAF-Prozess (Risk Assessment Form). Dann müssen der Engineering-Chef und ich das Risiko abzeichnen. Das hebt den Umgang mit Schwachstellen im Produkt auf ein angemessenes Niveau, um Entscheidungen darüber zu treffen, ob etwas behoben wird und wie es behoben wird.

Es müssen Prozesse vorhanden sein, die sicherstellen, dass man beim Schließen der Schwachstellen vorankommt. Nicht immer verschafft sich wie in unserem Fall ein externer Angreifer Zugang und verändert den Softwarecode. Es kann auch ein Akteur sein, der eine Zero-Day-Lücke in Ihren Produkten entdeckt und diese ausnutzt. Stellen Sie also sicher, dass Sie in beiden Bereichen abgesichert sind.