服務定位

Datadog Security 由四個 product 構成、共用 Datadog Agent 與 backend：Cloud SIEM（log-based detection、跟 Splunk Enterprise Security 同類）、Cloud Security Management (CSM) — 涵蓋 CSPM（cloud config posture）與 Cloud Workload Security (CWS)（container / Linux runtime via eBPF）、App and API Protection (AAP、前 ASM) — RASP-style 在 app runtime 收 attack signal、Sensitive Data Scanner — scan log 中的 PII / credential 並 redact。

跟 Splunk 比、Datadog 走 observability-first + security 是 view、Splunk 是 security-first。Splunk 在 enterprise SOC tooling 深度（SOAR playbook、RBA、CIM data model）與跨 on-prem 部署上更成熟、Datadog SaaS-only 但跟 APM / Infra 同 plane、混合 incident（latency 異常是攻擊還是容量？）的判讀路徑更短。跟 Elastic Security 比、Elastic 可跨 on-prem + OSS、Datadog 只給 SaaS；Elastic 要自己整合 observability 訊號、Datadog 出廠就有。跟 Google Security Operations 比、Google 走 fixed-price by data、PB-scale 划算、Datadog 隨 host 線性漲、中等規模友善但破千 host 後 cost 曲線變陡。

關鍵張力：observability 與 security 同 plane 是 Datadog 最大賣點、也是 cost 風險來源。host count 跟 events/month 同時是 observability 跟 security 的計費基準、security 加上去後 bill 不會獨立 — 預算要從 整個 Datadog 帳單 看、不是 security 單列。

本章目標

讀完本頁、讀者能判斷：

1. Datadog Security 在 SOC stack 中承擔哪一段（log SIEM / CSPM / 容器 runtime / WAF-runtime / log DLP）、哪些要外接（Vault、Okta IdP log、edge WAF）
2. observability + security 同 plane 的優勢何時成立、何時是 vendor lock-in 風險
3. Cloud SIEM 計費（events/month + indexed）跟 Standard / Flex Logs retention tier 的成本治理
4. 何時用 Datadog、何時走 Splunk / Elastic / Google Security Ops 的取捨

最短判讀路徑

判斷 Datadog Security 部署是否健康、最少看四件事：

• Datadog Agent coverage：agent 是否裝在所有 host / container / serverless wrapper、log forwarder 是否覆蓋 cloud control plane（AWS CloudTrail / GCP Audit Log / Azure Activity Log）、IdP（Okta）audit log 是否進來 — 缺一個就是 detection 盲點
• Detection rule ownership：Cloud SIEM rule 是用內建還是 custom、custom rule 是否走 Git 版控（Terraform datadog_security_monitoring_rule）、staging 環境是否 dry-run 24-48hr 才 promote production
• CSPM compliance check 治理：CIS / NIST / PCI baseline 開哪些、findings 是否進 ticket workflow、misconfig 修復 SLA 有沒有定義（critical 24hr、high 7d、medium 30d）
• Events/month + Indexed Log 預算：Cloud SIEM 按 events/month + indexed event 計費、新加 source 前是否估算 ingestion impact、Standard / Flex Logs retention tier 是否依 log priority 分流

四件事任一缺失、就是 Detection Coverage and Signal Governance 邊界的待補項目。

日常操作與決策形狀

Datadog Agent 採集：log / metrics / trace / security event 走同一個 Agent、用 integration（150+）抓 cloud / SaaS / database / queue。security event 跟 observability event 在後端用 attribute tag（env、service、host、trace_id）關聯、查 incident 時可以從 log alert pivot 到同 trace_id 的 APM trace 看 attack 發生的 application context。

Cloud SIEM detection rule：rule 形式類似 SPL 的 query — source:okta @evt.name:user.authentication.auth_via_mfa @outcome:failure 加 signal aggregation（rolling window count、new value、anomaly detection、impossible travel）。內建 rule 跟 MITRE ATT&CK 對應、跟 Splunk Security Content 同類但 rule 數量較少；custom rule 走 Terraform provider 進版控、不在 UI 直改 production。

CSPM compliance check：scan AWS / GCP / Azure 配置 vs CIS / NIST 800-53 / PCI / SOC 2 baseline、發現 misconfig（public S3 bucket、overly permissive IAM、不安全 SG rule）。跟 Wiz / Prisma Cloud 同類但跟 Datadog Infra 同 dashboard、findings 可以直接看到 affected resource 的 metrics / log。優勢是 資安發現可以直接看業務影響、限制是 graph-based attack path（Wiz 強項）不及專業 CNAPP。

Cloud Workload Security（CWS）：用 Linux eBPF probe 在 kernel 層觀察 container / process behavior、偵測 cryptominer / privilege escalation / 異常 syscall / file integrity 變動。跟 Falco 同類但跟 Datadog Infra 同 plane、CWS alert 可以直接 pivot 到該 container 的 CPU / memory / trace。Linux eBPF 對 kernel 版本敏感、舊 kernel 部份功能不可用、production 前要確認 fleet kernel matrix。

App and API Protection（AAP）：RASP-style protection、Datadog APM library 在 application runtime 收 attack signal（SQLi / XSS / SSRF / 異常 traffic pattern）。跟 Cloudflare WAF / AWS WAF 不同層 — WAF 在 edge / CDN、AAP 在 app runtime 看到的是真實 request handler / DB query。兩者互補不互斥：edge WAF 擋 volumetric attack 跟已知 pattern、AAP 補 app-specific business logic abuse。

Sensitive Data Scanner：scan ingest 進來的 log、用內建或 custom pattern 偵測 PII / credential / payment card / API key、發現後可以 redact、quarantine 或 alert。是 DLP-lite — 比不上 Google DLP / Microsoft Purview 的 sensitive data discovery / classification / lineage 全套、但對 log 中誤洩 secret 的場景夠用、是 detection signal source 也是 DLP 補位。

Notebooks + Workflow Automation：Notebooks 是 incident investigation 用的 query workbook、混 log query + metric chart + APM trace + 註記、跟 Splunk Search 比較像 Jupyter notebook 的 SOC 版。Workflow Automation 是輕量 SOAR、接 PagerDuty / Slack / Jira / Webhook / Vault API、playbook 走 visual builder + Python。SOAR 深度不到 Splunk SOAR、但對中等規模 SOC（10-50 人）的常見 response 動作（rotate credential / block IP / open ticket）夠用。

Standard Logs / Flex Logs + retention tier：log 進 Datadog 後分 Indexed（hot、可全文搜尋、貴）、Flex Logs（warm、retention 長、查詢延遲較高、cost 1/3-1/5）、Archive（cold、丟 S3 / GCS、純儲存）三層。Cloud SIEM detection 跑在 indexed log 上、所以 哪些 log 走 indexed 直接決定 detection coverage 跟 bill。tier 1 source（IdP / cloud control plane / payment）必 indexed、tier 2 source（app log）按 sampling、tier 3（debug）走 Flex 或 Archive。

核心取捨表

選 Datadog 的核心訴求：已經用 Datadog observability、cloud-native 為主、SOC 規模中等（10-50 人）、需要 observability + security 同 plane 的 incident 判讀路徑。on-prem 為主、預算敏感（host 量 1000+）、需要 enterprise SOAR / RBA 深度、走 Splunk；OSS-friendly、跨 on-prem、走 Elastic。

進階主題

Cross-product correlation（log + APM + metrics 同 trace_id）：Datadog 最特別的偵測形狀 — security alert 不只 log line、而是綁 trace_id 的 integrated incident view。例如 API endpoint 出現 SQLi 嘗試、Cloud SIEM 開 signal、同時 APM 看到該 request 的 DB query 跟 latency、infra 看到該 host 的 CPU。對「query latency 異常是不是被攻擊」這種混合 incident 偵測有結構性優勢、跟 Snowflake 2024 Credential Abuse 的調查路徑直接對應。

CWS Linux eBPF 行為偵測：eBPF probe 在 kernel 層、不需要 kernel module、不影響 process performance（< 1% overhead）。可以偵測的行為包括 file integrity（/etc/passwd 被改）、process tree（bash → curl → /tmp/payload 異常 chain）、network connection（容器對外連 cryptominer pool）、syscall pattern（ptrace 用於 process injection）。跟 Falco 同樣用 eBPF、差別是 Datadog CWS 不需要單獨部署 + 跟 Datadog 其他 signal 同 plane。

Datadog Threat Intelligence：內建 threat feed（malicious IP / domain / file hash）、自動標記 log / network event 命中 IoC。可以加自家 STIX/TAXII feed、不過深度比不上 Mandiant / Recorded Future / 專業 TI platform；中等規模 SOC 夠用、嚴重 APT 對抗場景要外接專業 TI。

跟 Datadog Incident Management 整合：security signal 可以直接開 Datadog Incident（內建 incident channel + timeline + post-mortem template）、跟 PagerDuty 同類但跟 observability 同 plane。對 資安事件升級成全公司 incident 的場景（Change Healthcare 2024 Operations Impact 那種規模）可以共用 incident commander 視角、不用兩套 timeline 拼起來。

排錯與失敗快速判讀

• Cloud SIEM 偵測 lag / 沒 alert：events 沒進 indexed log（走了 Flex）、retention tier 設錯 — 檢查 log pipeline rule 是否把 security-critical source 標 indexed
• Events/month 暴衝：debug log / verbose log 進 Cloud SIEM index、CWS event 量爆 — log pipeline 前置 filter（Datadog Observability Pipeline 或 Cribl）、CWS rule 收斂 noisy 行為
• CSPM findings 100+ 沒人修：findings 沒進 ticket workflow、沒分 priority — 整合 Jira / ServiceNow、severity 對應 SLA、findings 老化超 30 天升級
• CWS 在舊 kernel host 沒資料：eBPF feature 對 kernel 版本敏感（< 4.18 部份功能不支援）— 升級 kernel 或標記該 host 為 CWS-incompatible、補位用 host-based agent
• AAP false positive 卡 user：RASP 在 app runtime 直接 block、誤殺正常 request — AAP 先走 monitor mode 1-2 週收 baseline、tune 後再轉 protect mode
• Sensitive Data Scanner miss PII：custom pattern 沒寫對、log format 嵌套（JSON 內又是 JSON）— 用 sample log 跑 dry-run、scanner 跑在 ingest 階段不是 retroactive
• Workflow Automation playbook 黑箱：自動 rotate credential 結果誤殺 prod service account — playbook high-impact action 走 approval gate、default 走 containment 不走 deletion

何時改走其他服務

不在本頁內的主題

• Datadog Agent 完整 configuration reference、custom check 撰寫
• Datadog observability（APM / RUM / Synthetics / DBM）細節 — 屬 4 observability 模組
• Cloud SIEM rule 完整語法 reference
• CWS eBPF probe 撰寫（custom rule via Agent Expression Language）細節
• Datadog Incident Management workflow（屬 8 IR 模組）

案例回寫

Datadog Security 在 07 案例庫沒有直接 vendor-level 事件、但 observability + security 同 plane 的偵測形狀讓部份案例的調查路徑變短、值得對照：

下一步路由

• 上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle
• 平行：Splunk、Elastic Security、Google Security Operations
• 下游：Google DLP / Microsoft Purview（DLP signal 進 Datadog）
• 跨類：Okta（IdP log source）、HashiCorp Vault（Workflow Automation 拉 API）、Cloudflare WAF / AWS WAF（edge WAF log 進 Cloud SIEM、AAP 在 app 層補位）
• 跨模組：4 observability（同 Agent / 同 plane）、8 事故處理 vendor 清單（Datadog Incident → IR routing）
• 官方：Datadog Security Documentation

服務定位

Wiz 的核心定位是 agentless cloud posture + workload protection platform、把 CSPM（Cloud Security Posture Management）/ CWP（Cloud Workload Protection）/ CIEM（Cloud Infrastructure Entitlement Management）/ KSPM（Kubernetes Security Posture Management）/ DSPM（Data Security Posture Management）整合在同一個 Security Graph 上面。底層是 Connector（讀 AWS / GCP / Azure / OCI / K8s 的 read-only API + snapshot scan）、頂層是 Issues + Projects + Toxic Combination rules。

跟 Prisma Cloud / Lacework 比、Wiz 走 graph-first — 把 resource / IAM / vulnerability / secret / network exposure 連成圖（跳過 finding list 層）、可以用 query 問「哪些 EC2 有 RCE CVE 且 IMDS v1 且能 assume 跨帳戶 admin role」。跟 CrowdStrike Falcon Cloud Security 比、Wiz 是 agentless-first（CWP 才用 sensor、posture / 漏洞掃描 0 agent）、Falcon CS 走 endpoint agent 延伸到雲。跟 Datadog Security CSPM 比、Datadog 是 observability platform 上的 security view、Wiz 是 security-first CNAPP、Wiz 的 graph 跟 toxic combination 深度大幅領先、但獨立 SIEM / log 能力不如 Datadog / Splunk。跟 Snyk 比、Snyk 走 developer-first SAST + SCA + container、Wiz 走 cloud posture + agentless workload scan、兩者場景互補不替代 — 多數客戶 Snyk 管 left-shift dev 階段、Wiz 管 runtime cloud。

關鍵張力：agentless + multi-cloud + Security Graph ↔ 單一 workload count 計費 + 多模組組合容易踩 sticker shock。Wiz 的價值前提是組織夠大、cloud account / workload 夠多到 toxic combination 比 單點 CVE list 更有意義；小型團隊 + 單一雲 + 預算敏感、用 Wiz 等於買保時捷送外賣。

本章目標

讀完本頁、讀者能判斷：

1. Wiz 在 cloud security stack 中承擔哪一段（CSPM / CWP / CIEM / KSPM / DSPM / Wiz Code）、哪些要外接（Splunk 等 SIEM 接 Issues、Snyk / Trivy 是否要保留 dev-time scan）
2. Security Graph query 跟 Toxic Combination rule 的 ownership 設計（誰寫 rule、誰 triage Issue、誰調 Project scope）
3. Agentless scan 的可見性邊界（snapshot 能看到 / 看不到什麼、需不需要 Wiz Sensor / Defend 補 runtime）
4. 何時用 Wiz、何時走 Prisma Cloud / Lacework / CrowdStrike Falcon CS / Datadog CSPM 的取捨

最短判讀路徑

判斷 Wiz deployment 是否健康、最少看四件事：

• Connector 覆蓋率：所有 prod cloud account（AWS / GCP / Azure / OCI）跟 K8s cluster 是否都接上、IAM role 是否最小權限（Wiz 給的 CloudFormation / Terraform template 不要自己加權限）、snapshot scan 是否涵蓋所有 region / disk type
• Toxic Combination rule 設計：是不是只開預設 rule、有沒有針對自家環境 anti-pattern 寫 custom rule（例如 cross-account assume + payment service + secret access）、rule 走不走 PR review
• Issue triage SLA：critical / high Issue 的 mean-time-to-resolve、是否跟 Splunk / Jira / Slack 整合、Project scope 是否依 service owner 切（不是丟整包給 SecOps）
• Wiz Code / Wiz Defend coverage 邊界：IaC scan 跟 dev-time CI 是 Wiz Code 還是 Snyk / Trivy、runtime detection 是 Wiz Defend 還是 Falco / CrowdStrike、不要兩邊都裝又都沒人 triage

四件事任一缺失、就是 7.3 入口治理與伺服器防護 跟 7.13 偵測覆蓋率與訊號治理 的待補項目。

日常操作與決策形狀

Connector 跟 agentless scan：Wiz 透過 Connector（每個 cloud account 一個 IAM role）讀 cloud control plane API、定期 snapshot EBS / Persistent Disk / Managed Disk、在 Wiz 自家環境裡 mount snapshot 做 vulnerability / secret / malware scan。對 workload 0 影響、不需要在 EC2 / GKE node / VM 裡裝任何 agent。代價是 runtime 行為看不到（process / network connection / syscall）— 那段要 Wiz Defend / Wiz Sensor 或外接 Falco / CrowdStrike。

Security Graph：Wiz 把所有 resource（compute / storage / IAM principal / network / secret / vulnerability finding）建成 graph、用 GraphQL-like query 跨類型查詢。Security Graph 是 first-class concept、不只是 visualization — Toxic Combination rule、Issue correlation、blast radius 估算都走 graph。寫 SPL / KQL 跟寫 Wiz query 的 mindset 不一樣 — Wiz query 是 relationship-first（從 resource A 走幾跳到 resource B）、SPL 是 event-first（時間序列上的 log）。

Toxic Combination：CNAPP vs 傳統 vulnerability scanner 的根本差異。單一 finding 是 low risk（一個 CVE / 一條 over-permission / 一個 public S3）、組合起來是 critical attack path（public-facing EC2 + RCE CVE + IMDS v1 + assume admin role + 觸碰 customer PII bucket）。Wiz 預設帶幾十條 toxic combination rule（attack-path-style）、organization 應該加自家 anti-pattern。對應 7.2 身分與授權邊界 跟 7.5 應用層風險 的跨 control 整合。

Issues + Projects：finding 進 Wiz 後變 Issue、按 Project 路由 — Project 是邏輯切分（按 BU / service / 環境）、每個 Project 有 owner、Issue 自動分派。反例是 單一 default Project 收所有 Issue、SecOps 一天看 5000 個 Issue 看不完、跟 Alert Fatigue and Signal Quality 同樣模式。production 要 Project scope 對齊 service ownership、跟 Jira / Slack / Splunk 整合自動建 ticket。

Wiz Code：dev-time / IaC scan、覆蓋 Terraform / CloudFormation / K8s manifest / Helm + container image build-time scan + SCA、跟 Snyk Code/IaC 跟 Trivy Config 重疊。多數客戶選一邊用、不會雙開。Wiz Code 的賣點是 跟 runtime Wiz finding 同一個 graph — 在 IDE / PR 階段就能看到「這條 IaC 改動會在 prod 產生哪條 toxic combination」。

Wiz Defend (Gem)：2024 收購 Gem Security 整合 runtime detection / cloud detection、補 Wiz 早期缺的 runtime 層。Wiz Defend 走 cloud-native log + Wiz Sensor（K8s eBPF sensor）混合、跟 CrowdStrike Falcon EDR / Falco 競爭。產品成熟度仍在跟進、2024-2025 才大量 GA、不要假設它已經是 CrowdStrike / SentinelOne 等級的 EDR 替代品。

Wiz Sensor：K8s admission controller + eBPF runtime sensor、補 agentless 看不到的 runtime 行為（container process / network connection / file integrity）。是 選配、不裝 Wiz 仍能做 posture / vulnerability scan、裝了才有 runtime detection。資源開銷比 Falco 大、跟 CrowdStrike Falcon container sensor 競爭。

SIEM 整合：Wiz Issues / Detections 可推到 Splunk / Datadog Security / Elastic Security / Google Security Operations 走 SOAR playbook。常見 pattern：Wiz 偵測到 toxic combination → 推 Issue 到 Splunk → SOAR playbook 自動 isolate workload 或 rotate credential、走 HashiCorp Vault API。

核心取捨表

選 Wiz 的核心訴求：multi-cloud + 中大型組織 + 願意接受 agentless 的 runtime 邊界 + 重視 toxic combination 的優先級。如果組織已重度使用 CrowdStrike Falcon EDR、走 Falcon CS 延伸更一致；如果已重度 Palo Alto、走 Prisma Cloud 整合更深。

進階主題

Security Graph query language：類 GraphQL 的 query syntax、可以寫「找所有 public-facing EC2、有 CVE-2024-XXX、能 assume role 到 admin account、且該 role 可讀 prod-pii bucket」這種 5-hop query。production 用法：把高頻 query 存成 Saved Query + alert、把 attack pattern 寫成 Toxic Combination rule。Graph query 寫得好不好直接決定 attack path 是否被涵蓋、跟 SPL 寫 correlation rule 是同一個 ownership 議題。

Toxic Combination 設計：預設 rule 是 generic 雲安全 anti-pattern（public + vulnerable + over-permission）、organization 應該補 industry-specific 跟 organization-specific anti-pattern — 金融業要看「payment workload + cross-region replication + non-encrypted snapshot」、SaaS 多租戶要看「tenant-A workload + assume tenant-B role + 跨 tenant data access」。Toxic combination rule 走 PR review + staging tenant 驗證、跟 Detection Engineering Lifecycle 同流程。

Wiz AI (2024+)：LLM-assisted investigation — 用自然語言查 graph（「show me all critical issues touching prod payment service」翻譯成 graph query）、Issue triage 自動 summarize attack path、根因建議。實務上是 query 翻譯 + summarize、不是替代 analyst 判讀；高 stake 決策仍要人類 review。

Agentless secret scan：Wiz snapshot scan disk 時也掃 hardcoded secret（AWS access key / API token / private key）、跟 HashiCorp Vault / AWS Secrets Manager 整合做 rotation 路由。對應 7.6 秘密管理與機器憑證治理 的偵測層。

Sigstore / SBOM 整合：Wiz 可消費 SBOM（Syft / Grype 或 Trivy 產出）+ verify Cosign / Sigstore 簽章、把 artifact trust 接進 Security Graph。對應 7.12 供應鏈完整性與工件信任 的 build-to-runtime 證據鏈。

Wiz for AI：2024+ 新 module、針對 AI workload（LLM model storage / training dataset / inference endpoint）做 posture scan、找 misconfigured model bucket / exposed inference endpoint / training data leak。早期產品、定位是 AI workload 的 CSPM 延伸、不是替代 AI red team / prompt injection 偵測 工具。

排錯與失敗快速判讀

• Issue 爆炸 / 沒人 triage：default Project 收所有 finding、沒對齊 service ownership — 切 Project 給每個 BU / service、autoclose 已知 accepted risk、跟 Jira / Slack 整合自動分派
• Toxic Combination 沒命中真實 incident：只開預設 rule、沒寫 organization-specific rule — 從 red team case 庫 反推自家環境的 attack path、寫成 custom rule
• Snapshot scan 漏掉 ephemeral workload：scan 間隔 12-24hr、短命 Lambda / Fargate task 沒掃到 — 補 Wiz runtime sensor 或外接 Falco；ephemeral workload 改用 build-time scan（Trivy / Wiz Code）
• Connector IAM role 權限漂移：自己加了權限結果踩 over-permission — Connector role 用 Wiz 提供的 CloudFormation / Terraform template、走 Terraform 版控、不手改
• Sticker shock / 計費爆炸：開了所有 module（CSPM + CWP + CIEM + KSPM + DSPM + Wiz Code + Defend）、workload count 暴衝 — 只開核心 module、ephemeral workload 走 sampling、enterprise contract 談 cap
• Wiz Code 跟 Snyk / Trivy 雙開：dev team 用 Snyk、SecOps 用 Wiz Code、PR 兩邊 finding 重複 — 選一邊做 dev-time gate、另一邊只當 visibility、不要兩邊都 block PR
• Wiz Defend 當 EDR 用結果偵測能力不夠：runtime detection 期待 CrowdStrike 等級 — Wiz Defend 仍在跟進、純 EDR 需求保留 CrowdStrike / SentinelOne、Wiz Defend 補 cloud context 層
• Audit log retention 不夠：Wiz 預設 audit retention 偏短、incident 回查時資料缺 — push Issue 跟 audit log 到 Splunk / Datadog 做長期保存

何時改走其他服務

不在本頁內的主題

• Security Graph query syntax 完整 reference 跟所有 built-in toxic combination rule 清單
• Wiz Defend / Wiz Sensor 的 eBPF 內部實作細節
• Wiz Code 跟 IDE plugin（VSCode / JetBrains）的具體設定
• Cloud-native scanner（AWS Inspector / GCP Security Command Center / Azure Defender）的對照細節
• Wiz API 的具體 SDK 用法跟 Terraform Provider 配置
• CNAPP 市場的完整 vendor 比較（Gartner Magic Quadrant 等）

案例回寫

Wiz 在 07 案例庫沒有直接 vendor-level 事件、但多個 case 是 CNAPP 風險組合的對照：

下一步路由

• 上游：7.3 入口治理與伺服器防護、7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Snyk（dev-first SAST/SCA）、Trivy（OSS scanner）、Datadog Security（observability + CSPM）
• 下游：Splunk（Issues → SIEM）、HashiCorp Vault（SOAR 自動 rotation）、Syft / Grype（SBOM 接 Wiz Code）
• 跨類：AWS IAM / Google Cloud IAM / Azure RBAC（CIEM 分析對象）、Terraform（Connector / IaC 版控）
• 跨模組：8 事故處理 vendor 清單（Toxic combination → IR routing）、5 部署平台（cloud account / K8s onboarding）
• 官方：Wiz Documentation

服務定位

Prisma Cloud 的核心定位是 agent + agentless 雙軌 CNAPP、五模組覆蓋 cloud workload 從 IaC 到 runtime 的完整鏈：Compute Security（前 Twistlock、container / serverless / host workload 的 Defender agent + image scan）、CSPM（cloud posture、misconfiguration、compliance baseline）、Code Security（前 Bridgecrew、IaC 與 SCM scan）、Data Security（DSPM、雲端資料庫與 bucket 敏感資料偵測）、CIEM（cloud entitlement、跨雲 over-permission 治理）。Defender agent 是 host / pod / Lambda extension 上跑的常駐元件、提供 runtime IDS、file integrity、process anomaly 等 agentless 抓不到的訊號。

跟 Wiz 比、Prisma 走 agent + agentless 雙軌、Wiz 走 agentless-only。Wiz 用 cloud snapshot scan + control-plane API 抽訊號、部署快、不踩 host；Prisma Defender agent 補上 runtime behavior 的覆蓋（process spawn pattern、JNDI lookup、anomalous network connect）、代價是要在 host / pod / Lambda 上佈 agent、deployment 複雜度高一個層級。跟 Lacework 比、Lacework 用 Polygraph behavior graph 做 host-level anomaly、focus 在 detection；Prisma 覆蓋面廣（含 IaC + CIEM + DSPM）、但每個模組深度比 Lacework 偵測單點淺一點。跟 CrowdStrike Falcon Cloud Security 比、CrowdStrike 的 endpoint agent 已在多數 enterprise 環境跑、Cloud Security 直接共用 endpoint plane；Prisma 是 cloud-first CNAPP 加上 agent、不是 endpoint EDR 延伸。

關鍵張力：覆蓋面廣度 ↔ 模組整合成熟度 是 Prisma 客戶最常踩的 trade-off。五模組來自不同收購、UI / API / data model 整合仍在進行中、客戶常遇到「同一個 finding 在 Compute Console 顯示是 critical、在 CSPM 是 medium」、或「Code Security 報的 IaC issue 跟 Runtime 報的實際 config 對不起來」。預算允許就用 Prisma 拿覆蓋面廣度、不允許就走 Wiz（agentless 部署快）或 Lacework（單模組偵測深）。

本章目標

讀完本頁、讀者能判斷：

1. Prisma Cloud 在 cloud security stack 中承擔哪幾段（Compute / CSPM / Code / Data / CIEM）、哪些跟既有 SIEM / EDR / IdP 重疊或互補
2. Defender agent 該佈在 host / pod / Lambda 哪幾層、跟 Trivy / Snyk 等 OSS / SaaS image scanner 的分工
3. Compliance template（PCI / HIPAA / NIST / FedRAMP）跟自家 custom policy 的混用方式、誰能改 policy、誰 review
4. 何時用 Prisma、何時改走 Wiz（agentless-only）/ Lacework（detection-focused）/ Trivy（OSS CLI）/ EDR

最短判讀路徑

判斷 Prisma 部署是否健康、最少看四件事：

• Defender agent 覆蓋率：production K8s cluster 的 DaemonSet 是否所有 node 跑、VM workload 的 agent install rate、Lambda function 的 extension 啟用比例；缺一塊就有 runtime 偵測盲點
• Console 跟模組一致性：Compute Console / CSPM dashboard / Code Security finding / CIEM report 同一個 resource 的風險評級是否一致、不一致時誰是 SSoT
• Compliance template 對齊：啟用了哪幾套（PCI-DSS / HIPAA / NIST 800-53 / CIS / FedRAMP / SOC2）、跟內部 baseline 的客製 rule 是否走版控
• Alert 跟 SOC handoff：Prisma alert 是進自家 incident queue 還是 forward 到 Splunk / Google Security Operations、Cortex XSOAR 是否串 playbook

四件事任一缺失、就是 Detection Coverage and Signal Governance 邊界的待補項目。

日常操作與決策形狀

Defender agent deployment：agent 三種 footprint — K8s DaemonSet（每個 node 一個、攔截 container syscall + image runtime scan）、VM / host agent（Linux / Windows 安裝、file integrity + process anomaly）、Lambda extension（function runtime 注入、serverless 行為偵測）。Production 通常是 DaemonSet + VM agent 雙軌、Lambda extension 視 serverless workload 規模啟用。deployment 比 Wiz 多一步 — 要走 IaC（Helm chart / Terraform module）管 agent rollout、不能手動裝。

Console 跟 RBAC：Prisma Cloud Console 是統一入口、但底下 Compute（前 Twistlock UI 殘留）跟 Cloud（CSPM / Code / Data / CIEM）兩個 plane 分開。RBAC 角色設計常踩坑 — Compute 的 collection（host group）跟 Cloud 的 account group 是不同概念、需要分別給權限。

CSPM connector：CSPM 走 read-only cloud API（AWS Cross-Account Role / GCP Service Account / Azure App Registration）抽 config snapshot、定期 reconcile baseline。連 cloud account 是 onboarding 第一步、跟 Wiz / Lacework 同樣的 pattern、Prisma 的 connector permission template 偏寬、要 review 哪些 API 真用得到。

Code Security（Bridgecrew）：IaC scan 走 GitHub / GitLab / Bitbucket App、Terraform / CloudFormation / Kubernetes manifest / Dockerfile 在 PR 階段攔截 misconfiguration。Checkov 是 Bridgecrew 開源的底層引擎、Prisma 把 Checkov 規則庫 + 自家 policy 包成 SaaS。對應 6.6 release gate、IaC issue 在 PR 階段擋比 runtime 抓便宜兩個量級。

CIEM：cloud entitlement 治理、跨 AWS IAM / GCP IAM / Azure RBAC 找 over-permission 跟 toxic combination（例如 user 同時有 iam:PassRole + lambda:CreateFunction 可 privilege escalation）。CIEM 報告通常是大量「建議收權限」、實際 remediation 要跟 AWS IAM / Google Cloud IAM owner 排優先序、不是看到全收。

Data Security（DSPM）：雲端資料庫（RDS / BigQuery / Snowflake）+ object store（S3 / GCS）的 sensitive data discovery、跟 Google DLP / Microsoft Purview 功能重疊。Prisma DSPM 的優勢是跟 CSPM / CIEM 同 Console、可以看「敏感資料所在的 bucket 是否有 public ACL + 哪些 role 可以讀」、是 資料 + 入口 + 身份 同 plane 的關聯。

Runtime Protection（Aporeto microsegmentation）：Defender agent 提供 process / network level 的 runtime IDS / IPS — JNDI lookup 行為、異常 outbound callback、container escape 嘗試、unsigned binary 執行。比起 image-scan-only 多了 已知 CVE 沒 patch 但 runtime 行為偵測到 的覆蓋層。

跟 Palo Alto 生態整合：Prisma alert 可直接打到 Palo Alto Cortex XSOAR（SOAR / playbook）/ Cortex XDR（endpoint + cloud unified detection）/ NGFW / SASE（firewall rule 自動 push）。對已是 Palo Alto-heavy 環境是生態一致性增加；對非 Palo Alto 環境、Prisma 也 forward 到 Splunk / Elastic Security 走 webhook / Syslog。

核心取捨表

選 Prisma 的核心訴求：已在 Palo Alto 生態（NGFW / SASE / Cortex XDR / XSOAR）+ 需要 runtime agent + posture 雙覆蓋 + compliance audit heavy（PCI / HIPAA / FedRAMP）、且能承擔模組整合不完美 + 部署複雜度 + multi-year contract。純 agentless 用 Wiz、detection-focused 用 Lacework、純 OSS PR scan 用 Trivy + Syft / Grype。

進階主題

Defender agent rollout 策略：K8s DaemonSet 用 Helm chart 管 version + tolerations、staging cluster 先跑 1-2 週觀察 syscall overhead 跟 false positive、再 promote 到 production。VM agent 走 Ansible / SCCM / Terraform user-data、image baking 把 agent 包進 golden AMI 比每次 boot 安裝穩。Lambda extension 走 Lambda Layer、只對 high-value function 開（金流 / IdP / secret access）、不是全 function 都包。

Runtime IDS / IPS 模式：Defender 可設 audit only（只 log、不阻擋）或 prevent（自動 kill process / block network）。production 多數 workload 走 audit、只對 確定無誤報 的 rule 開 prevent（已知 malware hash、明確 CVE exploit pattern）。誤判 prevent 業務 process 比放過 alert 代價高、應該預設 audit + SIEM forward + SOC triage。

Compliance template + Custom policy 混用：Prisma 提供 PCI-DSS / HIPAA / NIST 800-53 / CIS Benchmark / FedRAMP / SOC2 完整 baseline、可直接啟用。但 baseline 通常太嚴或太寬、實務做法是 fork baseline + 加自家 exception + 加 organization-specific rule、走 Git 版控（policy as code、JSON / YAML）、PR review 後 sync 回 Console。policy 不能 console 直改、否則跟既有 SIEM rule 一樣失去 change history。

Cortex XSOAR / XDR 整合：Prisma alert → XSOAR playbook 是 Palo Alto 環境的標準路徑、playbook 自動執行 enrichment（拉 threat intel）/ containment（NGFW block / disable IAM user）/ remediation（Terraform PR auto-create）。playbook 要走版控 + dry-run、高影響動作（disable IAM user / delete resource）走 approval gate、不能 fire-and-forget。

計費結構：Prisma 按 module 選購 + 按 credit 消耗 + 按 workload count 三層計費、enterprise 通常是 multi-year package（3 年 commit 拿折扣）。實務坑 — 加新 cloud account 沒控管會吃 credit、Code Security 對大 monorepo scan 也吃 credit、Data Security 對大 bucket scan 是高成本項。月底常見的 sticker shock 來自 Defender agent 數量爆衝（K8s auto-scale 把 node count 推高）跟 新 cloud account onboard 沒走 quota 控管。

排錯與失敗快速判讀

• Defender agent overhead 影響業務 process：DaemonSet pod 吃 CPU / memory 過高、container syscall hook 拖慢 latency-sensitive workload — 把 runtime rule 從 prevent 改 audit、調 collection scope 排除 latency-critical namespace、向 Palo Alto support 開 ticket 看 agent profile
• 同一個 finding 模組評級不一致：Compute Console 顯示 critical、CSPM 顯示 medium — 確認 SSoT 是哪個模組、Compute 是 workload-level、CSPM 是 cloud-config-level、兩者本來就看不同 layer、用 Cortex XSOAR 統一 prioritization 而非靠 Console 對齊
• CSPM connector permission 報錯：Prisma 預設 IAM policy 太寬 / 太窄 — 走 least privilege 版本、跟 AWS IAM owner 確認哪些 API 真用到、不要照官方 template 全開
• Compliance template 一啟用就 1000+ finding：baseline 太嚴 + 既有環境本來就沒符合 — 走 staged adoption、先選 critical control（IAM / encryption / public exposure）、剩下進 backlog 排期、不要一次全開
• Code Security PR scan block 太多：Bridgecrew rule 對既有 IaC noisy — 用 baseline mode（既有 issue 標記、只 block 新 issue）、給 team 12 週 SLA 清 backlog、不要 day-1 block 全部
• CIEM 報告太多 over-permission：5000+ unused permission 看不完 — 排序看 toxic combination（privilege escalation path）優先、單純 unused 走每季 access review、不一次處理
• Cortex XSOAR playbook 誤殺：自動 disable IAM user 結果關到 CI/CD service account — 高影響動作走 approval gate、playbook default 是 containment（temporary block）not deletion

何時改走其他服務

不在本頁內的主題

• Defender agent 完整 syscall hook 清單 / runtime rule 語法 reference
• Bridgecrew Checkov 規則庫的逐條解釋 / 自寫 Checkov rule 細節
• Palo Alto Cortex XSOAR playbook 的 Python SDK 實作
• Prisma SASE / NGFW / Cortex XDR 完整功能（屬 network security / EDR、不在 CNAPP 範圍）
• Compliance 法規的逐條解讀（PCI-DSS / HIPAA 法律面）

案例回寫

Prisma 在 07 案例庫沒有直接 vendor-level 事件、但多個 supply chain / edge exposure case 是 Defender runtime + image scan 雙層的對照：

下一步路由

• 上游：7.13 偵測覆蓋率與訊號治理、7.10 供應鏈與第三方信任
• 平行：Wiz、Lacework、CrowdStrike Falcon Cloud Security
• 下游：Splunk / Elastic Security（Prisma alert forward）、AWS IAM / Google Cloud IAM（CIEM remediation 落地）
• 跨類：Trivy / Syft / Grype（OSS image scan 互補）、GitHub Advanced Security / Snyk（SCA 互補）
• 跨模組：6.6 release gate（Code Security PR scan）、8 事故處理 vendor 清單（alert handoff）
• 官方：Prisma Cloud Documentation

服務定位

Lacework 的核心定位是 Polygraph 驅動的 CNAPP、以 ML 自動學習正常行為作為偵測基礎。產品線涵蓋四個能力面：CSPM（Cloud Security Posture Management、misconfiguration 與合規 scan）、CWPP（Cloud Workload Protection Platform、host + container runtime 防護）、Code Security（IaC scan、container image scan、SAST baseline）、以及貫穿全平台的 Polygraph behavioral baseline engine。

跟 Wiz 比、設計哲學是相反的：Wiz 走 Security Graph + Toxic Combination（你顯式定義「EC2 + RCE + IMDS v1 + cross-account role」是 toxic、graph 找匹配 path）、Lacework 走 Polygraph implicit baseline（你不定義、ML 從 30 天歷史學 normal、偏離就 alert）。兩種都是 graph、但一個是 rule-driven graph、一個是 behavior-learned graph。跟 Prisma Cloud 比、Prisma 是 多模組 agent + agentless 寬覆蓋、Lacework 主打 Polygraph 為單一核心引擎、不靠堆模組廣度競爭。跟 CrowdStrike Falcon CS 比、Falcon CS 是 endpoint EDR 延伸到 cloud、Lacework 從第一天就為 cloud-native designed、沒 endpoint EDR 包袱。

關鍵張力：implicit behavioral baseline ↔ explicit auditable rule 是 Lacework 客戶最大的取捨。Polygraph 內部用 ML 學行為、好處是 zero rule maintenance、自動覆蓋未知 attack pattern；代價是內部邏輯不透明、false positive / false negative 都不容易 debug、強合規場景需要 explicit rule 可審計時會卡住。

本章目標

讀完本頁、讀者能判斷：

1. Lacework 在 cloud security stack 中承擔哪段（CSPM / CWPP / Code Security / behavioral detection）、哪些要外接（Splunk 等 SIEM 接 alert、8 事故處理 接 IR routing）
2. Polygraph ML baseline 的 ownership 設計（誰調 anomaly threshold、false positive 由誰判讀、ML model retraining cadence 誰負責）
3. implicit baseline vs explicit rule 的取捨何時偏 Lacework、何時要補 Wiz / Prisma 的 explicit rule layer
4. 何時用 Lacework、何時走 Wiz / Prisma Cloud / Falcon CS

最短判讀路徑

判斷 Lacework deployment 是否健康、最少看四件事：

• Polygraph baseline 覆蓋面：哪些 cloud account / workload / container 進了 Polygraph 學習、baseline window 多長（預設 30 天）、新 workload 進來幾天才視為 baseline 成熟、未覆蓋的 workload 是否走 fallback rule
• Anomaly tuning ownership：誰看 Polygraph alert、false positive 由誰標記、標記後怎麼回饋 model、有沒有 alert backlog grooming lifecycle（不是黑箱 fire-and-forget）
• CSPM 跟合規 mapping：CIS / PCI / SOC 2 / HIPAA framework 哪些開、misconfiguration finding 走 ticket workflow（誰修、deadline）、Compliance report 多久 export 一次給 audit team
• 跟 SIEM / SOAR handoff：Polygraph alert 是否同步進 Splunk / Datadog Security 給 SOC、是否跟 8 incident response playbook 對接、high severity 是否觸發 SOAR

四件事任一缺失、就是 Detection Coverage and Signal Governance 的待補項目。

日常操作與決策形狀

Polygraph behavioral baseline：Lacework 的 first-class concept、從 cloud API call（CloudTrail / Audit Log）+ host process tree + container syscall + network connection 四種 source 同時學習、用 time-series graph 表達「正常情況下 user X 在 workload Y 上會 spawn process Z、連 destination W」。anomaly 是 graph 上不在 baseline 中的 edge、自動 trigger alert。baseline window 預設 30 天、新 workload 進來時用同類 workload 的 baseline 過渡、避免 cold start 全部 alert。

CSPM（misconfiguration + compliance）：agentless 從 cloud API 拉 resource 設定、對照 CIS Benchmark / PCI / SOC 2 / HIPAA / CSA CCM 等 framework 跑 rule、出 finding。這部分是 explicit rule、不靠 Polygraph、跟 Wiz / Prisma 的 CSPM 能力同等級。Compliance report 可 schedule export 給 audit team。

CWPP（host + container runtime）：兩種模式 — agentless（從 cloud API + snapshot 掃 vulnerability + misconfiguration、低 overhead 但無 runtime signal）、agent-based（Lacework agent on host / DaemonSet on K8s、提供 process tree + syscall + file integrity monitoring 給 Polygraph）。production runtime detection 必須 agent、不然 Polygraph 沒 process / syscall 資料源。

Code Security（IaC + container image）：Terraform / CloudFormation / Helm chart 掃 misconfiguration、container image 掃 CVE + secret + SBOM、跟 Snyk / Trivy 同層級。整合 GitHub / GitLab PR check、release gate 前 block 高風險 IaC。

Compliance reporting：CSPM finding 自動 map 到 framework（CIS AWS / PCI DSS / SOC 2 等）、定期 export PDF / CSV 給 audit team、不需 SOC 手工整理。跨 cloud 帳號 aggregate view 對 multi-account 治理有用。

跟 SIEM 整合：Polygraph alert 走 webhook / S3 export / Splunk Add-on 進 Splunk / Elastic Security / Datadog Security / Google Security Operations、做 cross-source correlation。Lacework 不取代 SIEM、是 cloud-native detection 的 upstream signal source。

計費模型：按 workload count（vCPU 數 / container 數 / cloud account 數）+ 啟用模組。enterprise contract 為主、不公開 list price。跟 Wiz / Prisma 同模型、預算敏感場景需試算。

核心取捨表

選 Lacework 的核心訴求：cloud-native + 信任 ML behavioral baseline + 不想養 detection engineering team 寫 rule + 願意接受 Polygraph 是相對黑箱、false positive 要由 ML retraining 而非 rule edit 解決。強合規要 explicit rule 可審計、或 SOC 要深度 rule 客製化、走 Wiz / Prisma 更合適。

進階主題

Polygraph internals：Polygraph 不是單一 ML model、是 time-series behavioral graph + 多個 detection algorithm 組合。node 是 entity（user / workload / process / network endpoint）、edge 是 observed interaction、edge 上掛 frequency + temporal pattern。anomaly detection 用 unsupervised learning（clustering + outlier detection）找 baseline 外的 edge。優點是 zero-day attack pattern 不需事先定義也可能偵測到（行為偏離即可）、缺點是 detection 為何 trigger / 為何沒 trigger 都不易解釋、tuning 不是改 rule、是調整 baseline window 或標記 false positive 回饋 model。

Fortinet FortiCNAPP 整合（2024+）：Fortinet 收購後加速跟 Fortinet NGFW（network log 進 Polygraph 當 source）、FortiSOAR（Lacework alert 自動觸發 firewall block / endpoint isolation playbook）、FortiSandbox（suspicious file 進 sandbox 再回饋 baseline）整合。Fortinet-heavy 環境吃整合紅利、非 Fortinet 環境 Polygraph 跟原 connector 仍獨立運作。

Anomaly tuning lifecycle：Polygraph alert 出來不是終點、要走 triage → label false positive → ML model retraining lifecycle。實務上 SOC 看 alert 標 true positive / false positive / benign anomaly（合法但意外）、Lacework 後台用 label 重訓 model、下一個 baseline cycle 調整。組織要決定 誰負責 label（SOC analyst / detection engineer）、backlog grooming cadence（每週 / 每月）、retraining cycle（自動 / 手動觸發）。沒 lifecycle 就是「alert 看一陣子放著」、Polygraph 退化成噪音源。

跨 SIEM webhook / SOAR 整合：alert 推 Splunk / Elastic Security / Datadog Security 後、SOC 可用 SIEM correlation 補 cross-source（例如 Polygraph anomaly + Okta MFA fail + GitHub clone spike）、再進 SOAR playbook 自動 Vault rotate / Cloudflare WAF block。Lacework 是 detective layer、SIEM 是 correlation + orchestration layer。

排錯與失敗快速判讀

• 新 workload 進來大量 alert（cold start）：baseline 還沒建好、ML 把正常當異常 — 用同類 workload baseline 過渡、給 7-14 天 warm-up 再 enforce alert
• Polygraph alert 看不懂為何 trigger：ML 黑箱本質、不像 explicit rule 可指 line — 看 alert 帶的 involved entities + observed deviation、跨 entity 對 baseline 看差異、必要時補 Wiz / Prisma explicit rule 在強合規場景
• False positive 持續多但 model 沒進步：label lifecycle 沒跑、analyst 把 alert dismiss 沒打 label — 強制走 true positive / false positive / benign anomaly triage、不能直接 close
• Agent 沒裝 / 裝不到的 workload：legacy host / serverless / edge node 沒 agent、Polygraph 只有 cloud API source 沒 process / syscall — 接受 agentless-only 覆蓋面、不要假設 Polygraph 全 stack 看得到
• CSPM finding backlog 爆炸：framework 一次開全、misconfiguration 數千條沒人修 — 分批 enable framework、按 severity + asset criticality 排優先級、走 ticket workflow + deadline
• Compliance audit 要 explicit rule 可審查：Polygraph 內部邏輯不能交給 auditor — CSPM 部分可以審（是 explicit rule）、Polygraph 部分要補 detection engineering 文件 + label history 證明 ML 有治理
• Alert 進 SIEM 後沒 correlation：Lacework alert 跟 IdP / WAF / cloud control plane log 沒在 Splunk 跨 source 串 — 寫 correlation rule 把 Polygraph anomaly 當 one signal、不是當 final verdict

何時改走其他服務

不在本頁內的主題

• Polygraph ML 演算法的學術細節（unsupervised clustering / graph anomaly detection 具體方法）
• FortiCNAPP 跟 Fortinet 其他產品（FortiGate / FortiAnalyzer / FortiSIEM）的 deep integration 設定
• Lacework Labs threat research 報告的逐篇解讀
• 完整 CIS / PCI / SOC 2 framework 對應的 rule 清單
• Container runtime 防護的 OS-level 細節（cgroup / namespace / seccomp）

案例回寫

Lacework 在 07 案例庫沒有直接 vendor-level 事件、但多個 case 是 Polygraph behavioral baseline 的對照啟示：

下一步路由

• 上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle
• 平行：Wiz、Prisma Cloud、CrowdStrike Falcon Cloud Security
• 下游：Splunk / Elastic Security / Datadog Security / Google Security Operations（SIEM 接 Polygraph alert）
• 跨類：Snyk / Trivy（Code Security 重疊、CI 階段優先級）、HashiCorp Vault（SOAR playbook 拉 API rotate）
• 跨模組：8 事故處理 vendor 清單（Polygraph alert → IR routing）、4 observability（log pipeline 共用）
• 官方：Lacework Documentation / Fortinet Lacework FortiCNAPP

服務定位

Falcon Cloud Security 的定位是 agent-first 的 CNAPP、設計重心在「endpoint EDR agent 順便收 cloud workload 訊號」這條路徑、agentless CSPM 是補位、不是主軸。產品線靠多次收購整合：Bionic（2023 收購、現為 Falcon ASPM、application security posture management）負責 application architecture + runtime risk map；Flow Security（2024 收購、現為 Falcon Data Protection / DSPM）負責 sensitive data 發現與 access path；endpoint / workload / container runtime 偵測由 Falcon agent 自家補。

跟 Wiz 比、Falcon CS 走 agent-first + EDR 整合、Wiz 走 agentless-first + cloud workload graph。已部署 Falcon endpoint 的客戶上 Falcon CS 邊際成本 0；純 cloud-native 沒 endpoint workload 的環境、Falcon 的 agent 紅利不存在、Wiz 更快出價值。跟 Prisma Cloud 比、兩者都走 agent + agentless 雙軌、Prisma 強項是 compliance pack 跟 IaC scanning 模板、Falcon 強項是 CrowdStrike Intelligence threat actor profile + Counter Adversary Operations 提供的 hunting 服務。跟 Lacework 比、Lacework 走 behavioral baseline / anomaly detection、Falcon 走 signature + threat intel、兩種偵測哲學。

關鍵張力：agent 是 single point of compromise 是 Falcon agent-first 路線的長期信任成本。2024-07 Falcon sensor 推 bad content update 導致全球 Windows host BSOD 的事件、把 kernel-level agent 一改全炸 的風險具象化、對 agent-first vendor 是長期教訓。選 Falcon CS 等於買 agent 在 host kernel 的存取權、要把 agent 自身的供應鏈 當成風險來源納入評估。

本章目標

讀完本頁、讀者能判斷：

1. Falcon Cloud Security 在 cloud security stack 中承擔哪一段（CSPM / CWPP / CIEM / ASPM / DSPM）、哪些靠 Falcon agent、哪些靠 agentless connector
2. 已有 CrowdStrike endpoint 跟沒有 CrowdStrike endpoint 兩種起點下、Falcon CS 的判讀是否一樣
3. CrowdStrike Intelligence 跟 Counter Adversary Operations 在 detection lifecycle 的位置
4. 何時用 Falcon CS、何時走 Wiz / Prisma Cloud / Lacework 的取捨

最短判讀路徑

判斷 Falcon Cloud Security deployment 是否健康、最少看四件事：

• Agent coverage 跟版本治理：哪些 host / workload / container 跑 Falcon agent、是否跨 endpoint + cloud workload + Kubernetes node 一致、agent version 跟 sensor content channel 是否走 staging tenant + canary rollout（2024-07 incident 後的硬性要求）
• Agentless connector 覆蓋：CSPM 連到哪些 cloud account（AWS / GCP / Azure / OCI）、CIEM 是否拉 IAM identity graph、ASPM 連到哪些 application code repo
• Threat intel 是否接進 detection lifecycle：CrowdStrike Intelligence 的 IoC / threat actor TTP 是否餵進 Falcon detection rule、Counter Adversary Operations（MDR / threat hunting 服務）是否訂閱
• 跟 Falcon EDR 同 console / IR handoff：cloud finding 跟 endpoint finding 是否在同一個 Incident view、SOC team 跟 cloud team 的 routing 是否定義、跟 8 incident response 是否對齊

四件事任一缺失、就是 Detection Coverage and Signal Governance 邊界的待補項目。

日常操作與決策形狀

Falcon agent 統一：endpoint EDR 用的 Falcon sensor 同時收 cloud workload 上的 process / file / network telemetry、不需要再裝第二支 agent。對已用 Falcon endpoint 的組織意義最大 — VM / container host 上裝 Falcon 就同時是 EDR + CWPP + container runtime detection。新環境要評估 agent 的 kernel 存取權 是否可接受、container 內是否能或需要部署 agent（Falcon Container Sensor 走 sidecar / DaemonSet）。

CSPM：agentless 連 cloud account（AWS / GCP / Azure / OCI）、掃 misconfiguration（public S3 / over-privileged role / unencrypted disk）、對照 CIS Benchmark / NIST / PCI 模板。CSPM 是 配置面 訊號、補 agent 看不到的 cloud control plane 行為（例如 IAM policy change、S3 bucket policy 改變）。

CWPP — workload + container + Kubernetes：Falcon agent 在 VM host / container host / Kubernetes node 上做 runtime detection、看 process spawn、file integrity、network connection、container escape attempt。比 agentless snapshot scan 強的是 runtime behavior（看到實際發生的 process tree），比 Wiz agentless 弱的是 初始 coverage 速度（要先部署 agent）。

CIEM：把 cloud IAM identity 跟 access 畫成 graph、識別 over-privileged role / unused permission / cross-account trust risk。跟 AWS IAM Access Analyzer / Google Cloud IAM Policy Intelligence 是補位、不是替代 — CIEM 給的是 跨雲 + 跨 identity provider 的 risk view。

ASPM（前 Bionic）：application security posture management、把 application architecture（service graph / data flow / external dependency / vulnerability）畫成 map、識別哪個 vulnerability 真的可達 production attack surface。跟 Wiz Code / Snyk 的訴求重疊、但 Bionic 強項是 runtime + architecture 而不是 pure SAST/SCA。導入需要拉 application telemetry、不是裝完就有結果。

DSPM（前 Flow Security）：data security posture management、掃 cloud storage / database / SaaS 裡的 sensitive data 位置、誰能存取、access path 是什麼。跟 Google DLP / Microsoft Purview 不同層 — DSPM 是 posture 層（who can access what）、DLP 是 runtime 層（actual data egress event）、兩者互補。

CrowdStrike Intelligence 整合：CrowdStrike Intelligence 是 CrowdStrike 自家的 threat intel team、定期發 threat actor profile（COZY BEAR / FANCY BEAR / Scattered Spider 等命名來自 CrowdStrike）、IoC、TTP。Falcon CS detection rule 直接吃這層、不用 SOC team 自己訂閱外部 threat feed。這是 Falcon CS 跟 純 CNAPP 競品（Wiz / Prisma）最大差異 — 競品要再買 Mandiant / Recorded Future 才能補。

Charlotte AI：CrowdStrike 的 LLM-assisted investigation 介面、SOC analyst 用自然語言問 incident（「過去 24hr 有哪些 process 是 first-seen across fleet」）、Charlotte 翻成 Falcon query 跑。屬 SOC productivity 補位、不是 detection logic 本身。

跟 Falcon LogScale / Identity Protection 同 plane：完整 CrowdStrike stack 客戶可以把 Falcon LogScale（前 Humio 收購、SIEM）+ Falcon Identity Protection（identity threat detection）跟 Falcon CS 整合在同一個 console。Single pane of glass 強、但 vendor lock-in 也最深、退場成本是業界最高。

核心取捨表

選 Falcon CS 的核心訴求：已是 CrowdStrike endpoint 客戶 / SOC team 已熟 Falcon console + 看重 CrowdStrike Intelligence threat intel + 願意接受 agent-first 的供應鏈風險。純 cloud-only 沒 endpoint workload、agent 紅利不存在、走 Wiz 更划算。非 CrowdStrike 環境想要 compliance + IaC、走 Prisma Cloud。

進階主題

Counter Adversary Operations（MDR + threat hunting）：CrowdStrike 的 managed detection and response 服務、24x7 SOC team + threat hunter 主動掃客戶環境裡的 adversary 跡象。跟一般 MDR 不同的是、它直接接 CrowdStrike Intelligence 的 threat actor profile、看到 TTP 匹配就主動 hunt 而不是等 alert。對 SOC team 規模有限但要面對 nation-state actor 的組織、是補 SOC capability 的快路。

CrowdStrike Intelligence threat actor profile：CrowdStrike 把 threat actor 用命名規則（BEAR = Russian state、PANDA = Chinese state、KITTEN = Iranian state、SPIDER = eCrime）+ 編號管理、每個 actor 有 TTP、tooling、target sector 的 profile。Detection rule 不再只看 IoC（hash / IP）而是看 actor 的 behavioral pattern、IoC 變了也能抓。配對 Microsoft Storm-0558 Signing Key Chain 的 nation-state actor lesson。

Falcon LogScale 整合：Falcon LogScale（前 Humio）是 CrowdStrike 自家的 SIEM、可以把 Falcon agent telemetry + cloud log + 自家 app log 全收。跟 Splunk 比、LogScale 強在 跟 Falcon detection 同 plane、計費也不是 ingestion-based；弱在 detection content 跟 ecosystem 比 Splunk 淺。

Charlotte AI + LLM-assisted investigation：SOC analyst triage 時間長是普遍痛點、Charlotte AI 用 LLM 把自然語言問題翻成 Falcon query、補出 incident timeline summary。屬 SOC productivity 工具、不取代 detection rule、也不取代 analyst judgement。

Falcon Identity Protection 補位：identity-layer threat detection（pass-the-hash、Kerberoasting、AD enumeration）、跟 Okta ITDR 訊號互補。完整 stack 客戶可把 endpoint + cloud + identity 三層 telemetry 一起 correlate。

排錯與失敗快速判讀

• Agent rollout 一改全炸：sensor content channel 沒有 staging tenant、prod 直接吃 vendor push 的 update — 2024-07 incident 後 CrowdStrike 推 Sensor Update Policy 允許客戶設 canary ring、所有 prod 都該開、不開等於把 fleet 命交給 vendor QA
• Cloud workload coverage 不全 / 偵測盲點：只有部分 VM 部署 Falcon agent、container / Kubernetes 沒覆蓋 — 補 Falcon Container Sensor（DaemonSet）+ CSPM agentless 連 cloud account 補配置面
• Threat intel 沒接進 detection lifecycle：訂了 CrowdStrike Intelligence 但 SOC team 沒把 actor TTP 對應到自家 detection rule — 走 Detection Engineering Lifecycle、定期 review intel report + rule coverage gap
• CIEM finding 太多 / SOC 看不完：cloud IAM 累積 over-permission 沒清、CIEM 一掃幾千條 finding — 走 risk prioritization（哪些 identity 真的可達 sensitive resource）+ 跟 Cloud IAM ownership 對齊、不是 dump 給 SOC
• ASPM 拉不出 application graph：Bionic 需要 application telemetry + repo integration、只裝 Falcon agent 不會有 application architecture map — 補 ASPM 的 application onboarding（repo / CI / runtime telemetry）
• DSPM 找到 sensitive data 但沒 follow-up：DSPM 是 posture 層、發現問題後要走 Data Classification lifecycle、不是只把 finding 丟到 dashboard
• Vendor lock-in 過深、退場時 SOC 工作流崩潰：所有 detection content / IR playbook / Charlotte query / LogScale dashboard 都綁 Falcon — 關鍵 detection rule 同步 export 成 Sigma format（中性 format）、IR playbook 寫成 vendor-neutral 文件、不全押在 Falcon console

何時改走其他服務

不在本頁內的主題

• Falcon agent 內部 architecture（kernel module / sensor content channel 細節）
• CrowdStrike Intelligence 完整 threat actor 名單與 TTP reference
• Falcon LogScale 完整 SIEM 操作（屬獨立 SIEM 章節範圍、跟 Splunk 對照）
• 2024-07 Falcon update incident 的完整 root cause（屬 8 incident response 範圍）
• Falcon Identity Protection 的 AD-specific detection rule（屬 identity-access 範圍）

案例回寫

下一步路由

• 上游：7.12 雲端控制面安全與 CNAPP、Detection Coverage and Signal Governance
• 平行：Wiz、Prisma Cloud、Lacework
• 下游：Splunk / Google Security Operations（SIEM 對照）、Google DLP / Microsoft Purview（DLP 補位）
• 跨類：AWS IAM / Google Cloud IAM（CIEM 訊號來源）、Okta（identity threat 對照）
• 跨模組：8 事故處理 vendor 清單（cloud finding → IR routing）、6.4 release gate（ASPM finding → release gate）
• 官方：CrowdStrike Falcon Cloud Security