AWS re:Invent 2022: Wie Neiman Marcus zu Developer-First-Security wechselte

Auf der diesjährigen AWS re:Invent sprach Ravi Maira, VP of Product Marketing bei Snyk, mit Omar Peerzada, Cybersecurity-Architekt bei Neiman Marcus, darüber, wie sein Team von älteren Sicherheitspraktiken zu einer Developer-First-Security-Strategie wechselte. Sehen Sie sich jetzt das ganze Gespräch an oder lesen Sie weiter und erfahren Sie die wichtigsten Punkte.

https://youtu.be/BH2GY5GrsQM

Von Legacy-Systemen in die Cloud

Peerzada erklärte, dass Neiman Marcus, ein Unternehmen mit 100-jähriger Geschichte, zu den ersten Einzelhändlern gehörte, die den digitalen Wandel vorangetrieben haben. Zu Beginn des Umstiegs arbeitete das Unternehmen mit zahlreichen Legacy-Infrastrukturen und -Anwendungen. Die typischen Probleme von On-Premises-Systemen – Skalierbarkeit, Performance und Sicherheit – waren die Hauptgründe dafür, dass Neiman Marcus über On-Premises-Lösungen hinaus in die Cloud blickte.

Den Weg planen: Wie lief der Umstieg ab?

Maira fragte: „Wie sah der Wechsel in die Cloud aus? Wie kam es zu dieser Transformation?“

Nach umfangreichen Recherchen entschied sich das Unternehmen für AWS als Cloud-Partner. Anschließend gründete es eine Gruppe namens Cloud Center of Excellence, die dafür verantwortlich war, DevSecOps-Praktiken im gesamten Unternehmen einzuführen. Das Team erstellte Pipelines und stellte sicher, dass Sicherheit an verschiedenen Kontrollpunkten integriert war. Außerdem stellte es Entwicklern eine skalierbare Architektur zur Verfügung, in der sie innerhalb von Sicherheitsleitplanken arbeiten konnten.

Peerzada betonte, dass bei skalierbaren Architekturen im Zeitalter der digitalen Transformation die Sicherheit nicht beeinträchtigt werden darf. Inzwischen, im sechsten Jahr nach dem Wechsel in die Cloud, hat Peerzadas Team fast 90 % seiner Workloads von On-Premises in die Cloud migriert.

Die entscheidende Frage: Wem gehört die Cloud-Sicherheit?

„Sie sind also in die Cloud gewechselt“, sagte Maira. „Die Cloud-Migration hat begonnen. Wie sind Sie den Sicherheitsaspekt angegangen, und welche wichtigen Erkenntnisse haben Sie in der Anfangsphase gewonnen?“

Die entscheidende Frage, mit der sich jedes Unternehmen auseinandersetzt: Wem gehört die Cloud-Sicherheit? Dem DevOps-Team? Dem traditionellen Infosec-Team? Oder gibt es ein Cloud-Sicherheitsteam? Hier ist die Unternehmensführung gefragt.

Peerzadas Team entschied, dass das Cloud Center of Excellence am besten geeignet war, das Cloud-Sicherheitsprogramm zu betreiben. Schließlich war es das „Team vor Ort“, das direkt mit den Abläufen vertraut war. Gleichzeitig musste es sich an die übergeordneten Leitplanken der Sicherheitsrichtlinien des Unternehmens halten. Innerhalb dieser Leitplanken konnte das Team die für die Sicherheit eingesetzten Tools selbst auswählen. Diese Entscheidung war entscheidend: Sie ermöglichte es dem Cloud Center of Excellence, im gesamten Unternehmen skalierbar zu arbeiten, ohne die Produktteams im schnelllebigen Arbeitsumfeld auszubremsen.

Die passenden Tools für Cloud-Sicherheit finden

Das Team begann damit, Kontrollen in AWS einzuführen und dabei die On-Premises-Umgebung als Vorlage zu verwenden. On-Premises und Cloud wurden direkt miteinander verglichen. Doch bei der Cloud-Sicherheit traten dieselben Probleme auf wie zuvor in der On-Premises-Umgebung. Deshalb wechselte das Team schnell zu nativen AWS-Cloud-Tools, mit denen es die Geschwindigkeit beibehalten und zugleich die Kosten im Rahmen halten konnte.

Peerzadas Team führte AWS-Sicherheitskontrollen ein. Automatisierung stand von Anfang an im Mittelpunkt: Das Team implementierte standardmäßig verschiedene Sicherheitskonfigurationen und verschlüsselte alles. Es priorisierte grundlegende Cyberhygiene und stellte sicher, dass die Kontrollen für Identity- und Access-Management streng genug waren. Das half beim Aufbau eines Zero-Trust-Frameworks. Außerdem automatisierte das Team die Behebung wichtiger Sicherheitsprobleme. So nutzte es beispielsweise S3 zum Speichern von Objekten im AWS Data Lake und aktivierte die automatische Behebung, falls die S3-Verschlüsselung nicht korrekt konfiguriert war.

Application Security kommt hinzu

Maira fragte daraufhin: Nachdem Sie sich mit der Cloud-Sicherheit befasst hatten, wie kamen Sie zu traditionelleren Application-Security-Lösungen wie statischen Anwendungssicherheitstests (SAST) oder Software Composition Analysis (SCA)?

Peerzada berichtete, dass sein Team verschiedene Open-Source-Tools für grundlegende Sicherheits- und Codequalitätstests nutzte. Zunächst konzentrierte sich Peerzadas Team darauf, die Cloud-Infrastruktur ohne Schwachstellen in der Produktionsumgebung bereitzustellen. Doch dem Team wurde klar, dass es eine bessere Application Security brauchte. Es wollte die beiden Silos miteinander verbinden und denselben Rhythmus und dieselbe Feedbackschleife, die es für die Cloud-Sicherheit nutzte, auch auf die Application Security übertragen.

Wir hatten eine Lücke bei der Application Security. Wir wollten die Silos irgendwie miteinander verbinden, diese beiden Welten zusammenführen und so sicherstellen, dass wir denselben Rhythmus und dieselbe Feedbackschleife, die wir für die Cloud-Sicherheit hatten, auch auf die Application Security übertragen. Damals stießen wir auf Snyk und erkannten, dass es genau das war, wonach wir gesucht hatten.

Das Team begann, Snyk Open Source im Rahmen seines SCA-Prozesses zum Scannen von Abhängigkeiten und Paketen von Drittanbietern einzusetzen. Anschließend verknüpfte es Snyk mit seinen Git-Repositories, um neu auftretende Schwachstellen zu erkennen – und erzielte sofort Ergebnisse. Der Mehrwert von Snyk, der Entwicklern dabei half, Schwachstellen zu beheben, überzeugte Neiman Marcus schnell davon, Snyk als Unternehmenskunde einzusetzen.

Maira fragte: „Wie haben Sie Entwickler stärker in die Sicherheit eingebunden?“

Das Team führte Snyk schrittweise ein. Zunächst nutzte es das Tool nur für einige ausgewählte, besonders wichtige Projekte: Es integrierte Git-Repositories und gab Entwicklern Zeit, sich mit der Arbeit mit Snyk vertraut zu machen. Schon bald wurde Snyk jedoch zu einem verpflichtenden Bestandteil des Onboardings für Entwickler. Diese begannen, Code direkt in ihren IDEs mit Snyk zu scannen, und beschäftigten sich stärker mit Sicherheitspraktiken. So legte Peerzadas Team den Grundstein für seinen Developer-First-Ansatz. Als nächsten Schritt fügte es den Entwicklungspipelines ein Snyk-Plug-in hinzu, um DevSecOps-Automatisierung durchzusetzen.

Was den konkreten Nutzen für uns angeht: Wir führen regelmäßig Gespräche mit Snyk, alle zwei Wochen sprechen wir mit den Solution Architects von Snyk. Sie stellen uns Daten bereit und helfen uns zu verstehen, welchen finanziellen Wert wir eingespart haben – indem sie berechnen, wie viele Arbeitsstunden nötig gewesen wären, um diese Schwachstellen ohne Snyk zu beheben. Das ist sehr wichtig und ein Realitätscheck für Kunden. Außerdem erhalten wir eine Liste der Entwickler, die Code in ihren IDEs scannen. Anhand dieser Daten können wir Developer Security Champions identifizieren.

Bei der Serverless-First-Strategie von Neiman Marcus sind verschiedene Ebenen abstrahiert, und immer mehr Sicherheitsverantwortung wird in die Cloud verlagert. Doch Anwendungscode und Bibliotheken befinden sich weiterhin in Containern – auch sie müssen geschützt werden. Deshalb konzentrierte sich Peerzadas Team darauf, Cloud-Security-Posture-Management und Application Security miteinander zu verbinden und Entwicklern zu ermöglichen, Sicherheit von Anfang an in ihre Arbeit einzubeziehen, statt sie erst nachträglich zu berücksichtigen.

Erkenntnisse aus dem Aufbau von Developer-First-Security

Peerzada nannte die folgenden Punkte als wichtigste Erkenntnisse aus seinen Erfahrungen.

1. Beginnen Sie bei der Cloud-Sicherheit mit grundlegender Cyberhygiene und Kontrollen für das Zugriffsmanagement. Diese helfen Ihnen dabei, eine Zero-Trust-Architektur aufzubauen.

2. Nutzen Sie keine Informationen, auf die Sie nicht reagieren können. Manche Unternehmen setzen zahlreiche Tools ein, die eine Flut von Warnmeldungen erzeugen. Entscheidend ist jedoch eine kontextbezogene, risikobasierte Bewertung. Im Ozean gibt es viele Fische – konzentrieren Sie sich auf die Haie.

3. Behandeln Sie Cloud-Sicherheit anders als On-Premises-Sicherheit. Sie erfordert einen anderen Ansatz. Scheuen Sie sich auf Ihrem Weg zur Cloud-Sicherheit nicht, Open-Source-Tools einzusetzen.

4. Verbinden Sie Cloud-Security-Posture-Management und Application Security miteinander und betrachten Sie sie als eine Einheit. Was Snyk mit einer zentralen Policy Engine leistet, ist hervorragend. Wenn Sie diese Silos als eine Einheit behandeln, erhalten Sie ein robustes Cybersicherheits-Framework.

Vielen Dank an Omar Peerzada, dass er seine Geschichte auf der AWS re:Invent mit uns geteilt hat! Wir freuen uns über Geschichten darüber, wie Snyk Unternehmen dabei unterstützt, Entwickler zu befähigen, Sicherheit in ihre Workflows zu integrieren.