服務定位

Elastic Security 的核心定位是 Elastic Stack 上的 security solution、底層是 Elasticsearch（資料層）+ Kibana（查詢與 UI 層）+ Fleet / Elastic Agent（採集層）、頂層產品分三條：Elastic SIEM（log aggregation + detection rule + Case + Timeline）、Elastic Defend（前 Endgame 收購而來、EDR + endpoint protection、跟 CrowdStrike / SentinelOne 同層）、Elastic Cloud Security（CSPM + CWP、雲端資源 misconfig 與 workload 防護）。

跟 Splunk 比、Elastic 走 OSS-friendly + resource-based pricing — TB-scale ingestion 不直接漲費用（要 scale node 但邊際成本遠低於 Splunk per-GB 累進）、Sigma rule 社群可直接 import 5000+ 規則；但 Splunk Security Content 跟 SOAR / RBA 等 detection content + SOC tooling 成熟度仍高一個量級。跟 Datadog Security 比、Elastic 跨 on-prem + 多雲、可自管也可 Elastic Cloud SaaS；Datadog 是 SaaS-only、適合純 cloud-native。跟 Google Security Operations 比、Elastic 多查詢語言（KQL / EQL / Lucene / ES|QL）、Google 走 YARA-L 單一統一語言、超大規模 ingestion Google 反而划算。

關鍵張力：多查詢語言模型 同時是 Elastic 的優勢跟負擔。EQL 寫 attack chain sequence 比 SPL correlation 更直接、KQL 過濾快、ES|QL 寫 aggregation 像 SQL 直覺、Lucene 處理 full-text；但 SOC team 要決定哪個 rule 用哪個語言、不能讓每個 analyst 各寫各的。

本章目標

讀完本頁、讀者能判斷：

1. Elastic Security 在 SOC stack 中承擔哪一段（log aggregation / SIEM / EDR / CSPM）、哪些要外接（Okta IdP log、Vault secret rotation）
2. KQL / EQL / Lucene / ES|QL 四種查詢語言的職責分工（誰用在哪種 rule、誰負責教育 SOC）
3. Resource-based pricing 的治理（cluster sizing、hot-warm-cold tier、Searchable Snapshots、Elastic Cloud Serverless）
4. 何時用 Elastic、何時走 Splunk / Datadog / Google Security Ops 的取捨

最短判讀路徑

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

• 誰能改 detection rule：Elastic Security app 的 rule editor 權限、detection-rules repo（Elastic 官方 OSS rule 庫）有沒有 fork 進組織版控、rule change 是否走 PR review + staging space 驗證
• 採集治理：Fleet 統一管 Elastic Agent policy / 還是散落 Beats（filebeat / metricbeat / auditbeat / winlogbeat）各自設定、log source 是否分 hot / warm / cold tier、Searchable Snapshots 是否開
• Detection content coverage：Elastic Prebuilt rules + Sigma 社群規則 import 多少 enabled、是否跟 MITRE ATT&CK 對照、EQL sequence 規則覆蓋多少 attack chain pattern
• Alert quality / SOC handoff：alert volume per day、Case 跟 Timeline 是否進入日常 SOC workflow、ML anomaly job 是否在線 + threshold 是否 tuned、跟 8 incident response 的 routing 是否定義

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

日常操作與決策形狀

Ingestion architecture：log 進 Elastic 三種主路徑 — Elastic Agent + Fleet（現代部署的預設、單一 agent 收 system / endpoint / cloud / app log、中央 Fleet server 統一管 policy）、Beats（filebeat / metricbeat / auditbeat / winlogbeat 等專用 agent、Fleet 推出前的傳統做法、現在持續支援但建議遷移到 Elastic Agent）、Logstash（pipeline-style ETL、用在 enrich / filter / route 複雜場景）。production 通常 Elastic Agent + Fleet 為主、Logstash 補 ETL 缺口。

KQL / EQL / Lucene / ES|QL 的職責分工：四種查詢語言各有 first-class 場景。KQL（Kibana Query Language）是 Kibana 預設過濾語法、user.name : "alice" and event.action : "logon-failed"、簡單直觀、適合 dashboard / Discover 過濾。EQL（Event Query Language）做 sequence pattern matching、sequence by user.name [authentication where event.outcome=="failure"] [authentication where event.outcome=="success" and source.geo.country != "TW"]、表達 attack chain 比 SPL correlation 更直接。Lucene 是底層 full-text query、特殊需要時直接寫。ES|QL（Elasticsearch Query Language、2024+）是新版 SQL-like、FROM logs-* | WHERE event.category == "authentication" | STATS count = COUNT(*) BY user.name、寫 aggregation 直覺；屬新語言、production 採用 cadence 還在跟進中。

Detection rule 種類：Elastic Security 的 rule type 是六種 first-class 概念、不是只有「query rule」一種 — Query rule（KQL / Lucene 觸發）、EQL rule（sequence pattern）、Threshold rule（聚合超過閾值、例如同一 IP 5min 內 login fail > 100）、ML rule（綁 Elastic ML anomaly job、anomaly score 超過閾值觸發）、New term rule（首次出現的 entity、例如某 user 第一次從某國登入）、Indicator match rule（事件 enrich 比對 threat intel feed、IoC hit 觸發）。production rule 經常組合多種 — query rule 做粗篩、EQL rule 抓 sequence、threshold + ML 補 baseline anomaly。

Sigma rule import：Sigma 是 OSS 通用 detection rule 格式（YAML、跨 SIEM 可移植）、社群維護 5000+ 規則。Elastic 支援直接 import Sigma rule 轉成 Elastic detection rule、是 Elastic 拉開跟商業 SIEM 距離的 OSS 槓桿。實務做法：先 import Sigma baseline + 全部走 staging space 跑 false positive 觀察、再 enable 到 production；不要直接全 enable、Sigma rule 跨 SIEM 通用所以 environment-specific tuning 必須自己做。

Case + Timeline：Case 是 incident 容器、聚合 alert + comment + assignment + status；Timeline 是 SOC analyst 的 investigation workspace、可以 pin event / annotate / link related alert、產出 investigation narrative。兩者組合是 Elastic 的 SOC workflow first-class、不是外掛 — 對應 Splunk ES 的 Notable Event + Incident Review、但 Elastic 走 OSS 化、Case 可 export markdown 進 ticketing。

Elastic Defend（EDR）：前 Endgame 收購整合、提供 endpoint detection + prevention（malware block / ransomware protection / behavior detection）、跟 CrowdStrike Falcon / SentinelOne 同層。Elastic Defend 跑在 Elastic Agent 內、policy 從 Fleet 推。實務上多數 SIEM 客戶不會用內建 EDR、而是外接專業 EDR feed 進 Elastic SIEM；但 OSS-friendly + 預算敏感的中型客戶可以直接整合到一個 stack。

Cross-cluster search：跨多個 Elastic cluster 統一查詢（remote_cluster:index-name）、適合 multi-region / multi-tenant SOC、不需要把所有 log 搬到單一 cluster。對應 Splunk Cloud federated search。實務場景：歐洲 GDPR 資料留在 EU cluster、美國 cluster query 過去做 incident investigation 而不複製資料。

ML jobs（anomaly detection）：Elastic ML 內建 unsupervised anomaly detection、pre-built ML job library 覆蓋 SOC 常見場景（user behavior baseline、host login pattern、port scan detection、rare process）。ML rule 綁 ML job、anomaly score 超過閾值觸發 detection rule。對應 Splunk UBA、但 Elastic ML 是 stack 內建、不是 add-on app。

Resource-based pricing 治理：Elastic Cloud 按 cluster size（node count × node size）計費、不按 ingestion volume — 意義是 ingest 多 log 不直接漲費用、但要 scale node 維持查詢效能。實務治理：hot tier（最近 7-30 天、SSD 高效能 node）、warm tier（30-90 天、低 IO node）、cold tier / frozen tier（90 天以上、Searchable Snapshots on S3 / GCS、查詢慢但成本極低）。對應 Splunk SmartStore、但 Elastic frozen tier 把 retention 從幾個月延長到幾年、cost 不線性漲。

核心取捨表

選 Elastic 的核心訴求：OSS-friendly 文化 + resource-based pricing 友善 + Elastic Stack 已作為 observability 在用、團隊有能力跨四種查詢語言（或至少把 EQL 跟 KQL 雙語分工清楚）、能接受 detection content 跟 SOAR 成熟度 trade-off。TB-scale ingestion 時 Elastic 比 Splunk 省 60-80% license cost 是最大誘因、但要算進 cluster sizing 跟 SRE 維運的隱形成本。

進階主題

EQL sequence pattern（時序攻擊鏈）：EQL 的 sequence by 是 Elastic 表達 attack chain 的 first-class 武器、比 SPL correlation 直接。例如 MFA fatigue 寫成 sequence by user.name with maxspan=5m [authentication where event.outcome=="failure"] [authentication where event.outcome=="failure"] [authentication where event.outcome=="success" and source.ip != known_ip]、序列邏輯直接表達。配對 Uber 2022 MFA Fatigue lesson：MFA fail 序列 + 新裝置 success 直接觸發。

Elastic Defend endpoint response：除偵測外、Defend 支援 host isolation（隔離受感染 endpoint 但保留 SOC 連線）、process kill、file quarantine 等 response action、直接從 Kibana Security app 觸發。對應 CrowdStrike Real Time Response。production 採用前要設 approval gate、避免 SOC analyst 誤觸動 production server。

CSPM / CWP（Elastic Cloud Security）：CSPM（Cloud Security Posture Management）對 AWS / GCP / Azure 帳號做 misconfig 掃描（S3 bucket public、IAM over-permission、security group 0.0.0.0/0）、對照 CIS Benchmark；CWP（Cloud Workload Protection）對 Kubernetes workload 跑 runtime detection。屬較新的功能、跟 Wiz / Lacework 等專業 CNAPP 比覆蓋還在追趕。

Cross-cluster search 跨環境 federated query：multi-region SOC 的 first-class 工具 — query 寫 FROM logs-auth-*, eu-cluster:logs-auth-*、Elastic 自動路由跨 cluster。實務注意：跨 cluster query 延遲較高、要設 timeout；資料合規（GDPR）必須留意 query 結果是否包含跨境資料、不是搬資料但 query 結果回傳算不算傳輸要法務確認。

Sigma 規則社群：Sigma 是 OSS detection rule 通用格式、Elastic 是 Sigma 主力使用者（內建 importer + Elastic 工程師參與 Sigma upstream）。實務做法：fork SigmaHQ repo 進組織版控、CI pipeline 自動轉 Sigma → Elastic detection rule、staging space 跑 false positive curve、promote 到 production；不要每次 manually import。

Elastic Cloud Serverless（2024+）：新模型、按 workload type（search / observability / security）計費、不再按 cluster size — 減少 sizing 決策、autoscaling 由 Elastic 託管。屬新模型、production 採用 cadence 還在跟進中、適合 greenfield 部署或 PoC、existing cluster 遷移 roadmap 還在演進。

排錯與失敗快速判讀

• Alert volume 爆炸 / SOC 看不完：Sigma rule 全 enable 沒 tune、或 threshold rule 閾值太低 — staging space 跑 1 週統計 FP、tune threshold、加 exception list 排除已知合法 source、ML rule 補 user-specific baseline
• EQL sequence rule 跑不動 / timeout：sequence span 太長（24h）或 by field cardinality 太高、查詢成本爆炸 — 縮短 maxspan、限定 index pattern、加 pre-filter 條件
• Cluster 查詢慢 / Kibana 卡：hot tier 塞太多舊資料、沒做 hot-warm-cold tier 分層 — 開 ILM（Index Lifecycle Management）policy 自動 rollover、warm tier 用便宜 node、cold / frozen 走 Searchable Snapshots
• Fleet agent enrollment 失敗：Fleet server 跟 Elasticsearch 之間網路 / 憑證 / token 問題 — 檢查 Fleet server health、確認 enrollment token 未過期、agent log 看 specific 錯誤
• Sigma rule import 後大量 FP：Sigma rule 是 cross-SIEM 通用、沒有 environment-specific exclusion — 不要全 enable、staging tune 後再 promote、加 exception list（known scanner IP / 內部測試帳號）
• Resource-based pricing 超預算：node 過度 scale 或 hot tier 留太多 — 開 hot-warm-cold ILM、把 retention 超過 30 天的 index 推到 frozen tier on S3、Searchable Snapshots 是預設應該開
• ML job anomaly score 不準：training data 包含已 compromise 期間、baseline 被汙染 — 確認 training window 在乾淨期、定期重訓、配 detection rule 用 anomaly_score > 75 而非 > 50

何時改走其他服務

不在本頁內的主題

• KQL / EQL / ES|QL 完整語法 reference、Lucene query DSL 進階用法
• Elasticsearch index sharding / replica / ILM tuning 細節（屬 observability / 資料工程範圍）
• Elastic Observability（APM / logs / metrics）— 屬 observability 不屬 security
• Elastic Cloud Serverless 詳細 sizing 與 pricing 模型（2024+ 新模型、變動中）
• Elastic Stack 自管的維運（cluster upgrade、Kibana plugin 開發）

案例回寫

Elastic Security 在 07 案例庫沒有直接 vendor-level 事件、但所有 detection-related case 都是 SIEM 偵測覆蓋率的對照：

下一步路由

• 上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle
• 平行：Splunk、Datadog Security、Google Security Operations
• 下游：Google DLP / Microsoft Purview（DLP signal 進 Elastic SIEM）
• 跨類：Okta（IdP log source）、HashiCorp Vault（secret rotation API）、Cloudflare WAF（WAF log + Sigma rule 對接）
• 跨模組：8 事故處理 vendor 清單（Case → IR routing）、4 observability（Elastic Stack 共用 log pipeline）
• 官方：Elastic Security Documentation、detection-rules repo

服務定位

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