CloudDetection.
Cloud Detection erkennt aktive Angriffe in Control Plane, Identitäten, Workloads, Containern und Cloud-Netzen. Die Klasse verarbeitet Laufzeittelemetrie. Fehlkonfigurationen und theoretische Risiken gehören dagegen primär zu CSPM und Exposure Management.
Marktbild: hoch und stark von CNAPP, SIEM und XDR überlagert. Zwölf Plattformen unterscheiden sich vor allem bei Datenquellen, Laufzeittiefe und direkten Reaktionsmöglichkeiten.
Ereignisse statt Momentaufnahme.
Entscheidend sind Cloud-Audit-Logs, Identitätsereignisse, Netzwerkflüsse, Kubernetes-Aktivität und optional eBPF- oder Workload-Sensoren. Eine Posture-Prüfung allein erkennt keinen laufenden Angriff.
Prüfe AWS, Azure und Google Cloud getrennt, Latenz der Erkennung, Control-Plane- und Datenebene, Container, serverlose Dienste, Identitätskontext, Reaktionsaktionen, Datenresidenz und Integration in SIEM oder Case Management.
Wer hat den Schlüssel benutzt?
Cloud Detection and Response (CDR) erkennt Angriffe, die gerade in einer Cloud-Umgebung laufen, und hilft, sie einzudämmen. Die wichtigste Datenquelle ist die Control Plane: Jeder API-Aufruf, mit dem jemand eine Rolle ändert, einen Schlüssel erzeugt oder einen Speicher öffnet, landet in einem Audit-Log, bei AWS etwa in CloudTrail, bei Azure in den Aktivitäts- und Resource-Manager-Protokollen, bei Google in den Cloud Audit Logs. Erkennungsregeln und Verhaltensmodelle bewerten diese Ereignisse, zum Beispiel einen Dienstkontoschlüssel, der plötzlich aus einem fremden Land genutzt wird, oder eine Rollenübernahme, die nicht zum üblichen Muster passt.[1,2,3]
Die zweite Ebene ist die Data Plane, also das, was auf den Workloads selbst geschieht. Hier arbeiten zwei Architekturen nebeneinander. Agentenlose Verfahren lesen Logs, Netzflüsse und Snapshots über die Cloud-APIs und brauchen keine Installation. Laufzeitsensoren laufen als Agent auf VMs oder als DaemonSet im Kubernetes-Cluster und beobachten Systemaufrufe, oft über eBPF im Linux-Kernel. Nur ein Sensor sieht, dass in einem Container plötzlich eine Shell startet oder ein Kryptominer Prozesse nachlädt, und nur ein Sensor kann einen solchen Prozess sofort beenden. Das Open-Source-Projekt Falco ist ein Beispiel für diesen Ansatz: Es wertet Kernel-Ereignisse aus und liest über Plugins zusätzlich Kubernetes-Audit-, CloudTrail- und Okta-Ereignisse.[4,5,6]
Kubernetes hat eine eigene Control Plane. Ihr Audit-Log zeigt, wer Pods mit Root-Rechten startet, RBAC-Rollen ändert oder Zertifikate anfordert. Dazu kommen Identitätssignale aus dem Identity Provider und aus SaaS-Diensten, weil viele Cloud-Angriffe mit gestohlenen Zugangsdaten beginnen.[7,3]
Die Reaktion reicht von der Meldung an SIEM und Ticketsystem über automatische Playbooks bis zu Eingriffen auf dem Workload: Zugangsschlüssel deaktivieren, Identität sperren, Container stoppen, Pod löschen, Netz isolieren. Wie weit ein Werkzeug selbständig eingreift, hängt von Sensor, Berechtigungen und freigegebenen Regeln ab. Vor der Reaktion steht die Korrelation: Gute Werkzeuge fassen zusammengehörige Ereignisse zu einem Fall zusammen, ordnen sie Techniken aus MITRE ATT&CK zu und zeigen, welche Identität, welches Konto und welcher Workload betroffen sind. Ein Cloud-eigener Erkennungsdienst verknüpft zum Beispiel einzelne Ereignisse innerhalb eines Kontos über Ressourcen und Zeit zu einem mehrstufigen Angriff.[1,8,9]
| Datenquelle | Was sie zeigt | Typischer Befund |
|---|---|---|
| Cloud-Audit-Log (Control Plane) | API-Aufrufe auf Konto-, Rollen- und Ressourcenebene | Gestohlener Schlüssel erzeugt neue Zugänge |
| Netzflüsse und DNS | Verbindungen von und zu Workloads | Kontakt zu bekannter Angreifer-Infrastruktur |
| Kubernetes-Audit-Log | Aktionen gegen die Kubernetes-API | Privilegierter Pod, geänderte RBAC-Rolle |
| Laufzeitsensor (eBPF) | Prozesse, Dateien, Systemaufrufe im Workload | Shell im Container, Kryptominer |
| Identitäts- und SaaS-Logs | Anmeldungen, Rechteänderungen beim IdP und in SaaS | Ungewöhnliche Anmeldung vor einer Rollenübernahme |
Typische Probleme
| Problem | Wie man es löst |
|---|---|
| Lücken bei den Logquellen | Nicht alle Quellen sind ab Werk aktiv; bei einem grossen Cloud-Anbieter wird die Laufzeitüberwachung beim Erststart nicht automatisch eingeschaltet. Lösung: Logquellen je Konto, Abonnement und Projekt inventarisieren und die Aktivierung über die Organisationsebene erzwingen.[1] |
| Posture-Befund gilt als Angriff | Eine offene Sicherheitsgruppe ist ein Risiko, kein laufender Angriff. Lösung: Posture- und Bedrohungsbefunde in getrennten Warteschlangen mit eigenen Reaktionszeiten führen. |
| Kurze Aufbewahrung | Befunde und Rohdaten liegen oft nur Wochen bis wenige Monate, bei einem grossen Cloud-Anbieter 90 Tage. Lösung: Export in eine Langzeitablage oder ins SIEM vertraglich und technisch festlegen.[11] |
| Automatik ohne Leitplanken | Ein Playbook, das Produktionsressourcen löscht oder Konten sperrt, kann mehr Schaden anrichten als der Angriff. Lösung: Aktionen nach Umgebung staffeln, für Produktion eine Freigabe verlangen und das Rückgängigmachen testen. |
| Blinde Flecken ohne Sensor | Agentenlose Verfahren sehen Prozesse im Container nicht in Echtzeit. Lösung: Sensoren gezielt auf exponierten und kritischen Workloads einsetzen und die Abdeckung messen.[12] |
| Mehrere Clouds, mehrere Konsolen | Jeder Cloud-Anbieter liefert eigene Erkennung mit eigener Logik. Lösung: Befunde in einem Fallsystem zusammenführen und einheitlich nach MITRE ATT&CK einordnen. |
Auswahlfragen
| Frage | Worauf die Antwort hinweisen sollte |
|---|---|
| Welche Logquellen je Cloud werden tatsächlich ausgewertet? | Die Antwort sollte eine Liste je AWS, Azure und Google Cloud enthalten, inklusive Kubernetes-Audit und Identitätsquellen. |
| Wie lange dauert es vom Ereignis bis zur Warnung? | Erwartet wird eine gemessene Latenz aus dem Pilot, getrennt für Audit-Log- und Sensorerkennung. |
| Welche Reaktionen sind möglich, und wer gibt sie frei? | Hinweis auf konkrete Aktionen mit Rollenmodell, Protokoll und Rückweg. |
| Braucht es einen Sensor, und was kostet er im Betrieb? | Die Antwort sollte Kernel-Kompatibilität, Ressourcenbedarf und Update-Verfahren nennen. |
| Wie gelangen Befunde ins bestehende SOC? | Erwartet werden dokumentierte Exporte an SIEM, SOAR und Ticketsystem. |
| Wo werden die Ereignisdaten gespeichert und wie lange? | Die Antwort muss Region, Aufbewahrung und Exportmöglichkeiten nennen. |
| Wie wird ein Missbrauch eines Cloud-Schlüssels im Pilot erkannt? | Ein simulierter Angriff in einer Testumgebung zeigt Erkennung, Kontext und Reaktionsweg. |
Betrieb und Verantwortung
Das Cloud-Plattformteam aktiviert Logquellen und Sensoren in allen Konten, das SOC bearbeitet die Warnungen und führt die Reaktion. Welche automatischen Eingriffe in Produktion erlaubt sind, entscheidet die Linie gemeinsam mit den Anwendungsverantwortlichen. Sinnvolle Kennzahlen sind Anteil der Konten mit aktiven Logquellen, Sensorabdeckung kritischer Workloads, Zeit bis zur Erkennung und Zeit bis zur Eindämmung.
Regulatorischer Bezug
ISO/IEC 27001:2022 adressiert das Thema in Annex A vor allem über 8.15 «Logging», 8.16 «Monitoring activities» und 5.23 «Information security for use of cloud services». NIS2 verlangt in Art. 21 Abs. 2 Bst. b Massnahmen zur Bewältigung von Sicherheitsvorfällen; DORA fordert in Art. 10 Mechanismen, die anomale Aktivitäten umgehend erkennen. Im IT-Grundschutz sind die Bausteine DER.1 «Detektion von sicherheitsrelevanten Ereignissen», OPS.1.1.5 «Protokollierung» und OPS.2.2 «Cloud-Nutzung» einschlägig.[13,14,15,16,17,18]
Quellen: [1] docs.aws.amazon.com · [2] learn.microsoft.com · [3] cloud.google.com · [4] falco.org · [5] falco.org · [6] elastic.co · [7] learn.microsoft.com · [8] docs.sysdig.com · [9] learn.microsoft.com · [10] docs.sysdig.com · [11] docs.aws.amazon.com · [12] orca.security · [13] isms.online · [14] isms.online · [15] hightable.io · [16] nis-2-directive.com · [17] digital-operational-resilience-act.com · [18] bsi.bund.de · [19] aws.amazon.com
Zwölf Werkzeuge im Vergleich.
Cloud Detection and Response erkennt laufende Angriffe in Cloud-Konten, Identitäten, Workloads und Kubernetes-Clustern; die Produkte unterscheiden sich vor allem in ihren Datenquellen und in der Tiefe der Reaktion. Die Cloud-Anbieter liefern eigene Erkennungsdienste, die ihre Audit-Logs, Netzflüsse und Laufzeitdaten ohne zusätzliche Datenpipeline auswerten; Microsoft bindet auch AWS und Google Cloud an, Google bindet AWS und Azure über die Enterprise-Stufe an, die laut Google am 21.05.2027 eingestellt wird. CNAPP- und XDR-Anbieter verbinden Cloud-Ereignisse mit Endpunkt- und Identitätssignalen in einer Plattform, Laufzeitspezialisten setzen auf eBPF-Sensoren und Regeln im Stil von Falco, SIEM-Plattformen auf Logintegration und eigene Erkennungsregeln. Der Markt konsolidiert: Palo Alto Networks hat Cortex Cloud am 13.02.2025 als nächste Version von Prisma Cloud vorgestellt (Prisma Cloud mit Cortex CDR zusammengeführt), SentinelOne hat PingSafe am 05.02.2024 übernommen, Google hat die Übernahme von Wiz am 11.03.2026 abgeschlossen. Als Open-Source-Projekt ist Falco (CNCF, Apache 2.0) verbreitet, dessen Plugins neben Systemaufrufen auch Kubernetes-Audit-, CloudTrail- und Okta-Ereignisse lesen.
Audit-Logs: Cloud-Audit-Logs · K8s-Audit: Kubernetes-Audit · Sensor: Laufzeitsensor · Identität: Identitätssignale · Auto-Reaktion: automatische Reaktion · Multi-Cloud: AWS, Azure und GCP · SaaS-Quellen: SaaS-Logquellen wie Microsoft 365, Okta oder GitHub. ● = auf offizieller Hersteller- oder Projektseite beschrieben, – = nicht belegt (nicht zwingend nicht vorhanden). Auswahl nicht abschliessend, keine Rangliste. Stand: Oktober 2026.
Amazon GuardDuty
Amazon Web Services
Grundlage sind CloudTrail-Management-Ereignisse, VPC Flow Logs und DNS-Logs; Schutzpläne ergänzen EKS-Audit-Logs, S3-Datenereignisse, RDS-Anmeldungen, Lambda-Netzaktivität, EBS-Malware-Scans und KI-Dienste wie Bedrock.
GuardDuty liest die Datenquellen direkt aus der AWS-Infrastruktur, ohne dass Kunden eine Logpipeline bauen; Extended Threat Detection verknüpft Ereignisse innerhalb eines Kontos über Ressourcen und Zeit zu mehrstufigen Angriffen.
Runtime Monitoring wertet Betriebssystem-Ereignisse auf EKS, EC2 und ECS inklusive Fargate über einen GuardDuty-Sicherheitsagenten aus; Befundtypen wie CredentialAccess:IAMUser/AnomalousBehavior zeigen missbrauchte Anmeldedaten.
Befunde gehen an Amazon EventBridge und lassen sich dort automatisch weiterverarbeiten, etwa über Lambda oder SNS, oder nach S3 exportieren.
GuardDuty bewahrt Befunde 90 Tage auf; längere Aufbewahrung erfolgt über EventBridge oder den S3-Export. Runtime Monitoring wird beim Erststart nicht automatisch aktiviert.
Grunderkennung in jeder AWS-Organisation, ergänzt um Schutzpläne für EKS, S3 und Datenbanken.
Sofort nutzbare Erkennung auf Basis der AWS-eigenen Datenquellen, ohne eigene Log-Infrastruktur.
Deckt nur AWS ab; Azure, Google Cloud und SaaS-Dienste brauchen andere Werkzeuge.
Microsoft Defender for Cloud (Bedrohungsschutz)
Microsoft
Schutzpläne für Server, Container und Azure Resource Manager; Defender for Servers und Defender for Containers schützen Workloads in Azure, AWS, Google Cloud und On-Premises.
Defender for Resource Manager überwacht Verwaltungsoperationen aus Portal, REST-API, CLI und anderen Clients; Defender for Containers erhält Kubernetes-Audit-Logs für die Erkennung auf der Control Plane.
Meldet etwa Operationen von bösartigen IP-Adressen, deaktivierten Malware-Schutz, Ausnutzungswerkzeuge wie MicroBurst und laterale Bewegung von der Verwaltungsebene zur Datenebene; ein Sensor im Cluster liefert Laufzeiterkennung.
Workflow Automation startet Logic Apps bei Warnungen; Warnungen lassen sich nach Microsoft Sentinel oder in andere SIEM exportieren; Integration in das Defender-XDR-Portal.
Bei AKS werden Audit-Logs nativ über die Azure-Infrastruktur gesammelt; AWS- und Google-Cloud-Ressourcen werden an Defender for Cloud angebunden.
Azure-zentrierte Organisationen, die AWS- und Google-Cloud-Workloads im selben Portal überwachen wollen.
Tiefe Integration in Azure und das Microsoft-Sicherheitsportal, dazu angebundene AWS- und Google-Cloud-Ressourcen.
Funktionsumfang und Kosten hängen vom aktivierten Schutzplan je Ressourcentyp ab; die Abdeckung je Cloud unterscheidet sich laut Support-Matrix.
Security Command Center (Event und Container Threat Detection)
Google Cloud
Event Threat Detection überwacht den Cloud-Logging-Strom mit Cloud Audit Logs und kann Google-Workspace-Logs auswerten; Container Threat Detection überwacht GKE-Knoten zur Laufzeit.
Erkennungslogik nutzt Kompromittierungsindikatoren, Profile über gleitende Zeitfenster, maschinelles Lernen und Anomalieerkennung; Container Threat Detection sammelt Verhalten im Gast-Kernel und in ausgeführten Skripten.
Regeln decken unter anderem geleakte Dienstkontoschlüssel, sensible RBAC-Änderungen und privilegierte Pods in GKE ab; der CIEM-Dienst meldet Identitäts- und Zugriffsbefunde.
Befunde lassen sich über Pub/Sub exportieren und mit Cloud Run functions verarbeiten; die Enterprise-Stufe bringt Fälle, Playbooks und Google Security Operations.
Event und Container Threat Detection gehören zur Premium- und Enterprise-Stufe; die Enterprise-Stufe (Google Cloud, AWS, Azure, nur auf Organisationsebene) wird laut Google am 21.05.2027 eingestellt, betroffene Organisationen wechseln dann auf Premium.
Google-Cloud-Organisationen, die Control-Plane-, Workspace- und GKE-Ereignisse zentral überwachen.
Eigene Erkennung für Cloud Audit Logs, Workspace und GKE ohne separate Datenpipeline.
Multi-Cloud-Anbindung und Fallbearbeitung hängen an der Enterprise-Stufe, die Google per 21.05.2027 einstellt; die Nachfolge ist vor der Auswahl zu klären.
Cortex Cloud (Cloud Detection and Response)
Palo Alto Networks
Analytik-Erkennungen für AWS-, Azure- und GCP-Audit-Logs, Kubernetes-Audit-Logs, Azure-AD- und Okta-Logs sowie SaaS-Quellen wie Office 365, Google Workspace und Box.
Cloud-Logs werden über Konnektoren eingesammelt, für AWS etwa über eine dokumentierte Audit-Log-Sammelarchitektur, für Google Cloud über Pub/Sub; ein Agent auf den Workloads liefert Laufzeitschutz.
Der Agent blockiert Malware, Ransomware und bösartige Prozesse auf VMs, Containern, Kubernetes und Serverless; Risiken werden über Cloud, Identität, Netzwerk und Daten korreliert.
Automatisierungs-Playbooks und Skripte laufen auf Cortex-Engines; Cortex Cloud ist auch auf Cortex XSIAM verfügbar.
Cloud-Dienst; die Erkennungsregeln gehören zur gemeinsamen Analytik der Cortex-Plattform.
Unternehmen mit Cortex-SOC, die Cloud-, Identitäts- und SaaS-Ereignisse in denselben Fällen bearbeiten wollen.
Breite Liste von Cloud-, Identitäts- und SaaS-Datenquellen in einer Analytik, kombiniert mit Agent und Playbooks.
Die Zuordnung, welche Erkennungen zu Cortex Cloud und welche zu XSIAM gehören, ist je Lizenz zu klären.
CrowdStrike Falcon Cloud Security (CDR)
CrowdStrike
CDR ist eine Funktion von Falcon Cloud Security und schützt laut Datenblatt Workloads in AWS, Azure, Google Cloud, Kubernetes und On-Premises.
Verhaltensbasierte Cloud Indicators of Attack (IOAs) mit Streaming-Erkennung, verbunden mit Cloud Workload Protection sowie Identitäts- und Endpunktkontext.
Erkennt agentenbasierte und agentenlose Cloud-Angriffe über Infrastruktur und Control Planes; Eindämmung mit und ohne Sensor blockiert Identitäten und beendet kompromittierte Workloads.
Unified Cases verknüpfen Cloud-, Identitäts- und Endpunktaktivität in einer Zeitleiste der Falcon-Plattform.
Cloud-Dienst; Falcon Complete und Falcon Adversary OverWatch bieten 24/7-Überwachung und Reaktion als Managed Service.
SOCs, die bereits Falcon für Endpunkte und Identitäten nutzen und Cloud-Angriffe im selben Fall sehen wollen.
Cloud-, Identitäts- und Endpunktsignale laufen in denselben Fällen zusammen, inklusive Managed Service.
Die genutzten Cloud-Logquellen und Kubernetes-Audit-Daten sind auf den geprüften öffentlichen Seiten nicht benannt.
Wiz Defend
Wiz (Google)
Analyse von Cloud- und SaaS-Logs sowie Laufzeitsignalen aus VMs, Container-Umgebungen und Serverless-Containern.
Der Wiz Sensor liefert eBPF-gestützte Laufzeitsignale; sie werden mit dem agentenlosen Kontext der Wiz-Plattform verbunden.
Erkennt Laufzeitanomalien im Benutzerverhalten und in Zugriffsmustern; der Sensor blockiert Bedrohungen auf Workloads in Echtzeit.
Cloud-native Eindämmungs-Playbooks, Ursachenanalyse und Korrektur im Quellcode.
Cloud-Dienst; die Kunden von Wiz betreiben laut Hersteller AWS, Azure, GCP und OCI. Forensische Daten werden agentenlos und agentenbasiert gesammelt.
Multi-Cloud-Teams mit Wiz, die Laufzeitangriffe im selben Graphen wie die Posture-Befunde untersuchen.
Laufzeitsignale werden mit dem Sicherheitsgraphen der Posture-Plattform verbunden, bis zurück zum Code.
Welche Cloud- und SaaS-Logs im Einzelnen unterstützt sind, nennt die Produktseite nicht; das ist im Pilot zu prüfen.
Orca Cloud Detection and Response
Orca Security
Laufende Überwachung von Cloud-Provider-Logs und Threat-Intelligence-Feeds, ergänzt um Laufzeitsignale aus Workloads, Containern und KI-Systemen.
Agentenloses SideScanning liefert die Posture-Sicht; der Orca Sensor ergänzt Echtzeit-Laufzeitsignale dort, wo aktive Erkennung nötig ist.
Meldet verdächtige Prozesse, laterale Bewegung, Datenabfluss, Malware und anomales Verhalten; ein Threat Investigation Agent rekonstruiert den Ablauf und schlägt die Ursache vor.
Befunde gehen in bestehende Ticket- und Behebungsabläufe; Auto-Remediation und automatisierte Behebungsschritte sind dokumentiert.
Cloud-Dienst mit Integrationen für AWS, Microsoft Azure und Google Cloud.
Agentenlos geprägte Cloud-Programme, die Laufzeiterkennung gezielt für kritische Workloads ergänzen.
Laufzeitbefunde werden mit vorhandenen Risiken wie Schwachstellen und Fehlkonfigurationen verknüpft.
Die konkreten Cloud-Logquellen und Kubernetes-Audit-Daten sind auf den geprüften Seiten nicht einzeln benannt.
SentinelOne Singularity Cloud Security
SentinelOne
Kombiniert agentenlose CNAPP-Funktionen (Cloud Native Security) mit dem Laufzeitschutz Cloud Workload Security.
Cloud Workload Security nutzt laut Hersteller eBPF ohne eigenes Kernel-Modul; Cloud-, Endpunkt- und Identitätstelemetrie wird in Echtzeit korreliert.
Erkennung, Untersuchung und Reaktion laufen nach Herstellerangaben autonom; überhöhte oder falsch konfigurierte Identitätsrechte werden erkannt und korrigiert.
Automatisierte Reaktionsabläufe helfen bei Priorisierung und Behebung; Teil der Singularity-Plattform mit Endpunktschutz.
Cloud-Dienst; die Produktseite nennt eine Integration mit Cloud-Anbietern, ohne diese einzeln aufzuführen.
Organisationen mit SentinelOne-Endpunktschutz, die Cloud-Workloads in dieselbe Plattform aufnehmen.
Laufzeitschutz ohne Kernel-Modul und gemeinsame Korrelation mit Endpunkt und Identität.
Cloud-Logquellen und unterstützte Clouds sind auf der geprüften Produktseite nicht benannt.
Tenable Cloud Security (CDR)
Tenable
Tenable CDR verbindet Governance der Management-Ebene mit Verhaltensanalysen in Multi-Cloud- und KI-Umgebungen.
Agentenlose Abdeckung, ergänzt um einen optionalen eBPF-Agenten für tiefere Laufzeitsicht.
Bedrohungssignale werden mit Identitätskontext und Exposure-Kontext aus der übrigen Tenable-Plattform angereichert.
Tenable Hexa AI unterstützt die weitere Untersuchung; die Reaktion erfolgt als geführter, priorisierter Massnahmenplan.
Cloud-Dienst als Teil von Tenable Cloud Security.
Tenable-orientierte Teams, die Laufzeitsignale mit erreichbaren Risiken aus dem Exposure Management verbinden.
Erkennungen werden mit Exposure-Kontext priorisiert, also mit dem Wissen, welche Risiken erreichbar sind.
Die Reaktion ist als geführter Plan beschrieben; Datenquellen und Clouds sind auf der Produktseite nicht einzeln genannt.
Sysdig Secure (Cloud Detection and Response)
Sysdig
Richtlinien für AWS CloudTrail, Azure Platform Logs, GCP Audit Logs, Kubernetes-Audit, GitHub, Microsoft Entra ID, Okta sowie Linux- und Windows-Workloads.
Ein Agent analysiert laufende Prozesse in Echtzeit; die Erkennung beruht auf Falco-Regeln, die das Sysdig Threat Research Team pflegt, ergänzt um ML-Richtlinien für AWS, Okta und Workloads.
Reaktionsaktionen umfassen Container beenden, stoppen oder pausieren, Prozess beenden, Datei in Quarantäne, Datei sichern, Netzisolation und Pod löschen.
Weiterleitung an SIEM- und Datenplattformen wie Google SecOps; Identitäts- und Audit-Log-Integrationen wie Okta.
SaaS oder Betrieb für Kubernetes, Container und Hosts in On-Premises-, Air-Gapped- und Private-Cloud-Umgebungen.
Kubernetes- und Container-Teams, die Control-Plane-, Identitäts- und Laufzeitereignisse mit denselben Regeln überwachen.
Breite dokumentierte Datenquellen von Cloud-Logs bis Okta und GitHub, kombiniert mit konkreten Reaktionsaktionen auf Workloads.
Der Nutzen der Laufzeitregeln hängt von der Agentenabdeckung ab; Regelpflege und Ausnahmen brauchen eigenes Know-how zu Falco.
Falco
The Falco Project (CNCF)
Systemaufrufe aus dem Linux-Kernel als Standardquelle; offiziell registrierte Plugins lesen Kubernetes-Audit-Ereignisse (auch aus EKS und AKS), CloudTrail, GCP-Audit-Logs, Okta und GitHub-Webhooks.
Ein Treiber liefert Kernel-Ereignisse an Falco, Plugins ergänzen weitere Ereignisquellen; Regeln mit Bedingungen und Ausgaben werten alle Quellen aus.
Erkennt abnormales Verhalten, mögliche Bedrohungen und Compliance-Verstösse auf Hosts, in Containern, Kubernetes und Cloud-Umgebungen und meldet sie in Echtzeit über Ausgabekanäle.
Ausgaben lassen sich an andere Systeme weiterleiten; Installation per Helm, Operator, Container oder Paket.
Graduiertes CNCF-Projekt unter Apache 2.0; Betrieb, Regelpflege und Weiterleitung liegen beim eigenen Team.
Kubernetes-Plattformteams, die eine offene Laufzeiterkennung mit eigenen Regeln aufbauen.
Offene Regeln und Plugins für Kernel-, Kubernetes-, Cloud- und Identitätsereignisse.
Reaktion, Korrelation und Fallbearbeitung muss das Team mit weiteren Werkzeugen ergänzen; für Azure-Aktivitätslogs ist kein offizielles Plugin gelistet.
Elastic Security (Cloud Detection and Response)
Elastic
Aufnahme von Logs und Warnungen aus Cloud-Quellen wie AWS CloudTrail, Audit Manager und VPC Flow Logs sowie aus Cloud-Sicherheitswerkzeugen; kompatibel mit AWS, Azure und Google Cloud.
Ein leichtgewichtiger eBPF-Agent schützt Linux-VMs und Kubernetes-Workloads zur Laufzeit; alternativ agentenlose Überwachung für Sichtbarkeit und Compliance.
Hunderte vorgefertigte Regeln und Anomalieerkennung für Cloud-Quellen; der Laufzeitschutz erkennt und blockiert Bedrohungen während sie stattfinden.
Automatisierte Reaktionen von einer Slack-Nachricht bis zu Live-Massnahmen wie dem Beenden eines Prozesses.
Wahlweise in Elastic Cloud gehostet oder lokal betrieben, was die Datenhaltung im eigenen Rechenzentrum erlaubt.
Teams mit Elastic-Know-how, die Cloud-Erkennung im eigenen SIEM mit eigenen Regeln aufbauen.
Cloud-Logs, Laufzeitagent und SIEM-Suche in einer Plattform, auch selbst betrieben.
Parser, Datenvolumen und eigene Erkennungsinhalte erfordern Aufwand im eigenen Team.
Weitere Anbieter
Kurz eingeordnet, ausserhalb der Vergleichsmatrix.
- Aqua Security (Cloud Detection and Response): Cloud Detection and Response im Portfolio von Aqua Security
- Datadog Cloud SIEM und Workload Protection: Cloud-SIEM und Laufzeitschutz von Datadog
- Upwind, Exaforce, Mitiga, Permiso: Cloud-Laufzeit-, Cloud-SOC-, Cloud-Forensik- bzw. Cloud-Identitätsspezialisten
- Microsoft Sentinel, Google Security Operations, Splunk (Cisco): SIEM-Plattformen mit Cloud-Konnektoren; Klasse SIEM, hier nicht im Vergleich
- Falco Talon: Reaktions-Engine im Falco-Umfeld; Dokumentationsseite am 2026-10-19 nicht abrufbar
- Posture-Findings werden als aktive Angriffe missverstanden.
- Cloud-Audit-Logs fehlen, kommen verspätet oder werden nur teilweise normalisiert.
- Automatische Reaktion verändert produktive Ressourcen ohne ausreichend enge Leitplanken.
Simuliere in einer Testumgebung einen missbrauchten Cloud-Schlüssel, eine verdächtige Rollenübernahme und einen Container-Ausbruch. Miss Erkennung, Kontext, Reaktionsweg und die Übergabe an das bestehende Incident-Verfahren.
CSPM bewertet Fehlkonfigurationen, CNAPP bündelt mehrere Cloud-Sicherheitsklassen. Laufzeitsignale gehören anschliessend in SIEM, XDR oder Case Management.
Security Tool Navigator · Gebiet 06
Im Gebiet Cloud und Infrastructure Security einordnen.
Diese Werkzeugklasse gehört zum Gebiet Cloud und Infrastructure Security. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.