企業資訊安全營運管理之績效評估

國立臺灣大學管理學院碩士在職專班資訊管理組 碩士論文

Executive MBA Program in Information Management College of Management

National Taiwan University Master Thesis

企業資訊安全營運管理之績效評估

IT Security Operations Management: Performance Evaluation

黃瓊瑩

Huang Chiung-Ying

指導教授：孫雅麗 博士 Advisor: Yeali S. SUN, Ph.D.

中華民國 100 年 1 月

January, 2011

誌 謝

從事資訊安全領域的工作，已經快 20 年了，近年專注於資訊安全事件即時偵 測與防禦工作，透過 SOC (Secuirty Operations Center) 全年無休進行 7 x 24 監控服 務，及早發現資訊安全風險並處理資訊安全問題。在實際工作中，企業經營者均 體認資訊安全對現代企業 IT 營運的重要性，但對於資訊安全防護上的投資，是否 獲得合理的效益，卻沒有一個客觀評估的方法。

本論文整理實務上能客觀評估資訊安全績效的方法，加以分類並設計可行績 效指標，雖然工作上累積的資料非常多，但要有系統整理才發現並不容易，尤其 只能利用公餘的時間進行，進度非常緩慢。感謝指導老師孫教授的指導，老師鼓 勵除了技術內容以外，內容盡量要有「高階管理者思維」，可作為管理者評估效益 與決策的最佳指標。要達到此目的，最直接具體的方法是將評估方式轉換為＄

(dollar sign)，可有效回應經營階層關心的問題。

本論文中將實際案例換算成實際的財物損失，對我個人是突破也是最大收 穫。嘗試用財務報表的數字與相關法律來解釋投資效益的問題，是指導老師與台 大 EMBA 課程帶給我的成長，很高興可以踏出第一步，並感謝恩師孫教授的悉心 指導與鼓勵。

黃瓊瑩 謹識 于台大管理學院 中華民國一百年一月

中文摘要

企業經營者均體認資訊安全對企業 IT 營運的重要性，但投資在資訊安全防護 上的資源，是否得到合理效益，如何評估資訊安全營運管理的績效？由於資訊安 全涉及複雜的技術與管理問題，且攻擊手法與變化甚為快速，每一個環節都有可 能衍生風險，過去沒有問題的 IT 環境，不保證現在或未來仍能固若金湯、安全無 虞。企業除了自行聘用資訊安全專長的員工負責企業本身的安全，也可以選擇委 外專業的資訊安全服務廠商，提供企業資訊安全服務。

本論文探討資訊安全營運管理的技術架構，並設計「技術管理」與「營運管 理」的績效評估指標，用來衡量資訊安全營運管理表現的良窳。這些指標可以當 作日常營運管理的工具，隨時了解整體營運管理的表現，及時採取各種矯正或改 善措施，控制資訊安全風險。本論文進一步依照所設計績效評估指標，就真實發 生的個案，計算實際金錢損失以衡量投資效益。

各 項 績 效 評 估 指 標 ， 依 照 Specific, Measureable, Attainable, Repeatable, Time-dependent 的 S.M.A.R.T 原則設計，內容均為量化的單位如小時、次數、百 分比等，避免個人主觀 (Subjective) 認定不同，而有不同判斷。各項指標可以合理 的代價（時間、金錢、人力）有效取得，具備可操作性。有了適當的績效評估指 標，本論文運用真實個案，嘗試回答以下管理者關心的問題。

 投入的資訊安全成本，是否獲得「合理效益」 ？

 要「投資多少」資源，才能達到安全的程度？

 資訊安全的狀態「比」過去好嗎？

關鍵字：資訊安全防護管理中心、績效評估指標、SMART 原則

THESIS ABSTRACT

SENIOR PUBLIC ADMINISTRATION COLLEGE OF MANAGEMENT NATIONAL TAIWAN UNIVERSITY

NAME： Chiung-ying, HUANG MONTH/YEAR：JANUARY, 2011 ADVISER：Yeali S. SUN, Ph.D.

TITLE：IT Security Operations Management: Performance Evaluation

Information Security is a pivotal component in modern business activities without questions. Enterprise should exercise due care to perform the ongoing maintenance necessary to keep IT systems in proper working order, or to abide by what is commonly expected in a situation. IT head is responsible to implement countermeasures to provide protection from those threats. By developing and implementing security policies, procedures, and standards, shows that a company has taken responsibility for the activities that take place within the corporation and has taken the necessary steps to help protect the company, its resources, and employees from possible threats. It is especially important if the due care situation exists because of a contract, regulation, or law.

However, there’s been a lack of well-defined performance evaluations indexes to understand the return of investment regarding information security operations. The thesis designs “technical management” and “operational management” performance indexes to help enterprise top management level to evlautie the return regarding the money paid for security operations. Moreover, real security incident cases are discussed and the financial losses are calculated as well to response the concerns from the top management viewpoints:

 Am I spending the right amount of money?

 How much should I pay for information security?

 Am I better off than I was this time last year?

The indexes designed in the thesis are evaluated to a number, percentage or time elapsed. They are contextually specific, measureable, attainable (cheap to gather) repeatable and time-dependent. In addition, all of the indexed are clear, unambiguous and can be consistently measured without subjective distortion.

Keywords：Security Operations Center, Key Performance Indicator, Performance Evaluation Indexes, SMART Criteria

目 錄

第一章 緒 論 ... 1

第一節、 研究背景與動機 ... 1

第二節、 研究目的 ... 2

第二章 文獻探討 ... 4

第一節、 COBIT 簡介 ... 4

一、 聚焦業務 (Business-Focused) ... 4

二、 流程導向 (Process-Oriented) ... 5

三、 控制為基礎 (Control Based) ... 6

四、 以度量驅動 (Measurement-Driven) ... 7

五、 COBIT 與績效評估指標 ... 8

第二節、 CVSS –共通弱點評分系統 ... 9

一、 概述 ... 9

二、 內容 ... 9

第三節、 銀行業資訊安全損失估算方法 ... 11

一、 巴塞爾資本協定與作業風險 ... 11

二、 我國對作業風險損失的認列規範 ... 13

第四節、 個人資料保護法的罰則 ... 15

一、 概述 ... 15

二、 個人資料管理規範與罰則 ... 15

第三章 SOC 資訊安全服務概述 ... 17

第一節、 服務概述 ... 17

第二節、 SOC 平台之技術架構 ... 18

一、 前端事件收集器（FSA） ... 20

二、 SIEM/SIEM 系統 ... 20

三、 營運管理系統 ... 20

第三節、 組織與人力 ... 21

一、 維運組織範例 ... 21

二、 專業支援組織 ... 22

第四節、 資安事件管理作業 ... 24

一、 資安事件之通報 ... 24

二、 資安事件通報之回饋與改善 ... 24

三、 事件之處理（追蹤、鑑識與復原） ... 25

第五節、 SOC 營運技術與智慧 ... 29

第六節、 SOC 績效評估架構 ... 31

第四章 技術管理指標 ... 32

第一節、 組態管理 ... 32

第二節、 弱點管理 ... 33

第三節、 補強管理 ... 35

第四節、 閘道管制 ... 36

一、 閘道安全設備 ... 36

二、 技術內涵與度量指標 ... 38

第五節、 防毒管理 ... 44

一、 防毒軟體部署涵蓋度 ... 44

二、 病毒健康狀態評分 ... 45

第六節、 技術管理指標彙總 ... 47

第五章 營運管理指標 ... 48

第一節、 風險研判與分級 ... 48

一、 分級研判的不同階段 ... 48

二、 事件分級計算方法 ... 50

第二節、 風險等級指標 ... 56

一、 總風險與總避險指標 ... 56

二、 風險收斂比 ... 57

第三節、 關聯分析規則品質指標 ... 58

一、 規則數量 ... 59

二、 規則觸發數量 ... 60

三、 規則停用數量 ... 60

四、 規則自動化數量 ... 63

五、 半自動規則數量 ... 63

第四節、 事件通報質、量指標 ... 64

一、 事件通報頻率的控制 ... 64

二、 事件通報數量 ... 66

三、 事件通報時效 ... 67

四、 事件通報精準度 ... 68

第五節、 事件處理質、量指標 ... 69

一、 中繼站數量 ... 69

二、 新種惡意程式數量 ... 71

三、 解決時效 ... 72

第六節、 平台管理指標 ... 73

一、 可用度（Availability） ... 73

二、 容量管理指標（Capacity） ... 74

第七節、 技術管理指標彙總 ... 76

第六章 績效指標彙整與投資效益分析 ... 78

第一節、 績效評估指標彙整 ... 78

第二節、 與 COBIT 控制目標比較 ... 79

第三節、 績效評估指標與個案研究 ... 81

第四節、 案例分析：銀行 ... 82

一、 資訊安全監控架構 ... 82

二、 資安事件實例 ... 83

三、 業務影響分析 ... 84

四、 資訊安全指標分析 ... 89

五、 綜合討論 ... 91

第五節、 案例分析：醫療機構 ... 93

一、 網站弱點與個資洩漏 ... 93

二、 業務影響分析 ... 94

三、 綜合討論 ... 95

第七章 結論與建議 ... 97

第一節、 研究結論 ... 97

一、 客觀可行的績效衡量指標 ... 97

二、 回答管理者關心的投資效益問題 ... 97

三、 盡責管理 (Due Care)的證明 ... 97

第二節、 後續研究建議 ... 98

圖目錄

圖 1. 基本 COBIT 結構 ... 5

圖 2. COBIT 四個領域的關聯 ... 6

圖 3. COBIT 框架 ... 7

圖 4. 目標與成果度量 ... 8

圖 5. 績效驅動範例 ... 8

圖 6. CVSSMETRICS GROUPS ... 10

圖 7. CVSSMETRICS AND EQUATIONS ... 10

圖 8. SOC 邏輯功能圖... 18

圖 9. 四層式資料處理架構圖 ... 19

圖 10. SOC 維運人力... 21

圖 11. SOC 分工... 22

圖 12. 通報回饋改善網頁 ... 25

圖 13. ISO/IECTR18044 資安事件作業流程 ... 26

圖 14. 資安事件通報與處理 ... 26

圖 15. SANS 事件處理程序 ... 27

圖 16. 縱深防禦架構 ... 30

圖 17. 績效評估構面 ... 31

圖 18. 弱點掃瞄流程與績效評估指標 ... 33

圖 19. 弱點分佈指標範例 ... 34

圖 20. 防火牆資料分析與 IDS 交叉分析 ... 39

圖 21. 入侵偵測系統資料分析邏輯 ... 39

圖 22. 主要事件主機之事件內涵 ... 40

圖 23. 防火牆/IDS 連線數量統計 ... 41

圖 24. 防火牆連線來源主機排序－允許、阻擋 ... 41

圖 25. 防火牆阻擋連線排序統計－主機、通訊埠 ... 42

圖 26. IDS 攻擊來源、對象排序統計 ... 42

圖 27. 連線來源/目標主機排序與防火牆阻擋/允許連線目標 PORT排序 ... 43

圖 28. 防毒部署涵蓋度與感染率 ... 44

圖 29. 病毒健康評分範例 ... 46

圖 30. 資安事件風險研判與分級 ... 48

圖 31. 系統分析事件優先度邏輯 ... 50

圖 32. PRIORITY判定原則 ... 54

圖 33. 風險等級指標 ... 56

圖 34. 關聯性規則品質指標 ... 59

圖 35. 關聯性規則數量折線圖 ... 59

圖 36. 關聯性規則數量比較圖 ... 59

圖 37. 自動通報數量統計 ... 63

圖 38. 規則觸發時機控制 ... 64

圖 39. 事件通報質、量指標 ... 65

圖 40. 通報數量統計圖 ... 66

圖 41. 通報類別統計圖 ... 66

圖 42. SOC 事件通報時效... 67

圖 43. 事件誤報率 ... 68

圖 44. 事件處理質、量指標 ... 69

圖 45. 中繼站、黑名單 IP 成長趨勢圖 ... 71

圖 46. 中繼站管理流程 ... 71

圖 47. 新種惡意程式數量 ... 72

圖 48. 事件處理時效分析表 ... 73

圖 49. 系統可用度統計表 ... 74

圖 50. 系統可用性統計 ... 75

圖 51. SOC 營運流程與績效指標關係圖... 77

圖 52. 案例一資安監控架構 ... 82

圖 53. 清晨首度發現 WORM蔓延... 83

圖 54. WORM擴大蔓延... 83

圖 55. CONFILCER說明 ... 84

圖 56. 手續費影響時段分析 ... 85

圖 57. 事件通報數量趨勢圖 ... 92

圖 58. 攻擊流程說明 ... 93

圖 59. 病歷處方與診斷資料 ... 94

圖 60. 事件通報數量趨勢圖 ... 96

表目錄

表 1 COBIT 資訊準則 (INFORMATION CRITERIA) ... 5

表 2 COBIT 四大領域與說明 ... 5

表 3 營運管理系統與 ITIL 服務流程關係表 ... 20

表 4 通報對象表 ... 24

表 5 每一主機弱點指標 ... 34

表 6 閘道安全控制設備 ... 36

表 7 資安警訊通報事件列表 ... 40

表 8 病毒評分試算 ... 45

表 9 技術管理指標彙總表 ... 47

表 10 優先權計算加權變數 ... 50

表 11 交叉分析決定事件最終優先等級 ... 52

表 12 規則調整表 ... 60

表 13 規則觸發數量統計表 ... 61

表 14 事件處理結果範例 ... 62

表 15 事件觸發條件 ... 64

表 16 通報時效與人力負荷分析表 ... 67

表 17 系統可用度 ... 73

表 18 績效指標總表 ... 78

表 19 COBIT-PLAN &ORGANIZE與績效指標關係 ... 79

表 20 COBIT–ACQUIRE &IMPLEMENT 與績效指標關係 ... 80

表 21 COBIT–DELIVER &SUPPORT與績效指標關係 ... 80

表 22 COBIT–MONITOR &EVALUATE與績效指標關係 ... 80

表 23 監控內容與費用 ... 82

表 24 手續費淨收入 (單位千元) ... 85

表 25 ATM 手續費損失估算 (單位元) ... 86

表 26 99 年 9 月底金融機構自動化服務概況表 ... 87

表 27 99 年第二季損益表 ... 88

表 28 各項指標應用分析 ... 90

方程式目錄

方程式 1: 防毒部署涵蓋度 ... 44

方程式 2: 病毒健康狀態評分 ... 45

方程式 3: 優先權計算 ... 51

方程式 4: 嚴重度影響優先權計算 ... 52

方程式 5: 資產重要性影響優先權計算 ... 52

方程式 6: 總風險指標 ... 56

方程式 7: 總避險指標 ... 57

方程式 8: 風險收斂比 ... 57

方程式 9: 系統可用度 ... 73

方程式 10: 銀行手續費影響計算式 ... 85

方程式 11: 斷線期間手續費淨影響 ... 88

第一章 緒 論

第一節、 研究背景與動機

電腦運用普及與網際網路的蓬勃發展，帶給企業急速而巨大的衝擊，也改變 了現代人們的生活模式。隨著數位經濟時代來臨，e 化是企業跨足國際市場的趨 勢，企業為了符合全球化商業脈動，營運資訊的數位化，更是不可缺少的競爭力。

早期電腦系統多為封閉式環境，用途多為專屬功能（Proprietary System）其資訊安 全顧慮相對較低，然而隨著資訊便利與網際網路多元化的應用，各種資訊安全問 題層出不窮，資訊安全變成令人非常擔憂的問題。對資訊化依賴愈高，一旦電腦 系統或資料檔案發生資訊安全問題，往往造成營運中斷、企業機密外洩、顧客個 資外流、衍生法律訴訟等難以彌補的損失。因此沒有資訊安全，就等於沒有資訊 化，其重要性可想而知。

企業或政府機關，為了解決資訊安全的問題，編列預算購買各種資訊安全設 備，聘請專業人員管理、維護、處理各種資訊安全事件，投入的資源非常龐大。

依據主計處統計，2008 年我國投入資安部分的經費逾 71 億元，占資訊總投資的 5.20％，較 2007 年增加逾 2 億元[13]。

但如何看待或衡量資訊安全投資的效益呢？在真實的世界裡，企業高階管理 者（CEO）與資訊安全負責人（CSO）往往以不同構面來評估資訊安全投資的績 效，最明顯的差異是溝通語言不同。CSO 關心的是威脅、風險、控制等技術內容，

確認各種安全風險是否有效控制；CEO 關心的是成本、生產力與投資效益（ROI）。 同一個企業不同角色人員，對於公司目標雖然無明顯差異，僅就資訊安全效益的 衡量，就很難有共通、統一與客觀的衡量方法，遑論不同企業、不同領域如何評 估投資是否達到預期效益，企業高階管理階層需要了解資訊安全營運管理問題有：

 投入的資訊安全成本，是否獲得「合理效益」 ？

 要「投資多少」資源，才能達到安全的程度？

 資訊安全的狀態「比」過去好嗎？

本論文根據實務經驗，設計評估企業資訊安全營運管理績效的方法，客觀的 計算、衡量管理績效，並回答上述的管理問題。

第二節、 研究目的

資訊安全績效評估須要有方法衡量，沒有衡量指標，就無法有效的管理 (You can’t manage what you can’t measure)，本論文嘗試就技術面、營運面，設計資訊安 全績效評估架構(Framework)，作為企業衡量資訊安全績效良窳的依據。績效評估 的項目，搭配適當的測量指標(Security Metrics)，以量化的方式來呈現各評估項目 表現，並具備「S.M.A.R.T.」原則。S.M.A.R.T.原則是進行成員組織、目標制定和 控制，達到更好工作績效的方法，由管理學大師彼得·杜拉克於 1954 年首先提出。

在 1981 年 12 月《管理評論》（Management Review），是目前最早與更完整的 S.M.A.R.T.原則探討文獻[5]，廣泛應用在企業界。

S.M.A.R.T.原則中的五個字母分別對應了五個英文單詞：Specific（明確性）、 Measurable（可衡量性）、Attainable（可達成性）、Relevant（相關性）和 Time-bound

（時限性）。

 Specific（Contextually Specific) - 與決策者所關心的事項具體與明確相 關，並可據以採取對應的行動或做成決策。

 Measurable（Number, Percentage, Unit of Measure） - 可測量的量化內 容，並有對應量測單位如小時、次數、百分比等。

 Attainable（Gather under reasonable costs）-蒐集原始資料經過整理、分 析後，可以依照計算出來的結果滿足所關心的問題，具備實務上的可操 作性。Attainable 另一層的意思，是指在合理的代價（時間、金錢、人力）

下可有效取得。

 Repeatable（Consistently Measured）- 可穩定、長期蒐集與計算，不同 人重複相同步驟，可以得到相同的結果並避免個人主觀 (Subjective) 認 定不同，而有不同判斷。

 Time-Dependent（Single-point-in-time view）- 量測的內容是某一時間點 的表現，與時間直接相關。

資訊安全測量指標，需要有對應的資訊安全營運管理服務來滿足，此服務包 含軟、硬體、人員與流程等。依據企業本身的規模、安全要求與人力等，服務的 提供者可以是「企業本身（自建）」、「部分委外（協同維運）」或「完全委外」等 不同模式。專責提供資訊安全服務的中心，稱為資訊安全防護管理中心 (SOC –

Security Operation Center)，是以資安監控防護平台為基礎，進行 7x24 資安防護維 運，監控異常狀況，處理突發攻擊事件的專責單位。

SOC 收集資安監控日誌資訊：如防火牆、入侵偵測系統、防毒系統等，然後 進行事件分析、通報、調查與處理等。當 IT 系統大量導入，成為企業活動命脈時，

SOC 資訊安全服務是企業保障資訊安全的方法。不管是「自建」、「協同維運」或

「完全委外」，其所需要的安全績效衡量指標應該相同，作為投資效益衡量的依據。

第二章 文獻探討

第一節、 COBIT 簡介

COBIT 是美國資訊系統審計與控制協會（ISACA）和 IT 治理委員會（IT Governance Institute - ITGI）於 1992 年草擬，全名為：Control Objectives for Information & related Technology（簡稱 COBIT）[3]，是一系列關於 IT 治理（IT Governance）最佳實務的管理框架（Management Framework）。COBIT 為企業管理、

稽核和 IT 人員提供通用的測量、呈現和處理方法，幫助企業使用 IT 技術時，可以 有效進行治理與控制，以滿足企業的經營目標（Business Goal）。COBIT 協助使用 者認識和瞭解企業資訊系統，以決定系統的安全性，及透過資訊治理來保護企業 資訊資產。2007 年最新 4.1 版中，提出 IT 治理開放性框架及相關工具集，協助組 織透過控制、度量、標準來管理 IT 資源，提升 IT 價值並透過適當的監控作業，確 保各種控制均如預期運作，降低 IT 風險。為了滿足經營目標，COBIT 的主要特性 有「聚焦業務」、「流程導向」、「以控制為基礎」、「以度量驅動」，以下逐項說明。

一、 聚焦業務 (Business-Focused)

COBIT 架構訴求對象不侷限於 IT、稽核人員或使用者，更重要的還包含了管 理指引與業務流程的負責人(Business Process Owner)。為了提供企業滿足經營目標 所需之資訊，企業必須投資與管理資訊資源，並透過結構化的流程與服務，確保 資訊的交付（圖 1）。

Business Requirements

Business Requirements

IT Resources

IT Resources

IT Process

IT Process Enterprise

Information Enterprise

Information COBIT

drive the investment in

that are used by to deliver

which responds to

圖 1.基本COBIT結構

管理與控制資訊的提供，是 COBIT 確保與經營目標一致的核心，且要兼顧品 質、監督、安全等需求，資訊必須符合七項資訊準則（表 1 ）。

表1 COBIT 資訊準則 (Information Criteria)

準則 內容

有效性（Effectiveness） 一致、適用、及時與正確提供營運活動相關的資訊 效率（Efficiency） 最佳運用資源，以最具生產力與經濟效益提供資訊 機密性（Confidentiality） 保障企業機密，不受未經授權揭露

完整性（Integrity） 符合企業預期的準確與完整內容 可用性（Availability） 確保企業維持穩定不中斷的可用性 遵循性（Compliance） 符合企業與法規之規範

可靠性（Reliability） 提供公司治理與組織運作的資訊

二、 流程導向 (Process-Oriented)

COBIT 過程及監控範圍包含四個部分（表 2 ）。

表2 COBIT 四大領域與說明

領域 說明 管理議題

計畫與組織 用來找出為達成經營目標最  IT 是否與經營目標一致

Plan and Organize

佳方案的 IT 策略

（Strategy/Tactics）與所關心 事項，並透過不同的構面計 畫、溝通與管理來完成。

 資源利用是否最佳化

 企業成員是否均瞭解 IT 目標

 IT 風險是否清楚且有效管理

 IT 品質是否適當滿足企業需求 獲得與建置

Acquire and Implement

透過 IT 策略的瞭解，辨認、

發展、獲得 IT 解決方案，並 建置與整合到業務流程中。

 新方案是否滿足經營需求

 新方案是否如期、如預算的交付

 新系統是否如預期正確運作

 異動不會干擾既有業務運作 交付與支援

Deliver and Support

服務交付、安全與不中斷管 理、服務支援、設備與資料 管理。

 服務交付是否合乎業務優先次序

 成本是否最優化

 有生產力與安全的使用 IT 系統

 適當的資訊安全保護(C.I.A.) 監控與評估

Monitor and Evaluate

透過常態性的監控與評估控 制需求，確保 IT 流程的品質 與符合度。

 IT 效能有效監控並提早發現問題

 確認內部控制有效性與高效率

 IT 效能連結經營目標

 適當的資訊安全保護(C.I.A.)

三、 控制為基礎 (Control Based)

COBIT 訂定 34 個控制目標，並將 210 個相關工作項目組織起來（圖 3）。

圖 2.COBIT四個領域的關聯

•DS8 Manage Servie Desk and Incidents.

•DS9 Manage the configuration.

•DS10 Manage Problem

•DS11 Manage data.

•DS12 Manage the physical environment.

•DS13 Manage operations.

•Applications

•Information

•Infrastructure

•People

Monitor &

Evaluate

Information Criteria

Plan &

Organize

Acquire &

Implement Deliver &

Support

•Effectiveness

•Efficiency

•Confidentiality

•Integrity

•Availability

•Compliance

•Reliability

IT Resources

Governance Objectives Business Objectives

•ME1 Monitor and evaluate performance.

•ME2 Monitor and evaluate internal control.

•ME3 Ensure compliance with external requirements.

•ME4 Provide IT governance.

•DS1 Define and manage service levels.

•DS2 Manage 3rd party services.

•DS3 Manage performance capacity

•DS4 Ensure continue service.

•DS5 Ensure system security.

•DS6 Identity and allocate cost.

•DS7 Educate and training users.

•AI1 Identity automated solutions.

•AI2 Acquire and maintain application software.

•AI3 Acquire and maintain technology infrastructure.

•AI4 Enable operation and use.

•AI5 Procure IT resources.

•AI6 Manage change.

•AI7 Install and accredit solutions and changes.

•PO1 Define strategic IT plan.

•PO2 Define the information architecture.

•PO3 Determine technological direction.

•PO4 Define IT process, organization and relationships.

•PO5 Manage IT investment.

•PO6 Communicate management aims and direction.

•PO7 Manage IT human resources.

•PO8 Manage quality

•PO9 Assess and manage IT risks

•PO10 Manage Projects.

圖 3.COBIT框架

四、 以度量驅動 (Measurement-Driven)

經營目標由上而下定義，再決定需要多少 IT 目標來達成；而 IT 目標是由一個 或多個作業流程來實現，因此 IT 目標協助定義不同的作業流程目標，作業流程目 標會由多個活動來滿足（圖 4）。度量這些目標的有以下兩種類型：

 成果度量 (outcome measure) – 判斷目標是否達成，一般是在相關結果已 經發生之後，也可稱為落後指標（lag indicators）。

 績效度量 (performance measure) – 度量目標達成的可能性高低，是在結 果已經產出之前的度量，也可稱為領先指標（lead indicators）（圖 5）。

圖 4.目標與成果度量

圖 5.績效驅動範例

五、 COBIT 與績效評估指標

COBIT 是一個較為完整與廣泛的管理框架，且有流程、控制與度量的概念，

對於 SOC 的績效度量，有較多可以參考的地方。但 COBIT 是廣義的 IT Governance 框架，不是單獨針對 IT Security Govarnmance 的管理框架。但是 IT Security Governance 是 IT Governance 是的ㄧ部份，有關 IT Governance 所需注意與管理的 項目，均可做為 IT Security Governance 的參考。

本論文之績效指標，將比對 COBIT 的控制目標（參考第六章 第二節、與 COBIT 控制目標比較），檢視本論文設計指標的完整度與涵蓋情況。

第二節、 CVSS –共通弱點評分系統

一、 概述

CVSS (Common Vulnerability Scoring System)是由美國國家基礎建設諮詢委員 會 (NIAC) 委託製作，並且受到 Cisco、 Symantec 、ISS 和 eBay 等支持。CVSS 與一般專用的評估系統不同，它是使用標準的數學方程式，來判定威脅的嚴重性，

列入評估標準的因素，還包括安全弱點能否被遠端利用，或是攻擊者是否需要登 入，才能利用此一弱點。為數不少的商業點腦安全業者和非營利組織已經發展出 許多可列出系統弱點資料的先進系統工具。

IT 管理必須在許多不同的硬體和軟體平台間識別和評估弱點。他們需要為那 些會構成最大風險的弱點定義出優先權和補救。但是，有這麼多次的修復，每次 都用不同的方式得到不同的弱點嚴重分數，IT 管理者如何能將這些堆積如山的漏 洞數據轉換為可管理的有用資訊？共通弱點評分系統（CVSS 的）是一個開放的框 架內，它具有以下優點：

 Standardized Vulnerability Scores:

當一個組織將那些不同軟體和硬體平台的弱點正規化的時候，它可以使用一 個單一的弱點管理政策。這一個政策可能類似於一個服務水平協議（SLA），指出 一個特別的弱點必須要多快被驗證和補救。

 Open Framework:

“什麼樣的特性讓這個弱點得到這個分數？為什麼會跟昨天公佈的分數不 同？＂，根據 CVSS，任何人都可以看到個別的特性來推算分數。

 Prioritized Risk:

當環境的分數被計算出來之後，其弱點的分數就代表著這個組織真正的風險。

使用者可以瞭解這些弱點之間的重要性。

二、 內容

CVSS 度量由三個度量群組組成：Base, Temporal and Environmental，如（圖 6）。

圖 6.CVSS Metrics Groups

 Base: 代表內在和基本特徵的弱點，是不會隨著時間和用戶環境推移的固 定評量。

 Temporal: 代表弱點程度，會隨時間變化，但不會隨著用戶環境有所變化。

 Environmental: 弱點與用戶的環境有關聯且有獨特性。

這種客觀的態度為用戶提供了清晰且直觀的表示方法，使用者根據上述 Temporal 和 Environmental 群組更精確顯示出環境裡獨特的風險。當 base metrics 的值代入後，方程式計算出 0~10 的分數（圖 7）Vector 來解釋每一個弱點的分數。

圖 7.CVSS Metrics and Equations

Base score 指派值給 Temporal 和 Environmental Metrics，Temporal 並不是必 要的，根據不同目的，Base 通常已經足夠使用。如果需要 Temporal Score，方程式 將會把 Temporal Metrics 與 Base Score 產生時間評分(Temporal Score)從 0 到 10。

同樣，如果 Environmental Score 是必要的，對環境的方程式將結合 Environmental Metrics 與 Temporal Score 產生環境評分範圍從 0 到 10。

第三節、 銀行業資訊安全損失估算方法

有關資訊安全事件，屬於作業風險，本節先說明巴塞爾資本協定對於作業風 險的定義，之後再探討我國金管會依據巴塞爾資本協定，規範銀行認列作業風險 損失的原則，作為本論文探討銀行個案時，計算財務損失的依據。

一、 巴塞爾資本協定與作業風險

1974 前聯邦德國赫爾斯塔銀行（Herstatt Bank）和美國的富蘭克林國民銀行

（Franklin National Bank）倒閉，兩家國際著名銀行倒閉後，銀行業了解國際性銀 行監管主體發生問題，衍生了兩個基本監管思維：

 任何銀行國外機構都不能逃避監管。

 母國和地主國應共同承擔相應職責。

1988 年 7 月國際清算銀行(Bank for International Settlement, BIS)的巴塞爾銀行 監理委員會（Basel Committee on Banking Supervision, BCBS），公佈以信用風險為 主的跨國規範，通過了《關於統一國際銀行的資本計算和資本標準的報告》（簡稱

《巴塞爾報告》，即 BASEL I）。1996 年巴塞爾銀行監理委員會針對巴塞爾資本協 定提出修正案，以期標準化國際上的風險控管制度，提升國際金融服務的風險控 管能力。該修正案將市場風險納入資本需求的計算；2001 年 1 月公佈了新巴塞爾 資本協定草案第二版即 BASEL II，修正之前的信用風險評估標準，且再加入了作 業風險的參數，將三種風險納入銀行資本計提考量，以期規範國際型銀行風險承 擔能力，另：

 2003 年 4 月公佈第三版草案。

 2004 年 6 月正式定稿公佈新巴賽爾資本協定，並希望在 2006 年年底以 前，大多數的國家都能採用此架構。

 而我國亦於 2007 年開始配合實施。

彙總前述巴賽爾資本協定的發展歷史，新巴賽爾資本協定主要變革在於基本 架構的演進。除了現行強調的「最低資本適足率要求」外，增加「監理機關的監 理審查」及「市場紀律」，形成三大支柱。同時在計提最低資本適足率要求時，除 考慮信用風險與市場風險外，亦增加作業風險的因素。

「作業風險」指的是來自於內部作業、人員及系統的不當或失誤，或因外部 事件所造成損失的風險。包含法律風險，但排除策略及信譽風險。作業風險並不

是近來才發生的，資訊系統(IT)、人為因素、詐欺等作業風險事件所引起的損害及 不確定性已存在很久，在作業風險這個名稱出現後，這些風險始被重新定位並成 為管理決策之重要輔助工具之一。Basel II 的作業風險規範詐欺、流程疏失、營運 中斷、人力資源管理、法律債務等風險進行綜合管理。作業風險所需資本計算方 式，有基本指標法(Basic Indicator Approach)、標準法(Standardized Approach)及進階 衡量法(Advanced Measurement Approaches；AMA)等三種，分述如下：

 基本指標法

以基本指標法計提作業風險所需資本，係依據金融機構前三年中為正值的營 業毛利乘上固定比率 15%，當做任一年的營業毛利為負值或零時，應不列入計算 平均值。其中，營業毛利(Gross Income)定義為：淨利息收益加上淨非利息收益，

不扣除各項提存、營業費用，支付給委外服務提供者的費用，不計算銀行簿上已 實現之有價證券買賣損益，及不計入特殊或異常項目及保險利得等[20]。

 標準法

本法將銀行的業務分為八項業務別：企業財務規劃(corporate finance)、財務交 易 與 銷 售 (trading & sales) 、 消 費 金 融 (retail banking) 、 商 業 金 融 (commercial banking)、收付清算(payment & settlement)、代理業務(agency services)、資產管理 (asset management)和消費經紀(retail brokerage)。計算各業務別所需資本的方法是 用銀行的營業毛利乘以各業務適用的係數(β)，再予以加總。

總資本需求額是每一年度各業務別法定資本的簡單加總後的三年平均值，在 任一年中，任一業務別若有負值的資本計提(由於營業毛利為負)，可抵銷掉其他業 務別中為正值的資本計提；任一年中所有業務別加總後之資本計提額為負值時，

則當年對分子的貢獻值為零。

 進階衡量法

進階衡量法是指在監理機關審核同意後允許符合品質及量化條件之銀行，依 據內部作業風險衡量系統計提作業風險所需資本。銀行於正式採用進階衡量法之 前一年，其適足資本必須分別以進階衡量法及原計算方式進行試算。

二、 我國對作業風險損失的認列規範

新巴塞爾資本協定（英文簡稱 Basel II）目的在標準化國際上的風險控管制度，

提升國際金融服務的風險控管能力。在此協定中因作業風險所產生的損失，則應 該由該期的實際收益依照比例直接計算，而不需考慮風險控制後的變化。我國金 管會銀行局，參酌新巴塞爾資本協定的規範，於民國 98 年 7 月 27 日銀局(法)字第 09800303590, 09800303591 號函，要求由銀行公會與聯徵中心共同研商於 98 年 12 月前辦理作業風險外部損失資料庫。另依銀行公會 98 年 8 月 10 日全風字第 0980002071A 號函請本國銀行與農業金庫配合於 98 年年底前進行作業風險資料報 送[15][23]。在此函文中規範：

 作業風險的定義 - 起因於銀行內部作業、人員及系統之不當或失誤，或 因外部事件造成銀行損失之風險，包括法律風險，但排除策略風險及信 譽風險。

 損失之認定 - 不以列入損益表為依據，應視是否實際產生支付金額或資 產減損為準。

 金額之估計 - 機會成本不納入考量，且不作風險相關金額分攤，以避免 人為判斷影響報送基礎，故金額估算以截至資料填報基準日，直接損失 的實際支付金額為準(不扣除回收金額)，故應報送總直接損失。

舉例來講：銀行的催收系統中斷一小時，導致催收一百萬的帳款無法進行；

或者 ATM 提款機因為網路中斷，顧客無法進行跨行提款交易等，此類營運中斷的 事件，屬於作業風險的規範範圍。實際損失之認定：

 不考慮風險控制後的變化: 催收系統一小時就恢復，仍可繼續完成中斷期 間未催收的作業，但實際損失認定過程，不考慮風險控制後之變化，仍 應認列損失一百萬。

 不考慮機會成本: ATM 提款機發生網路中斷，客戶可以選擇使用他行 ATM，也可能過一段時間等系統恢復正常後，再回來使用原來的 ATM，

手續費只是延後收入，並未損失。但這類的機會成本，不在認定損失的 考慮範圍，因此需認定該客戶在中斷期間為完成交易衍生的手續費收入 損失。

 不考慮策略風險與信譽風險: ATM 提款機發生網路中斷，對客戶產生不

便，對於銀行信譽產生負面影響，客戶可能會選擇轉移到其他銀行。此 類因信譽風險衍生的損失，不在認定損失的考慮範圍。

第四節、 個人資料保護法的罰則

我國個人資料保護法，規範個人資料保護的範圍、方式與罰則。本節先說明 有關個人資料保護法對於個資外洩的罰款規定，作為本論文探討個資外洩個案 時，計算財務賠償金額的依據。計算可能賠償金額，是用來衡量資訊安全對企業 的效益方法。

一、 概述

隨著近年來詐騙事件與外洩事件頻傳，讓人逐漸了解一般個人資料若不慎外 流，會造成相當大的傷害，例如金融業或網路購物業者，擁有眾多且龐大的客戶 資料，營業過程對大量客戶資料進行蒐集、處理或利用，因此需確保個人資料的 安全與保密性，若疏忽對個人資料的保護，可能會讓企業蒙受大金額罰鍰的損失。

我國於 99 年 5 月 26 日，總統公布《個人資料保護法》[18]，法案中將個人資 料保護的範圍將過去醫療、電信、大眾傳播、金融等八大行業，擴大至所有公民 營機關，也就是說無店面零售業、個人、團體也都納入規範圍，並加重民事及刑 事的責任或對負責人科處同一額度之罰鍰，更提供民眾主動投訴機制，並賦予主 管機關、直轄市或縣政府可依職權實施行政檢查。

新法增訂個人之醫療、基因、性生活、健康檢查及犯罪前科等 5 種資料為特 種資料，特種資料原則上不得蒐集、處理或利用(§6)；特定目的外利用個人資料，

避免列入定型化契約之約定條款而作概括同意，應由當事人單獨為書面同意(§7、§

19) ；蒐集資料原則上，均需明確告知當事人蒐集機關名稱、目的等資料。不論直 接或間接蒐集個人資料，均有告知當事人之義務(§8、§9)。對於資料正確性與通知 義務，及資料外洩或被竊取時，資料持有者應以適當方式通知當事人(§11、§12)。

若有違反本法規定時，應主動或依當事人之請求，刪除或停止蒐集、處理或利用 其個人資料(§20)。

二、 個人資料管理規範與罰則

非公務機關違反本法規定，致個人資料遭不法蒐集、處理、利用或其他侵害 當事人權利者，負損害賠償責任。但能證明其無故意或過失者，不在此限。如被 害人不易或不能證明其實際損害額時，得請求法院依侵害情節，以每人每一事件 新臺幣五百元以上二萬元以下計算。對於同一原因事實造成多數當事人權利受侵

害之事件，經當事人請求損害賠償者，其合計最高總額以新臺幣二億元為限。但 因該原因事實所涉利益超過新臺幣二億元者，以該所涉利益為限。(§28)

非公務機關保有個人資料檔案者，應採行適當之安全措施，防止個人資料被 竊取、竄改、毀損、滅失或洩漏。中央目的事業主管機關得指定非公務機關訂定 個人資料檔案安全維護計畫或業務終止後個人資料處理方法。前項計畫及處理方 法之標準等相關事項之辦法，由中央目的事業主管機關定之。(§27)

非公務機關之代表人、管理人或其他有代表權人，因該非公務機關依前三條 規定受罰鍰處罰時，除能證明已盡防止義務者外，應並受同一額度罰鍰之處罰 (§

50)。

由上述法律的規範，我們可以試算如果企業洩漏一筆客戶的個人資料，如果 被當事人依法提出損害賠償，需賠償新臺幣 500 元以上 20,000 元以下的罰款。這 是一個客觀的金錢損失指標，如果可以證明資訊安全服務，有效防止多少筆個人 資料外洩，可以參酌個資法的條文，計算可能的賠償金額，這是另一種用來衡量 資訊安全對企業的效益方法。

第三章 SOC 資訊安全服務概述

第一節、 服務概述

面對這種威脅四伏的情況，入侵偵測系統、入侵防禦系統、標榜多種防毒與 防駭功能的資安設備一一出爐，但是買了這些系統或設備就能高枕無憂嗎？入侵 偵測系統的高誤報率(False Positive)，讓許多使用者搖頭嘆息，面對每天成千上萬 的警訊，多半只能將這些警訊紀錄儲存，束之高閣，沒有時間逐項檢視處理。如 果未經適當的調整，入侵偵測系統每天可能產生數千項甚至數萬項的警訊，遠超 過人為處理的能量。

入侵防禦系統雖然標榜具有偵測及阻絕入侵行為的能力，但在誤報無法減低 的情況下，隨意阻絕偵測到的誤報可能造成正常使用者的斷線與抱怨，問題並無 法有效的解決。就算使用者有能力和時間調整入侵偵測系統或入侵防禦系統，將 誤報的比例減低到合理的程度，但幾乎不可能完全消除誤報，人為的介入審視與 判斷仍不可避免。這類封包導向的偵測系統，之所以會產生過多的誤報，主要是 欠缺足夠的環境資訊來做判斷。就如同一位資安專家進行資安事件的判讀，必須 兼顧下列因素才能提高正確率與合理性，避免見樹不見林的毛病：

 被攻擊標的物防禦狀況與系統弱點

 被攻擊標的物的價值高低

 其他資安設備或網路設備所發生的相關事件

許多單位漸漸發現將資安資訊彙整、集中分析，才能有效的提高入侵偵測、

資安風險監控與處理的效能，因應市場的需求，資安資訊管理系統(Security Information & Event Management System；簡稱 SIEM)便誕生了。若欠缺適當的工 具來蒐集、整合、分析、顯示成千上萬原始事件，再有能力的資安專家也難以判 斷與處理。SIEM 系統通常可以蒐集各種資安設備和網路設備的資安相關資料，經 過正規化(Normalization)調整資料格式為一致，再交給關聯分析系統進行分析，參 考資訊資產的屬性與價值，最後推論出值得進一步檢視的事件，再交由作業流程 控管系統自動派工給資安專家，進行分析和研判，並進行必要的應變處理。

SOC 是負責管理、維運 SIEM 系統的單位，除了 SIEM 軟、硬體的建置以外，

還需要有人員、流程的搭配，才能提供穩定與高品質的服務。

第二節、 SOC 平台之技術架構

SOC 服務乃是以資安監控防護平台為基礎，進行機關、企業端的 7x24 資安防 護維運，監控網路環境異常狀況，處理突發的攻擊事件。防護平台的嚴謹度與功 能乃是防護成功與否的重要關鍵，整理 SOC 處理邏輯如（圖 8）所示，包括下述 之功能模組：

圖 8.SOC邏輯功能圖

 收集客戶端的資安監控軟硬體維運資訊：如防火牆、入侵偵測系統、防 毒系統等。

 SOC 平台前端資訊收集正規化（Import Layer/SIEM, Security Information Management Platform ）： 將 各 種 客 戶 端 設 備 的 資 訊 進 行 正 規 化

（Normalization）與過濾（Filtering），以利於後端一致性的處理與判斷。

 SOC 平台事件智慧判斷（Intelligence Layer/SIEM Platform）：所收集到的 資訊安全事件資訊，與過去已知之案例進行智慧型的比對，以及對不同 的資料群間作關聯性的分析，判斷出最有可能的攻擊型態與來源。

 事件處理與派工（Workflow Layer）：對於所判定的攻擊行為進行因應處 理作業，包括事件發生時優先隔離問題，再進行深入處理之程序，以及 問題處理之分派、進展追蹤與層報等。

 客戶服務入口網站：將事件處理進展資訊透過網站機制供客戶參考，或 是提供客戶登錄與追蹤問題的管道。

以另一個角度觀之，上述之處理邏輯亦可視之由「資料來源層」、「安全日誌 收集層」、「安全事件分析層」與「營運管理層」所組成（圖 9）。

防毒監控 防駭監控

FSA



警訊通報警訊通報



應變作業應變作業 SOP

流程追蹤流程追蹤

服務水準稽核服務水準稽核 第四層 營運管理層

Case Mgt Case Mgt

BMC Remedy Service Desk

監控作業

通報預警 通報預警

資安事件關聯分析資安事件關聯分析

深度解析報告深度解析報告

事件報告

Manager Manager 第三層 安全事件分析層

Web Web Console

Console BrowserBrowser

事件日誌進行過濾事件日誌進行過濾



標準化、格式化標準化、格式化

FSA

A A

Syslog

SNMP

Log File

Database 第二層 安全日誌收集層



安全事件收集支援安全事件收集支援

事件日誌分類事件日誌分類

N-IDS/IPS

Firewall Firewall

H-IDS/IPS 第一層 資料來源層

Server Event

Log

Customer Site（客戶端） SOC

Virus Log Antivirus

Standard Agent Flex Agent

防毒監控 防駭監控

FSA



警訊通報警訊通報



應變作業應變作業 SOP

流程追蹤流程追蹤

服務水準稽核服務水準稽核 第四層 營運管理層

Case Mgt Case Mgt

BMC Remedy Service Desk

監控作業

通報預警 通報預警

資安事件關聯分析資安事件關聯分析

深度解析報告深度解析報告

事件報告

Manager Manager 第三層 安全事件分析層

Web Web Console

Console BrowserBrowser

事件日誌進行過濾事件日誌進行過濾



標準化、格式化標準化、格式化

FSA

A A

Syslog

SNMP

Log File

Database 第二層 安全日誌收集層



安全事件收集支援安全事件收集支援

事件日誌分類事件日誌分類

N-IDS/IPS

Firewall Firewall

H-IDS/IPS 第一層 資料來源層

Server Event

Log

Customer Site（客戶端） SOC

Virus Log Antivirus

Standard Agent Flex Agent

圖 9.四層式資料處理架構圖

在上述的四層架構中：

 「資料來源層」為被監控之設備。

 「安全日誌收集層」為收集監控設備原始事件資訊之層次，包括內含安 裝於 FSA 的日誌收集 Agent 與收集防毒資訊之 Agent。

 「安全事件分析層」為智慧型判斷分析之核心 SIEM/SIEM（Security Information & Event Management 或 Security Information Management）。

 營運管理層為負責驅動營運作業流程之系統，包括提供營運異常事件之 警示、通報、查詢、層報、追蹤與統計等功能。

SOC 平台支援各種網路、資安設備監控作業，包括 Firewall，網路型入侵偵測

／防禦系統（IDS/IPS），主機型入侵偵測系統（Host IDS），防毒偵測系統等。前 端設備（FSA / Front-End Security Appliance）接收各項監控設備之原始事件資料，

並傳送至後端的監控平台進行事件的匯整與關聯性分析。

一、 前端事件收集器（FSA）

FSA（Front-end Security Appliance）部署於客戶端的前端設備，主要功用為收 集各項監控資安設備的原始事件資訊，經過聚合、過濾與壓縮後送回後端系統，

以分析出真正有威脅性的事件。FSA 具有集中管理、高可靠度、高安全性、快速 更新等特點，是一個理想的資安前端設備。

二、 SIEM/SIEM 系統

SIEM（Security Information & Event Management, SIM or SIEM）乃是 SOC 平 台智慧判斷能力的核心模組，為一整合性的資訊安全事件管理平台，主要提供用 戶更為即時且有效的資訊安全管理。SIEM 系統收集各資訊安全設備、網路設備、

作業系統、應用程式之日誌，配合 SOC 營運人員之經驗，對這些資訊加以過濾、

正規化及關聯分析，從成千上萬錯綜複雜之日誌檔中即時獲知單位或客戶端之資 訊安全狀態。

三、 營運管理系統

營運管理平台用來管理資安事件之處理流程，內含維運經驗及客戶維運需 求，是 SOC 營運效率與服務水準之精髓所在。營運管理平台提供資訊安全服務管 理一個整合性的基礎，基於 ITIL 最佳實務方法論，將設計相關流程並加以自動化，

包括監控、傳送與管理異常事件之服務請求、異動服務請求，顯示受到事件或問 題衝擊的服務，並顯示相關的組態資訊與管理資訊，以提供營運組織做服務優先 順序的決策，採取適當的回應動作。

表3 營運管理系統與ITIL服務流程關係表

營運管理系統 ITIL 服務管理流程 Service

Desk

Incident Management Incident Management（事件管理）

Problem Management Problem Management（問題管理）

Task Tracking Change Management（異動管理）

Service Level Management Service Level Management（SLM，服務水準管理）

CMDB Configuration Management（組態管理）

SIEM 平台

第三節、 組織與人力

質量俱備的技術人員，必須透過良好的組織分工設計，方能發揮團隊戰力。

以 Acer SOC 為例，資安監控中心 7x24 維運組織與專業支援，透過不同分工、不 同層次之技術人員分層負責。

一、 維運組織範例

維運組織共分為一線、二線至三線的技術人員，負責資安、設備監控與事件 處理。以某一台灣 SOC 為例，維運組織（圖 10）分工權責分別為：

圖 10. SOC維運人力

 一線監控人員

一線監控維運人員共約 20~30 人，全年無休不間斷提供穩定監控服務；

主要責任為依據 SOP 進行快速的問題標準診斷與解決程序。

 二線監控工程師

受過平台技術移轉專業訓練，負責由蒐集之原始資料中透過 SOC 平台功 能與本身經驗挖掘異常現象，診斷潛在之資安問題，必要時發出資安警 訊通報，並進行鑑識工作。

 三線資安專家

受過 MSS 訓練，並具備超過十年以上之資訊安全工作經驗；負責檢核 複雜之資安通報，對受侵之鑑識結果進行覆核，並對二線技術人員提供 技術諮詢。

二、 專業支援組織

專業支援組織在於提供營運所需各種專業服務能力，（圖 11）各區塊之項目，

包括：

圖 11. SOC分工

 監控前置作業

主要內容在於針對新加入的客戶監控環境進行瞭解，運用弱點掃瞄工具進行 環境評估與強化，安裝設定監控之硬軟體設備，調校資安設備，導入資安設備之 事件資訊以建立監控基準，以及進行事件減量之設定。俟測試驗證所有的監控部 署均為正確，才能交接給資安監控人員進行 7X24 的監控作業。

 專業服務

專業服務在於提供監控維運所需的弱點掃瞄、資安事件鑑識工作。此外，客 戶通常希望搭配 SOC 監控能有教育訓練、電子郵件社交工程測試以及國際重大資 安警訊分析通報服務，亦屬專業服務組織之範圍。而依據營運經驗不斷開拓新的 關聯性分析規則，使資安監控精準度能不斷提升，更是專業服務組織價值所在。

 平台維護管理

主要工作在於管理 SOC 平台軟硬體系統，並依據運轉狀況進行前瞻的容量規 劃，使平台維持於尖峰穩定狀況。此外也負責維護前端 FSA、後端 SIEM 系統，

對資料庫之儲存空間進行管理與備份作業。如遇特殊之新資安設備需導入時，負

責客製化之銜接開發整合。此外，報表客製化、關聯性分析規則之部署等，亦為 平台組織的責任範圍。

此外，亦需搭配系統管理與網路管理相關人才，對於 SOC 的維運也有相當的 幫助，支援工作包括：監控平台維護管理、系統與網路支援作業、技術資訊與工 具的提供等。NOC 一線人員對於簡易的資安事件亦可提供相關支援，例如網頁竄 改事件之通報與處理。由於資安問題包羅萬象，常涉及網路與系統問題，因此整 合此類專案之部門，得以發揮完整的資安防護能力。

第四節、 資安事件管理作業

一、 資安事件之通報

資安事件警訊通報是 SOC 人員依據系統分析處理的資安原始訊息，輔以人員 本身豐富的資安知識與經驗分析，對客戶所進行之通報，目的在提醒客戶檢查與 比對警訊通報內容與實際環境狀況，判定是否發生異常事件。

SOC 將於客戶 SLA 協議的時效內，以電子郵件、電話通知客戶權責人員，並 於 SOC 營運管理系統中詳細記錄。在發佈警訊通報時，將依分工權責領域決定通 報對象（表 4 ），讓相關管理者即時獲得通知，達到真正責任劃分與即時問題診斷 的目的。

表4 通報對象表

對象 說明 對應人員

管理 單位內，具有政策擬定、規範發佈等職 責之人員

資訊主管、單位管理人

網路 單位內之技術人員，如網路設備、資訊 設備…相關負責人

Router, Switch, Firewall, 入 侵偵測設備等之管理者 系統 單位內之系統人員，如程式設計、網站

網頁、伺服器系統…相關負責人

Web/Mail Server，應用系 統、重要主機管理者

二、 資安事件通報之回饋與改善

由於 SOC 監控之各種網路、主機與應用程式的設定和彼此間互動關係複雜，

資安事件難免有誤判。為提升 SOC 資安事件通報之精準度，必須對應檢核客戶環 境實際狀況後進行通報回饋作業。SOC 資安通報均含可疑電腦之 IP 位址，客戶端 權責窗口接獲通報後應檢視該 IP 主機是否有通報所述之異常行為。如該主機之正 常行為被 SOC 誤判為異常，則需透過 SOC 之入口網站（圖 12）回饋此資訊，以 便 SOC 調整偵測規則，避免未來持續誤判。

圖 12. 通報回饋改善網頁

三、 事件之處理（追蹤、鑑識與復原）

SOC 對於事件之處理，係依循 ISO/IEC TR 18044[7]流程四個階段的精神。除 了第一、二階段之事前準備與監控、偵測外，處理作業上係集中力量於第三階段 的「封鎖與復原階段」，執行封鎖作業與證據蒐集、事故還原外，以及事後的蒐集 與存證（經驗學習），以完成事件之處理。

依據 ISO/IEC TR 18044 第三、四階段之精神，SOC 設計出事件通報之作業分 工與流程（圖 14），除進行通報適當對象（客戶權責人員或駐點服務人員）外，

亦需進行通報之追蹤，確認負責現場事件處理之人員已收到通報，同時瞭解事件 之複雜度以及是否需要後端提供遠端與現場支援與諮詢等。

如遇資安事件於指定時間內無法圓滿解決，或 SOC 工程師研判事件複雜度達 一定程度，則會啟動「重大資安事件流程」，除將事件處理升級、投入更多資源外，

也將持續回報客戶、宏碁相關主管處理之進展。

準備與預防階段 偵測與分析階段 封鎖與復原階段 蒐集與存證階段

事前準備

安全認知與 教育訓練

發現 事件徵兆

初步分析

確認事故？

持續 監控與偵測

進行 通報應變作業

執行封鎖作業 與證據蒐集

資安事故還原

經驗學習

蒐集事故資料 與保留證據 里程碑

里程碑

否

是

圖 13. ISO/IEC TR 18044資安事件作業流程

圖 14. 資安事件通報與處理

（一） 事件鑑識

一旦確認客戶環境遭受入侵，則需進行鑑識，找出入侵管道，並確認是否感

染惡意程式，進行清除作業。SOC 依據過去眾多事件的鑑識經驗，設計了「惡意 程式清除與採證 SOP」，作為惡意程式清除之依循。SOP 乃是擷取經驗智慧的精髓，

並參照 SANS（SysAdmin, Audit, Networking, and Security）國際組織的建議精神，

依圖 15「鑑識排除根除回復追蹤」五個階段進行作業。主要工作項目包 括：

 鑑識：分析事件資訊，尋找攻擊來源，並評估威脅與衝擊。

 排除：隔離受害主機，控制損害程度，並防堵事件繼續擴大。

 根除：確認問題根源，據以調整系統或政策。

 回復：恢復系統至未受害前之狀態。

 追蹤：持續觀察事件是否復發。

圖 15. SANS事件處理程序

上述步驟中，事件之鑑識為技術相當複雜之作業，全賴資安技術人員之經驗 與知識，配合現場狀況之判斷，執行機動作業。鑑識工作共包括下述程序：

 檢視不當連線

 檢視可疑程式

 利用工具檢測惡意程式

 蒐集系統組態

 收集、採樣可疑程式

 收集、保存事證、檔案與作業畫面

（二） 系統復原程序

系統復原程序建立前，應先調查現行系統環境，記錄系統、網路、服務等設 定參數；再行調查現行系統軟體，記錄系統安裝軟體清單，最後再建立復原程序 與流程，據以進行復原作業。在人員搭配上，系統復原前須先知會硬體供應商以 及系統管理、應用軟體管理維護、網路管理人員，以便於復原作業發生問題之第 一時間聯絡相關人員排除問題。

系統復原工作極為細緻，SOC 以從事的復原工作經驗為基礎，提供系統復原 的諮詢服務，並適時提出建議及風險評估，以及對應之處理方案。

（三） 事件處理報告

資安事件排除後，Acer SOC 將交付資安事件處理報告書，其項目包括：

 資安事件發生之原因

說明資安事件的整體始末，以及使用的系統漏洞或入侵攻擊方法的說明。

 處理的過程

包括事件整體的過程、入侵或攻擊過程、鑑識及追查過程。

 事件分析判斷

分析判斷所有事件所代表的意義與訊息。

 檢測鑑識所使用的工具

如：網路工具（TcpView 等）、程序檢查工具（ProceView 等）、間諜程式 移除工具（Microsoft Windows Malicious Software Removal Tool）、系統基 本程式（如防毒軟體、系統工具等系統具有的合法軟體），以及其他臨時 依當時情況所使用的軟體或工具。

 蒐證的紀錄及相關資訊

包括：被入侵攻擊系統的關鍵記錄（Logs）或事件（Events）、系統程序 及網路連線狀態紀錄、入侵或惡意程式檔案、網路設備或系統偵測之事 件紀錄（Firewall、IDS、IPS、Anti-Virus Gateway、Anti-Virus Server 等），

以及被入侵攻擊系統軟硬體設備資料。

 事件之結論與改善建議

總結所有鑑識過程、入侵方式、事件影響、強化改善建議等資料及具體 改善建議。

第五節、 SOC 營運技術與智慧

仔細分析網路上的攻擊行為，將會發現有很重要的特徵：各種攻擊事件有先 後次序的關係，例如一個系統被成功攻擊之前，攻擊者需先建立進入點；要建立 進入點之前，就要先可以通過各種管制點或逃避偵測；要知道哪裡有可能的進入 點，就要先進行偵查或刺探，以決定要選擇哪一個目標為入侵標的。

依照這樣的時序關係，我們搭配在 IT 環境不同節點的不同功能資安設備，綜 合各種事件的比對與分析，可以協助我們儘早掌握入侵事件，並進行後續的通報、

阻絕與處理等等。典型的資安防禦架構（圖 16）[11]，各組成元件說明如下。

 實體安全：利用特殊設備（如門禁、指紋辨識），限制存取電腦系統。

 偵查獲取情報：攻擊者利用各種資訊技術或其他方法，瞭解企業的網路 架構或電腦系統的位置與提供之服務內容。

 預警聯防：表示防護端者利用各種偵測技巧，標定可能的偵查行為並預 警，常見的有誘捕系統（honeypot）將不尋常的連線行為儘早辨識出來。

或使用各種弱點掃瞄工具，自行偵測、發掘潛在的資安弱點。

 攻擊標的分析：目標分析是指攻擊者分析偵察獲取情報，評估標的特徵 與可能的弱點，攻擊者也可以與駭客社群，獲取各種工具或手法。

 威脅分析與補丁：威脅分析是防守端採取的防守行為，以進一步確定潛 在的攻擊者和他們的動機。防守者還可以進行滲透測試之類的檢測，以 攻擊者的思維，對防守端的環境進行攻擊。一般滲透測試會找第三方專 家來負責，以便找出高風險的問題，並預先加以補強與防範。

 試探存取系統：試探存取是指那些在之前偵查獲取情報實取得的基本用 戶名，並嘗試是否可以登錄系統，並取得權限（如 root）的行為。

 入侵偵測與防禦：防守方利用各種監控設備，找出符合攻擊特徵的事件，

並加以記錄或阻擋。

 閘道進出管制：用戶進出管制是指防守方以電子方式來限制登錄系統所 採取的措施，這些控制可能包含有多重密碼，整合防火牆、IC 卡等，用 來決定或限制用戶的進出、登入、權限等行為。

 入侵系統：實際進入系統並獲得其控制權。

 發起攻擊：實際攻擊，可能發生在單一事件或一個波段的攻擊事件中。