Über Transparenz, Skalierbarkeit und Beziehungen in der sicheren Entwicklung: Phil Guimond von ViacomCBS im Gespräch

Kürzlich habe ich mich mit Phil Guimond, Principal Cloud Security Architect bei ViacomCBS, ausgetauscht. Er beschreibt seine Rolle als eine elegante Umschreibung dafür, dass er sich gern um alles Mögliche kümmert. Dazu gehören Cloud-Sicherheit und -Architektur, Anwendungssicherheit, Penetrationstests sowie digitale Forensik und Incident Response – und gelegentlich auch Anbieterbewertungen und Risikomanagement. Er arbeitet in einem Team mit vielen unterschiedlichen Fachbereichen.

Wir hatten ein großartiges Gespräch, das ich gern mit Ihnen teilen möchte. Wir sprachen über Sicherheitspraktiken, moderne sichere Entwicklung und mehr. Ich hoffe, Ihnen gefällt das Gespräch genauso gut wie mir.

Zunächst fragte ich Phil, wie sein allgemeiner Sicherheitsansatz aussieht und worauf es seiner Meinung nach beim Aufbau eines Informationssicherheitsprogramms besonders ankommt.

Guimond: Mein Ansatz für Informationssicherheit beruht auf Transparenz, Skalierbarkeit und Beziehungen. Dieses System habe ich im Laufe der Jahre dank vieler großartiger Menschen entwickelt, mit denen ich zusammengearbeitet habe – darunter unser Streaming-CISO Jonathan Keith, der ein hervorragender Mentor für mich war. In den vergangenen Jahren habe ich als Berater an der Incident Response gearbeitet und festgestellt, dass viele Informationen fehlten. Keine Logs … nichts. Fast immer tappte ich völlig im Dunkeln und musste mich ganz auf standardmäßige CLI-Tools verlassen, um Probleme zu erkennen. Meine wichtigste Empfehlung nach jedem Vorfall war, ein geeignetes Logging-System aufzubauen, um Transparenz zu schaffen. Es spielt keine Rolle, wie viel Sie für Sicherheitstools ausgeben, wenn Sie nicht sehen können, was Sie schützen müssen oder was passiert ist, falls etwas kompromittiert wurde. Woher wissen Sie, was Sie schützen müssen, wenn Sie nicht sehen können, was passiert ist?

Transparenz gilt oft als wichtiger Indikator, mit dem wir Risiken und Erkenntnisse im gesamten Unternehmen priorisieren können. Mich interessierte, wie Phil Transparenzdaten in seiner täglichen Arbeit einsetzt.

Guimond: Transparenz ermöglicht es uns, auf eine enorme Zahl von Problemen zu reagieren – ganz gleich, ob es sich um alte, neue oder aufkommende Bedrohungen handelt. Mit Transparenz können Sie so viel anfangen, dass es manchmal geradezu verblüffend ist. Es ist wirklich spannend, wenn Sie auf etwas Neues stoßen und Ihre Transparenz-Tools Ihnen genau zeigen, was passiert ist. Transparenz verbessert Incident Response, Penetrationstests, Anwendungssicherheit, Cloud-Sicherheit, Risiko- und Schwachstellenmanagement und eigentlich so ziemlich alles ganz erheblich.

Bei Supply-Chain-Angriffen mit kompromittierten Open-Source-Bibliotheken oder Schwachstellen in Open-Source-Bibliotheken können Sie erkennen, welche Anwendungen diese Bibliotheken verwenden, und sie schnell aus Ihren Projekten entfernen, aktualisieren oder selbst korrigieren. Bei einer kompromittierten Cloud- oder Netzwerkinfrastruktur können Sie rasch herausfinden, wer dafür verantwortlich ist, wo der Angriff seinen Ursprung hatte und was die Angreifer mit den angegriffenen Ressourcen gemacht haben. Und vor allem: welche schlechte Praxis zu dieser Kompromittierung geführt hat. Anschließend können Sie die betroffenen Ressourcen ganz einfach von der Infrastruktur isolieren und alle nicht autorisierten Aktionen auf einmal unterbinden. Oder wenn der Laptop eines Mitarbeiters kompromittiert wurde, können Sie sehen, was der Angreifer mit den Zugangsdaten unternommen hat und auf welche Ressourcen er zugreifen wollte.

Beim Aufbau umfangreicher Informationssicherheitsprogramme ist es wichtig, möglichst viele Bereiche im Blick zu haben. Sie möchten wissen, welche Technologien Sie verwenden, welche Open-Source-Bibliotheken in einem Projekt vorhanden sind und wie Ihre gesamte Cloud-Infrastruktur aussieht – einschließlich IAM-Richtlinien, Buckets, Containern, Infrastructure as Code und Ähnlichem.

Alle oder zumindest die meisten Ihrer Probleme sehen zu können, ist ein großer Vorteil. Sie erkennen, welche Teams gute Praktiken anwenden und dadurch bessere Ergebnisse erzielen – und welche nicht. Wenn Sie Teams entdecken, die keine Best Practices anwenden, ist das die perfekte Gelegenheit, auf sie zuzugehen und ihnen zu helfen. Sobald Entwickler Best Practices anwenden, verschwinden die meisten Schwachstellen plötzlich. Außerdem können Sie ihnen so direkt bei der Arbeit praktische Schulungen anbieten. Natürlich reicht Transparenz allein nicht aus: Sie müssen Probleme auch in großem Umfang beheben können, sonst sind Sie ständig damit beschäftigt, Brände zu löschen.

Die letzten beiden Punkte sind mir sehr wichtig. Erstens muss man erkennen, dass es nicht nur darum geht, Probleme zu finden, sondern auch darum, auf die Erkenntnisse zu reagieren. Zweitens muss man dafür sorgen, dass die Voraussetzungen für Skalierung gegeben sind. Mit unternehmensweiten Daten können Sie den Status und die Abdeckung Ihrer Produktteams ermitteln und diese Daten in Ihre Risikobewertung einbeziehen. Wenn Sie teamübergreifend skalieren, bevor Sie bereit sind, verteilen Sie womöglich Probleme statt Best Practices. Ich fragte Phil, was Skalierbarkeit für ihn bedeutet.

Guimond: Für mich bedeutet Skalierbarkeit, etwas einmal zu tun und damit alles zu beheben. Wenn beispielsweise mehrere Projektteams jeweils eine bestimmte Funktion benötigen, lässt sich das Problem eines Dutzends Codebasen, die alle dasselbe tun und jeweils eigene Schwachstellen und Herausforderungen mit sich bringen, am einfachsten lösen, indem Sie ein zentrales Projekt entwickeln, das dieses Problem behebt, und es dann allen Teams zur Verfügung stellen. Im Grunde sollen Ihre Lösungen mit möglichst wenigen Maßnahmen und Projekten für möglichst viele Teams skalierbar sein. Dazu gehört auch, durch Best Practices bessere Ergebnisse zu erzielen.

Ich bin außerdem fest davon überzeugt, dass echte Skalierbarkeit ohne Transparenz nicht möglich ist. Wenn Sie nicht sehen können, was Sie schützen sollen, wie wollen Sie es dann schützen? Wissen Sie überhaupt, dass es existiert? In den meisten Fällen nicht – es sei denn, Sie verfügen über umfangreiches internes Wissen, das Sie sich durch jahrelange Arbeit im Unternehmen angeeignet haben. Was passiert, wenn die Person mit diesem ganzen Insiderwissen kündigt oder von einem Bus angefahren wird? Dann ist dieses Wissen plötzlich weg. Und Sie hätten weiterhin kaum Einblick in die Schwachstellen der Projekte. Dieser Ansatz ist überhaupt nicht skalierbar.

Fehlende Skalierbarkeit überfordert schnell Ihr Sicherheitsteam und die Entwickler, mit denen Sie zusammenarbeiten. Weder Sie noch Ihre Entwickler haben Zeit für diesen Ansatz. Auch bei der heutigen Vorgehensweise für Penetrationstests ist Skalierbarkeit ein großes Problem. Kriminelle interessieren sich ganz und gar nicht für Ihren Scope oder die wenigen kleinen Bereiche, die Sie getestet haben. Ich will Penetrationstests keineswegs schlechtreden. Ich halte sie für absolut notwendig, aber herkömmliche Pentests sind teuer und überhaupt nicht skalierbar. In der heutigen Cloud-First-Umgebung brauchen Sie unbedingt einen Infrastruktur-übergreifenden Ansatz für Pentests. Und dieser muss kontinuierlich sein. 

Wie Phil bereits erwähnte, kann eine zu schnelle oder ausbleibende Skalierung das Sicherheitsteam überfordern – insbesondere, wenn Prozesse, Dokumentation usw. noch nicht auf die Herausforderungen der Skalierung vorbereitet sind. Deshalb fragte ich Phil, wie er erfolgreich skaliert hat.

Guimond: Mit einem Transparenz-zuerst-Ansatz und der Konsolidierung von Tools in einer zentralen Übersicht. Ich weiß, das klingt abgedroschen, aber es funktioniert wirklich. Sie möchten den Alltag der Entwickler erleichtern, nicht erschweren. Sie zu zwingen, 25 verschiedene Sicherheitstools für ihre Projekte zu verwenden, ist absurd. So erntet man endlosen Widerstand, mangelnde Skalierbarkeit und Transparenz und deutlich weniger Interesse der Geschäftsbereiche an einer Zusammenarbeit mit den Sicherheitsteams.

Wenn Sie also einen Weg finden, ihnen das Leben leichter zu machen, indem Sie möglichst wenige Tools bereitstellen, die möglichst viele Probleme skalierbar lösen, erzielen Sie bessere Ergebnisse. Viel bessere. Das sorgt für mehr Transparenz und damit für ein Schwachstellenmanagement in großem Maßstab. Herkömmliches Schwachstellenmanagement ist nicht skalierbar – im Zeitalter des Cloud-Computing ist es überholt. Best Practices beseitigen die meisten Probleme. Bei den verbleibenden Problemen ist es wichtig, kompensierende Kontrollen einzurichten, wenn sich die Probleme nicht ohne eine umfassende Neugestaltung der Architektur beheben lassen.

Ich fragte Phil, welche Best Practices er anderen empfehlen würde, um möglichst aussagekräftige Transparenzdaten zu erhalten.

Guimond: Konsolidieren und abschaffen. Sie brauchen Tools, die schlechte Praktiken aufdecken UND Ihnen helfen, sie mit möglichst wenigen Schritten und möglichst wenigen Angeboten zu beheben. Außerdem müssen Sie Tools abschaffen, die Ihrem Sicherheitsteam oder Ihren Entwicklern keinen echten Mehrwert bieten. Wenn Sie Mitarbeiter einstellen, die sich ausschließlich um ein einzelnes Tool oder eine Gruppe von Tools kümmern, kann das zu Silos führen – und damit häufig zu einem Sicherheitsansatz, der nicht skalierbar ist.

Ihr Team sollte möglichst funktionsübergreifend aufgestellt sein. Geben Sie ihm also die Möglichkeit, sich auszuprobieren und auch andere Bereiche kennenzulernen, zusätzlich zu den Aufgaben, die es ohnehin unterstützt. Wenn einzelne Mitarbeiter den ganzen Tag in Besprechungen sitzen, bleibt die Arbeit liegen. Arbeiten Sie mit Anbietern zusammen, deren Produkte über eine solide API verfügen, die alle Informationen bereitstellt, die auch das zugehörige Dashboard anzeigt.

Um die Tools zu konsolidieren, können Sie mit Anbietern zusammenarbeiten, die große Teile Ihrer Infrastruktur mit einem einzigen Produktangebot schützen. Dazu gehören beispielsweise Open-Source-Bibliotheken, Container, SAST [static application security testing], Infrastructure as Code, Cloud-Inventar usw. Anschließend können Sie all diese Daten in ein Dashboard einspeisen, das sie in einer zentralen Übersicht oder in möglichst wenigen Ansichten darstellt. Sie sollten Probleme nach Kategorien aufschlüsseln können: Anwendung, Netzwerk, Infrastruktur oder sogar einzelnes Projekt.

Es ist entscheidend, die Unterstützung von Personen zu gewinnen, die helfen oder Vorgaben durchsetzen können, oder von denen, die die Arbeit tatsächlich erledigen und Dinge voranbringen. Ich fragte Phil, von wem man sich Unterstützung sichern sollte, bevor man sich daranmacht, Transparenz in den eigenen Teams zu schaffen.

Guimond: Wenn Sie ein unterstützendes Informationssicherheitsteam aufbauen, müssen Sie zunächst Beziehungen zu den Teams oder Geschäftsbereichen aufbauen, die Sie unterstützen. Gehen Sie auf sie zu, vereinbaren Sie ein Meeting, schreiben Sie ihnen in Slack – ganz gleich, was für Sie funktioniert – und sprechen Sie mit ihnen, um ihre Herausforderungen zu verstehen. Wenn Sie wissen, worin diese bestehen, können Sie besser einschätzen, wie Sie helfen können. Wenn Sie wissen, dass ein Team in der Vergangenheit bestimmte Sicherheitsprobleme hatte, sollten Sie eine Lösung entwickeln, die ihm hilft, diese Probleme zu beheben. Entwickler hören Ihnen zu, wenn Sie das tun.

Es ist sehr wichtig, den Direktoren, Managern, Entwicklern und Ingenieuren eines Teams zuzuhören und ihre Sichtweise zu verstehen – vor allem dann, wenn sie sich von Ihrer eigenen unterscheidet. Wenn Sie andere Perspektiven nicht akzeptieren und immer alles nach dem Motto „Friss oder stirb“ laufen muss, will niemand mit Ihnen zusammenarbeiten, und Ihr Informationssicherheitsprogramm wird schlechtere Ergebnisse erzielen. Sobald Sie jedoch diese Beziehungen aufgebaut haben, fällt es oft leicht, die nötige Unterstützung zu gewinnen. Die Menschen wissen, dass Sie ansprechbar sind und ihnen nicht ständig im Nacken sitzen. Anschließend führen Sie sie in Best Practices und Toolsets ein.

Zum Schluss fragte ich Phil, welchen allgemeinen Rat er jemandem geben würde, der in einem Unternehmen ein eigenes Sicherheitsteam und -programm aufbauen möchte.

Guimond: Stellen Sie ein vielfältiges, funktionsübergreifendes Team zusammen. Menschen mit einem anderen Hintergrund als Sie betrachten die Dinge aus einer anderen Perspektive. Wenn Sie andere Sichtweisen verstehen, können alle sich beruflich weiterentwickeln und die Innovation im Team fördern. Ich habe zum Beispiel mit einem Team gesprochen, das 20 verschiedene Projekte hatte, die alle exakt denselben Bedarf abdeckten. Jedes Team nutzte seine eigene Codebasis, und jede davon hatte eigene Sicherheitslücken. Also versuchten sie immer wieder, diese Probleme einzeln zu beheben. Mein Ansatz war, genau zu zeigen, wie ich typische Sicherheitslücken in diesem Projekt beheben würde. Doch dann sagte das Team etwas, das mich überraschte: Es hatte nicht nur diese Sicherheitslücken behoben, sondern auch ein einziges Projekt für denselben Bedarf erstellt, das alle Teams nutzen konnten. Damit entfiel das Hin und Her zwischen all den Codebasen, und es war nicht mehr nötig, 20 verschiedene Projekte einem Penetrationstest zu unterziehen. Jetzt müssen sie nur noch eines testen. Kommt Ihnen das bekannt vor? Genau dieses Beispiel hatte ich vorhin schon erwähnt!

Es ist also wichtig, offen zu bleiben, sich die Herangehensweisen anderer anzuhören und nicht zu erwarten, dass Sie in jedem Unternehmen immer wieder dasselbe tun. Jedes Unternehmen und jedes Team ist einzigartig.

Warum ist ein funktionsübergreifendes Team wichtig? Was passiert, wenn Sie mehrere Tools abschaffen, deren Nutzen die Kosten nicht mehr rechtfertigt? Die Teams, die diese Tools bisher betreut haben, müssen sich möglicherweise neu ausrichten. Wenn sie sich bereits weitere Kompetenzen angeeignet haben, können sie sich viel schneller an Veränderungen anpassen. Und die Informationssicherheit verändert sich ständig. So können sich die Teammitglieder beruflich weiterentwickeln, ohne das Unternehmen verlassen zu müssen – und Ihr Security-Team wird anpassungsfähiger.

Ich sage nicht, dass alle Alleskönner sein müssen. Es hilft aber sehr, wenn mehrere Teammitglieder verschiedene Rollen übernehmen können und sich gleichzeitig auf ihre Hauptaufgabe spezialisieren. Das ist die ideale Gelegenheit, Ihrem Team dabei zu helfen, neue Kompetenzen zu entwickeln und sich weiterzubilden. Wenn das Team die Möglichkeit hat, Neues zu lernen und sich beruflich weiterzuentwickeln, wird es auch für vielfältigere Bewerberinnen und Bewerber attraktiver.

Ihr Team sollte sich nicht ausschließlich auf eine einzige Sache konzentrieren, denn das schadet seiner beruflichen Entwicklung und bremst Ihr InfoSec-Programm aus. Und wenn Sie als Führungskraft das zulassen, haben Sie Ihr Team und Ihr Unternehmen im Stich gelassen. Sie haben dessen Karrierechancen eingeschränkt, indem Sie es in einem Silo arbeiten lassen. Nun ist auch Ihr InfoSec-Programm auf die von Ihnen festgelegten Grenzen beschränkt. Mit der Zeit führt die technische Schuld zu mehr blinden Flecken, geringerer Skalierbarkeit und deutlich mehr Sicherheitslücken.