MDR資安服務能將海量告警轉化為實際應變行動！本文透過製造業14天POC案例，解析如何結合EDR與NDR進行多源交叉比對，主動揪出Log4j漏洞與Linux權限漏洞，協助企業建構完整的24/7資安防禦體系。
某精密材料製造大廠在發生資安事件後，為評估MDR是否可以提前預防資安事件發生，故模擬測試環境來測試各家資安廠商產品，客戶安排了一次為期 14 天的 POC，來驗證NEITHSeeker 端點威脅監控，是否能發現這次資安事件的根因。
在監控期間，系統共記錄 2,183 筆事件告警，其中包含688 筆中風險可疑行為，以及 1,495 筆參考性事件。乍看之下多屬於中低風險，但經監控團隊逐一交叉比對後，發現其中潛藏足以讓攻擊者長驅直入的關鍵漏洞。
1.看似「合法」卻帶著已知漏洞的服務元件
客戶內部主機持續運行 Elasticsearch 及另一套企業應用系統，兩者皆載入了存在已知漏洞（Log4Shell, CVE-2021-44228）的 Log4j 日誌框架版本。
這類服務平時穩定運作、不會主動報錯，極容易被視為「沒有問題」而長期忽略。監控團隊透過持續比對主機上運行元件版本與最新 CVE 資訊，主動標記出這項高風險項目，而非等待攻擊事件發生後才被動應對。
2.一個系統設定，就足以讓攻擊者提權
Linux 主機的 Ptrace 保護機制被設定為 0，代表保護處於關閉狀態。這是一個極容易被忽略的系統參數，一旦遭利用，攻擊者可藉此進行程序注入或提升至 root 權限。
這類設定層級的風險，通常不會觸發傳統防毒或防火牆告警，必須仰賴具備資安背景的分析人員主動盤點，才會被發現。
但透過監控團隊將端點行為與網路流量進行時間軸交叉比對，確認此連線行為缺乏授權紀錄，進而發出風險告警並提出應變建議，這正是「單一工具看不見、多方情資交叉比對才看得見」的典型案例，在結案報告中監控團隊從案例得知這些風險都是可以從監控中被掌握，而不是發生資安事件後來進行驗證各家產品功能。
【看見不等於安全】
多數企業導入資安工具的第一步，往往是在端點安裝 EDR（Endpoint Detection and Response），期待藉此「看見」端點上的異常行為。但 EDR 本身只回答了「發生了什麼」，並不會告訴企業「這代表什麼風險」「該如何處理」。
這也是為什麼近年來 NDR（Network Detection and Response）與 MDR（Managed Detection and Response）逐漸成為企業資安佈局的關鍵拼圖，NDR、MDR角色不同，缺一不可：
一、NDR
從網路流量的角度補足端點看不到的橫向移動、異常連線與內網掃描行為。
二、MDR
由專業資安團隊 24/7 持續監控、交叉比對 EDR／NDR 數據，主動判讀「哪些告警是真正的風險」，並在必要時即時介入處置。
【看見威脅只是開始，回應威脅才是關鍵】
這次 POC 案例說明了一件事
多數企業並非沒有「看見」風險的能力，而是缺乏將大量告警轉化為明確行動的判讀與應變機制。EDR 提供了可視性，NDR 補齊了視野的死角，而 MDR 則是把這些片段情資串連起來、主動出手處理的最後一哩路。
NEITHNET 提供包含 NEITHSeeker（端點）、NEITHViewer（流量／NDR）在內的完整 MDR 代管服務，並提供 14 天 POC 支援與結案報告，協助企業在正式導入前，即可實際驗證潛藏在日常營運中的資安風險。
有任何資安問題，歡迎隨時與NEITHNET團隊聯繫！
