Cloud and Response (CDR): Ein Leitfaden für Sicherheitsarchitekten

Cloud and Response (CDR) ist der Bereich der Laufzeitüberwachung, der aktive Bedrohungen in cloud aufspürt und stoppt – jene Ebene zwischen Sicherheitsstatusverwaltung und Incident Response, auf der sich die meisten modernen Sicherheitsverletzungen tatsächlich ereignen. Es ist zudem ein Bereich, über den Analysten und Anbieter nach wie vor kontrovers diskutieren. Eine Forrester-Analyse vom Mai 2024 bezeichnete CDR als eine Funktion, nicht als einen Markt. Zwei Jahre später bewertete Forresters „Wave for Cloud Application Protection Solutions“ für das erste Quartal 2026 14 Anbieter mit wesentlicher CDR-Abdeckung. Wie auch immer man es nennen mag: Diese Fähigkeit ist heute von zentraler Bedeutung dafür, wie regulierte Unternehmen Identitätsmissbrauch, Angriffe auf die Steuerungsebene und Kompromittierungen kurzlebiger Workloads erkennen – also genau jene Sicherheitsverletzungen, für deren Erkennung herkömmliche endpoint and Response- und SIEM-Tools nie konzipiert wurden.

Dieser Leitfaden erläutert, was CDR ist, wie es funktioniert, wie es sich von EDR, NDR, XDR, CSPM, CWPP, CNAPP und SIEM unterscheidet und inwiefern es den Anforderungen von NIS2, NIST SP 800-61 Revision 3 und der britischen DSGVO entspricht. Wir verwenden reale cloud – Capital One, Snowflake, UNC6426, die Europäische Kommission –, um zu zeigen, wie CDR-Signale in der Praxis aussehen, nicht im Marketing.

Was versteht man unter cloud und -Reaktion?

Cloud and Response (CDR) ist ein Verfahren zur kontinuierlichen Überwachung, das aktive Bedrohungen in den Bereichen cloud , Daten und Verwaltung erkennt, untersucht und darauf reagiert. Es erfasst cloud Telemetriedaten – CloudTrail, Azure Activity Logs, GCP Audit Logs, Laufzeitprozessereignisse – und nutzt Verhaltensanalysen, um Angriffe aufzudecken, die herkömmliche EDR-, SIEM- und Sicherheitsüberwachungstools übersehen.

Cloud einen neuen Ansatz, da die Annahmen, auf denen endpoint basiert, nicht mehr zutreffen. Laut dem „2025 Cloud Security and Usage Report“ von Sysdig haben 60 % der Container eine Lebensdauer von weniger als einer Minute – oft gibt es keinen dauerhaften Host, auf dem ein Agent installiert werden könnte, und forensische Beweise verschwinden schneller, als sie von Log-Aggregatoren im Batch-Modus gesichert werden können. Identität hat das Netzwerk als dominierenden Erstzugriffsvektor abgelöst: Rund 83 % der cloud im Jahr 2026 beginnen mit einer Kompromittierung der Identität, und Branchenstudien zu Bedrohungsinformationen berichten für 2026 von einem Anstieg der cloud Angriffe um 266 % gegenüber dem Vorjahr. Das finanzielle Bild entspricht dem operativen: Data Breach „Cost of a Data Breach des Ponemon Institute hat durchweg gezeigt, dasscloud etwa 1 Mio. USD teurer sind als Vorfälle vor Ort – ein Durchschnitt von fast 5,05 Mio. USD in den jüngsten Ausgaben.

Die Überwachung Cloud – also die allgemeine Praxis, cloud auf Risiken und Richtlinienverstöße zu überwachen – überschneidet sich mit CDR, ist aber nicht dasselbe. Die Überwachung beschreibt die Funktion der Telemetrieerfassung; CDR ist der Bereich der aktiven Erkennung und Reaktion, der auf dieser Telemetrie aufbaut. Verwandte Begriffe, die Sie in Materialien von Anbietern und Analysten finden, sind cloud Detection and Response (CNDR) und cloud Detection and Response (CTDR). Sie bedeuten im Wesentlichen dasselbe.

Die Kategorie selbst ist umstritten. Im Mai 2024 vertrat Forrester noch die Auffassung, dasscloud als eigenständiger Markt nicht existierten. Zwei Jahre später bewertet Forresters „Wave for Cloud Application Protection Solutions“ für das erste Quartal 2026 14 Anbieter mit wesentlichen CDR-Fähigkeiten – eine deutliche Verschiebung in der Einordnung. Auf den Anbieter-Pillars von Wiz, Sysdig und Tenable wird CDR als aufstrebender Bereich innerhalb der cloud beschrieben. Wir betrachten die zugrunde liegende Fähigkeit – die Erkennung von Bedrohungen zur Laufzeit über die drei cloud hinweg – als real und notwendig, unabhängig davon, wie die Kaufgrenzen gezogen werden.

Woher der Begriff „CDR“ stammt

CDR entwickelte sich zwischen etwa 2022 und 2024 zu einer von Anbietern geprägten Kategorie, da die Zahl der Sicherheitsverletzungen cloud das Maß überstieg, das mit Positionsmanagement-Tools (CSPM) und Tools zur Absicherung von Workloads (CWPP) allein bewältigt werden konnte. Gartner ordnet CDR der Familie cloud Application Protection Platforms (CNAPP) zu – eine Einordnung, die weitgehend mit der Art und Weise übereinstimmt, wie die meisten Unternehmenskunden cloud derzeit strukturieren.

So funktioniert cloud und Reaktion cloud

Die anschaulichste Analogie stammt von Sysdig: Stellen Sie sich CDR als eine ständig aktive Überwachungskamera für die cloud vor. Endpoint zeigen Ihnen, was auf einem einzelnen Rechner passiert ist. Posture-Tools zeigen Ihnen, wie Ihre Konfiguration zu einem bestimmten Zeitpunkt aussah. CDR zeigt Ihnen, was gerade in jeder Ebene, bei jedem Anbieter und bei jeder Workload geschieht – und fügt diese Signale zu einer einzigen Angriffsgeschichte zusammen. Operativ umfasst dieser Ansatz sechs Schritte:

1. Erfassen Sie cloud Telemetriedaten aus allen Bereichen und von allen Anbietern (AWS, Azure, GCP, Kubernetes, SaaS).
2. Protokolle verschiedener Anbieter vereinheitlichen – CloudTrail, Aktivitätsprotokolle und Audit-Protokolle verwenden unterschiedliche Schemata.
3. Analyse mittels Verhaltensanalytik – Erfassung des Normalverhaltens von Identitäten und Ressourcen, anschließend Kennzeichnung von Anomalien.
4. Erweitern Sie Erkennungsergebnisse um Identitätskontext, Bedrohungsinformationen und Metadaten zu Systemressourcen.
5. Führen Sie die entsprechenden Signale zu einer einheitlichen Angriffsszenerie zusammen, die auf die Cyber-Kill-Chain abgestimmt ist.
6. Reagieren – Automatisieren Sie die Eindämmung bei Maßnahmen mit geringem Risiko; verlangen Sie bei Maßnahmen mit hohem Risiko eine Genehmigung durch einen Menschen (Sitzung beenden, Workload isolieren, IAM-Prinzipal sperren).

Im dritten und vierten Schritt zeigt CDR, was es kann. Eine rein auf Signaturen basierende Erkennung kann mit der Geschwindigkeit cloud nicht Schritt halten, und allein das ungefilterte Alarmvolumen von CloudTrail ist unüberschaubar. Verhaltensbasierte Referenzwerte – was macht dieses Objekt normalerweise? Mit wem kommuniziert diese Workload normalerweise? – verwandeln dieses Volumen in zusammengeführte, hochpräzise Signale für die Incident-Response.

Agentenbasiert versus agentenlos: Bereitstellungsmodelle

Die Debatte um agentenbasierte versus agentenlose Lösungen ist zwar real, wird jedoch zunehmend zu einer falschen Entweder-oder-Frage. Agentenloses CDR – auf Snapshots basierend und API-gesteuert – bietet umfassende Abdeckung und schnelle Bereitstellung ohne jegliche Arbeitslast. Es eignet sich hervorragend für die Transparenz in der Steuerungs- und Verwaltungsebene, die Abdeckung mehrerer Konten sowie für ein zügiges Onboarding. Agentenbasiertes CDR (typischerweise eBPF oder Sidecar) bietet Tiefe in der Laufzeit: Ereignisse auf Prozessebene, Syscall-Traces, Netzwerkaufrufe innerhalb von Containern und jene Art von Datenebenen-Forensik, die bei kurzlebigen Workloads sonst gelöscht würde. Die meisten modernen Programme kombinieren beides – agentenlos für die Breite, agentenbasiert für die Tiefe bei kritischen Workloads und Kubernetes-Sicherheitsclustern, wo Laufzeit-Forensik entscheidend ist.

Die Rolle von KI und Verhaltensanalytik

Verhaltensbasierte Erkennung ist mittlerweile Mainstream und kein Zukunftstraum mehr. Laut dem Bericht von Sysdig für 2026 nutzen mehr als 70 % der Teams verhaltensbasierte Erkennung, die 91 % der Umgebungen abdeckt. Die automatische Beendigung verdächtiger Prozesse stieg im Jahresvergleich um rund 140 %. Nur etwa 2,8 % der verwalteten cloud sind menschliche Benutzer – der Rest sind Dienstprinzipale, Maschinenidentitäten und kurzlebige Workload-Token, was genau der Grund dafür ist, dass die Anreicherung des Identitätskontexts unverzichtbar ist. Die Einführung von KI-spezifischen Paketen stieg im Jahresvergleich um das 25-Fache und vergrößerte damit die Angriffsfläche in der Lieferkette, die CDR überwachen muss.

Die Antwort der Verteidiger lautet „Parität bei der Reaktionsgeschwindigkeit“. Dark Reading hat den 5/5/5-Maßstab – 5 Sekunden für die Erkennung, 5 Minuten für die Triage, 5 Minuten für die Reaktion – als operatives Ziel für Szenarien cloud Angreifern etabliert, bei denen die Ausbruchszeit in Minuten und nicht in Stunden gemessen wird.

Die dreistufige Architektur: Steuerung, Daten und Verwaltung

Die meisten Unklarheiten bezüglich CDR lösen sich in dem Moment auf, in dem man die cloud in ihre drei Ebenen unterteilt. Dies ist das architektonische Grundgerüst, das jeder Sicherheitsarchitekt innerhalb von 30 Sekunden auf einem Whiteboard skizzieren können sollte.

• Steuerungsebene — die API und die Verwaltungsoberfläche, über die Konfiguration, Orchestrierung und IAM-Ereignisse abgewickelt werden. Telemetrie: AWS CloudTrail, Azure-Aktivitätsprotokolle, GCP-Auditprotokolle. Erkennung: anomale Übernahme von IAM-Rollen, Missbrauch von OIDC-Vertrauensrichtlinien, unerwartete Erstellung von CloudFormation-Stacks mit CAPABILITY_NAMED_IAM Änderungen außerhalb der festgelegten Zeitfenster, ungewöhnliche Änderungen an S3-Richtlinien.
• Datenebene – die Laufzeitebene, auf der Workloads (Container, VMs, serverlose Funktionen) tatsächlich ausgeführt werden. Telemetrie: Prozessereignisse, Systemaufrufe, Container-Laufzeit, Netzwerkflüsse, aus eBPF abgeleitete Signale. Erkennungen: Anomalien bei der Prozesserstellung, Versuche, den Container zu verlassen, unerwartete ausgehende Aufrufe, Ausführung von Cryptominern.
• Verwaltungsebene – Identität, Abrechnung, Governance und Verbundschnittstelle (Administratoraktionen, Ereignisse im Zusammenhang mit Verbundidentitäten, Verhalten von Dienstprinzipalen, Abrechnungsanomalien). Erkennung: Ketten von Berechtigungserweiterungen, anomales Verhalten von Dienstprinzipalen, Missbrauch von Verbundtokens, ungewöhnliche Aktivitäten beim Annehmen von Rollen über Konten hinweg.

Ein hilfreiches Bild: Die Steuerungsebene ist die Schaltzentrale cloud, die Datenebene ist die Werkstatt, in der die eigentliche Arbeit stattfindet, und die Verwaltungsebene ist das Front Office, wo Entscheidungen zu Identität und Governance getroffen werden. Angreifer müssen mindestens zwei Ebenen durchqueren, um nennenswerten Schaden anzurichten. Verteidiger benötigen Einblick in alle drei Ebenen, um sie abzufangen.

Zuordnung von Telemetriequellen zu Flugzeugen

Die folgende Tabelle ordnet jede Ebene ihren typischen Telemetriequellen, einem Beispiel für eine Erkennung und dem MITRE ATT&CK Technik, die dabei zum Vorschein kommt. Diese Zuordnung macht den Unterschied zwischen Alarmrauschen und einem verwertbaren Erkennungs-Backlog aus.

Tabelle 1: Zuordnung von cloud quellen zu den drei CDR-Erkennungs-Ebenen.

Die Zahlen für 2026 verdeutlichen, warum diese Karte gerade jetzt von Bedeutung ist. Laut dem Bericht „Threat Horizons H1 2026“ Cloud Google Cloud hat sich die Zeit bis zum Ausbruch Cloud auf etwa 29 Minuten verkürzt. Der UNC6426-Cluster, auf den wir in den Fallstudien noch zurückkommen werden, erlangte innerhalb von weniger als 72 Stunden vollständigen administrativen Zugriff auf AWS über ein einziges kompromittiertes npm-Paket – die gesamte Angriffskette durchlief alle drei Ebenen (Erstellung des Control-Plane-Stacks, Missbrauch des OIDC-Vertrauens in der Management-Plane, S3-Enumeration in der Data-Plane). Weitere Informationen speziell zur Angriffsfläche der Control-Plane finden Sie unter Schutzcloud .

CDR im Vergleich zu EDR, NDR, XDR, CSPM, CWPP, CNAPP und SIEM

Die häufigste Frage bei der Bewertung von CDR-Lösungen lautet: „Was ersetzt diese Lösung?“ Die ehrliche Antwort: nichts. Der besondere Anwendungsbereich von CDR ist die Erkennung von Bedrohungen zur Laufzeit über alle drei cloud hinweg – ein Bereich, den endpoint, Netzwerk-, Sicherheitsstatus- und Workload-Tools jeweils nur teilweise abdecken. Die Kategorien ergänzen sich, und die meisten modernen Programme setzen mehrere davon gemeinsam ein.

• CDR vs. EDR – Endpoint and Response (EDR) erfasst verwaltete Endgeräte und Server. CDR erfasst die cloud und kurzlebige Workloads, wo kein persistenter endpoint eingesetzt werden kann. EDR ist unverzichtbar für Laptop- und Serverflotten; CDR ist unverzichtbar für AWS, Azure, GCP und Kubernetes-Laufzeitumgebungen.
• CDR vs. NDR – Network Detection and Response erfasst den Ost-West- und Nord-Süd-Netzwerkverkehr. CDR erfasst cloud API- und Identitätsereignisse. Sie ergänzen sich in Hybrid cloud , in denen sowohl das lokale Netzwerk als auch cloud eine wichtige Rolle spielen.
• CDR vs. XDR – XDR ist eine Korrelationsschicht, die zahlreiche Quellen miteinander verknüpft. CDR ist eine domänenspezifische Erkennungsschicht, die hochpräzise Signale erzeugt, die von XDR verarbeitet werden können. Unter „EDR vs. XDR“ erfahren Sie, wie sich das umfassendere Korrelationsmodell aus endpoint entwickelt hat.
• CDR vs. CSPM – Cloud Posture Management deckt Fehlkonfigurationen im Ruhezustand auf. CDR erkennt aktive Angriffe in Echtzeit. CSPM zeigt Ihnen, dass die Tür unverschlossen war; CDR zeigt Ihnen, dass jemand durch sie hindurchgegangen ist. Sie ergänzen sich, stehen nicht in Konkurrenz zueinander.
• CDR vs. CWPP – Cloud Protection Platforms (CWPP) sichern einzelne Workloads ab (Schwachstellenscans, Durchsetzung von Konfigurationen, Laufzeitschutz). CDR erkennt aktive Bedrohungen über die gesamte cloud hinweg, einschließlich der Steuerungs- und Verwaltungsebenen, die CWPP nicht erfasst. Oft werden beide Lösungen gemeinsam im Rahmen von CNAPP bereitgestellt.
• CDR vs. CNAPP – CNAPP ist eine Plattformfamilie, die CSPM, CWPP, CDR und weitere Komponenten umfasst. CDR ist der Teil von CNAPP, der sich mit der Erkennung und Reaktion während der Laufzeit befasst – es handelt sich also nicht um eine konkurrierende Kategorie.
• CDR vs. SIEM – SIEM aggregiert und korreliert Protokolle unternehmensweit. CDR ist speziell auf die Semantik cloud zugeschnitten – IAM-Beziehungen, kurzlebige Identifikatoren, Grafiken mit mehreren Konten. Die meisten modernen Programme speisen CDR-Signale in SIEM-Optimierungsworkflows ein, anstatt sich zwischen den beiden zu entscheiden. Die neutrale Analyse von TechTarget zu CDR im Vergleich zu EDR, NDR und XDR kommt zu demselben Ergebnis.

Tabelle 2: Vergleich des Anwendungsbereichs von CDR mit benachbarten Kategorien im Bereich Erkennung und Reaktion.

Ist CDR eine eigenständige Kategorie oder lediglich eine Reihe von Funktionen?

Dies verdient eine klare Antwort. Forrester vertrat im Mai 2024 die Auffassung, dass CDR kein eigenständiger Markt sei – dass diese Funktion in CNAPP-, SIEM- und verwandten Plattformen integriert sei und keine separate Kaufkategorie rechtfertige. Dieses Argument war 2024 stichhaltig, hat aber seitdem an Gewicht verloren. In Forrester’s „Wave for Cloud Application Protection Solutions“ für das erste Quartal 2026 wurden 14 Anbieter mit wesentlicher CDR-Abdeckung bewertet, was eine strikte Interpretation nach dem Motto „Feature, nicht Kategorie“ erschwert. Die Konsolidierung der Hyperscaler verstärkt diesen Trend: Google schloss am 11. März 2026 die Übernahme von Wiz im Wert von 32 Milliarden US-Dollar ab, wie TechCrunch über den Abschluss berichtete, und integrierte damit wesentliche CDR-Funktionen in das Portfolio eines Hyperscalers.

Unsere Einschätzung: Die zugrunde liegende Funktion ist real, notwendig und wird von EDR, NDR, CSPM, CWPP oder SIEM allein nicht ausreichend abgedeckt. Ob Sie sie als eigenständiges Produkt oder als Bestandteil von CNAPP erwerben, hängt von der Zusammensetzung Ihres Sicherheitsstacks ab. Bei Neuprojekten wird sie in der Regel in CNAPP integriert. Ausgereifte Programme mit umfangreichen bestehenden Investitionen in SIEM und EDR setzen CDR häufig als eigenständige Ebene ein, die den Rest des Stacks mit Daten versorgt.

Cloud und -Reaktion in der Praxis

Abstrakte Kategorieargumente lassen sich durch konkrete Angriffe leichter widerlegen. Die folgenden vier Sicherheitsverletzungen veranschaulichen, wie CDR-Signale auf den drei Ebenen aussehen und welche Kosten den betroffenen Organisationen durch deren Fehlen entstanden sind.

Fall 1 – Capital One (Juli 2019, rückblickend). Eine fehlerhaft konfigurierte AWS WAF in Verbindung mit Server-Side Request Forgery (SSRF) ermöglichte es einem Angreifer, eine IAM-Rolle für EC2-Instanz-Metadaten zu missbrauchen, um rund 106 Millionen Datensätze von Kreditkartenantragstellern aus den USA und Kanada aus S3 aufzulisten und zu exfiltrieren. Der Angriff dauerte mehrere Monate, bevor er entdeckt wurde. CDR-Signal: Anomales Verhalten in der Daten- und Steuerungsebene – ein einzelner IAM-Prinzipal, der ungewöhnlich hohe S3-Lesevolumina abrief, stammend von einer EC2-Instanz, deren normales Verhalten niemals eine Massen-S3-Auflistung beinhaltete. Dies ist genau das plattformübergreifende Signal, das die Verhaltensanalyse auf CloudTrail in Verbindung mit der AWS-Bedrohungserkennung aufdecken soll.

Fall 2 – Snowflake (2024). Die Wiederverwendung von Anmeldedaten (die teilweise auf Logs von Infostealern aus dem Jahr 2020 zurückgeführt werden konnten) sowie die fehlende Durchsetzung der MFA auf Kundenseite führten dazu, dass rund 165 Kundenunternehmen betroffen waren. Die Retrospektive derCloud zu Snowflake aus dem Jahr 2024 ist die maßgebliche öffentliche Analyse. CDR-Signal: Anmeldungen aus ungewöhnlichen geografischen Regionen, erhöhtes Abfragevolumen und das Fehlen von MFA auf SaaS-Authentifizierungsoberflächen mit hohen Berechtigungen – alles über Identitäts-Telemetrie auf Management-Ebene erkennbar. Die Lehre daraus ist, dass die Folgen von Anmeldedaten-Diebstahl ein CDR-Problem auf SaaS-Ebene sind und nicht nur endpoint .

Fall 3 – UNC6426 (1. Quartal 2026). Dies ist der eindeutigste Fall aus der Praxis, der öffentlich bekannt ist. Ein kompromittiertes npm-Paket (QUIETVAULT) – ein Lehrbuchbeispiel Angriff auf die Lieferkette — stahl GitHub-Tokens. Eine zu weit gefasste OIDC-Vertrauensrichtlinie zwischen GitHub und AWS ermöglichte es diesen Tokens, eine AWS-IAM-Rolle zu übernehmen. Mit CloudFormation wurde ein IAM-Stack erstellt, der CAPABILITY_NAMED_IAM, wodurch der Angreifer innerhalb von weniger als 72 Stunden Administratorrechte bei AWS erlangte. Anschließend führte der Angreifer eine Bestandsaufnahme der S3-Ressourcen durch, beendete EC2- und RDS-Instanzen und entschlüsselte Anwendungsschlüssel. Die Angriffskette ist dokumentiert in Die Berichterstattung von The Hacker News über den UNC6426-Angriff auf die npm-Lieferkette, der Informationsveranstaltung der Cloud Alliance zum Missbrauch der OIDC-Vertrauensketteund Der Bericht „Threat Horizons H1 2026“ Cloud Google Cloud. CDR-Signal: Ausgabe von STS-Token durch einen nicht zu CI gehörenden Auftraggeber in Verbindung mit CloudFormation CAPABILITY_NAMED_IAM Erstellung von Stacks außerhalb des Änderungsfensters – ein zusammengefügter Ablauf zwischen Steuerungs- und Verwaltungsebene, der von keiner einzelnen Tool-Kategorie allein abgedeckt wird.

Fall 4 – Europäische Kommission Europa.eu (März 2026). Durch eine Kompromittierung der Lieferkette von Trivy entstand ein fünf Tage andauerndes „Dwell-Fenster“, in dem etwa 91,7 GB aus der von der EU gehosteten AWS-Infrastruktur abgezogen wurden. Der Blogbeitrag von CERT-EU zum cloud bei der Europäischen Kommission, die Berichterstattung von BleepingComputer sowie die Berichterstattung von Help Net Security dokumentieren den zeitlichen Ablauf. CDR-Signal: Anomalien in der Control-Plane-API über einen Zeitraum von fünf Tagen – ein Muster, das reine Posture-Tools nicht erkennen können und das bei der SIEM-Korrelation im Batch-Modus ohne cloud Kontext typischerweise übersehen wird.

Tabelle 3: Zeitlicher Ablauf der Vorfälle und CDR-Signale bei cloud jüngsten cloud .

Forensische Untersuchung kurzlebiger Workloads

Flüchtige Workloads widerlegen die Annahmen der traditionellen digitalen Forensik. Da 60 % der Container weniger als eine Minute bestehen, ist eine nachträgliche Beweissicherung oft unmöglich. Die operative Lösung besteht in der Erfassung in Echtzeit und der unveränderlichen Sicherung:

1. Erfassen Sie Prozessereignisse und Netzwerktelemetriedaten in Echtzeit mit eBPF-basierten Agenten für kritische Workloads – dies ist die einzige zuverlässige Methode, um Beweismaterial auf Systemaufrufebene zu sichern, bevor ein Container beendet wird.
2. Verlängern Sie die Aufbewahrungsfrist für Audit-Protokolle cloud über die übliche Standardeinstellung von 30 bis 90 Tagen hinaus, insbesondere für Ereignisse in der Steuerungsebene und im Bereich der Identitäts- und Zugriffsverwaltung (IAM). Angriffe mit langer Verweildauer, wie beispielsweise der Hackerangriff auf die EU-Kommission, können die Standardaufbewahrungsfrist überschreiten.
3. Sichern Sie cloud zum Zeitpunkt der Erkennung – EBS-Snapshots, Azure Managed Disk-Snapshots, GCP Persistent Disk-Snapshots – und kennzeichnen Sie diese als forensische Artefakte, um eine automatische Löschung zu verhindern.
4. Die forensische Beweiskette ist mithilfe cloud Speicherprimitive cloud(S3 Object Lock im Compliance-Modus, Azure Immutable Blob Storage) zu gewährleisten. Die einmalige Speicherung bildet die Grundlage für zulässige cloud .

Erkennung und Abwehr von cloud

Die folgenden sieben Verteidigungsmaßnahmen wurden aus herstellerübergreifenden Leitlinien zusammengestellt und, soweit zutreffend, mit bestimmten MITRE ATT&CK verknüpft. Betrachten Sie sie als Verteidigungsmaßnahmen und nicht als Checklisten der Hersteller.

1. Decken Sie alle Umgebungen ab – öffentliche, private,cloud und SaaS-Umgebungen. Die Überwachung durch einen einzigen Anbieter ist die häufigste Ursache für Silos und die häufigste Lücke bei der Erkennung.
2. Kontinuierliche Echtzeitüberwachung – Erfassung von CloudTrail, Aktivitätsprotokollen und Audit-Protokollen zur Laufzeit. Eine Protokollaggregation im Batch-Modus erfüllt weder den 5/5/5-Benchmark noch die 24-Stunden-Fristen gemäß NIS2.
3. Verhaltensanalyse statt reiner Signaturerkennung – Verknüpfung ressourcenübergreifender Ereignisse zu einheitlichen Abläufen. Die 70 % der Teams, die mittlerweile verhaltensbasierte Erkennung einsetzen und damit 91 % der Umgebungen abdecken, tun dies, weil regelbasierte Erkennung mit der Geschwindigkeit cloud nicht Schritt halten kann.
4. Der Identitätskontext ist obligatorisch — Laufzeitereignisse mit Identitätsaktionen in Beziehung setzen (T1078.004, T1552). Die Zahl von 83 % bei den Identitätsdiebstählen ist der eigentliche Grund Erkennung und Reaktion auf Identitätsbedrohungen und Erkennung und Eindämmung identitätsbasierter Angriffe befinden sich nun neben dem CDR.
5. Automatisierte Reaktion mit menschlichen Kontrollmechanismen – Sitzungen automatisch beenden; für die Sperrung von IAM-Rollen bei Produktionskonten eine menschliche Genehmigung einholen. Automatisierung ohne Kontrollmechanismen führt zu Ausfällen.
6. Integration mit SIEM und SOAR – CDR ergänzt bestehende Plattformen, anstatt sie zu ersetzen. Leiten Sie detaillierte, zusammengeführte Erkennungsergebnisse an den SOC-Betrieb weiter, statt bloße Alarmmengen.
7. Planen Sie für die Kurzlebigkeit – sichern Sie forensische Beweise in Echtzeit und nicht erst im Nachhinein. Gehen Sie davon aus, dass die Datenmenge bereits verschwunden ist, bevor Sie die Triage abgeschlossen haben.

Tabelle 4: Sieben Abwehrmaßnahmen, die cloud und Reaktion cloud operativ effektiv machen.

Eine ausführlichere Darstellung der zugrunde liegenden Erkennungsmethodik finden Sie unter „Threat Detection “ und in der MITRE ATT&CK Cloud . Als ergänzende Rahmenbedingungen für Anwendungsfälle bietet die CDR-Anwendungsfallanalyse von TechTarget eine nützliche, neutrale Referenz. Zu den Branchen-Frameworks, an denen sich eine Ausrichtung lohnen kann, gehören die „OWASP Cloud Application Security Top 10“ und der „ENISA Cloud Guide“.

Cloud und -Reaktion sowie Compliance

CDR ist heute ebenso sehr eine Funktion zur Einhaltung gesetzlicher Vorschriften wie eine Sicherheitsfunktion. Die in den aktuellen Vorschriften der EU und des Vereinigten Königreichs festgelegten Fristen von 24 und 72 Stunden lassen sich durch die Überprüfung von Protokollen im Batch-Modus und manuelle Triage nicht einhalten.

• NIST SP 800-61 Revision 3 (April 2025) – die erste Aktualisierung des Leitfadens der US-Regierung zum Umgang mit Sicherheitsvorfällen seit 2012. Er befasst sich ausdrücklich mit cloud und Einschränkungen bei der Protokollaufbewahrung und ordnet die Reaktion auf Sicherheitsvorfälle den Funktionen „Erkennen“, „Reagieren“ und „Wiederherstellen“ des NIST CSF 2.0 zu. Der vollständige Text ist beim NIST erhältlich. Er ergänzt NIST SP 800-207 Zero Trust – siehe zero trust für den breiteren architektonischen Kontext — als grundlegende Bundesrichtlinie für cloud .
• NIS2 (EU) – Artikel 23 zur Meldung von Vorfällen schreibt eine Frühwarnung innerhalb von 24 Stunden sowie eine Meldung des Vorfalls mit einer ersten Bewertung innerhalb von 72 Stunden vor. Die Höchststrafen betragen für kritische Einrichtungen 10 Millionen Euro oder 2 % des weltweiten Umsatzes. Die Seite der Europäischen Kommission zur NIS2-Richtlinie ist die primäre Informationsquelle. Die Erkennung von CDR in Echtzeit ist entscheidend dafür, dass die 24-Stunden-Frist operativ eingehalten werden kann.
• Britische DSGVO – Artikel 33 schreibt eine Meldung von Datenschutzverletzungen an die ICO innerhalb von 72 Stunden vor. Die gleiche operative Anforderung gilt: Eine Erkennung, die betroffene Vorfälle schnell genug identifiziert, um die Frist zuverlässig in Gang zu setzen. Weitere Informationen zum allgemeinen regulatorischen Kontext finden Sie in den Leitlinien der britischen ICO zu NIS und Datenschutzverletzungen im Rahmen der britischen DSGVO sowie zur Einhaltung der DSGVO.
• Gesetzentwurf zur Cybersicherheit und Widerstandsfähigkeit im Vereinigten Königreich – befindet sich zum Zeitpunkt der Erstellung dieses Artikels in der Ausarbeitungsphase; Inkrafttreten voraussichtlich Mitte bis Ende 2026. Er sieht zusätzliche Melde- und Widerstandsfähigkeitspflichten für britische Unternehmen vor, die systemrelevante und digitale Dienste erbringen.
• MITRE ATT&CK Cloud – der Anker für den nachweisbaren Wirksamkeitsnachweis bei Audit-Gesprächen. Durch die Zuordnung von CDR-Erkennungen zu ATT&CK-Techniken können Compliance-Teams die Abdeckung konkret nachweisen.
• CISA-Referenzarchitektur für Cloud – relevant für den US-Bundesbereich und für Kontexte im Umfeld von Cloud-Service-Anbietern (CSP); die CISA-SCuBA-Projektseite ist der offizielle Einstiegspunkt.

Tabelle 5: Zuordnung der CDR-Funktionen zu den wichtigsten Vorschriften für cloud .

Moderne Ansätze und die Zukunft dieser Kategorie

Drei Faktoren werden den CDR-Markt in den nächsten 12 bis 24 Monaten grundlegend verändern. Erstens entwickelt sich cloud vom Konzept zum Produkt – automatisierte Korrekturmaßnahmen, die Anomalien erkennen und ohne menschliches Eingreifen eindämmen, sind nun bei allen führenden CNAPP-Anbietern in der Forrester Wave für das erste Quartal 2026 zu beobachten. Zweitens hat sich die Konsolidierung der Hyperscaler mit dem Abschluss der 32-Milliarden-Dollar-Übernahme von Wiz durch Google am 11. März 2026 deutlich beschleunigt; unabhängige CDR-Anbieter müssen sich durch Signalqualität und Integrationsneutralität incloud von der Konkurrenz abheben. Drittens nähern sich Verteidiger der Maschinen-Geschwindigkeits-Parität mit KI-gestützten Angreifern an – Sysdigs Bericht für 2026 zeigt, dass verhaltensbasierte Erkennung und automatische Beendigung Standardpraxis sind und kein Unterscheidungsmerkmal mehr darstellen.

Für Sicherheitsteams mit weniger als fünf Vollzeitkräften bedeutet dies, dass eine Form von Managed Detection and Response zunehmend die richtige Lösung für cloud ist cloud das erforderliche Arbeitstempo, um die 5/5/5- und 24-Stunden-NIS2-Vorgaben zu erfüllen, lässt sich bei kleinen Teams intern kaum aufrechterhalten. Der Ausblick für diese Kategorie lautet Konsolidierung: CDR als eigenständige Kaufkategorie wird für Unternehmen mit ausgereiften CNAPP-Stacks bestehen bleiben; für Unternehmen, die bei Null anfangen, wird es in die CNAPP-Plattform integriert werden. In jedem Fall ist die Fähigkeit zur Laufzeit-Erkennung unverzichtbar. Zusammenfassungen zur Branchenpositionierung – einschließlich der Übersicht von Medium zur CDR-Positionierung von Gartner und Referenzen zu Anbieter-Frameworks wie dem CDR-Best-Practices-Framework von Skyhawk – bieten zusätzlichen Kontext.

Wie Vectra AI das Thema cloud und -Reaktion Vectra AI

Der Ansatz Vectra AI für cloud und Reaktion cloud spiegelt eine auf die cloud angewandte „Assume Compromise“-Philosophie wider: kontinuierliche Beobachtbarkeit über alle drei Ebenen hinweg, KI-gesteuerte „Attack Signal Intelligence™“ zur Filterung von Störsignalen und Aufdeckung zusammenhängender Angriffsabläufe sowie fundierte Maßnahmen, die aktive Bedrohungen eindämmen, bevor sich laterale Bewegungen etablieren können. Das Ziel sind nicht mehr Warnmeldungen – sondern das richtige Signal in Echtzeit. Eine unabhängige IDC-Analyse der Vectra AI ergab eine Abdeckung von mehr als 90 % MITRE ATT&CK und einen ROI von 391 % bei einer Amortisationszeit von 6 Monaten. Informationen zur AWS-spezifischen Laufzeitabdeckung finden Sie unter Vectra AI für AWS.

Schlussfolgerung

Cloud und -Reaktion ist die Laufzeitebene, die cloud in zusammenhängende Angriffsszenarien umwandelt – keine weitere Produktkategorie, die mit EDR, NDR oder SIEM konkurriert, sondern die Disziplin, die die drei cloud für den Sicherheitsbetrieb endlich verständlich macht. Der Wandel weg von einer rein auf den Sicherheitsstatus und endpoint Denkweise ist nicht mehr optional. Identität ist der vorherrschende Vektor für den Erstzugang. Workloads sind kurzlebig. Die Ausbruchszeit wird in Minuten gemessen. Regulierungsbehörden schreiben 24-Stunden-Fristen vor. Die Organisationen, die unter diesen Bedingungen bestehen werden, sind diejenigen, die cloud zur Laufzeit als erstklassige Fähigkeit betrachten, ganz gleich, wie sie diese verpacken.

Wenn Sie ein cloud aufbauen oder aktualisieren, beginnen Sie mit dem Drei-Ebenen-Modell, ordnen Sie Ihre vorhandene Telemetrie diesem Modell zu und ermitteln Sie die Ebenen, auf denen Sie über Erkennung verfügen und nicht nur Protokollierung. Kombinieren Sie CDR mit Verhaltensanalysen, binden Sie diese in Ihr bestehendes SIEM sowie in erweiterte Erkennungs- und Reaktions-Workflows ein und richten Sie die Erfassungsreichweite an der MITRE ATT&CK Cloud aus, damit bei Audit-Gesprächen konkrete Nachweise als Grundlage zur Verfügung stehen. Um tiefer in angrenzende Disziplinen einzutauchen, lesen Sie die Abschnitte zu Identitätsbedrohungserkennung und -reaktion, AWS-Bedrohungserkennung und Kubernetes-Sicherheit in den unten aufgeführten verwandten Themen. Für einen methodischen Überblick beschreibt die Vectra AI (Link oben), wie Attack Signal Intelligence™ dasselbe Problem angeht.