Von den 5 Säulen zum goldenen Dreieck

Bei der Otto Group data.works entwickeln und pflegen wir einen der größten Retail-Nutzerdatenpools im deutschsprachigen Raum. Darüber hinaus entwickeln unsere Produktteams Machine-Learning-basierte Empfehlungs- und Personalisierungsdienste. Viele Online-Händler der Otto Group - wie otto.de und baur.de - integrieren unsere Dienste in ihre Shops, um das Kundenerlebnis zu verbessern.

Unsere interdisziplinären Produktteams - bestehend aus Data Engineers, Cloud Engineers, BI-Ingenieuren und Data Scientists - arbeiten autonom und werden von zwei zentralen Infrastruktur- und Datenmanagement-Teams unterstützt. Einer der Hauptgründe, warum wir in der Lage sind, neue Produkte so schnell zu entwickeln, ist die Autonomie, die unsere Teams genießen, insbesondere wenn es um Abhängigkeiten von zentralen Infrastrukturteams geht. Wenn wir beispielsweise mit der Entwicklung eines neuen Produkts beginnen, wird ein GCP-Projekt unter Einhaltung grundlegender Sicherheitsrichtlinien und -konfigurationen gestartet und innerhalb weniger Minuten an das Produktteam übergeben. Danach erhalten die Teammitglieder vollen Zugriff auf ihre GCP-Umgebung, einschließlich der Nutzung aller Google-Dienste, die sie für den sicheren Zugriff auf unseren einzigartigen Datenpool benötigen.

Diese Freiheit geht mit der Verantwortung für die Sicherheit der Projekte einher. Um die Produktteams bei ihrem doppelten - und oft doppelten - Ziel zu unterstützen und zu befähigen, schnell zu entwickeln und gleichzeitig sicher zu bleiben, haben wir ein Sicherheits-Framework eingerichtet, das auf fünf Säulen basiert, die wir in unserem letzten Blogpost auf Medium ausführlich vorgestellt haben. In den folgenden Abschnitten gehen wir näher auf die Herausforderungen ein, mit denen wir konfrontiert wurden. Was wir gelernt haben, um diese Herausforderungen zu meistern, ist eingebettet in unser goldenes Dreieck aus Menschen, Prozessen und Technologie.

Ingenieure stehen bei der Arbeit in einer nativen Cloud-Umgebung vor vielen Herausforderungen. Einige davon sind ihnen bereits bekannt, andere sind neu. Hier möchten wir die wichtigsten Herausforderungen nennen, mit denen wir konfrontiert wurden.

Komplexe Umgebungen und Abstraktionsleiter

Die Cloud-Technologie kann als Wegbereiter für eine schnelle Markteinführung gesehen werden. Gleichzeitig kann dies zu der Beobachtung führen, dass verschiedene Produkte, die zu unterschiedlichen Zeiten entwickelt wurden, sich in ihrer Cloud-Architektur stark unterscheiden können. Dies kann entweder darauf zurückzuführen sein, dass der Cloud-Anbieter schnell neue verwaltete Dienste herausbringt, oder auf die sich ständig verändernde Technologielandschaft. Auch wenn die Technologie oder die Architektur bei späteren Anwendungen völlig anders sein kann, bleiben die Sicherheitsanforderungen meist gleich. Daher müssen die Ingenieure einen Weg finden, ihre Sicherheitskontrollen in vielen verschiedenen Umgebungen zu verwalten, wobei die inhärenten Kontextwechsel zu einer hohen operativen Arbeitsbelastung führen. Dies wird durch den "Abstraktionsleiter"-Effekt, der im nächsten Abschnitt ausführlich beschrieben wird, noch schwieriger.

Unterschiedliche Sicherheitsprodukte und Alert Fatigue

Der Versuch, eine immer komplexer werdende Umgebung zu verwalten, kann zu einem häufigen Problem führen: dem Vorhandensein vieler verschiedener Sicherheitsprodukte, die jeweils für ihren eigenen Anwendungsfall bestimmt sind. Eine Vielzahl von Sicherheitsprodukten bringt eine Reihe weiterer Herausforderungen mit sich. Zunächst einmal hat jede Integration eines Sicherheitsprodukts ihre spezifischen Kosten, die sich aus der technischen Einarbeitung oder der Schulung der Mitarbeiter ergeben. Außerdem ist nicht jedes Geschäftsmodell eines Produkts Cloud-fähig, so dass die Kosten entweder mit dem zunehmenden Platzbedarf in der Cloud-Umgebung rapide ansteigen oder die Datenaufbewahrung reduziert werden muss, um die Kosten zu senken - mit dem Nachteil einer begrenzten Beobachtbarkeit. Und schließlich hat jedes Produkt sein eigenes Warnsystem und die entsprechenden Benachrichtigungsrichtlinien, was dazu führt, dass die Menschen aufgrund der schieren Anzahl von Benachrichtigungen in Kombination mit einem hohen Anteil an Fehlalarmen unter Warnmüdigkeit leiden. Letztendlich können zu viele verschiedene Sicherheitsprodukte genau den gegenteiligen Effekt haben, den sie eigentlich haben sollten.

Hohe mittlere Wiederherstellungszeit und Talentmangel

Eine weitere Herausforderung ergibt sich aus dem Missverhältnis zwischen der Geschwindigkeit, mit der ein Angriff erfolgt, und der Geschwindigkeit, mit der Ingenieure einen Angriff beheben können. Die Gesamtzeit dieses Prozesses kann mit der Metrik der mittleren Wiederherstellungszeit (MTTR) gemessen werden. Dabei handelt es sich um eine Kombination aus der Zeit, die benötigt wird, um einen Angriff zu erkennen, die betroffenen Systeme zu identifizieren, die Systeme zu reparieren und die Abhilfemaßnahmen zu validieren. Eine hohe MTTR kann mehrere Gründe haben. Sie kann darauf zurückzuführen sein, dass es den Technikern an Sicherheitsexpertise mangelt, um eine große Datenmenge effizient zu durchforsten und Indikatoren für eine Gefährdung zu finden, um einen Angriff zu erkennen. Es kann auch an zeitaufwändigen Prozessen liegen, bei denen die Techniker manuell zwischen verschiedenen Sicherheitsprodukten wechseln müssen, um betroffene Systeme zu identifizieren. Oder es kann auch an der erwähnten Alarmmüdigkeit liegen. Um die MTTR zu verringern, müssen die Ingenieure ihre Fähigkeiten zur Reaktion auf Sicherheitsvorfälle stärken, indem sie ihre Fähigkeiten zur Sicherheitsuntersuchung verbessern. Dieser Prozess kostet wertvolle Zeit, aber es gibt keine Abkürzung dafür, da die Menge an Sicherheitsexpertise, die in jedem Produktteam durch die Einstellung von Sicherheitsingenieuren zugewiesen werden kann, aufgrund des Mangels an Sicherheitstalenten auf dem Markt begrenzt ist.

Sicherheitsbewußtsein

Schließlich ist es ein ständiger Aufwand, den durch SecOps-Maßnahmen (z. B. Security-Awareness-Schulungen) in Ihrem Unternehmen geschaffenen Wert zu ermitteln. Dies macht es manchmal schwierig, die notwendigen Ausgaben zu rechtfertigen, da man am Ende nicht nachweisen kann, was nicht geschehen ist, was zu einer Endlosschleife der Ausbildung von Mitarbeitern und der Schaffung von Sicherheitsbewusstsein führt, um das Budget für Cybersicherheit zu erhalten.

Leiter der Abstraktion

Wie bisher beschrieben, bringt der Weg in die Cloud vielfältige Herausforderungen mit sich. Dies ist auf den Paradigmenwechsel in der Cloud im Vergleich zu einer On-Premises-Umgebung zurückzuführen. Die Grundlage für diesen Paradigmenwechsel ist wohl die Abkehr von einer zentralisierten IT-Abteilung hin zu autonomen DevOps-Teams, was zu mehr Verantwortung und Aufgabenvielfalt für Ingenieure führt. Die Auswirkungen dieses Paradigmenwechsels auf die Ingenieure lassen sich mit dem Begriff "Abstraktionsleiter" zusammenfassen.

In einer Cloud-Umgebung hat die Abstraktionsleiter viele Sprossen, angefangen bei Low-Level-Technologien wie virtuellen Maschinen, Kubernetes und Netzwerken (VPC, Lastverteilung und Routing-Tabellen, Firewalls, VPN) über Mid-Level-Technologien wie PaaS und Serverless bis hin zu High-Level-Technologien wie No-Code-Anwendungsentwicklung und KI/ML-Services. Zu Gunsten des Cloud-Anbieters hat jeder Spross für sich eine niedrige Einstiegshürde. Dies führt dazu, dass die Ingenieure die Abstraktionsleiter kontinuierlich auf- und absteigen müssen. Normalerweise gilt: Je höher ein Ingenieur steigt, desto automatisierter wird das System, und desto weniger Freiheitsgrad besteht für individuelle Konfigurationen. Aber wie eingangs erwähnt, bleiben die Sicherheitsanforderungen meist gleich. So müssen beispielsweise Daten, die in einen Empfehlungsdienst hochgeladen werden, denselben Datensicherheitskontrollen entsprechen, wie wenn sie auf einer Compute Engine verarbeitet werden, auf die über SSH zugegriffen wird. Sie müssen unabhängig von der Abstraktionsebene mit Sicherheitsanforderungen umgehen.
Die Konsequenz für Ingenieure ist, dass sie über ein starkes T-förmiges Technologie-Know-how verfügen und kontinuierlich an ihrer vertikalen und horizontalen technischen Breite arbeiten müssen.

Im folgenden Abschnitt gehen wir näher auf Lösungen für diese Herausforderungen ein.

Das goldene Dreieck gilt auch für unseren Fall, dass die drei wichtigsten Aspekte für eine Organisation Menschen, Prozesse und Technologie sind. Im Folgenden gehen wir auf jeden einzelnen Aspekt ein und teilen mit Ihnen, was wir auf unserer Cloud-Reise gelernt haben.

Alles beginnt mit den Menschen und ist wohl der Aspekt, der die meisten Anstrengungen erfordert. Der Aufbau einer digitalen Sicherheitshygiene und -kompetenz erfordert eine ständige Weiterbildung der Mitarbeiter. Es reicht nicht aus, die Verantwortung für die Informationssicherheit innerhalb einer Organisation zu teilen. Es ist wichtig, die Mitarbeiter in die Lage zu versetzen, ihre Verpflichtungen zu akzeptieren und sie zu eigenverantwortlichem Handeln zu ermutigen. Im Gegensatz zu Sicherheitswissen kann eine Sicherheitsmentalität nicht erlernt werden, sondern basiert auf der Befähigung der Mitarbeiter, ihre Sicherheitsverpflichtungen wahrzunehmen und in ihrer täglichen Arbeit achtsam zu handeln.

Dieser Bewusstseinswandel erfordert auch einen Wandel in der Art und Weise, wie ein tiefgreifendes Sicherheitsbewusstsein geschaffen werden kann. Instruktionsgeleitete oder computerbasierte Sicherheitstrainings erweisen sich meist als ineffizient, wenn es darum geht, den digitalen Mangel an Sicherheitsbedenken nachhaltig zu verringern. Heutige Sicherheitstrainings stützen sich zum Teil auf Gamification-Aspekte wie Serious Games, Capture-the-Flag-Hackathons, Sicherheits-Dojo-Ranglisten, Modellierung von Bedrohungen durch böse User-Storys, blau-rote Team-Challenges und vieles mehr.

Im Wesentlichen muss Sicherheit als ein technisches Problem und nicht als ein Fließbandproblem behandelt werden, da sie eher eine Reise als ein Ziel ist. Daher wird die Sicherheit natürlich frühzeitig in den Produktentwicklungszyklus einbezogen und nicht als nachträglicher Gedanke. Dadurch wird die Sicherheit schließlich zu einem gleichberechtigten Element in einer DevSecOps-Kultur. Mit einem solchen Kulturwandel wird die Realisierbarkeit einer architektonischen Evolution hin zu einer Zero-Trust-Architektur viel höher. Ein praktisches Beispiel ist die Abschaffung des Unternehmens-VPN-Tunnels, der aufgrund der zunehmenden Zahl von Remote-Mitarbeitern und verteilten Mitarbeitern immer beliebter wird. Ein solches Migrationsprojekt ist ein guter Indikator für den Reifegrad der Sicherheit in einem Unternehmen. Es zwingt Anwendungen, die zuvor durch ein Netzwerksicherheitsprodukt "geschützt" waren, nun außerhalb einer Netzwerkfestung zugänglich zu sein, und dadurch muss die Anwendungssicherheit realen Szenarien und Bedrohungen standhalten.

Wir haben gelernt, dass es in einer Cloud-Umgebung selbstverständlich ist, die Komfortzone z. B. einer VPN-Umgebung zu verlassen und bei Architekturentscheidungen frühzeitig über die Sicherheit einer Anwendung nachzudenken (und sie für später in Architekturentscheidungsprotokollen zu dokumentieren), was einen wesentlicheren Einfluss auf die Sicherheit hat. So ist es eine gängige Praxis unserer Ingenieure, z.B. über das IAM und den Netzwerkperimeter ihrer Anwendung nachzudenken, wie Datenschutzkontrollen durchgeführt werden und wie sie die Sicherheit ihrer Anwendung überwachen werden. Wir haben die Erfahrung gemacht, dass dieser Denkprozess einer der Gründe ist, warum eine Cloud-Umgebung als Katalysator wirkt, um frühzeitig über die Sicherheit des Systems nachzudenken und die Verantwortung dafür zu übernehmen. Wir haben auch gelernt, dass es bei diesem Umdenken wichtig ist, so früh wie möglich mit der Einführung der Cloud zu beginnen, denn wie jede andere kulturelle Veränderung braucht es Zeit, um eine neue Kultur zu etablieren.

Unserer Erfahrung nach ist es wichtig, den Sicherheitsstand von Produkten und unserer gesamten Organisation im Laufe der Zeit kontinuierlich zu messen . Eine zwingende Voraussetzung dafür ist die Erfassung von Cloud-Ressourcen, um ein Cloud-Ressourceninventar zu erstellen. Auf der Grundlage dieser Konfigurationsmanagement-Datenbank (kurz: CMDB) können wir einen kontinuierlichen Reifegradprüfungsprozess aufbauen, der uns die Möglichkeit zur datengestützten Entscheidungsfindung gibt. So lässt sich beispielsweise feststellen, welche Teams derzeit mehr Sicherheitsunterstützung benötigen, welche Systeme seit einiger Zeit nicht mehr gepatcht wurden oder welche Schlupflöcher im Rollen- und Rechtekonzept bestehen (z. B. kreative Ingenieure, die eine Service-Account-Impersonation ausnutzen, um auf Ressourcen zuzugreifen, für die sie nicht vorgesehen sind). Dies sind Beispiele für die Aufdeckung von Sicherheitsmängeln, so dass die Produktteams diese durch die Einrichtung von Prozessen angehen können.

Wir verwenden Prozesse, um starke Sicherheitsleitplanken zu setzen, wo immer dies möglich ist, und als Ergebnis einen goldenen Pfad für die Produktteams zu pflastern. Wir kombinieren diesen goldenen Pfad mit einer Reihe von minimalen Sicherheitsanforderungen, die kontinuierlich überwacht werden. Die Produktteams können wählen, ob sie auf dem goldenen Pfad bleiben oder davon abweichen wollen, wenn der aktuelle Anwendungsfall sie dazu drängt. Unabhängig von ihrer Entscheidung können sie sich jedoch darauf verlassen, dass es Prozesse gibt, die ihnen ein kontinuierliches Feedback über ihre aktuelle Sicherheitslage geben. Es hat sich gezeigt, dass diese Prozesse auch neuen Ingenieuren helfen, schnell Vertrauen in die Cloud-Umgebung zu gewinnen, ohne dabei übervorsichtig zu sein.

Wir haben auch gelernt, dass es besser und effizienter ist, bereits zu Beginn einer Software-Lieferkette Feedback zu geben. Dieser als "shift-left" bezeichnete Prozess bezieht sich auf Bemühungen, die Sicherheitskontrollen von Anwendungen in den frühesten Stadien des Entwicklungslebenszyklus zu gewährleisten. Der Aufbau von Prozessen in dieser Phase kann für die Verantwortlichen für die Sicherheit ihrer Anwendungen von großem Nutzen sein, da sich dadurch der Aufwand für die Behebung von Sicherheitsproblemen verringern lässt, bevor diese in der Cloud-Umgebung in Produktion gehen. Die Argumentation ist einfach: Es ist einfach, Sicherheit in ein System zu implementieren, während es aufgebaut wird, aber es ist viel komplizierter, wenn es nachträglich hinzugefügt wird, weil es mehr Zeit und Mühe kostet.

Schließlich gibt es noch Werkzeuge. Wie eingangs erwähnt, können zu viele Werkzeuge genau das Gegenteil von dem bewirken, was sie eigentlich bewirken sollten. Werkzeuge sollten dann eingeführt werden, wenn ein eindeutiger Bedarf besteht, wobei gleichzeitig zu bedenken ist, dass sie eine zusätzliche Lernkurve und zusätzliche Warnungen für die Ingenieure mit sich bringen werden.

Werkzeuge sollten den Menschen helfen, wiederkehrende Aufgaben zu automatisieren. Sie sollten den Mitarbeitern den Vorteil bieten, dass sie weniger Zeit aufwenden müssen, um relevante Informationen zu finden und wichtige Maßnahmen zu ergreifen. Eine der wichtigsten Lektionen, die wir gelernt haben, ist, dass die Anzahl der gefundenen Probleme weniger wichtig ist als die tatsächliche Zuverlässigkeit eines Sicherheitsproblems. Wir bemühen uns, das Signal-Rausch-Verhältnis so hoch wie möglich zu halten und versuchen, Entwickler nicht mit kontextlosem, generischem CVE-Rauschen zu belästigen. Um dies zu erreichen, haben wir gelernt, dass Sicherheitsüberwachungs-Tools einen ganzheitlichen Ansatz für die Lieferkette haben müssen. Sie müssen in der Lage sein, Anwendungen vom Quellcode über Artefakte bis hin zur Laufzeitimplementierung einschließlich ihrer Endpunkte und schließlich ihrer Zugriffskonfiguration zu beobachten. Als Log4Shell aufkam, brauchten wir zum Beispiel nur etwa eine Woche, um anfällige Anwendungen zu identifizieren und das Risiko zu mindern. Dazu haben wir unsere CMDB genutzt, um betroffene Quellcode-Repositories zu identifizieren, sie bis zu ihrer Cloud-Laufzeit zu verfolgen und so den Produktteams eine klare Anweisung zu geben, was zu tun ist, während wir gleichzeitig den Status mit unserer CMDB validieren.

Wie bei Cloud-nativen Anwendungen müssen auch Produkte zur Sicherheitsüberwachung Cloud-nativ sein. Sie müssen mühelos mit dem Footprint der Cloud-Umgebung skalieren und gleichzeitig wirtschaftlich effizient sein. Im besten Fall nutzen sie die Ereignishaftigkeit einer Cloud-Umgebung, um Änderungen in Echtzeit aufzunehmen. Diese Fähigkeit gibt den Ingenieuren aufgrund der zuvor beschriebenen schnellen Feedbackschleife Vertrauen in das Tool. Diese Tools sollten nicht die Probleme der Vergangenheit beheben, sondern die Ingenieure beim Übergang in die nächste Cloud-Ära unterstützen. In dieser Ära wird die Infrastrukturautomatisierung mit Infrastructure as Code (IaC) nahtlos in die Durchsetzung von Sicherheitsrichtlinien mit Policy as Code (PaC) in einer kontinuierlichen Integrationspipeline integriert, die den Ingenieuren schnelles Feedback zu ihrer Cloud-Sicherheitslage gibt, bevor eine Schwachstelle in der Cloud auftritt. Die Techniker erhalten sofort Sicherheitsvorschläge, die sofort angepasst oder angewendet werden können, um Schwachstellen zu entschärfen. Die Ingenieure sollten sich durch ihren Werkzeuggürtel ermutigt und befähigt fühlen, zukünftige sichere Produkte zu entwickeln.

Wir haben auf unserer Cloud-Reise einen langen Weg zurückgelegt, auch wenn es sich so anfühlt, als hätten wir auf unserem Weg zur Cloud-Sicherheit noch einen langen Weg vor uns. Auf eine Sache sind wir jedoch besonders stolz: unsere eigens entwickelte Lösung zur Überwachung der Cloud-Sicherheit. In diesem letzten Abschnitt geben wir einen Überblick darüber, was wir in sie eingebaut haben, wie sie unser goldenes Dreieck unterstützt und wie sie uns hilft, unsere Herausforderungen zu meistern.

Die Entscheidung, in eine Cloud-native Sicherheitsüberwachungslösung zu investieren, kam auf, als unser Cloud-Arbeitsmodus klarer wurde und sich unser Cloud-Footprint-Anstieg abflachte. In der Zwischenzeit haben wir einige Dinge von unserem vorherigen Sicherheitsüberwachungs-Tool gelernt, die wir in unserer neuen Lösung haben wollten.

Die Grundlage unserer 5 Säulen, die wir in unserem letzten Beitrag auf Medium vorgestellt haben, sind immer noch die Kernprinzipien , auf die wir uns verlassen. Aber zusätzlich zu einem Asset-Inventar in Form einer CMDB wollen wir auch kontinuierliche Cloud-Compliance-Tests (CCCT) mit darauf aufbauendem Cloud Security Posture Management (CSPM) haben. Diese Funktionen ermöglichen es uns, unsere Cloud-Umgebung vollständig abzubilden und so die wirklich wichtigen Sicherheitsprobleme zu identifizieren. Dies hat den Vorteil, dass sich die Techniker auf die wichtigsten Probleme konzentrieren können und nicht durch falsch-positive Warnmeldungen belästigt werden. Im Laufe der Zeit haben wir mehr als 130 Sicherheitskontrollen entwickelt, die die Grundlage für unser CSPM bilden. Sie wirken auf unsere graphengestützte CMDB, die verschiedene Ressourcenbeziehungen modelliert, wie unten dargestellt.

Ausgestattet mit den Ideen, die wir erreichen wollen, machen wir uns an die Arbeit, um eine ereignisbasierte Cloud-Architektur aufzubauen, die alle unsere Cloud-Ressourcenkonfigurationen über Cloud-Audit-Protokolle und Batch-Ingestion sammelt. Diese Cloud-Ressourcenkonfigurationen werden dann in einem kohärenten Datenmodell zusammengefasst, das für die Analyse von Sicherheitsproblemen verwendet werden kann. Die Probleme werden dann aufgezeichnet und für die Erstellung einer Sicherheitsübersicht für Produktteams verwendet. Als Nebenprodukt dieser ereignisbasierten Cloud-Architektur haben wir ein CCCT entwickelt, das auf Änderungen in unserer Cloud in Echtzeit reagiert.

Unsere Ansicht der Sicherheitslage umfasst derzeit 13 Konformitätskontrollen, die in vier Dimensionen unterteilt sind: Datensicherheit, IAM-Sicherheit, Netzwerksicherheit und Endpunktsicherheit. Jede Dimension besteht aus mehreren Problemklassen, die zu einer Darstellung der Cloud-Sicherheitslage der jeweiligen Dimension kombiniert werden. Auch wenn es mehr Sicherheitsprobleme gibt, können Produktteams sicher sein, dass sie eine gute Cloud-Sicherheitslage haben, wenn sie alle 13 Konformitätskontrollen beheben. Dies ist jedoch kein Grund, faul zu werden, denn die Sicherheitslage kann sich jederzeit ändern und wird historisch zu einer Sicherheitsbewertung zusammengefasst, so dass sie ständig ein hohes Niveau aufrechterhalten müssen und weitere Kontrollen hinzukommen werden.

Dies ist der Abschluss unserer Geschichte und unserer bisherigen Erkenntnisse. Im nächsten Beitrag wollen wir tiefer in die technischen Details und Herausforderungen einsteigen, die wir bei der Entwicklung unserer Cloud-nativen Sicherheitsüberwachungslösung bewältigt haben.

Dieser Artikel wurde ursprünglich auf Medium veröffentlicht und kann dort auch nachgelesen werden.

Dieser Vortrag könnte auch interessant für dich sein: Hier stellen wir unsere neu entwickelte Cloud-Native Echtzeit-Sicherheitslösung für GCP namens Pantheon bei den code.talks 2022 vor.