Höhere Anforderungen an die Sicherheit bei AWS und darüber hinaus

Clarke (10:27):
Ich könnte mir vorstellen, dass alle Entwickler, die bei AWS-Sicherheit arbeiten, nicht unbedingt mit einem starken sicherheitstechnischen Hintergrund beginnen. Welche Art von Mechanismen haben Sie eingerichtet, um diese Entwickler auf den Stand zu bringen, den Sie für die AWS-Sicherheit festgelegt haben? Vor allem bei den Tools für Entwickler oder vielleicht sogar bei Sicherheitsprodukten für Kunden? 

Eric (10:50):
Nun, es gibt mehrere Möglichkeiten, über diese Frage nachzudenken. Einerseits ist die Sicherheit bei Amazon die Disziplin des Erbauers. Wir können nicht alle Dinge tun, die wir tun müssen. Wir können nicht mit dem Unternehmen mitwachsen, wenn wir dies nur durch die Aufnahme von Ingenieuren in unser Team erreichen. Ein großer Teil unserer Arbeit besteht also darin, Werkzeuge zu entwickeln. Es handelt sich um reine Softwareentwicklung, genau wie in jedem anderen Team bei Amazon, mit dem Unterschied, dass Sie Sicherheitstools entwickeln. Viele unserer Ingenieure sind also keine Sicherheitsfachleute, sie haben keinen Sicherheitshintergrund. Sie müssen keine besonderen Sicherheitskenntnisse haben, um dem Team beizutreten. Einige von ihnen haben eine Leidenschaft für die Sicherheit, andere mögen einfach den Job und das Team, in dem sie arbeiten, und sie sind sehr zufrieden mit dem, was sie tun, aber sie haben kein besonderes Interesse an der Sicherheit, und das ist in Ordnung.

Eric (11:37):
Der ganze Bereich der Sicherheit besteht darin, herauszufinden, welche Annahmen ein Erbauer getroffen hat, und dann herauszufinden, wie man diese Annahmen verletzen kann, um das System in einen unerwarteten Zustand zu versetzen. Was passiert, wenn ich eine ganze Festplatte mit Daten in dieses Feld packe? Was passiert, wenn ich den Regler auf 11 stelle? Was passiert, wenn ich in dieses Feld eine negative Zahl eingebe? Und die Leute, die so denken, neigen meiner Erfahrung nach dazu, von Natur aus so zu denken, und es ist wirklich schwer, ihnen diese Mentalität beizubringen. 

Eric (12:18):
Wenn wir also jemanden mit dieser Mentalität finden, kann das gesamte spezifische Sicherheitswissen vermittelt werden, und alle alltäglichen Technologien können wir den Leuten sehr leicht beibringen. Nichts von dem, was ich heute tagtäglich tue, gab es schon zu meiner Studienzeit. Die Grundlagen, die ich an der Hochschule gelernt habe, gelten also immer noch, aber keine der spezifischen Technologien. Wir haben also ein wirklich solides Programm, mit dem wir Leute mit diesem besonderen Sicherheitsbedürfnis ausbilden können.

Eric (12:46):
Die Antwort auf Ihre Frage ist also zweifach. Es gibt eine Reihe von Menschen, denen wir die Sicherheit nicht beibringen müssen. Es ist ein Standard-Entwicklungsjob. Es ist eine Standard-Builder-Rolle. Und sie sind hervorragend. Einige von ihnen interessieren sich für das Thema Sicherheit, und das ist großartig, wir fördern das. Aber das ist nicht notwendig. Und auf der anderen Seite finden wir die Menschen, die dazu neigen, herauszufinden, wie ich Dinge kaputt machen kann. Und die Frage „Wie mache ich Dinge kaputt?“ führt ganz natürlich zu „Und wie repariere ich sie, damit sie nicht noch einmal kaputt gehen können?“ Und alle berufsspezifischen Fähigkeiten können wir den Menschen vermitteln.

Clarke (14:03):
Viele unserer Kunden, die versuchen, Sicherheitsexpertise in ihren eigenen Entwicklungsgemeinschaften aufzubauen, nehmen einen Sicherheitsexperten und setzen ihn in ein „normales Entwicklungsteam“ ein, um die Sicherheitsbarriere in diesem Team zu erhöhen und im Grunde genommen das Bewusstsein eines Sicherheitschampions zu haben. Die Idee ist also, dass wir nur eine begrenzte Anzahl von Sicherheitsexperten haben, also versuchen wir, sie auf die Entwicklungsteams zu verteilen, und schließlich steigen alle Boote. Ist das bei AWS und Amazon ähnlich, wie wir die Dinge betrachten, oder ist die Sicherheit in unserem Ethos verankert, so dass jeder erkennt: „Ich trage eine gewisse Verantwortung für die Sicherheit meiner Anwendung, und deshalb werde ich den Prozess befolgen“? Können Sie ein wenig darüber erzählen, wie das funktionieren könnte?

Eric (14:58):
Gerne. Sie müssen sich über Sicherheit keine Gedanken mehr machen. Wir sind grundsätzlich der Meinung, dass Sicherheit genauso wie Skalierbarkeit, Verfügbarkeit, niedrige Latenz und geringer Ausfall ein Teil des Kundenerlebnisses ist. Sie ist ein Teil von allem, was wir bauen. Allerdings ist das Fachwissen über Sicherheit nicht sehr verbreitet. Wir haben nicht annähernd so viele Sicherheitsingenieure, wie wir gerne hätten. Ich meine, ich würde es toll finden, wenn jeder einzelne Entwickler, den wir haben, auch ein Sicherheitsexperte wäre. Ich halte nicht den Atem an. Ich finde es interessant, dass Sie den Begriff „Sicherheitschampion“ verwendet haben, denn das ist buchstäblich der Name unseres internen Programms, bei dem wir sicherheitsbewusste Mitarbeiter in den Serviceteams finden und sie schulen und unterstützen, um ihre Sicherheitskenntnisse zu verbessern, damit sie in ihrem Serviceteam Einfluss nehmen können.

Eric (16:38):
Und wenn dann eine wichtige Entscheidung ansteht, müssen sie nicht die einsame Position einnehmen und sagen: „Ich als einziger Sicherheitsverantwortlicher hier bin der Meinung, dass dies noch nicht einsatzbereit ist oder dass wir diese zusätzliche Arbeit leisten müssen.“ Es gibt diese ganze Sicherheitsorganisation, auf die sie zurückgreifen können, und wir können aus einer Position der Kundenbesessenheit heraus zusammenarbeiten, um herauszufinden, was das Richtige für die Kunden ist. Wenn wir einen unsicheren Dienst anbieten, ist das das falsche Ergebnis für die Kunden, aber wenn wir den Dienst nicht anbieten ... Eine Dienstleistung, die es nicht gibt, erfreut null Kunden, und deshalb müssen wir das richtige Gleichgewicht finden. Durch die Einbindung von Sicherheitsexperten in das Serviceteam, die dem Serviceteam sehr wohlwollend gegenüberstehen, und durch Sicherheitsexperten im AWS-Sicherheitsteam, die dem Serviceteam wohlwollend gegenüberstehen, aber eher als Auditoren fungieren, können wir viel bessere Entscheidungen treffen, und zwar viel schneller.

Clarke (17:28):
Und ich könnte mir vorstellen, dass dies eine Erleichterung ist ... In vielen Kundengesprächen, die ich führe, wird die Sicherheitsabteilung als die Abteilung angesehen, die es nicht gibt, oder als die Abteilung, die ich vermeiden muss, um meine Anwendung zu starten. Mit dem Modell, über das Sie gerade gesprochen haben, scheint sich diese Vertrauensbrücke zu erweitern, und jeder erkennt: „Nun, Sicherheit ist einfach ein Teil des Jobs, und so machen wir es bei Amazon“, in unserem Fall. Das Endergebnis ist dann ein sichereres Produkt, das auf den Markt kommt.
 
Eric (18:00):
Vor einiger Zeit haben wir also versucht, ein Leitbild zu entwickeln. Wie sagt man zum Beispiel: Was macht AWS-Sicherheit? Und das Beste, was uns einfiel, war sicher ausliefern. Das sind zwei Worte, die meiner Meinung nach sehr gut ausdrücken, warum wir existieren. Das Unternehmen existiert nicht, um Sicherheit zu bieten. Es heißt Amazon Web Services, nicht Amazon Security. Und so sind wir hier, um diese Webdienste auszuliefern, um für die Kunden zu liefern. Wenn wir nicht ausliefern, führen wir nicht aus. Wir tun nicht das, wozu das Unternehmen da ist. Wir sind also hier, um das Geschäft zu ermöglichen. Wir sind nicht der Grund für das Geschäft. Und man kann dieses Geschäft nicht betreiben, wenn man nicht über vorbildliche Sicherheit verfügt, aber wir sind nur eine Facette des Geschäfts.
 
Eric (18:44):
Und das Wichtigste für uns ist die Unterstützung durch die Geschäftsleitung, die wir erhalten. Es ist klar, dass die Sicherheit unglaublich wichtig ist, und das kommt von oben. Und weil wir nicht sagen: „Wir sind das Sicherheitsteam, Sie müssen auf uns hören. Bitte, bitte passen Sie auf ...“ Ich habe dieses Problem nicht. Vom CEO an abwärts ist der Ansatz vorgegeben. Jeder weiß, dass Sicherheit wichtig ist.
 
Clarke (20:04):
Vielen Dank dafür. Was sind die wichtigsten Metriken, die Sie zur Messung der Wirksamkeit des Sicherheitsprogramms in der gesamten AWS-Entwicklergemeinschaft verwenden, wenn es um die Messung eines Sicherheitsprogramms geht, insbesondere bei Entwicklern und anderen, die Code in AWS schreiben?
 
Eric (20:57):
Wir haben zwei Stellen, an denen wir Metriken anwenden.
 
Eric (21:43):
Sie wollen nicht die Zeit bis zum Abschluss des Tickets messen. Die Schließung des Tickets dauert so lange, wie das Ticket zum Schließen braucht. Was wir jedoch messen, ist unsere Reaktionsfähigkeit. Wir haben also SLAs für das erste Engagement. Wenn Sie z. B. eine E-Mail an AWS-Security senden, erhalten Sie innerhalb von 24 Stunden eine Antwort von einem Mitarbeiter, wie wir öffentlich erklärt haben. Und das messen wir. Wir haben Grafiken und Diagramme, die ich mir jede Woche ansehe und die zeigen: „So lange haben wir gebraucht, um uns bei den Leuten zu melden, die uns eine E-Mail geschickt haben.“ Die Reaktionsfähigkeit ist also sehr wichtig. Erstens, weil man das Vertrauen der Menschen verliert, wenn man nicht reaktionsfähig ist. Und zweitens, weil eine gute Reaktion in der Regel bedeutet, dass andere gute Dinge geschehen.
 
Eric (22:25):
Ein weiterer Bereich, in dem wir ähnliche Überlegungen anstellen, sind die Tickets, die nicht mehr gültig sind.
…
Alles ist ein Ticket. Wir haben also eine Menge Automatisierung in das Ticket-System eingebaut, um sicherzustellen, dass, wenn ein Ticket veraltet, wir sowohl die Zeitspanne zwischen der Korrespondenz des Serviceteams als auch die Zeitspanne zwischen der Korrespondenz des Sicherheitsteams messen, und so wissen wir, wenn Tickets verfallen, wir wissen, wenn wir für das Serviceteam blockiert sind oder das Serviceteam für uns blockiert ist, und wir können sehr schnell die Tickets aufdecken, die sofortige Aufmerksamkeit benötigen. Aber das gibt uns auch die Daten, um uns selbst und rückblickend zu betrachten und herauszufinden, welche unserer Prozesse nicht funktionieren, wo wir den Personalbestand ändern müssen, wo wir in bessere Werkzeuge investieren müssen. Wir messen also die Prozesse rund um die Sicherheit, und wir haben festgestellt, dass dies tatsächlich zu den richtigen Sicherheitsergebnissen führt.
 
Eric (23:20):
Bei der anderen Sache, die wir aktiv messen, geht es nicht darum, es richtig zu machen. Wir investieren sehr viel Zeit in die Anwendungssicherheit, um einen guten Service zu entwickeln, aber Amazon bringt nie etwas auf den Markt und lässt es allein. Wir fügen ständig neue Funktionen hinzu, wir reagieren ständig auf das Feedback unserer Kunden, und unsere Dienste ändern sich schnell auf der Grundlage dieses Feedbacks. Unser Ziel ist es also nicht, sicher zu starten, sondern die Sicherheit während der gesamten Lebensdauer des Dienstes aufrechtzuerhalten, und das bedeutet, dass die Maßnahmen, die Sie während der anfänglichen Überprüfung der Anwendungssicherheit ergreifen, schnell altern und ihren Wert verlieren. Ein Teil des Anwendungssicherheitsprozesses besteht also darin, zu bestimmen, welche Invarianz, welche Aussagen über den Dienst immer wahr sein sollen, und dann herauszufinden, wie wir diese in Varianten im Code verifizieren.
 
Eric (24:10):
Wenn also ein Dienst eine so formatierte Anfrage immer ablehnen sollte, sollte es einen Testballon geben, der diesen Dienst in der Produktion mit dieser besonders formatierten Anfrage aufruft, um sicherzustellen, dass sie abgelehnt wird. Und dann messen wir die Ergebnisse unserer Testballons. Wie viel von der Oberfläche des Dienstes decken sie ab? Wie oft werden sie durchgeführt? Wie oft versagen sie? Wie oft erhalten sie anomale Ergebnisse? Und wir messen diese Prozesse, um unseren Sicherheitsstandpunkt zu bestätigen. Es geht nicht um die Messung der gelieferten Sicherheit. Das ist schwer zu messen. Aber es misst die Regressionen in der Sicherheitsleiste, die wir bereits festgelegt haben. Das ist unglaublich wichtig, denn es wird immer ein weiteres Sicherheitsproblem geben. Unsere Teams sind innovativ, sie entwickeln immer wieder neue und aufregende Dienstleistungen, die wir bisher noch nicht sichern mussten. Auch das ist einer der Gründe, warum ich jeden Tag zur Arbeit komme.
 
Clarke (26:00):
Das klingt hervorragend. Eine verwandte Frage, aber aus der Kundenperspektive: Wir haben einige Kunden, die sehr, sehr fortgeschritten sind, die Infrastruktur als Code über eine CICD-Pipeline in die Produktion bringen. Auf der anderen Seite haben wir Kunden, die nur an der Konsole sitzen und Point-and-Click-Aktivitäten ausführen.. Meiner Erfahrung nach befinden sich die meisten unserer Kunden irgendwo in der Mitte und versuchen, diese Infrastruktur als Code „Nirwana“ zu erreichen. Welchen Rat würden Sie der Kundenleitung geben, um eine stärkere Fokussierung auf die Technik gegenüber den operativen Point-and-Click-Aspekten des Betriebs einer Infrastruktur zu fördern?
 
Eric (26:42):
Ich habe also nie etwas Schönes entwickelt. Ich habe Dinge entwickelt, auf die ich unglaublich stolz bin, Dinge, die sich auf dem Markt sehr gut bewährt haben, sei es auf dem öffentlichen Marktplatz der AWS-Services oder auf dem internen Marktplatz, wo unsere Kunden unsere Service-Teams und andere Amazonianer sind. Aber es sind alles Systeme, die mit einem Kern einer Idee begonnen haben, und wir haben das gebaut, von dem wir dachten, dass es das kleinste Ding ist, das wir bauen können, das die Kunden begeistern würde, und dann haben wir es so schnell wie möglich iteriert. Und sie wuchsen mit der Zeit. Erst durch diese Iteration erhält man die großartigen Werkzeuge. Die Menschen, die ihnen nahestehen, halten sie für Frankensteins Monster. Das ist so ein Schrotthaufen, der sieht aus, als hätte ihn MacGyver gebaut, nur aus Draht und Klebeband. Aber in Wirklichkeit sind sie großartige Werkzeuge. Sie sind verblüffend effektiv. Und weil sie für die Aufgabe, die sie erfüllen sollen, gebaut wurden, erfüllen sie Schritt für Schritt die Aufgabe, die sie erfüllen sollen.
 
Eric (27:42):
Wenn also jemand zu uns kommt, sei es, dass er zum Team stößt oder dass wir mit einem Kunden darüber sprechen, wie wir intern vorgehen, sieht er diese Vielzahl von Werkzeugen, die wir haben, all diese Mechanismen, die wir entwickelt haben, und es ist überwältigend. Es scheint, dass es keine Möglichkeit gibt, das zu replizieren. Erstens: Sie müssen es nicht replizieren. Damit sollen unsere spezifischen Sicherheitsfragen behandelt werden. Aber zweitens haben wir diese Dinge nicht aufgebaut, wir haben sie mit der Zeit wachsen lassen, und alle haben klein angefangen. Es geht also um diesen schrittweisen Ansatz. Als wir gerade über Metriken sprachen, habe ich davon gesprochen, dass es keine Regressionen geben darf, dass man das gleiche Problem nicht zweimal lösen muss. So verbessert man sich jeden Tag. Jeden Tag wird die Sicherheitslatte schrittweise höher gelegt, und es kommt zu einem exponentiellen Wachstum.
 
Clarke (29:34):
Für die Kunden, die sich dies ansehen, besteht die Idee also darin, im Wesentlichen klein mit Ihren technischen Bemühungen anzufangen und dann einfach mit der Zeit zu wachsen und sie immer besser zu machen, anstatt meinen Ansatz für alles auf einmal zu ändern?
 
Eric (29:48):
Auf jeden Fall. Diese schrittweise Denkweise zahlt sich immer aus. Und sie muss auf der anderen Seite von Sicherheitsexperten vereinigt werden, die keine Angsthasen sind. Wir alle sind jeden Tag von Risiken umgeben. Das Überqueren der Straße ist ein Risiko, Autofahren ist ein Risiko, das Anschließen des Laptops an das Netz ist ein Risiko. Wir müssen uns also daran gewöhnen, angemessene Risiken einzugehen. Sicherheit ist also eine Kunst, und ich wünschte, es wäre mehr eine Wissenschaft, aber ich denke, es ist eine Kunst, diese Risiken zu managen, zu verstehen, welche Risiken akzeptabel sind, welche Risiken gemildert werden können und welche Risiken schlichtweg inakzeptabel sind. Als Sicherheitsexperte, egal in welcher Funktion, überall dort, wo Unsicherheit herrscht, muss man also in der Lage sein, über die Ernsthaftigkeit dieses Risikos zu sprechen.
 
Eric (30:38):
Wenn wir in der Sicherheitsorganisation über Sicherheit sprechen, verwenden wir ständig den Ausdruck „klinisch und präzise“. Wenn Sie sagen: „Das ist die schlimmste Sicherheitslücke aller Zeiten, und wir können nichts tun, um sie zu beheben“, haben Sie gerade enorm an Glaubwürdigkeit verloren. Sie haben alle Bereiche der Diskussion ausgeschlossen. Wir verhandeln nicht mehr über den Weg nach vorn. Sie haben ihn einfach abgeschaltet. Wenn Sie stattdessen sagen: „Das ist ein wirklich besorgniserregendes Thema. Ich bin besorgt über diese spezielle Auswirkung“, hier sind drei mögliche Wege nach vorne. Ich mag die erste Variante, sie ist zwar teurer, aber sie bietet auch diesen Vorteil. Lassen Sie uns darüber sprechen, was wir hier tun müssen. Es ist klinisch, es ist präzise, und es eröffnet das Gespräch. Ich bringe Ihnen mein Fachwissen, damit wir ein Gespräch über das Geschäft führen können. Der Ingenieur, der diese Sicherheitstools entwickelt, muss dies also im Hinterkopf behalten. Sie müssen sich fragen: „Wie kann ich das Geschäft verbessern?“ und nicht: „Oh mein Gott, alles brennt und alles ist schrecklich.“