人工智能漏洞评分系统 (AIVSS)提供了一个标准化、全面的框架,用于评估和量化与人工智能系统相关的安全风险。该框架特别关注大型语言模型 (LLM) 和基于云的部署,同时仍适用于广泛的人工智能系统。AIVSS 将传统的安全漏洞评分概念应用于人工智能的独特特征和挑战,并借鉴了领先的人工智能威胁分类法和安全标准。本文档概述了 AIVSS 框架,包括详细的评分细则、实施检查表以及环境因素的考虑。
传统的漏洞评分系统,例如通用漏洞评分系统 (CVSS),不足以应对人工智能系统带来的独特安全挑战。这些挑战包括:
- 对抗性攻击: 人工智能系统容易受到对抗性攻击,这些攻击通过精心设计的输入来操纵模型行为,这是传统系统无法充分捕捉到的威胁。
- 模型退化: 人工智能模型可能会由于概念漂移或数据中毒而随着时间的推移而退化,从而影响其准确性和可靠性。
- 生命周期漏洞: 人工智能系统具有复杂的生命周期,从数据收集和训练到部署和维护,每个阶段都会引入潜在的漏洞。
- 伦理和社会影响: 人工智能系统可能具有重大的伦理和社会影响,例如偏见和歧视,这些在传统的安全评估中并未考虑。
- 人工智能的动态性: 人工智能系统通常是动态和自适应的,这使得静态评分方法的效果较差。
AIVSS 通过提供一个针对人工智能特定安全风险的全面框架来应对这些挑战。
AIVSS 包含以下关键组件:
基本指标捕获了漏洞的基本特征,这些特征在不同时间和不同环境中保持不变。
- 攻击向量 (AV): 反映漏洞利用的上下文。
- 网络 (N):0.85
- 相邻网络 (A):0.62
- 本地 (L):0.55
- 物理 (P):0.2
- 攻击复杂性 (AC): 衡量攻击者控制之外必须存在才能利用漏洞的条件。
- 低 (L):0.77
- 高 (H):0.44
- 所需权限 (PR): 描述攻击者在成功利用漏洞之前必须拥有的权限级别。
- 无 (N):0.85
- 低 (L):0.62
- 高 (H):0.27
- 用户交互 (UI): 捕获除攻击者之外的用户参与成功入侵易受攻击组件的要求。
- 无 (N):0.85
- 必需 (R):0.62
- 范围 (S): 衡量一个易受攻击组件中的漏洞是否会影响其安全范围之外的组件中的资源。
- 未更改 (U):1.0
- 已更改 (C):1.5
人工智能特定指标捕获了与人工智能系统相关的独特漏洞和风险。这些指标是根据详细的评分细则(在第 4 节中提供)进行评估的。
AISpecificMetrics = [MR × DS × EI × DC × AD × AA × LL × GV × CS] × ModelComplexityMultiplier
- MR (模型稳健性): 评估系统对对抗性攻击和模型退化的抵抗力。
- DS (数据敏感性): 评估与人工智能系统使用的数据的机密性、完整性和来源相关的风险。
- EI (伦理影响): 考虑潜在的偏见、透明度问题、问责制问题和社会影响。
- DC (决策关键性): 衡量人工智能系统做出的不正确或恶意决策的潜在后果。
- AD (适应性): 评估系统适应不断变化的威胁并在一段时间内保持安全性的能力。
- AA (对抗性攻击面): 评估系统暴露于各种对抗性攻击技术的程度。
- LL (生命周期漏洞): 考虑人工智能系统生命周期不同阶段的安全风险。
- GV (治理和验证): 评估治理机制和验证过程的存在性和有效性。
- CS (云安全联盟 LLM 分类法): 解决云环境中 LLM 的特定威胁,如 CSA LLM 威胁分类法所定义。
- 模型复杂度乘数: 根据人工智能模型的复杂度调整人工智能特定指标分数的因子(对于简单模型为 1.0,对于高度复杂模型为 1.5)。
环境指标反映了人工智能系统部署环境的特征,这些特征会影响整体风险。
- 机密性要求 (CR): 衡量维护人工智能系统处理的数据的机密性的重要性。
- 完整性要求 (IR): 衡量维护数据和人工智能系统输出的完整性的重要性。
- 可用性要求 (AR): 衡量确保人工智能系统为其预期目的的可用性的重要性。
- 社会影响要求 (SIR): 衡量减轻人工智能系统潜在负面社会影响的重要性。
这些指标的评级如下:
- 未定义 (X):1.0(默认值,不修改分数)
- 低 (L):0.5
- 中 (M):1.0
- 高 (H):1.5
这些指标基于基本指标,但可以根据特定环境进行修改:
- 修正的攻击向量 (MAV)
- 修正的攻击复杂性 (MAC)
- 修正的所需权限 (MPR)
- 修正的用户交互 (MUI)
- 修正的范围 (MS)
这些指标的评级方式与基本指标相同,并增加:
- 未定义 (X):使用未修改的基本指标值。
人工智能特定指标中的每个子类别都按 0.0 到 1.0 的等级进行评分,具有以下一般解释:
- 0.0:未知漏洞: 表示没有已知漏洞或对特定威胁有正式证明的抵抗力。
- 0.1 - 0.3:低漏洞: 表示存在低漏洞,并采取了强有力的缓解措施,但仍可能存在一些小的弱点。
- 0.4 - 0.6:中等漏洞: 表示存在中等漏洞,并采取了一些缓解措施,但仍存在明显的弱点。
- 0.7 - 1.0:严重/高漏洞: 表示存在严重漏洞,几乎没有或没有采取缓解措施。
MR (模型稳健性)
-
规避抵抗
- 0.0: 正式验证了对各种规避攻击的稳健性。
- 0.1-0.3: 对大多数已知的规避攻击具有稳健性,采用了多种防御机制(例如,对抗性训练、输入净化、认证的稳健性)。
- 0.4-0.6: 容易受到某些规避攻击,进行了基本的对抗性训练或输入验证。
- 0.7-1.0: 非常容易受到常见的规避攻击(例如,FGSM、PGD)。没有或只有极少的防御措施。
- 示例:
- 0.0: 模型的稳健性通过形式化方法得到证明。
- 0.2: 模型结合使用对抗性训练、输入过滤和认证的稳健性技术。
- 0.5: 模型使用对抗性样本进行训练,但仍然容易受到更复杂的攻击。
- 0.8: 通过对输入图像添加小的扰动,模型很容易被欺骗。
-
梯度掩蔽/混淆
- 0.0: 梯度完全隐藏或正式证明无法恢复。
- 0.1-0.3: 使用了强大的梯度掩蔽技术(例如,破碎梯度、温度计编码),使基于梯度的攻击变得更加困难。
- 0.4-0.6: 采用了基本的梯度混淆方法(例如,添加噪声),但梯度仍然可以部分恢复。
- 0.7-1.0: 梯度易于访问和解释,没有使用掩蔽技术。
- 示例:
- 0.0: 模型使用同态加密或其他方法使梯度完全无法访问。
- 0.2: 模型使用破碎梯度等先进技术,使基于梯度的攻击在计算上非常昂贵。
- 0.5: 对梯度添加了一些噪声,但它们仍然揭示了有关模型的信息。
- 0.9: 模型的梯度可以轻松计算和可视化。
-
稳健性认证
- 0.0: 从信誉良好的第三方组织获得正式的稳健性认证。
- 0.1-0.3: 使用多种指标(例如,CLEVER、Robustness Gym)对各种攻击进行了严格的稳健性测试。
- 0.4-0.6: 对有限的攻击集或使用简单的指标进行了基本的稳健性测试。
- 0.7-1.0: 没有进行稳健性测试。
- 示例:
- 0.0: 模型已通过公认的认证机构认证,可抵御特定类型的攻击。
- 0.2: 使用像 Robustness Gym 这样的综合稳健性测试框架评估模型。
- 0.5: 模型针对具有有限扰动预算范围的 FGSM 攻击进行了测试。
- 0.8: 没有针对对抗性示例的稳健性测试。
DS (数据敏感性)
-
数据机密性
- 0.0: 使用差分隐私或同态加密等技术完全匿名化数据。
- 0.1-0.3: 对静态和传输中的数据使用强加密(例如,AES-256),并实施严格的访问控制和密钥管理实践。
- 0.4-0.6: 敏感数据具有基本的访问控制(例如,密码),但没有加密。
- 0.7-1.0: 高度敏感的数据(例如,PII、财务数据)在没有或只有极少保护的情况下存储或处理。
- 示例:
- 0.0: 数据已完全匿名化,并且可以证明与个人无关。
- 0.2: 数据在静态和传输中均已加密,并具有严格的访问控制和密钥轮换策略。
- 0.5: 数据访问受用户角色限制,但数据以明文形式存储。
- 0.9: 训练数据包括所有开发人员都可以访问的未加密的 PII。
-
数据完整性
- 0.0: 使用区块链或 Merkle 树等技术正式验证数据完整性。
- 0.1-0.3: 实施了强大的完整性检查(例如,数字签名、加密哈希)和篡改检测机制。
- 0.4-0.6: 使用了基本的完整性检查(例如,校验和),但没有防篡改机制。
- 0.7-1.0: 没有数据完整性检查,数据可以轻松修改而不被检测到。
- 示例:
- 0.0: 数据存储在区块链上,确保不变性和防篡改完整性。
- 0.2: 数据经过数字签名,任何修改都会被检测到并发出警报。
- 0.5: 在访问时使用校验和来验证数据完整性。
- 0.8: 数据可以在没有任何检测的情况下被更改。
-
数据来源
- 0.0: 数据来源经过正式验证和可审计,并具有确保数据源真实性和可信度的机制。
- 0.1-0.3: 跟踪详细的数据沿袭,包括所有转换和处理步骤,并具有清晰的审计跟踪。
- 0.4-0.6: 有关数据源的基本信息可用,但沿袭不完整或不清楚。
- 0.7-1.0: 没有关于数据来源、收集方法或转换的信息。
- 示例:
- 0.0: 数据来源经过加密验证且防篡改。
- 0.2: 跟踪完整的数据沿袭,包括所有处理步骤和数据所有者。
- 0.5: 记录了数据源,但未明确记录应用的转换。
- 0.9: 数据的来源和收集方法未知。
EI (伦理影响)
-
偏见和歧视
- 0.0: 系统在不同群体中表现出公平和无偏见,并持续监控和审核偏见。
- 0.1-0.3: 使用多种指标(例如,机会均等、预测率平价)进行严格的公平性测试,并应用了偏见缓解技术(例如,重新加权、对抗性去偏)。
- 0.4-0.6: 对潜在偏见有一些认识,监控了基本的公平性指标(例如,人口统计均等),但没有积极的缓解措施。
- 0.7-1.0: 歧视性结果的风险很高,没有使用偏见检测或缓解方法。
- 示例:
- 0.0: 系统的公平性经过正式验证并持续监控。
- 0.2: 系统使用对抗性去偏等技术进行训练,并定期审核公平性。
- 0.5: 监控公平性指标,但不采取任何措施来解决已识别的偏见。
- 0.9: 系统始终对某些人口群体产生有偏见的输出。
-
透明度和可解释性
- 0.0: 系统的决策过程完全透明且可正式解释,并建立了明确的因果关系。
- 0.1-0.3: 高度可解释,系统使用固有可解释的模型(例如,决策树)或为所有决策提供可靠和全面的解释。
- 0.4-0.6: 有限的可解释性,可以生成一些事后解释(例如,LIME、SHAP),但它们可能不可靠或不全面。
- 0.7-1.0: 黑盒系统,无法深入了解决策过程。
- 示例:
- 0.0: 系统的逻辑完全透明,并且可以正式验证。
- 0.2: 系统使用可解释的模型或为每个决策提供详细且可靠的解释。
- 0.5: 可以生成事后解释,但它们并不总是准确或完整的。
- 0.8: 没有提供系统决策的解释。
-
问责制
- 0.0: 完全问责制,并具有补救、纠正和独立监督机制。
- 0.1-0.3: 建立了明确的问责制框架,并定义了处理错误和争议的角色、责任和流程。
- 0.4-0.6: 对开发人员或运营商分配了一些责任,但没有正式的问责制框架。
- 0.7-1.0: 对系统的行为或错误没有明确的问责制。
- 示例:
- 0.0: 系统具有正式的问责制框架,并具有独立审核和公开报告机制。
- 0.2: 为开发、部署和运营定义了明确的角色和责任,并制定了事件响应计划。
- 0.5: 开发团队通常负责,但没有明确的错误处理程序。
- 0.9: 不清楚系统出错时谁负责。
-
社会影响
- 0.0: 系统旨在最大限度地提高积极的社会影响并最大限度地减少负面后果,并持续监控和与受影响的社区互动。
- 0.1-0.3: 进行了全面的社会影响评估,考虑了广泛的利益相关者和潜在危害,并制定了缓解策略。
- 0.4-0.6: 对潜在的社会影响有一些考虑,但没有全面的评估或主动缓解措施。
- 0.7-1.0: 负面社会影响的风险很高(例如,失业、操纵、信任侵蚀),没有评估或缓解措施。
- 示例:
- 0.0: 系统采用强有力的道德框架设计,促进公平、透明和社会福祉。
- 0.2: 进行了全面的社会影响评估,并制定了缓解策略。
- 0.5: 开发人员承认潜在的负面影响,但没有采取具体步骤来解决这些影响。
- 0.8: 该系统可用于大规模监视或传播错误信息,而没有任何保障措施。
DC (决策关键性)
-
安全关键
- 0.0: 系统经过正式验证,符合安全关键标准(例如,汽车领域的 ISO 26262、医疗器械领域的 IEC 62304)。
- 0.1-0.3: 进行了严格的安全测试,包括边缘情况和故障场景,并具有故障安全机制和人工监督。
- 0.4-0.6: 采取了基本的安全措施(例如,一些冗余),但没有严格的安全测试或正式验证。
- 0.7-1.0: 系统用于安全关键应用(例如,自动驾驶、医疗诊断),没有适当的安全考虑或故障安全机制。
- 示例:
- 0.0: 系统已通过认证,符合其应用领域的相关安全标准。
- 0.2: 系统经过严格的安全测试,并具有多种故障安全机制。
- 0.5: 系统有一些备份系统,但它们没有经过全面测试。
- 0.9: 系统用于控制关键功能,没有任何冗余或故障安全机制。
-
财务影响
- 0.0: 系统旨在最大限度地降低财务风险,并具有实时欺诈预防、异常检测和全面的保险范围。
- 0.1-0.3: 实施了强大的财务控制和欺诈检测机制,并进行定期审核以识别和减轻财务风险。
- 0.4-0.6: 采取了一些措施来减轻财务风险(例如,交易限额),但没有全面的风险评估或欺诈预防机制。
- 0.7-1.0: 由于系统错误或恶意攻击而造成重大财务损失的风险很高,没有采取任何保护措施。
- 示例:
- 0.0: 系统具有多层财务控制、实时欺诈预防和针对财务损失的保险。
- 0.2: 系统使用先进的欺诈检测算法并进行定期财务审核。
- 0.5: 系统有一些交易限额和基本的欺诈监控。
- 0.8: 系统错误可能导致在没有任何检测的情况下进行未经授权的大额交易。
-
声誉损害
- 0.0: 系统旨在最大限度地降低声誉风险,并持续监控公众认知、主动与利益相关者互动,并制定了稳健的危机管理计划。
- 0.1-0.3: 进行了声誉风险评估,考虑了各种场景和利益相关者,并制定了沟通计划和缓解策略。
- 0.4-0.6: 对声誉风险有一些认识,对公众认知的监控有限,但没有采取主动措施来应对负面宣传。
- 0.7-1.0: 由于系统错误、偏见或安全漏洞而造成严重声誉损害的风险很高,没有缓解策略。
- 示例:
- 0.0: 系统设计为透明和道德的,最大限度地降低了声誉损害的风险,并且公司在负责任的人工智能实践方面拥有良好的记录。
- 0.2: 进行了声誉风险评估,并制定了危机沟通计划。
- 0.5: 公司监控社交媒体上的负面评论,但没有计划解决这些评论。
- 0.8: 系统错误或偏见可能导致广泛的公众批评和信任丧失。
-
运营中断
- 0.0: 系统设计为具有高可用性和弹性,并具有实时监控、自动恢复和定期测试故障转移机制。
- 0.1-0.3: 强大的运营控制,包括冗余、故障转移机制和全面的业务连续性和灾难恢复计划。
- 0.4-0.6: 采取了一些措施来减轻运营风险(例如,有限的冗余),但没有全面的业务连续性计划。
- 0.7-1.0: 由于系统故障或攻击而导致重大运营中断的风险很高,没有备份系统或恢复计划。
- 示例:
- 0.0: 系统设计为具有多层冗余和自动恢复的 24/7 全天候可用性。
- 0.2: 系统具有定期测试和更新的全面业务连续性计划。
- 0.5: 系统具有一些冗余组件,但故障转移程序没有定期测试。
- 0.8: 系统故障可能会导致关键业务运营中断,而没有任何备份。
AD (适应性)
-
持续监控
- 0.0: 实时监控,对检测到的威胁自动响应,包括动态模型调整和回滚功能。
- 0.1-0.3: 全面监控系统输入、输出和内部状态,并具有异常检测算法和针对可疑活动的自动警报。
- 0.4-0.6: 采取了基本的监控措施(例如,记录系统输出),但分析有限,没有自动警报。
- 0.7-1.0: 没有针对对抗性攻击、异常或性能下降的监控。
- 示例:
- 0.0: 系统具有实时入侵检测和自动响应功能。
- 0.2: 系统使用 SIEM 系统监控异常并生成警报。
- 0.5: 系统日志已存储,但仅定期手动分析。
- 0.9: 没有收集日志,也没有执行监控。
-
再训练能力
- 0.0: 由于性能下降、概念漂移或新数据的可用性而触发持续和自动的再训练,且人工干预最少。
- 0.1-0.3: 建立了自动再训练管道,允许使用新数据和模型改进进行定期更新。
- 0.4-0.6: 可以手动再训练,但不经常且耗时,自动化程度有限。
- 0.7-1.0: 没有再训练模型的能力,或者再训练需要大量的人工工作和停机时间。
- 示例:
- 0.0: 模型不断学习并适应新数据和不断变化的条件。
- 0.2: 模型使用自动管道定期自动再训练。
- 0.5: 模型可以手动再训练,但这需要大量的精力和停机时间。
- 0.8: 如果不从头开始重建模型,则无法更新模型。
-
威胁情报集成
- 0.0: 基于威胁情报的主动威胁搜寻,自动分析和关联威胁数据,以在潜在风险影响系统之前识别和减轻这些风险。
- 0.1-0.3: 将威胁情报源集成到安全监控和响应系统中,提供有关新威胁的自动警报和更新。
- 0.4-0.6: 使用了基本的威胁情报(例如,手动查看威胁报告),但没有系统地集成到安全运营中。
- 0.7-1.0: 没有与威胁情报源或其他安全信息源集成。
- 示例:
- 0.0: 系统使用威胁情报主动识别和减轻潜在漏洞。
- 0.2: 系统自动摄取和分析威胁情报源,为相关威胁生成警报。
- 0.5: 安全团队偶尔会查看威胁情报报告,但不采取具体行动。
- 0.9: 安全团队不知道当前对人工智能系统的威胁。
-
对抗性训练
- 0.0: 使用不断发展的攻击技术进行持续的对抗性训练,随着新攻击的发现而纳入新攻击,并使用形式化验证方法来确保稳健性。
- 0.1-0.3: 使用更大的扰动预算,针对各种攻击(例如,PGD、C&W)进行稳健的对抗性训练,并使用多种技术(例如,集成对抗性训练、认证防御)。
- 0.4-0.6: 使用有限的攻击类型集(例如,FGSM)和小的扰动预算进行基本的对抗性训练。
- 0.7-1.0: 在模型开发期间没有使用对抗性训练。
- 示例:
- 0.0: 模型经过持续的对抗性训练,并针对特定的攻击模型正式验证了稳健性。
- 0.2: 模型使用不同的对抗性训练技术和攻击类型的组合进行训练。
- 0.5: 模型使用 FGSM 生成的对抗性示例进行训练。
- 0.8: 模型没有经过训练来抵抗任何对抗性示例。
AA (对抗性攻击面)
-
模型反演
- 0.0: 模型可证明能够抵抗模型反演攻击,并对训练数据的隐私提供正式保证。
- 0.1-0.3: 对模型反演有强大的防御能力,例如差分隐私或数据净化技术,大大增加了重建训练数据的难度。
- 0.4-0.6: 采取了一些措施来减轻模型反演(例如,限制模型输出精度),但仍然存在重大风险。
- 0.7-1.0: 模型反演攻击的风险很高,可以从模型输出或梯度中轻松重建敏感的训练数据。
- 示例:
- 0.0: 模型被正式证明在特定攻击模型下能够抵抗模型反演。
- 0.2: 模型使用差分隐私进行训练,为模型反演提供了强大的保护。
- 0.5: 模型的输出被四舍五入或扰动以使反演更加困难,但仍可能泄漏一些信息。
- 0.9: 攻击者可以轻松地从模型的输出中重建人脸或其他敏感数据。
-
模型提取
- 0.0: 模型可证明能够抵抗模型提取,并对创建功能副本的难度提供正式保证。
- 0.1-0.3: 对模型提取有强大的防御能力,例如 API 查询异常检测、模型水印和与用户的法律协议,这使得窃取模型的难度和成本大大增加。
- 0.4-0.6: 采取了一些措施来减轻模型提取(例如,速率限制、水印),但坚定的攻击者仍然可以成功。
- 0.7-1.0: 模型提取的风险很高,攻击者可以通过查询其 API 轻松创建模型的功能副本。
- 示例:
- 0.0: 模型被设计为能够抵抗模型提取,并且其功能无法通过黑盒查询复制。
- 0.2: 模型使用水印和异常检测来检测和防止提取尝试。
- 0.5: API 访问受到速率限制,但攻击者仍然可以在较长时间内提取模型。
- 0.8: 攻击者可以通过发出大量 API 调用来创建模型的副本。
-
成员推理
- 0.0: 模型可证明能够抵抗成员推理攻击,并对单个训练数据点的隐私提供正式保证。
- 0.1-0.3: 对成员推理有强大的防御能力,例如差分隐私或模型堆叠,大大降低了攻击者推断成员资格的能力。
- 0.4-0.6: 采取了一些措施来减轻成员推理(例如,正则化、丢弃),但仍然存在重大风险。
- 0.7-1.0: 成员推理攻击的风险很高,攻击者可以轻松确定特定数据点是否用于模型的训练集中。
- 示例:
- 0.0: 模型被正式证明在特定攻击模型下能够抵抗成员推理。
- 0.2: 模型使用差分隐私进行训练,为成员推理提供了强大的保护。
- 0.5: 模型使用正则化技术,这可能会降低成员推理的风险,但没有正式保证。
- 0.9: 攻击者可以轻松确定特定个人的数据是否用于训练模型。
LL (生命周期漏洞)
-
开发
- 0.0: 具有代码正式验证、严格访问控制和持续监控安全威胁的安全开发环境。
- 0.1-0.3: 遵循安全开发生命周期 (SDL) 实践,包括代码审查、静态分析和漏洞扫描,并对开发资源进行访问控制。
- 0.4-0.6: 在开发环境中采取了基本的安全措施(例如,开发人员工作站安装了防病毒软件),有一些安全编码准则,但没有正式的安全开发生命周期 (SDL)。
- 0.7-1.0: 不安全的开发环境,没有安全编码实践,对开发资源没有访问控制。
- 示例:
- 0.0: 开发环境是隔离的并持续监控,并使用形式化方法来验证关键代码组件的安全性。
- 0.2: 遵循 SDL 实践,包括代码审查、静态分析和漏洞扫描,并根据角色限制对代码存储库的访问。
- 0.5: 开发人员使用公司提供的具有基本安全软件的笔记本电脑,并且制定了一些安全编码准则。
- 0.8: 开发人员在没有安全控制的个人笔记本电脑上工作,并且代码存储在没有访问限制的公共存储库中。
-
训练
- 0.0: 具有训练过程正式验证、严格访问控制和持续监控入侵和异常的安全且隔离的训练环境。
- 0.1-0.3: 具有访问控制、静态和传输中数据加密以及定期安全审核的安全训练环境。
- 0.4-0.6: 在训练环境中采取了基本的安全措施(例如,训练数据存储在受密码保护的服务器上),但没有加密或严格的访问控制。
- 0.7-1.0: 不安全的训练环境,没有数据安全或访问控制,训练数据在不安全的系统上存储和处理。
- 示例:
- 0.0: 训练在具有严格访问控制、持续监控和训练过程正式验证的安全区域中执行。
- 0.2: 训练数据在静态和传输中均已加密,访问根据角色进行限制,并且定期审核训练环境的安全性。
- 0.5: 训练数据存储在受密码保护的服务器上,但访问没有严格控制。
- 0.8: 训练数据存储在没有任何加密或访问控制的公共云服务器上。
-
部署
- 0.0: 具有持续监控、自动安全修补和部署过程正式验证的安全且隔离的部署环境。
- 0.1-0.3: 具有强身份验证和授权、定期安全更新和入侵检测系统的安全部署环境。
- 0.4-0.6: 在部署环境中采取了基本的安全措施(例如,模型部署在防火墙后面),但没有强身份验证或授权机制。
- 0.7-1.0: 不安全的部署环境,没有访问控制或安全监控,模型部署在没有任何保护的公开访问的服务器上。
- 示例:
- 0.0: 模型部署在具有严格访问控制、持续监控和自动安全修补的安全区域中。
- 0.2: 模型部署在具有强身份验证、授权和定期安全更新的安全云环境中。
- 0.5: 模型部署在防火墙后面,但 API 密钥在多个用户之间共享。
- 0.8: 模型部署在公共服务器上,访问其 API 不需要身份验证。
-
运营
- 0.0: 具有自动事件响应能力的持续安全监控、定期安全审核和专门的安全运营中心 (SOC)。
- 0.1-0.3: 使用 SIEM 系统进行全面的安全监控,针对可疑活动发出自动警报,以及定期测试的定义明确的事件响应计划。
- 0.4-0.6: 基本的安全监控(例如,手动查看日志),有限的事件响应能力,没有正式的事件响应计划。
- 0.7-1.0: 没有安全监控或事件响应计划,没有收集或分析系统日志。
- 示例:
- 0.0: 专门的 SOC 全天候监控系统,具有自动事件响应能力和定期安全审核。
- 0.2: 使用 SIEM 系统监控安全事件、生成警报并触发事件响应程序。
- 0.5: 每周收集并手动查看系统日志,并且有一个基本的事件响应计划。
- 0.8: 没有收集日志,也没有响应安全事件的流程。
GV (治理和验证)
-
合规性
- 0.0: 系统超出法规要求并制定了合规性方面的行业最佳实践,并采取主动措施来适应新法规。
- 0.1-0.3: 完全遵守相关法规和行业标准,并设有专门的合规团队和定期审核。
- 0.4-0.6: 对法规有基本的了解,有一些临时的合规工作,但没有正式的合规计划。
- 0.7-1.0: 不了解或不遵守相关法规(例如,GDPR、CCPA、HIPAA)或行业标准。
- 示例:
- 0.0: 系统设计为默认合规,超出法规要求并制定行业最佳实践。
- 0.2: 系统完全符合所有适用的法规,并进行定期审核和设有专门的合规团队。
- 0.5: 为遵守法规做出了一些努力,但存在重大差距,并且没有正式的合规计划。
- 0.8: 系统在未经用户同意或适当保护的情况下收集和处理个人数据,违反了数据隐私法规。
-
审计
- 0.0: 由信誉良好的第三方进行定期独立审核,并对系统的安全性、公平性和道德绩效进行正式验证。
- 0.1-0.3: 进行定期的内部审核,涵盖人工智能系统生命周期的各个方面,并具有清晰的审核跟踪和文档。
- 0.4-0.6: 不经常或有限的审核(例如,仅审核代码是否存在安全漏洞),没有独立的验证。
- 0.7-1.0: 没有对人工智能系统的设计、开发、部署或运营进行审核。
- 示例:
- 0.0: 每年由信誉良好的第三方进行独立审核,并公开报告结果。
- 0.2: 进行定期的内部审核,涵盖安全性、公平性和绩效,并具有详细的审核跟踪。
- 0.5: 在部署之前审核代码是否存在安全漏洞,但不进行其他审核。
- 0.8: 没有维护审核日志,也没有执行审核。
-
风险管理
- 0.0: 主动和持续的人工智能风险管理,并设有专门的人工智能风险管理团队、定期风险评估,并高度重视预测和减轻新出现的人工智能风险。
- 0.1-0.3: 建立了全面的人工智能风险管理框架,并具有识别、评估、减轻和监控人工智能风险的具体流程,并完全集成到组织风险框架中。
- 0.4-0.6: 对人工智能系统进行基本的风险评估,缓解策略有限,人工智能风险部分集成到组织风险框架中。
- 0.7-1.0: 没有人工智能特定的风险管理流程,在整体组织风险框架中没有考虑人工智能风险。
- 示例:
- 0.0: 人工智能风险管理是一个持续的过程,与组织的整体风险管理和治理结构相结合。
- 0.2: 建立了全面的人工智能风险管理框架,并进行定期风险评估和制定缓解计划。
- 0.5: 对人工智能风险进行临时评估,缓解策略有限。
- 0.8: 在组织的风险管理流程中没有考虑人工智能风险。
-
人工监督
- 0.0: 人在环路系统具有明确定义的角色和职责,明确的人机协作程序,以及在系统运行的各个阶段进行人工监督的机制。
- 0.1-0.3: 在系统的决策过程中具有明确的人工审查和干预机制,并为人工操作员定义了明确的角色和职责。
- 0.4-0.6: 有限的人工监督,主要是被动的(例如,用户可以报告错误),没有明确的人工干预或否决机制。
- 0.7-1.0: 在人工智能系统的决策过程中没有人工监督或干预。
- 示例:
- 0.0: 系统设计用于人机协作,人类在决策过程中发挥核心作用。
- 0.2: 系统具有人工操作员在特定情况下审查和否决其决策的机制。
- 0.5: 用户可以报告错误,但没有人工干预系统决策的流程。
- 0.8: 系统在没有任何人工控制或监控的情况下自主运行。
-
道德框架一致性
- 0.0: 系统明显遵守并促进道德人工智能原则,并持续监控和审核道德绩效。
- 0.1-0.3: 系统设计和运营与已建立的道德框架(例如,经合组织人工智能原则、蒙特利尔负责任人工智能宣言)保持一致,并具有解决道德问题的机制。
- 0.4-0.6: 对道德准则有基本的认识,实施有限,没有正式的道德审查流程。
- 0.7-1.0: 在人工智能系统的设计、开发或部署中没有考虑道德框架或原则。
- 示例:
- 0.0: 定期评估系统的道德绩效,并且它积极促进道德人工智能原则。
- 0.2: 系统设计结合了相关道德框架的原则,并且有一个解决道德问题的流程。
- 0.5: 开发人员了解道德准则,但没有将它们正式集成到系统的设计中。
- 0.8: 系统在开发和部署时没有考虑道德影响。
CS (云安全联盟 LLM 分类法)
-
模型操纵
- 0.0: 系统可证明能够抵抗模型操纵,并对提示注入和其他对抗性技术的稳健性进行正式验证。
- 0.1-0.3: 对模型操纵有强大的防御能力(例如,输入过滤、对抗性训练、输出验证),使得操纵模型行为变得非常困难。
- 0.4-0.6: 对操纵采取了一些防御措施(例如,基本的输入净化),但仍然存在漏洞,并且通过一些努力可以操纵模型。
- 0.7-1.0: 非常容易受到模型操纵,包括提示注入和其他对抗性技术,没有或只有极少的防御措施。
- 示例:
- 0.0: 模型的抗提示注入能力经过正式验证。
- 0.2: 模型结合使用输入过滤、对抗性训练和输出验证来防御操纵。
- 0.5: 模型具有基本的输入净化功能,但仍然可以通过精心设计的提示进行操纵。
- 0.8: 模型很容易受到提示注入攻击。
-
数据中毒
- 0.0: 系统可证明能够抵抗数据中毒,并对训练数据的完整性和安全性提供正式保证。
- 0.1-0.3: 实施了强大的数据验证、异常检测和来源跟踪机制,使得成功毒化训练数据变得非常困难。
- 0.4-0.6: 采取了一些措施来减轻数据中毒(例如,异常值检测),但仍然存在风险,并且有针对性的中毒攻击仍然可能成功。
- 0.7-1.0: 数据中毒的风险很高,没有或只有极少的措施来确保训练数据的完整性和安全性。
- 示例:
- 0.0: 训练数据存储在具有加密完整性验证的不可变账本上。
- 0.2: 使用强大的数据验证、异常检测和来源跟踪机制来防止和检测数据中毒。
- 0.5: 使用基本的异常值检测,但复杂的中毒攻击仍然可能成功。
- 0.8: 训练数据很容易被篡改,并且没有检测中毒的机制。
-
敏感数据泄露
- 0.0: 系统可证明能够防止敏感数据泄露,并对敏感信息的隐私提供正式保证。
- 0.1-0.3: 实施了强大的访问控制、加密和输出净化机制,使得从系统中提取敏感数据变得非常困难。
- 0.4-0.6: 采取了一些措施来防止数据泄漏(例如,输出过滤),但仍然存在漏洞,并且在某些情况下可能会泄露敏感信息。
- 0.7-1.0: 敏感数据泄露的风险很高,没有或只有极少的措施来保护系统处理或存储的敏感信息。
- 示例:
- 0.0: 系统使用同态加密或其他隐私保护技术来防止任何敏感数据泄露。
- 0.2: 使用强大的访问控制、加密和输出净化来防止数据泄漏。
- 0.5: 模型输出经过过滤以删除潜在的敏感信息,但仍可能发生一些泄漏。
- 0.8: 模型可能会在其输出中泄露敏感信息,并且没有防止数据泄露的保护措施。
-
模型窃取
- 0.0: 模型可证明能够抵抗模型窃取,并对创建功能副本的难度提供正式保证。
- 0.1-0.3: 对模型窃取有强大的防御能力(例如,API 查询异常检测、模型水印、法律协议),这使得窃取模型的难度和成本大大增加。
- 0.4-0.6: 采取了一些措施来减轻模型窃取(例如,速率限制),但坚定的攻击者仍然可以成功。
- 0.7-1.0: 模型窃取的风险很高,攻击者可以通过查询其 API 轻松创建模型的功能副本。
- 示例:
- 0.0: 模型被设计为能够抵抗模型提取,并且其功能无法通过黑盒查询复制。
- 0.2: 模型结合使用水印、异常检测和法律协议来阻止和检测模型窃取。
- 0.5: API 访问受到速率限制,但攻击者仍然可以在较长时间内提取模型。
- 0.8: 攻击者可以通过发出大量 API 调用来创建模型的副本。
-
故障/失灵
- 0.0: 系统设计为具有高可用性和容错能力,并对其可靠性进行正式验证。
- 0.1-0.3: 实施了强大的错误处理、监控和冗余机制,大大降低了故障或失灵的风险。
- 0.4-0.6: 采取了一些措施来确保可靠性(例如,基本的错误处理),但仍然存在风险,并且系统可能会出现停机或在某些条件下产生不正确的输出。
- 0.7-1.0: 故障或失灵的风险很高,没有或只有极少的措施来确保系统的可靠性。
- 示例:
- 0.0: 系统设计为具有多层冗余和故障转移机制,并且其可靠性经过正式验证。
- 0.2: 系统具有强大的错误处理、监控和自愈能力。
- 0.5: 系统具有基本的错误处理和日志记录功能,但可能会因意外错误而停机。
- 0.8: 系统容易崩溃或出错,并且没有确保其持续运行的机制。
-
不安全的供应链
- 0.0: 安全且可审核的供应链,并对所有第三方组件和依赖项进行正式验证。
- 0.1-0.3: 实施了强大的供应链安全实践(例如,代码签名、依赖项验证、定期审核),最大限度地降低了供应链攻击的风险。
- 0.4-0.6: 采取了一些措施来减轻供应链风险(例如,使用可信来源),但第三方组件中仍可能存在漏洞。
- 0.7-1.0: 供应链漏洞的风险很高,没有或只有极少的措施来确保第三方组件和依赖项的安全性。
- 示例:
- 0.0: 所有第三方组件都经过正式的安全验证,并且持续监控供应链是否存在漏洞。
- 0.2: 在整个供应链中遵循强大的安全实践,包括代码签名、依赖项验证和定期审核。
- 0.5: 使用来自信誉良好的来源的第三方库,但它们没有经过彻底的安全漏洞审查。
- 0.8: 系统依赖具有已知漏洞的过时或未修补的第三方组件。
-
不安全的应用程序/插件
- 0.0: 对应用程序/插件强制执行安全的开发和集成实践,并对其安全性进行正式验证。
- 0.1-0.3: 针对应用程序/插件制定了强大的安全准则和审查流程,最大限度地降低了第三方集成引入漏洞的风险。
- 0.4-0.6: 对应用程序/插件采取了一些安全措施(例如,沙盒),但仍然存在风险,并且可能通过不安全的集成引入漏洞。
- 0.7-1.0: 不安全的应用程序/插件引入漏洞的风险很高,没有或只有极少的措施来确保第三方集成的安全性。
- 示例:
- 0.0: 所有应用程序/插件都经过严格的安全审查,并在允许与系统集成之前进行正式验证。
- 0.2: 针对应用程序/插件开发制定了强大的安全准则,并使用审查流程来最大限度地降低风险。
- 0.5: 应用程序/插件是沙盒化的,但它们仍然可以访问敏感数据或功能。
- 0.8: 可以轻松安装应用程序/插件,而无需任何安全检查,这可能会将漏洞引入系统。
-
拒绝服务 (DoS)
- 0.0: 系统可证明能够抵抗 DoS 攻击,并对其在高负载或恶意流量下的可用性提供正式保证。
- 0.1-0.3: 对 DoS 攻击有强大的防御能力(例如,流量过滤、速率限制、自动扩展),使得中断系统的可用性变得非常困难。
- 0.4-0.6: 采取了一些措施来减轻 DoS 攻击(例如,基本的速率限制),但系统仍然可能容易受到复杂攻击。
- 0.7-1.0: 非常容易受到 DoS 攻击,没有或只有极少的措施来保护系统的可用性。
- 示例:
- 0.0: 系统设计为能够承受大量流量峰值,并且其抗 DoS 攻击能力经过正式验证。
- 0.2: 系统结合使用流量过滤、速率限制和自动扩展来减轻 DoS 攻击。
- 0.5: 系统具有基本的速率限制,但仍然可能被大量请求淹没。
- 0.8: 通过发送大量请求或恶意流量可以轻松地使系统不可用。
-
失去治理/合规性
- 0.0: 系统达到或超过所有相关的法规和治理要求,并采取主动措施来适应新法规,并高度重视保持合规性。
- 0.1-0.3: 实施了强大的合规框架和控制措施,确保遵守相关的法规和治理政策。
- 0.4-0.6: 做出了一些合规努力,但仍然存在差距,并且系统可能无法完全满足所有法规或治理要求。
- 0.7-1.0: 不遵守法规或治理政策的风险很高,没有或只有极少的措施来确保遵守。
- 示例:
- 0.0: 系统设计为默认合规,并具有自动机制来确保遵守法规和政策。
- 0.2: 定期审核系统的合规性,并由专门的团队确保满足所有要求。
- 0.5: 为遵守法规做出了一些努力,但存在重大差距,并且没有正式的合规计划。
- 0.8: 系统不符合数据隐私法规,并且没有确保遵守内部政策的机制。
基本公式
AIVSS_Score = [
(w₁ × ModifiedBaseScore) +
(w₂ × AISpecificMetrics) +
(w₃ × ImpactMetrics)
] × TemporalMetrics × MitigationMultiplier
其中:0 ≤ AIVSS_Score ≤ 10
- w₁, w₂, w₃: 分配给每个组件(修正的基本指标、人工智能特定指标、影响指标)的权重。建议的起始点:w₁ = 0.3,w₂ = 0.5,w₃ = 0.2(更加重视人工智能特定风险)。根据特定的人工智能系统及其风险状况进行调整。
- 时间指标: 根据可利用性、补救级别和报告可信度进行调整(类似于 CVSS 时间分数)。
- 可利用性 (E):
- 未定义 (ND):1.0
- 未经验证 (U):0.9
- 概念验证 (P):0.95
- 功能性 (F):1.0
- 高 (H):1.0
- 补救级别 (RL):
- 未定义 (ND):1.0
- 官方修复 (O):0.95
- 临时修复 (T):0.96
- 变通方法 (W):0.97
- 不可用 (U):1.0
- 报告可信度 (RC):
- 未定义 (ND):1.0
- 未知 (U):0.92
- 合理 (R):0.96
- 已确认 (C):1.0
- 可利用性 (E):
- 缓解乘数: 根据缺乏有效缓解措施而增加分数的因子(范围从 1.0 到 1.5)。1.0 = 强有力的缓解措施;1.5 = 没有/薄弱的缓解措施。
1. 修正的基本指标
ModifiedBaseScore = min(10, [MAV × MAC × MPR × MUI × MS] × ScopeMultiplier)
其中修正的基本指标 (MAV, MAC, MPR, MUI, MS) 源自基本指标,并根据特定环境和使用环境指标进行调整。每个修正的基本指标都可以按照与基本指标相同的方式进行评级,并增加:
- 未定义 (X):使用未修改的基本指标值。
2. 人工智能特定指标
AISpecificMetrics = [MR × DS × EI × DC × AD × AA × LL × GV × CS] × ModelComplexityMultiplier
- 每个指标 (MR, DS, EI, DC, AD, AA, LL, GV, CS) 根据每个子类别中漏洞的严重程度,使用上面提供的详细评分细则从 0.0 到 1.0 进行评分(分数越高 = 问题越严重)。
- 模型复杂度乘数: 用于解释更高级模型的攻击面和复杂性增加的因子(1.0 到 1.5)。
3. 影响指标
ImpactMetrics = (C + I + A + SI) / 4
- C (机密性影响): 对数据机密性的影响。
- I (完整性影响): 对数据和系统完整性的影响。
- A (可用性影响): 对系统可用性的影响。
- SI (社会影响): 更广泛的社会危害(例如,歧视、操纵)。由 EI(伦理影响)子类别提供信息。
严重性级别(对于 C、I、A、SI):
- 无:0.0
- 低:0.22
- 中:0.55
- 高:0.85
- 严重:1.0
4. 环境分数
环境分数是通过使用环境指标修改基本分数来计算的。该公式综合考虑了以下因素:
EnvironmentalScore = [(ModifiedBaseScore + (Environmental Component)) × TemporalMetrics] × (1 + EnvironmentalMultiplier)
环境组件源自人工智能特定指标,并根据环境上下文进行调整:
EnvironmentalComponent = [CR × IR × AR × SIR] × AISpecificMetrics
其中:
- CR、IR、AR、SIR 分别是机密性、完整性、可用性和社会影响要求。
- 环境乘数根据 CR、IR、AR、SIR 未涵盖的特定环境因素调整分数。
风险类别
严重:9.0 - 10.0
高: 7.0 - 8.9
中: 4.0 - 6.9
低: 0.1 - 3.9
无: 0.0
先决条件
- 访问人工智能系统架构详细信息
- 安全评估工具
- 了解机器学习/人工智能概念和正在评估的特定人工智能模型。
- 具备道德人工智能原则和潜在社会影响方面的专业知识。
- 熟悉云安全原则,特别是如果人工智能系统是基于云的或 LLM,则熟悉 CSA LLM 威胁分类法。
- 具有漏洞分析经验,特别是在人工智能/机器学习系统的背景下。
角色和责任:
- 人工智能安全团队/专家: 领导 AIVSS 评估,与其他团队协调,确保准确性和完整性。
- 人工智能开发人员/数据科学家: 提供技术细节,协助识别漏洞,实施缓解措施。
- 安全工程师: 评估基本指标,评估开发、训练和部署环境的安全性,为整体评估做出贡献。
- 合规/风险官: 确保与法规和组织风险管理框架保持一致。
- 道德人工智能官/审查委员会: 评估道德影响并提供减轻道德风险的指导。
此检查表为组织进行 AIVSS 评估提供了一个简化且可操作的指南。
阶段 1:系统和环境定义
- 1.1 确定要评估的人工智能系统,包括其组件、数据流和依赖项。
- 1.2 定义系统的运行环境,包括其部署模型(云、本地、混合)、网络配置和用户群。
- 1.3 根据系统的具体情况确定环境指标 (CR, IR, AR, SIR)。
- 1.4 根据环境因素记录修正的基本指标 (MAV, MAC, MPR, MUI, MS)。
阶段 2:基本指标和人工智能特定指标评估
- 2.1 根据已识别的漏洞评估基本指标 (AV, AC, PR, UI, S)。
- 2.2 使用详细的评分细则评估每个人工智能特定指标 (MR, DS, EI, DC, AD, AA, LL, GV, CS):
- 2.2.1 模型稳健性 (MR):规避抵抗、梯度掩蔽、稳健性认证。
- 2.2.2 数据敏感性 (DS):数据机密性、数据完整性、数据来源。
- 2.2.3 伦理影响 (EI):偏见和歧视、透明度和可解释性、问责制、社会影响。
- 2.2.4 决策关键性 (DC):安全关键、财务影响、声誉损害、运营中断。
- 2.2.5 适应性 (AD):持续监控、再训练能力、威胁情报集成、对抗性训练。
- 2.2.6 对抗性攻击面 (AA):模型反演、模型提取、成员推理。
- 2.2.7 生命周期漏洞 (LL):开发、训练、部署、运营。
- 2.2.8 治理和验证 (GV):合规性、审计、风险管理、人工监督、道德框架一致性。
- 2.2.9 云安全联盟 LLM 分类法 (CS):模型操纵、数据中毒、敏感数据泄露、模型窃取、故障/失灵、不安全的供应链、不安全的应用程序/插件、拒绝服务 (DoS)、失去治理/合规性。
- 2.3 根据评估的人工智能模型确定模型复杂度乘数。
阶段 3:影响和时间评估
- 3.1 根据漏洞的潜在后果评估影响指标 (C, I, A, SI)。
- 3.2 根据当前的可利用性、可用的补救措施和报告可信度评估时间指标 (E, RL, RC)。
阶段 4:缓解和评分
- 4.1 评估现有缓解措施的有效性并确定缓解乘数。
- 4.2 计算修正的基本分数。
- 4.3 计算人工智能特定指标分数。
- 4.4 计算影响指标分数。
- 4.5 计算环境组件。
- 4.6 计算环境分数。
- 4.7 使用公式生成最终的 AIVSS 分数。
阶段 5:报告和补救
- 5.1 在综合报告中记录评估结果,包括 AIVSS 分数、详细的指标分数、理由和支持证据。
- 5.2 将评估结果传达给相关的利益相关者(技术团队、管理层、董事会)。
- 5.3 根据 AIVSS 分数和已识别的漏洞制定和优先考虑补救建议。
- 5.4 实施建议的缓解措施并跟踪进度。
- 5.5 在实施缓解措施后重新评估人工智能系统,以验证其有效性并更新 AIVSS 分数。
# 示例漏洞评估(说明性和简化)
vulnerability = {
'attack_vector': 'Network', # 0.85
'attack_complexity': 'High', # 0.44
'privileges_required': 'Low', # 0.62
'user_interaction': 'None', # 0.85
'scope': 'Unchanged', # 1.0
'model_robustness': {
'evasion_resistance': 0.7, # 对规避的高度敏感性
'gradient_masking': 0.8, # 梯度易于访问
},
'data_sensitivity': {
'data_confidentiality': 0.9, # 具有极少保护的敏感数据
'data_integrity': 0.7 # 没有数据完整性检查
},
'ethical_impact': {
'bias_discrimination': 0.8, # 歧视性结果的高风险
'transparency_explainability': 0.7, # 黑盒系统
},
'cloud_security': {
'model_manipulation': 0.8, # 容易受到提示注入的攻击
'data_poisoning': 0.6, # 数据中毒的一些风险
'sensitive_data_disclosure': 0.7, # 敏感数据泄露的风险
'model_stealing': 0.5, # 一些模型窃取缓解措施,但仍然存在风险
'failure_malfunctioning': 0.7, # 故障风险
'insecure_supply_chain': 0.6, # 一些供应链风险
'insecure_apps_plugins': 0.4, # 一些应用程序/插件安全性,但仍然存在风险
'denial_of_service': 0.8, # 容易受到 DoS 攻击
'loss_of_governance_compliance': 0.7 # 不合规的风险
},
# ... (具有子类别的其他人工智能特定指标)
'confidentiality_impact': 'High', # 0.85
'integrity_impact': 'Medium', # 0.55
'availability_impact': 'Low', # 0.22
'societal_impact': 'Medium', # 0.55
'temporal_metrics': {
'exploitability': 'Proof-of-Concept', # 0.95
'remediation_level': 'Temporary Fix', # 0.96
'report_confidence': 'Confirmed' # 1.0
},
'mitigation_multiplier': 1.4, # 示例:薄弱的缓解措施
'model_complexity_multiplier': 1.4, # 示例:复杂模型(例如,大型语言模型)
'environmental_metrics': {
'cr': 'High', # 1.5
'ir': 'Medium', # 1.0
'ar': 'Low', # 0.5
'sir': 'Medium', # 1.0
},
}
# 根据环境调整基本指标
vulnerability['modified_attack_vector'] = vulnerability['attack_vector'] # 无变化
vulnerability['modified_attack_complexity'] = vulnerability['attack_complexity'] * 0.5 # 示例:在此环境中较低的复杂性
vulnerability['modified_privileges_required'] = vulnerability['privileges_required'] # 无变化
vulnerability['modified_user_interaction'] = vulnerability['user_interaction'] # 无变化
vulnerability['modified_scope'] = vulnerability['scope'] # 无变化
# 计算分数(简化和说明性)
# 修正的基本指标
modified_base_score = min(10, vulnerability['modified_attack_vector'] * vulnerability['modified_attack_complexity'] * vulnerability['modified_privileges_required'] * vulnerability['modified_user_interaction'] * vulnerability['modified_scope']) # = 0.098
# 人工智能特定指标 - 示例计算(为简单起见使用平均值):
mr_score = (vulnerability['model_robustness']['evasion_resistance'] +
vulnerability['model_robustness']['gradient_masking']) / 2 # = 0.75
ds_score = (vulnerability['data_sensitivity']['data_confidentiality'] +
vulnerability['data_sensitivity']['data_integrity']) / 2 # = 0.8
ei_score = (vulnerability['ethical_impact']['bias_discrimination'] +
vulnerability['ethical_impact']['transparency_explainability']) / 2 # = 0.75
# 云安全 (CS) - 使用详细的细则和平均值:
cs_score = (vulnerability['cloud_security']['model_manipulation'] +
vulnerability['cloud_security']['data_poisoning'] +
vulnerability['cloud_security']['sensitive_data_disclosure'] +
vulnerability['cloud_security']['model_stealing'] +
vulnerability['cloud_security']['failure_malfunctioning'] +
vulnerability['cloud_security']['insecure_supply_chain'] +
vulnerability['cloud_security']['insecure_apps_plugins'] +
vulnerability['cloud_security']['denial_of_service'] +
vulnerability['cloud_security']['loss_of_governance_compliance']) / 9 # = 0.64
# 假设计算了其他人工智能特定指标,我们有这些分数(说明性):
dc_score = 0.7
ad_score = 0.55
aa_score = 0.6
ll_score = 0.75
gv_score = 0.8
# 计算整体人工智能特定指标分数:
ais_score = (mr_score * ds_score * ei_score * dc_score * ad_score * aa_score * ll_score * gv_score * cs_score) * vulnerability['model_complexity_multiplier'] # = 0.095
# 影响指标
impact_score = (vulnerability['confidentiality_impact'] + vulnerability['integrity_impact'] + vulnerability['availability_impact'] + vulnerability['societal_impact']) / 4 # = 0.543
# 时间指标 - 为简单起见使用平均值:
temporal_score = (vulnerability['temporal_metrics']['exploitability'] +
vulnerability['temporal_metrics']['remediation_level'] +
vulnerability['temporal_metrics']['report_confidence']) / 3 # = 0.97
# 环境组件
environmental_component = (vulnerability['environmental_metrics']['cr'] * vulnerability['environmental_metrics']['ir'] * vulnerability['environmental_metrics']['ar'] * vulnerability['environmental_metrics']['sir']) * ais_score # = 0.072
# 环境分数
environmental_score = min(10, ((modified_base_score + environmental_component) * temporal_score) * vulnerability['mitigation_multiplier']) # = 0.232
# 最终的 AIVSS 分数
final_score = ((0.3 * modified_base_score) + (0.5 * ais_score) + (0.2 * impact_score)) * temporal_score * vulnerability['mitigation_multiplier'] # = 0.323
示例解读:
在此示例中,最终的 AIVSS 分数约为 0.323,属于低风险类别。考虑了环境分数,根据具体的环境要求稍微修改了基本分数。
重要注意事项:
- 说明性: 这只是一个简化的示例。实际评估将涉及对每个子类别的更全面评估。
- 加权: 权重 (w₁, w₂, w₃) 会显著影响最终分数。组织应根据其特定的风险状况仔细考虑适当的权重。
- 上下文: 应始终在特定人工智能系统、其预期用途和安全事件潜在后果的背景下解释 AIVSS 分数。
- 评估报告: 应生成一份综合报告,包括:
- 被评估人工智能系统的摘要。
- 最终的 AIVSS 分数和风险类别。
- 每个指标和子类别的详细分数。
- 分配分数的理由,参考评分细则和收集的证据。
- 关键漏洞及其潜在影响的分析。
- 根据漏洞的严重程度优先考虑的缓解建议。
- 附录,包含支持性文档(例如,威胁模型、评估数据)。
- 沟通: 应将评估结果传达给相关的利益相关者,包括:
- 技术团队: 为补救工作提供信息。
- 管理层: 支持风险管理决策。
- 董事会: 提供组织人工智能安全状况的概述。
- 映射: 可以将 AIVSS 指标映射到组织风险管理框架(例如,NIST 网络安全框架、ISO 27001)中的现有风险类别。
- 风险评估: 可以将 AIVSS 评估纳入更广泛的风险评估中。
- 审核: 可以将 AIVSS 用作审核人工智能系统的框架。
分类法 | 描述 | 链接 |
---|---|---|
MITRE ATLAS | 基于真实世界观察的对手策略和技术知识库,专门针对机器学习系统的威胁。它提供了一个理解对抗性机器学习生命周期的框架,并包括攻击案例研究。 | https://atlas.mitre.org/ |
NIST AI 100-2 E2023 | 对抗性机器学习的分类法,包括攻击、防御和后果。它提供了一个详细的框架,用于理解和分类人工智能系统的威胁,并提供风险管理指导。 | https://csrc.nist.gov/pubs/ai/100/2/e2023/final |
欧盟 HLEG 可信人工智能 | 由欧盟委员会人工智能高级专家组制定的可信人工智能道德准则。它侧重于以人为本的人工智能原则,包括公平性、透明度、问责制和社会福祉。 | https://digital-strategy.ec.europa.eu/en/library/ethics-guidelines-trustworthy-ai |
ISO/IEC JTC 1/SC 42 | 一个制定人工智能国际标准的国际标准机构。它涵盖人工智能的各个方面,包括风险管理、可信度、偏见和治理。 | https://www.iso.org/committee/6794475.html |
AI Incident Database | 一个真实世界人工智能系统事件的数据库,包括故障、事故和恶意攻击。它为理解与人工智能相关的风险和制定风险管理策略提供了有价值的数据。 | https://incidentdatabase.ai/ |
DARPA's GARD | 保证人工智能抵抗欺骗 (GARD) 计划旨在开发针对人工智能系统对抗性攻击的防御措施。它侧重于开发能够抵御欺骗或操纵企图的强大人工智能。 | https://www.darpa.mil/program/guaranteeing-ai-robustness-against-deception |
OECD AI Principles | 经济合作与发展组织 (OECD) 采纳的负责任管理可信人工智能的原则。它们涵盖了包容性增长、以人为本的价值观、透明度、稳健性和问责制等方面。 | https://oecd.ai/en/ai-principles |
MITRE Atlas Matrix | 对抗性机器学习威胁矩阵是一个框架,用于捕获攻击者攻击机器学习系统所使用的策略、技术和程序。它的结构类似于 ATT&CK 框架,但专门针对机器学习领域。 | https://atlas.mitre.org/ |
CSA LLM Threat Taxonomy | 定义了与云中大型语言模型相关的常见威胁。关键类别包括模型操纵、数据中毒、敏感数据泄露、模型窃取以及特定于基于云的 LLM 部署的其他威胁。 | https://cloudsecurityalliance.org/artifacts/csa-large-language-model-llm-threats-taxonomy |
MIT AI Threat Taxonomy | 全面分类人工智能的攻击面、对抗性技术和治理漏洞。它详细介绍了各种类型的攻击,并提供了缓解策略。 | https://arxiv.org/pdf/2408.12622 |
OWASP Top 10 for LLMs | 强调了大型语言模型应用程序最关键的安全风险。它涵盖了诸如提示注入、数据泄漏、不安全的输出处理和模型拒绝服务等漏洞。 | https://owasp.org/www-project-top-10-for-large-language-model-applications/ |
注意: 此表格旨在作为入门,可能并不详尽。随着人工智能安全领域的不断发展,可能会出现新的分类法和框架。
此 AIVSS 框架应被视为一份活文件。这是 0.1 版,它将被修订和更新。鼓励组织提供反馈,为其发展做出贡献,并根据其特定需求进行调整。将定期发布更新,以纳入新的研究、威胁情报和最佳实践。
AIVSS 框架提供了一种结构化和全面的方法来评估和量化人工智能系统的安全风险。通过使用此框架以及提供的检查表,组织可以更好地了解其人工智能特定的漏洞,优先考虑补救工作,并改善其整体人工智能安全状况。详细的评分细则、包含相关的人工智能威胁分类法、增加环境分数以及关注实际实施,使 AIVSS 成为保护人工智能未来的宝贵工具。持续改进、社区参与以及适应不断变化的威胁形势,对于 AIVSS 的长期成功和采用至关重要。
免责声明:
AIVSS 是一个评估和评分人工智能系统安全风险的框架。它不能保证安全,也不应作为做出安全决策的唯一依据。组织应将 AIVSS 与其他安全最佳实践结合使用,并在评估和减轻人工智能安全风险时始终运用自己的判断。