Ausdehnung des Sicherheitseigentums auf Ihr gesamtes Unternehmen

Clarke: (00:05)
Megan, vielen Dank, dass Sie heute bei mir sind.

Megan: (00:07)
Ja, auf jeden Fall.

Clarke: (00:08)
Können Sie uns ein wenig über Ihren Hintergrund erzählen und wie Sie zu AWS gekommen sind?

Megan: (00:13)
Ich war mehr als 15 Jahre lang in verschiedenen Sicherheitsfunktionen tätig, angefangen als Netzwerksicherheitsspezialistin in einem Krankenhaus. Dann kam ich zu einem globalen Einzelhandelsunternehmen mit Sitz in Seattle, wo ich verschiedene Aufgaben in den Bereichen Sicherheitstechnik und Architektur übernahm. Dann wurden wir 2014 Kunde von AWS und ich half dabei, die Cloud-Sicherheitsstrategie festzulegen und dort die Sicherheitskontrollen zu implementieren. Und dann kam ich zu Slalom und war Teil des Dev-Sec-Ops-Teams und half Kunden in ganz Nordamerika dabei, dasselbe zu tun – eine Cloud-Sicherheitsstrategie zu entwickeln und Sicherheitsmaßnahmen zu integrieren. Und dann kam ich tatsächlich als Enterprise Solution Architect für Pacific Northwest zu AWS und trat dem Team der Sicherheitsspezialisten bei.

Clarke: (01:02)
Das ist großartig.

Megan: (01:03)
Ich bin also seit ungefähr vier Jahren hier. Ja.

Clarke: (01:04)
Prima.

Megan: (01:04)
Vielen Dank.

Clarke: (01:05)
Sie haben also, glaube ich, mit einem Informatik-Hintergrund angefangen. Was brachte Sie in den Bereich Sicherheit?

Megan: (01:12)
Das war tatsächlich interessant. Ursprünglich wollte ich Maschinenbauingenieurin werden und absolvierte drei Sommer lang ein Praktikum bei Boeing, wo ich mit den Ingenieuren der 767-400-Linie zusammenarbeitete. Und ich fragte sie, wenn sie jetzt zur Schule gehen würden, was würden sie studieren? Und sie sagten mir, es sei Informatik. Daraufhin sagte ich: „Okay.“ Und das sagten sie durchweg alle. Also sagte ich: „Okay, ich werde einen Kurs in Computersicherheit oder Informatik belegen.“ Und ich war begeistert. Es hat wirklich Spaß gemacht. Es war wie das Lösen von Rätseln, richtig?

Clarke: (01:47)
Richtig.

Clarke: (01:47)
Die Hälfte der Klasse brach den Kurs ab, weil es nicht ihr Ding war. Aber ich habe einfach weitergemacht. Eines der Wahlfächer war digitale Sicherheit, und das klang für mich sehr spannend. Ich belegte diesen Kurs und war fasziniert. Ich fand es wirklich interessant. Es gibt noch mehr Rätsel zu lösen, die sich ständig ändern. Und so habe ich IDS tatsächlich als mein Abschlussprojekt für mein Informatikstudium entwickelt. Ich habe ein kleines Programm erstellt, das die Erfassung von Netzwerkpaketen analysiert und schädliches Netzwerkverhalten ermittelt. Es hat richtig Spaß gemacht.

Clarke: (02:21)
Das ist großartig. Das hat offensichtlich zu einer großartigen Karriere geführt.

Megan: (02:23)
Ja.

Clarke: (02:24)
In Ihrer Rolle bei AWS sind Sie also ein leitender Architekt für Sicherheitslösungen. Was bedeutet das? Und was sind Ihre Hauptaufgaben in dieser Funktion?

Megan: (02:33)
Ich helfe Kunden mit der Sicherheit von AWS. Ich helfe ihnen dabei, die Grundlagen zu schaffen, den Integritätsschutz zu setzen, Sicherheitskontrollen zu implementieren und zu verstehen: „Was ist das Betriebsmodell für die Cloud? Wie sieht das aus?“ Ich helfe auch bei der Schulung von Kunden auf Veranstaltungen, in Entwickler-Workshops, bei Entwicklungssitzungen und im internen Bereich. Wir haben einige interne Programme, bei denen wir interne Feldversuche durchführen und sie über die verschiedenen Aspekte der Sicherheit aufklären. Sie werden also von der Sicherheitsstufe 100 auf die Sicherheitsstufe 300 gebracht, so dass sie in diesen Kundengesprächen effektiver sein können.

Clarke: (03:20)
Also, Megan, bei AWS haben wir eine sehr ausgeprägte Sicherheitskultur, und wir haben viele Mechanismen, um diese Kultur durchzusetzen. Haben Sie einen bestimmten Lieblingsmechanismus?

Megan: (03:29)
Ja, auf jeden Fall. Eines der Verfahren, die wir haben, ist das Einreichen von Sev Two. Wenn Sie der Meinung sind, dass es ein Sicherheitsproblem gibt, können Sie unabhängig von Ihrer Position im Unternehmen ein Ticket einreichen – das Verfahren nennt sich Sev Two. Am anderen Ende steht ein Sicherheitstechniker, der dabei hilft, zu beurteilen, ob es sich um ein Problem handelt oder nicht, und die Sache von dort aus in die Hand nimmt. Und es gibt kein Problem, wenn es kein Sicherheitsproblem ist. Das ist großartig. Und es ist tadellos. Die Idee ist also wirklich, dass wir nicht wollen, dass sich jemand beunruhigt oder eingeschüchtert fühlt, wenn er denkt, dass es ein Sicherheitsproblem gibt. Wir möchten darüber Bescheid wissen. Wir wollen darauf reagieren, und zwar auf eine positive Art und Weise. Und das wird auf der Führungsebene unterstützt, was wirklich erfreulich ist. Ich denke, bei Sicherheitsschulungen und Gesprächen mit den eigenen Führungskräften sieht es oft so aus, als würden alle positiv darüber denken. Ich denke, dass dadurch eine Kultur der Transparenz in Bezug auf Sicherheit und Offenheit entsteht, die ich bisher noch nirgendwo gesehen habe. Ich schätze es sehr.

Clarke: (04:44)
Richtig. Wenn Sie also mit all den verschiedenen Kunden sprechen, mit denen Sie auf unterschiedlichen Ebenen innerhalb eines Kundenunternehmens zu tun haben, gibt es dann bestimmte Schwerpunktbereiche, zu denen Sie sie ermutigen, um ihnen zu helfen, ihre eigene Sicherheitskultur aufzubauen? Wieder die Art von tadelloser Sicherheitskultur?

Megan: (05:01)
Ja, auf jeden Fall. Ich sehe das in mehreren Bereichen. Ich neige dazu, Kunden zu ermutigen, ihre Sicherheitsteams als Hilfe für das Unternehmen und die Entwickler zu betrachten. Wenn sie dabei helfen, das Einfache und Richtige aus der Sicherheitsperspektive zu tun, wird der Weg geebnet, so dass sie, wenn sie im Rahmen des richtigen Modells arbeiten und die Sicherheitsanforderungen transparent sind, schneller vorankommen können und nicht auf eine Menge Hindernisse stoßen. Und ich denke, das schafft dieses schöne Gleichgewicht zwischen Sicherheit und Entwicklung, bei dem beide Seiten zusammenarbeiten. Und es macht mir wirklich Spaß, diese Arbeit bei den Kunden zu sehen. Ich habe es definitiv in ein paar Kundenfällen gesehen. Und ich denke, dies bietet einfach eine gute Möglichkeit, von der Sicherheitsseite und der Entwicklungsseite aus zu operieren, wo sie zusammenarbeiten und sich gegenseitig helfen.

Clarke: (06:00)
Sicherheit ist also nicht die Abteilung, die nur „Nein“ sagt, sondern die tatsächlich versucht, zu helfen und erfolgreich zu sein?

Megan: (06:05)
Ja, auf jeden Fall.

Clarke: (06:07)
Was kann die oberste Führungsebene eines Unternehmens tun, um die Sicherheitskultur zu fördern, die wir in den Kundenbeziehungen aufzubauen versuchen?

Megan: (06:20)
Nun, ich denke, es ist anders als früher, oder? Es ist nicht nur das Sicherheitsteam, das für die Sicherheit verantwortlich ist – das kann nicht sein. Die Entwickler müssen einen großen Teil davon übernehmen. Eigentlich führe ich Kunden gerne durch: „Hey, es gibt das Modell der gemeinsamen Verantwortung zwischen AWS und dem Kunden“, aber Sie erweitern dieses Modell der gemeinsamen Verantwortung für all die verschiedenen Sicherheitskontrollen und Sicherheitsaspekte für die Cloud auf den Rest Ihrer Organisation und machen es für jeden transparent, was er zu verantworten hat.

Clarke: (06:53)
Richtig.

Megan: (06:53)
Und dann helfen Sie dabei, diese Dinge einfach zu machen und einfach richtig zu machen. Die Ausdehnung des Modells der geteilten Verantwortung innerhalb der eigenen Organisation, damit es für alle greifbar ist, halte ich für einen wirklich effektiven Weg.

Clarke: (07:05)
Das ist großartig. Viele Ihrer Kunden haben also sicher weit weniger Sicherheitsexperten, als sie gerne hätten. Was sind einige der Dinge, die Sie beobachtet haben, durch die Sicherheitsteams ihren Fokus und Einfluss auf den Rest ihrer Kundenorganisation erweitern können?

Megan: (07:22)
Nun, ein paar Dinge. Ich denke, erstens finden wir nicht immer den richtigen Fachmann, den wir für den Job suchen. Und manchmal bedeutet das, den Horizont ein wenig zu erweitern und zu denken: „Hey, wenn Sie Sicherheitsleute haben, die sich nicht unbedingt mit Cloud auskennen, aber daran interessiert sind, dann führen Sie sie auf den Weg dorthin.“ Und wenn Sie Entwickler oder DevOps-Mitarbeiter haben, die sich für Sicherheit interessieren, aber nicht unbedingt über den entsprechenden Hintergrund verfügen, sollten Sie ihnen den Weg dorthin weisen. Bieten Sie einen Teil dieser Ausbildung an. Und es gibt da draußen eine Menge Tools, die das können. Eine meiner Lieblingsmethoden ist das Anschauen früherer re:Invent-Videos, re:Inforce, die eine 30- bis 45-minütige Sitzung zu grundlegenden bewährten Methoden für die Sicherheit anbieten. Und viele der Videos, die speziell mit Kunden gemacht sind, sind wirklich gute Beispiele dafür, wie Kunden es angehen, die uns dazu bringen, über den Tellerrand zu blicken, was meiner Meinung nach wirklich hilfreich sein kann. Darüber hinaus ist das AWS Solutions Architect Associate- oder Professional-Zertifikat eine wirklich gute Möglichkeit, diese grundlegenden Konzepte zu erwerben. Und dann ist da natürlich noch die Zertifizierung zum Sicherheitsspezialisten, die wirklich gut ist.

Clarke: (08:39)
Die letzten 18 Monate waren also für alle schwierig. Wir hatten die Pandemie, immer mehr Menschen arbeiten nun von zu Hause aus. Hat die Pandemie zu einer Zunahme oder Abnahme der Cloud-Akzeptanz der Menschen geführt? Was beobachten Sie bei Ihren Kunden?

Megan: (08:54)
Ja, auf jeden Fall. Ich habe beobachtet, dass mehrere große Kunden ihre Cloud-Nutzung ausweiten mussten, um mit der neuen Situation zurechtzukommen. Der Online-Handel ist geradezu explodiert, weil der stationäre Handel schließen musste. Und ich denke, wir haben dabei einige interessante Muster erkannt. Wir haben daraus einige Erkenntnisse für andere Kunden gewonnen, die davon abhängen, wie sie ihre anfängliche Basissicherheit und ihre Multi-Konto-Strategie aufgebaut haben. Wenn es ihnen gelang, die Automatisierung dafür zu nutzen, waren sie klar im Vorteil, denn sie konnten mehr Konten erstellen und die Automatisierung implementieren. Sie verfügten bereits über die Automatisierung, um diese Sicherheitsgrundlagen zu schaffen, und ihre Kontrollen waren einfach da. Wenn der Prozess hingegen nicht automatisiert war, haben wir ihnen natürlich geholfen, etwas ohne Automatisierung zu entwickeln und sie so schnell wie möglich in Betrieb zu nehmen. Wenn dies jedoch manuell geschieht, ist es einfach nur mühsam und langsam. Ich denke also, dass wir sicherstellen müssen, dass alles ... All dieser Integritätsschutz, wie z. B. die Automatisierung Ihres Multi-Accounts, werden von entscheidender Bedeutung sein. Und das war ein nur ein sehr gutes Beispiel dafür, wie die reale Welt das gewissermaßen erzwingt. Als ich als Kunde von AWS anfing, hatten wir zwei Entwicklungsteams, die nur ein wenig herumprobierten. Sechs Monate später waren es 20 Entwicklerteams, die Systeme waren in Produktion, und alle anderen wollten auf die Plattform aufsteigen. Diese Lektion habe ich also schon früh gelernt, und ich glaube, dass viele Kunden diese Erfahrung auch machen mussten.

Clarke: (10:31)
Denn dann musste man nacharbeiten, um tatsächlich den Sicherheitsstandard zu erreichen, den man haben wollte.

Megan: (10:35)
Ja, genau.

Clarke: (10:37)
Also, in gewisser Weise die gleiche Richtung – Sicherheitsteams, Sicherheitsteams innerhalb der Kundenkonten. Gibt es eine Möglichkeit, wie diese Art von Sicherheit den Kunden den Weg in die Cloud weisen kann?

Megan: (10:50)
Ich glaube, ich habe es bei Kunden erlebt, dass die Sicherheit oft an letzter Stelle steht. Aber das muss nicht sein. Ich denke, wenn sie ihr Sicherheits-Framework, das sie On-Premises eingeführt haben, für die Cloud aktualisieren können, ein Mapping vorzunehmen und diesen Integritätsschutz im Wesentlichen schon im Vorfeld einzurichten, wird das viel einfacher sein. Sie werden für den Einsatz von Menschen vorbereitet. Und wenn Sie niemand dazu drängt, ist das großartig. Sie können eine Art Metrik definieren. Sie können die Automatisierung einrichten lassen, ohne dass jemand an die Hintertür klopft und sagt: „Hey, lass uns gehen.“ Und ich glaube auch, dass es uns als Sicherheitsteam die Möglichkeit gibt, die Sicherheitsanforderungen transparent zu gestalten und den Entwicklern zu helfen, zu verstehen, wie sie bauen müssen und welche Spezifikationen das Sicherheitsteam erwartet. Und ich denke, auch hier geht es wieder um die Beziehung zwischen Entwicklern und Sicherheit und einfach ... Es ist eine effektivere, effiziente Beziehung, die die Umsetzung der von den Entwicklern angestrebten Geschäftsfunktionen unterstützt.

Clarke (12:10):
Richtig. Ich könnte mir vorstellen, dass ein gewisses Maß an Zuversicht und Vertrauen entsteht, wenn man feststellt, dass das Sicherheitsteam vor einem in die Cloud geht, und man als Entwickler oder Produktverantwortlicher denkt: „Jetzt habe ich wirklich keine Ausrede mehr, wenn das Sicherheitsteam das macht.“

Megan: (12:25)
Genau. Und ich denke, dass ist eines der Dinge, die ich bei Kunden gesehen habe, das wirklich gut funktioniert, wenn sie diese Sicherheitsanforderungen nennen und Beispiele geben. Beispielsweise. eine interne Wiki-Seite: „Wie sieht eine sichere Identitäts- und Zugriffsrichtlinie aus?“, „Was ist eine sichere Sicherheitsgruppe im Vergleich zu einer schlechten?“ und tatsächlich greifbare Beispiele – das geht wirklich weit. Und das ist genau das, worüber wir sprechen. Kein Wettrennen zwischen Handlungen und Ressourcen für deine Zugangsrichtlinien, so etwas in der Art. Die andere Sache ist, dass, wenn Sicherheitsteams sich selbst zur Verfügung stellen ... also wenn ein Entwicklungsteam blockiert wird, aus welchem Grund auch immer ... Also, wenn zum Beispiel ein Kunde mit einer bestimmten Sicherheitsanforderung kämpft, wenn das Sicherheitsteam sich selbst zur Verfügung stellt durch Sprechstunden einmal pro Woche oder einen Slack-Kanal, kann das wirklich den gesamten Prozess für Entwickler vereinfachen. Sie haben ein gutes Team. In vielen Fällen entwickeln sie Freundschaften mit diesen Leuten, so dass sie nicht immer da sitzen müssen und 24 Stunden lang blockiert sind oder so etwas. Sie können einfach einen schnellen Feedback-Prozess erstellen. Und eventuell ist das auch ein Feedback für „Hey, unsere Dokumentation ist zu kompliziert“ oder „Wir müssen etwas spezifizieren“, oder wenn wir Leute bitten, einen Sicherheitsagenten auf einem Host zu booten, warum schreiben wir dann nicht einfach ein Skript für sie und stellen dieses Skript in einem Code-Repository zur Verfügung?

Clarke (14:02):
Bei all dem, was du gerade gesagt hast, höre ich auch einige Fähigkeiten heraus, die dein durchschnittliches Sicherheitsteam vielleicht nicht hat. Wenn wir uns also die traditionellen Sicherheitsteams ansehen, dann haben sie das IDS und verschiedene Netzwerkservices betrieben, Systeme gepatcht, was auch immer, aber ich höre von dir, und bitte korrigiere mich, wenn ich falsch liege, dass Sicherheitsteams jetzt wirklich verstehen müssen, wie Entwicklungszyklen funktionieren und vielleicht sogar selbst programmieren können?

Megan: (14:33)
Ja, auf jeden Fall. Ich denke, wir haben nicht ... Je nach dem Hintergrund der Sicherheitsexperten haben sie vielleicht keinen Entwicklerhintergrund oder ein CS-Diplom, und das ist auch nicht erforderlich, aber ich denke, ein wenig Python-Programmierung hat noch niemandem geschadet, und Cloud-Formation ist ziemlich einfach zu lernen. Ansible ist nur eine YAML-Konfigurationsdatei. Und ich denke, dass eine ähnliche Vorgehensweise wie bei einem Entwicklungsteam, die Anwendung agiler Praktiken mit einem Backlog und einem Produktverantwortlichen, der eine Priorität aus der Sicherheitsperspektive verwaltet, sehr hilfreich ist. Als erstes muss man verstehen, wie Entwickler arbeiten, aber es ist auch eine wirklich effiziente Arbeitsweise. Als ich noch praktisch tätig war, haben wir das so gehandhabt, weil sich die Dinge, vor allem aus der Sicherheitsperspektive, so schnell ändern und weil sich die Geschäftsanforderungen so schnell ändern. Plötzlich muss man sich vergrößern und die Art und Weise, wie man bisher gearbeitet hat, ändern. Es hilft dir also dabei, in regelmäßigen Abständen die Prioritäten neu zu setzen.

Clarke (15:39):
Also quasi Sicherheit als Service innerhalb einer Organisation betreiben?

Megan: (15:44)
Ja, auf jeden Fall.

Clarke (15:46):
Prima. Wechseln wir also ein bisschen das Thema und konzentrieren uns auf einige der Dinge, die in letzter Zeit in den Nachrichten zu lesen waren. Man braucht nicht lange zu suchen und hört von einer Ransomware-Geschichte nach der anderen. Welche Erfahrungen hast du mit Kunden gemacht und welche Ratschläge gibst du ihnen in Bezug auf Ransomware-Abwehrtechniken?

Megan: (16:11)
Allein in den letzten zwei Monaten habe ich bestimmt über 20 direkte Gespräche mit Kunden über Ransomware geführt. Und ich liebe diese Gespräche, weil sie sagen: „Hey, wir wollen verstehen, wie die Nachricht von AWS lautet.“ Und das sagt mir nur, dass sie uns als Partner betrachten, was großartig ist. Normalerweise erstelle ich eine Liste der 10 bewährten Methoden, denn es gibt kein Patentrezept gegen Ransomware. Du musst wirklich ein starkes Sicherheitsprogramm und starke Sicherheitskontrollen haben und sicherstellen, dass sie effizient funktionieren. Aber es gibt auf jeden Fall einige Schlüsselbereiche, die abgedeckt werden müssen, also gehen wir auf die Mehrkontenstrategie und den Zugriff mit geringsten Rechten ein. Der einzige Bereich, auf den ich wirklich Wert lege, ist die Frage, ob du irgendwo statische, dauerhafte IM-Anmeldeinformationen hast. Falls ja, ist es an der Zeit, diese mit der Lupe zu betrachten und festzustellen, ob sie noch gebraucht werden. Können wir die Architektur neu gestalten? Und wenn sie wirklich benötigt werden – denn in einigen Fällen sind sie für den hybriden Zugang notwendig –, dann sollten wir den mit diesem Berechtigungsnachweis verbundenen Zugang minimieren, so dass sie in der Umgebung nur sehr wenig tun können, und dann überwachen, wann sie verwendet werden, und sie nur als Risiko behalten. Nimm es in das Risikoregister auf. Lass es nicht verschwinden. Und wenn es eine Möglichkeit gibt, sie in Zukunft loszuwerden, dann tu es. Das ist eines der größten Risiken, die wir sehen, und wir wollen sicherstellen, dass wir unseren Kunden proaktiv helfen, schlechte Tage zu vermeiden, um es mal so auszudrücken.

Clarke (17:44):
Soweit ich verstanden habe, geht es bei der Bekämpfung von Ransomware eigentlich nur darum, die Sicherheitsgrundlagen sehr, sehr gut zu beherrschen. Ist diese Einschätzung gerechtfertigt?

Megan: (17:52)
Ja, das ist sie. Patching ist kein neues Konzept. Und dies kann man in AWS auf viele verschiedene Arten tun. Sie können Ihre Systeme aus Ihrer CICD-Pipeline heraus mit der automatischen Skalierungsgruppe austauschen und neu starten. Du kannst Systems Manager verwenden. Systems Manager ist zurzeit halb Betriebs- und halb Sicherheitstool. Es ist erstaunlich, was man damit alles machen kann. Also ja. Es gibt eine Menge Möglichkeiten. Und wir sprechen auch darüber. Ich denke, dass die andere Frage, die mir Kunden gestellt haben, ein gutes Gespräch ist: „Hey, wir haben früher Air-Gapped-Backups mit On-Premises gemacht. Wir hatten im wahrsten Sinne des Wortes Bandsicherungen, die wir zu Iron Mountain schickten, damit niemand diese Sicherungen anfassen konnte. Wie machen wir das in AWS?“ Nun, alles ist eine API, also ist es verbunden, aber es gibt Möglichkeiten, wenn du die Sicherheitsgrenze als AWS-Konto betrachtest, kannst du ein separates Konto mit einem anderen erstellen ... und deine Backups an dieses Konto senden. Du kannst die Automatisierung mit Push-Pull-Mechanismen durchführen, so dass du ein Zielkonto für die Backups hast. Und dann, ein separates Konto, wo du von einer bekannten guten Quelle beziehst und du kannst Dinge wie S3-Objektblock verwenden, was einmal schreiben, oft lesen auf diesem S3-Bucket ist, und wirklich starke Sicherheit und Steuerungen, minimierter Zugriff sogar für wenige Administratoren des Kontos. Und dann AWS Backup, das wurde vor zwei Wochen oder erst kürzlich angekündigt, AWS Backup Vault Lock, das eine ähnliche Funktion wie Write Once, Read Many für diesen Tresor ermöglicht. Dadurch wird im Grunde genommen verhindert, dass du nachträglich Änderungen an diesen Sicherungen vornehmen kannst. Du kannst also nichts löschen. Mit AWS Backup Vault Lock kannst du also Richtlinien und Zugriffsrichtlinien festlegen und verhindern, dass andere Personen Änderungen daran vornehmen. Er ähnelt also im Wesentlichen dem S3-Objektblock, da die dort gespeicherten Daten für eine bestimmte Zeit nicht zugänglich sind.

Clarke: (20:05):
Ok. Zusätzlich zu den von dir erwähnten Werkzeugen und bewährten Methoden habe ich nicht gehört, wie man sich auf Vorfälle vorbereitet. Wie wichtig ist das und was sollten die Kunden in diesem Bereich tun?

Megan: (20:19)
Wenn wir speziell über Ransomware diskutieren, frage ich meine Kunden immer: „Hast du schon einmal eine Tischübung für ein Ransomware-Sicherheitsereignis durchgeführt?“ Weil Tischübungen so wichtig sind. Wenn du noch nie in der Notfallbewältigung gearbeitet hast, kann das eine stressige Situation sein. Eine Tischübung bietet dir die Möglichkeit, viele Probleme zu lösen, mit denen du dich während einer Veranstaltung nicht auseinandersetzen musst, bei der du dich einfach nur konzentrieren und deine Ermittlungen ohne Probleme durchführen möchtest. Und bei der Tischübung wirst du dich im Wesentlichen fragen: Woher wissen wir, dass das Ereignis stattgefunden hat? Haben wir Zugriff auf alle unsere AWS-Konten, um die erforderlichen Untersuchungen durchzuführen? Wo werden wir das Ereignis sehen? Würde es durch unsere Sicherheitsbetriebszentrale kommen? Besitzen wir ein Handbuch, in dem alle Aktivitäten beschrieben sind, die diese Leute durchführen müssen, damit sie einheitlich reagieren können und über die Daten verfügen, die sie für ihre Entscheidungen benötigen? Und dann: Ziehen wir die richtigen Interessenvertreter hinzu? Denn wenn es zu einem Sicherheitsereignis kommt, müssen wir wissen, wie wir mit unseren Kunden und mit deren Kunden kommunizieren können. Außerdem lassen sich damit viele Probleme lösen und unser Profi-Serviceteam kann den Kunden auch dabei helfen. Wir haben das schon einige Male gemacht, und Übung macht den Meister, nicht wahr? Ich denke, wenn man Angst vor einem bestimmten Szenario hat, dann bedeutet das: „Na ja, üben.“ Dann wird es nicht mehr so beängstigend sein. Es ist ganz einfach, etwas zu üben und besser zu werden.

Clarke: (21:55):
Du hast andere Interessengruppen erwähnt. Es handelt sich also nicht nur um eine Übung des Sicherheitsteams?

Megan: (22:00)
Nein, ganz und gar nicht.

Clarke: (22:01)
Welche anderen Interessengruppen sollten an diesen Tischübungen teilnehmen?

Megan: (22:06)
Ja. Auf jeden Fall werden die Rechtsabteilung, ein Datenschutzteam, das Sicherheitsmanagement und – je nach Art der Übung und des Vorfalls – der Helpdesk, die Anwendungs- und Entwicklungsteams hinzugezogen, um zu verstehen, ob wir irgendwelche Maßnahmen ergreifen müssen, zum Beispiel. Was wären die nachgelagerten Auswirkungen?

Clarke: (22:36)
Siehst du, ich meine, alle Ebenen einer Kundenhierarchie sind beteiligt? Ich meine, würde der CEO bei einer dieser Tischübungen anwesend sein? Oder welche Ebenen? Wo hört es auf?

Megan: (22:50)
Ja. Ich denke, es geht auch darum, wer sich einbringen und den Prozess verstehen will, denn wenn man ein Sicherheitsereignis durchmacht, ist es normalerweise vertraulich. Du willst sicherstellen, dass nur die richtigen Leute davon wissen, die davon wissen müssen, damit die Kommunikation auf kalkulierte Weise erfolgen kann. Aber bei einer Übung gibt es keinen Grund, Leute, die sich beteiligen wollen, nicht einzubeziehen. Und wenn der CEO interessiert ist, solltest du ihn unbedingt hinzuziehen.

Clarke: (23:21)
Großartig!

Megan: (23:22)
Jeder kann etwas davon lernen.

Clarke: (23:24)
Ein weiteres großes Thema, das in diesen Tagen in den Nachrichten auftaucht und nach dem die Kunden immer wieder fragen, ist das Konzept des Zero Trust. Was bedeutet Zero Trust für dich?

Megan: (23:34)
Ja. Traditionell haben wir uns bei den Zugangs- und Sicherheitskontrollen in unserer Umgebung stark auf den Netzwerkrahmen verlassen. Heute dagegen geht es um die Authentifizierung und Autorisierung von Aufrufen auf der API-Ebene. Das bedeutet, dass wir sicherstellen wollen, dass jeder Schritt der Netzwerkkommunikation authentifiziert und autorisiert ist, ganz egal, ob es sich um einen Benutzer handelt, der Zugang zu unserer Umgebung erhält, oder um einen Aufruf von API zu API.

Clarke: (24:10)
Megan, danke, dass du heute bei mir bist.

Megan: (24:12)
Ja. Vielen Dank. Das hat Spaß gemacht.