[新知] Google 發布最新的代理支付協議 (AP2)

昨天 Google 正式發布了最新的 Agent Payment Protocol (AP2) 的 AI 支付協議，擴展了原本 Google 讓不同的 Agent 之間可以協同合作的 A2A (Agent2Agent Protocol) 協定，進一步使 AI Agent 可以根據人類的需求，自動化地完成商品的搜尋、加入購物車，甚至直接支付款項完成交易。

當然，只要跟錢有關的事情，對使用者而言第一個想到的就是交易過程安不安全？會不會在未經使用者同意之下，AI Agent 就自己亂花錢，或是買了不想要的商品。而對商家來說，關注的則是跟資安有關的不可否認性 (Non-repudiation)，如何佐證這筆交易的確是經過真人的授權，而且是基於使用者的意圖來進行交易。

對此，Google 設計了授權書 (Mandates) 的機制來強化交易雙方信任，它是一種防篡改且可驗證的交易證明，可作為每一筆交易實際執行的證據，有興趣了解這項機制的夥伴，可以進一步參考以下 Google 網站的說明。

未來，隨著支持這項協議的商家愈來愈多，讓 AI 自動地幫您尋找並購買喜愛的球鞋、限量發售的公仔，或是直接以自然語言告知 AI 您預計休假的時間，想要去日本旅遊的景點，偏好的住宿飯店地點和價格，往返想乘坐的航班，以及總預算的金額，以上這些不用再一一自己去查找和下訂了，只要 AI Agent 找到符合您設定條件的組合，就可以同時完成以上商品或服務的預訂和付款。

參考資料：
Powering AI commerce with the new Agent Payments Protocol (AP2)

[分享] 關於 NIST Cybersecurity Framework v2.0 轉版與驗證

NIST Cybersecurity Framework (NIST CSF) 已在2024年2月發布最新版的v2.0 (目前NIST官網有提供中文版可供下載)，針對有意想申請轉版或新驗證的組織，可參考以下的文章。

NIST Cybersecurity Framework (NIST CSF) 最早是在2014年2月，由美國白宮所發布的總統命令，要求美國聯邦機構和地方政府需依據美國國家標準暨技術研究院 (NIST) 所提出的網路安全框架 (CSF)，藉此來強化關鍵基礎設施的安全。(老文章請見 https://jackforsec.blogspot.com/2014/11/blog-post.html )

時至今日，NIST CSF 經過在2018年更新為 v1.1，到了2024年則升級為最新的 v2.0，可以應用實施的對象，也不再只侷限於關鍵基礎設施，而是適用於各行各業，只要有心想強化網路安全 (Cybersecurity) 的組織，都可以應用這個框架，相關文件也可以直接免費從 NIST 的官網 ( https://www.nist.gov/cyberframework ) 來下載。

新版主要的改變

除了適用的對象更廣泛之外，NIST CSF v2.0 最大的改變是在框架核心 (Framework Core) 中，從原本的五個功能：識別 (Identify)、保護 (Protect)、偵測 (Detect)、回應 (Respond) 及復原 (Recover) 之外，再加入了「治理 (Govern)」，成為了具有6大核心功能和85個控制措施 (Subcategories) 的好用工具，並且也將原先導入實施的7個步驟，再簡化成為5個。

基本上，NIST CSF 不是用來取代組織已實施的任何安全標準，而是希望和既有的管理體系和控制措施相結合，讓組織自訂想要達成的層級目標 (Tier 1 to Tier 4)，逐步提升能力來管理所面臨的網路安全風險 (Cybersecurity Risks)。如果組織本身已建立ISMS並取得ISO 27001的證書，在驗證範圍內業已實施了NIST CSF，還可以向第三方的驗證機構 (BSI) 申請驗證以取得獨立的一張 NIST CSF 的證書。

轉版與驗證注意事項

目前，針對想要新驗證和既有已獲得證書的組織，有以下事項可供做參考:

1. 舊版 NIST CSF 的證書 (v1.0 or v1.1) 從今年3月起算有二年的轉換期。

2. 持有舊版 NIST CSF 證書的組織，最晚在2027年3月1日之前要完成轉版的稽核，否則證書就會失效了。

3. 還想驗證舊版 NIST CSF 的組織，最晚要在明年2月底前完成，因為在2026年3月1日之後，就只能申請驗證 NIST CSF v2.0 了。

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

隨著 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)

上一篇文章說明了在 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)

上一篇文章說明了在 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)

在 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)

針對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)

上一篇文章已說明了「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)

本週在成功大學擔任 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)：分析威脅所涉及攻擊者的方法，包括其採用的工具、技術、社交工程手法等。

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

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

(待續...)