[新知] 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 資訊傳送」控制措施的要求，確保資訊傳送過程中的安全。

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

(待續...)