红蓝对抗演练评分系统 - RTASS

Red Team Assessment Scoring System ( RTASS )

English doc

维护者: Monyer@JD.Army 协作者: Members@JD.Army, vf3ng

RTASS在线评分工具: https://jd.army/RTASS/?lang=cn

红蓝对抗演练评分系统（RTASS）是一个开放式框架，用来评估单次网络红蓝对抗或实战演习中的攻防双方能力投入情况，以及涉及业务及所在企业所面临的风险程度。

RTASS由JD.Army创建、拥有和进行管理。JD.Army专注于挖掘和解决企业安全运行风险隐患的专业型红队。JD.Army保留自行决定定期更新RTASS和本文档的权利。虽然JD.Army拥有RTASS的所有权利和利益，但它许可公众自由使用，遵循Apache开源协议。

更新日志

• v0.2.2, 2021-11-15, 修改了RTASS键值名称，撰写了英文文档
• v0.2.0, 2021-11-11, 重新划分了因子的评分维度
• v0.1.0, 2021-11-04, 创建

背景

很多年前，企业通常仅靠采用“渗透测试”挖掘单个应用系统漏洞的方式来评估自身安全。为了评估漏洞的危害性，美国国家基础设施顾问委员会（NIAC）开发了一套通用漏洞评估系统CVSS，并交由事件响应和安全团队论坛（FIRST）进行托管。FIRST在前序版本基础上，又继续迭代了v2和v3版本，针对单个漏洞的危害性评估标准越来越精确和完善，也被各大安全组织和漏洞收录平台所使用。

随着网络安全的发展，面临的网络威胁与日俱增，通过模拟黑客APT攻击手段与行为，对企业开展综合性安全评估的红蓝对抗实战演习方式开始被广泛采用。有些组织单位为了对攻击方之间以及防守方之间进行评估，也制定了一些评分制度。但这种评分制度只能衡量攻击方与攻击方之间，防守方与防守方之间的差异，科学性也有待商榷，也无法做攻击方与防守方间的能力对比。而在仅有一支攻击队伍和一支防守队伍的情况下，问题则更加突出：如果核心系统被突破，那么是说明攻击队伍强，还是说明防守队伍弱呢？如果核心系统没有被突破，那么是攻击队伍弱，还是防守队伍强呢？这是非常难衡量的，业内也没有一套成熟的体系来进行评价。因此JD.Army结合多年网络实战攻防演习以及红蓝对抗经验，参考CVSS以及OWASP风险评级方法，开发了这套针对实战演习场景下的红蓝对抗评分框架。

介绍

RTASS（Red Team Assessment Scoring System）是一套针对红蓝双方对抗式网络实战攻防演练中，攻击方、防守方、业务方以及企业风险进行评分的框架。

RTASS适用于网络红蓝对抗演练、网络实战攻防演习、红队评估、蓝军评估等通过模拟黑客APT手段对企业开展实网攻击的安全评估场景。

目前版本，RTASS通过评估因子形成6个过程分值。过程分值再通过不同组合，形成针对攻击方、防守方、业务以及企业等不同角色的四项最终分值：进攻能量、防守能量、业务风险和企业风险。

• 进攻能量是攻击方在单次演练中做的有效输出，可代表攻击方之于本次演练的水平；
• 防守能量是防守方在单次演练中的有效输出，可代表防守方之于本次演练的水平；
• 业务风险指业务在安全上暴露的风险程度，可代表参演业务方在本次演练中的安全水平；
• 企业风险指企业在安全上暴露的风险程度，可代表企业整体上在本次演练中表现出的安全水平。

这四项分值均指代在单次演练中的情况，因此在不同的演练中，分值可能会有所不同。 下面将对评分的方法和因素进行详细介绍。

方法

RTASS评分框架整体上由“攻防因素”与“业务（影响）因素”两大类别构成。 攻防因素主要是从进攻以及防守角度上去衡量各自的强度，对渗透路径中的关键漏洞的杀伤力进行评价，最终结合业务因素形成“进攻能量”和“防守能量”分值。

业务因素主要是是从可对企业造成的影响，业务安全能力水平，以及CIA信息安全三要素角度进行评价，最终结合攻防因素形成“业务风险”和“企业风险”分值.

我们以攻防因素为例：

• 进攻实力指攻击方在单场次红蓝对抗演练中，在关键渗透路径上使用攻击技术的最高水平
• 防守实力指防守方在单场次红蓝对抗演练中，在关键渗透路径上使用防守技术的最高水平
• 漏洞风险指在单场次红蓝对抗演练中，在演练的关键渗透路径上对最关键漏洞的风险性评价

为什么一定是“关键路径”和“最高”、“最关键”呢？

这是因为在单场次红蓝对抗当中，攻击者能够采取不同的战略形成不同的进攻路径，并在进攻路径中使用数十、上百种不同的TTPs。如果依次针对这些TTPs进行衡量，很明显是不现实的，也大幅增加了评估的工作量。

安全遵循“短板原理”，同样也遵循“长板原理” —— 攻击者不需要保证每一次TTPs的投入都是最高的技术能力，只要在关键路径上有一次或几次的高水平，就有可能把企业目标拿下。 所以我们以攻击者在进攻关键路径上投入的最高水平作为他们的进攻实力的表现。

显然，我们也能看出：攻击者实力并不能代表攻击者在单次红蓝对抗演练中的总的有效技术投入。我们拿物理学做个比喻：一个人在一个物体上施加的最大力，并不能代表这个人在物体上做的有效功。所以，为了衡量攻击者的“功”，我们引入“进攻能量”概念，用以表示攻击者在单次红蓝对抗演习中的总有效投入，也即攻击者在本次演练中投入的技术水平。

在目前版本中:

• “进攻能量”与“进攻实力”、“防守实力”、“企业影响”有正向关系。
• “防守能量”与“防守实力”有正向关系，与“漏洞风险”、“企业影响”有反向关系。
• “业务风险”与“技术影响”、“企业影响”有正向关系，与“业务实力”有反向关系。
• “企业风险”与“防守实力”有反向关系，与“漏洞风险”、“企业影响”有正向关系。

当然，上述关联也有可能随着RTASS的进化有所改变，目前各因子、因素之间的系数均为1，后续也有可能根据更新的理念发生变化。

在本评分框架中，每个因子都有0到5共6个评分项。而过程分值和最终分值：最低分0分，最高分为10分。其中，各分值对应等级的分布如下：

分值	等级
0.00分	无
0.01 - 3.99分	低
4.00 - 6.99分	中
7.00 - 8.99分	高
9.00 - 10.00分	极

注：本框架部分评分因子如“漏洞风险”、“企业影响”等参考借鉴了OWASP风险评级方法中相关因子。

下面将对现版本RTASS的各分值的计算、各因素和因子进行详细讲解：

进攻能量

• 进攻能量 = ( 进攻实力 * 系数 + 防守实力 * 系数 + 企业影响 * 系数 ) / 3

进攻能量指代攻击方在单次演练中做的有效的“功”。如果使用了很高级的技术，费了很大力气，但是没有取得功效，那么相当于在本次演练中做了无用功，就意味着进攻能量很低。

为了衡量攻击者的有效能力输出，我们将其与“进攻实力”、“防守实力”、“企业影响”绑定。进攻实力比较好理解，我们引入“防守实力”因素是为了校正“进攻实力”在能力上的有效展现。一般来讲，防守的实力越强，在达成同等目标的前提下，说明攻击的实力越强；反之，如果防守者的实力越弱，那么为了达成目标，攻击者通常可以有更少的投入。“企业影响”是用于衡量攻击者“做功”上的有效性。在单次演练中暴露的企业风险越多，说明攻击者的能量越强；反制，暴露的企业风险越少，说明攻击者在演练中的能量越小。

防守能量

• 防守能量 = ( 防守实力 * 系数 + ( 10 - 漏洞因素 * 系数 ) + ( 10 - 企业影响 * 系数 ) ) / 3

同进攻能量一样，防守能量指代防守方在单次演练中做的有效“功”。但不能简单认为“防守实力”就是防守的能量体现。因为即便防守的实力很强，如果在进攻关键路径上暴露了严重的漏洞风险，那么说明防守的实力并没有落在实处，应该予以减分。同样，即便实力很强，漏洞面也很小，但是依然能给企业带来重大的影响，说明防守产生的有效能量是不够的，要予以减分。

所以防守能量与防守实力成正比，与漏洞风险、企业影响成反比。

业务风险

• 业务风险 = ( 技术影响 * 系数 + 企业影响 * 系数 + ( 10 - 业务实力 * 系数 ) ) /3

如果关键系统在技术影响上的问题较大，则说明在保密性、完整性和可用性这三大信息安全维度上出现了较大问题；如果是能够给企业带来较大的影响，不管是经济损失、商誉损失还是合规影响，那么都会较大程度上影响企业的发展；而如果是因为SDL或者是DevSecOps的落实上出现了问题，那么将会在安全的推进以及风险的消除上带来较大的阻碍。

也就是说，当业务系统受到威胁后，技术影响越大、企业影响越大、暴露的安全能力越差，说明业务面临更大的威胁，因此业务风险与技术影响、企业影响呈正向关系，与业务实力呈反向关系。

企业风险

• 企业风险 = ( ( 10 - 防守实力 * 系数 ) + 漏洞风险 * 系数 + 企业影响 * 系数 ) / 3

一个企业如果在安全建设上的投入不大，一般会直接作用在防护能力、检测能力和响应能力上，即防守实力上。反之，如果企业防守实力弱，那么说明企业在安全建设或者防守团队建设上面临问题，将使企业面临更多的风险；演练中，在关键的渗透路径上的关键漏洞是非常容易发现的、非常容易利用的，并且杀伤力极大的，一般其实说明防守在日常的安全运营和SDL或DevSecOps的安全流程落地上出现了比较大的问题和隐患，企业的安全性出现较大问题；而“企业影响”更是影响到企业的正常运营、营收甚至是生死存亡。

因此，企业风险分值与防守实力呈反向关系，防守实力越弱，企业风险越高；与漏洞风险、企业影响呈正向关系，漏洞风险越大、企业影响越大，则企业风险越高。

评分因素

攻防因素

攻防因素由进攻实力、防守实力、漏洞因素三部分组成

进攻实力[OS]

进攻实力由进攻水平、进攻难度、目标达成情况三个因子计算得出，计算方法为：

• 进攻实力 = ( 进攻水平 * 系数 + 进攻难度 * 系数 + 目标达成 * 系数 ) / 3

进攻水平[OL]

主要评估本次演练，攻击者在评估路径中使用的最高技术水平？

• 0 - N/A
• 1 - 相当于入门级黑客
• 2 - 相当于普通水平黑客或工具、脚本黑客
• 3 - 等同精通渗透技术的黑客
• 4 - 需要较为专业的团队配合
• 5 - 相当于国家级APT黑客团队

进攻难度[OD]

主要评估本次演练，攻击者在整个评估路径中搞定难题的最高难度？

• 0 - N/A
• 1 - 几乎没有难度
• 2 - 有点难度
• 3 - 较大难度
• 4 - 很难搞定
• 5 - 几乎不能搞定

目标达成[TR]

主要评估本次演练，攻击者是否达成预期目标？

• 0 - N/A
• 1 - 基本没达成
• 2 - 少量达成
• 3 - 中量达成
• 4 - 大量达成
• 5 - 完全达成

一般来说，我们要求在演练目标的制定上一定要设定企业重要的核心系统，在目标完全被拿下的情况下，可以对企业造成非常严重影响。

防守实力[DS]

防护实力由防护水平、威胁监测水平、应急响应水平、溯源反制水平四个因子计算得出，计算方法为：

• 防护实力 = ( 防护水平 * 系数 + 监测水平 * 系数 + 响应水平 * 系数 + 溯源水平 * 系数 ) / 4

防护水平[PL]

主要评估本次演练，防守者对关键渗透路径的拦截能力？

• 0 - N/A
• 1 - 几乎没有拦截
• 2 - 轻微的拦截
• 3 - 较强的拦截
• 4 - 非常强的拦截
• 5 - 几乎难以突破

监测水平[DL]

主要评估本次演练，防守者对关键渗透路径的网络威胁发现能力？

• 0 - N/A
• 1 - 几乎监测不到威胁
• 2 - 监测到周边攻击威胁
• 3 - 监测到少量关键路径威胁
• 4 - 监测到大量关键路径威胁
• 5 - 几乎监测到全部威胁

响应水平[RL]

主要评估本次演练，防守者对沦陷系统的恢复能力、修复能力和应急响应能力？

• 0 - N/A
• 1 - 几乎难以推进（一周以上）
• 2 - 响应较为缓慢（24小时以上）
• 3 - 响应较为及时（24小时内）
• 4 - 响应接近实时（2小时内）
• 5 - 实时响应（30分钟内）

从PDR的公式，我们知道当：

Pt > Dt + Rt,

不等式成立时，即“防御时间 > 监测时间 + 响应时间”时，证明防守者的应急响应是成功的。在对防御时间的确定上，我们根据多年实战攻防演习经验，估算了一个区间：一般来说，攻击者进行横向移动的时间在30分钟到8小时左右。因此如果响应时间比30分钟还小，那么防守者基本上可以在攻击者进一步开展横向移动时，将攻击者踢出系统。同样，如果防守者响应时间大于8小时，在对系统进行响应时，通常攻击者已经横向移动到了企业内网的其他位置。

当然，这个时间还有待商榷，各框架使用者可以根据企业自身情况进行动态调整。

溯源水平[TL]

主要评估本次演练，防守者是否能够对攻击者进行有效溯源？

• 0 - N/A
• 1 - 几乎不能有效溯源
• 2 - 可以找到攻击者使用的DNS、C2等信息
• 3 - 可以溯源到攻击者横向移动路径
• 4 - 可以找到攻击者的部分真实IP或虚拟身份
• 5 - 可以对攻击者进行成功溯源反制

漏洞风险[VR]

漏洞风险由漏洞的可发现性、可利用性以及杀伤力三个因子计算得出，计算方法为：

• 漏洞风险 = ( 漏洞可发现性 * 系数 + 漏洞可利用性 * 系数 + 漏洞杀伤力 * 系数 ) / 3

漏洞可发现性[VD]

主要评估本次演练，渗透路径中的关键漏洞的可发现性？

• 0 - N/A
• 1 - 几乎难以发现
• 2 - 困难
• 3 - 中等
• 4 - 简单
• 5 - 可用的自动化工具

漏洞可利用性[VE]

主要评估本次演练，渗透路径中的关键漏洞的可利用性？

• 0 - N/A
• 1 - 几乎难以利用
• 2 - 困难
• 3 - 中等
• 4 - 简单
• 5 - 可用的自动化工具

漏洞杀伤力[VL]

主要评估本次演练，渗透路径中的关键漏洞的最大杀伤力？

• 0 - N/A
• 1 - 几乎没有危害
• 2 - 较低的杀伤力
• 3 - 中等规模的杀伤力
• 4 - 大范围的杀伤力
• 5 - 极其广泛的杀伤力

业务因素[]

业务因素由技术影响、企业影响、业务影响三部分组成

技术影响[TI]

技术影响由CIA安全三要素组成，即保密性、完整性、可用性，并成反向关系，计算方法为：

• 技术影响 = ( 失去保密性 * 系数 + 失去完整性 * 系数 + 失去可用性 * 系数 ) / 3

失去保密性[LC]

主要评估本次演练，可以泄露多少数据以及它的敏感度如何？

• 0 - N/A
• 1 - 可泄露少量的非敏感数据
• 2 - 可泄露少量的敏感数据
• 3 - 可泄露中量的敏感数据
• 4 - 可泄露大量的敏感数据
• 5 - 可泄露全部的敏感数据

失去完整性[LI]

主要评估本次演练，有多少数据可能被损坏，损坏程度如何？

• 0 - N/A
• 1 - 可损坏少量非核心数据
• 2 - 可损坏少量的核心数据
• 3 - 可损坏大量非核心数据
• 4 - 可损坏大量核心数据
• 5 - 可损坏全部数据

失去可用性[LA]

主要评估本次演练，可能会丢失多少服务，它有多重要？

• 0 - N/A
• 1 - 可导致企业少量的非核心业务中断
• 2 - 可导致企业少量的核心业务中断
• 3 - 可导致企业中量的核心业务中断
• 4 - 可导致企业大量核心业务中断
• 5 - 可中断企业几乎所有重要业务

企业影响[EI]

企业影响由演练成果所能造成最大危害所引起的：经济损失、商誉损失、合规影响三个因子计算得出，计算方法为：

• 企业影响 = ( 经济损失 * 系数 + 商誉损失 * 系数 + 合规影响 * 系数 ) / 3

经济损失[FD]

主要评估本次演练，可对企业经济造成的最大影响？

• 0 - N/A
• 1 - 低于修复漏洞的成本
• 2 - 不会对企业年利润有明显影响
• 3 - 可以影响一定的企业年利润
• 4 - 对企业年度利润有显著影响
• 5 - 对企业年利润影响重大

商誉损失[RD]

主要评估本次演练，是否会导致企业声誉受损从而损害业务？

• 0 - N/A
• 1 - 轻微的伤害
• 2 - 大客户或大量客户流失
• 3 - 商誉损失
• 4 - 品牌损害
• 5 - 品牌重大损害

合规影响[CI]

主要评估本次演练，出现的问题或攻击者进行恶意行动会带来多少违规风险？

• 0 - N/A
• 1 - 几乎不违规
• 2 - 轻微违规
• 3 - 明显违规
• 4 - 高调违规
• 5 - 严重违规或违法

业务实力[BS]

从系统及应用风险面来看，安全会较多地体现在安全性需求设计、安全编码、安全测试、安全运维、安全防护、应急响应、安全意识、终端防护、安全架构、安全管理、现实安保、供应链安全等方面。其中安全性需求设计、安全编码、安全测试、安全架构属于开发生命周期范畴，安全运维、终端防护、安全管理都属于运维生命周期范畴。安全意识、现实安保属于员工安全意识范畴。安全防护、应急响应属于安全运营团队的PDR范畴。

所以在对业务实力进行评价时，我们刨除掉安全运营团队（防守方）因素，分成安全开发生命周期、安全运维生命周期和员工安全意识三个因素。计算方法为：

• 业务实力 = ( 开发生命周期 * 系数 + 运维生命周期 * 系数 + 员工安全意识 * 系数 ) / 3

开发生命周期[DLC]

主要评估本次演练，是否发现在软件开发生命周期中存在安全问题？

• 0 - N/A
• 1 - 基本没有考虑安全问题
• 2 - 有大量的安全流程问题
• 3 - 有中量的安全流程问题
• 4 - 有少量的安全流程问题
• 5 - 几乎没有安全流程问题

运维生命周期[OLC]

主要评估本次演练，是否发现在运维生命周期中存在安全问题？

• 0 - N/A
• 1 - 基本没有考虑安全问题
• 2 - 有大量的安全流程问题
• 3 - 有中量的安全流程问题
• 4 - 有少量的安全流程问题
• 5 - 几乎没有安全流程问题

员工安全意识[ESA]

主要评估本次演练，在评估过程中大部分员工是否有安全意识问题？

• 0 - N/A
• 1 - 几乎全员没有安全意识
• 2 - 大部分关键岗位员工安全意识较弱
• 3 - 少部分关键岗位员工安全意识较弱
• 5 - 大部分关键岗位员工安全意识较高
• 6 - 全部员工都有极高的安全意识

向量字符串

参考CVSS评分框架，RTASS同样使用“向量字符串”来记录评分过程，以及对RTASS指标信息进行传输。RTASS向量字符串以标签“RTASS:”和当前版本的数字表示（譬如：1.0.0）开头。指标信息以一组指标的形式出现，每个指标前面都有一个正斜杠“/”，作为分隔符。每个指标都是缩写形式的指标名称、冒号及指标值构成。缩写形式在本规范的前面定义（在每个因素名称后面的括号中），并在下表中进行了总结。

因素名称	可能的值	是否必须？
进攻水平[OL]	0-5	是
进攻难度[OD]	0-5	是
目标达成[TR]	0-5	是
防护水平[PL]	0-5	是
监测水平[DL]	0-5	是
响应水平[RL]	0-5	是
溯源水平[TL]	0-5	是
漏洞可发现性[VD]	0-5	是
漏洞可利用性[VE]	0-5	是
漏洞杀伤力[VL]	0-5	是
失去保密性[LC]	0-5	是
失去完整性[LI]	0-5	是
失去可用性[LA]	0-5	是
经济损失[FD]	0-5	是
商誉损失[RD]	0-5	是
合规影响[CI]	0-5	是
开发生命周期[DLC]	0-5	是
运维生命周期[OLC]	0-5	是
员工安全意识[ESA]	0-5	是

示例如下： RTASS:0.1.6/AL:4/AD:2/TR:4/PL:2/DL:3/RL:2/TL:5/VD:4/VE:4/VL:4/LC:4/LI:4/LA:4/FD:3/RD:3/CI:4/DLC:2/OLC:4/ESA:2

向量字符串应包含上表中所示全部指标，接受任何顺序的度量。如果向量字符串多次包含相同度量，则以最后一次度量为准。

关于RTASS的一句话

RTASS框架在设计上通过各基本因子计算生成过程分值，再通过过程分值生成最终分值。算法为未来的扩展预留了空间，但在现阶段数据还不太充足的情况下，因子的系数基本还是为1。

CVSS在解决此问题上，采取的方式是通过CVSS特别兴趣小组(SIG)人工构建了一套真实漏洞对应严重性的查找表，再反过来调整参数。最终保证人工评估漏洞分值与CVSS框架评估分值的偏差值小于0.5.

由于红蓝对抗演练与漏洞的不同，目前无法通过大量现成的样本来调整参数。但我们会不断收集新样本，通过人工评定以及参考更新的方法论，来使得RTASS的分值更加精确。这也需要阅读本规范的您的多加参与和大力支持。

协作 & 贡献

本框架采用JSON格式进行了系统描述，详见“/src/RTASS.json”文件，其中：

• 评分因子放于“factors”对象中，包括每个因子的0到5的中英文分值描述
• 过程分值通过“processScores”进行描述，其中“algorithm”为评分算法。
• 最终得分通过“finalScores”进行描述，其中“algorithm”为评分算法。
• “levels”对象存储分值与极、高、中、低之前的对应关系。
• “factorGroups”对象存储攻防因素和业务因素两大分组与过程分值的对应关系。

各协作者可以通过修改RTASS.json文件对各评分因子的描述以及评分算法来与我们进行该系统框架的协作开发。

致谢

暂无

参考链接

• https://owasp.org/www-community/OWASP_Risk_Rating_Methodology
• https://www.first.org/cvss/v3.1/specification-document
• https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System

RTASS在线计算器

• 中文版：https://jd.army/RTASS/?lang=cn
• English Version：https://jd.army/RTASS/?lang=en