【人工智能】人工智能威胁建模——改变你看待信任边界的方式

本博客将重点介绍目前为威胁建模产品/服务与基于AI/ML的服务交互或依赖这些服务而存在的框架
这对我来说是一个有趣的话题，因为渴望利用LLM潜力的企业正在迅速将其整合到他们的运营中，但这些用例挑战了目前对信任边界的理解，并超过了全面安全协议的建立，使许多应用程序容易受到高风险问题的影响。
信任边界是指系统内或系统之间的安全/在我们控制下/可信和不安全/超出我们控制/不可信区域之间的界限。在集成基于AI/ML的服务或产品时，由于AI的固有特性，这些信任边界会发生变化和扩展。
以下是信任边界随AI变化的几种方式：

• 数据处理的复杂性增加
  • 人工智能系统经常处理大量数据。信任边界不仅包括人工智能模型，还包括它所训练的数据，需要从数据收集到处理和存储的安全处理。
• 人工智能的动态性和学习性
  • AI模型根据新数据不断学习和适应。信任边界超越了静态系统，包括正在进行的学习过程，因此有必要采取措施确保传入数据和适应过程本身的完整性。
• 系统中的互联性
  • 随着人工智能被整合到更大的系统或生态系统中，信任边界在相互连接的组件之间扩展，需要一种全面的安全方法来保护整个系统。人工智能模型可能容易受到对抗性攻击，操纵输入会导致不正确的输出，并影响下游系统

什么可以帮助我们应对这种模糊性并保护基于人工智能的应用程序？

威胁建模可以帮助理解在创建与基于AI/ML的服务交互或依赖于基于AI/ML服务的产品/服务或以AI/ML为核心构建产品/服务时，信任边界是如何变化的
通过威胁建模，我们可以在早期更好地了解这些场景，以保护我们的模型和依赖这些模型的应用程序。我们可以预测其中一些威胁，并通过威胁建模来规划应对方法
威胁建模是一种基于风险的设计安全系统的方法。它基于识别威胁，以制定缓解措施。随着网络安全风险的增加，企业越来越意识到自己的责任，以及对驾驭人工智能浪潮并快速交付演示的期望，软件交付团队最好从威胁建模练习开始，以消除以后可能代价高昂的考虑因素。

但是，我们如何开始使用威胁建模LLM呢？

我们可以使用OWASP为LLM创建的列表，其中他们创建了一个可操作的资源，其中包含一组漏洞，以及常见示例、预防技巧、攻击场景和参考，并使用此资源构建威胁建模练习中要问的问题。

问题：

以下是我整理的帮助我进行人工智能威胁建模的问题列表。这绝不是一个详尽的列表，但应该被视为一个起点。web应用程序的STRIDE方法论仍然屹立不倒，以下问题只是这里提到的问题之外的问题——https://thoughtworksinc.github.io/sensible-security-conversations/ 

提示注入：

攻击者可以通过精心设计的输入操纵LLM，使其执行攻击者的意图

攻击场景：

• 恶意用户上传带有提示注入的简历。由于及时注射，LLM说是的，尽管实际简历内容
• 攻击者向基于LLM的支持聊天机器人提供直接提示注入。注入包含“忘记所有先前的指令”，并执行查询私有数据存储的新指令。
   

问题：

• 您对该内容进行了什么样的输入验证和净化？
• 你的LLM遵循最小特权原则吗？
• 特权操作是否需要人工批准？

不安全的输出处理：

当下游组件在没有适当审查的情况下盲目接受LLM输出时，就会出现不安全输出处理漏洞

攻击场景：

• 应用程序利用LLM插件为聊天机器人功能生成响应。
• 但是，应用程序直接将LLM生成的响应传递给内部函数，而不进行适当的验证。
• 这允许攻击者操纵LLM输出以执行任意命令

问题：

• 您的LLM数据是否直接输入到系统shell或类似函数中？
• 输出是否正在编码？

训练数据中毒：操纵数据以引入漏洞、后门或偏见，从而损害模型的安全性、有效性或道德行为。

攻击场景：

• 受害者模型使用伪造的信息进行训练，这些信息反映在生成性人工智能提示的输出中。
• 如果训练数据没有被正确过滤和/或净化，应用程序的恶意用户可能会试图影响并将有毒数据注入模型

问题：

• 如果你的数据被毒害或篡改，你怎么知道？
• 你有什么遥测技术来检测训练数据质量的偏差？
• 您是否根据用户提供的输入进行培训？
• 您是否确保有足够的沙盒来防止模型抓取意外的数据源？

模型拒绝服务：

攻击者与LLM交互的方法消耗了异常大量的资源，导致他们和其他用户的服务质量下降，并可能导致高昂的资源成本。

攻击场景：

• 攻击者不断用超出其上下文窗口的输入轰炸LLM。攻击者可能会使用自动化脚本或工具发送大量输入，从而压倒LLM的处理能力。因此，LLM消耗了过多的计算资源，导致系统速度显著减慢或完全无响应。

问题：

• 您是否限制每个请求或步骤的资源使用？
• 您是否持续监控LLM的资源利用率，以识别可能表明DoS攻击的异常峰值或模式？
• 您是否强制执行API速率限制，以限制单个用户或IP地址在特定时间段内可以发出的请求数量？
• 您是否限制了对LLM响应做出反应的系统中排队操作的数量和总操作的数量？

供应链漏洞：

LLM中的供应链可能存在漏洞，影响训练数据、机器学习模型和部署平台的完整性。这些漏洞可能导致有偏见的结果、安全漏洞，甚至完全的系统故障。

攻击场景：

• 攻击者利用易受攻击的Python库来危害系统。这发生在第一次开放式人工智能数据泄露事件中。

问题：

• 您是否实施了修补策略来减轻易受攻击或过时的组件？
• 你有审查数据来源的程序吗？
• 您是否实施了监控，以涵盖组件和环境漏洞扫描、使用未经授权的插件和过时的组件，包括模型及其工件？

敏感信息披露：

LLM应用程序可能会无意中披露敏感信息、专有算法或机密数据，导致未经授权的访问、知识产权盗窃和隐私泄露。

攻击场景：

• 由于用户自身或LLM应用程序的疏忽，PII等个人数据通过训练数据泄露到模型中。这种情况可能会增加攻击的风险和概率

问题：

• 分类是为了记录你的训练数据的敏感性吗？
• 您如何确保对LLM回复中的敏感信息进行适当过滤？
• 对外部数据源的访问（运行时的数据编排）是否受到限制？
• 你能防止过度装配吗？
• 是否适用最小特权规则？
• 您如何确保不对模型进行最高权限用户可以访问的信息的训练，这些信息可能会显示给较低权限的用户？

不安全的插件设计：LLM插件是扩展，启用后，在用户交互期间由模型自动调用。它们由模型驱动，对执行没有应用程序控制。

攻击场景：

• 攻击者使用间接提示注入来利用一个没有输入验证和弱访问控制的不安全代码管理插件来转移存储库所有权，并将用户从其存储库中锁定

问题：

• 您是否应用了一层类型化调用，其中引入了对请求的解析，并且无法进行严格的参数化输入？
• 你的插件设计是否考虑了最小权限访问控制？
• 您的插件是否使用适当的身份验证标识（如OAuth2）来应用有效的授权和访问控制？
• 您是否使用API密钥为反映插件路由而不是默认交互式用户的自定义授权决策提供上下文？
• 您的敏感插件是否需要手动用户授权和确认所采取的任何操作？

过度代理：

基于LLM的系统通常由其开发人员授予一定程度的代理权，即与其他系统交互并根据提示采取行动的能力。

攻击场景：

• 基于LLM的个人助理应用程序可以通过插件访问个人的邮箱，以总结收到的电子邮件的内容。为了实现这一功能，电子邮件插件需要读取消息的能力，但是系统开发人员选择使用的插件也包含发送消息的功能。LLM容易受到间接提示注入攻击，恶意制作的传入电子邮件会诱使LLM命令电子邮件插件调用“发送消息”函数，从用户的邮箱发送垃圾邮件。

问题：

• 您是否将LLM插件/工具中实现的功能限制在必要的最低限度？
• 您是否跟踪用户授权和安全范围，以确保代表用户采取的操作在特定用户的上下文中在下游系统上执行？
• 您是否在下游系统中实施授权，而不是依赖LLM来决定是否允许操作？
• 您是否记录和监控LLM插件/工具和下游系统的活动，以识别发生不良行为的地方，并做出相应的响应？

过度依赖（技术列表中非常人性化的脆弱性）：

过度依赖LLM可能会导致严重的后果，如错误信息、法律问题和安全漏洞。当LLM被信任在没有充分监督或验证的情况下做出关键决策或生成内容时，就会发生这种情况。

攻击场景：

• 人工智能提供误导性信息导致虚假信息
• AI的代码建议引入了安全漏洞
• 开发人员在不知不觉中集成了AI建议的恶意软件包。

问题：

• 定期监控和审查LLM输出的流程是什么？
• 您是否将LLM输出与可信来源进行交叉检查？

模型盗窃：

LLM模型盗窃涉及未经授权访问和泄露LLM模型，有经济损失、声誉受损和未经授权获取敏感数据的风险。强大的安全措施对于保护这些模型至关重要。

攻击场景：

• 攻击者使用精心选择的输入查询API，并收集足够数量的输出以创建影子模型。
• 供应链中存在安全控制故障，导致专有模型信息的数据泄露

问题：

• RBAC实现了吗？
• 是否实施了速率限制？
• 是否会检测到提取查询？
• 有哪些政策可以从盗窃或违规中恢复？

这是我试图理解各种框架，这些框架具有常见的攻击场景、漏洞和参考，旨在弥合一般应用程序安全原则与LLM带来的具体挑战之间的鸿沟。

作为威胁模型LLM，请分享您的问题，以便我们一起练习并变得更好。