Lacework Runtime Security EU Alternative 2026: FortiCNAPP CLOUD Act 22/25 und EU-nativer CWPP Stack

Post #1241 in der sota.io EU Cloud Workload Protection (CWPP) Serie

Lacework war einmal eines der am höchsten bewerteten Cybersecurity-Unicorns der Welt: 1,8 Milliarden Dollar Funding, eine Spitzenbewertung von über 8 Milliarden Dollar, und eine Polygraph-Technologie, die als Durchbruch in der ML-basierten Runtime-Threat-Detection galt. Das Ende dieser Geschichte ist bekannt — im August 2024 schloss Fortinet Inc. (NASDAQ: FTNT) die Übernahme für geschätzte 200–230 Millionen Dollar ab, ein Abschlag von über 97 Prozent gegenüber dem Höchstwert.

Lacework heißt seither FortiCNAPP und ist in das Fortinet-Sicherheitsportfolio integriert. Was diese Übernahme für EU-Organisationen bedeutet, die Lacework für Runtime Security und Cloud Workload Protection (CWPP) einsetzen oder evaluieren, ist der Fokus dieses Leitfadens.

Wichtiger Abgrenzungshinweis: Blog #1234 dieser Serie analysierte Lacework/FortiCNAPP aus CSPM-Perspektive (Cloud Security Posture Management — statische Konfigurations- und Compliance-Checks). Dieser Post konzentriert sich ausschließlich auf die Runtime Security und CWPP-Funktionen: die Polygraph-Verhaltensanalyse, Container-Runtime-Protection, Kubernetes-Sicherheit und Echtzeit-Bedrohungserkennung. Beide Funktionsblöcke haben dieselbe corporate-rechtliche CLOUD Act-Problematik — aber unterschiedliche Datenflusse und Risikoprofile.

Was ist Lacework Runtime Security / FortiCNAPP CWPP?

Laceworks technologisches Herzstück war nie CSPM — das kam später. Der ursprüngliche Differenziator war die Polygraph-Technologie: ein ML-basiertes System, das normales Verhalten von Workloads (Prozesse, Netzwerkverbindungen, Dateizugriffe) als Graph-Baseline modelliert und Abweichungen automatisch als Anomalien markiert, ohne dass manuell Regeln geschrieben werden müssen.

Polygraph: Stärke und EU-Datenschutz-Risiko zugleich

Die Polygraph-Technologie ist das, was Lacework technisch von regelbasierten CWPP-Systemen unterscheidet — und gleichzeitig der Grund, warum die EU-Datenschutz-Analyse besonders kritisch ist. Um Verhaltensabweichungen zu erkennen, muss Lacework granulare Telemetrie von jedem geschützten Workload kontinuierlich in die Cloud-Plattform übertragen.

EU-Kubernetes-Cluster (z.B. Frankfurt/Berlin)
  ↓ Lacework Agent auf jedem Node — privilegierter DaemonSet
  ↓ Polygraph: Syscall-Traces, Netzwerkflows, File-Events (kontinuierlich)
  ↓ Übertragung an FortiCNAPP Cloud-Backend (Fortinet-Infrastruktur, US)
  ↓ ML-Baseline-Modell wird aufgebaut (Stunden bis Tage)
  ↓ Anomalie-Alerts → SOC (SIEM-Integration)
  ↓ National Security Letter / FISA-Beschluss an Fortinet Inc. (Sunnyvale CA)
  ↓ Kein Audit-Trail für EU-Kunden, keine Benachrichtigungspflicht

Aus DSGVO-Perspektive ist diese Telemetrie problematisch: Prozess-Traces können personenbezogene Daten enthalten (Benutzernamen in CLI-Parametern, E-Mail-Adressen in Anwendungsprotokollen, API-Keys in Umgebungsvariablen), und die kontinuierliche Übertragung an einen US-Anbieter mit CLOUD Act-Exposition bedeutet, dass diese Daten potenziell US-Behörden zugänglich sind.

Unternehmensstruktur nach der Fortinet-Übernahme

Fortinet Inc. (NASDAQ: FTNT)

• Gründungsjahr: 2000 (Ken Xie + Michael Xie, vormals Juniper Networks)
• Rechtsform: Delaware C-Corporation
• Hauptsitz: 899 Kifer Road, Sunnyvale, CA 94086 (Silicon Valley)
• Börsennotierung: NASDAQ: FTNT (Large Cap, ~$60 Mrd. Marktkapitalisierung 2026)
• US-Bundesverträge: Ja — FortiGate/FortiOS ist auf US-Militärhardware, DoD-Netzwerken und Defense-Behörden im Einsatz. GovRAMP-Autorisierung für FortiCloud. FedRAMP Authorized für mehrere Fortinet-Dienste.
• Gründer-CEO: Ken Xie (seit 2000) — chinesisch-amerikanischer Staatsbürger, US-Resident

Lacework Inc. (Übernahme-Ziel, jetzt FortiCNAPP)

• Gründungsjahr: 2015 (Sanjay Kalra + Vikram Kapoor, Menlo Park CA)
• Rechtsform: Delaware C-Corporation (vor Übernahme)
• Post-Akquisition: Vollständig in Fortinet integriert als FortiCNAPP-Produktlinie
• Team: Kernteam weiterhin in San Jose, CA; Fortinet-Engineering in Sunnyvale
• Kunden-Übergang: Bestehende Lacework-Verträge werden unter Fortinet fortgeführt

MLAT-Abkommen und Sonderverhältnis USA-Justiz

Fortinet ist als US-Unternehmen dem CLOUD Act (18 U.S.C. § 2713) vollständig unterworfen. Besonders relevant: Fortinet hat aktive DoD-Verträge und GovRAMP-Autorisierungen — das ist eine Kategorie tiefer als ein normales SaaS-Startup. US-Strafverfolgung kann über National Security Letters (ohne Richterbeschluss) auf gespeicherte Kommunikation zugreifen; FISA-Beschlüsse ermöglichen Zugriff ohne Kundenbenachrichtigung.

CLOUD Act Risiko-Analyse: 22/25

Vergleich mit der EU-CWPP-Serie

Lacework/FortiCNAPP erreicht den höchsten Score in dieser Serie. Die Kombination aus FedRAMP-Autorisierung, aktiven DoD-Verträgen und der granularsten Runtime-Telemetrie aller analysierten Plattformen macht das CLOUD Act-Risiko besonders signifikant.

DSGVO-Implikationen: Runtime Telemetrie als Sonderfall

Während CSPM-Daten (Cloud-Konfigurationen, IAM-Policies) selten direkt personenbezogen sind, ist bei Runtime-Telemetrie der Personenbezug häufig implizit:

Art. 32 DSGVO — Technische und organisatorische Maßnahmen

Runtime-Telemetrie übermittelt an einen US-Anbieter mit CLOUD Act-Exposition bedeutet:

Noncompliance-Risiko:
- Prozess-Traces können Benutzernamen, Session-IDs, API-Keys enthalten
- Netzwerkflows zeigen welche Nutzer auf welche Dienste zugreifen (Metadaten)
- File-Integrity-Events können Dateipfade mit Personenbezug zeigen
- Bei US-Behördenauskunft: EU-Nutzer-Aktivitätsdaten übermittelt ohne Art. 49 DSGVO-Basis

Art. 32 verlangt: "Geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten." Eine Plattform, bei der US-Behörden ohne Benachrichtigung auf Runtime-Telemetrie zugreifen können, erfüllt dieses Erfordernis für kritische EU-Workloads nicht.

NIS2 Art. 21 — Cybersicherheitsmaßnahmen

NIS2 Art. 21(2)(d) verlangt Sicherheit der Lieferkette. Der Einsatz eines privilegierten DaemonSets mit kontinuierlicher Telemetrie-Übertragung an einen US-Anbieter ist ein dokumentierter Lieferketten-Risikofaktor, der einer expliziten Risikoakzeptanz der Geschäftsführung bedarf.

DORA Art. 28 — Drittparteien-Risikomanagement

Für Finanzunternehmen gilt DORA Art. 28: Wesentliche IKT-Drittparteien müssen einem strikten Risikomanagement-Framework unterzogen werden. Ein CWPP-Anbieter, der privilegierten Kernel-Level-Zugang zu Workloads hat und Telemetrie an US-Backend überträgt, qualifiziert in der Regel als wesentliche IKT-Drittpartei.

EU-native CWPP/Runtime Security Alternativen

Die EU-native Runtime Security-Landschaft ist stark im Open-Source-Bereich verankert — was für EU-Organisationen vorteilhaft ist, da selbst-gehostete Lösungen keine CLOUD Act-Exposition haben.

1. NeuVector (SUSE) — Vollständige Container-Netzwerksicherheit

Herkunft: SUSE SE (Nürnberg, Deutschland) — NeuVector 2022 als Open Source überführt (Apache 2.0)

NeuVector ist der umfassendste EU-native Container-Sicherheits-Stack mit Deep Packet Inspection auf Layer 7. Im Gegensatz zu Laceworks ML-Ansatz setzt NeuVector auf verhaltensbasierte Whitelists mit explizitem Lernmodus.

# NeuVector mit Helm deployen
helm repo add neuvector https://neuvector.github.io/neuvector-helm/
helm install neuvector neuvector/core \
  --namespace cattle-neuvector-system --create-namespace \
  --set manager.env.ssl=true \
  --set cve.updater.enabled=true

CLOUD Act Score: 0/25. SUSE SE ist ein deutsches Unternehmen (EQT-Fonds als Investor, aber SUSE selbst deutsches Recht), NeuVector läuft vollständig self-hosted.

2. Falco (CNCF) — Kernel-Level Syscall-Basierte Threat Detection

Herkunft: Sysdig Inc. (ursprünglich) → 2018 an CNCF gespendet. CNCF ist US-Nonprofit, aber Falco läuft vollständig self-hosted.

Falco ist der De-facto-Standard für Open Source Runtime Threat Detection in Kubernetes. Es nutzt eBPF oder Kernel-Module um Syscalls zu überwachen und wendet regelbasierte Policies (Falco Rules) an.

# Beispiel Falco-Regel: Unauthorized Shell in Container
- rule: Terminal shell in container
  desc: A shell was used as the entrypoint/exec point into a container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and container_entrypoint
    and not user_expected_terminal_shell_in_container_conditions
  output: >
    A shell was spawned in a container with an attached terminal
    (evt.type=%evt.type gparent=%proc.aname[2] evt.res=%evt.res
     proc=%proc.name user=%user.name %container.info)
  priority: NOTICE

Stärke gegenüber Lacework/FortiCNAPP: Keine Cloud-Backend-Abhängigkeit. Regeln werden lokal ausgewertet. Keine Telemetrie verlässt den Cluster. CLOUD Act Score: 0/25 (vollständig self-hosted).

3. Tracee (Aqua Security OSS) — eBPF-basierte Runtime Security

Herkunft: Aqua Security Software Inc. entwickelt, aber unter Apache 2.0 lizenziert und CNCF Sandbox. Aqua selbst ist US/Israel-Unternehmen — aber Tracee läuft vollständig self-hosted.

Tracee verwendet Linux eBPF (extended Berkeley Packet Filter) für granulare Kernel-Event-Überwachung ohne Kernel-Modul-Kompilierung. Es ist moderner als Falco in der eBPF-Implementierung.

EU-Deployment: Self-hosted, kein Backend. CLOUD Act Score: 0/25.

4. Tetragon (Cilium/CNCF) — eBPF Security Enforcement

Herkunft: Isovalent (heute Teil von Cisco, aber Tetragon CNCF-Projekt). Cilium/Tetragon läuft vollständig self-hosted.

Tetragon geht über Monitoring hinaus: Es kann Policy-Enforcement in Echtzeit im Kernel durchführen — Prozesse beenden, Syscalls blockieren — ohne User-Space-Latenz.

# Tetragon TracingPolicy: Schreiben in /etc/ erkennen und blockieren
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "write-etc-monitoring"
spec:
  kprobes:
  - call: "sys_write"
    syscall: true
    args:
    - index: 0
      type: "int"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Prefix"
        values:
        - "/etc/"
      matchActions:
      - action: Sigkill

Unterschied zu Falco: Enforcement statt nur Detection. Für Zero-Trust-Kubernetes-Cluster relevant.

5. KubeArmor — Kubernetes-native Runtime Security

Herkunft: AccuKnox (US-Startup), aber KubeArmor ist Apache 2.0 Open Source und CNCF Sandbox-Projekt.

KubeArmor verwendet Linux Security Modules (AppArmor, SELinux, BPF-LSM) für Container-Runtime-Security und kann pro Pod-Profil Security Policies durchsetzen.

Vergleich: Lacework/FortiCNAPP vs. EU-nativer CWPP Stack

Praxis-Empfehlungen für EU-Compliance-Teams

Szenario A: Lacework/FortiCNAPP bereits im Einsatz

Organisationen, die Lacework vor der Fortinet-Übernahme eingeführt haben, stehen vor einer veränderten Risikosituation. Die Empfehlung:

1. Datenschutz-Folgenabschätzung (DSFA/DPIA) nach Art. 35 DSGVO aktualisieren — die Übernahme durch einen FedRAMP-autorisierten US-Konzern ist ein material change.
2. Vertrag prüfen: Liegt ein aktueller DPA mit SCCs für Drittlandübermittlung vor? Sind die SCCs auf Fortinet Inc. als Datenimporteur ausgestellt?
3. Migration-Roadmap: Falls CLOUD Act-Freiheit Compliance-Anforderung ist (Finanzsektor DORA, Healthcare, Behörden) — Migrationspfad zu EU-nativem Stack definieren.

Szenario B: Lacework/FortiCNAPP in Evaluation

Vor der Einführung:

1. Legal Review: Fordern Sie von Fortinet eine schriftliche Stellungnahme, wie die Gesellschaft mit CLOUD Act-Anfragen umgeht und ob eine Benachrichtigungspflicht gegenüber EU-Kunden besteht.
2. Datenminimierung Art. 5(1)(c) DSGVO: Prüfen Sie, welche Polygraph-Telemetrie deaktiviert werden kann, ohne die Detection-Qualität zu kompromittieren.
3. Vergleich: Testen Sie NeuVector + Falco in einer parallelen Proof-of-Concept-Phase — die Kombination deckt 90%+ der FortiCNAPP CWPP-Funktionen ab.

Szenario C: Greenfield EU-native CWPP

Die empfohlene Stack-Kombination für neue EU-Deployments:

Container Runtime Security:  NeuVector (SUSE DE) — Netzwerk + Prozess-Security
Syscall Threat Detection:    Falco (CNCF) — regelbasierte Anomalie-Erkennung
Advanced eBPF Detection:     Tracee oder Tetragon (CNCF) — tiefes Kernel-Tracing
Policy Enforcement:          KubeArmor — LSM-basiertes Container-Hardening
Vulnerability Management:    Trivy (Aqua OSS, self-hosted) — Image + Runtime CVEs
SIEM-Integration:            Falcosidekick → Elastic/Loki/Splunk EU-Instanz

Dieses Setup hat einen CLOUD Act Score von 0/25, ist vollständig self-hosted, und kombiniert die Stärken verschiedener Projekte ohne eine einzelne kommerzielle Abhängigkeit.

Fazit: FortiCNAPP-Übernahme als CLOUD Act-Wendepunkt

Die Lacework-zu-FortiCNAPP-Übernahme ist aus EU-Datenschutzperspektive kein gradueller Wandel — sie ist ein Kategoriewechsel. Aus einem VC-backed Startup wurde ein FedRAMP-autorisierter, börsennotierter US-Konzern mit aktiven DoD-Verträgen. Das CLOUD Act-Risikoprofil von 22/25 ist das höchste in dieser EU-CWPP-Vergleichsserie.

Für EU-Organisationen, insbesondere in regulierten Sektoren (Finanzdienstleistungen, Gesundheitswesen, öffentlicher Sektor), ist FortiCNAPP/Lacework damit als primäre CWPP-Plattform problematisch. Die technologische Stärke des Polygraph-Ansatzes ist real — aber der EU-native Stack aus NeuVector, Falco und Tetragon/Tracee hat diese Stärken weitgehend nachgeholt, ohne das CLOUD Act-Risiko.

Der nächste Post in der EU-CWPP-Serie schließt die fünfteilige Analyse mit einem vollständigen Vergleich aller vier analysierten Plattformen (Wiz.io 21/25, Prisma Cloud 20/25, Trend Micro Cloud One 17/25, Lacework/FortiCNAPP 22/25) und einer Entscheidungsmatrix für EU-Compliance-Teams ab.

sota.io ist ein EU-natives Managed PaaS ohne US-Parent und ohne CLOUD Act-Exposition. Alle Workloads laufen auf Hetzner-Infrastruktur in Deutschland unter ausschließlich europäischem Recht. Jetzt deployen →