知識庫 Knowledge Base
產品介紹

Trellix 系列：品牌沿革、產品線與 XDR 平台

本篇合併「Trellix 是誰」「核心防護產品線」「XDR 平台與 Helix 運作原理」三篇文章，依序說明 Trellix 的企業沿革與品牌血統、產品線分工，以及其 XDR 平台 Helix 的實際運作方式與有出處的市場評價。

2026-08-17 · 18 min read
Trellix XDR EDR 資安廠商

本篇合併「Trellix 是誰」「核心防護產品線」「XDR 平台與 Helix 運作原理」三篇文章，依序說明 Trellix 的企業沿革與品牌血統、產品線分工，以及其 XDR 平台 Helix 的實際運作方式與有出處的市場評價。三篇內容各自獨立成節，可依左側目錄跳讀。

Trellix 系列 · 第 1 篇

Trellix 是誰？從 McAfee 與 FireEye 合併談起

企業沿革與品牌血統，附完整查證來源

📌 概述

Trellix 是 2022 年 1 月由私募基金 Symphony Technology Group（STG） 主導成立的資安廠商，不是一家從零開始的新創公司，而是 STG 先後收購兩家老牌資安公司「McAfee Enterprise（企業端業務）」與「FireEye（產品業務）」後，把兩者合併打造成的新品牌，主打「XDR（延伸式偵測與應變）」平台。

坊間對 Trellix 的來歷有不少以訛傳訛的說法，最常見的一個是「Trellix 因為合併而失去了 FireEye 最有名的 Mandiant 招牌」——查證後這個說法其實不準確，本篇會把時間順序講清楚。

🎯 適用情境

以下情境會用得到這篇的內容：

  • 客戶或主管詢問「Trellix 到底是誰、跟 McAfee、FireEye 是什麼關係」
  • 評估資安廠商時，需要判斷 Trellix 的技術血統與市場定位
  • 看到報價單或標案規格書出現 Trellix，想快速搞懂它的背景

🔍 技術原理（企業沿革時間軸）

Trellix 的身世牽涉四個名字：McAfee Enterprise、FireEye、Mandiant、Skyhigh Security。關鍵是時間順序——尤其 Mandiant 獨立的時間點，早於 Trellix 誕生。

FireEye
合併前
McAfee Enterprise
2021 年 3 月 · STG 收購約 40 億美元
FireEye 產品業務
不含 Mandiant 團隊
Mandiant
2021 年 10 月完成獨立掛牌
Skyhigh Security
2022 年 3 月同步拆出，專責雲端安全
Trellix
2022 年 1 月成立
Google
2022 年 9 月收購完成
FireEye 血統 McAfee 血統 Trellix（兩者合併後品牌）

Trellix 企業沿革：McAfee Enterprise 與 FireEye 產品業務合併成立 Trellix；Mandiant 早在合併前就已從 FireEye 獨立，與 Trellix 無直接血緣。

逐步拆解：

  1. 2021 年 3 月：STG 主導的財團以約 40 億美元收購 McAfee 的企業端業務（McAfee Enterprise，區隔於面向一般消費者的 McAfee 品牌）。
  2. 2021 年 5～10 月：FireEye 宣布把「產品業務」（含 FireEye 品牌與防護產品線）賣給 STG 主導的財團，同時把 Mandiant 這塊威脅情資／事件應變業務保留下來，改名為獨立上市公司「Mandiant, Inc.」。也就是說，Mandiant 在 Trellix 出生之前，就已經先跟 FireEye 分家了。
  3. 2022 年 1 月：STG 把手上的 McAfee Enterprise 與 FireEye 產品業務合併，改名為 Trellix，主打 XDR。
  4. 2022 年 3 月：同一時期，STG 把 McAfee Enterprise 原本的雲端安全資產（CASB／SWG／雲端 DLP 等）另外拆出，成立姊妹公司 Skyhigh Security，與 Trellix 同屬 STG 旗下但各自獨立營運（詳見系列第二篇）。
  5. 2022 年 9 月：Google 收購的是獨立公司 Mandiant, Inc.，併入 Google Cloud，交易金額約 54 億美元。這筆收購不是從 Trellix 內部拆走 Mandiant——因為 Mandiant 從一開始就沒有併入過 Trellix。

精確的表述應該是：Mandiant 在 FireEye 與 McAfee Enterprise 合併成立 Trellix「之前」，就已經先脫離 FireEye 成為獨立公司；Google 後來收購的是這家獨立的 Mandiant，與 Trellix 沒有直接的拆分關係。Trellix 自己保留的是原 FireEye「產品線」那一支的研究人員，現稱 Advanced Research Center（內含 Threat Intelligence Group），血統上追溯得到 FireEye，但不是 Mandiant 那支以事件應變聞名的團隊。

✅ 查證與來源

本篇所有企業沿革事實已由唯讀研究 subagent 交叉查證，來源如下：

💡 最佳實踐

  • 對客戶或內部簡報 Trellix 背景時，不要說「Trellix 因合併失去了 Mandiant」，這暗示 Trellix 曾經擁有過 Mandiant，會誤導聽眾。正確說法是「Mandiant 跟 Trellix 沒有直接血緣關係，兩者的共同源頭只到 FireEye 這一層，且分家時間點在 Trellix 成立之前」。
  • 若要強調 Trellix 的威脅情資能力，應該引用它自己的 Advanced Research Center，而不是借用 Mandiant 的名聲背書。
  • 遇到「Trellix 跟雲端安全的關係」相關問題，留意 Trellix 與 Skyhigh Security 是姊妹公司分工，細節見系列第二篇。
Trellix 系列 · 第 2 篇

Trellix 核心防護產品線深度介紹

端點、網路、郵件、DLP、雲端安全的分工全貌

📌 概述

如果把一間公司的資訊系統想成一個人體，端點（電腦、手機）是四肢、網路是血管、郵件是呼吸道、資料是血液——那 Trellix 賣的就是保護這幾個部位的「免疫系統」產品組合。但有一個常被搞混的地方：Trellix 不是這個人體唯一的醫生，它有一個負責「皮膚防曬與防護（雲端）」的姊妹公司 Skyhigh Security，兩家分工不同科別、但同屬一個集團（STG）。

本篇把 Trellix 各條產品線攤開來看，並釐清「雲端安全」這塊常被誤解的分工。

🎯 適用情境

  • 需要盤點 Trellix 產品線功能，判斷是否符合客戶需求
  • 撰寫 RFP／標案規格，需要準確描述 Trellix 各產品線涵蓋範圍
  • 客戶問「雲端安全是不是 Trellix 做的」，需要準確回答

🔍 技術原理（產品線逐一拆解）

1. Endpoint Security（ENS）— 端點安全

官方全名為 Endpoint Security (ENS)，延續原 McAfee ENS 產品線，涵蓋防毒、EDR（端點偵測與應變）、行為分析。這是 Trellix 產品組合中歷史最久、市佔基礎最大的一塊。

⚠️ 已知的使用者反饋

Capterra、PeerSpot 等評測網站上多則評論提到 McAfee/Trellix 端點代理程式在較舊硬體上會有明顯的 CPU 占用偏高、系統變慢的情況，甚至有用戶反映需要停用部分規則才能維持機器可用。這是彙整多則評論後的常見反饋，非單一具名評論的逐字引用，實際評估時建議自行試裝評測。（來源：Capterra 評論頁、PeerSpot 比較頁）

Trellix GTI 全域情資雲 MITRE ATT&CK / Story Graph 端點 Endpoint（Patient Zero 感染起點） 特徵碼資料庫 (DAT) + GTI 雲端信譽查詢 行為監控 Real Protect static + runtime 特徵 可疑 機器學習分類 Real Protect 判定 registry memory 動態遏制 DAC 攔截 + Rollback last known good state 已回復到最後一次已知的健康狀態 patient zero
1
檔案落地執行
惡意檔案透過下載、郵件附件或隨身碟落地端點，使用者開啟或程序啟動——這是 Trellix 官方所稱的 patient zero，端點防護鏈由此刻開始介入。

2. Network Security — 網路安全

延續原 FireEye NX 產品線的網路層威脅偵測能力，內建沙箱分析引擎（MVX），用於偵測透過網路流量傳遞的進階威脅。

網頁物件下載 HTTP／HTTPS 內容 郵件附件 SMTP 夾帶檔案 SPAN／TAP 鏡像 Trellix Network Security（NX） MVX 沙箱引擎 可疑物件擷取 JS／附件／URL 過濾 封閉測試網路 MVX 多重虛擬環境引爆 行為觀察記錄 檔案／登錄檔異動 API 呼叫與位址 感染歷程紀錄 攻擊者 C2 伺服器（僅虛擬環境內收到） 全球動態威脅情資 Dynamic Threat Intelligence （MPC） 受保護的 內部網路 ✕ 即時封鎖，並回溯標記先前已放行的相同物件
1
流量鏡像截取與可疑物件擷取
裝置透過 SPAN／TAP 鏡像埠複製通過的網頁物件與郵件附件流量，不影響原始封包路徑；系統從中擷取可能成為攻擊觸發點的可疑物件，包含傳統簽章難以判定的灰色地帶內容。

3. Email Security — 郵件安全

郵件威脅防護、釣魚偵測，同樣延續 FireEye 的郵件安全技術基礎。

外部寄件者 信譽檢查 SPF ✓ DKIM ✓ DMARC ✓ NED URL重寫佇列 連結改寫為代理網址 附件沙箱佇列 送入隔離環境等待引爆 IVX 動態分析引擎 檔案建立 登錄檔變更 對外連線 Advanced URL Defense PhishVision Kraken 網域與內容分析 商業郵件詐騙（BEC）偵測 — 獨立分支 身份冒充 $ 匯款變更誘導 外部寄件者旗標 派送決策 收件匣 隔離區 SOC ／ 使用者回報 情資更新後回頭清除
1
寄件者與網域信譽檢查
郵件送達時，先驗證 SPF/DKIM/DMARC 是否通過，並用 NED（Newly Existing Domain）工具檢查寄件網域註冊時間——攻擊者常在冒用網域註冊後數小時內就發動攻擊。

4. Data Security／DLP — 資料安全與資料外洩防護

Trellix 有自己的 DLP（trellix.com/products/dlp/），主打端點／網路／郵件場景的資料外洩防護——例如攔截員工把機密檔案透過 USB 或郵件外寄。

關鍵字／字典 正則表達式 資料指紋 IDM 檔案類型辨識 300+ 內容類型（官方數字） 機密財務報告.xlsx 使用者：王小明 USB／隨身碟 電子郵件 雲端上傳 網頁上傳 分類引擎 Content Classification 標籤：機密－財務 政策引擎 Policy Engine 情境資訊 使用者：王小明 通道：電子郵件 目的地：外部信箱 Block（阻擋傳送） Encrypt（加密後放行） Quarantine（隔離待審） Justify（要求理由才能繼續） Monitor（僅記錄） 使用者提示 偵測到您嘗試外寄 機密財務資料 理由： 客戶要求提供報價單 取消 送出並繼續 Trellix ePO 事件紀錄 09:15　陳小華　USB　一般文件　已放行 10:02　林大同　雲端上傳　客戶名單　已加密放行 10:42　王小明　電子郵件　機密財務報告　已記錄理由並放行
1
分類方法建置
部署前置作業：管理者用關鍵字／字典、正則表達式、資料指紋（IDM）、檔案真實類型辨識定義敏感資料規則，官方宣稱涵蓋 300+ 種內容類型。

5. Cloud Security — 雲端安全（分工重點，容易搞混）

這是最多人問錯的地方。查證後的準確狀況是：

  • Trellix 官網目前仍有一個「Cloud Security Service Edge」產品頁面，標榜 CASB＋SWG＋ZTNA 能力。
  • 但 STG 在 2022 年 3 月同步把 McAfee Enterprise 原本的雲端資產（CASB／SWG／CSPM／雲端 DLP）拆出，成立了專責雲端安全的姊妹公司 Skyhigh Security。
  • 兩家公司自 2025 年 1 月起由同一位執行長（Vishal Rao）兼任，STG 明確表示目前不考慮把兩家再合併，維持各自獨立營運但深度整合（2024 年 8 月雙方發布雲對雲整合公告）。
  • DLP 也是類似的分工：Trellix DLP 顧的是端點／網路／郵件場景，Skyhigh 的 DLP 則內建在其 CASB／CNAPP 產品中，顧的是雲端場景。兩者有整合，但不是同一個產品、也不是誰取代誰。
STG
私募基金，共同母公司
Trellix
端點・網路・郵件・DLP・XDR
Skyhigh Security
CASB・CSPM・SSE・CNAPP
深度整合／非合併

Trellix 與 Skyhigh Security 同屬 STG 旗下姊妹公司，各自獨立營運、深度整合，並非同一產品線。

💬 尚待查證之處

這一點目前公開資料無法百分之百確認：Trellix 官網的 Cloud SSE 頁面所使用的技術，究竟是 Trellix 自建，還是與 Skyhigh 整合／授權後的產物，未能查證到完全確定的結論，建議實際評估時直接向兩家官方業務確認技術歸屬。

上傳檔案 使用者瀏覽器 存取雲端 SaaS 應用 Forward Proxy 未受管裝置流量 Reverse Proxy 已知 SaaS 應用 API 連接器 主流 SaaS 服務 SSE 閘道 CASB / SWG Cloud Registry・已知雲端服務 ? CloudTrust 風險評分 1–9 評分 8・高風險 資料分類與 DLP 比對 EDM IDM OCR 雲端硬碟 SaaS 應用 允許 阻擋 加密 警示 隔離 Policy Incident 事件列表 剛上傳事件・已加密＋警示・回饋 SOC ★ SSE/CASB 引擎主要由同集團 Skyhigh Security 提供 Trellix 官網此頁技術歸屬未完全公開查證
1
使用者發起存取
員工用瀏覽器把檔案上傳到雲端硬碟這類 SaaS 應用——這是整條鏈的起點，沒有這個動作，後面的可視性、評分、政策比對都無從發生。

✅ 查證與來源

💡 最佳實踐

  • 跟客戶介紹「Trellix 全家桶」時，不要把雲端安全（CASB/CSPM/SSE）算進 Trellix 自己的核心能力，那主要是姊妹公司 Skyhigh Security 的專長，只是深度整合、共用集團資源。
  • 若客戶已用 Trellix 端點但想補雲端防護，方向應該是評估 Skyhigh Security（同集團、整合度較高），而不是預設 Trellix 內建就足夠。
  • 評估端點代理效能疑慮時，建議在客戶實際硬體環境做 POC 測試，不要只看廠商官方效能數據。
Trellix 系列 · 第 3 篇（完結篇）

Trellix 的 XDR 平台與 Helix 運作原理

Helix 運作流程、有出處的市場評價、優劣勢與選型建議

📌 概述

想像一間大樓有好幾組保全系統：門禁刷卡、監視器、火警偵測、電梯感應器，各自獨立運作、各吹各的哨子。傳統資安產品常常就是這樣——端點防毒、網路防火牆、郵件過濾各自為政，管理者得自己拼湊訊號才能判斷「這是不是同一起事件」。XDR（延伸式偵測與應變） 的概念，就是找一個「總機房」把所有哨子聲收進來，自動判斷哪些是同一件事、哪些只是誤報。Trellix 的總機房，叫做 Helix。

本篇說明 Helix 實際怎麼運作，並附上目前查證得到、有明確出處的市場評價，作為系列文章的總結篇。

🎯 適用情境

  • 需要跟客戶解釋「Trellix XDR 到底在做什麼」，而不是只會說「延伸式偵測與應變」這種行話
  • 評估是否採用 Trellix 作為 XDR 平台，需要客觀的市場定位參考（而非廠商自家行銷語）
  • 撰寫 Trellix 優劣勢比較報告，需要有出處的評價依據

🔍 技術原理：Helix 的運作流程

Helix 的角色是雲原生 SIEM ＋ 關聯分析引擎，不只是把資料堆在一起的「資料倉庫」，而是主動做跨來源比對、產生有意義告警的那一層。大致流程如下：

端點 網路 郵件 雲端 500+ 第三方工具 230+ 廠商 · 官方數字 Helix 關聯分析引擎 約排除 50%～70% 誤判（官方數字） ! 分析師優先佇列 新偵測 · 高優先
1
訊號收集
端點、網路、郵件、雲端等防護點持續各自產生 log、事件、流量紀錄。

點擊上方步驟或使用「自動播放」，看訊號如何從各來源匯入 Helix、經關聯分析產生偵測，再交給分析師處理。

✅ 市場評價（有出處，非行銷語）

以下是查證得到、可具體引用來源的第三方分析機構評價，刻意避開廠商自家宣傳用語：

評比機構／報告 結果 說明
Gartner NDR（網路偵測與應變）Magic Quadrant 2025 Niche Player（利基型） Trellix 有入榜，但非領先梯隊（來源，Trellix 自家部落格引述）
Gartner EPP（端點防護平台）Magic Quadrant 2025 Challenger（挑戰者） 111 家受評僅 15 家入選象限，Trellix 為 Challenger（來源，Trellix 自家部落格引述）
Forrester Wave：XDR Platforms Q2 2026 未受邀評比 本輪受邀 7 家（Bitdefender、CrowdStrike、Elastic、Microsoft、Palo Alto、SentinelOne、TrendAI）不含 Trellix；上一輪 Q2 2024 曾納入 Trellix（來源，CrowdStrike 引述）
GigaOm Radar for XDR 2024 廠商自稱 Leader 未找到 GigaOm 原始報告連結，僅有 Trellix 自家引述，建議標註「廠商引述、未見獨立原文」，不宜直接採信為客觀結論

白話解讀：Trellix 在端點防護（EPP）與網路偵測（NDR）市場有被主流分析機構納入評比，但定位是「挑戰者／利基型」，不是「領先者」；在最新一輪 XDR 平台專項評比（Forrester）甚至沒有受邀參加，這點在對客戶做廠商比較時應如實反映，不宜直接引用廠商自家「業界領先」的說法。

💡 最佳實踐：優劣勢總結與選型建議

優勢

  • 技術血統紮實：McAfee 端點/DLP 經驗＋FireEye 網路威脅偵測經驗，兩邊都是各自領域的老牌廠商（見系列第一篇）
  • 整合廣度大：Helix 號稱可接 500+ 第三方工具，不強迫客戶全部換成 Trellix 自家產品
  • 產品線齊全：端點、網路、郵件、DLP、XDR 一次到位，適合想找單一供應商減少管理複雜度的客戶
  • 同集團雲端安全資源：透過 Skyhigh Security 補足雲端防護，兩者深度整合（見系列第二篇）

劣勢

  • 市場定位非領先梯隊：Gartner 評比為 Challenger／Niche Player，最新 Forrester XDR Wave 未受邀，客觀評比上落後於 CrowdStrike、Microsoft Defender、Palo Alto Cortex XDR、SentinelOne 等
  • 品牌整合仍在進行：McAfee 與 FireEye 兩套產品線架構、管理主控台歷史上並非天生一體，實際使用上可能仍感覺到拼接痕跡
  • 端點代理效能疑慮：使用者評論反映在較舊硬體上有 CPU 占用偏高的情況（見系列第二篇的來源）
  • 雲端安全非自家核心：需要透過姊妹公司 Skyhigh Security 才能補齊完整雲端防護，不是單一廠商一站購足
選型建議

若企業已有 McAfee 或 FireEye 產品線、希望漸進整合而非全面換血，Trellix 是合理選項。若是全新採購決策，建議實際 POC 比較偵測率、代理程式效能、與管理體驗，並將 CrowdStrike、SentinelOne、Microsoft Defender for Endpoint 等目前分析機構評比較領先的廠商一併納入比較，不宜只看廠商官方行銷資料。