Warum ich hier bin

Warum ich hier bin

Ulfar Erlingsson - Chief Architect

June 3, 2021

Bitte beachten Sie: Dieser Beitrag ist eine gekürzte Fassung des Interviews mit Úlfar Erlingsson“ durch das Forschungsteam von Sutter Hill Ventures. Hier finden Sie den Originalbeitrag: Artikel

Wie viele Leute, die im Bereich Security arbeiten, bin ich durch Zufall dazu gekommen. Mitte der 90er Jahre strebte ich eine Promotion an, als plötzlich das Internet aufkam – das heißt, jeder auf der Welt fing an, das Internet über einen Webbrowser zu nutzen. 

Es war sofort klar, dass das Internet eine unfassbar hohe Zahl an Security-Problemen verursachte, sodass es zunächst sogar so aussah, als würde diese Sache niemals funktionieren. In der Zwischenzeit arbeitete ich an einem zuverlässigen verteilten Computing – der Grundlage dessen, was heute als Cloud bekannt ist –, und all diese Bedenken in Sachen Security waren dort ebenfalls ein Thema. 

Auch wenn ich meine ganze Karriere im Bereich Security verbracht habe, hatte ich nie Interesse an dem reaktiven, regelbasierten Ansatz, der die Branche seit ihrer Gründung dominiert. 

Bei der Sicherung von Software-Aktivitäten gibt es zwei diametral entgegengesetzte Ansätze. Ein Ansatz besteht darin, Regeln zu erstellen, die bösartige Aktivitäten – potenzielle Fallstricke – erkennen und einen Warnhinweis senden, wenn eine Aktivität entdeckt wird, auf die diese Regeln zutreffen. Das ist so ziemlich die Art und Weise, wie die gesamte Security-Branche seit den 1980er Jahren funktioniert. Die ersten Anbieter von Antivirenprogrammen haben signaturbasierte Antiviren entwickelt, und seitdem haben alle erfolgreichen Unternehmen im Bereich Software Security in erster Linie denselben Ansatz verfolgt.

Der entgegengesetzte Ansatz besteht darin, den tatsächlichen Workload des Kunden zu verstehen und zu bestimmen, was die Software tun soll, anstatt zu sagen, was sie nicht tun soll. Auf den ersten Blick sieht das nach einer viel einfacheren Aufgabe aus. Die Menge der Aktivitäten, die eine Software ausführen sollte, ist viel kleiner als die (abzählbar) unendliche Menge der Aktivitäten, die sie niemals ausführen sollte. Dieser Ansatz wird als Erkennung von Verhaltensanomalien bezeichnet und ermöglicht es uns, Security durchzusetzen, indem wir sicherstellen, dass nur die Dinge geschehen, die auch tatsächlich geschehen sollen. 

Obwohl die Erkennung von Verhaltensanomalien in der Theorie einfach ist, gestaltet sich die Umsetzung in die Praxis tatsächlich ziemlich schwierig. Aus vielerlei Gründen war das Lernen dessen, was normal ist, unglaublich schwierig, und historisch gesehen war es nicht skalierbar. In der Welt der großen Rechenzentren verfügten Unternehmen einen Haufen spezieller Software und Hardware, die sie üblicherweise über Jahrzehnte hinweg zusammengeschustert hatten. Zu bestimmen, was für ein Unternehmen funktionierte, hatte so gut wie keine Bedeutung für das, was für das nächste funktionieren würde, und es war daher unmöglich, wiederholbare Erfolge zu erzielen.

In der Cloud ist das anders. Die meisten Cloud-nativen Unternehmen sind sich tatsächlich recht ähnlich. Wir können mit ihnen zusammenarbeiten, um kontinuierlich zu verbessern, was wir tun, und bessere Erkenntnisse darüber zu gewinnen, und wir können überwachen, wie gut unsere Arbeit ist. Wir scheitern seltener als die Konkurrenz, und jedes Mal, wenn wir es doch tun, nutzen wir es als Chance, unseren Blickwinkel zu verändern und eine Menge anderer ähnlicher Arten von Problemen in Zukunft zu verhindern. Unsere Konkurrenz steht dagegen vor der ewigen Sisyphusaufgabe, eine vollständige Liste von benutzerdefinierten Regeln zu pflegen.

Bei Lacework ist es uns wirklich gelungen, ein erstklassiges Security-Produkt zu entwickeln, das auf dem Ansatz basiert, genau zu verstehen, was in der Umgebung unserer Kunden normal ist, und Abweichungen von diesem Gefühl von Normalität sofort zu melden. Es ist eine grundlegende Veränderung in der Art und Weise, wie Security gemacht wird. Es ist eine grundlegende Veränderung, die uns einzigartig macht – nicht nur durch unseren praktischen Ansatz zur Cloud-Security, sondern auch in Bezug darauf, wie wir den Wert und die Parameter der Security definieren.

Die entscheidende Technologie zur Durchsetzung dieses Werteverständnisses ist unser Polygraph. Ein Polygraph ist im Grunde eine virtuelle, abstrakte Ansicht dessen, was in der Cloud des Kunden passiert. 

Zu den konkreten Details dessen, was in der Cloud passiert, gehören Dinge wie das Starten von Prozessen, das Erledigen der Arbeit von Mitarbeitern und die Migration von Dingen zwischen den einzelnen Rechnern. Alles ist dort im Fluss. IP-Adressen sind nicht statisch. DNS-Namen sind nicht statisch. Selbst die Prozesse und Aufträge sind nicht statisch. Viele kleine Unternehmen sind zu Microservices übergegangen, die vielleicht nur ein paar Sekunden oder Minuten laufen. In großen Unternehmen waren dagegen üblicherweise Infrastrukturkomponenten wie Client-Server-Computing zu finden, bei denen die gesamte Arbeit des IT-Supportteams ausschließlich darin bestand, diese Komponenten monatelang ohne Ausfallzeiten am Laufen zu halten. Die heutige Cloud ist eine Abstraktion davon, stellenweise in Form von Mikroservices – von denen keiner länger als 30 Sekunden läuft. Aber diese kurzlebigen Services sind tatsächlich eine Komponente und ein wesentlicher Teil dessen, was der Kunde tut.

Diese kurzlebigen Services haben auch eigene Verhaltensweisen. Wenngleich sie nur für kurze Zeit laufen, erhalten sie ihre Daten von irgendwoher und beantworten Fragen, die von irgendwoher kommen. Indem wir zuerst feststellen, dass eine kurzlebige Cloud an Aktivitäten tatsächlich eine Komponente ist, das Gleiche dann für die Komponenten tun, mit denen die Komponente kommuniziert (die ebenfalls virtuell und kurzlebig sein können), und schließlich herausfinden, welches für diese Dinge das richtige Verhalten ist, können wir unseren Polygraph erzeugen. 

Wenn einer dieser Prozesse also aus heiterem Himmel einen TFTP-Port öffnet, oder Daten aus einem komplett anderen S3-Bucket einliest – beides typische Dinge für bösartiges Verhalten – können wir es sofort erkennen. Das ist es, was der Polygraph tut. Er erstellt diese Abstraktionen, diese virtuellen abstrakten Einheiten, die eine Vielzahl von Aktivitäten, Prozessen und Rechnern repräsentieren, darunter Rechner, die aufgrund der elastischen Skalierung kommen und gehen. Der Polygraph erkennt dies als eine einzelne Abstraktion und verknüpft sie mit anderen Abstraktionen, sodass ein Graph entsteht, der festhält, wie Abstraktionen miteinander kommunizieren und interagieren und voneinander abhängen sollten. Das ist unsere Kerntechnologie. 

Der Grund, warum ich zu Lacework gekommen bin, ist, dass ich seit weit über einem Jahrzehnt versuche, den Ansatz der Anomalie-Erkennung zu verfolgen. Und das ist extrem schwierig. Es ist eine erstaunliche Leistung, dass Lacework es geschafft hat, diesen Ansatz erfolgreich umzusetzen. Ich bin also hier, weil ich begeistert war und Teil davon sein wollte, die Art und Weise, wie Software Security in der Cloud umgesetzt wird, grundlegend zu verändern und zu verbessern.