本人从事网路安全工作12年,曾在2个大厂工作过,安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过,对这个行业了解比较全面。
最近遍览了各种网络安全类的文章,内容参差不齐,其中不伐有大佬倾力教学,也有各种不良机构浑水摸鱼,在收到几条私信,发现大家对一套完整的系统的网络安全从学习路线到学习资料,甚至是工具有着不小的需求。
最后,我将这部分内容融会贯通成了一套282G的网络安全资料包,所有类目条理清晰,知识点层层递进,需要的小伙伴可以点击下方小卡片领取哦!下面就开始进入正题,如何从一个萌新一步一步进入网络安全行业。
需要体系化学习资料的朋友,可以加我V获取:vip204888 (备注网络安全)
学习路线图
其中最为瞩目也是最为基础的就是网络安全学习路线图,这里我给大家分享一份打磨了3个月,已经更新到4.0版本的网络安全学习路线图。
相比起繁琐的文字,还是生动的视频教程更加适合零基础的同学们学习,这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。
网络安全工具箱
当然,当你入门之后,仅仅是视频教程已经不能满足你的需求了,你肯定需要学习各种工具的使用以及大量的实战项目,这里也分享一份我自己整理的网络安全入门工具以及使用教程和实战。
项目实战
最后就是项目实战,这里带来的是SRC资料&HW资料,毕竟实战是检验真理的唯一标准嘛~
面试题
归根结底,我们的最终目的都是为了就业,所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
数据毒化被视为完整性攻击,因为篡改训练数据会影响模型输出正确预测的能力。由于模型创建者无法控制外部数据源,使得外部数据源具有更高的风险。模型创建者也没有高度的信心来确认内容不包含偏见、伪造信息或不适当的内容。这就使得训练数据毒化是一个不容忽视的风险。
3.2 攻击举例
- LLM生成式人工智能提示输出可能会误导应用程序的用户,从而导致偏见观点、追随者甚至更糟的情况,比如仇恨犯罪等。
- 如果训练数据没有正确过滤和/或清理,应用程序的恶意用户可能会尝试影响并向模型注入有毒数据,以使其适应偏见和虚假数据。
- 恶意行为者或竞争对手故意创建不准确或恶意的文档用作模型的训练数据,而该模型正以此数据作为输入进行训练。受害模型使用这些伪造的信息进行训练,就会反映在生成式AI提示输出中传递给其消费者。
- 如果使用LLM应用程序的客户端输入来进行模型训练时未进行足够的清理和过滤,那么“提示注入”漏洞可能成为此漏洞的攻击向量。也就是说,可以利用提示注入攻击手段将恶意或伪造的数据从客户端输入到模型中,这样进入到模型的数据自然就包含了被毒化的数据。
3.3 如何防范
- 验证训练数据的供应链,特别是使用从外部获取的数据时,并通过“ML-BOM”(机器学习物料清单)方法保持认证,同时验证模型卡。
- 验证目标数据源的正确合法性,以及验证在预训练、微调和embedding阶段获取的数据的合法性。
- 验证需要集成到LLM和应用程序中的use case。使用不同的训练数据或微调为不同的use-cases 创建不同的模型,以根据其定义的use-case创建更细粒度和准确的生成式AI输出。
- 确保通过网络控制存在足够的沙盒化,以防止模型抓取非预期数据源中数据,这可能会妨碍机器学习输出。
- 对特定训练数据或数据源类别使用严格的审查或输入过滤器,以控制伪造数据的数量。使用数据清理技术,如统计异常值检测和异常检测方法,以检测和移除潜在地被输入到微调过程中的对抗性数据。
- 使用对抗鲁棒性技术,如联邦学习和约束条件,以最小化训练数据的异常值或对抗性训练,使其能够抵御对训练数据的最坏情况扰动。
- “MLSecOps”方法可以在训练生命周期中包括使用了自动毒化技术的对抗鲁棒性。
- 这种方法的一个示例存储库是Autopoison测试,包括内容注入攻击(“试图在模型响应中推广品牌名称”)和拒绝攻击(“始终使模型拒绝响应”)等攻击。
- 通过测量训练阶段的损失并分析已训练模型来测试和检测,通过分析模型对特定测试输入的行为,以检测毒化攻击的迹象。
- 监控和警报超过阈值的偏斜响应数量。
- 使用人工环路审查响应和审计。
- 实施专用的LLM来benchmark不良结果,并使用强化学习技术对其他LLM进行训练。
- 在LLM的生命周期的测试阶段执行基于LLM的红队演习或LLM漏洞扫描。
4 模型拒绝服务(LLM04: Model Denial of Service)
4.1 概念描述
与网站安全的DDoS攻击类似,攻击模型拒绝服务漏洞也是通过跟LLM进行某种交互并大量消耗资源,从而导致模型降低服务用户的质量。
与DDoS不同的是,针对LLM的DoS攻击还能通过干扰或操纵LLM的上下文窗口来实施。在LLM中,上下文窗口表示模型可以管理的文本的最大长度,包括输入和输出。这是LLM的一个关键特征,因为它决定了模型可以理解的语言模式的复杂性,以及它可以处理的文本大小。上下文窗口的大小由模型的架构定义,不同的模型可能不同。
总之,模型拒绝服务攻击可以通过大量交互访问或者操控上下文窗口使得模型的服务质量下降或者承受高昂的成本。
4.2 攻击举例
- 攻击者反复向托管模型发送多个复杂和昂贵的请求,导致其他用户服务质量下降,并使主机的资源费用增加。
- 某个LLM驱动的工具收集信息以响应正常查询。当遇到网页上的某段文本,非预期地导致该工具发出更多的网页请求,从而造成大量的资源消耗。
- 攻击者持续不断地向LLM发送超过其上下文窗口的输入。攻击者可能使用自动化脚本或工具发送大量输入,压倒LLM的处理能力。结果,LLM消耗了过多的计算资源,导致系统显著减速或完全无响应。
- 攻击者向LLM发送一系列连续的输入,每个输入都设计为略低于上下文窗口的限制。通过反复提交这些输入,攻击者旨在耗尽可用的上下文窗口容量。这使得LLM在其上下文窗口内处理每个输入都变得困难,进而导致系统资源变得紧张,最终可能导致性能下降或完全拒绝服务。
- 攻击者利用LLM的递归机制反复触发上下文扩展。通过构造特定输入以利用LLM的递归行为,攻击者迫使模型反复扩展和处理上下文窗口,以此消耗大量的计算资源。这种攻击会对系统造成压力,并可能导致DoS情况,使LLM无响应或导致崩溃。
- 攻击者向LLM洪水般地发送大量变长输入,精心设计以接近或达到上下文窗口的限制。通过向LLM发送不同长度的输入,攻击者旨在利用任何处理不同长度输入的低效性(缺陷)。这些输入的洪水会对LLM的资源造成过度负载,可能导致性能下降,并妨碍系统响应合法请求。
- 虽然DoS攻击通常旨在压倒系统资源,但它们也可以利用系统行为的其他方面,比如API限制。例如,在最近的Sourcegraph安全事件中,恶意行为者使用泄露的管理员访问令牌来更改API的速率限制,从而通过启用异常水位的请求量就可能导致服务中断。
4.3 如何防范
- 对输入内容进行验证和净化,确保用户的输入符合定义好的限制,并过滤掉任何恶意内容。
- 限制每个请求或步骤的资源使用,使涉及复杂部分的请求执行速度较慢。
- 强制限制API速率,在特定时间段内限制个人用户或IP地址可以发出的请求数量。
- 如果某个系统需要针对LLM做出响应,那么就要限制队列中的操作数量以及总的操作数量。
- 持续监控LLM的资源利用情况,用以识别可能暗示有DoS攻击的异常波动或模式。
- 对LLM的上下文窗口设置严格的输入限制,以防止过载和资源耗尽。
- 提高开发人员对LLM中潜在DoS漏洞的意识,并提供安全LLM的实施指南。
5 供应链漏洞(LLM05: Supply Chain Vulnerabilities)
5.1 概念描述
在机器学习领域,LLM可能经常采用一些大公司提供的预训练模型,或者采用第三方的数据进行训练。在这些供应链中可能存在漏洞,影响训练数据、机器学习模型和部署平台的完整性。这些漏洞可能导致偏见的结果、安全漏洞,甚至完全的系统故障。这些漏洞可能来源于过时的软件、受影响的预训练模型、被毒化的训练数据和不安全的插件。
5.2 攻击举例
- 如果系统使用了一个存在漏洞的Python库,攻击者可以利用该库使系统处于危险当中。
- 攻击者提供了一个恶意的LLM插件来搜索航班,生成导致用户受骗的虚假链接。
- 攻击者利用PyPi软件包注册表欺骗模型开发者去下载一个受破坏的软件包,并在模型开发环境中窃取数据或提升权限。这是一个真实的攻击案例。
- 攻击者对某个专门用于经济分析和社会研究的公开可用的预训练模型进行毒化,用于创建后门,生成错误信息和假新闻。然后他们将其部署在一个模型市场上(比如 Hugging Face),供受害者使用。
- 攻击者毒化公开可用的数据集,用以在微调模型时帮助创建后门。这个后门暗地里偏向于不同市场中的某些公司。
- 某个违规的供应商员工(外包开发人员、托管公司等)窃取数据、模型或代码,窃取知识产权。
5.3 如何防范
- 仔细审查数据来源和供应商,包括其条款和隐私政策,只使用可信任的供应商。确保有足够的、独立审计的安全措施,并且模型运营者的政策与您的数据保护政策一致,即您的数据不会用于训练他们的模型;类似的,寻求保证和法律措施,以防止模型维护者使用了受版权保护的材料。
- 只使用声誉良好的插件,并确保它们已经根据您的应用需求进行了测试。后文漏洞“不安全的插件设计”部分提供了关于不安全插件设计LLM方面的信息,您可以测试用以降低使用第三方插件的风险。
- 理解并应用“OWASP十大漏洞”中“A06:2021 - 脆弱和过时组件”提到的缓解措施。这包括漏洞扫描、管理和修补组件。对于具有访问敏感数据权限的开发环境,也在这些环境中应用这些控制措施。
- 使用软件材料清单(SBOM)维护组件的最新清单,以确保您拥有最新的、准确的、经过签名的清单,防止部署软件包被篡改。SBOM可以用于快速检测和提醒新的、0-Day漏洞。
- 截至本文档编写时,SBOM不包括模型、工件和数据集。如果您的LLM应用使用自己的模型,您应该使用MLOps的最佳实践和平台来提供包含数据、模型和实验跟踪的安全模型仓库。
- 在使用外部模型和供应商时,还应该使用模型和代码签名。
- 如前文所述漏洞“训练数据毒化”中所讨论的那样,对提供的模型和数据进行异常检测和对抗鲁棒性测试,可以帮助检测篡改和毒化。理想情况下,这应该是MLOps pipeline的一部分;然而,这些新兴的技术也许作为红队演练的一部分更容易去实施。
- 实施足够的监控来覆盖组件和环境的漏洞扫描、未经授权的插件使用、以及过时的组件,也包括模型及其工件。
- 实施补丁政策,用来减轻易受攻击或过时的组件风险。确保应用程序依赖于维护的API版本和底层模型。
- 定期审查和审核供应商的安全和访问权限,确保其安全态势或条款没有变化。
6 敏感信息泄露(LLM06: Sensitive Information Disclosure)
6.1 概念描述
LLM 应用有可能通过它们的输出透露敏感信息、专有算法或其他机密细节。这可能导致未经授权访问敏感数据、知识产权、隐私侵犯和其他安全漏洞。对于 LLM 应用的消费者来说,重要的是要意识到如何安全地与 LLM 进行交互,识别到无意中输入敏感数据的相关风险,这些数据可能随后会由 LLM 返回在其他地方的输出中。
为了减轻这一风险,LLM 应用应该进行充分的数据清洗,以防止用户数据进入训练模型数据。LLM 应用的所有者还应该制定适当的使用条款政策,让消费者了解他们的数据如何被处理,并有权选择不让他们的数据包含在训练模型中。
消费者与LLM应用之间的交互形成了一个双向的信任边界,我们不能天生信任客户端到LLM的输入或LLM到客户端的输出。需要注意的是某些前提条件,比如威胁建模练习、安全基础设施和充分沙箱,本漏洞假设它们是在考虑范围之外的。在系统提示中添加约束来限制LLM应该返回的数据类型,可以在一定程度上减轻敏感信息的泄露。但是作为LLM的基本特性之一的不可预测性,它意味着这种约束可能并不总是能被遵守,并且可能会通过提示注入或其他途径被规避。
6.2 攻击举例
- 毫无戒备心理的合法用户A在与LLM应用非恶意地交互时,通过LLM暴露给了某些其他用户数据。
- 用户A针对LLM发起了一系列精心设计的提示,以绕过LLM的输入过滤器和清洗,导致其透露出应用程序其他用户的敏感信息(PII)。
- 个人数据(例如PII)通过训练数据泄漏到模型中,原因可能是用户本身的疏忽,也可能是LLM应用的原因。这种情况可能增加了上述两种情况的风险和概率。
6.3 如何防范
- 集成充分的数据清洗和擦除技术,防止用户数据成为进入训练模型的数据。
- 实施强大的输入验证和清洗方法,以识别和过滤潜在的恶意输入,防止模型被毒化。
- 当使用数据来丰富模型或微调模型时(即在部署之前或期间输入到模型中的数据):
- 在微调数据中任何被视为敏感的信息都有可能被透露给用户。因此,应用最小权限原则,不要让模型在最高权限用户可以访问但可能显示给较低权限用户的信息上进行训练。
- 对外部数据源的访问(在运行时进行数据编排)应受到限制。
- 对外部数据源使用严格的访问控制方法,并采取严格的方法来维护安全的供应链。
7 不安全的插件设计(LLM07: Insecure Plugin Design)
7.1 概念描述
LLM插件是一种扩展,当启用时,模型在用户交互期间会自动调用它们。模型集成平台驱动它们,且应用程序可能无法控制它的执行,特别是当模型由另一方托管时。此外,插件可能会实现来自模型的自由文本输入,而没有进行验证或类型检查来处理上下文大小限制。这使得潜在的攻击者可以构造一个恶意请求发送到插件,并可能导致一系列不期望的行为,甚至包括远程代码执行。
恶意输入的危害往往取决于不充分的访问控制以及插件之间失败的授权跟踪。不充分的访问控制允许插件盲目地信任其他插件,并假设最终用户提供的输入。这种不足的访问控制可能使恶意输入产生从数据外泄、远程代码执行到权限提升等有害后果。
本条目聚焦于创建LLM插件而不是使用第三方插件,因为在LLM“供应链漏洞”部分涵盖了它。
7.2 攻击举例
- 某插件接受一个基本URL,并指示LLM将URL与查询组合以获取天气预报,这些预报包含在处理用户请求中。恶意用户可以构造一个请求,使URL指向他们控制的域,从而允许他们通过自己的域注入内容到LLM系统中。
- 某插件接受自由形式的输入到某一字段中,但未做验证。于是攻击者输入精心构造的负载,并检测错误消息获取更多可能被利用的信息。然后利用已知的第三方漏洞来执行代码以实施数据外泄或权限提升。
- 某插件用于从向量存储(vector store)中检索嵌入(embedding),并接受配置参数作为连接字符串,但没进行任何验证。这使得攻击者可以通过更改名称或主机参数来试验并访问其他向量存储,并窃取他们不应该访问的嵌入。
- 某插件接受SQL WHERE子句作为高级过滤器,然后将其附加到过滤SQL中。这使得攻击者可以发动SQL攻击。
- 攻击者使用间接提示注入来利用一个不安全的代码管理插件,该插件没有输入验证且访问控制薄弱,以转移代码仓库所有权并锁定用户使得他们无法访问自己的代码仓库。
7.3 如何防范
- 插件应尽可能强制执行严格的参数化输入,并对输入进行类型和范围检查。当这不可行时,则引入额外的类型化调用验证层,解析请求并应用验证和净化。当由于应用语义而必须接受自由形式输入时,应仔细检查以确保没有调用任何潜在有害的方法。
- 插件开发人员应根据OWASP在ASVS(Application Security Verification Strandard 应用程序安全性验证标准)中提供的建议来进行适当的输入验证和清理。
- 应彻底检查和测试插件,以确保充足的验证。在开发管道pipeline中使用静态应用程序安全性测试(Static Application Security Testing, SAST)扫描和动态交互式应用程序测试(Dynamic and Interactive application testing, DAST,IAST)。
- 插件应遵循OWASP ASVS访问控制指南(ASVS Access Control Guidelines),设计为最小化任何利用不安全输入参数所带来的影响。这包括最小特权访问控制,在执行所需功能的同时尽可能暴露少的功能。
- 插件应使用适当的身份验证标识,例如OAuth2,以应用有效的授权和访问控制。此外,API密钥应该用于提供自定义授权决策的上下文,该上下文反应的是插件路由而不是默认的交互用户。
- 对于敏感插件采取的任何操作,都要求用户手动授权和确认。
- 插件通常是REST API,因此开发人员应该采用OWASP Top 10 API安全风险 - 2023(OWASP Top 10 API Security Risks – 2023)中的建议,用以最小化通用漏洞。
8 过度代理(LLM08: Excessive Agency)
8.1 概念描述
通常开发者会授予基于LLM的系统一定程度的代理能力,以使其能与其他系统进行交互,并根据提示来执行某些操作。甚至决定调用哪些功能也可能是委托给LLM的“代理人(agent)”,去根据输入提示或LLM输出来动态确定。
过度代理是这么一种漏洞,能在LLM产生意外/模糊输出时执行破坏性操作(无论是什么原因导致LLM发生故障,是幻觉/虚构、直接/间接提示注入、恶意插件、设计不佳的提示,还是仅仅因为模型性能较差)。过度代理典型的根本原因有以下一个或多个:功能过度、权限过度或自治权过度。与“不安全的输出处理”漏洞不同,后者关注的是对LLM输出的审查不足。
过度代理可能会导致在机密性、完整性和可用性范围内产生广泛的影响,这取决于LLM应用能够与哪些系统进行交互。
8.2 攻击举例
基于LLM的个人助手应用程序通过插件获得了访问个人邮箱的权限,以便总结收件箱中的内容。为了实现这一功能,电子邮件插件需要读取消息的能力,但系统开发者选择使用的这个插件还包含发送消息的功能。当LLM存在间接提示注入攻击的漏洞时,通过传入恶意制作的电子邮件,欺骗LLM命令电子邮件插件调用“发送消息”功能,从用户的邮箱发送垃圾邮件。
8.3 如何防范
以下操作可以防止过度代理:
- 限制LLM代理所允许调用的插件和工具,只使用最小的必要功能。例如,如果基于LLM的系统不需要获取URL的内容,则不应将此类插件提供给LLM代理。
- 限制LLM插件和工具实现的功能,只实现最小的必要功能。例如,用于访问用户邮箱以总结电子邮件的插件可能仅需要读取邮件的能力,因此插件不应包含删除或发送邮件等其他功能。
- 尽可能避免开放式功能(例如运行shell命令、获取URL等),并使用具有更细粒度功能的插件/工具。例如,基于LLM的应用程序可能需要将一些输出写入文件。如果使用插件来运行shell函数实现此目的,则不良操作的范围非常大(可以执行任何其他shell命令)。更安全的替代方案是构建一个只支持特定功能的文件写入插件。
- 访问其他系统的LLM插件及工具,授予它们的权限需要被限制为最小必要的权限,以限制不良操作的范围。例如,LLM代理使用产品数据库向客户提供购买建议,可能它只需要对“产品”表具有读取权限;它不应该访问其他表,也不应该具有插入、更新或删除记录的能力。这通过给标识采用合适的数据库权限来实施,该标识是LLM插件用来链接数据库的。
- 跟踪用户授权和安全的范围,以确保在下游系统中代表用户执行的的操作是在该特定用户的上下文中,并且授予的是最小的必要权限。例如,读取用户代码仓库的LLM插件应要求用户通过OAuth进行身份验证,并且权限范围最小。
- 利用人工控制授权,要求执行所有操作之前需要得到人的批准。这可以在下游系统(LLM应用程序范围之外)或LLM插件和工具本身中实施。例如,代表用户创建并发布社交媒体内容的基于LLM的应用程序应在“发布”操作的插件/工具/API中包含用户批准流程。
- 在下游系统中实施授权,而不是依赖LLM来决定是否允许执行操作。在实现工具或插件时强制实施完全中介原则,所以通过插件和工具对下游系统发出的所有请求都根据安全策略进行了验证。
以下选项不会防止过度代理,但可以限制造成的损害程度:
- 记录并监视LLM插件/工具和下游系统的活动,以确定不良操作发生的位置,并相应地做出响应。
- 实施速率限制,以减少在给定时间段内可能发生的不良操作数量,增加通过监视发现不良操作的机会,以在发生重大损害之前发现它们。
9 过度依赖(LLM09: Overreliance)
9.1 概念描述
过度依赖可能发生在大型语言模型(LLM)产生错误信息并以权威的方式提供它的情况下。虽然LLM可以生成富有创意和信息性的内容,但它们也可能产生事实不正确、不适当或不安全的内容,这被称为幻觉或臆断。当人们或系统在没有监督或确认的情况下信任这些信息时,可能会导致安全漏洞、错误信息、沟通不畅、法律问题和声誉损害。
LLM生成的源代码可能引入未被注意到的安全漏洞,这对应用程序的操作安全和安全性构成了重大风险。
9.2 攻击举例
- 某新闻机构大量使用LLM生成新闻文章。恶意行为者利用这种过度依赖,向LLM提供误导性信息,导致虚假信息的传播。
- 人工智能无意中窃取了相关内容,导致版权问题并降低了组织的信任度。
- 某软件开发团队利用LLM系统加速编码过程。过度依赖AI的建议导致应用程序中出现安全漏洞,可能是由于不安全的默认设置或给出的建议与安全编码实践不一致。
- 某软件开发公司使用LLM来协助开发人员。LLM 建议了一个不存在的代码库或包,开发人员信任人工智能,不知不觉地将恶意包集成到公司的软件中。这也突显了交叉检查LLM建议的重要性,尤其是涉及第三方代码或库时。
9.3 如何防范
- 定期监控和审查LLM的输出。使用自洽性或投票技术来过滤不一致的文本。对于单个提示,比较多个模型响应可以更好地评估输出的质量和一致性。
- 与可信的外部来源交叉检查LLM的输出。这种额外的验证层可以帮助确保模型提供的信息准确可靠。
- 通过精调或嵌入来增强模型以改善输出质量。与特定领域中调整过的模型相比,通用的预训练模型更容易产生不准确的信息。可以采用提示工程、PET(parameter efficient tuning)、全模型调整和思维链提示等技术来实现这一目的。
- 实施自动验证机制,可以将生成的输出与已知事实或数据进行交叉验证。这可以提供额外的安全层,并减轻与幻觉相关的风险。
- 将复杂任务分解为可管理的子任务,并将它们分配给不同的代理。这不仅有助于管理复杂性,还减少了幻觉的可能性,因为每个代理可以负责一个较小的任务。
- 清楚地传达使用LLM时的风险和限制。这包括信息不准确性的潜在风险和其他风险。有效的风险沟通可以使用户为潜在问题做好准备,并帮助他们做出明智的决策。
- 构建API和用户界面以促进负责任地和安全地使用LLM。这包括内容过滤器、有关潜在不准确性的用户警告和AI生成内容的清晰标记。
- 在开发环境中使用LLM时,建立安全的编码实践和指南,以防止可能集成漏洞。
10 模型盗窃(LLM10: Model Theft)
10.1 概念描述
这个条目涉及恶意行为者或APT攻击者未经授权访问和外泄LLM模型的情况。这种情况发生在专有的LLM模型(作为有价值的知识产权)被破坏、物理上被盗窃、复制或权重和参数被提取以创建一个功能上等价的模型的情况。LLM模型被盗窃的影响可能包括经济和品牌声誉损失、竞争优势的侵蚀、模型的未经授权使用或未经授权访问模型内部包含的敏感信息。
因为语言模型变得越来越强大和普及,LLM盗窃也成为了一个重大的安全问题。组织和研究人员必须优先考虑采取强大的安全措施来保护他们的LLM模型,确保其知识产权的保密性和完整性。对于减轻与LLM模型盗窃相关的风险、保护依赖LLM的个人和组织的利益,采用包括访问控制、加密和持续监控等手段在内的综合安全框架至关重要。
10.2 攻击举例
- 攻击者利用公司基础设施的漏洞未经授权地访问了他们的LLM模型仓库。攻击者进而窃取有价值的LLM模型,并使用它们启动了一个竞争性的语言处理服务或者提取了敏感信息,给原始公司造成了重大的财务损失。
- 一名不满的员工泄露了模型或相关的资产。这种情景的公开曝光增加了攻击者进行灰盒对抗性攻击的知识或者直接窃取可用财产的可能性。
- 攻击者通过精心选择的输入查询API,并收集足够数量的输出以创建一个影子模型。
- 在供应链中存在失败的安全控制,导致专有模型信息的数据泄露。
- 恶意攻击者绕过LLM的输入过滤技术和序文,进行侧信道攻击(side-channel attacks),并将模型信息检索到他们控制的远程资源中。
- 最近公布的一篇论文,感兴趣的可以翻阅:Stealing Part of a Production Language Model
10.3 如何防范
- 实施强访问控制(例如: Role-based Access Control(RBAC) 和最小权限原则)和强身份验证机制,限制对LLM模型仓库和训练环境的未经授权访问。 因为内部威胁、配置错误和/或对承载LLM模型、权重和架构这些基础设施的弱安全控制,恶意行为者可能会从内部或外部渗透。供应商管理跟踪、验证和依赖性漏洞是防止供应链攻击利用的重要关注点。
- 限制LLM对网络资源、内部服务和API的访问。这种限制可能是防止侧信道攻击(side-channel attacks)的一种机制或预防步骤。
- 定期监控和审计与LLM模型仓库相关的访问日志和活动,及时检测和应对任何可疑或未经授权的行为。
- 使用治理、跟踪和审批工作流的自动化MLOps部署,以加强基础设施内的访问和部署控制。
- 实施控制和缓解策略,以减轻或减少由提示注入技术引起的侧信道攻击(side-channel attacks)的风险。
- 在适用的情况下对API调用进行速率限制和(或)过滤器,以减少LLM应用程序的数据外泄风险,或者实施从其他监控系统中检测(例如,DLP)提取活动的技术。
- 实施对抗鲁棒性训练,以帮助检测提取查询并加强物理安全措施。
- 在LLM的生命周期中的嵌入和检测阶段实施水印框架。
11. LLM应用风险示例图
文档中这个图片非常赞,可以可视化了解在LLM应用上下游整体环境中前文所述各风险点是如何影响到应用安全的:
参考资料:
视频:OWASP Top 10 for Large Language Model Applications (for AI systems)")
还有兄弟不知道网络安全面试可以提前刷题吗?费时一周整理的160+网络安全面试题,金九银十,做网络安全面试里的显眼包!
王岚嵚工程师面试题(附答案),只能帮兄弟们到这儿了!如果你能答对70%,找一个安全工作,问题不大。
对于有1-3年工作经验,想要跳槽的朋友来说,也是很好的温习资料!
【完整版领取方式在文末!!】
93道网络安全面试题
需要体系化学习资料的朋友,可以加我V获取:vip204888 (备注网络安全)
内容实在太多,不一一截图了
黑客学习资源推荐
最后给大家分享一份全套的网络安全学习资料,给那些想学习 网络安全的小伙伴们一点帮助!
对于从来没有接触过网络安全的同学,我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线,大家跟着这个大的方向学习准没问题。
1️⃣零基础入门
① 学习路线
对于从来没有接触过网络安全的同学,我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线,大家跟着这个大的方向学习准没问题。
② 路线对应学习视频
同时每个成长路线对应的板块都有配套的视频提供:
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!