Sicherung des Internets dank Cloud-Innovation

Clarke Rodgers (00:10):
Es ist kaum zu glauben, dass es eine Zeit vor dem Internet gab, in der Sicherheitsfragen einfacher und klarer waren. Die Welt hat sich in den letzten 40 Jahren dramatisch verändert und die Online-Verbindung ist heute von zentraler Bedeutung für unser Leben und unsere Geschäfte. Das bringt größere Chancen mit sich, aber auch viel größere Risiken.

Ich bin Clarke Rodgers, Director of Enterprise Strategy bei AWS, und führe Sie durch eine Reihe von Gesprächen mit AWS-Sicherheitsverantwortlichen hier auf Executive Insights.

Heute sprechen wir mit Paul Vixie, AWS Deputy CISO, Vice President und Distinguished Engineer. Paul bringt eine einzigartige Perspektive in AWS Security ein, da er die Entwicklung des Internets schon früh beeinflusst hat. Seien Sie dabei, wenn wir über die Rolle der Sicherheitsverantwortlichen bei der Verbesserung der Sicherheit im Internet diskutieren. Wir wünschen Ihnen viel Spaß.

Clarke Rodgers (00:57):
Paul, vielen Dank, dass Sie heute bei mir sind. Sie sind schon seit geraumer Zeit im Internet unterwegs. Können Sie uns einige Ihrer Beobachtungen darüber mitteilen, wie alles begann und wie wir dorthin gekommen sind, wo wir heute sind, insbesondere aus der Sicherheitsperspektive?

Paul Vixie (01:11):
Die Sicherheit wurde erst im Nachhinein berücksichtigt. Dies kommt also erst viel später in der Geschichte vor, aber die Geschichten sind wahr. Alles begann als Netzwerk der US-Regierung. Es wurde nie vom Militär verwendet, zumindest nicht in der Anfangszeit. Und so gibt es den Mythos, dass die Protokolle gegen kinetische Angriffe oder was auch immer geschützt werden sollten. Und das stimmt nicht. Es war schon immer ein System nach bestem Wissen und Gewissen. Und wenn es funktioniert, funktioniert es für viele Menschen sehr gut. Wenn es nicht funktioniert, kann es zu katastrophalen Ausfällen kommen, die ein robusteres Netzwerk nicht hätte.

Clarke Rodgers (01:48):
An welchem Punkt haben Sie gemerkt: „Hoppla, die Sicherheit wurde nicht berücksichtigt“? Und was musste Ihrer Meinung nach offensichtlich passieren?

Paul Vixie (01:56):
Bei mir läuteten die Alarmglocken schon ziemlich früh und meine erste Sorge galt Spam. Wir hatten keine Authentifizierung, nichts, was Leute daran hinderte, unerwünschten Datenverkehr zu senden, denn in einem reinen Regierungsnetzwerk gab es niemanden, der vom Senden unerwünschten Datenverkehrs profitiert hätte.

Ich habe also schon 1992 damit begonnen, die Alarmglocken klingeln zu lassen. Und nachdem ich mich selbstständig gemacht hatte und als Berater tätig war, startete ich auch das erste Anti-Spam-Projekt, aus dem das erste Anti-Spam-Unternehmen hervorging. Und unser verteiltes Reputationssystem war das erste seiner Art. Ich wünschte, ich hätte das patentiert. Und dieses System ist auch heute noch weit verbreitet, obwohl das Unternehmen, das ich gegründet habe, um Spam zu bekämpfen, bis in den Ruin verklagt wurde. Also ist diese Firma weg. Aber die Idee und die Technologien leben weiter und ich hatte wirklich Recht.

Clarke Rodgers (02:57):
Was, wenn es irgendetwas gibt – und ich hoffe, dass es etwas gibt – ermutigt Sie jetzt, weil Sie sehen, dass das Thema Sicherheit ernster genommen wird, nicht nur bei den großen Cloud-Anbietern, sondern auch bei den Kundenunternehmen? Macht das Hoffnung?

Paul Vixie (03:13):
Ich habe Hoffnung, aber sie ist von Enttäuschung geprägt, denn alles, was wir tun, ist zu wenig oder kommt zu spät. Aber man muss wohl warten, bis der gesamte Markt aufwacht und das Problem erkennt. Man kann nicht nur als einzelnes Unternehmen oder als einzelne Person Alarm schlagen.

Eine Sache, die mir Hoffnung gibt, ist eine Reihe von Technologien, auf die ich nach meinem Wechsel zu Amazon gestoßen bin. Es stellt sich heraus, dass es im großen Maßstab einige Probleme gibt, die man verallgemeinern kann, und Lösungen, die man implementieren kann, die kleinere Betriebe, welche nur ein kleines Projekt durchführen, nicht erreichen können. Was wir zum Beispiel bei den Graviton-Prozessoren erreicht haben, um unsere VMs besser gegen andere VMs abzusichern, das hat uns noch niemand nachgemacht.

Wenn man sich den Nitro-Chipsatz und den Nitro-Hypervisor ansieht, hat das außer uns auch noch niemand geschafft. Als zum Beispiel Log4j herauskam, ging das zwar auch nicht spurlos an uns vorüber, aber wir hatten in ein paar Dutzend Stunden einen Patch für alle unsere Kunden. Das war möglich, weil wir ausreichend Kapazität haben, um zu wissen, wie man ein solches Problem behebt, und weil wir in der Lage sind, den Fix schnell und global zu implementieren. Bei einem weniger zentralisierten System, bei dem jeder für sich selbst verantwortlich ist, müsste man dagegen warten, bis die eigene Lieferkette aufwacht.

„Ich bin daher optimistisch, denn als das Internet zu einer kritischen Infrastruktur, zu einer Art globalem digitalem Nervensystem und zur Quelle der Weltwirtschaft wurde, nahmen die Menschen es endlich ernster.“

Und viele Dinge, die wir zu Beginn mit sehr geringen Mitteln gemacht haben, als Transistoren noch einen Dollar pro Stück kosteten, werden allmählich eingestellt. Und abgesehen davon, dass wir die Dummheiten, die uns geholfen haben, schneller auf den Markt zu kommen als die OSI-Protokolle, gar nicht erst machen, gibt es keine andere Möglichkeit, das Problem zu lösen, außer mit Clouds wie den unseren.

Clarke Rodgers (05:09):
Wenn wir nun auf die nächsten Jahre blicken, gibt es da bestimmte Technologien oder Methoden, von denen Sie besonders begeistert sind und von denen Sie glauben, dass sie nicht nur Unternehmen wie dem unseren, sondern auch unseren Kunden helfen werden, mit ihren Sicherheits- und Compliance-Workloads voranzukommen?

Paul Vixie (05:31):
Eine Sache, die uns intern ermutigt, ist die Art und Weise, wie sich die Container entwickeln. Die Tatsache, dass wir 10 000 dieser Systeme auf einem einzigen Chip betreiben und Tausende von ihnen pro Sekunde starten können, wenn eine Lastspitze auftritt, ohne dass jemand die Art und Weise, wie er seine Softwareentwicklung betreibt, komplett ändern muss, ist ermutigend. Denn wenn die Leute zu diesem Modell übergehen, werden wir das Problem, das wir jetzt haben, zum Beispiel beim Patchen, los.

Jeden Tag gibt es etwas, das gepatcht werden muss. Und wenn Sie kein Team haben, das sich dem widmet, werden Sie es aufschieben, Sie werden es einmal pro Woche, einmal im Monat tun, was auch immer. Und wenn Sie das tun, stellen Sie vielleicht fest: „Oh je, damit dieser Patch in das System passt, das ich habe, muss ich auch diese anderen Dinge aktualisieren, was bedeutet, dass ich die ganze Sache in ein Testlabor stecken muss.“ Es können also Monate vergehen, bis Sie feststellen, dass etwas wirklich dringend gepatcht werden muss, und bis Sie den Patch endlich in Ihrem System haben.

► Podcast anhören: Schwachstellenmanagement in einem Zero-Day-Sicherheitsszenario

Ich glaube nicht, dass wir die glorreiche Zukunft von Raumschiff Enterprise erreichen können, in der einfach alles funktioniert, wenn wir so weitermachen. Dinge wie Container, ob Lambda oder Kubernetes, Firecracker, geben Ihnen die Möglichkeit, Ihre Build-Pipeline, die sogenannte CICD, ein Image erstellen zu lassen und es durch die Tests laufen zu lassen, und wenn es die Tests besteht, können Sie es einfach in den Betrieb aufnehmen.

Sie müssen nicht unbedingt eine VM haben, die genügend Tools und Logik an Bord hat, sodass Sie darauf zugreifen und sie zum Patchen verwenden können. Das machen wir heute – es wird sich nicht skalieren lassen. Es hat bereits einige Risse gezeigt, obwohl ich immer noch so arbeite, weil das die Welt ist, in der ich aufgewachsen bin, aber ich empfehle anderen nicht, das auch so zu machen. Es gibt keinen Grund, dies zu tun und es wäre von großem Vorteil, wenn wir uns einfach darauf einigen könnten: „Ja, wir werden Dinge entwickeln und sie dann nicht mehr anfassen.“

Daher ist die Idee, dass wir aufhören werden, Menschen in den Ablauf einzubeziehen, ebenfalls ermutigend. Und es tut mir leid, das zu sagen, denn Menschen haben sich das ausgedacht und entwickelt, aber wir müssen das menschliche Element jetzt reduzieren, wenn wir eine Sicherheit haben wollen, die nicht mit der Zeit abnimmt.

Die Menge an Software und Hardware, die quasi zwischen einem Menschen und dem Wert steht, der einem Kunden geliefert wird, ist größer als je zuvor. Und unser Verständnis ist relativ konstant geblieben, das heißt, dass wir jedes Mal, wenn die Menge an Software und Hardware zunimmt, einen kleineren Teil davon verstehen. Das wird nicht funktionieren. Wir müssen uns überlegen, wie wir sicherstellen können, dass die Komplexität nicht zu unerwünschten Resultaten führt. Und auch das hängt davon ab, dass wir mehr Disziplin haben und die Menschen aus dem Spiel lassen.

„Und es tut mir leid, das zu sagen, denn Menschen haben sich das ausgedacht und entwickelt, aber wir müssen das menschliche Element jetzt reduzieren, wenn wir Sicherheit haben wollen, die nicht mit der Zeit abnimmt.“

Clarke Rodgers (08:18):
Die Idee von Zero Trust hat sich im Laufe der Jahre weiterentwickelt und dreht sich um den Zugriff von Menschen und Netzwerke. Was denken Sie über Zero Trust, sowohl aus der AWS-Perspektive, also wie wir über Dinge nachdenken und sie intern implementieren, als auch aus der Kundenperspektive, wie sollten sie Zero Trust betrachten?

Paul Vixie (08:39):
Das zentrale, absolut wesentliche Element von Zero Trust wird missverstanden. Ich habe zum Beispiel Leute darüber reden hören, die sagen: „Stellt einfach alles online, macht alles erreichbar und sichert die Dienste und die Server an sich ab. Schützt das Netzwerk, ohne einen Perimeter zu haben.“ Das ist nicht der Sinn von Zero Trust und funktioniert nicht. Man braucht immer noch eine Firewall, aber sobald man sich innerhalb der Firewall befindet, wird man kein besonderes Vertrauen mehr haben, nur weil man sich innerhalb des Perimeters befindet.

Die Annahme, dass Erreichbarkeit Vertrauenswürdigkeit impliziert, ist damit hinfällig. Früher nannte man das „außen knusprig“ und „innen weich“. Wir wollen also kein weiches Inneres haben, obwohl wir immer noch ein knuspriges Äußeres haben. Wir benötigen also ein System, das Identität, Authentifizierung und Berechtigungen in großem Umfang mechanisiert. Und während wir beide dieses Gespräch führen, finden beispielsweise in der Amazon Cloud einige Milliarden Authentifizierungsereignisse pro Sekunde statt.

Und wir haben keine billigen Tricks angewandt, wie das Zwischenspeichern der letzten Ergebnisse und die Annahme, dass Sie, wenn Sie vor einer Sekunde die Erlaubnis hatten, wahrscheinlich jetzt immer noch die Erlaubnis haben. Nein, wir überprüfen das jedes Mal und irgendwann haben wir in den sauren Apfel gebissen und gesagt: „Nichts weniger als das wird die Sicherheit als oberstes Gebot angemessen berücksichtigen.“

Aber auch hier gilt, dass die meisten Systeme mit dem Gedanken entwickelt wurden, dass Sie alles tun können, was Sie wollen, wenn Sie sich Zugang verschaffen konnten, da es keine fein abgestufte Zugangskontrolle gab, die im großen Maßstab funktioniert hätte. Das ändern wir. Und es gibt eine Reihe verschiedener Authentifizierungsstandards. Unserer hat sich als erster durchgesetzt und ist sehr hoch, aber er war nie dazu gedacht, ein Branchenstandard zu werden. Andere Clouds arbeiten also mit ähnlichen Dingen und es gibt einige Branchenstandards, die sich durchsetzen wollen.

Und soweit ich weiß, ohne mit dem Serviceteam gesprochen zu haben, werden wir dafür sorgen, dass jeder Kunde, der auf diese Weise arbeiten möchte, dies tun kann.

Clarke Rodgers (10:49):
Seit etwa einem Jahr ist generative KI in aller Munde und taucht gefühlt fast täglich in meinem Newsfeed auf. Was halten Sie aus der Sicht eines Sicherheitsexperten davon? Wie sehen Sie die Verwendung durch Sicherheitsexperten, um diese Art von Informationen zu schützen, zu untersuchen und so weiter?

Paul Vixie (11:10):
Man muss also über den Hype hinwegsehen und sich fragen: „Was wird da sein, wenn es sich beruhigt hat?“ Und in einigen Fällen wissen wir es nicht. Es ist eine ziemlich neue Technologie und eine Menge Hard- und Software wird dafür entwickelt. Und man weiß nie wirklich, welche Wirkung ein Tool haben wird, bis es von jemand anderem als seinem Hersteller verwendet wird. Wenn man einen Schraubenschlüssel als Hammer benutzt, ist das wahrscheinlich nicht das, was sich der Hersteller des Schraubenschlüssels vorgestellt hat, aber es könnte in manchen Situationen funktionieren.

Wir haben noch keine eindeutigen Anzeichen dafür gesehen, was damit wirklich möglich sein wird, wenn der Hype erst einmal abgeklungen ist und etwas anderes die Schlagzeilen beherrscht. Dennoch forschen, entwickeln und implementieren wir bei Amazon seit mindestens 12 Jahren KI-basierte Lösungen. Das war also keine totale Überraschung für uns.

Mit dem CodeWhisperer-System haben wir bereits ein Beispiel für etwas, das generative KI-Techniken einsetzt, aber nicht so aussieht wie das, was gerade in den Schlagzeilen ist. Ich sehe, dass das auf allen möglichen Systemen passiert. Wenn Sie zum Beispiel eine Anomalieerkennung durchführen, sehen Sie sich die Telemetrieflüsse Ihres Systems an. Sie sehen entweder Ereignisse, die darauf hinweisen, dass etwas schief läuft, oder Ereignisse, die darauf hindeuten, dass jemand Sie angreift. Jetzt, wo wir diese Technologie haben, wird es möglich sein, diese besser miteinander zu korrelieren. Und wieder habe ich das Gefühl, dass wir kaum 1 % dessen gesehen haben, was möglich sein wird.

►  Video ansehen: Der Stand der generativen KI

Während ich also einerseits den Hype verachte und wünschte, wir könnten von Anfang an ernsthaft an die Sache herangehen, verstehe ich auch, dass es hier einige echte Vorteile gibt. Ich arbeite mit einigen Teams innerhalb von AWS Security zusammen, die versuchen, genau diese Frage zu beantworten: „Was können wir tun, um unsere Kunden besser zu betreuen, jetzt, wo dies allgemein verfügbar ist und allgemein verstanden wird?“

Clarke Rodgers (13:14):
Und dann helfen Sie dem menschlichen Sicherheitsexperten mit generativen KI-Tools bei einem Großteil der Routinearbeit aus technologischer Sicht?

Paul Vixie (13:25):
Ja, und das soll keine Produktwerbung sein, aber Amazons größter Cloud-Erfolg war schon immer, dass wir unseren Kunden ermöglichen, Workflows zu übernehmen und zu erstellen. Deshalb war Bedrock eine unserer ersten Aktivitäten im Bereich großer Sprachmodelle. Die Frage ist: Wenn Sie ein großes Sprachmodell verwenden möchten, wollen Sie dann auch die Kosten für das Training tragen? Will man das Modell bauen müssen?

Denn das kann Tausende oder Zehntausende von Stunden an sehr teurer Rechenzeit in Anspruch nehmen. Und wenn es verschiedene vorgefertigte Modelle gibt, die Sie aus einer Art Menü auswählen können, ohne dafür bezahlen zu müssen, sie in Ihr eigenes System zu kopieren, können Sie einfach eine Logik in Ihre VPC – oder was auch immer Sie in unserer Cloud-Umgebung tun – einbauen, die direkten Zugriff auf APIs hat, die wissen, dass Sie Zugriff auf diese Abonnementmodelle haben.

Die ursprüngliche Annahme, die ich damals noch nicht kannte und die ich erst lernen musste, nachdem ich hierher gekommen war, war, dass wir durch eine elastische Menge an Rechenleistung, also so viel, wie Sie wirklich brauchen, und eine elastische Menge an Speicherplatz, wiederum so viel, wie Sie wirklich brauchen, ohne Zugriffsgebühren, groß werden konnten. Und jetzt haben wir das in der generativen KI nachgebildet, sodass Leute, die in ihrem eigenen Marktsegment vielleicht sehr ehrgeizig sind, mit unserer Cloud und LLMs das tun können, was sie schon immer mit unserer Cloud ohne LLMs getan haben. Das gefällt uns. Das gefällt mir, denn die wirkliche Stärke dieses Produkts wird sich darin zeigen, was unsere Kunden damit machen.

Clarke Rodgers (15:13):
Und dass die Kunden das Vertrauen in all die Sicherheitstools haben, die sie seit Jahren nutzen, und andere Aspekte, die jetzt auf Tools wie Bedrock und was auch immer noch kommen mag, angewendet werden können.

Paul, vielen Dank, dass Sie heute bei mir sind waren.

Paul Vixie (15:26):
Es war großartig. Nochmals vielen Dank für die Einladung.