SolarWinds-CISO im Interview: “Mehr Offenheit ist gut für die Branche”

Foto: Forge Productions – shutterstock.com

Ende 2020 gelang es einer kriminellen Hackergruppe (vermutlich die in Russland ansässige Bande namens Cozy Bear, beziehungsweise APT29), die Orion-Update-Software von SolarWinds zu kompromittieren und sie so in ein Massentransportvehikel für Malware zu verwandeln. Dazu verschafften sich die Angreifer Zugang zur IT-Infrastruktur von SolarWinds und erstellten trojanisierte Software Updates. Diese wurde an knapp 100 Kunden ausgeliefert, die die Netzwerk-Monitoring-Software einsetzen – darunter auch Regierungsbehörden und das Sicherheitsunternehmen FireEye.

Dabei schätzen Security-Experten nicht nur den Angriff an sich als bemerkenswert ein, sondern auch die Reaktion von SolarWinds: Das Unternehmen holte sich schnell kompetente Hilfe von außen. Nicht nur, um die unmittelbare Krise zu bewältigen, sondern auch um Sicherheitsprozesse auf den Prüfstand zu stellen und eine Strategie zu entwickeln, die künftig besseren Schutz vor Angriffen auf die Software-Lieferkette gewährleistet. Darüber hinaus hat SolarWinds sowohl sein Wissen über den Sicherheitsvorfall als auch die Schritte zur Optimierung des Security-Niveaus offen kommuniziert.

Im Interview mit CSO spricht Tim Brown, CISO und Vice President of Security bei SolarWinds, darüber, wie der schlagzeilenträchtige Angriff sein Unternehmen verändert hat.

“Über Sicherheit wird auf allen Ebenen gesprochen”

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

Tim Brown: Vor dem Angriff habe ich mich nicht unbedingt als CISO bezeichnet, weil ich mich sowohl auf die Sicherheitsabläufe als auch auf die Produktsicherheit und -strategie konzentriert habe. In einer Produktentwicklungsumgebung ist dieser Mix wichtig. Wir liefern in erster Linie Produkte aus, daher ist es sehr wichtig, dass unser Security-Team in beide Bereiche eingebunden ist.

Wie haben Sie entschieden, wie es weitergehen soll, nachdem sich der Staub gelegt hatte?

Brown: Im ersten Schritt haben wir während der Untersuchung die Experten von CrowdStrike hinzugezogen, um Makroinspektionen vorzunehmen. Wir haben circa fünf Monate lang gemeinsam wirklich alle Details jeder Workstation und jedes Servers untersucht. Gleichzeitig haben wir das IT-Forensik-Team von KPMG dazugeholt, weil wir auch Spezialisten brauchten, die sich auf die Technik- und Entwicklungsumgebungen konzentrieren und anschließend Mikroinspektionen durchführen.

Um die Effizienz zu steigern, konzentrierte sich CrowdStrike auf die Makroebene, KPMG auf die Mikroebene. In den ersten ein bis zwei Monaten haben wir uns täglich getroffen und von beiden Parteien eine Auflistung der Dinge bekommen, die wir uns ansehen sollten.

Ein Ergebnis dieser Untersuchung war, dass wir einen besseren Blick auf unsere gesamte Umgebung brauchen. Vor dem Angriff habe ich mein eigenes SOC betrieben – ein sehr vernünftiges mit guter Abdeckung. Nun werden die Workstations und Server mit CrowdStrike Falcon überwacht. SecureWorks übernimmt dann von CrowdStrike die Daten zu AWS, Firewalls, Azure, Microsoft 365 und allen Workstations und Servern. Das bisherige SOC wird so zu einem dritten SOC – die Sichtbarkeit hat sich von einem SOC auf drei erhöht, 7×24. Das hat sich für uns bewährt, nun haben wir unsere gesamte Umgebung im Blick.

Foto: SolarWinds

Eine weitere Änderung bestand in der Umstellung unseres Red-Teaming-Ansatzes von Teil- auf Vollzeit. So konnten wir mehrere Rollen übernehmen. Eine davon ist das interne Red Teaming der Infrastruktur: Hierbei werden alle Kontrollen, die wir eingerichtet haben, überprüft. So stellen wir sicher, dass diese ausreichen und unser SOC die richtigen Dinge abfängt.

Wir führen in regelmäßigen Abständen auch interne und externe Penetrationstests für jede Lösung durch – so haben wir einen komplementären Ansatz. Außerdem arbeiten wir eng mit dem Engineering zusammen, wo noch einmal eigene, interne Sicherheitstests absolviert werden. Auf diese Weise verdreifacht sich die Zahl der Sicherheitstests durch mehrere Parteien: extern, intern mit meinem Team und intern mit dem Entwicklungsteam.

Wie hat sich das Sicherheitsdenken des Unternehmens für Ihr Team und das Unternehmen im Allgemeinen verändert?

Brown: Ich höre von diversen Leuten, dass es immer Probleme damit gebe, Entwickler dazu zu bringen, sich mit Sicherheit zu beschäftigen. Ein Vorwurf, der unsere Developer Community verständlicherweise aufbringt. Bei all unseren Bemühungen sind die Entwickler ganz vorne mit dabei – und sie sind mit dem Thema Sicherheit im Allgemeinen sehr vertraut.

Eine unserer Säulen, wenn es darum geht, “Secure by Design” umzusetzen, sind die Menschen – also die Etablierung einer Sicherheitskultur. Dabei handelt es sich um einen fortlaufenden Prozess: Wir führen Schulungen durch, fördern das Reporting und beziehen alle Mitarbeiter ein. Und ich glaube nicht, dass unser CEO Sudhakar Ramakrishna ein Meeting mit allen Mitarbeitern abhält, ohne über Security zu sprechen. Über Sicherheit wird auf allen Ebenen gesprochen.

Der andere Teil kommt aus dem Vertriebsteam und der Sales-Mentalität: Für unsere Kunden ist Sicherheit im Moment das Wichtigste. So bleibt die Security keine interne Angelegenheit und wird auch zum Business Enabler.

“Wir legen offen, welche Tools wir verwenden”

Softwareunternehmen, auch außerhalb der Sicherheitsbranche, wollen jetzt über ihre Sicherheitsfunktionen sprechen.

Brown: Ganz genau. Wir stellen fest, dass unsere Kunden immer komplexere und detailliertere Fragen zu unseren Sicherheitsprozessen stellen. Ich halte das für eine gute Entwicklung. Es ermöglicht den Kunden, die Security-Unternehmen auf den richtigen Weg zu bringen oder Produkthersteller in die richtige Richtung zu drängen und sie darüber aufzuklären, worauf sie achten sollten.

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

Brown: Vor dem Angriff hatten wir sichere Konfigurationsinformationen an vielen verschiedenen Stellen. Nach dem Vorfall haben wir diese in einem Dokument – und einem eigenen Bereich – zusammengefasst.

Vor allem bei On-Premises-Lösungen ist es eine Partnerschaft mit dem Kunden: Wir brauchen sie, um die richtigen Maßnahmen zu ergreifen, und wir brauchen sie, um die richtige Konfiguration vorzunehmen. Wir haben allerdings nicht immer Einblicke in die Konfiguration der Kunden. In einigen Fällen sind sie komplett auf sich allein gestellt und sprechen uns auch nicht an, sondern installieren einfach das Produkt. Es ist essenziell, zu wissen, wie das Produkt angemessen und sicher konfiguriert, überwacht und verwaltet wird.

Bieten Sie tiefere Einblicke in Ihr Ökosystem und die von Ihnen genutzten Dienste?

Brown: Wir legen offen, welche Tools wir verwenden. Etwa Checkmarx für die statische Codeanalyse oder WhiteSource, um Open-Source-Produkte zu prüfen.

Wir werden mehr über unseren Secure-Development-Lifecycle-Prozess und die Sicherheitsvorkehrungen sprechen, die wir in die Umgebung einbauen. Und ehrlich gesagt waren wir – wie die meisten Anbieter vor dem Vorfall – ziemlich vage unterwegs, weil es sich um ein On-Premises-Produkt handelt. Vor dem Angriff hat es nur wenige interessiert, wie wir entwickeln. Jetzt will es jeder wissen, was ein guter Schritt nach vorne ist. Ich spreche auch mit anderen CISOs, die feststellen, dass die Fragebögen härter und die Informationen, die sie anfordern, komplexer werden. Sie fordern mehr Offenheit – das ist gut für die Branche.

Sie haben einige Dinge erwähnt, an denen Sie arbeiten, die aber noch nicht implementiert sind, wie das Least-Privilege-Access-Modell für Produkte und die interne Revision. Haben Sie dafür einen Zeitplan?

Brown: Interne Audits, von der ersten Codezeile bis hin zum Produkt, werden voraussichtlich im ersten Quartal 2022 durchgeführt. Das Least-Privilege-Access-Modell für Produkte wird bereits angewandt.

Das ist ein Anfang. Wir haben bereits Änderungen in Bezug auf Agenten und andere Dinge vorgenommen, um den Leuten Ideen zu vermitteln, wie sie konfigurieren sollten, wenn sie Daten von diesem Agenten sammeln. Zum Beispiel haben wir dafür gesorgt, dass das Warnsystem über ein anderes Konto läuft, das sich mit entsprechenden Berechtigungen ausstatten lässt.

Der nächste Schritt ist die Integration von Privilege-Management-Systemen, um von Passwörtern unabhängig zu werden. All diese Maßnahmen zielen darauf ab, minimale Berechtigungen erforderlich zu machen, dabei aber alle Funktionen aufrechtzuerhalten.

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

Brown: Ganz genau. Es würde für einige Kunden Sicherheitsvorkehrungen auf bestimmten Ebenen einziehen. Während des Vorfalls haben wir das Orion Assistance Program mit unseren Partnern verwirklicht, die die Kunden bei Upgrades und der Überprüfung der Konfiguration unterstützt haben.

“Man kann nicht alles selbst machen”

Was sollte die Softwarebranche tun, um alle Beteiligten besser vor Supply-Chain-Angriffen zu schützen?

Brown: Zunächst sollten sie sicherstellen, dass ihre eigenen Unternehmen auf Angreifer vorbereitet sind, die in ihre Umgebungen eindringen wollen. Gelingt das, braucht es einen Notfallplan. Darüber hinaus empfiehlt es sich, die Prozesse einzuüben, die bei der Reaktion auf Vorfälle ablaufen sollen.

Zweitens sollten die Produkte für die Kunden so gestaltet sein, dass sie gegen unsachgemäße Konfiguration und Angriffe im Allgemeinen besser gewappnet sind. Egal, ob es sich dabei um Anleitungen oder Tools handelt – es geht immer darum, den Kunden bei der richtigen Konfiguration ihrer Umgebung zu unterstützen und sie damit widerstandsfähiger zu machen.

Aus Sicht der Branche geht es bei der Umsetzung von US-Präsident Bidens Anordnungen um mehr Transparenz. Es geht um Software und alle Komponenten, die in ihren Produkten verwendet werden und darum, diese zu veröffentlichen. Es geht auch darum, Entwicklungs-Frameworks und -Zyklen zu verstehen und Informationen darüber zu geben, wie diese ausgestaltet sind.

Im Sinne der Transparenz ist das ein Schritt in die richtige Richtung: Die Softwarebranche sollte sich dieser Realität stellen und nicht nur die Grundlagen schaffen, sondern dazu beitragen, dass die Frameworks und Informationen, die wir offenlegen, wirklich zur Sicherheit der Umgebung beitragen und sie widerstandsfähiger gegen Angriffe machen.

Was ist die wichtigste Aufgabe, die CISOs erledigen sollten, um sich gegen Supply-Chain-Angriffe dieser Qualität zu wappnen?

Brown: Jeder sollte sich über das Niveau des Bedrohungsakteurs bewusst sein. “Nation-State” ist keine Filmrequisite, sondern ein sehr realer Bedrohungsakteur, der geduldig, äußerst umsichtig, zielstrebig und sehr leise ist. All diese Attribute erschweren es, diese Bedrohung zu erkennen und zu bekämpfen, doch es sind die Gegner, mit denen wir es heute zu tun haben. Die gleichen Vorgehensmodelle werden sich auf das organisierte Verbrechen verlagern.

Wenn Sie nicht verstehen, worauf die Angreifer aus sind, fangen Sie dort an: Beginnen Sie damit, Ihre Umgebung zu verstehen und verschaffen Sie sich schnell einen umfassenden Überblick über Ihre Umgebung. Vergewissern Sie sich, die entsprechenden Sicherheitsvorkehrungen getroffen zu haben. Aus Entwicklungsperspektive sollten Sie sicherstellen, dass Sie die Schwachstellen angemessen managen, die Ihnen (oder Dritten) bekannt sind.

Zur Wahrheit gehört aber auch: Es ist egal, wie viel man übt, auf Vorfälle zu reagieren – am Ende wird ein realer Angriff immer anders ablaufen. Kommt es zu einem Vorfall dieser Größenordnung, müssen Prozesse und Verfahren einfach bereit sein. Wichtig ist zudem, die richtigen Leute auf Kurzwahl zu haben – man kann nicht alles selbst machen. Wenn man so etwas auf die Beine stellt, sollte man erfahrene Experten hinzuziehen.

Ungefähr ein Jahr vor dem Angriff haben wir einen Prozess eingeführt, der vorsieht, dass jeder Sicherheitsproblemfall – egal, ob er extern, mit unseren Tools oder irgendwo anders aufgezeichnet wird – in ein Jira-Ticket aufgenommen wird. Ebenso wie normale Fehler, aber mit einem Sicherheitskennzeichen und einem CVSS-Score versehen. Diese Tickets werden durch mein Sicherheitsteam überwacht. Wenn sie unsere interne SLA für die Lösung nicht erfüllen, durchlaufen sie unseren RAF-Prozess (Risk Assessment Form), bei dem sowohl ich als auch unser technischer Leiter das Risiko abzeichnen muss. Das hebt den Umgang mit Schwachstellen im Produkt auf ein angemessenes Niveau, um Entscheidungen darüber zu treffen, ob und wie etwas behoben wird.

Es müssen Prozesse vorhanden sein, die sicherstellen, dass Sie an der Schwachstellenfront vorankommen, denn es muss nicht unbedingt der Bedrohungsakteur sein, der in Ihre Umgebung eindringt und den Code verändert, so wie es bei uns der Fall war. Es könnte auch ein Bedrohungsakteur sein, der eine Zero-Day-Lücke in Ihren Produkten entdeckt und es schafft, diese auszunutzen. Sie sollten also alles daransetzen, in beiden Bereichen abgesichert zu sein.

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.