威脅建模您的生成式人工智慧工作負載以評估安全風險

隨著生成性人工智能模型越來越多地融入商業應用程序，評估它們所引入的潛在安全風險至關重要。在AWS re:Invent 2023大會上，我們就此主題進行了演講，幫助數百名客戶安全地進行新技術的快速決策。參加這次會議的客戶能夠更好地理解我們對於評估安全風險和保持高安全標準的建議方法，以確保他們所構建的應用程序的安全性。在這篇博文中，我們將重溫針對生成性人工智能工作負載進行有效威脅建模的關鍵步驟，以及其他最佳做法和示例，包括您在每個階段應尋找的一些典型交付成果和結果。在這篇文章中，我們將連結到我們使用AWS Threat Composer工具創建的具體示例。Threat Composer是一款開源的AWS工具，您可以用來記錄您的威脅模型，無需額外費用。

這篇文章涵蓋了一種實用的生成性人工智能工作負載的威脅建模方法，並假設您已經知道威脅建模的基本知識。如果您想了解威脅建模的概述，我們建議您查看這篇博文。此外，這篇文章是有關生成性人工智能安全和合規考慮的更大系列的一部分。

為什麼要對生成性人工智能使用威脅建模？

每項新技術在識別和減輕其所帶來的獨特安全風險時都會有自己的學習曲線。生成性人工智能進入工作負載的過程也不例外。這些工作負載，特別是使用大型語言模型（LLMs），引入了新的安全挑戰，因為它們可以根據用戶提示生成高度定制和非確定性的輸出，這增加了潛在濫用的可能性。此外，它們依賴於訪問龐大且定制的數據集，這些數據集往往是包含敏感信息的內部數據源。

儘管使用LLMs是一項相對較新的實踐，並且存在一些獨特和微妙的安全風險和影響，但重要的是要記住，LLMs僅是更大工作負載的一部分。將威脅建模方法應用於系統的各個部分非常重要，考慮到已知的威脅，例如注入或憑證的妥協。《安全生成性人工智能AWS博客系列》的第1部分《生成性人工智能安全範疇矩陣介紹》很好地概述了這些細微之處，以及根據您在組織中如何使用LLMs而風險的不同。

生成性人工智能的威脅建模四個階段

快速回顧一下，威脅建模是一種結構化的方法，用於識別、理解、解決和傳達給定系統或應用程序中的安全風險。這是設計階段的一個基本要素，它使您能夠識別和實施適當的減輕措施，並儘早做出基本的安全決策。

在AWS中，威脅建模是啟動我們的應用安全（AppSec）流程所需的輸入，並且我們的構建團隊會獲得安全守護者的支持，以構建其功能或服務的威脅模型。

由專家Adam Shostack創建的一種組織威脅建模的方法包括回答四個關鍵問題。我們將研究每個問題以及如何將它們應用於您的生成性人工智能工作負載。

我們正在做什麼？
可能會發生什麼問題？
我們將如何應對？
我們的工作做得夠好嗎？

我們正在做什麼？

這個問題旨在深入了解您的業務背景和應用程序架構。您所尋求的細節應該已經作為生成性人工智能解決方案的構建者所創建的綜合系統文檔的一部分進行了記錄。通過從這份文檔開始，您可以簡化威脅建模過程，並專注於識別潛在的威脅和漏洞，而不是重新創建基礎系統知識。

示例結果或交付成果

至少，構建者應該捕捉解決方案的關鍵組件，包括數據流、假設和設計決策。這為識別潛在威脅奠定了基礎。需要記錄的關鍵元素包括：

清晰地展示應用程序關鍵數據流的數據流圖（DFDs），從請求到響應，詳細說明每個組件或“跳躍”處發生的事情
關於用戶如何預期與系統交互和詢問問題的明確假設，或模型如何與系統的其他部分進行互動。例如，在RAG場景中，模型需要檢索存儲在其他系統中的數據，它將如何進行身份驗證並將該數據轉換為適合用戶的響應
業務做出的關鍵設計決策的文檔，包括這些決策背後的理由
有關應用程序的詳細業務背景，例如是否被視為關鍵系統、處理何種數據（例如，機密、高完整性、高可用性），以及應用程序的主要業務關注點（例如，數據機密性、數據完整性、系統可用性）

圖1顯示了Threat Composer如何讓您在應用程序信息、架構、數據流和假設部分中輸入有關應用程序的信息。

圖1：生成性AI聊天機器人示例的Threat Composer數據流圖視圖

可能出現什麼問題？

對於這個問題，您使用為上一個問題收集的背景和信息來識別可能對您的應用程序構成威脅。為了幫助您識別可能的威脅，利用現有的知識庫，特別是那些與您正在採用的新技術相關的知識庫。這些通常包含可以應用於您的應用程序的具體示例。有用的資源包括LLMs的OWASP前10名、MITRE ATLAS框架和AI風險存儲庫。您還可以使用結構化框架，例如STRIDE，以幫助您思考。使用您從“我們在構建什麼？”問題中獲得的信息，並將最相關的STRIDE類別應用到您的思考中。例如，如果您的應用程序托管著業務不願意失去的關鍵數據，那麼您可能會首先考慮各種信息披露威脅。

您可以將這些可能的威脅以威脅陳述的形式進行書寫和記錄。威脅陳述是一種在記錄您的威脅時保持一致性和簡明性的方式。在AWS，我們遵循的威脅語法如下：

一個[威脅來源]具有[前提條件]可以[威脅行動]，這導致[威脅影響]，對[受影響資產]產生負面影響。

這種威脅語法結構幫助您保持一致性，並允許您迭代性地撰寫有用的威脅陳述。如圖2所示，Threat Composer為您提供了新威脅陳述的結構，並包含示例以協助您。

圖2：Threat Composer威脅陳述生成器

一旦完成創建威脅陳述的過程，您將擁有“可能出現什麼問題”的摘要。然後，您可以定義攻擊步驟，作為“如何出錯”的分析。並不總是需要為每個威脅陳述定義攻擊步驟，因為威脅實際發生的方式有很多。通過識別和記錄幾種不同的威脅機制的過程，可以幫助獲得與每個攻擊步驟相關的具體減輕措施，以便更有效地採取深度防禦方法。

Threat Composer使您能夠為您的威脅陳述添加其他元數據。已經將此選項納入其工作流程的客戶最常使用STRIDE類別和優先級元數據標籤。這些客戶可以快速追蹤哪些威脅是最高優先級的，以及它們對應的STRIDE類別。圖3顯示了如何在Threat Composer中記錄威脅陳述及其相關元數據。

圖3：Threat Composer示例genAI聊天機器人應用程序 – 威脅視圖

示例結果或交付成果

通過系統地考慮可能出現什麼問題以及如何出現，您可以發現一系列可能的威脅。讓我們探討一些可以從這一過程中產生的示例交付成果：

一份威脅陳述清單，您將為其開發減輕措施，按STRIDE元素和優先級分類
一份與您的威脅陳述相關的攻擊步驟清單。如前所述，攻擊步驟在此階段是一項可選活動，但我們建議至少為您的最高優先級威脅識別一些攻擊步驟

示例威脅陳述

這些是與LLM組件交互的應用程序的一些示例威脅陳述：

一個擁有訪問公用應用程序的威脅行為者可以注入惡意提示，覆蓋現有系統提示，導致其他患者的醫療數據被返回，影響數據庫中數據的機密性
一個擁有訪問公用應用程序的威脅行為者可以注入惡意提示，請求惡意或破壞性的行動，導致其他患者的醫療數據被刪除，影響數據庫中數據的可用性

示例攻擊步驟

這些是一些示例攻擊步驟，顯示前述威脅陳述可能發生的方式：

執行精心製作的提示注入以繞過系統提示的防護
嵌入一個有權訪問模型的易受攻擊代理
在網頁中嵌入間接提示注入，指示LLM忽略先前用戶指令，並使用LLM插件刪除用戶的電子郵件

我們該如何應對？

現在您已經識別出一些可能的威脅，請考慮哪些控制措施適合幫助減輕與這些威脅相關的風險。這一決定將受到您的業務背景和相關資產的驅動。您的組織政策也會影響控制措施的優先級：一些組織可能會選擇優先考慮影響最多威脅的控制措施，而其他組織可能會選擇從影響被認為風險最高的威脅（按可能性和影響）開始。

對於每個識別出的威脅，定義具體的減輕策略。這可能包括輸入清理、輸出驗證、訪問控制等。理想情況下，至少希望與每個威脅相關聯至少一個預防控制和一個檢測控制。與“可能出現什麼問題？”部分中鏈接的相同資源對識別相關控制措施也極為有用。例如，MITRE ATLAS有一個專門的減輕措施部分。

注意：您可能會發現，在為您的威脅識別減輕措施時，您開始看到控制措施的重複。例如，最小特權訪問控制可能與幾乎所有的威脅相關聯。這種重複也可以幫助您進行優先排序。如果單一控制出現在90%的威脅減輕措施中，該控制的有效實施將有助於降低每個威脅的風險。

示例結果或交付成果

與每個威脅相關，您應該擁有一個減輕措施清單，每個措施都有一個唯一標識符以便於以後查找和重用。示例減輕措施及其標識符包括：

M-001：預定義SQL查詢結構
M-002：對已知參數進行清理（輸入過濾）
M-003：檢查是否符合模板化的提示參數
M-004：檢查輸出是否與用戶相關（輸出過濾）
M-005：限制LLM上下文窗口
M-006：對模型執行的高風險行為進行動態權限檢查（將身份驗證參數與提示分開）
M-007：對應用程序所有組件應用最小特權

有關您的工作負載相關安全控制的更多信息，我們建議您閱讀《安全生成性人工智能系列》第3部分：應用相關安全控制。

圖4顯示了在Threat Composer中完成的一些示例威脅陳述，並鏈接到每個陳述的減輕措施。

圖4：完成的威脅陳述，帶有元數據和鏈接的減輕措施

在回答前三個問題後，您已經完成了威脅模型。文檔應該包含您的DFD、威脅陳述、[可選]攻擊步驟和減輕措施。

有關更詳細的示例，包括顯示威脅摘要細分的可視化儀表板，請參見Threat Composer中的完整GenAI聊天機器人示例。

我們的工作做得夠好嗎？

威脅模型是一份活文檔。這篇文章討論了如何創建威脅模型幫助您識別針對威脅的技術控制，但考慮威脅建模過程提供的非技術性好處同樣重要。

在您的最終活動中，您應該驗證威脅建模活動的兩個要素。

驗證所識別的減輕措施的有效性：您識別的一些減輕措施可能是新的，而有些您可能已經實施。無論如何，持續測試和驗證您的安全措施是否按預期工作是重要的。這可能涉及滲透測試或自動安全掃描。在AWS中，威脅模型作為自動測試用例的輸入，以嵌入管道中。定義的威脅也用於定義滲透測試的範圍，以確認這些威脅是否已得到充分減輕。

驗證過程的有效性：威脅建模根本上是一項人類活動。它需要在您的業務、構建團隊和安全職能之間的互動。與應用程序的創建和運行最接近的人應該擁有威脅模型文檔並經常重新訪問它，並得到其安全團隊（或安全守護者等效項）的支持。進行這項工作的頻率將取決於您的組織政策和工作負載的關鍵性，但定義觸發條件以啟動對威脅模型的審查是重要的。示例觸發條件包括威脅情報更新、顯著改變數據流的新功能，或影響系統的安全相關方面的新功能（例如身份驗證或授權，或日誌記錄）。定期驗證您的過程在您採用新技術時尤為重要，因為這些技術的威脅環境演變速度比平常快。

對威脅建模過程進行回顧也是一個很好的方法，可以幫助討論什麼運作良好，什麼運作不佳，以及您將在下次重新訪問威脅模型時承諾的變更。