分享 on 資安見聞錄

[分享] 從零開始讀 ISO 42001：3 層知識地圖與 5 階段學習路徑

Wed, 29 Jul 2026 15:40:11 +0000

最近發現無論是由組織指派，或是自己主動報名來參加 ISO 42001 主導稽核員課程的學員，課前完全沒有接觸過任何 ISO 標準的並不少，他們最常提出的問題就是「我是一個 ISO 標準新手，我該如何學習 ISO 42001 標準？」

ISO/IEC 42001:2023（以下簡稱 ISO 42001）是全球第一個可稽核驗證的人工智慧管理系統標準，但 AI 管理並不是一個容易掌握的專業技能，因為它橫跨了管理系統、風險管理與 AI 技術這 3 個知識領域，學習之前需要先具備一些基礎知識。因此，我準備了一份知識地圖和學習路徑，希望可以為有意學習人工智慧管理系統標準的夥伴，指出一個容易前進的方向。

圖1　學習 ISO 42001 前需要補齊的 3 層基礎知識

第一層 — 管理系統核心概念

對於沒有接觸過 ISO 管理系統標準 (Management System Standard, MSS) 的人而言，第一步要先理解的是管理系統不是指一個 IT 的應用系統，而是一套「體系」或「制度」，它規範的是組織如何「有系統地」規劃、執行、查核與改善，而不是規定技術做法。所以組織通過驗證取得證書，代表的是管理流程符合標準要求，並不代表驗證範圍中的 AI 系統本身通過測試，這是新手最常見的誤解。

ISO 42001 與其他管理系統標準 (例如 ISO/IEC 27001:2022) 目前都採用高階結構 (High Level Structure, HLS，2021 年後的正式名稱為 Harmonized Structure)，它對應了 PDCA 的管理精神：標準本文第 4 至 7 章是規劃 (Plan)、第 8 章是執行 (Do)、第 9 章是查核 (Check)、第 10 章是改善 (Act)，運作起來就如同一個輪子一般，讓組織的管理體系可以持續向前滾動。

第二層 — 風險管理基礎

管理系統標準最重要的核心要求，就是風險管理。在 ISO 42001 本文條款 6.1（因應風險與機會的行動）要求組織執行風險評鑑（包含風險識別、風險分析、風險評估 3 個步驟）與風險處理，它的方法論基礎來自 ISO 31000:2018《風險管理－指引》。ISO 31000 把風險管理拆成 7 個構成要素，其中 5 項是核心步驟，依序是範疇界定與準則建立、風險識別、風險分析、風險評估與風險處理；至於「溝通與諮詢」和「監督與審查」則貫穿整個流程。

人工智慧管理系統特別重視風險評鑑的過程，主要是因為 AI 風險有 3 項特性：一是不確定性高，模型行為會隨資料更新與再訓練而改變；二是影響對象擴及了個人、群體（如求職者、弱勢團體）及社會；三是風險型態多元，除了資訊安全與隱私保護之外，還涉及公平性、透明度與可解釋性，以及穩健性等。這使得傳統 IT 風險管理方法不足以完整涵蓋 AI 風險，也是實務上還要搭配 ISO/IEC 23894:2023《人工智慧－風險管理指引》的原因。

第三層 — AI 基本概念

如果您對於 AI 的認知，還是停留在與 ChatGPT 或 Gemini 的對話過程，這對於學習人工智慧管理來說明顯不夠。雖然學習人工智慧管理系統標準並不需要精通技術細節，但需要能理解 AI 相關名詞的定義與層次，例如人工智慧 (AI) 是最上層的概念，機器學習 (ML) 是實現 AI 的方法之一，而深度學習是機器學習的子集合，大型語言模型 (LLM) 與生成式 AI 則是深度學習技術的近期應用型態。

想要獲得 AI 的基礎知識，可以研讀 ISO/IEC 22989:2022《人工智慧－概念與術語》（以下簡稱 ISO 22989），它是少數不用花錢就可以從 ISO 官網下載的標準。另外，在 AI 生態系中，使用者不會是唯一的角色。如果您的組織有開發或提供 AI 系統，那麼能辨識 AI 系統生命週期 7 個階段（起始、設計與開發、驗證與確效、部署、運作與監控、再評估、汰除）各自的目標與風險，也是必須具備的能力，而這套 7 階段模型同樣出自 ISO 22989。

建議的 5 階段學習路徑

在具備了以上 3 層知識之後，建議您可以依下列 5 個階段持續推進，並且試著用自己的話來解釋標準的核心知識，或是產生對應的內容，路徑如下：

1. 管理系統基礎建立：自己能白話說明 PDCA 各階段所對應的標準本文章節。

2. 風險與 AI 基本概念：自己能解釋風險管理的過程與 AI 系統生命週期 7 階段。

3. 精讀標準本文：逐條研讀第 4 至 10 章，能夠指出管理系統要求建立的文件化資訊。

4. 研讀附錄 A／B：理解 9 大控制領域、38 項控制措施，能夠說明控制措施的目標與要求。

5. 案例演練與自我檢核：以實際或假設情境（例如 AI 客服系統）練習差異分析 (gap analysis)，產出一份差異分析報告。

圖2　ISO 42001 建議的 5 階段學習路徑與各階段產出

結語

回到一開始提到的，AI 管理並不是一個容易掌握的專業技能，所以先照著知識地圖與建議的學習路徑來走，會是比較容易的做法。

如果您已有 ISO 27001 或其他管理系統標準的學習經驗，代表第一層的知識已經具備，那麼就可以直接從第二層開始；如果完全沒有接觸過標準，就請務必從第一層起步。至於沒有 AI 技術背景的夥伴，您也不需要擔心，只要能理解 AI 相關名詞與 AI 系統生命週期各個階段，您也能成為組織建立人工智慧管理系統的重要推手。

Source: 本文之知識分層與學習路徑架構，整理自作者編撰之《ISO/IEC 42001 基礎知識地圖 v2.1》（2026 年 8 月）。

[分享] 運用標準來滿足永續準則的要求 - 資安、隱私、AI

Sat, 09 May 2026 05:39:00 +0000

永續 (Sustainability) 已是目前全世界所關注的重要議題，主要目的是要藉由環境保護、社會共榮和經濟成長三個面向的均衡發展，透過組織自主建立對應各項議題的指標，以達成聯合國所發布的永續發展目標 (Sustainable Development Goals，SDG)。

以台灣而言，金管會要求實收資本額達20億元以上的上市櫃公司，每年都要編製和公開申報永續報告書 (ESG Report)，這已成為企業的經營管理階層需要負起的重要責任。基本上，組織在編寫永續報告書的時候，不能只是單純任意書寫的作文比賽，而是必須按照特定的議題內容來進行，目前受到國際所認可的準則規範，像是GRI、SASB、DJSI等，都是可以參考的內容，所以組織就要依照準則中的架構和主題，產出符合公司實施現況與可公開揭露的內容。目前在永續報告書中最重要的三個指標，分別是環境 (Environment)、社會責任 (Social) 和治理 (Governance)，也就是所謂的「ESG」，個人觀察大多數組織比較重視的議題，主要著重在環境相關的溫室氣體、污水處理、降低塑膠生產和使用、生態多樣性、節約能源，以及社會責任相關的勞資權益、人權和職業安全風險等。在實務方面，組織通常會利用 ISO 標準所建立的管理體系 (Management System)，例如：ISO 14001 (環境管理)、ISO 50001 (能源管理)、ISO 14064 (溫室氣體盤查)、ISO 14067 (碳足跡) 等，用來產生具備可信度的佐證資料，進而填補永續報告書中各項主題的揭露要求。但是隨著資訊科技的快速發展，資安、隱私和AI應用，也成為了組織在實現永續過程中的重大議題。最近我在講授ISO 42001 (AIMS) 的課程時，就有參與課程的學員提到，目前已被公司的永續發展委員會要求，需要提供在資安、隱私與 AI 上的實施成果，以便在永續報告書中揭露，但是他們卻不知該從何處著手，也不清楚有哪些資安、隱私和AI相關標準可以用來滿足準則的要求，所以我彙整了以下的資訊，可作為相關人員在面對永續議題時的參考。

GRI 準則 (Global Reporting Initiative)

# GRI 418：客戶隱私 (Customer Privacy)

要求內容：

揭露經證實的侵犯客戶隱私及遺失客戶資料的投訴總數（來自監管機構或外部第三方）。
若發生重大洩漏事件，需要說明其過程和處理結果。

如何運用標準滿足要求：

ISO/IEC 27701 (隱私資訊管理系統)：透過此標準建立的「隱私影響評估 (DPIA)」與「當事人權利處理流程」，能夠確保企業可以系統化記錄與追蹤所有投訴，直接提供 GRI 418 所需要的量化數據。
ISO/IEC 27018 (公有雲隱私保護)：如果涉及提供公有雲的雲端服務，此標準可證明對個人可識別資訊 (PII) 的處理符合國際規範，降低 GRI 揭露中出現「違規事件」的風險。

SASB 準則：財務重大性與產業核心風險

SASB在社會資本 (Social Capital) 面向下，關注資安與隱私對企業財務表現的直接影響，針對不同產業有不同指標。

要求內容：

資訊安全：發生資訊洩漏的次數、受影響的用戶比例，以及如何透過技術手段降低風險。
客戶隱私：收集個人資訊的商業目的、如何因應法規的個資保護要求。

如何運用標準滿足要求：

ISO/IEC 27001 (資安管理系統)：透過管理體系和附錄 A 的控制措施，可描述如何利用自動化工具監測威脅，並落實縱深防禦，揭露對供應商進行資安稽核的頻率與合格率。另外，可描述達成營運持續演練 (BCP) 和災難復原演練 (DRP) 的結果，展現在遭受攻擊時的恢復能力。
ISO/IEC 27017 (雲端服務資安)：針對 SASB 中關於基礎設施可靠性的要求，此標準能證明企業對雲端服務特定風險，例如: 虛擬機隔離、共享責任模型等已有妥善管理機制。

DJSI（道瓊永續指數）評選

在 2026 年的 DJSI（道瓊永續指數）評選中，原DJSI已正式更名為「道瓊領先指數（Dow Jones Best-in-Class Indices, DJBIC）」，其採用的企業永續評鑑 (CSA) 已將資訊安全、個資隱私與人工智慧（AI）治理，從單純的「技術合規」提升至「財務重大性」與「數位人權」的高度。

# 資訊安全 (Information Security)

要求內容：

政策覆蓋範圍：資安政策必須涵蓋全體員工、約聘人員及第三方供應商。
董事會監督：需明確揭露董事會中具備資安背景的人員，以及資安長 (CISO) 向董事會報告的頻率。
事件揭露與重大性分析：要求公開重大資安事件的數量、受影響比例，以及該事件對財務的具體影響。

如何運用標準滿足要求：

ISO/IEC 27001 (資安管理系統)：

滿足政策要求：利用 5.2 (政策) 與 Annex A 5.1 (資安政策) 確保政策的完整性。
滿足供應鏈要求：利用 Annex A 5.19 (供應者關係) 建立評核機制。

NIST CSF 2.0 (網路安全框架)：

滿足治理要求：運用其中的「Governance (GV)」功能，定義組織內部資安策略與風險溝通流程，這與 DJSI 要求董事會參與資安治理的核心目標有關。

# 隱私保護 (Privacy Protection)

2026 年的重點在於「透明度」與「資料生命週期管理」，特別是在涉及敏感性 AI 訓練數據時。

要求內容：

資料最小化與保留限制：需證明企業有明確的資料銷毀機制。
當事人權利請求 (DSR)：要求揭露企業處理用戶撤回同意、要求刪除資料的成功率。
第三方隱私稽核：必須對涉及個人資料處理的外部供應者進行獨立查核。

如何運用標準滿足要求：

ISO/IEC 27701 (隱私資訊管理系統)：

滿足資料生命週期：定義 PII（個人可識別資訊）從收集到銷毀的標準作業程序。
滿足當事人權利請求：實施標準條文中的「當事人權利處理機制」，提供可量化的處理數據。

ISO/IEC 29100 (隱私框架)：

滿足隱私設計要求：提供「隱私設計 (Privacy by Design)」和「隱私預設 (Privacy by Default)」的基本隱私要求。

# 負責任的 AI (Responsible AI) - 2026 年新亮點

這是 2026 年 DJBIC 變動最大的部分，主要加入了以下兩個問項。

Q. 公司是否有負責任的人工智慧政策，並且該政策是否公開？

Q. 公司是否有負責任的人工智慧專案？

要求內容：

AI 政策與倫理：尊重人工智慧使用和開發過程中的資料隱私，需要建立「人為干預機制 (HITL)」及「問責機制」。
AI 量化指標 (2026 新增)：要求揭露 AI 的投資額 (Investments)、所帶來的營收增長及 ROI評估。
生態足跡 (Ecological Footprint)：要求揭露 AI 模型訓練與數據中心的能耗、水耗及減碳措施。
AI 生成標記：所有 AI 產出的內容必須有清晰的標記 (防止誤導)。

如何運用標準滿足要求：

ISO/IEC 42001 (AI 管理體系)：

滿足AI治理框架：建立 AI 系統的風險評鑑流程與AI系統影響評鑑，這能直接對應負責任的AI要求。
滿足 HITL 要求：清楚定義 AI 決策中人類介入的權限和方式。

NIST AI RMF (AI 風險管理框架)：

滿足負責任的 AI：利用其「可信賴 AI」的七大指標 (公平、可解釋、安全等) 來管理AI相關的風險，並將結果作為 ESG 報告的證據。

備註：以上準則為透過AI蒐集，再由個人進行手動編輯後的資訊，僅供參考。

[分享] 運用 ISO/IEC 38507 強化組織的AI治理

Fri, 24 Apr 2026 13:21:00 +0000

隨著人工智慧 (AI) 的使用愈來愈普及到日常工作之中，同時也為組織帶來了更多的影響與挑戰，因此，建立一套明確的AI治理架構與監督管理機制，已是組織高層必須要面對的重要課題。

對組織而言，所謂的 AI 治理是指需要建立有效的指導與管理體系，這涉及了組織內部必須建立一個「治理機構 (Governing Body)」，針對組織所具有的 AI 角色來制訂明確的政策，並且清楚定義與「管理層 (Managers)」之間的職責劃分和互動關係。

可依循的AI治理國際標準

針對組織的 AI 治理需求，可以參考由國際標準組織所發布的 ISO/IEC 38507 標準 (Governance of implications of the use of artificial intelligence by organizations)，它引用了來自於 ISO/IEC 38500 的 IT 治理核心模型 – EDM (Evaluate, Direct, Monitor)，同樣可以將它運用在 AI 治理的情境之中。

在 ISO/IEC 38507 標準中提到需要建立的治理機構，它是為組織設定營運宗旨，決定策略目標，並且要為整個組織負起問責性 (Accountability) 的最高決策與監督組織。治理機構需要考量來自於組織內外的各項議題，包括了內部的營運壓力與業務需求，以及了解外部的主管機關、法規義務及關注方的期望等，這些可以進一步聚焦在 AI 特性與差異 (AI differences)、市場需求 (Market needs) 及利害關係人期望 (Stakeholder expectations) 等三個層面。

Source: Governance implications of the use of AI (ISO/IEC 38507:2022)

運用EDM模型來達成治理任務

ISO/IEC 38507 建議組織可以運用 EDM 模型，針對使用 AI 所面臨的五大關鍵政策領域，將治理機構的任務轉化成為實際可行的營運計畫，並且交付給管理層人員來落實完成。所謂的 EDM 模型，它是治理機構主要的核心任務，可用來持續評估 AI 治理的現況，藉由 EDM 所評估的結果，也可以反映出組織的 AI 治理成熟度，鼓勵組織可以定期的安排與實施。

針對 EDM 模型的概念，簡要說明如下：

評估 (Evaluate)：治理機構需要評估目前和未來 AI 可能的使用情況，包括了 AI 為組織所帶來的商業機會、技術變革與潛在風險，以及審查管理層對於 AI 的計畫與使用安排。
指導 (Direct)：依據評估的結果，治理機構要制訂 AI 相關的策略、政策和目標，確立可接受的行為準則與風險胃納 (Risk appetite) 之後，再交給管理層來執行，並且要確保這些與組織本身的願景、文化和法規要求一致。
監督 (Monitor)：治理機構要建立使用 AI 的監控與量測機制，確保 AI 系統遵循了組織的政策要求，並且可以達成既定的績效，也讓組織有能力及時發現 AI 是否發生不符合預期的情況。

AI治理的五大關鍵政策領域

對組織的治理機構來說，需要涵蓋哪些政策層面，才能夠滿足 AI 治理的要求呢？ISO/IEC 38507 提到了以下五個具體的關鍵政策領域，每一個都需要經歷完整的 EDM 過程，才能夠展現組織的 AI 使用活動被有效地治理，這也是治理機構主要的任務工作。

決策制定 (Decision making)：由於 AI 可以高度的自動化，因此治理機構必須要有能力確保人類對於 AI 保有適當的監督與控制權，並且在必要的時候可以介入，甚至可以強制中斷 AI 系統的運行與決策。
資料使用 (Data use)：訓練資料的品質高度影響了 AI 系統的表現與結果，治理機構必須要求組織在資料生命週期的各個階段，建立資料保護、隱私合規，以及防止資料偏見的機制。
文化與價值觀 (Culture and values)：由於 AI 系統本身沒有情感、倫理和道德觀，因此治理機構必須要遵循「以人為本」的精神，確保 AI 的使用與運作，還有利用 AI 系統所產出的結果，都要符合組織的文化、社會期待、人權及永續發展的價值觀。
合規性 (Compliance)：AI 的運作對於人類社會和法規帶來了全新的挑戰，治理機構需要確保現有的管理制度，可以因應目前和未來可能會有的 AI 使用活動，使 AI 系統生命週期各個階段和過程，能夠符合組織所適用的法令法規要求。
風險 (Risk)：AI 帶來了過去在使用 IT 系統過程中，許多未曾面臨的風險，像是缺乏透明度和可解釋性、AI 幻覺與偏見等，因此治理機構需要將 AI 使用納入組織整體的風險管理之中，包括決定對 AI 的風險胃納，實施 AI 風險評鑑與影響評鑑，進行風險處理以將風險控制在組織可以接受的範圍。

依據 ISO/IEC 38507 的規範，組織的治理機構可以運用 EDM 模型，定期針對以上五個關鍵政策領域逐一進行評估，即可建立一個動態且持續的治理循環。

(本圖由 Gemini 生成)

組織中的AI治理與管理職責

在本文一開始提到，組織內部必須建立一個治理機構，針對組織的 AI 角色來制訂政策，並且清楚定義與管理層之間的職責。

從職責的角度而言，治理機構主要負責設定 AI 政策和目標，給予方向和明確的指導，並且承擔最終的責任，而管理層也要負責建立和維護一個 AI 系統的管理體系，像是可以參考 ISO/IEC 42001 標準建立人工智慧管理系統 (AIMS)，透過它將治理機構的評估、指導與監督要求，落實到與 AI 有關的活動與流程之中。

換句話說，在 AI 治理的過程中，治理 (Governance) 與管理 (Management) 是兩個角色不同但必須緊密協作的實體，唯有透過明確的角色分工與職責，雙方保持緊密的互動與合作關係，才能夠達成組織 AI 治理的目標。

[分享] 新版ISO 27701:2025之改變和轉版規劃

Tue, 10 Feb 2026 07:01:00 +0000

新版ISO 27701:2025標準已於2025-10-14發布，正式成為可獨立實施和驗證的隱私資訊管理系統標準，新版標準採用了調和結構 (Harmonized Structure)，包括建立管理體系的本文4~10章，內容架構採用相同標題和文字，方便組織和其他標準進行整合。

在新版標準的附錄A，則針對「PII控制者 (A.1)」和「PII處理者 (A.2)」兩個角色，說明它的控制目標和控制措施。另外，也新增了兩個角色在資安方面需考量的控制措施 (A.3)，並且在附錄B提供了控制措施實作的參考指引，以下列舉新版標準主要的調整和變動。

管理體系的調整

- 原本文5.2~5.8調整為4~10，建立完整的高階管理架構，讓組織更容易和其他標準對齊。

- 原本文6~8調整為新版的附錄B實作指引。

- 原舊版中的附錄A和B，在新版中調整為A.1和A.2，並新增A.3 資安控制措施 (A.3.3~A.3.31)。

控制措施的調整

- 原附錄A.7.2~A.7.5針對「PII控制者」的控制措施，新版調整為附錄A.1.2~A.1.5，包括四個控制領域：蒐集及處理條件、對PII當事人之義務、於設計階段保護隱私及預設保護隱私，以及PII 共享、傳輸及揭露，一共有31個控制措施。

- 原附錄B.8.2~B.8.5針對「PII處理者」的控制措施，新版調整為附錄A.2.2~A.2.5，包括四個控制領域：蒐集及處理條件、對PII當事人之義務、於設計階段保護隱私，以及預設保護隱私及PII 共享、傳輸及揭露，一共有18個控制措施。

- 取消原條款6 ISO 27002 資安控制措施指引，新增附錄A.3「PII控制者和PII處理者的安全事項」，挑選了包括A.3.3~A.3.31共29個資訊安全控制措施，同時也提供了附錄B.3 「PII控制者和PII處理者的實作指引」作為參考。

轉版規劃與準備

目前各家驗證公司還沒有正式發布轉版的細節 (個人預估最晚在2026 Q3可申請進行轉版)，已知的資訊是所有 ISO 27701:2019 舊版證書將於 2028 年 10 月 31 日到期而失效。對於已持有舊版證書，準備要進行轉版的組織而言，可以先透過以下步驟進行規劃與準備：

1. 進行差異分析：可對照舊版和新版的要求事項，評估目前的差異，包括本文新增的條款6.3變更之規劃、條款6.1.3要求建立資訊安全計畫 (information security programme)，以及附錄A.3的29個資安控制措施。

2. 制訂轉版計畫：包括資源的準備，轉版工作的職責分配，本文4~10章管理體系各項流程實施完成時間的安排。

3. 實施新版要求：修訂管理制度文件，實作隱私控制措施，包括隱私風險評鑑和隱私風險處理、更新適用性聲明 (對應新版條款) 及隱私目標規劃與量測等，並且完成內部稽核和管理審查。

4. 申請轉版驗證：跟驗證公司確認轉版稽核時間，安排受稽人員和場地設施，以便順利取得新版證書。

[分享] 從ISO 27001看MCP應用的安全

Mon, 15 Sep 2025 02:44:00 +0000

隨著 2024年11月底 Model Context Protocol (MCP) 正式的發布，有愈來愈多的 AI Agent 利用這種開放式的通訊協議，能夠即時地取得各項數據，或是調動可以一起協作的服務，讓AI各項的應用更加地多元和簡便，對使用者來說是一大福音。

只是在方便使用的背後，通常也隱含著需要我們關注的資安風險，以下文章是彙整最近閱讀相關文件的心得，並應用 ISO 27001 的控制措施來強化 MCP 的安全。

MCP 的誕生解決了傳統 API 連結各項服務，都需要手動設定各自的金鑰才能存取服務的要求，使用者只要透過 MCP Client 就可連接一台或多台的 MCP Server，MCP Server 有能力去調動各項工具、取得資源及協同的服務，而且除了可以存取儲存在地端的資料之外，也可透過網際網路存取遠端的資源與應用服務。

MCP應用可能的資安風險

目前，AI agent 有了 MCP 的幫助，就可讓大型語言模型 (LLM) 快速回應用戶端的 Prompt，並且依據 AI 的判斷主動地來執行各項任務，在這個過程中，包括使用了遠端的 MCP Server 和自行建置地端的 MCP Server，都可能需要注意以下相關的資安風險。

身分憑證 (Token) 被竊取：目前網路上充斥著許多由個人開發，或是偽冒知名 MCP Server 名稱的服務，如果沒有進行適當的確認就使用，可能會造成 MCP Server 的憑證被竊取，或是因授權過大而導致濫用的情況。

惡意攻擊指令注入：惡意人士可能會利用輸入的 Prompt，刻意操縱 LLM 去觸發惡意的行為，例如: 刪除特定的資料、送出敏感性資訊 (外洩個資或金鑰)，或是透過為數眾多的 MCP Server 來實現組合式的攻擊。

MCP Server 缺少認證機制：MCP Server 常由一些獨立的開發者建立，在開發的過程中可能缺少了安全檢測，或是撰寫的程式碼未經過安全的審查，使用者若下載了內含安全漏洞或惡意程式的 MCP Server，並且安裝在本地端的電腦 (使用自動安裝工具) ，也可能就直接開了一個後門而毫不知情。

ISO 27001的安全控制措施

針對以上提到有關使用 MCP 的風險，組織可以依照 ISO 27001附錄A 的控制措施，包括但不限於以下的做法來強化資訊安全的管控：

A.5.15 存取控制 - 在組織內部的存取控制政策中，制訂明確的 MCP 管理和授權的過程，事先確認 MCP 的合理性和進行版本的管控。

A.8.3 資訊存取限制 - 限制可呼叫的遠端 MCP Server，並檢測可能有惡意行為的 Prompt 指令。

A.8.5 安全鑑別 - 利用 OAuth 等技術來強化安全認證機制，並限制用戶端只可使用經過驗證的 MCP Sever。

A.8.8 技術脆弱性管理 - 針對本地端自己建置的 MCP Sever 定期執行弱點掃瞄，並進行高風險弱點的修補。

A.8.15 存錄 - 留存 MCP 活動的日誌 (log)，並針對高風險的操作進行分析與審查。

A.8.16 監視活動 - 利用工具持續地監控和記錄 MCP Server 的活動，若發現異常的行為，則結合事件通報的機制進行評鑑和處理。

A.8.18 具特殊權限公用程式之使用 - 將 MCP Server 視為是一種含有特權的應用程式，在安裝和使用時需要經過適當的審查與核可過程，以及建立可使用自動化工具的白名單。

A.8.24 密碼技術之使用 - 使用 TLS 傳輸加密來防範網路的中間人攻擊，安全地儲存所使用的金鑰，並適當輪替更換和限制金鑰的有效期限。

[分享] ISO 27001:2022 新增的控制措施 (6)

Fri, 12 Sep 2025 16:10:00 +0000

上一篇文章說明了在 ISO 27001:2022 的附錄A中，有關技術面的「A.8.11 資料遮蔽」和「A.8.12 資料洩露預防」，接下來說明本系列最後3個控制措施，分別是「A.8.16 監視活動 (Monitoring activities)」、「A.8.23 網頁過濾 (Web filtering)」以及「A.8.28 安全程式設計 (Secure coding)」的要求和實施重點。

A.8.16 監視活動

這項控制措施的要求是「應監視網路、系統及應用之異常行為，並採取適切措施，以評估潛在資訊安全事故」。若是從要求內容來看，我們需要實施監控的項目至少包括了網路、系統和應用程式的異常行為，但要如何確認有異常行為的發生呢？其實我們需要事先定義正常的行為基準 (baseline)。

舉例來說，大多數的機房都會進行溫度異常的監視，那麼該如何得知溫度有異常呢？首先就先要定義溫度正常的範圍基準，假設基準要求溫度需要維持在攝氏25度以下，那麼只要監控時發現機房溫度超過25度的情況，我們就會定義它是一個異常的事件 (event)，在進行通報之後，就要依據「A.5.25 資訊安全事件之評鑑及決策」的控制措施，進行損害的評估。

如果確認這已經是一個造成損害的事故 (incident)，那就需要再進一步依據「A.5.26 對資訊安全事故之回應」的控制措施，進行資安事故的處理，盡快地降低事故範圍的擴大並減輕造成的損害。所以在監視活動的實施方面，通常還需要結合事件通報和事故處理的流程，才能讓整體的資安控制更完整。

A.8.23 網頁過濾

這項控制措施的要求是「應管理對外部網站之存取，以降低暴露於惡意內容」。顯而易見的，這項控制措施的目的就是要降低有愈來愈多的惡意程式，都是感染至含有惡意內容的網站之風險。

實務方面，首先要建立使用者的上網行為規則，讓使用者有能力認知並避免瀏覽高風險的網站，接著還需要搭配技術面的管控機制，例如透過閘道端 (Gateway) 的上網行為管理設備，藉由啟用內建的一些高風險網站群組，限制組織內可上網瀏覽的網站。如果缺少這類設備的支援，也可以直接在防火牆上設定阻擋惡意網站IP的黑名單，只是它經常需要手動且及時的更新，才能達成阻擋過濾的效果。

A.8.28 安全程式設計

這項控制措施的要求是「軟體開發應施行安全程式設計原則」，目的是要確保在撰寫程式的過程中，能夠降低軟體中存在資安弱點的數量。

在實施方面，除了要先依據「A.8.25 安全開發生命週期」的要求，建立安全開發軟體的各個階段和過程的安全規則之外，還可以特別針對撰寫程式的開發人員，製作並提供給開發人員一份安全開發指南 (coding guideline)，讓開發人員可以清楚知道撰寫程式的安全準則，避免使用有弱點的語法或引用了不安全的第三方和開放原始碼的元件，建立一套安全編碼的方法。

當然，在安全開發指南的文件中，請盡量以淺顯易懂的方式，像是列舉一些正確寫法或錯誤的範例，讓開發人員願意來閱讀和遵循，可以更容易避開一些常見的安全漏洞 (ex. SQL Injection)。

(本系列完)

[分享] ISO 27001:2022 新增的控制措施 (5)

Tue, 09 Sep 2025 08:27:00 +0000

上一篇文章說明了在 ISO 27001:2022的附錄A中，有關技術面的「A.8.9 組態管理」和「A.8.10 資訊刪除」，接下來說明剩下的5個控制措施中，有關「A.8.11 資料遮蔽 (Data masking)」和「A.8.12 資料洩露預防 (Data leakage prevention)」的要求和實施重點。

A.8.11 資料遮蔽

這項控制措施的要求是「應使用資料遮蔽，依組織關於存取控制之主題特定政策及其他相關的主題特定政策，以及營運要求事項，並將適用法令納入考量」。一般來說，需要進行遮蔽的資料，大多都是與個人資料 (PII) 有關，但實務上只要是敏感性資訊，都可以考量採取不同的技術來隱藏不想讓人得知的資料內容。

目前，針對資料遮蔽最常採取的做法有以下幾種方式：

擬匿名化 (pseudonymization) : 這種方式又叫做「假名化」，也就是使用別名或暱稱來取代原本可直接識別的當事人資訊。例如組織內部以員工編號取代姓名，或是在網路公開的討論區或社群媒體使用暱稱來替代真實的姓名。
匿名化 (anonymization)：一般也稱之為「去識別化」，也就是採取不可逆轉的方式，讓資訊無法再直接或間接的識別到特定的當事人。例如有一筆記錄顯示王小明中午喜歡吃排骨便當，若將姓名取代成為王OO，並且不保留原始記錄的資料，也確認無法再用併湊或比對的方式知道，原來中午喜歡吃排骨便當的人就是王小明，即可達成不可逆的去識別化的結果。

另外，將資訊中的某些數值進行「替換 (replace)」也是常見的方法，例如將信用卡簽單中的卡號部份數值取代為「*」，但在實施時必須考量所採取資料遮蔽方法的強度，是否可達成不被反解或猜中的目的。以卡號遮蔽方式來說，目前業界主要是參照 PCIDSS 標準的要求，將16位數字的卡號僅顯示前6碼和後4碼的方式，也就是遮蔽中間6碼數字。

A.8.12 資料洩露預防

這項控制措施要求「應將資料洩露預防措施，套用至處理、儲存或傳輸敏感性資訊之系統、網路及所有其他裝置」。在實務方面，對於資安防禦者 (Blue team) 來說，防止資料洩露是件說來簡單，但實施起來極為挑戰的工作。以居家安全為例，出門前您必須確保家中每一扇大大小小門窗和進入管道都要上鎖，只要有一個地方遺漏了，入侵者就可能利用這個小地方入侵成功，而且即使已上鎖了，還要考量上鎖的強度，是否足以抵擋外力的破壞。

雖然要達成資料洩露預防是件不容易的事，但標準告訴我們可以從三個層面的預防角度出發，也就針對「處理」、「儲存」及「傳輸」的資料，對應採取防範的措施。

針對處理中的資料，大部份的組織都是透過資訊處理設施和端點裝置來進行，所以針對實體資料處理的埸域，像是辦公室、機房，都可以藉由ISO 27001 A.7 各項實體控制措施 (例如門禁、CCTV等) 來達成防護。針對使用者的端點裝置，也可利用「A.8.1使用者端點裝置」的控管要求，來防範資料的洩露。

至於儲存中的資料，組織需要透過資訊資產的盤點清查 (A.5.9 資訊及其他相關聯資產之清冊)，了解有哪些資料儲存的地點和方式，包括線上儲存的資料庫、NAS、雲端儲存空間等，到離線儲存的資料 (例如磁帶、光碟等儲存媒體)，再實施對應的保護機制 (例如存取權限、加密)。

而針對傳輸中的資料，則是要評估組織目前對內或對外，有哪些傳輸的管道和方式 (包括電子和實體傳輸)，再依據「A.5.14 資訊傳送」控制措施的要求，確保資訊傳送過程中的安全。

最後，資料洩露預防單靠管理程序和人力是難以達成的，組織還可以考量使用資料洩露預防相關技術工具，進一步強化以下三個階段的防護措施 - 識別 (發生前保護)、偵測 (發生中得知) 及矯正 (發生後阻擋)，才可以有足夠的能力達成資料洩露預防的目標。

(待續…)

[分享] ISO 27001:2022 新增的控制措施 (4)

Wed, 03 Sep 2025 14:03:00 +0000

在 ISO 27001:2022的附錄A中，一共有四個控制領域，分別是「組織、人員、實體和技術」，若是和舊版標準相比，在組織面新增了3個控制措施，在人員面沒有新增，在實體方面則新增了1個。

以上三個層面新增的控制措施重點和實施做法，在前三篇文章中都已分享，接下來將陸續說明在技術面新增的7個控制措施。

A.8.9 組態管理

組態管理 (Configuration management) 不是一個新的概念，早在以前曾經流行過的「ITIL」和 ISO 20000 標準中，針對IT服務的管理要求，組態管理就扮演了重要的角色。那到底什麼叫做組態？簡單白話的說法就是設定或配置，它可以用來確保和IT有關的服務能夠正常地運作。

在ISO 27001的組態管理控制措施中，要求「應建立、書面記錄、實作、監視並審查硬體、軟體、服務及網路之組態 (包括安全組態)」。所以在實施方面，組織就必須建立一個過程，以文件化的方式來管理包括硬體、軟體、服務及網路等四個層面有關安全的設定和配置。

對組織而言，基本上就是要先建立硬體、軟體、服務及網路組態的安全基準 (baseline) 或範本 (template)，這部份可以參考公開的指引，例如由資安院提供的政府組態基準 (GCB)，或是參考由IT供應商所提供的安全設定規範。

如果組織有資源，可以進一步考慮建立一個「組態管理資料庫 (Configuration Management Database, CMDB)」，藉此來管理所有和資安有關的硬體、軟體、服務及網路的基本組態，並且記錄異動後的組態設定，再搭配相關工具來達成組態的監視 (Monitor) 和審查 (Review)。

如果組織沒有足夠的資源，則可以結合既有的資訊資產管理過程，利用資產清冊來盤點和記錄有關硬體、軟體、服務及網路組態的安全設定，在建立基本的安全組態要求之後，後續再搭配變更管理的過程來實現組態管理和留存組態異動的記錄。

A.8.10 資訊刪除

接下來在技術面新增的三個控制措施 (A.8.10, A.8.11, A.8.12)，主要都和資訊隱私保護 (Privacy) 有關。

資訊刪除 (Information deletion) 的控制要求是「當於資訊系統、裝置或所有其他儲存媒體中之資訊不再屬必要時，應刪除之」，主要目的就是讓組織能避免因保留了不必要的敏感性資訊，遭到未經授權存取而影響了資訊的機密性。

不過，在實務方面常遇到的問題是，組織到底要如何去確認「資訊已不再屬必要？」個人鼓勵可以從以下兩個角度來評估資訊是否可以進行刪除。

資訊已過保留期限：這個做法的前提是組織必須清楚定義各項資訊的保留期限，尤其是針對許多以前認為要永久保存的資訊，應該考量法令法規的要求，或是業務上實際的需要，定出一個適當的保留期限，之後才能依據是否已過期了，進行資訊的刪除。
當初蒐集、處理及利用的目的已不存在：這類資訊主要是和個人資料有關，如果這些個人資料已經沒有當初蒐集時，告知當事人在蒐集之後和目的有關的活動，也沒有法規要求需要保留的必要性，組織就應該主動的進行刪除。

最後，組織在進行資訊刪除時，需要考量針對不同類型的資訊 (電子檔案或紙本文件) 所儲存的媒體，採取有效的刪除方法，並且記錄刪除的過程作為佐證的記錄。如果有委託供應商進行大批的資料銷毀，也要進行過程中的監督和確認，並保存適當的銷毀記錄。

(待續…)

[分享] ISO 27001:2022 新增的控制措施 (3)

Sun, 31 Aug 2025 13:55:00 +0000

針對ISO 27001:2022新增的11項控制措施，先前已經說明了3項，接下來說明第4項「A.7.4 實體安全監視 (Physical security monitoring)」的要求與實務做法。

A.7.4 實體安全監視

在新版 ISO 27001:2022 標準中對於實體安全監視的要求是「應持續監視場所，以防未經授權之實體進出」，最常見的管控機制就是建置影像監控系統 (CCTV) 了。

其實在舊版 ISO 27001:2013 的實體安全防護方面，針對管制區域像是機房和辦公室的出入口，安裝 CCTV 進行監控並留存影像，本來就是常見的實務做法，只是過往並沒有特別將這項控制措施獨立出來。

基本上，CCTV 只是實體安全監視的其中一項方法，其他可能的管控方式還包括了設置警衛、紅外線或壓力感測入侵警報器等，目的是要達成偵測並及時阻止未經授權的進出。

在新版 ISO 27001:2022 的要求中，針對這項控制措施的重點在於「持續」，所以必須要確保監視的時間和記錄的留存，是否可以滿足組織本身的要求。

最後，組織若要在特定的場所設置監視器，也要特別注意裝設監視器的位置，並依據相關法令法規的規定，千萬不要以監控之名而侵犯了他人的隱私。

(待續…)

[分享] ISO 27001:2022 新增的控制措施 (2)

Sun, 24 Aug 2025 13:50:00 +0000

上一篇文章已說明了「A.5.7 威脅情資」的管控重點，接下來跟各位分享在ISO 27001:2022「A.5 組織控制措施」方面，其他兩個控制措施的重點要求。

ISO 27001:2022 分別在附錄A的四個控制領域 (組織、人員、實體、技術)，增加了11個新的控制措施，在「A.5 組織控制措施」方面，包括了「A.5.7 威脅情資 (Threat intelligence)」、「A.5.23 使用雲端服務之資訊安全 (Information security for use of cloud services)」、「A.5.30 營運持續之ICT備妥性 (Information and Communications Technology readiness for business continuity)」等三項，接下來說明其它兩項的重點要求。

A.5.23 使用雲端服務之資訊安全

目前已經有愈來愈多的組織，使用了由外部提供的公有雲服務，例如：微軟的 M365、Google的Workspace、AWS EC2 等。有些組織認為，只要利用既有的委外廠商管理作業規範，同樣也能管理這些雲端服務業者來達到資訊安全的要求，但是卻忽略了雲端服務的特性和傳統的委外服務有著很大的差異性，組織既有對於委外廠商的資安要求，恐怕無法完全適用於雲端服務業者。

因此，在 ISO 27001:2022 附錄A，增加了使用雲端服務之資訊安全的控制措施，要求「應依組織之資訊安全要求事項，建立獲取、使用、管理及退出雲端服務的過程」。在這個要求之中，對於雲端服務的資安要求涵蓋了三個層面，我們可以分別從雲端服務使用的前 (獲取)、中 (使用、管理)、後 (退出) 三個階段，考量實施以下的管控機制。

使用雲端服務之前 (獲取)：組織需要考量如何評選一家安全可靠的服務業者，可能的條件包括了業者是否有通過雲端安全相關標準的驗證 (ISO 27017, 27018, CSA STAR)、業者是否主動揭露雲端安全和隱私保護的機制，以及在服務等級協議 (SLA) 或合約之中，所承諾要達成的安全事項，是否滿足組織本身的要求。
使用雲端服務期間 (使用、管理)：為了有效管理組織內部雲端服務的使用者，必須建立雲端服務的使用政策或程序，並且針對負責管理雲端服務的單位 (通常是IT部門) 或是具有特權的服務管理者 (Administrator)，需要確認和審查使用雲端服務有關的安全控管機制 (例如：帳號與權限、日誌功能、資料加密等) 是否落實。
終止使用雲端服務 (退出): 組織應考量若有一天要終止雲端服務的使用，或是要轉換使用不同的雲端服務業者時，確認雲端服務上的資料是否能夠取回的方式 (最好事先明訂在合約或協議中)，同時也要確認業者移除所租用的服務或刪除儲存資料的機制 (了解刪除方式和所需時間)。

A.5.30 營運持續之ICT備妥性

對組織而言，營運持續管理 (Business Continuity Management, BCM) 是一個很大的議題，這個控制措施雖然是新增加的，但其實在舊版的 ISO 27001:2013 中，就已經有對於營運持續的資安要求，也就是把營運持續的考量，限縮在資安的層面。如果想要了解有關組織整體的營運持續管理，可以進一步參考它對應的國際標準 ISO 22301。

在這項控制措施的內容方面，它要求「應依營運持續目標及 ICT (Information and Communication Technology) 持續之要求事項，規劃、實作、維護及測試ICT備妥性」，也就是更明確的把對營運持續的要求，聚焦在資通訊技術相關的裝置和設施，組織必須考量由於ICT造成營運中斷的可能性，提前做好準備。

所以在實施方面，組織可以透過進行營運衝擊分析 (Business Impact Analysis, BIA) 來決定有哪些重要的業務活動，需要依靠哪些關鍵的ICT資源來支持業務活動的持續運作，並針對將服務恢復至可正常提供水準的時間要求，訂出恢復的時間目標 (Recovery Time Objective, RTO)。

如果服務還涉及了資訊處理活動，也要依據組織可承受遺失資料的損失程度，訂出資料回復的時間點目標 (Recovery Point Objective, RPO)，並採取對應的備份機制，例如：組織能承受的資料遺失只有一天，那麼就至少必須每24小時進行一次資料備份。當然，除了備份之外，也要定期進行備份資料的回復測試，確認備份檔案的有效性。

完成以上活動之後，組織還需要針對各個可能造成營運中斷的情境，建立完整的營運持續計畫 (Business Continuity Plan, BCP)，將回復ICT相關活動的作業流程、操作步驟、人員職掌等描述清楚，並且安排定期實施BCP演練，確認有能力滿足所訂定的RTO和RPO，並根據演練過程中所獲得的經驗來持續改善，達成組織營運持續的目標。

(待續…)

[分享] ISO 27001:2022 新增的控制措施 (1)

Mon, 18 Aug 2025 15:21:00 +0000

本週在成功大學擔任 ISO 27001 Lead Auditor 主導稽核員的課程講師，有學員詢問 ISO 27001:2022 的標準，最晚在什麼時候一定要完成轉版稽核？以及新版增加的11項控制措施，實施方面的重點和要求是什麼？我想透過以下一系列的文章來和大家分享。

ISO 27001:2022 的轉版要求：ISO 27001:2022 標準正式發布於2022年10月，ISO組織給予持有舊版證書的組織有三年的轉換期，也就是說，所有ISO 27001:2013的證書必須要在2025年10月31日之前完成轉版稽核，否則舊版的證書就會到期或撤銷，因此，還沒有完成轉換的組織目前已剩下不到3個月的時間了，請務必要在截止期限完成才行。

ISO 27001:2022 新增的控制措施：對於想要轉換到新版證書的組織而言，最想了解的就是新版和舊版的主要改變是什麼？基本上，新版標準在管理制度方面的要求，除了新增加一個全新的條款「6.3 變更之規劃」之外 (可參考這篇文章)，最大的改變就是控制措施從原本14個控制領域調整為4個 (組織、人員、實體、技術)，控制措施的數量也整併減少為93個，但是其中卻增加了11個新的控制措施，所以接下來的文章，就逐一來說明這11個控制措施的實施重點和要求。

A.5.7 威脅情資 (Threat intelligence)

針對這個控制措施，首先我們需要先定義什麼叫做「情資」？透過以下 CREST - What is Cyber Threat Intelligence and how is it used? 這份指南所提出的，它會經過「蒐集、處理、分析」三個階段。

Source: CREST

以產生網路威脅情資為例，一開始需要蒐集的是原始資料 (Data)，可能的來源像是網路設備或防火牆所記錄的IP位址或日誌，再將這些資料導入日誌平台或透過工具進行處理，就能得到一些可疑的活動資訊 (Information)。最後，再經由適當的關聯分析和歸納，匯聚成為管理階層可以判斷做出進一步行動的決策依據，這就是所謂的情資 (Intelligence)。

如果參考ISO 27002控制措施的實務指引，它還提到了威脅情資可以分為三個層面，提供和分享給管理階層來進行評估，分述如下：

策略面 (Strategic)：分析威脅屬於哪一種攻擊類型？組織可依據自己的現況來建立類型 (例如主機、網路、實體、人員類)，或是參考SANS定義的三種情資類型 (內部、外部、社群或特定產業)。
營運面 (Operational)：分析威脅的攻擊目標主要針對哪些資訊系統？或是可能影響到內部什麼樣的資訊 (例如研發資料、客戶資料、交易資料)？
戰術面 (Tactical)：分析威脅所涉及攻擊者的方法，包括其採用的工具、技術、社交工程手法等。

在了解以上的情資定義和分層評估以做出決策行動之後，我們回頭來看看標準中針對這個控制措施的要求 -「應蒐集並分析與資訊安全威脅相關之資訊，以產生威脅情資。」

所以在實施方面，依據這項要求，組織必須建立威脅情資蒐集的來源，以及處理和分析的過程，並且可透過分層的方式，讓管理階層能易於掌握和理解情資的重要性，以做出決策和採取適當的行動，這樣才能讓組織真正具備預防、偵測及回應威脅的能力。

(待續…)

[分享] 如何選擇適用的雲端安全標準

Sun, 20 Jul 2025 07:14:00 +0000

上一篇文章，分享了「導入雲端安全標準前應思考的三件事」，如果您已經確認組織所提供的服務，符合了雲端運算的五個基本特徵，並且歸納出是屬於哪一種部署模式和服務型式，也清楚了組織的角色是雲端服務顧客 (CSC) 或是雲端服務提供者 (CSP)，那接下您就可以參考這一篇文章，選用適合實施和進行驗證的雲端安全標準。

Source: BSI

可實施驗證的雲端安全標準

目前國際上認可和雲端安全有關，常見並且可以實施驗證的四個標準如下：

ISO/IEC 27001：它是適用於各行各業的資訊安全管理標準，可協助組織建立一個資訊安全管理系統 (ISMS)，藉由執行風險評鑑來選擇適當的控制措施，定義組織要達成的資安目標，再透過定期實施的內部稽核和管理審查，讓組織秉持PDCA的精神來持續改善資安，組織必須先通過ISO 27001驗證，這是獲得其他雲端安全標準證書的基本要求。
ISO/IEC 27017：它是基於ISO 27002，所延伸補充的雲端服務資訊安全控制措施的實作指引 (Code of practice for information security controls based on ISO/IEC 27002 for cloud services)，可適用於四種部署模式 (公有雲、私有雲、社群雲、混合雲) 和三種服務型式 (SaaS, PaaS, IaaS)，也同時適用雲端服務顧客 (CSC) 和雲端服務提供者 (CSP) 兩種角色。換句話說，它是目前適用性最廣泛的雲端安全標準。
CSA STAR：它是由雲端安全聯盟 (CSA)，所推出由產業認可的雲端安全標準，本身是基於由產業工作小組所聯合發展的雲端控制矩陣 (Cloud Control Matrix, CCM)，在實施之後，雲端服務提供者可藉由完成雲端安全自評表 (CAIQ)，或委由獨立公正的驗證單位像是BSI實施稽核，讓組織來展現已達成CSA STAR Level 1和Level 2的驗證。適用的對象，通常是以提供公有雲的三種服務型式為主的雲端服務提供者 (CSP) 。
ISO/IEC 27018：它是基於ISO 29100的隱私框架 (Privacy Framework) 和延伸補充自ISO 27002的控制措施，提供給PII處理者於公有雲環境，依據合約或協議處理個人可識別資訊 (PII) 時可遵循的實作指引 (Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)。這個標準是目前適用性範圍最小的，適用的對象包括提供公有雲的三種服務型式，但必須是PII處理者 (經由控制者委託處理PII) 的雲端服務提供者 (CSP)。

最簡單的評估和選擇方法

看了以上的說明，各位肯定還是眼花繚亂和一頭霧水，對吧？

別擔心，這裡介紹簡單選用的三個步驟 - 先釐清組織角色 (CSC or CSP)、確認服務類型 (SaaS, PaaS, IaaS)、選用部署模式 (公有雲、私有雲、社群雲、混合雲)，再依下列方法來選擇。

選擇一，無論您的組織是雲端服務顧客 (CSC) 或是雲端服務提供者 (CSP) ，使用或提供的是哪一種服務型式，也不管是哪一種部署模式，ISO 27017 肯定是最為適用的雲端安全標準。

選擇二，如果您的組織是雲端服務提供者 (CSP)，提供了任何一種的服務型式，通常部署的模式為公有雲 (Public Cloud) ，那麼選擇實施 CSA STAR 沒問題。

選擇三，如果您的組織是雲端服務提供者 (CSP)，在公有雲上提供了任何一種的服務型式，並且受到您的顧客委託 (有簽訂合約或協議)，使用雲服務來進行個資 (PII) 處理的活動，那麼您可以選擇實施ISO 27018來強化雲端服務的個資與隱私保護。

最後，再從組織角色方面，歸納出以下最簡單的判斷方式。

如果您是雲端服務顧客 (CSC)，只能驗證 ISO 27001 + ISO 27017。
如果您是雲端服務提供者 (CSP)，可以驗證 ISO 27001 + ISO 27017 + CSA STAR。
如果您是雲端服務提供者 (CSP)，並且也是公有雲的PII處理者，可以驗證 ISO 27001 + ISO 27017 + CSA STAR + ISO 27018。

[分享] 導入雲端標準前應思考的三件事

Sat, 19 Jul 2025 13:00:00 +0000

本週協助講授雲端服務資安管理主導稽核員的訓練課程，有學員詢問：「如果想要導入和驗證雲端服務的標準，那要如何確認自己是什麼樣的雲服務和適用哪一個國際標準？」

這是一個好問題，基本上，許多有興趣導入和實施雲標準的組織，最常見的情況就是不太清楚自己是真正的雲服務，還是只是傳統的網站服務，也不太知道自己是哪一種服務型式。

幸好，在雲端服務發展的初期，美國國家標準和技術研究院 (NIST) 就提出了雲端運算的定義 (NIST 800-145)，我個人喜歡把它稱之為「雲端運算的543」，組織可以利用它來評估自己是否有應用了雲端運算，而且是提供哪一類型的雲端服務。

Source: CSA Security Guidance

雲端標準導入第一步- 先確認自己是不是雲

關於雲端運算的543，其中5個基本特徵指的是:

廣泛的網路存取 (Broad network access)：所提供的服務支援各種用戶端設備，包括但不限於手機、筆記型電腦、平板電腦等，基本上只要此設備上面有瀏覽器，就可以透過網路來存取雲端服務。
快速且彈性的運作 (Rapid elasticity)：雲端服務的功能或資源可以快速且彈性的配置和調整，以租用IaaS的虛擬機器（VM）為例，租用雲端服務的顧客，可以依需求調整VM的數量，快速從10台擴展至50台，或是從50台減少至10台；若是SaaS的儲存服務，同樣也可以快速取得更多的儲存空間。在服務過程中，除了可自由手動配置之外，還可透過相關技術 (ex. API) 進行自動調整，如果口袋夠深，就可以實現在非常短時間內，獲得難以想像的運算能力，這是傳統IT架構比較難以達成的地方。
可量測的服務 (Measured service)：雲端服務是一種租賃的服務，雲端服務顧客（Cloud Service Customer, CSC）可以透過網路取得雲端服務提供者（Cloud Service Provider, CSP）所提供的各項運算資源 (例如：儲存、運算、頻寬、線上應用服務的帳戶等)，通常可採用按次付費或按使用資源收費的方式。所以對雲端服務提供者而言，就必須提供透明化的方式，並且有能力可以監控、控制和提供報表，讓雲端服務顧客可以清楚掌握目前資源使用的情況，以及需要付出的費用。
隨需的自助化服務 (On-demand self-service)：雲端服務可以讓顧客就像吃自助餐一樣，依照自己的喜好和需求來配置雲端運算的能力和資源，不需要透過雲端服務提供者的人工介入，包括申請、使用、配置功能和資源，都可以透過業者的雲端服務入口網站來達成。
資源池的調配 (Resource pooling)：由於雲端服務提供給為數眾多的顧客來使用，所以會形成一種共用資源的多租戶模式 (multi-tenant model)，為了要達成上面提到的快速且彈性的擴充和運作，對於雲端服務提供者來說，就必須要有能力匯整和調配包括實體和虛擬化的資源 (例如處理器、記憶體、儲存空間及網路頻寬)，快速地提供給需要的顧客，或是由不使用的顧客端進行回收。這些資源池可能位於世界各地，讓租用服務的顧客可以快速取用，業者也可順利的回收匯整。

對有意導入和驗證雲標準的組織，第一步就是要確認自己提供或使用的服務，是否運用了雲端運算，能夠符合雲端服務的5個基本特徵。

舉例來說，如果組織提供的服務是一個官方網站，它使用了一台實體的主機 (Windows Server + IIS)，放在自己的機房，設定開放對外的網路 (TCP 80, 443 port)，提供了組織簡介和產品資訊等內容，也開放給使用者可加入網站會員，申請帳號並利用它來登入網站使用電子報的訂閱和取消功能。

雖然它可滿足了一項雲端運算的特徵 (廣泛的網路存取)，但在其他4項特徵方面如果都沒有相關的功能和機制，只能說它其實還是傳統的網站服務，並不是所謂的雲端服務，也不太適用雲端服務的標準。

當然，目前NIST並沒有定義雲端服務需要完全滿足以上5個特徵，但若只是符合其中一項或二項，然後就認為自己是雲端服務的提供者，那實在是有點牽強。既然本質上不是雲端服務，又要強求去實施雲端服務相關的控制措施，恐怕很多的控制措施都很難展現和達成，也是浪費了組織的時間和人力成本。

但是，官方網站真的不能適用和驗證雲端服務的標準嗎？

有一種情況是可以實現的，就是組織同樣提供官網和會員的網站服務，但不是放在自家建置的環境，而是租用了其他業者的雲端服務，例如跟AWS, Azure, GCP租用虛擬主機，在上面運行所提供的網站服務。

這時候，藉由租用符合雲端運算5個基本特徵的雲端服務提供者的資源，就可以對外宣稱自己的網站服務是運用了雲端運算的服務，只不過組織的角色，並不會因此就直接變成雲端服務提供者，組織本身其實是雲端服務顧客的角色。

如果組織的目的是為了強化內部使用雲端服務的資訊安全，那就可以導入和驗證適用顧客的雲端標準 (ISO 27017) 了。

雲端標準導入第二步- 提供什麼類型的雲服務

關於雲端運算的543，剩下的4和3指的是：

4種部署模式：公有雲 (開放給大眾使用)、私有雲 (限單一組織使用)、社群雲 (具有共同目標的族群)、混合雲 (使用兩種以上部署模式)
3種服務型式： SaaS 軟體即服務 (ex. M365, Dropbox)、PaaS 平台即服務 (ex. 開發環境或容器運作平台)、IaaS 基礎設施即服務 (ex. VM)

若是確認了自己的服務已具備雲端運算的基本特徵，接下來請問問自己，採用的部署模式是什麼？所提供的是哪一類型的雲服務。

雲端標準導入第三步- 釐清自己的角色

如果您的組織和Microsoft、Google、Amazon一樣，提供各式各樣的雲服務給大家使用，並且滿足雲端服務的5大特徵，您就是「雲端服務提供者 (Cloud Service Provider, CSP)」。

如果您的組織單純只是使用現有的雲服務，例如：M365, GCP, AWS EC2等，那您就是「雲端服務顧客 (Cloud Service Customer, CSC)」。

如果您的組織像是儲存服務的業者Dropbox，在底層的儲存空間租用了AWS S3服務 (IaaS)，並且利用它來打造成為自己的檔案儲存應用服務 (SaaS)，此應用服務也藉由自己提供的機制符合了雲端運算的五大特徵，那麼您就是同時兼具了雲端服務顧客 (面對AWS)，同時也是雲端服務提供者 (面對Dropbox顧客)的角色。

最後，如果您已完全清楚了以上三件事，下一篇文章將告訴您如何選擇適用的雲端服務國際標準。

[分享] 製造業的資安管理重點

Thu, 17 Jul 2025 07:13:00 +0000

上週到新竹某個高科技製造業公司，擔任 ISO 27001 Lead Auditor 的課程講師，現場有參與課程的學員問到，對高科技製造業者來說，需要考量的資安管理重點是什麼？

一般來說，高科技製造業的資安管理，至少需要涵蓋以下三個層面：

1. 生產製造：建立機台相關控制系統的存取控制、網路管理及端點裝置防護的流程；

2. 內部系統：實施基礎設施的實體安全管理、強化內部系統安全 (ex. MES, ERP) 及資料保護的控制措施；

3. 外部服務：針對供應商和供應鍊的安全管理，以及使用外部提供的新興科技服務 (ex. Cloud, AI) 的管控機制。

另外，除了定期實施一般人員的資安訓練，防範社交工程和釣魚郵件的威脅，強化最高管理階層的資安認知也是必要的工作，唯有最高管理階層具備資安風險管理的觀念，才有辦法帶領組織和員工落實資訊安全的要求。

[分享] ISO 27001:2022 本文新增之條款

Wed, 15 Nov 2023 12:48:00 +0000

受到國際公認的新版ISO 27001:2022資訊安全管理系統 (ISMS) 國際標準，從2022年10月底正式公告發行之後，至今也已經屆滿一週年了，依據ISO組織的要求，所有取得舊版證書的組織，都必須要在三年的轉換期內 (2025年10月底前) 完成轉版稽核，以便持續維持證書的有效性，接下來跟大家分享新版和舊版中，主要條款內容的差異，希望能夠協助大家順利的完成轉版的工作。

在ISO 27001: 2022 標準本文中主要的改變，就是加入了一個全新的條款「6.3 變更之規劃」，要求「當組織決定需要對資訊安全管理系統變更時，應以規劃之方式執行變更」。在舊版標準中，提到跟變更有關的要求，應該就是「A.12.1.2 變更管理」的控制措施了，這個控制措施要求「應控制對影響資訊安全之組織、營運過程、資訊處理設施及系統的變更」。所以大到不管是組織的策略方向和營運過程的改變可能影響到資安，小至資訊系統和防火牆的設定異動調整，都需要備妥正式的管理責任及程序，以確保所有變更之控制皆符合要求，並留下適當的記錄。

不過在新版的標準中，跟組織ISMS有關的變更要求，已經把它歸屬在「6.3 變更之規劃」中了，至於舊版原本的「A.12.1.2 變更管理」控制措施，條款編號已經調整為「8.32 變更管理」，並且也將控制措施的要求，調整為「資訊處理設施及資訊系統之變更，應遵循變更管理程序」，也就是改變成為只針對資訊處理設施和資訊系統的變更管理要求了。

實務分享

至於在什麼樣的情況下，組織需要依照「6.3 變更之規劃」的要求來實施呢？

一般而言，通常是組織有重大的異動 (例如合併了另一家公司)，或是資訊相關作業活動有了重大的改變，ISMS管理制度可能就得因應來做調整，以下舉一個例子來說明。

舉例: 某組織選擇停止自建和維運現有的實體機房，改為採用三大公有雲所提供的 IaaS 服務，將資訊系統運作在租用的虛擬機器 (VM) 之上。此時，當組織決定採用由外部提供的雲端服務時，就需要考量 ISMS 體系面 (本文4-10章節) 的管理要求，以有計畫的方式做出ISMS的對應調整，並且留下適當的記錄，包括:

鑑別與雲端服務有關的內外部議題和關注方的期望與要求 (4.1, 4.2)。
資安政策中是否包括針對雲端安全的要求事項，以及持續改善的承諾 (5.2)。
針對使用的雲端服務進行風險評鑑和風險處理 (6.1, 8.2, 8.3)，選擇適當的控制措施 (A.5.23)。
考量針對雲端服務制訂相關的資訊安全目標，並且定期進行監督與量測 (6.2, 9.1)。
實施和雲端服務有關的專業與認知教育訓練 (7.2, 7.3)。
確保使用雲端服務的過程實施適切的控制，例如: 管理外部供應商 (8.1)。
針對使用的雲端服務進行內部稽核 (9.2)，管理審查時進行與雲端服務相關的反饋與改善 (9.3, 10)

查核重點

最後，組織在進行自我查核和檢視相關稽核證據時，可考量以下事項:

詢問組織如何決定需要變更資訊安全管理系統 (ISMS)，所採取的規劃方式是什麼？
詢問如何針對ISMS管理體系 (本文4-10) 做出因應的調整？
針對所做出的ISMS管理體系之調整，檢視對應的客觀證據有哪些？

[分享] 強化帳戶安全 - Google提供中文化兩步驟身分驗證

Sat, 30 Jul 2011 05:19:00 +0000

如果您是一位資訊工作者，由Google所提供的Gmail、Google doc、Google+等多項應用服務，想必已是每天都不可或缺的工具之一。即使是一般的普羅大眾，在生活中透過電子郵件的往來，信件內容也會包括許多和個人有關的資訊，像是電子帳單、保險資料、網路購物記錄，甚至是電子情書等。

因此，除非您是一個完全沒有秘密或不在乎隱私外洩的人，一旦個人所使用的Google帳號被竊了，勢必會對生活造成非常大的困擾。鑑於這項風險，Google針對使用者的身分驗證方式，推出了兩步驟驗證服務(2-Step Verification)。

所謂的「Google兩步驟驗證」，和資訊安全中經常提到的雙因素(two-factor)驗證類似，為的就是強化身分驗證的安全，它將原本只需要使用者帳號和密碼即可登入的方式，更進一步擴充為多加一道驗證碼的方式來進行，而這個第二道驗證碼，可以透過個人手機簡訊，或是利用手機上的應用程式來協助產生。

想要快速了解什麼是兩步驟驗證服務，您可以先看看Google的影片說明：

如果您想更進一步瞭解如何確保個人Google帳號的安全，請參考Google的官方網頁說明。

兩步驟身分驗證設定說明

以下是Google兩步驟身分驗證簡要的設定步驟，提供給您作為參考：

首先請登入自己的Google帳號，然後點選「帳戶設定」，接著在使用兩步驟驗證這邊，點選「編輯」。

接下來的頁面說明了設定只要3個動作就可完成，請點選「設定兩步驟驗證」開始來進行吧。

第一動是「設定您的手機」，在這裡您可以選擇希望收到驗證碼的方式，包括簡訊(SMS)、語音來電，或透過智慧型手機的應用程式。對於不是智慧型手機的使用者而言，透過簡訊傳送是最簡單的方式，但如果您有iPhone或Android手機，那麼透過手機的應用程式將會更加地方便，不過，您得先去App store或Android market下載「Google Authenticator」這個應用程式才行。在此，我以iPhone作為範例，請點選「iPhone」，然後按「下一步」。

接下來，請啟動iPhone上的Google Authenticator，輕觸「+」，再點按「掃瞄條碼」來掃瞄頁面中所出現的QR條碼。掃瞄完成之後，手機會開始出現6位數字的密碼，而且每一分鐘就會重新產生一組新密碼，舊的也隨即失效來確保其安全性。接著，請按「下一步」來進行測試。

在這裡，我們可以輸入Google Authenticator所產生的驗證碼，接著按下「驗證」來測試一下。成功之後，請按「下一步」來繼續。

目前，我們已成功設定可以用手機來產生驗證碼，但是，要是萬一手機掉了、臨時沒電，或忘了帶出門，可是想使用時該怎麼辦？Google也為您想到了這些，所以提供了備用選項，一共有10組的備用驗證碼來提供您使用，建議您可以放在皮夾裡以便隨身攜帶，(什麼？也忘了帶皮夾？好吧，我救不了您~) ，接下來請點選「下一步」。

完成第一動之後，第二動是「新增備用選項」，在這裡請把備用的驗證碼列印或是抄下來，以便不時之需，記下後，請勾選「是，我有一個備用驗證碼」，然後點選「下一步」。

除了備用驗證碼之外，Google還讓您加入第二個電話號碼作為備用，如果手機遺失，就可以透過簡訊或語音留言來傳送驗證碼到備用電話上。填寫完成之後，請點選「下一步」。

最後的第三動是「確認」，在這個頁面中，Google偵測到您必須要建立應用程式專用密碼，原因是如果您使用了其他應用程式來登入Google帳戶，例如透過電腦上的Outlook或手機的電子郵件軟體來收取Gmail郵件，這些軟體並沒有提供輸入第二道驗證碼的功能，所以必須要產生一個特別的應用程式專用密碼，來讓這些軟體使用。以我自己為例，我會使用iPhone和iPad來看Gmail，所以就需要分別為它們設定一個專用密碼，幸好，這只需要設定一次就行了。請點選「下一步」來繼續。

這是最後一個頁面，您只要點選「啟用兩步驟驗證」就完成了，但要注意的是，一旦啟動之後，原先在行動裝置上收信的功能就會失效，需要為它們設定專用密碼才行，所以完成之後，我們就要開始使用兩步驟驗證方式來登入Gmail，並且來為個別的應用程式設定專用密碼了。

應用程式專用密碼設定說明

請使用原先的密碼來登入Gmail，登入完成之後，接著會出現要求您輸入驗證碼的頁面，請輸入由手機的Google Authenticator所產生的6位驗證碼，點選「驗證」即可順利登入。如果您覺得每次都要輸入驗證碼有點麻煩，則可以勾選「接下來的30天保持這台電腦的驗證狀態」，當然，為了安全起見，這台電腦最好是您自己專用的才行。

登入Gmail之後，請點選「帳戶設定」，接著在授權應用程式和網站的項目，點選「編輯」，為了確保隱私，在這邊會要求再輸入一次密碼。

在這個頁面，我們就要來產生新的應用程式專用密碼，請給您的行動裝置或應用程式取一個名字，然後點選「產生密碼」。

接下來，頁面上會出現一組16位的密碼，請把原本在您的iPhone中所使用的密碼，改成這個專用密碼即可。若要繼續為其他行動裝置或應用程式設定專用密碼，請點選「隱藏密碼」，請注意，一旦隱藏之後密碼就看不到了，若是忘記的話，需要「撤銷」之後，再重新產生。

將所有行動裝置或應用程式的專用密碼一一生成，並且取代原先使用的密碼之後，就大功告成了。

以上的說明，看起來有點複雜，但實際操作一遍之後，使用起來並不會太困難，如果您對於Google的帳戶安全有高度的要求，建議您可以啟動這項機制。至於一般使用者的話，或許只要將原本的密碼，設定的夠複雜就行了(英文大小寫加數字混合至少8碼)，以免造成使用上不必要的麻煩。

舊留言存檔

以下留言轉存自原 Blogger 網站，僅供存檔，無法回覆。

Rainie（2011-10-15）

求救… 不好意思，我啟用了，google帳戶兩步驟驗證後，我iphone內的gmail就無法使用了，他一直說我的帳密錯誤，不論我使用原來密碼，又或者是用產生新的應用程式專用密碼，都無法登入!!!! 而後我關掉google這個功能，可是還是無法登入gmail,請問哪裏錯誤了??不知版主知不知道這個問題…

傑克小花（2011-10-16）

Hello~您好, 如果您啟用了兩步驟驗證，在iPhone裡的mail就必須設定為應用程式的專用密碼，因為它一共有16位，請確認在輸入時沒有錯誤喔~ 如果之後您關閉了這項功能，就應該要換回原來的密碼，您可以先試著在網頁上登入，若成功的話，再將它設定在iPhone上。

傑克小花（2011-12-07）

Hi 您好, 如果您是使用家中電腦，透過瀏覽器進入Gmail收信的話，第一步還是要輸入原先的密碼，接著第二步才是輸入手機傳送來的驗證碼。如果不行的話，請使用「備用驗證碼」來進入信箱，然後重新設定，或者乾脆取消兩步驗身分驗證功能，以避免驗證失敗的問題發生。

[分享] 請關心學童的上網行為

Wed, 13 Jul 2011 02:25:00 +0000

暑假到了，小朋友在家的時間更長，您有沒有發現他們黏在電腦前的時間也更增加了呢？根據台灣微軟所發佈的「兒少網路安全調查報告」，提到有將近四成的學童每天都會上網，有近二成的學童每天上網超過六小時，所以很可能延伸出和許多大人一樣的症狀叫作「網路成癮症」。

有位小六學童說，「不上網不打卡，我就覺得自己好像不存在。」這或許是一個比較極端的例子，不過，請問您真的了解小朋友們的網路活動，或是稱之為網路社交生活嗎？

調查也顯示，有兩成五的學童上網看過色情和暴力資訊，有五成學童會玩限制級等超齡遊戲，更有四成的家長完全不知道孩子的MSN、e-mail、Facebook等帳號，因此會和小朋友有一段所謂的親子網路距離。

其實，個人更擔心的是，許多家長可能連線上遊戲、MSN、Facebook都沒聽過或是不了解，這種數位落差，可能會是未來親子教養的另一項危機。

所以，今日的家長們真的更辛苦了，除了要具備網路基本知識，恐怕也要懂一點資安概念才行，否則，你的小孩可能很容易就會接觸不當資訊，或是因為玩遊戲洩露個資而受到詐騙。

以下幾項小建議，提供給各位家長作為把關學童上網的參考：

家用電腦應擺放在看得到的地方(例如客廳)，而非隱密的房間，以避免小朋友可任意的使用上網。
提醒小朋友注意可能的網路詐騙問題，若是有人提到需要個人資料，或是和金錢有關的事項時，都要盡快和父母或師長回報。
如果家中小朋友真的經常上網，大人又很難在一旁監督，那麼初階的家長，可申請電信業者的色情守門員服務，協助您防堵一些有害資訊和不良網站。若是有進階需求的家長，則可以購置電腦的側錄軟體，來協助您監控小朋友的上網行為。

站在管理的角度而言，一昧的限制小朋友使用電腦或是監看側錄並不是良方，唯有適時的溝通、詢問、了解，才是在資訊時代讓小朋友能夠善用資訊工具，並且懂得學習成長的解決之道。

<參考資料>

[分享] 保護個人使用Facebook的隱私

Tue, 12 Jul 2011 13:32:00 +0000

關於社群網路，最近有幾則令人矚目的新聞，首先是facebook的使用者在全球已突破七億人；其次則是Google也推出了具有社群網路功能的服務Google+；第三則是有惡意人士盜用媒體的名義，於美國獨立紀念日當天，在Twitter上發佈美國總統歐巴馬遇刺的假消息。

什麼是社群網路？簡單的說就是一些有著共同愛好、興趣，或是為了某項共同目的所結合起來的個人與團體，透過網路無遠弗屆與傳播快速的特色，讓大家可以在線上進行互動、討論，以及分享各種資訊。

社群網路的前身，來自於風行於校園的BBS，它採用了文字介面來分享訊息，而隨著多媒體與動態網頁技術的更新，一些具有互動功能像是留言板、討論區、聊天室的網站也開始盛行，提供人們另一個可以溝通互動的園地。

近來，社群網站更成為一種商業行銷與人脈經營的工具，包括臉書(facebook)、噗浪(Plurk)，推特(Twitter)和大陸流行的微博等，已成為眾多使用者每天必要的網路活動之一。

只是，在虛擬的網路世界中，同樣有著現實生活需要面對的人際關係問題，例如個人隱私、冒名交友，甚至是詐騙金錢等事件發生。

因此，適時的保護個人隱私是必要的，尤其在網路的世界中，往往看不到背後真正的那個人，在使用社群網路的同時，除了要保護自己，更要保護自己的親朋好友，免得因為洩露過多的個人資訊，導致有人受害。

以下是使用Facebook的玩家，建議您應該要啟用的隱私設定。

在登入之後，請至帳號 -> 隱私設定 ->自訂設定，將所有的內容都設定為「僅限朋友」。

請至帳號 -> 帳號設定 -> 帳號安全，請將「安全加密瀏覽模式(https)」和「登入通知」的項目勾選起來。

在隱私設定方面，將所有分享內容設定為僅限朋友，可以避免那些您根本無法掌握，可能也不知其名的「朋友的朋友」們，能夠瀏覽您的資訊。

在帳號設定方面，啟用安全加密可以保障您在公用網路，像是網咖、麥當勞，或是最近台北市提供的免費無線網路等環境時，瀏覽facebook的內容安全。而登入通知則是可以在有人使用其他的電腦裝置登入您的facebook時，您可以馬上得知，以避免帳號受到盜用。

[分享] 資安事件管理(SIEM)的魔術象限

Wed, 01 Jun 2011 04:14:00 +0000

談到Gartner的Magic Quadrant(魔術象限)，它是Garther在特定的時間內，對於市場和使用者的體驗，所作出的分析結果，也一向是被許多廠商用來證明自己的產品，已在市場中佔有一席之地。

基本上，它只是一項研究報告，不代表落在象限內的產品就一定是好的產品，但個人認為Gartner對於市場現況的描述和針對各家產品的優缺點分析，是相當適合用來作為在選購產品時的評估和明列相關規格時的參考。

過去，我曾經提到IT Log管理的重要性(請參考「從記錄分析談IT Log管理」一文)，而它其實也就是所謂資安事件管理(SIEM)的基礎，依據Gartner的定義，SIEM的技術可以提供：

安全資訊管理(Security Information Management；SIM) - 可用來進行log管理和法規報告。

安全事件管理(Security event management；SEM) - 可針對來自於網路、資安設備、系統和應用程式，進行和安全有關的事件即時(real-time)監控，以及事故的管理。

而在組織之中會想要部署SIEM的技術，則是為了達到以下目的：

法規遵循 - 對應到剛才提到的安全資訊管理，提供法規要求的相關報告。
威脅管理 - 即時監控使用者的行為、資料存取和應用程式的相關活動，以及事故管理。
兩者皆是 - 可提供法規報告，也同時具備威脅管理的能力。

在國內現況方面，SIEM的需求，主要來自於政府所建構的國家資通安全防護管理中心(NSOC)，需要進行資安事件的監控與資料交換；而民間企業，則有提供資安監控服務的安全管理服務供應商(MSSP)，所建置的資安監控中心(Security Operating Center；SOC)，兩者是早期採用的先行者。

當然，目前也有許多大型企業或高科技製造業，也會採購相關的設備與技術，來提升本身的資安防護能力，至於對中小型企業而言，為了因應未來個資法或導入ISO 27001標準的要求，則建議還是先從作好Log管理開始。

[參考資料] Magic Quadrant for Security Information and Event Management (12 May 2011)

[分享] 關於應用程式安全稽核的現況

Mon, 30 May 2011 04:17:00 +0000

上星期有朋友問到有關軟體/應用程式安全稽核的一些現況，以及什麼樣的工具才會是客戶願意使用的檢測工具，就個人的了解，將相關的資訊整理分享如下：

目前在應用程式安全稽核方面，大致可分為資安管理面和技術面的稽核，在管理面方面，可依據ISO 27001中A.12資訊系統取得、開發及維護的控制項目來進行，包括在軟體專案一開始的時候，是否識別了安全風險，並且加入所需要的安全控制；應用系統是否設計了輸入資料確認、處理程序查核機制、訊息完整性、輸出資料的確認等。

另外，若軟體使用了加密機制，就要注意是否制定了加密控制與使用政策；是否有適當的金鑰管理；還有如何確保系統檔案和源碼的安全，包括像是程式的組態與安裝控管、測試資料的保護、源碼的存取控制；最後是整個軟體開發與支援過程的安全如何確保，包括了控管專案與所需的支援、應用系統的變更程序、變更之後的技術審查、以及後續系統弱點修補的程序等，這些都是實施資安稽核時的重點。

至於技術性稽核，通常是使用一些檢測工具，進行白箱或黑箱的測試，之後會產出一份檢測報告，再依據報告內容進行改善。但是，若是沒有配合完整的稽核程序，這部份較像是單一軟體檢測和在專案驗收時才會進行的事項，比較不像是所謂的資安稽核。

在工具方面，黑箱部份知名的有HP Webinspect和IBM Appscan等，白箱則有Fortify等，當然也有一些免費開放的工具，這些工具已內建了許多模組，可以選擇依照法規要求(ex. ISO 27001, PCI DSS)或是Owasp Top10常見的弱點，進行掃瞄並產出對應的報告。

在報告之中，它會列出有問題的程式碼或參數是落在哪一行，也會提出建議的改善方法，當然這些只能供作程式開發人員的參考，讓他們明白需要改善的方向，而且通常在改善完成之後，也需要再作一次檢測，看看是否還有遺漏的部份。

如果回到需求面來看，組織會想要作應用程式的檢測，大致有以下幾個原因：

自我要求：通常是非常重視資安的企業，內部有自己的程式開發人員，為確保所撰寫程式在上線前沒有安全漏洞，所以需要進行檢測。

法規要求：為因應ISO法規或政府對相關單位的資安要求，所以需要定期實施安全檢測。

客戶要求：這部份是一些受到企業委外的軟體開發商，為確保程式需合RFP相關安全要求，故在驗收之前需要作軟體的安全檢測。

因此，使用檢測工具是最容易滿足以上要求的作法，不過像黑箱工具最容易受到質疑的地方，就在於是否能夠完全檢測出其所有的弱點，以及所提供的改善建議是否切實可用。所以客戶在評估使用檢測工具時，通常會有以下的考量：

購置成本：以國外的工具而言，通常價格都不菲，雖然有些工具可以在程式開發階段時，就可以輔助開發人員來避免可能的漏洞，但是許多客戶都傾向於不購買工具，而是在程式開發完成後，甚至是已經上線了，再請提供服務的廠商來實施檢測。
使用介面：國外工具大都使用英文介面，相關的選項設定，甚至對於弱點的修補建議都是英文，這對於一些IT人員而言，使用上可能不太容易上手。
支援能力：可支援常見的程式語言，包括html、java、.net、vbscript、xml、ActiveX、Flash、AJAX等之外，也包括常見的通常協定如http、https、proxy等，以及相關的編碼方式如ISO-8859、UTF等。也會要求在檢測過程中，不得新增或修改其後端資料表的任何內容(針對黑箱工具)。
法規模組：這部份和產出的報表內容有關，是否可支援常見的安全標準例如OWASP Top10、ISO 27001、PCI DSS、HIPPA等，可完整的檢測其提出的安全漏洞和安全要求事項。
報表品質：是否包括執行摘要、漏洞描述、程式修補建議等。過去曾遇到的情況是，在掃瞄完成之後，出了厚厚一本詳盡的弱點報告給客戶，但客戶認為太繁瑣，甚至要求必須依照其需求，例如不同人員屬性像是開發人員、測試人員、法規人員，再客製化一份報表，以及提供中文化的修正建議。事實上報表的內容品質，也會是客戶是否願意採用這些工具的重點。

所以，針對以上提到的問題，若廠商都能有相對應的解決方案，相信就會是客戶想要使用的好工具，當然其中在實務面上有許多需要克服的困難，這也需要讓廠商來傷腦筋了~