Freigeben über

DevSecOps-Kontrollen

  • Artikel

In diesem Artikel wird beschrieben, wie Sie Sicherheitskontrollen anwenden, um die Continuous SDL-Sicherheitspraktiken zu unterstützen. Diese Sicherheitskontrollen sind ein integraler Bestandteil einer DevSecOps-Strategie, die Personen, Prozesse und Technologien umfasst. Diese Dokumentation beschreibt jede Kontrolle und zeigt, wie diese Sicherheitskontrollen auf drei Sicherheitsprofile angewendet werden. Diese Profile erfüllen übliche Sicherheitsanforderungen für allgemeine Geschäftsszenarien in den meisten Organisationen:

Diagramm der Sicherheitskontrollen im Vergleich zu Zeit und Auswirkungen.

Profile der Sicherheitskontrollen

Es gibt drei Ebenen von Kontrollprofilen, die in diesem Artikel behandelt werden.

Temporäres Minimum: Gekürztes Sicherheitsprofil für einen temporären Ausnahmezustand zur Unterstützung der schnellen Prototyperstellung von Workloads mit geringem Risiko. Dieses Profil sollte nur für temporäre Ausnahmen verwendet werden, die für eine beschleunigte Zeitleiste freigegeben werden müssen, um kritische Geschäftsanforderungen zu erfüllen. Elemente, die dieses Profil verwenden, sollten schnell in das Standardprofil aufgenommen werden.

Standard: Ausgewogener Ansatz für die meisten Workloads im Allgemeinen.

Hohe Sicherheit: Strenge Sicherheit für Workloads mit potenziell starken Auswirkungen auf geschäftliche und menschliche Sicherheit.

DevSecOps-Sicherheitskontrollen

Dieser Abschnitt enthält eine Referenz der empfohlenen Sicherheitskontrollen für jede Art von Workloads. Diese Referenz kann wie besehen übernommen werden. Alternativ kann sie an Ihre bestehenden Softwareentwicklungs- und Softwaresicherheitsprozesse angepasst werden. Die meisten Organisationen können nicht sofort alle diese Kontrollen implementieren, wenn sie nicht bereits einige umsetzen. Ein kontinuierlicher Verbesserungsansatz ist häufig der beste Ansatz: Priorisieren Sie Kontrollen, implementieren Sie die erste Kontrolle, gehen Sie zur nächsten Kontrolle, implementieren Sie sie usw. Die meisten Organisationen sollten zuerst die kritischen Grundlagen priorisieren.

Weitere Informationen finden Sie unter DevSecOps-Journey.

Dieses Diagramm fasst die Sicherheitskontrollen zusammen und zeigt, wie sie auf jedes Sicherheitsprofil der Workload angewendet werden.

Bei der Planung sollten Sie die folgenden wichtigen Aspekte berücksichtigen:

  • Linksverschiebung aber mit zweifacher Überprüfung – Diese Referenz dient dazu, Probleme so früh wie möglich zu erkennen und zu korrigieren, damit Sie sie beheben können, wenn deren Behebung noch einfacher und billiger ist (manchmal als „Linksverschiebung“ bezeichnet). Sie soll aber auch von Fehlern ausgehen und die zweifache Überprüfung später im Prozess einbeziehen. Überprüfen Sie alle Sicherheitskontrollen im CI/CD-Prozess stets zweimal und stellen Sie sicher, dass vermeidbare Probleme nicht in Produktionssysteme übertragen werden. Dieses Konzept folgt den Prinzipen „Tiefgehende Verteidigung“ und „Ausfallsicherheit“.
  • Künstliche Intelligenz (KI): Die beiden Standardauswirkungen der künstlichen Intelligenz sind:
    • Gesamten Code sichern, unabhängig davon, ob er von Personen oder generativer KI geschrieben wird
    • Beide für Sicherheit verwenden: Wenden Sie klassische und KI-Kontrollen als verfügbar an, um die Sichtbarkeit und den Kontext für alle Sicherheitsprobleme zu erhöhen (z. B. Tools für die Codeanalyse)

Sicherheitskontrollen

Die Kontrollen werden in die Phasen der Entwicklung gruppiert, auf die sie angewendet werden, und die allgemeinen Kontrollen (kritische Grundlagen), die für alle Entwicklungsphasen und Kontrollprofile gelten:

Jeder dieser Artikel wird in den folgenden Abschnitten definiert:

Kritische Grundlagen erstellen

Diese Kontrolle unterstützt Continuous SDL Übung 1 „Erstellen von Sicherheitsstandards, Metriken und Governance“, Übung 2 „Verwendung von bewährten Sicherheitsfeatures, Sprachen und Frameworks“ sowie Übung 10 „Sicherheitstraining bereitstellen“.

Standard: Diese Kontrollen gelten für alle Entwicklungsphasen und Kontrollprofile.

Sicherheitstraining bereitstellen

Diese Kontrolle konzentriert sich auf die Bereitstellung von Trainings für Ihre Fachkräfte in der Entwicklung und Sicherheitsteams zum Erkennen und Beheben von Sicherheitsproblemen im gesamten Entwicklungslebenszyklus. Ohne Sicherheitstrainings könnten Ihre Teams wichtige Sicherheitsschwachstellen übersehen, die während der Lebensdauer der Anwendungen zur Kompromittierung führen.

Daher müssen Sie Sicherheitstrainings für alle Rollen implementieren (einschließlich Benutzer, Fachkräfte in der Entwicklung, Produktmanager, Tester etc.). Jede Rolle muss über Wissen zu Sicherheitsrisiken und deren Rolle bei der Sicherheit von Anwendungen verfügen. Dieses Training kann in folgenden Formen durchgeführt werden: formales oder bedarfsgesteuertes Training, Simulationsübungen, Gefahrenmodellierung, Mentoring/Beratern, Sicherheitsexperten, Supportteams für die Anwendungssicherheit, lila Teamaktivitäten, Podcasts, Videos oder andere Lernmethoden.

Letztendlich muss jede Rolle Folgendes verstehen:

  • Warum es wichtig ist, Sicherheitsrisiken zu beheben
  • Was sie für die Sicherheit in ihrer Rolle tun muss
  • Wie man Sicherheit zum Bestandteil der alltäglichen Rolle macht

Personen, die die Perspektive des Angreifers, seine Ziele und die Art und Weise, wie sich diese in realen Sicherheitsvorfällen manifestieren, kennen, werden schnell zu Sicherheitsexperten und werden nicht versuchen, Sicherheit zu vermeiden.

Sicherheit ist ein nie endendes Spiel, bei dem sich die Bedrohungen, zu schützenden Technologien und geschäftlichen Ressourcen stets ändern und die Bedrohungsakteure nie aufgeben. Das Sicherheitstraining muss stetig und kontinuierlich weiterentwickelt werden. Effektive Trainings sind auf die folgenden Aspekte abgestimmt und verstärken Sicherheitsrichtlinien, SDL-Praktiken (Software Development Lifecycle), Standards und Anforderungen an die Softwaresicherheit. Das Trainingsmaterial sollte auf den Erkenntnissen basieren, die sich aus den Daten und den neu verfügbaren technischen Funktionalitäten ergeben.

Obwohl das Thema Sicherheit jeden etwas angeht, sollten Sie daran denken, dass nicht jeder Benutzer ein Sicherheitsexperte sein muss oder das Ziel hat, auf professioneller Ebene Penetrationstests durchzuführen. Es ist wichtig, dass jede Person die Sicherheitsgrundlagen versteht und weiß, wie sie auf ihre Rolle beim Aufbau von Sicherheit in Software und Dienste angewendet werden. Dieses Training sollte die sichere Verwendung von Workstations, Anwendungen, Identitäten und Konten umfassen.

Insbesondere sind Fachkräfte in der Entwicklung und Techniker, die Systeme bauen, in der Regel keine Sicherheitsexperten. Das Training sowohl in den technischen als auch konzeptionellen Aspekten der Gefahrenmodellierung ist erforderlich, damit sie effektiv in der Lage sind, Systeme zu entwickeln, die vom Entwurf her sicher sind. Dieses Training ist für den Prozess der Gefahrenmodellierung von entscheidender Bedeutung, um in Organisationen im großen Stil zu funktionieren, in denen es weit mehr Fachkräfte in der Entwicklung als Sicherheitsexperten gibt. Die Gefahrenmodellierung muss als grundlegende Fertigkeit in der Entwicklung betrachtet werden, in der alle Fachkräfte in der Entwicklung und Techniker mindestens grundlegende Kenntnisse vorweisen müssen. Daher müssen Entwicklungs- und Technikteams in regelmäßigen Abständen und als Teil des Onboardings in der Gefahrenmodellierung geschult werden.

Sicherheit in Post-mortem-Analysen ohne Schuldzuweisungen einschließen

Die Post-mortem-Analyse ohne Schuldzuweisungen ist eine kritisch wichtige Methode für Teams, um aus Fehlern effektiv und effizient zu lernen, ohne bei den Teammitgliedern Abwehrhaltungen hervorzurufen, indem sie einen Schuldigen suchen. Sicherheitserkenntnisse sollten explizit in den Prozess der Post-mortem-Analyse ohne Schuldzuweisungen einbezogen werden, um sicherzustellen, dass die Teams auch ein Maximum an Sicherheit lernen.

Sicherheitsstandards, Metriken und Governance einrichten

Organisationen sollten diese Sicherheitsstandards, Metriken und Governance einrichten, da sie die Fähigkeit, Innovationen zu erlangen, unterstützen. Sie ermöglichen ein leistungsstarkes Sicherheitsprogramm, das nicht nur die Ressourcen der Organisation schützt, sondern auch mit dessen Geschäftszielen übereinstimmt. Bei den Sicherheitsstandards handelt es sich um die grundlegenden Anforderungen und bewährten Methoden, die die Sicherheit von Systemen, Daten und Prozessen einer Organisation gewährleisten.

Diese Standards sollten überprüft und verwaltet werden, einschließlich der Überwachung der Einhaltung und der regelmäßigen Bewertung und Aktualisierung dieser Standards im Hinblick auf aktuelle Bedrohungen, Werkzeuge und andere Faktoren. Dieser Prozess sollte den gesamten Lebenszyklus von der anfänglichen Idee bis hin zur Außerbetriebnahme der Anwendung und aller unterstützenden Entwicklungsumgebungen abdecken.

Metriken werden verwendet, um die Effektivität der Sicherheitskontrollen und -prozesse zu messen. Eine Schlüsselmetrik ist die Mean Time To Remediate (MTTR). Damit kann festgestellt werden, wie lange eine Anwendung verwundbar ist. Diese Messung ermöglicht es uns, strategisch schneller in die Veröffentlichung von Sicherheitspatches zu investieren.

Hinweis

Dieses Konzept unterscheidet sich von MTTR bei Security Operations, die sich auf die Zeit konzentrieren, um den Angreiferzugriff auf die Ressourcen der Organisation zu entfernen.

Die Sicherheitsgovernance fungiert als Leitfaden für Sicherheitsteams und basiert häufig auf Frameworks und Prozessen, die Organisationen zum Verwalten und Steuern ihrer Informationssicherheit nutzen. Dazu gehören Richtlinien,Vorgehensweisen, Kontrollen und Risikomanagement. Metriken helfen bei der Quantifizierung der Risikogefährdung. Ohne sie versteht die Organisation ihre Verwundbarkeiten und potenziellen Auswirkungen möglicherweise nicht vollständig.

Da sicherheitsrelevante Anforderungen möglicherweise neu sind, haben Sie die Möglichkeit, einen progressiven Ansatz zu ergreifen, der die Codierungsstandards schrittweise in einen idealen Zustand versetzt. Dieser Ansatz bietet Teams Zeit, um die Überwachung und Steuerung zu erlernen und zu automatisieren.

Verwendung bewährter Sicherheitsfeatures, Sprachen und Frameworks

Definieren und veröffentlichen Sie eine Liste genehmigter Tools und der zugehörigen Sicherheitsprüfungen. Die Verwendung von erprobten und bewährten Sicherheitslösungen ist wichtig, um häufige Fehler zu vermeiden, da die Entwicklung sicherer Lösungen sehr herausfordernd ist. Der Versuch, Sicherheitslösungen neu zu erfinden, führt fast immer zu einer Erhöhung des Sicherheitsrisikos und zu einer Verschwendung von Zeit und Aufwand.

Stellen Sie sicher, dass Fachkräfte in der Entwicklung und Techniker neue Funktionalitäten und Schutzmaßnahmen für die Sicherheitsanalyse nutzen. Sie sollten immer den Compiler, den Linker, die Bibliotheken und die entsprechenden Compiler- und Linker-Flags in der aktuellsten Version verwenden, um sichere ausführbare Dateien zu generieren.

Organisationen sollten einen Prüfungs- und Genehmigungsprozess implementieren, um die Sicherheit aller integrierten Komponenten zu validieren. Sie sollten eine Richtlinie einrichten, um genehmigte Komponenten nur in Build- und Bereitstellungsprozessen zu verwenden, die durchgesetzt und überwacht werden.

Grundlegende Identitätssicherheit

Stellen Sie sicher, dass die Verwendung und Integration von Identität bewährten Sicherheitsmethoden folgt. Bedrohungsakteure verwenden häufig Identitätsangriffstechniken gegen Produktionssysteme und Entwicklungsprozesse. Eine beliebte Aussage fasst das zusammen: „Angreifer brechen nicht ein, sie loggen sich nur ein“.

Identitätssicherheit nimmt bei der Entwicklung folgende beide Formen an:

  • Identitätssicherheit für den Entwicklungsprozess: Stellen Sie sicher, dass alle Teilnehmer*innen im Entwicklungsprozess strenge Authentifizierungsmethoden für ihre tägliche Arbeit verwenden und nur über Rechte verfügen, die zum Ausführen ihrer Aufgaben erforderlich sind. Weitere Informationen finden Sie im Abschnitt Zugriffssteuerung für Identitäts/Anwendung.
  • Identitätssicherheit für Systeme und Anwendungen: Stellen Sie sicher, dass die Systeme, die sie entwerfen und entwickeln, bewährte Methoden für Authentifizierungs- und Autorisierungsmethoden befolgen (und nicht eigene schwache Imitationen bewährter und nachhaltiger Identitätssysteme erstellen).

Wenden Sie die Identitätssicherheit für Systeme und Anwendungen an, indem Sie den Anweisungen in diesen Ressourcen folgen:

Kryptografiestandards

Wenden Sie solide kryptografische Methoden auf alle Einsätze von Kryptografie an. Befolgen Sie alle in Continuous SDL Übung 4 „Kryptografische Standards definieren und verwenden“ beschriebene Richtlinien.

Weitere Informationen finden Sie in Microsoft-Empfehlungen zur SDL-Kryptografie.

Sicherheit Ihrer Entwicklungsumgebung

Diese Kontrolle unterstützt Continuous SDL Übung 6 „Sicherheit Ihrer Entwicklungsumgebung“.

Diese Kontrolle konzentriert sich auf die Sicherheit Ihrer Entwicklungsumgebung mit sicheren Workstations und integrierten Entwicklungsumgebungen (IDEs). Diese Kontrolle hebt den Vorteil der Verwendung eines Zero Trust-Ansatzes in Ihrem Lebenszyklus der Softwareentwicklung hervor.

In der aktuellen Landschaft erweitern Angreifer ihre Operationen, um die Computer Ihrer Fachkräfte in der Entwicklung anzugreifen und Buildprozesse zu manipulieren. Ein zentrales Beispiel für einen solchen Angriff war der Angriff auf SolarWinds, bei dem der Angreifer eine schädliche DLL vor den letzten Phasen des Softwarebuilds einfügte. Die Anwendung verfügte dadurch effektiv über eine Hintertür, was zu einem gezielten Angriff führte, der über die Lieferkette an Tausende von Kunden weltweit weitergegeben wurde. Weitere Informationen zum SolarWinds-Angriff finden Sie im Microsoft Blog Analyse von Solorigate, der kompromittierten DLL-Datei, die einen komplexen Cyberangriff auslöste und wie Microsoft Defender Kunden schützt.

Es ist wichtig, Workstations zu härten, Umgebungen, Identitäten und andere Entwicklungssysteme zu erstellen, um die Integrität der entwickelten Anwendungen zu gewährleisten. Wenn Sie dies nicht tun, wird ein Pfad für Angreifer geschaffen, um Ihre Anwendung über Ihr SCM-System (Source Code Management) oder Ihre Entwicklungsarbeitsstation zu kompromittieren.

Diese Methode ist eine wichtige Grundlage ihres Entwicklungslebenszyklus und sollte über alle Profile hinweg eingeführt werden.

In dieser Methode müssen Sie einen Zero Trust-Ansatz ergreifen. Im Wesentlichen erfordert das Zero Trust-Modell, dass jede Zugriffsanforderung (Benutzer, Dienst oder Gerät) überprüft wird, als ob sie von einem nicht vertrauenswürdigen Netzwerk stammt, unabhängig davon, woher die Anforderung stammt oder auf welche Ressource zugegriffen wird. Die Richtlinie „Immer authentifizieren und autorisieren“ gilt für alle verfügbaren Datenpunkte. Sie sollten den Benutzerzugriff, insbesondere privilegierte Benutzer, über Just-In-Time- und Just-Enough-Access-Richtlinien (JIT/JEA) einschränken und den Segmentzugriff beschränken, um den möglichen Schaden zu minimieren, wenn eine Verletzung vorliegt.

Die Härtung Ihrer Entwicklungsumgebung kann durch verschiedene Methoden erreicht werden, aber ein guter Startpunkt besteht darin, die Entwicklungsarbeitsstation zu berücksichtigen. Durch die Verwendung von Technologien wie GitHub Codespaces oder Microsoft DevBox verschieben Sie die Entwicklungsumgebung auf SaaS-Anwendungen, die dann über Sicherheits- und Netzwerkeinstellungen oder durch organisationsweite Richtlinien verwaltet werden können.

Um weitere Sperrmodus-Entwicklungsarbeitsstationen zu erhalten, können Sie ihnen Workstations mit privilegiertem Zugriff/Workstations mit sicherem Zugriff (PAW/SAW) ausstellen. Diese Workstations helfen Ihnen, Bedrohungsvektoren zu reduzieren und ein standardisiertes und kontrolliertes Entwicklergerät sicherzustellen.

Sichere Entwürfe

Durchführen der Gefahrenmodellierung (Überprüfung des Sicherheitsentwurfs)

Diese Kontrolle unterstützt Continuous SDL Übung 3 „Gefahrenmodellierung durchführen“.

Diese Kontrolle identifiziert Sicherheitsschwachstellen im Entwurf, die zu Sicherheitsvorfällen und Geschäftsschäden führen können. Sicherheitsschwachstellen im Design können nach der Implementierung schwer entschärft werden. Daher ist es wichtig, diese Schwachstellen frühzeitig im Lebenszyklus zu entdecken und zu beheben.

Die Gefahrenmodellierung dient als Prozess zur Prüfung des Sicherheitsentwurfs, der Sicherheit in den Entwurf eines Systems oder einer Anwendung integriert.

Die Gefahrenmodellierung identifiziert, bewertet, priorisiert und mindert Sicherheitsrisiken innerhalb eines Softwaresystems systematisch. Dieser strukturierte Ansatz zur Analyse des Entwurfs und der Architektur einer Softwareanwendung identifiziert potenzielle Bedrohungen und Schwachstellen frühzeitig im Entwicklungsprozess.

Das Hauptziel ist das Verständnis des Systems und der Dinge, die schief gehen können. Die Gefahrenmodellierung trägt zur Erreichung dieses Ziels bei, indem ein tiefes Verständnis sowohl des Systems selbst als auch der Art und Weise angewendet wird, wie ein potenzieller Angreifer es sieht.

Bei diesem Prozess handelt es sich in der Regel um Workshops zur Bedrohungsermittlung, in denen ein Expertenteam des Systems und Sicherheitsexperten zusammenarbeiten, um Risiken zu erkennen und zu dokumentieren. Dieser Prozess kann zwar informell beginnen, sollte sich jedoch schnell zu einem strukturierten Prozess entwickeln, der jeden Aspekt des zu erstellenden Diensts, dessen Verwendung und Systemschnittstellen erläutert.

Die Phasen der Gefahrenmodellierung sind:

  1. Identifizieren von Anwendungsfällen, Szenarien und Ressourcen: Beginnen Sie mit einem Verständnis der Geschäftsfunktionen und Anwendungsfälle, die das System ermöglicht, um die potenziellen geschäftlichen Auswirkungen eines kompromittierten Systems abzuschätzen und um Informationen für die Diskussion zur Verfügung zu stellen.
  2. Erstellen einer Architekturübersicht: Erstellen Sie eine visuelle Zusammenfassung der Anwendung (oder verwenden Sie eine vorhandene), um ein klares Verständnis des Systems und deren Funktionsweise zu erhalten. Diese Übersicht sollte Folgendes umfassen: eine Geschäftsprozessplan, Komponenten und Subsysteme, Vertrauensgrenzen, Authentifizierungs- und Autorisierungsmechanismen, externe und interne Schnittstellen sowie Datenflüsse zwischen Akteuren und Komponenten.
  3. Identifizieren von Bedrohungen: Verwenden Sie eine gängige Methode zur Enumeration potenzieller Sicherheitsbedrohungen, z. B. des STRIDE-Modells oder der OWASP-Gefahrenmodellierung.
  4. Identifizieren und Nachverfolgen von Risikominderungen: Überwachen Sie entdeckte Entwurfsfehler mithilfe vorhandener Entwicklungsprozesse und -tools und verfolgen Sie diese nach, um sicherzustellen, dass die Behebungen implementiert und dokumentiert werden. Dieser Prozess sollte die Priorisierung der Risikominderungen umfassen, die zuerst ausgeführt werden sollen, damit sich Teams zuerst auf die wichtigsten Themen konzentrieren. Dieser Prozess ist risikogesteuert und Sie verfügen möglicherweise nicht über Ressourcen, um alle Risiken im ersten Zyklus vollständig zu mindern. Überlegen Sie sorgfältig, welche Risikominderungen, einschließlich teilweiser Risikominderungen, die Kosten für einen Angreifer erhöhen, um die geringsten Abwehrkosten und Ressourcen zu haben. Das Ziel der Sicherheit ist das Scheitern von Angreifern. Dies kann in Form einer vollständigen Blockierung einer Angriffstechnik, ihrer Erkennung, um eine Reaktion des Verteidigers zu ermöglichen, ihrer Verlangsamung, um dem Verteidiger Zeit zur Reaktion zu geben, der Begrenzung des Schadensumfangs und vielem mehr geschehen.

Ein Gefahrenmodell dient häufig als Bildungsprozess für alle Beteiligten sowie als wichtiger Kontext für andere Sicherheitsplanungen, die Implementierung und Tests.

Anwendungen, die die Verwendung von KI-Komponenten (Künstliche Intelligenz) enthalten, müssen die spezifischen Risikotypen auswerten, die mit KI verbunden sind und sich von klassischen Anwendungen unterscheiden.

Erstellen und analysieren Sie Gefahrenmodelle, indem Sie über den Sicherheitsentwurf ihrer Systeme kommunizieren, diese Entwürfe für potenzielle Sicherheitsprobleme mithilfe einer bewährten Methodik analysieren und Risikominderungen für Sicherheitsprobleme vorschlagen und verwalten.

Sicherer Code

Codeanalyse

Diese Kontrolle unterstützt Continuous SDL Übung 7 „Ausführen von Sicherheitstests“.

Diese Kontrolle konzentriert sich auf die Erhöhung der Codesicherheit, wenn Fachkräfte in der Entwicklung ihn in eine integrierte Entwicklungsumgebung (IDE) schreiben/eingeben oder während der Überprüfung von Code. Diese Kontrolle ist der Eckpfeiler der DevSecOps-Methoden, da sie direkt Verwundbarkeiten behandelt, die Angreifer regelmäßig missbrauchen.

Ohne diese Kontrolle übersehen Sie möglicherweise Verwundbarkeiten, die von Ihren Fachkräften in der Entwicklung direkt in Ihre Anwendung codiert werden. Ihre Fachkräfte in der Entwicklung handeln nicht böswillig, aber möglicherweise fehlen ihnen die erforderlichen Kenntnisse, um zu ermitteln, warum der von ihnen erstelle Code unsicher ist.

Diese Kontrolle ist entscheidend, um die Produktivitäts- und Sicherheitsvorteile eines Shift-Left-Konzepts zu erzielen, indem Tools direkt in die IDE integriert werden. Dieser Prozess ermöglicht die frühzeitige und kostengünstige Erkennung und Behebung von Verwundbarkeiten. Dieser Prozess kann rückwirkend auf bereits entwickelte Anwendungen angewendet werden, indem Sicherheitsschwachstellen identifiziert und später behoben werden (allerdings zu höheren Kosten und mit größerem Aufwand).

Dieser Prozess verwendet in der Regel IDE-Plug-Ins oder dedizierte Scantools, die den Code mithilfe von Static Analysis Security Testing (SAST)- und Dynamic Analysis Security Testing (DAST)-Toolsets scannen.

SAST-Tools scannen die vorhandene Codebasis und haben Vollzugriff auf den Code. SAST-Tools können grundlegende Schwächen im Code selbst erkennen. DAST auf der anderen Seite wird auf der bereitgestellten Anwendung ausgeführt. Das Tool hat daher keinen Zugriff auf den Code und wird ausgeführt, um Sicherheitsschwachstellen zur Laufzeit zu simulieren und zu identifizieren.

Hinweis

KI-Anwendungen haben verschiedene Arten von Verbundbarkeiten (z. B. Verzerrungen und Halluzinationen) als klassische Anwendungen und erfordern Tools, die sich auf diese Punkte konzentrieren.

Qualitätskontrolle ist ausschlaggebend! Eine wichtige Überlegung beim Einsatz dieser Tools ist, dass sie optimiert werden sollten, um das Fehler und den Aufwand, der durch falsch-positive Ergebnisse entsteht, zu reduzieren. Die Optimierung dieser Tools erfordert in der Regel einen Sicherheitsexperten mit einem Entwicklerhintergrund, der die Entwicklungsprozesse Ihrer Organisation versteht. Die gleichen Experten können auch Anleitungen zur Selektierung und Fachwissen zu individuellen Erkennungen für Fachkräfte in der Entwicklung bereitstellen. Sie können bei der Unterscheidung zwischen echten und falsch-positiven Ergebnissen, echten Problemen und Fehlalarmen behilflich sein. Die Verfahren, die es den Fachkräften in der Entwicklung ermöglichen, auf diese Experten zuzugreifen, sind oft eng mit der Bereitstellung von Sicherheitstrainings zusammen, z. B. durch Expertenprogramme oder Supportteams für die Anwendungssicherheit.

Temporäres Minimum: Stellen Sie sicher, dass Sie integrierte IDE-Sicherheitsfeatures aktivieren und ein Mindestmaß an SAST-Scans in Ihrem Repository implementieren, um Verwundbarkeiten in der gesamten Anwendung zu identifizieren. Es muss ein dokumentiertes Verfahren vorhanden sein, um erkannte Probleme in angemessener Zeit zu beheben, wobei der Fehlerstandard, welche Fehler behoben werden müssen, begrenzt ist, bis die Anwendung das standardmäßige ausgewogene oder hohe Sicherheitsprofil erreicht.

Standard: Stellen Sie sicher, dass Sie alle Komponenten mit allen anwendbaren SAST/DAST-Tools vollständig scannen und Schwachstellen identifizieren. Stellen Sie eine vollständige Sicherheitsabdeckung über Ihren Anwendungscode sicher. Stellen Sie sicher, dass Sie dem dokumentierten Verfahren zur Behebung folgen und über einen Fehlerstandard verfügen, der der Risikotoleranz Ihrer Organisation entspricht.

Hohe Sicherheit: Stellen Sie sicher, dass alle anwendbaren Anwendungen einen detaillierten und dokumentierten Prozess erzwingen, der alle Sicherheitsrisiken behandelt. Erzwingen Sie die Behebung vor Build- oder Releaseaktivitäten. Stellen Sie sicher, dass Sie dem dokumentierten Verfahren zur Behebung folgen und über eine streng restriktive Fehlerleiste verfügen, die der Risikotoleranz Ihrer Organisation für unternehmenskritische Workloads mit hoher Sicherheit entspricht.

Es stehen zahlreiche Tools zur Verfügung, die für statische Analysen verwendet werden können. Überprüfen Sie die Liste unter Microsoft Security Development Lifecycle, um weitere Informationen zu erhalten.

Sichern der CI/CD-Pipeline

Lieferketten-/Abhängigkeitsverwaltung

Diese Kontrolle unterstützt Continuous SDL Übung 5 „Sicherung der Software-Lieferkette“.

Diese Kontrolle konzentriert sich auf die Sicherung Ihrer Entwicklungslieferkette mithilfe von Tools und Frameworks zur Softwarezusammensetzungsanalyse (SCA) wie dem Secure Supply Chain Consumption Framework (S2C2F). Diese Prozesse tragen dazu bei, das Risiko einer Kompromittierung durch nicht von Microsoft stammenden Code zu verringern.

In der heutigen Landschaft basieren die meisten Anwendungen auf Open-Source-Software (OSS) mit wenig Aufsicht oder Kontrolle von Verbrauchern dieser Komponenten. Diese Kontrolle hebt Kernstrategien, Techniken und Technologien hervor, um OSS sicher zu erfassen, zu verbrauchen, zu nutzen und zu unterstützen. Außerdem wird die Sicherung interner Abhängigkeiten hervorgehoben. Darüber hinaus wird ein vollständiger End-to-End-Lebenszyklus sichergestellt, unabhängig davon, wer die Software codiert hat.

Wenn Sie Ihre Software-Lieferkette nicht kontrollieren, setzen Sie sich erheblichen Sicherheitsrisiken durch Code aus, den Sie nicht kontrollieren. Ein bekanntes Beispiel ist die Verwundbarkeit von log4J/Log4Shell, die die Remote-Ausführung von Code in beliebigen Systemen oder Anwendungen mit diesem Paket ermöglichte. Solche Verwundbarkeiten können versehentlich oder böswillig auftreten.

Die Sicherung der Lieferkette ist ein wesentlicher Bestandteil eines sicheren Entwicklungslebenszyklus und sollte in jedem Profilstatus berücksichtigt werden, obwohl jeder einzelne Status dem gleichen standardisierten Prozess zur Aufnahme von Abhängigkeiten folgen sollte.

Temporäres Minimum: Führen Sie die Inventur aller Abhängigkeiten durch, damit Sie die Auswirkungen einer OSS-Verwundbarkeit auf Ihre Anwendung verstehen. Diese Inventur kann mithilfe von Dependabot oder anderen Tools zur Softwarezusammensetzungsanalyse (SCA) erzielt werden. Diese Tools können Ihnen auch helfen, eine Software-Stückliste (Software Bill of Materials, SBOM) zu generieren.

Standard: Analysieren Sie alle OSS-Verwundbarkeiten und beheben Sie sie automatisch mit automatischen Pull Requests. Diese Kontrolle kann auch mithilfe von Dependabot und dem GitHub-Abhängigkeitsdiagramm/der GitHub–Abhängigkeitsprüfung erreicht werden.

Hohe Sicherheit: Blockieren Sie aktiv alle unsicheren Pakete mit ausnutzbaren Sicherheitsanfälligkeiten, die in der Anwendung verwendet werden.

Weitere Informationen zu dieser Kontrolle und zur Messung Ihrer OSS-Sicherheitsreife finden Sie in der Dokumentation zu OSS Supply Chain Framework und Bewährte Methoden zur Sicherung Ihres Entwicklungslebenszyklus mit GitHub.

Sicherheits-Code Review

Diese Kontrolle konzentriert sich auf die Überprüfung eines Codes für Sicherheitsexperten, um potenzielle Sicherheitsfehler zu identifizieren. Sie hilft bei der Suche nach Sicherheitsproblemen, deren Erkennung schwer zu automatisieren ist.

Diese Prüfung kann von folgenden Personen durchgeführt werden: von einem Kollegen im selben Team mit Kenntnissen im Bereich Anwendungssicherheit, einem Sicherheitsexperten innerhalb der Organisation, einem Experten für Anwendungssicherheit aus dem zentralen App-Sicherheitsteam oder einer externen Partei.

Diese Prüfung sollte immer durch eine andere Person als die Person erfolgen, die für das Schreiben des Codes verantwortlich ist. Diese Prüfung sollte als separate Aktivität durchgeführt werden, nachdem die automatisierte Code Analysis abgeschlossen ist.

Temporäres Minimum: Diese Kontrolle wird für dieses Profil empfohlen.

Standard: Diese Kontrolle wird für dieses Profil empfohlen.

Hohe Sicherheit: Diese Kontrolle ist für alle Anwendungen mit hoher Sicherheit erforderlich und umfasst häufig mehrere einzelne Experten.

Scannen von Anmeldedaten und Geheimnissen

Diese Kontrolle unterstützt Continuous SDL Übung 7 „Ausführen von Sicherheitstests“.

Diese Kontrolle konzentriert sich auf die Verringerung des Risikos von Authentifizierungsschlüsseln und anderen Geheimnissen, die im Code verfügbar gemacht werden. Bedrohungsakteure verfügen über Fachwissen und Automatisierung, um eingebettete Geheimnisse im Code zu finden und auszunutzen.

Der beste Ansatz ist die Verwendung von verwalteten Identitäten und modernen Authentifizierungsprotokollen anstelle von Schlüsseln und Geheimnissen, wann immer dies möglich ist. Während die Verwendung von API-Schlüsseln und Geheimnissen traditionell eine Kodierungs- und Testmethode war, sollte die bevorzugte Methode immer die identitätsbasierte Authentifizierung von Ressourcen sein, da die Sicherheits- und Lebenszyklusmanagementfähigkeiten verbessert wurden. Diese Kontrolle wird durch die Verwendung verwalteter Identitäten, beispielsweise verwalteter Identitäten für Azure-Ressourcen, umgesetzt.

Wenn die Verwendung von Geheimnissen erforderlich ist, müssen Sie sie über den gesamten Lebenszyklus einschließlich ihrer Erstellung, Verwendung, regelmäßigen Rotation und Sperrung sichern. Vermeiden Sie die direkte Verwendung von Geheimnissen im Code, und speichern Sie sie nur bei Bedarf in einem sicheren Schlüssel/geheimen Speichersystem wie Azure Key Vault oder einem Hardwaresicherheitsmodul (HSM). Keinesfalls dürfen Nur-Text-Schlüssel und -Geheimnisse im Code gespeichert werden, auch nicht temporär! Angreifer werden diese Geheimnisse finden und ausnutzen.

Wichtig

Interne Repositorys für Quellcode sind nicht sicher!

Interne Repositorys sollten den gleichen Anforderungen unterliegen wie öffentlich zugängliche Repositorys, da Bedrohungsakteure, die häufig in Repositorys nach Geheimnissen und Schlüsseln suchen, durch Phishing oder andere Methoden Zugang zu einer Umgebung erlangt haben. Dies ist für einen Zero Trust-Ansatz erforderlich, bei dem die Akzeptanz und der Entwurf von Sicherheitskontrollen erforderlich sind.

Standard: Eine gute Pflege geheimer Schlüssel und Geheimnisse ist unerlässlich und ist in allen Profilen erforderlich.

Hinweis

Da diese Geheimnisse von Ihren Teams oder Angreifern gefunden werden können, müssen Sie nicht nur den Mechanismus auf eine sicherere Zugriffsmethode wie verwaltete Identitäten umstellen, sondern auch sicherstellen, dass der Schlüssel nicht für den Zugriff auf Ressourcen verwendet werden kann (abhängig vom Ressourcentyp).

Weitere Details und Ressourcen beinhalten:

Hinweis

Wir empfehlen dringend die Verwendung pro Workload-Schlüssel mit geheimen Speicherlösungen wie Azure Key Vault.

Sichere Pipeline

Diese Kontrolle unterstützt Continuous SDL Übung 5 „Sicherung der Software-Lieferkette“.

Diese Kontrolle konzentriert sich auf die Sicherung der DevOps-Pipeline und aller Artefakte, die während der Buildprozesse Ihrer Anwendung erstellt wurden.

Pipelines sind ein wesentlicher Bestandteil der Automatisierung von wichtigen wiederholbaren Aktivitäten innerhalb des DevSecOps-Lebenszyklus. Bei CI/CD führt Ihr Team regelmäßig den gesamten Entwicklungscode in einer zentralen Codebasis zusammen. Darauf basierend werden automatisch die standardmäßigen Build- und Testprozesse ausgeführt, die Toolsets für die Sicherheit beinhalten.

Die Verwendung von Pipelines zum Ausführen von Skripts oder Bereitstellen von Code in Produktionsumgebungen kann besondere Sicherheitsanforderungen mit sich bringen. Stellen Sie sicher, dass sich aus Ihren CI/CD-Pipelines keine Möglichkeiten ergeben, bösartigen Code auszuführen, Anmeldedaten zu stehlen oder eine Angriffsfläche zu bieten. Sie sollten außerdem sicherstellen, dass nur der vom Team zur Veröffentlichung vorgesehene Code bereitgestellt wird. Dieser Prozess umfasst Artefakte Ihrer CI/CD-Pipelines, insbesondere Artefakte, die von verschiedenen Tasks gemeinsam genutzt werden und als Teil eines Angriffs verwendet werden können.

Die Generierung einer Software-Stückliste (Software Bill of Materials, SBOM) sollte im Buildprozess automatisiert werden, um dieses kritisch wichtige Artefakt zur Codeermittlung ohne manuelle Entwicklungseingriffe zu erstellen.

Die Sicherheit der Pipeline kann durch eine gute Zugriffskontrolle auf die in der Pipeline verwendeten Ressourcen und durch regelmäßige Überprüfung/Aktualisierung der Kernabhängigkeiten/Skripte gewährleistet werden. Es ist wichtig zu beachten, dass Skripts, die in CI/CD-Pipelines verwendet werden, auch Code sind und auf die gleiche Weise behandelt werden sollten, wie Sie anderen Code in Ihrem Projekt behandeln.

Hinweis

Die Sicherheit der Pipeline hängt von der Sicherheit der zugrunde liegenden Infrastruktur und den Konten/Identitäten ab, die für den Prozess verwendet werden. Weitere Informationen finden Sie in der Sicherung Ihrer Entwicklungsumgebung und den Kontrollen für sichere Operationen (Identitäts-/App-Zugriffssteuerungen, Host-/Containersteuerelemente, Netzwerkzugriffssteuerelemente).

Standard: Diese Kontrolle sollte auf einer Zugriffsebene für jede Ressource im Projekt ausgewertet werden. Diese Kontrolle ist auf allen DevSecOps-Profilebenen erforderlich.

Weitere Informationen zur Pipelinesicherheit finden Sie unter Schützen von Azure-Pipelines.

Sichere Vorgänge

Penetrationstests für Livewebsites

Diese Kontrolle unterstützt Continuous SDL Übung 7 „Ausführen von Sicherheitstests“.

Lassen Sie professionelle Penetrationstester für Anwendungen versuchen, eine Liveinstanz der gesamten Workload zu kompromittieren. Bei diesen Tests wird überprüft, ob die Sicherheitskontrollen der Workload effektiv und konsistent sind. Penetrationstests helfen, den Weg des geringsten Widerstands zu finden und aufzuzeigen, den ein Angreifer nutzen könnte, um Ihre Anwendung auszunutzen und Ihr Unternehmen zu kompromittieren. Penetrationstests können unglaublich wertvoll sein, wenn sie zum richtigen Zeitpunkt durchgeführt werden. Verwenden Sie sie, nachdem Sie die billigen und leicht ausnutzbaren Sicherheitsanfälligkeiten aus früheren Scans beseitigt haben.

Es wird empfohlen, diese Tests auf allen Ebenen der DevSecOps-Sicherheitsprofile durchzuführen.

Temporäres Minimum: Wir empfehlen, einen Penetrationstest für alle Anwendungen durchzuführen. Aufgrund von Zeitbeschränkungen kann es sein, dass Sie nur einfachere Methoden in der Anwendung identifizieren können, die ein Angreifer ausnutzen könnte. Sie sollten sich bemühen, dies schnell auf das Standardniveau zu bringen.

Standard: Bei einem Standardprofil empfehlen wir die Durchführung eines Penetrationstests. In diesem Fall kann die zusätzliche Sorgfalt in einem frühen Stadium des Entwicklungsprozesses dazu führen, dass komplexere Verwundbarkeiten aufgedeckt werden.

Hohe Sicherheit: Für Branchenanwendungen und kritische Workloads ist die Durchführung eines Penetrationstests erforderlich. Jede Verwundbarkeiten in diesen Anwendungen sollte mit zusätzlicher Aufmerksamkeit und Sorgfalt behandelt werden.

Integrieren Sie die Ergebnisse und das Feedback aus diesen Aktivitäten, um Ihre Sicherheitsprozesse und -tools zu verbessern.

Identitäts-/Anwendungszugriffskontrollen

Diese Kontrolle unterstützt Continuous SDL Übung 8 „Sicherstellen der Sicherheit der operativen Plattform“ und Übung 6 „Sicherheit Ihrer Entwicklungsumgebung“.

Stellen Sie sicher, dass bewährte Methoden für die Identitäts- und Zugriffsverwaltung, einschließlich dem Schutz des privilegierten Zugriffs, für alle technischen Elemente der Entwicklungsumgebung, der CI/CD-Pipeline, der operativen Workload und anderer Entwicklungssysteme befolgt werden. Bedrohungsakteure verfügen über komplexe Methoden und Automatismen für Identitätsangriffe, die sie häufig sowohl gegen Produktionssysteme als auch gegen Entwicklungsprozesse einsetzen. Die Identitäts- und Zugriffsverwaltung ist ein grundlegender Teil des Zero Trust-Modells, das Microsoft empfiehlt.

Stellen Sie sicher, dass bewährte Methoden für alle Entwicklungssysteme und die Infrastruktur befolgt werden, die sie hosten (VMs, Container, Netzwerkgeräte etc.).

Temporäres Minimum: Stellen Sie sicher, dass jede Person die Multi-Faktor-Authentifizierung verwendet und nur auf Systeme zugreifen kann, die zum Ausführen der jeweiligen täglichen Aufgaben erforderlich sind.

Standard: Stellen Sie sicher, dass die Infrastrukturkomponenten, die den Workload hosten (z. B. VMs, Container, Netzwerk und Identitätssysteme), den bewährten Methoden für die Identitäts- und Zugriffsverwaltung entsprechen, einschließlich des Schutzes privilegierten Zugriffs.

Hohe Sicherheit: Implementieren Sie eine vollständige Zero Trust-Strategie, die MFA, Identity Threat Detection and Response und Cloud Infrastructure Entitlement Management (CIEM) enthält. Führen Sie ein spezifisches Gefahrenmodell für jede Workload von Identitätssystemen und -komponenten durch, die jede Workload mit hoher Sicherheit unterstützen.

Verwaltete Identitäten sind nach Möglichkeit die sicherere und bevorzugte Authentifizierungsmethode. Die Verwendung von Token und Geheimnissen ist weniger sicher, da sie auf Anwendungsebene gespeichert und abgerufen werden müssen. Darüber hinaus werden verwaltete Identitäten automatisch übertragen, ohne dass ein manueller Eingriff erforderlich ist.

Weitere Details und Ressourcen beinhalten:

Host-/Container-/Umgebungskontrollen

Diese Kontrolle unterstützt Continuous SDL Übung 8 „Sicherstellen der Sicherheit der operativen Plattform“ und Übung 6 „Sicherheit Ihrer Entwicklungsumgebung“.

Stellen Sie sicher, dass bewährte Methoden zur Sicherheit für alle Computeressourcen und Hostumgebungen für alle technischen Elemente des Entwicklungslebenszyklus befolgt werden. Bedrohungsakteure verfügen über komplexe Methoden und Automatismen für Angriffe auf Infrastruktur und Benutzerendpunkte, die sie häufig sowohl gegen Produktionssysteme als auch gegen Entwicklungsprozesse einsetzen. Die Infrastruktursicherheit ist ein grundlegender Teil des Zero Trust-Modells, das Microsoft empfiehlt.

Diese Kontrolle muss alle Elemente des Entwicklungs- und Operationslebenszyklus umfassen, einschließlich, aber nicht beschränkt auf:

  • Allgemeine IT/operative Workstations und Umgebungen
  • Dedizierte Entwicklungsarbeitsstationen und Umgebungen
  • CI/CD-Pipelineinfrastruktur
  • Hostumgebungen für Workloads
  • Alle anderen Entwicklungssysteme.

Diese Kontrolle enthält alle Ressourcen, die beliebigen Code ausführen können, einschließlich, aber nicht beschränkt auf:

  • Virtual Machine (VM) Hosts und VMs
  • Container und Containerinfrastruktur
  • Hostingplattformen für Anwendungen, Skripte und Code
  • Cloud-Abonnements/-konten und Registrierungen
  • Workstations für Fachkräfte in der Entwicklung, Benutzer und IT-Administratoren

Stellen Sie sicher, dass Sie bewährte Methoden auf die Infrastrukturkomponenten anwenden, einschließlich Sicherheitsupdates (Patches), grundlegender Sicherheitskonfigurationen etc.

Temporäres Minimum: Wenden Sie Standardkonfigurationen für Unternehmen für Hosts und Abonnements an.

Standard: Stellen Sie sicher, dass die Infrastruktur die bewährten Methoden für Sicherheit erfüllt, die im Microsoft Cloud Security Benchmark (MCSB) beschrieben sind.

Hohe Sicherheit: Wenden Sie MCSB-Standards streng an und führen Sie ein spezifisches Gefahrenmodell für jede Workload der Infrastruktur aus, die jede Workload mit hoher Sicherheit unterstützen.

Weitere Details und Ressourcen beinhalten:

Kontrolle des Netzwerkzugriffs

Diese Kontrolle unterstützt Continuous SDL Übung 8 „Sicherstellen der Sicherheit der operativen Plattform“ und Übung 6 „Sicherheit Ihrer Entwicklungsumgebung“.

Stellen Sie sicher, dass bewährte Methoden für die Netzwerkzugriffsverwaltung für alle technischen Elemente der Entwicklungsumgebung, der CI/CD-Pipeline, der Workload-Umgebung und anderer Entwicklungssysteme befolgt werden. Bedrohungsakteure verfügen über komplexe Methoden und Automatismen für Identitätsangriffe, die sie häufig sowohl gegen Produktionssysteme als auch gegen Entwicklungsprozesse einsetzen. Die Netzwerksicherheit ist ein grundlegender Teil des Zero Trust-Modells, das Microsoft empfiehlt.

Die Netzwerksicherheit sollte Folgendes umfassen:

  • Externer Netzwerkschutz: Isolierung von unerwünschtem externen/Internet-Datenverkehr und Entschärfung bekannter Angriffstypen. Diese Isolierung erfolgt in der Regel in Form von Internet-Firewalls, Web Application Firewalls (WAF) und API-Sicherheitslösungen.
  • Interner Netzwerkschutz: Isolation von nicht angefordertem internen Datenverkehr (von anderen Unternehmensnetzwerkadressen). Diese Isolierung kann ähnliche Kontrollen wie der externe Netzwerkschutz verwenden und kann für die Workload oder für einzelne Komponenten und IP-Adressen bestimmt sein.
  • Denial-of-Service-Risikominderungen: Schutz vor verteilten Denial of Service-Angriffen (DDoS) und anderen Denial of Service-Angriffen.
  • Security Service Edge (SSE): Verwendung der clientseitigen Mikrosegmentierung, um sicheren Zugriff direkt auf Ressourcen zu ermöglichen, einschließlich der Anwendung von Zero Trust-Richtlinien.

Stellen Sie sicher, dass bewährte Methoden für alle Entwicklungssysteme und die Infrastruktur befolgt werden, die sie hosten (VMs, Container, Netzwerkgeräte etc.).

Temporäres Minimum: Wenden Sie standardmäßige Enterprise-Konfigurationen auf Workloads an.

Standard: Stellen Sie sicher, dass alle Systeme über externen Netzwerkschutz, DDoS-Schutz und einen minimalen internen Netzwerkschutz pro Workload verfügen.

Hohe Sicherheit: Alle standardmäßigen Schutzfunktionen sowie hoch granularer interner Netzwerkschutz, erzwungenes Tunneln des ausgehenden Serververkehrs über externe Netzwerkschutzmechanismen und ein Workload-spezifisches Gefahrenmodell für die Netzwerkinfrastruktur, das jede Workload mit hoher Sicherheit unterstützt.

Weitere Details und Ressourcen beinhalten:

Überwachung, Antwort und Erholung

Diese Kontrolle unterstützt Continuous SDL Übung 9 „Implementieren der Sicherheitsüberwachung und -antwort“.

Stellen Sie sicher, dass die Teams für Sicherheitsvorgänge (SecOps/SOC) über Sichtbarkeit, Bedrohungserkennung und Reaktionsverfahren für Workloads (APIs und Anwendungen) und die Infrastruktur, die sie hosten, verfügen. Stellen Sie sicher, dass teamübergreifende Prozesse und Tools zwischen SecOps- und Infrastruktur/Workload-Teams eine schnelle Erholung nach einem Angriff ermöglichen.

Diese Kontrolle trägt zur Sicherheit der Workload bei, sobald sie in der Produktion ist und aktiv in Ihrer Organisation eingesetzt wird. Dieser Prozess sollte in Ihre vorhandene Funktion zur Sicherheitsoperation integriert werden, die Sicherheitsvorfälle erkennt und darauf reagiert.

Die Sicherheitsüberwachung für angepasste Workloads kombiniert erweiterte Lösungen zur Erkennung und Reaktion (Extended Detection and Response, XDR) für allgemeine Komponenten, indem Protokolle und andere Anwendungsdaten analysiert werden, um potenzielle Sicherheitsbedrohungen zu erkennen und zu untersuchen. Angepasste Anwendungsdaten umfassen häufig: Informationen zu Benutzeranforderungen, Anwendungsaktivität, Fehlercodes, Netzwerkdatenverkehr, andere relevante Details aus der Anwendung, Datenbanken, Netzwerkendpunkte und andere Systemkomponenten.

Diese Daten werden dann mit Erkenntnissen aus der Echtzeit-Bedrohungsintelligenz angereichert, um Muster anomalen Verhaltens zu erkennen, die auf potenzielle Versuche hinweisen, das Netzwerk zu infiltrieren. Nach dem Aggregieren, Korrelieren und Normalisieren bietet die XDR- und SIEM-Plattform (Security Information and Event Management) Abhilfemaßnahmen.

Temporäres Minimum: Bereitstellen von XDR-Funktionen in Ihrer Umgebung, um den Datenverkehr Ihrer Endbenutzergeräte zu überwachen.

Standard: Bereitstellen von XDR- und angepassten SIEM-Erkennungen, die anomales Verhalten relativ zur Gesamtumgebung identifizieren. Dieses Profil kann angepasste Erkennungen für einzelne Workloads umfassen.

Hohe Sicherheit; Standardmäßige Kontrollen sowie angepasste Erkennungen pro Workload basierend auf Erkenntnissen aus der Gefahrenmodellierung der Workload. Kombinieren Sie dieses Profil mit KI, um kontextsensitive Korrekturempfehlungen bereitzustellen.

Nächste Schritte

Übernehmen Sie diese Sicherheitskontrollen, und passen Sie sie an die Risikotoleranz und Produktivitätsanforderungen Ihrer Organisation an. Verwenden Sie einen Ansatz zur kontinuierlichen Verbesserung, bei dem eine ständige Annäherung an den Idealzustand angestrebt wird.

Beginnen Sie mit der Priorisierung von Kontrollen und den minimalen idealen Zielebenen. Stellen Sie sicher, dass Sie in erster Linie positive Auswirkungen auf die Sicherheit und Änderungen mit wenig Reibungsverlusten vornehmen. Priorisieren, implementieren und integrieren Sie die erste Kontrolle und wiederholen Sie dann den Prozess mit der nächsten Kontrolle.

Sie sollten die kritischen Grundlagen zuerst priorisieren, da sie aufgrund ihrer allgemeinen positiven Auswirkungen und des Scannens von Anmeldedaten und Geheimnissen aufgrund ihrer hohen Auswirkungen und der häufigen Nutzung durch Angreifer große Auswirkungen haben.