在一般 IT 環境中，收到重大漏洞通報後修補、關票，流程通常相對清楚；但在工業控制系統（ICS）或營運技術（OT）環境中，即使同為 CVSS 10 的漏洞，從評估到處置的複雜度也可能大不相同。本文提供一套實務框架，用於判斷「這個漏洞在我的環境中是否真的可被利用」。
七步驟評估框架
第一步是確認資產確實存在且仍在運行。由於 OT 環境中的網路變動頻繁，設備可能已離線、搬遷或汰換，卻未被即時通報。實務上應比對漏洞掃描報告中的 IP 位址是否與現場位置一致，並釐清設備所處的網路區段，例如可程式化邏輯控制器（PLC）網路、經由網路位址轉換（NAT）隔離的網段，或是裝置彼此互通的平坦式 VLAN。
第二步，確認含漏洞的功能是否確實已安裝或啟用。漏洞掃描工具有時只會依據應用程式自回報的版本號，去比對已知漏洞清單，而非進行實際測試。曾有案例顯示，報告列出七個受影響的 Adobe 版本，但實際檢查裝置後卻找不到這些舊版本；重新開機後再測，這些發現也隨之消失。在 OT 環境中，若必須等到排程停機才能完成驗證，也不必因此中止其他評估步驟。
第三步，確認網路可達性與既有緩解措施。是否能從 IT 或辦公室網路連線到該資產？若可以，就代表存在可被利用的攻擊路徑。製造業環境中常見 OT 網路對外開放，或允許廠商遠端存取，這意味著資產可能可由網際網路直接存取。可透過 Shodan 等工具檢視公用 IP 的暴露情況，以評估實際可利用程度。
第四步，盤點並記錄既有的虛擬與技術緩解措施。若資產已透過防火牆規則或其他機制與外部隔離，這通常是「漏洞難以被利用」的第一項證據。建議的緩解方向包括：在 IT 與 OT 網路之間建立具備跳板伺服器（jump server）的非軍事區（DMZ），以增加驗證與控管層次；在防火牆存取控制清單（ACL）及裝置端防火牆上封鎖特定埠號或 IP；並確保所有帳號使用長詞組式強密碼、停用預設帳號。
第五步，追蹤漏洞的利用路徑與可行性。需要釐清該漏洞的利用條件：必須開啟哪些埠號？哪些服務或軟體必須正在運行？以 CVE-2025-27495（CVSS 9.8）為例，該漏洞預設開放 8000 埠；只要攻擊者能從網際網路對該埠發送資料，就可能取得控制權、清除伺服器資料，或橫向移動至 OT 網路。
第六步，評估是否採取風險接受並延後處置。並非所有漏洞都能立即修補，尤其是可程式化邏輯控制器（PLC）或已無廠商支援的舊版 Windows 系統。風險接受（risk acceptance）應透過正式流程，由 IT 與 OT 主管、營運與法務共同審視並留存書面紀錄，內容需包含風險描述、現有補償控制措施（例如強化監控、增加日誌與流量檢查）、各項控制措施的負責人，以及明確的重新評估期限。
第七步，若確認漏洞確實存在且可被利用，則安排修補作業。在 OT 環境中，修補前應先於測試或開發環境進行驗證，並準備近期系統備份，以降低修補導致系統不穩定的風險。
文件記錄是溝通的基礎
專家指出，七步驟框架的重點在於協助團隊判斷漏洞在現場是否具備「可被利用」的條件，而非僅依 CVSS 分數決定處置優先順序。即便同為 CVSS 10 的漏洞，若已透過多層防火牆與存取控制清單隔離在多層網路之後，實際風險仍可能不同於在平坦網路中以預設密碼直接對外暴露的情境。
此外，完整且可追溯的文件紀錄也是後續治理的基礎。包含資產清單、帳號狀態、密碼管理方式與各項緩解措施等資訊，不僅有助於後續追蹤與稽核，也能作為向管理層溝通現況與缺口的依據。
本文轉載自 DarkReading。
資料來源:資安人