# 弱點/漏洞管理 - 金融機構最佳實踐
Author: 陳詰昌
Email: [e-mail]

## 一、簡介
### 軟體錯誤類型
1. 漏洞(Vulnerability)
* 可被利用的弱點，攻擊者可以透過該漏洞獲得未授權存取、操控或中斷服務。
* 已確認可被利用、具實際風險的弱點，通常需要及時修補（patch）。
2. 弱點(Weakness)
* 程式碼、系統、或流程中存在的潛在缺陷，若被利用可能導致安全風險
* 弱點本身不一定能被利用，但若與攻擊技巧（exploit）結合，就可能成為 vulnerability
3. 缺陷(Flaw)
* 在系統設計階段出現的邏輯性錯誤，導致整個架構在本質上存在風險。
* 是「設計層面」的問題，與 bug 不同，不是 coding mistake，而是邏輯錯誤
4. 錯誤(Bug)
* 軟體中的實作錯誤，導致程式在某些情況下不按預期運作，不一定與安全有關，更多是功能或可靠性問題

### 漏洞管理的各層面
1. 治理面
* 漏洞管理政策、修補與例外政策、風險容忍度、資安治理架構與責任歸屬
2. 管理面
* 應建立明確的可執行規劃與流程，納入風險評估與年度資安計畫
* 資產分類、弱點評估機制、修補與緩解流程設計、修補時效要求、例外處理程序和追蹤機制
3. 維運面
* 定期（如每季）進行弱點掃描，重大變更或年度至少進行一次第三方滲透測試
* 掃描工具與結果管理
* 修補與回報

### 漏洞管理的合規面
* 目標：建立測試紀錄、修補流程、與稽核追蹤報告，以備主管機關查核

1. 上市上櫃公司資通安全管控指引
* 對核心資通系統辦理下列資安檢測作業，並完成系統弱點修補
* 定期辦理弱點掃描
* 定期辦理滲透測試
2. 金融機構辦理電腦系統資訊安全評估辦法
* 資訊安全評估作業項目
* 弱點掃描：
* 網路設備(防火牆開啟非必要通訊埠或設定有安全性弱點)、伺服器、端末設備及物聯網等設備
* 客戶端應用程式檢測(https、ftp弱掃）
* 滲透測試：
* 網路設備、伺服器及物聯網等設備且連線至Internet者
* 客戶端應用程式檢測
3. 金融機構資通安全防護基準
* 脆弱性管理
* 應定期進行弱點掃描，並針對其掃描或測試結果進行風險評估，針對不同風險訂定適當措施及完成時間，填寫評估結果及處理情形，採取適當措施並確保作業系統及軟體安裝經測試且無弱點顧慮之安全修補程式
* 網路管理
* 提供員工經由外部網際網路連線使用之應用系統，應定期執行弱點掃描、滲透測試及程式原始碼掃描並盡速完成弱點修補
4. PCI DSS 4.0
* 11.4 每年定期、重大升級或變更進行滲透測試

### 資安框架與標準與漏洞管理
1. NIST CSF 2.0
* Identify/Protect/ Detect /Respond
* ID.AM ： 確保弱點評估範圍涵蓋所有資產
* PR.IP ： 漏洞識別、風險評估與修補流程
* PR.MA ： 系統維護期間應一併處理弱點修補
* DE.CM ： 定期進行弱點掃描，掌握新興威脅
* RS.AN ： 辨識弱點是否未修補遭利用
2. ISO 27001:2022
* A 8.8 Management of Technical Vulnerabilities
* 確保組織能夠及時取得、評估並處理技術性弱點（vulnerabilities），防止其被惡意利用造成資訊安全事件。
* A 8.29 Security testing in development and acceptance
* 在開發與驗收階段，針對資訊系統進行適當的資訊安全測試，確保其安全性，防止弱點流入正式環境。
3. ISO 30111漏洞處理程序、NIST SP 800-40企業補丁管理指引

### 資安能力

## 二、漏洞管理介紹
### 漏洞來源
* 漏洞產生過程：
* 資訊系統：從概念與提案、需求收集、設計、開發、測試、部署完成，因不良設計、開發、配置或品質控制導致資訊系統元件產生錯誤
* 編程錯誤：邊界條件錯誤、緩衝區溢出
* 設計錯誤：權限管理不當
* 設定錯誤：弱密碼
* 第三方漏洞
* 漏洞管理：資訊資產弱點無法立即被發現或修補，因此必須透過識別、評估、修復等循環過程進行管理
* 主要影響因素：
* 複雜性：多層次軟體元件與硬體的複雜互動創造攻擊向量(attack vector)
* 連通性 (Communication)：IP 協定在開放網路中的誤用（原為封閉系統設計）。
* 互操作性 (Interoperability)：標準組件中的缺陷可能影響多個使用該組件的程式

### 漏洞衍生風險與挑戰
1. 重大經濟損失
* 客戶機密數據的外洩可能導致高額裁罰和訴訟
* 銀行法與個資法
2. 聲譽與收益損失
* 資安事件會直接影響公司收益並造成難以挽回的聲譽損害
* 對於社會大眾而言，不瞭解資安實際狀況，僅透過媒體傳播獲得資訊
3. 生產力損失
* 系統受損導致不可用，影響員工工作和企業生產力，甚至產生機會成本
4. 合規性
* 遵循日益嚴格的政府和行業法規與標準

### 漏洞管理
* 漏洞是指組織在資訊安全管理體系過程中存在的漏洞，包括技術與非技術方面：
* 技術：網路設備、軟體等
* 非技術：人員與流程等
* 漏洞管理（VM）程序是一種結構化方法，用於主動識別、評估、排序和修補系統、網絡和應用程式(技術面)中的安全漏洞
* 是一個週期性循環的過程，包括數據收集、數據分析及提出建議，目的在最大程度地減少組織的攻擊表面(Attack Surface)並降低遭成功駭侵的風險。

### 漏洞管理的目的與成功關鍵
1. 風險管理
* 風險減降：弱點管理是風險管理的一個細分領域，旨在發現和解決組織裡的弱點所帶來的風險，縮減攻擊面
* 技術性漏洞
* 配置錯誤
2. 符合法規
* 滿足PCI-DSS和NIST CSF、主管機關等監管要求
* 稽核準備
#### 成功的關鍵:
* 深入理解技術與流程的結合，兩者相輔相成
* 案例元大撞庫攻擊案
* 非技術問題

### 漏洞管理正確認知
1. 漏洞是不可避免的
* 系統是人設計一定會有漏洞
* 資源有限無法立即修補
* 產品EOS
2. 漏洞處置是風險為本
* 風險評估結果來決定優先順序
* RISK=Threat x Vulnerability x Impact
* CVSS、KEV、EPSS(Expolit Predicition Scoring System)、VISS(Vulnerability Impact Scoring Systm)
3. 漏洞發現與處置分離
* 發現（廠商）與修補（產品使用者）是持續對抗的過程
4. 修補後披露
* 披露同時應該提出解決方案

### 資安緩解措施常治標不治本
* 資安產品(FW、WAF)常被用作暫時降低風險的手段，但若不從根本上修復漏洞，最終仍會被攻破
* 金融業需從被動防禦轉向主動修復漏洞

## 三、漏洞管理框架與標準
### 漏洞管理框架
1. PDCA
2. P2DR: Policy、Protect、Detect、Response
3. OVMG (Owasp Vulnerability Management Guide)
* 檢測循環：漏洞檢測範圍（Scope）、優化工具(Tools)、漏洞檢測運行(Run Test)、檢測結果(Confirm Findings)
* 報告循環：資產分組(Asset Groups)、度量指標(Metrics)、稽核追蹤(Audit Trail)、報告(Reports)
* 修復循環：優先級確定(Prioritize)、漏洞修復(Remediation)、誤報識別(Investigate FP)、漏洞例外(Exceptions)

### 漏洞管理生命週期
1. Gartner
2. NIST

### 漏洞管理四大階段
1. ＝==分析後制訂策略==
* 制定實現組織目標的弱點管理策略
* 目的
* 範圍
* 角色與職責
* 工具、頻率、方法
* 策略應結合
* 漏洞管理流程、組織的需求和關鍵成功因素（技術與管理並重）
* 蒐集利害關係人的意見和支持
* 主要步驟
* 決定弱點管理範圍
* 決定弱點評鑑方法
* 提供資源支持活動
2. ==依政策制訂計畫==
* 策略轉化為計畫
* 包含規則和指南的計畫，供漏洞管理團隊參考
* 考量因素
* 利害關係人的期望
* 整合與善用現有資源
* 主要步驟
* 定義與建立計畫
* 定義有效性量測
* 定義訓練要求
* 決定對齊策略工具
* 識別弱點資訊的來源
* 定義角色與責任
* 洞管理不僅仰賴技術，需要組織支持與有效溝通
* 漏洞修補需要平衡業務優先級及資源限制
* 

* 利害關係人參與
* 建立計畫修正流程
3. ==落實執行計畫==
* 組織利用前階段所定的方法、工具和資源，並依據計畫中所定的時間框架，執行計畫降低組織面臨的漏洞風險
* 在執行漏洞分析和解決過程中，組織採取措施確保追蹤漏洞、蒐集資訊，並在適當的情況下啟動風險管理流程
* 步驟
* 提供培訓
* 進行漏洞評估活動
* 記錄已發現的漏洞
* 漏洞分類和排定順序
* 管理已發現漏洞的風險
* 確定漏洞處置的有效性
* 分析根本原因
4. ==評估及持續改善==
* 漏洞管理要求組織了解並評估兩個特定能力：
* 漏洞發現和相關漏洞分析
* 漏洞發現需要專業知識來評估關鍵服務的資產和相關流程
* 組織也必須確保漏洞發現能力涵蓋組織內相當全面的部分
* 漏洞分析是指確定漏洞的嚴重程度及其對組織及其關鍵服務的預期影響的能力
* 評估整體漏洞管理能力可確保分析和漏洞發現均符合組織的需求
* 步驟
* 決定專案狀態
* 收集並分析專案資訊
* 提升能力

## 四、漏洞管理執行
### 漏洞管理執行主要步驟
1. 資產清查（Asset Inventory）：
* 組織需要清楚了解其數位環境，包括所有連接的設備、軟體、伺服器和其他資產。 
* 自動化資產管理工具可以幫助維護最新的資產清單，並提供漏洞可見性。 
2. 漏洞掃描（Vulnerability Scanning）：
* 使用專用軟體掃描系統和網路，查找已知安全漏洞。 
* 掃描器可以識別過時的軟體、配置錯誤和未打補丁的系統等問題。 
* 報告會根據嚴重性對漏洞進行排序，幫助IT團隊優先處理最關鍵的威脅。 
3. 風險評估（Risk Assessment）：
* 根據漏洞的嚴重性和對組織的潛在影響進行評估。 
* 風險評估可以幫助組織了解哪些漏洞最有可能被利用，並優先進行修復。 
* 風險導向的漏洞管理平台可以提供更深入的分析和關鍵重點，幫助組織專注於最重要的事情。 
4. 修復和驗證（Remediation and Verification）：
* 對於已識別的漏洞，組織需要採取行動進行修復。 
* 這可能包括應用軟體更新、修補程式、更改配置，或實施額外的安全措施。 
* 修復後，需要驗證漏洞是否已成功緩解。 
5. 持續監控（Continuous Monitoring）：
* 使用SIEM（安全資訊和事件管理）工具等，持續監控安全事件。 
* 監控有助於及時發現新的威脅和漏洞利用，並及時作出反應。 
* 漏洞管理程式需要持續進行，以適應不斷變化的威脅形勢。 

### 漏洞識別、評估技術的多元性與應用
* 主動掃描 (Active Scanning)
* 運作原理： 產生網絡數據包主動接觸目標，探測其存在和漏洞
* 優勢：高擴展性，能夠從駭客視角審視網絡，潛在支持任意網絡設備
* 潛在影響： 可能消耗頻寬、佔用目標 CPU 資源，甚至導致服務中斷 (DoS)。頻寬消耗對 WAN 鏈路影響顯著
* 被動網絡分析 (Passive Network Analysis)
* 運作原理： 安裝設備監聽和分析網絡流量副本以發現漏洞，類似入侵檢測系統 (IDS)
* 優勢： 無需與網絡交互，持續進行，可發現隱匿主機，提供網絡拓撲資訊
* 限制： 安裝受限於交換機能力 (如 SPAN)，可能增加交換機 CPU 負載，且對漏洞檢測能力有限
* 代理 (Agent-based Scanning)
* 運作原理： 軟體安裝在目標主機上，持續監控系統狀態並執行漏洞評估
* 優勢： 可擴展性高，幾乎不涉及額外硬體部署，不佔用網絡頻寬。可發現網絡上無法發現的漏洞，即使系統未聯網也可運行
* 挑戰： 可能與目標機其他應用衝突，本地安全權限不足，可能導致中斷。在虛擬環境中，多個代理運行會加倍影響底層硬體性能
* 混合與推斷方法 (Hybrid & Inference Methods)
* 結合多種技術可更全面應對漏洞
* 推斷掃描則透過分析為其他目的獲取的數據來檢測漏洞，例如利用配置管理數據庫 (CMDB) 的數據
### 漏洞評估標準化與量化
* 共通漏洞與曝險 (CVE)
* 由 MITRE 發布的公開漏洞通用名稱列表，為漏洞識別提供了一定程度的標準化
* 每個 CVE 都被分配一個唯一識別碼，提供統一描述和附加資訊來源的引用
* 重要性： 促進不同廠商間的資訊共享，減少混淆
* 共通漏洞評分系統 (CVSS)
* 提供評估漏洞影響和其基本特徵的標準框架。
* 分數範圍 0-10，更精確反映風險，並可調整（基本面向、時間面向、環境因子）。
* Critical:9.0-10.0
* High:7.0-8.9
* Meduime:4.0-6.9
* 重要性： 為漏洞嚴重性提供一致的量化標準，有助於優先級排序和風險溝通。
* CISA KEV（Known exploited Vulnerability）
* 開放漏洞評估語言 (OVAL)
* 使用 XML 記錄機器漏洞狀態的結構化語言
* 重要性： 規範漏洞資訊交換，有助於不同工具間的互操作性，例如配置管理工具和安全事件與事件管理 (SEIM)
* 安全內容自動化協定 (SCAP)
* 整合 CVE、CVSS、CPE 、XCCDF和 OVAL 的標準集合，用定義前述協定如何自動配合

## 五、發現漏洞後管理
### 報告、分析與決策支援
* 發現報告： 提供環境中目標數量、類型、配置、位置和價值資訊
* 評估報告： 包含資產價值（更換成本、收益價值）和物理風險等級，有助於確定修復優先級
* 審計報告： 顯示當前審計狀態、進度及資源使用情況
* 趨勢分析報告： 監測漏洞數量、網路風險隨時間的變化，幫助識別過程缺陷
* 控制圖 (Control Charts)： 透過統計方法（如 UCL/LCL）監測漏洞分數隨時間的變化，識別特殊原因變異，避免對正常變動的過度反應
* 漏洞群報告 (Swarm Reports)： 識別危害程度低但聚集起來可能造成嚴重威脅的漏洞，例如大量開放寫入權限的文件共享。這對金融業防範內部威脅尤為重要
* 合規性報告： 顯示系統與既定策略和標準的符合程度，對金融業的監管要求至關重要

### 漏洞發現後作為

### 漏洞管理指標
1. 平均採取行動時間：提出應對方法或計畫
2. 平均修復時間：與SLA相關
3. 風險分數：CVSS等因素
4. 接受風險評分：風險評鑑單不修補的漏洞
5. 平均漏洞年齡：瞭解漏洞揭露到發現時間，可供制訂SLA參考
6. 內部與外部曝險：對外服務與內部服務曝險不同，應差異考量
7. 復發率：可能組態配置基準出錯
8. 總風險趨勢：整體漏洞風險是成長或下降
9. 資產清單/覆蓋範圍
10. 服務水平協議（SLA）

### 有效漏洞管理建議

### 漏洞管理最佳實踐
* 自動掃描及修補程序：使用自動化工具來識別漏洞識別，補丁管理和合規性報告
* 補丁管理計畫：制定定期時間表，以應用補丁程序和軟件更新以最大程度地減少曝光率
* 風險為本方法：將資源集中在解決對關鍵系統構成最高風險的漏洞上
* 第三方安全專家參與：進行滲透測試或僱用獨立安全顧問進行公正評估
* 事件應變準備：確保計劃得出迅速應處關鍵漏洞的計劃
* 定期審核和評估：通過定期審查和更新評估程序的有效性

### 漏洞管理與ITSM流程的整合
* 事件管理 (Incident Management)：
* 漏洞被發現後可自動產生事件單追蹤解決，確保按服務水平協議 (SLA) 規定時間修復
* 問題管理 (Problem Management)：
* 針對重複發生或根本原因不明的漏洞事件，以避免其演變為重大問題
* 組態管理 (Configuration Management)：
* 漏洞管理系統為組態管理數據庫 (CMDB) 提供大量組態數據，幫助監測組態設定項目 (CI) 的變化及其對服務的影響
* 變更管理 (Change Management)：
* 漏洞管理系統可自動發送漏洞詳情至變更管理系統，啟動標準化修復流程
* 服務水平管理 (Service Level Management)：
* 漏洞管理服務應有自己的 SLA，量化其在發現和修復漏洞、降低風險方面的表現

### 策略性的漏洞與風險評估
* 資產估值：
* 透過貨幣金額或分級（如低、中、高）評估資產價值，以決定修復優先級和安全投資。
* 資料分級 (Data Classification)：
* 決定對特定目標採取何種安全控制手段的重要基礎，確保敏感數據得到適當保護。
* 管理外部因素：
* 採用模塊化和鬆耦合的 IT 組件和程序設計，提高組織面對外部環境變化的靈活性和適應性。
* 控制內部漏洞：
* 識別因業務模式、供應鏈缺陷或組織複雜性等內部策略錯誤導致的漏洞

## 六、未來挑戰與趨勢
* 自動化與整合的挑戰
* 實現完全自動化需要克服多種數據格式、系統介面和流程差異
* 與現有 IT 流程（如 Patch Management、NAC、SEIM、IPS）的深度整合仍需努力
* 運行環境的變化
* 持續監控與資產變動： 快速變化的 IT 環境中，如何持續、準確地更新資產清單和漏洞狀態是一個挑戰
* 趨勢
* 加強跨領域整合（如與 CMDB、SEIM、IPS 結合），提供更全面的風險視角
* 提升用戶自定義漏洞參數功能，支持開放標準 (OVAL)，以提供更精確、客制化的檢測