LLM安全入門：為初學者破解大語言模型

本文試圖為那些對 LLM 安全性感興趣的人提供第一本入門書。

基本建議：

• 不要相信 LLM 的輸出，在使用之前儘量檢查輸出。這對於與輸出互動的人以及依賴輸出的系統或元件都適用。
• 從安全形度來看，應將 LLM 本身視為複雜應用程式和系統的一部分。
• 看看威脅，考慮操縱、提取和注入。
• 在測試 LLM 和 LLM 應用程式時，應用人類視角並使用自動化工具以及其他 AI 系統。
• 仔細考慮安全性和實用性之間的權衡。更安全的 LLM（例如，考慮其產生錯誤或有害輸出的可能性）可能不太有用。在其他情況下，可能需要不那麼“強大”但更“謹慎”的 LLM。
• 特別是在檢視 LLM 申請時，不要忘記“常規”安全性，並確保像任何其他申請一樣強化 LLM 申請。

LLM 安全框架
在進一步討論之前，我想指出的是，OWASP 基金會和 MITRE 都發布了與 AI 和 LLM 相關的框架。OWASP LLM 應用程式 Top 10以及MITRE ATLAS™都是很好的起點。

雖然這些框架確實需要進一步開發，但它們對於理解需要考慮的事項確實非常有用。雖然 OWASP 專注於 LLM 應用程式，但 ATLAS™ 還包括與 LLM 狹窄範圍之外的 AI 相關的“對手戰術和技術”。

這兩個框架也成功地構建了 LLM 安全領域的廣闊領域。鑑於視角眾多，找到好的類別非常困難，這兩個框架都可以作為起點。

大語言模型
LLM大語言模型，例如 OpenAI 的 GPT-4，是一種經過訓練的模型，可根據給定的單詞（標記）序列預測以下可能的單詞（標記）。本質上，LLM 只知道序列“天空是……”最有可能由“藍色”完成。

為此，這些模型在龐大的語料庫上進行訓練，本質上表示給定先前序列的單詞（標記）的機率。雖然這似乎是一個相當簡單的目標，但以這種方式訓練的模型在建立和“理解”語言時可能非常強大。使用微調和各種巧妙的訓練方法，LLM 可以塑造成強大的工具，能夠以驚人的能力執行許多與語言（或模式）相關的任務。

由於它們是以這種方式訓練的，因此它們是機率性的，而不是確定性的。因此，我們不能“相信”模型的輸出。即使一個模型在給定一個特定的提示模板的情況下，10 次中有 9 次產生了所需的輸出，但它在剩餘的時間裡可能會做出完全不同的事情。

此外，我們必須記住，這些模型首先是語言模型，而不是知識模型。雖然它們能夠根據訓練資料產生事實輸出，但它們也可以編造新的資訊（幻覺）。

為了與這些模型互動，我們使用自然語言提示。無論是人類與模型還是機器互動，都是如此——輸入始終是自然語言。

它們也是無狀態的：每個提示都會導致一次獨特的互動。為了進行持續的對話，我們需要將之前的對話或其部分內容附加到新的提示中。

提示和提示
提示是模型的輸入，是與 LLM 互動的核心。它們也是我們攻擊模型的主要方式。通常，我們不希望使用者完全控制提示，因為這會讓他們控制 LLM。自然，作為攻擊者，我們希望控制輸入到模型中的提示。

簡而言之，提示是模型嘗試完成的字串。因此，LLM 的輸出通常稱為“完成”。模型有一個（最大）上下文視窗：模型可以處理的最大標記數。更大的上下文視窗意味著模型可以處理更長的提示以及產生更長的輸出。

提示本身（長字串）通常由多個部分組成。其中最有趣的兩個常見部分是所謂的系統提示（通常由執行模型的人設定）和自定義指令（通常由使用者設定）。

提示的這些部分通常被新增到使用者提示的前面，以設定某些模型行為。例如，它們用於設定模型回覆的樣式或所需的輸出。

雖然使用者（通常）只能看到提示中的自己那部分，但傳送給 LLM 的實際提示通常如下所示：

[SYSTEM PROMPT]
[CUSTOM INSTRUCTIONS]

User Prompt (i.e., <font>"the prompt")

惡意/對抗性提示和中毒訓練資料
攻擊者的目標通常是讓模型產生一些不想要的輸出。例如，這可能是有害內容、有效載荷、系統後續步驟的一些錯誤輸入，或者只是一些正在洩露的敏感資訊。

為了實現這一目標，攻擊者通常採用兩種可能的手段：

1. 他們可以嘗試向LLM傳送惡意/對抗性提示，或者
2. 他們可以嘗試毒害訓練資料。

常見安全問題
有一系列與 LLM 相關的常見安全問題。在詳細介紹這些問題之前，我想指出一個由Adversa提供的簡單但有用的模型。
他們認為，基本上有三個類別：

1. 操縱（繞過預期的 AI 行為）
2. 竊取人工智慧系統中的資料
3. 感染（破壞人工智慧決策的質量；秘密控制人工智慧系統）

與 LLM 有關的某些常見安全問題是：

• 模型錯位→ 模型並非（總是）按照預期發揮作用。例如，錯位的模型會產生不想要的、有害的輸出。
• 直接和間接提示注入→ 攻擊者使用精心設計的提示使 LLM 以非預期的方式執行。在間接提示注入期間，惡意/對抗性提示儲存在模型或系統正在訪問的某些內容中（例如網站）。
• 越獄→ 越獄通常是直接提示注入，試圖繞過模型的限制。例如，攻擊者可以利用越獄讓模型產生有害輸出，儘管已經採取了安全措施。
• 毒害訓練資料和操縱內容→ 攻擊者試圖毒害訓練資料以改變模型行為。同樣，攻擊者試圖修改內容，例如新增虛假資訊或偏見。
• 資料提取和資訊洩露→攻擊者試圖從模型或模型本身中提取資料。關於資訊洩露，我們還需要考慮，例如，訓練資料、系統提示、知識庫中的資料、有關其他使用者及其會話的資訊以及系統本身。
• 過度依賴→LLM的成果沒有得到嚴格評估，人們過於依賴LLM。這可能會導致決策失誤或法律問題。
• 隱私→使用者的隱私受到威脅，例如，模型已經根據他們的資料進行了訓練。

LLM 應用型別
由於 LLM 應用型別眾多，很難選擇一系列問題。因此，以下列表作為 LLM 本身的列表，絕對不是全面的。

• 惡意工具或外掛/擴充套件→ LLM 使用惡意元件。
• (不安全的) 外掛與其敏感資料之間的互動​​→ 使用外掛（或其他工具）時，這些外掛與其可以訪問的資料之間可能會存在不安全的互動。
• 不安全的輸入和輸出處理→模型的輸入和輸出未得到正確處理（例如，未經過淨化）。例如，這可能導致惡意輸出被用作輸入的情況。
• 資料洩露→尤其是在 RAG 應用程式中，攻擊者可能會嘗試從知識庫中提取資料。當然，攻擊者也可能嘗試從模型中提取訓練資料以發現敏感資訊。
• 永續性→攻擊者試圖在系統內放置惡意/對抗性提示（例如，系統提示或自定義指令）以獲得對提示的持久控制。
• 提升訪問許可權→ LLM 可能擁有對系統其他部分的提升訪問許可權。透過獲得對 LLM 的控制權，攻擊者可以提升其許可權。
• 傳播感染→一個“受感染的”（提示）LLM 感染其他 LLM 或系統內的資料。
• 程式碼執行→ 許多 LLM 可以在其執行的系統上執行程式碼。控制 LLM 可能使攻擊者獲得 RCE。

LLM紅隊
在 LLM 安全領域，“紅隊”一詞的含義與 IT/網路安全領域中的含義略有不同。在 LLM 安全領域中，該術語的使用範圍非常廣泛，通常指從安全形度測試的所有型別的 LLM。有時它甚至專門用於評估 LLM 及其一致性。

話雖如此，我認為紅隊從定義上來說就是從對抗的角度測試 LLM 和/或 LLM 應用程式。尤其是從 LLM 應用程式來看，紅隊可以理解為端到端的對抗模擬，可能包括藍隊的響應。根據範圍，紅隊對 LLM 應用程式的攻擊包括對訓練資料、底層基礎設施等的攻擊。

方法範圍從“簡單”實驗（例如基本的直接瞬時注入）到系統瞬時工程以及 LLM 與 LLM 的對決。當然，根據測試模型或考慮整個 LLM 應用，所採用的方法將有很大不同。

縱觀紅隊LLM，一般來說，有三種基本方法：

1. 紅隊正在設計提示和人類可理解的對抗樣本。本質上，紅隊正在對 LLM 進行實驗。
2. 紅隊正在使用（自動化）提示工程、提示和示例資料庫等。提示和示例不再一定是人類可以理解的。
3. 紅隊正在讓專門的 LLM（或其他 AI 模型）與相關 LLM 進行對決。整個過程可能會實現自動化。

無論如何，紅隊訓練的目的都是提高模型的安全性（和一致性）。在此過程中，我們通常還會嘗試提高模型和/或應用程式的穩健性。特別是對於 LLM，這通常涉及協商安全性和實用性，如上所述。

當然，還有一系列工具（包括進攻性和防禦性工具）正在開發中。例如，這些工具包括用於提示注入的模糊器（例如 LLMFuzzer）以及用於測試的對抗性提示資料庫（例如Anthropic 的 Red Teaming Attempts或 Allen AI 的 RealToxicityPrompts）。

基本防禦策略
可能的防禦策略列表很長，並且很大程度上取決於模型和/或應用程式的特定架構。但是，有一些策略和措施應該始終考慮在內。

1、模型
考慮到模型（LLM），請確保進行仔細、透明的訓練，並反映模型正在訓練的資料。

這會產生各種影響，包括可能存在的偏見以及資訊洩露的風險。如果您自己不訓練（或微調）模型，請務必儘可能瞭解模型的訓練方式。簡而言之，確保模型的訓練依據是什麼，並儘可能瞭解潛在的偏見。

理想情況下，如果您自己訓練模型，請進行對抗性訓練並嘗試透過訓練使模型更能抵禦攻擊。

一旦你有了訓練好的模型，一定要進行徹底的測試。這包括，首先，使用一系列對抗性提示來測試模型是否能抵禦注入。最終，你要確保模型的行為符合預期，即使遇到極端情況也是如此。這包括建立（專門的）測試套件，你可以定期使用，尤其是在部署模型的修改版本時。也就是說，鑑於這些模型的非確定性，測試永遠不會是 100% 的解決方案。

2、系統和應用
考慮整個系統或應用程式，確保在資料管道的每個步驟中執行資料驗證和過濾。永遠不要相信 LLM 的輸入或輸出。例如，如果 LLM 要生成 JSON，則第一道防線可能是在進入下一步之前驗證是否已生成有效的 JSON。當然，這可以並且應該擴充套件到例如事實核查或過濾不需要的內容。

一般來說，對使用者儘可能透明也是最佳做法。例如，告知使用者已知的偏見，或者如果可能的話，告知使用者對輸出的置信度。

除了驗證和過濾之外，您還可以並且應該應用防禦性提示工程。例如，告訴模型應該以何種格式輸出資料，並提供惡意示例以及處理它們的規則。在您自己的提示模板中嵌入使用者提示也是一種很好的做法，使用自然語言限制提示中有多少內容由使用者（或其他 LLM）控制。

最後，確保總體安全態勢良好。考慮應用程式的所有元素，確保不會忘記其他更傳統的安全方面。當然，這包括仔細考慮連線的服務和資料來源。

作為進攻（和防禦）工具
本文將 LLM 和 LLM 應用程式視為可能存在漏洞的事物，需要從安全形度進行考慮。

然而，LLM 也可以被威脅行為者和安全專家用作有價值的工具。一些用例可能包括：

• 使用 LLM（可以作為軟體開發中的強大工具）進行工具和惡意軟體開發。
• 使用 LLM 快速理解、分析和建立指令碼、配置檔案等。這在遇到不熟悉的系統時可能特別有用。
• 使用 LLM 分析樣本和日誌檔案。
• 使用 LLM 自動化社會工程攻擊（例如，建立網路釣魚郵件）。
• 使用 LLM 來自動化部分測試過程（例如，使用代理系統）。
• 使用 LLM 協助（或自動化）撰寫報告。