機器學習有希望改善我們的世界，而且在很多方面它已經做到了。然而，研究和生活經驗繼續表明，這項技術存在風險。過去僅限于科幻小說和學術界的能力越來越多地向公眾開放。負責任地使用和開發人工智能需要在可行的情況下對列舉的風險進行分類、評估和減輕。從純人工智能的角度來看，這是真的，但從標準信息安全的角度來看也是如此。
在標準到位和成熟的測試站穩腳跟之前，各組織都在使用紅隊來探索和列舉人工智能帶來的直接風險。這篇文章介紹了 NVIDIA 人工智能紅隊的理念和 ML 系統的一般框架。
評估基礎
我們的人工智能紅隊是一支由進攻性安全專業人員和數據科學家組成的跨職能團隊。我們使用我們的綜合技能來評估我們的 ML 系統，以從信息安全的角度識別并幫助減輕任何風險。
信息安全有很多有用的范例、工具和網絡訪問，使我們能夠在所有領域加快負責任的使用。該框架是我們的基礎，并將評估工作引向組織內的標準。我們使用它來指導評估（圖 1 ）實現以下目標：
- 我們的組織關心并希望消除的風險得到了解決。
- 明確規定了所需的評估活動以及各種戰術、技術和程序（ TTP ）。 TTP 可以在不改變現有結構的情況下添加。
- 我們評估范圍內的系統和技術有明確的定義。這有助于我們保持對 ML 系統的關注，而不會偏離其他領域。
- 所有的工作都存在于一個單一的框架中，利益相關者可以參考該框架，并立即對 ML 安全性有一個大致的了解。
這有助于我們設定評估的預期，我們可能影響的系統，以及我們應對的風險。該框架并不特定于紅團隊，但其中一些屬性是功能性 ML 安全程序的基礎，紅團隊只是其中的一小部分。
具體的技術和哪些功能并不一定重要。重要的是，無論你是紅隊、漏洞掃描還是對 ML 系統進行任何類型的評估，一切都有一個地方可以去。
該框架使我們能夠解決 ML 管道、基礎設施或技術的特定部分中的特定問題。它成為一個向受影響的系統傳達問題風險的地方：向上和向下，并為政策和技術提供信息。
任何給定的小節都可以在整個系統的上下文中進行隔離、擴展和描述。以下是一些示例：
- 規避被擴展為包括與特定模型類型的評估相關的特定算法或 TTP 。紅色團隊可以準確地指出受影響的基礎設施組件。
- 技術漏洞可以影響任何級別的基礎設施或僅影響特定的應用程序。它們可以根據其職能和相應的風險評級進行處理。
- 對許多信息安全從業者來說陌生的傷害和濫用場景不僅被包括在內，而且被整合在一起。通過這種方式，我們激勵技術團隊在評估 ML 系統時考慮傷害和濫用場景。或者，他們可以為道德團隊提供工具和專業知識。
- 傳遞下來的需求可以更快地集成，包括舊的和新的。
這樣的框架有很多好處。考慮一下披露流程可以從這種冷靜的觀點中獲益。核心構建塊是治理、風險和合規（ GRC ）以及機器學習（ ML ）開發。
治理、風險和合規
與許多組織一樣， GRC 是信息安全工作的最高級別，可確保列舉、傳達和實施業務安全需求。作為一支打著信息安全旗號的人工智能紅隊，以下是我們感興趣的高級別風險：
- 技術風險：ML 系統或過程由于技術漏洞或缺點而受到損害。
- 聲譽風險：模型性能或行為對組織的反映很差。在這個新的范式中，這可能包括發布一個具有廣泛社會影響的模型。
- 合規風險：ML 系統不合規，導致罰款或降低市場競爭力，就像 PCI 或 GDPR 一樣。
這些高級別風險類別存在于所有信息系統中，包括 ML 系統。把這些類別想象成燈上的單獨彩色透鏡。使用每一種彩色鏡片都可以從不同的角度看待底層系統的風險，有時風險可能是疊加的。例如，導致違約的技術漏洞可能會造成聲譽損害。根據違約發生的地點，合規還可能需要違約通知、罰款等。
即使 ML 沒有自己的漏洞，它仍然是在受 GRC 工作制定的標準約束的基礎設施上開發、存儲和部署的。組織內的所有資產都必須符合 GRC 標準。如果他們沒有，理想情況下只是因為管理層提出并批準了一個例外。
ML 開發
堆棧的底部是 ML 開發生命周期，因為它是 GRC 想要深入了解的活動。我們通常將 ML 系統視為任何涉及 ML 的系統，包括構建模型的過程和系統。 ML 系統的組件可能包括托管用于推理的模型的 web 服務器、保存訓練數據的數據湖，或者使用模型輸出來做出決策的系統。
開發管道跨越多個系統，有時甚至是不協調的系統。生命周期的每個階段在功能上都是唯一的，并且依賴于前一個階段。正因為如此， ML 系統往往是緊密集成的，管道的任何一個部分的折衷都可能影響其他上游或下游開發階段。
有更詳細的 MLOps 管道，但規范的示例足以成功地將支持工具和服務與其生命周期階段分組（表 1 ）。
| 階段 | 描述 | 模型狀態 |
| 理想 | 討論、會議和對需求的意圖。 | 前期開發 |
| 數據收集 | 模型需要數據進行訓練。數據通常是從公共和私人來源收集的，并考慮到特定的模型。這是一個持續的過程，數據將繼續從這些來源收集。 | 訓練 |
| 數據處理 | 所收集的數據在被引入用于訓練和推理的算法之前以任何數量的方式進行處理。 | 訓練 |
| 模特培訓 | 然后通過算法獲取處理后的數據，并訓練模型。 | 訓練 |
| 模型評估 | 訓練模型后，對其進行驗證，以確保準確性、穩健性、可解釋性或任何數量的其他度量。 | 訓練 |
| 模型部署 | 經過訓練的模型被嵌入到一個系統中，以便在生產中使用。機器學習以多種方式部署：在自主車輛內部、在 web API 上或在客戶端應用程序中。 | 推論 |
| 系統監控 | 模型部署完成后，將對系統進行監控。這包括系統的可能與 ML 模型不直接相關的方面。 | 推論 |
| 生命的終結 | 數據轉移、業務需求變化和創新都需要適當地中斷系統。 | 后期開發 |
這種高級結構使風險能夠被放入整個 ML 系統的上下文中，并提供了一些自然的安全邊界。例如，在階段之間實現權限分層可能會防止事件跨越整個管道或多個管道。無論是否妥協，管道的目的都是部署模型以供使用。
方法和用例
該方法試圖涵蓋與 ML 系統相關的所有主要問題。在我們的框架中，任何給定的階段都可以交給一個技術熟練的團隊：
- 現有的攻擊性安全團隊可能具備執行偵察和探索技術漏洞的能力。
- 負責任的人工智能團隊具備應對傷害和虐待場景的能力。
- ML 研究人員具備處理模型漏洞的能力。
我們的 AI 紅隊更喜歡將這些技能匯總在同一支或相鄰的隊伍中。學習和效率的提高是不可否認的：傳統的紅隊成員可以通過 學術論文 為數據科學家提供 漏洞披露（CVEs）。
| 評估階段 | 描述 |
| 偵察 | 本階段介紹了在 MITRE ATT&CK 或 MITRE ATLAS |
| 技術漏洞 | 所有你所知道和喜愛的傳統弱點。 |
| 模型漏洞 | 這些漏洞通常來自研究空間，涵蓋以下內容：提取、規避、反轉、成員推斷和中毒。 |
| 傷害和虐待 | 模型通常是經過訓練和分發的，因此它們可能被濫用用于惡意或其他有害任務。模型也可能有意或無意地帶有偏見。或者，它們不能準確地反映部署它們的環境。 |
無論哪個團隊執行哪項評估活動，都將在同一框架內進行，并為更大范圍的評估工作提供信息。以下是一些具體的應用案例：
- 解決新的即時注射技術
- 檢查并定義安全邊界
- 使用權限分層
- 進行桌面練習
解決新的即時注射技術
在這種情況下，大型語言模型（ LLM ）的輸出被笨拙地放入 Python exec 或 eval 語句中。您已經可以看到組合視圖如何幫助解決多個方面的問題，因為輸入驗證是防止即時注入的一層防御措施。
檢查并定義安全邊界
將每個階段與安全控制分隔開來，可以減少攻擊面，并提高對 ML 系統的可見性。一個示例控制可能是 pickle （是的，那個 torch 文件有 pickle ）在開發環境之外被阻止，生產模型必須轉換為不太容易執行代碼的東西，比如 ONNX 。這使得研發人員能夠在開發過程中繼續使用泡菜，但不能在敏感環境中使用泡菜。
雖然完全不使用泡菜是理想的，但安全性通常是妥協。在完全避免問題不可行的情況下，各組織應尋求增加緩解控制措施。
使用權限分層
在開發流程中，了解生命周期每個階段的工具及其屬性非常重要。例如，默認情況下， MLFlow 沒有身份驗證。在知情或不知情的情況下啟動 MLFlow 服務器會打開該主機以通過反序列化進行利用。
在另一個例子中，Jupyter 服務器通常以禁用身份驗證的參數啟動，而 TensorBoard 沒有身份驗證。這并不意味著 TensorBoard 應該有身份驗證。團隊應該意識到這一事實，并確保制定適當的網絡安全規則。
考慮開發管道內所有技術的范圍。這包括一些簡單的事情，比如 HuggingFace 等 ML 服務上的雙因素身份驗證。
進行桌面練習
考慮一下如何清空 ML 開發過程，只考慮您的技術、它們所在的位置以及將應用的 TTP 。沿著煙囪上下移動。以下是一些需要快速思考的場景：
- 部署的 Flask 服務器啟用了調試權限，并暴露在 Internet 上。它托管了一個為 HIPAA 保護的數據提供推斷的模型。
- PII 是作為數據集的一部分下載的，并且已經對幾個模型進行了培訓。現在，一位客戶正在詢問它。
- 一個包含幾個 ML 工件（包括生產模型）的公共 bucket 對公眾開放。它被不正確地訪問，文件也被更改。
- 盡管模型是準確和最新的，但有些人可以始終繞過內容過濾器。
- 某個模型在某些地理區域的表現不如預期。
- 有人正在從用于托管 LLM 的推理服務器掃描內部網絡。
- 系統監控服務檢測到有人針對推理服務發送了眾所周知的數據集。
這些可能有點做作，但要花一些時間把各種技術放在正確的桶里，然后通過方法論逐步提升。
- 這聽起來像是技術漏洞導致的問題嗎？
- 這是否會影響任何 ML 流程？
- 誰負責這些模型？他們會知道是否已經做出了改變嗎？
這些都是必須回答的問題。其中一些場景似乎立即融入了方法的一個部分。然而，仔細觀察，你會發現它們大多跨越多個領域。
結論
這個框架已經為您提供了幾個熟悉的范式，您的組織可以開始圍繞這些范式制定戰略。通過有原則的方法，您可以為構建持續的安全改進奠定基礎，從產品設計到生產部署，達到標準和成熟度。我們邀請您采用我們的方法，并根據您自己的目的進行調整。
我們的方法沒有規定行為或過程。相反，它旨在組織他們。您的組織可能已經有了成熟的流程來發現、管理和減輕與傳統應用程序相關的風險。我們希望此框架和方法能夠為您識別和減輕組織中部署的 ML 組件帶來的新風險做好類似的準備。
如果您有任何問題，請在下面發表評論或聯系 threatops@nvidia.com。
?
