简介：《网络安全防御能力评价体系框架》是360政企安全在2021年推出的实战化网络安全防御能力度量与评价方法，面向企业安全负责人、安全主管及安全规划团队，着力解决传统等级保护、ISO 27001等度量方式难以预判威胁、缺乏有效性评估的难题，提出从攻防实战视角评估组织防御水平。资源为单个PDF文档，压缩包约7.38MB，内容以演示文稿形式系统拆解方法框架，融合C2M2成熟度模型、NIST CSF的PDR能力、MITRE ATT&CK攻击模型及DoD CAR/GovCAR评估思路。目前已有257人学习，适合需要规划或优化安全防御评价体系的从业者。借助该框架可掌握网络攻击全景知识库、安全产品实战检验、攻击者模拟服务的应用逻辑，并学会盘点核心资产与现有防护，划分攻击阶段逐项打分，形成可落地的防御能力改进路线图。
1. 安全预算花了不少，防御能力到底涨没涨：评价体系框架解决的是这个黑匣子问题
很多安全团队每年花大几百万买设备、上平台、堆人力，年底汇报却只能说“我们部署了 XX 台防火墙、XX 套 WAF、拦截了多少次攻击”。这些数字只能证明“东西在跑”，证明不了“防线真的扛得住”。网络安全防御能力评价体系框架.pdf 这类文档解决的就是这个被问烂了的问题：安全投入和防御效果之间，怎么建立一套可量化、可对比、可复现的度量标准。它不教你怎么配置防火墙，也不教你怎么写检测规则，它定义的是“评价防御能力”这件事本身的规则——选什么指标、怎么打分、权重怎么定、结果怎么解读。适合三类人看：要给上级写安全预算报告的负责人，做等保测评或安全咨询的从业者，以及安全运营团队里想把自己工作价值说清楚的工程师。这套框架的本质，是把玄学变科学。
2. 评价体系框架的底层逻辑：先弄清楚“防御能力”能被测量吗
2.1 防御能力不是一个数，而是一组在不同对抗阶段的表现
网络安全防御能力不是“安全设备数量”或“漏洞清零”，而是组织在攻击链的每个阶段——侦察、入侵、驻留、横向移动、数据外泄——能够延缓、检测、阻止攻击的程度。评价体系框架通常把防御能力拆成几个维度：防护能力（Prevention）、检测能力（Detection）、响应能力（Response）、恢复能力（Recovery），有时再加上预测能力（Prediction）和合规能力（Compliance）。这种拆分的逻辑是：单点防护再强，如果检测和响应跟不上，整体防御依然是脆弱的。
我见过不少团队只盯着“拦截率”这一个指标，结果攻击者绕过 WAF 进到内网后，横向移动了一个月都没被发现。这就是典型的“防护强、检测弱”。评价体系框架的价值在于，它强制你用结构化的方式看待防御，而不是凭感觉说“我们做得还行”。
一个可落地的框架，通常会为每个维度定义测量对象。比如防护能力测量的是“未被绕过前成功阻断的攻击占比”，检测能力测量的是“从入侵发生到被确认的时间差（MTTD）”，响应能力测量的是“从确认到遏制的时间差（MTTR）”。这些测量对象必须满足三个条件：可采集、可重复、可对比。不可采集的指标再科学也是摆设。
2.2 评价框架的三种主流模型：成熟度模型、能力评分卡、攻防验证
目前业界常见的评价模型有三条路线。第一条是能力成熟度模型（CMM），把每个能力域从 1 级（临时/无序）到 5 级（持续优化）分级打分，偏管理视角，适合做长期规划。第二条是安全评分卡（Security Scorecard），把各维度量化为 0-100 分，通过加权汇总成总分，偏运营视角，适合做跨部门横向对比和月度复盘。第三条是攻防验证（Breach and Attack Simulation），用自动化工具持续模拟攻击路径，验证现有防御是否真的生效，偏技术视角，结果最硬但成本也最高。
在“网络安全防御能力评价体系框架”这类文档中，最常见的是第二种评分卡模型，因为它最容易落地，也最容易和 KPI 挂钩。它不需要像渗透测试那样大动干戈，也不需要像 SOC 2 审计那样动辄几个月，它只需要你有一套清晰的数据采集方案，就能按月输出得分趋势。
选型建议是：如果你所在组织安全团队只有三到五人，核心诉求是向上汇报和内部整改优先级排序，评分卡模型是性价比最高的。如果你已经在建安全运营中心（SOC），且数据基础比较扎实，可以在此基础上叠加攻防验证，用实战结果校准评分卡里的权重。
2.3 指标分层：从原始日志到决策指标之间的三层结构
评价体系里最容易翻车的点，是把原始数据直接当指标用。比如说“我们每天拦截 10 万次攻击”，这个数字没有任何评价意义，因为它既没有区分攻击类型，也没有关联业务影响。框架的做法是把指标分成三层：原始数据层（Raw Data）、运营指标层（Operational Metrics）、决策指标层（Decision Metrics）。
原始数据层是日志、告警、流量记录，比如 WAF 拦截日志的数量、IDS 告警条数、EDR 查杀记录。运营指标层是对原始数据的聚合计算，比如“Web 攻击拦截率”“告警误报率”“平均检测时间”。决策指标层才是给管理层看的，比如“整体防御评分”“高危风险敞口占比”“安全事件平均损失”。这三层之间必须能互相追溯——管理层看到一个分数下降，能逐层下钻到具体哪条业务线、哪个安全设备、哪类攻击导致了这个变化。
如果框架文档里没有清晰区分这三层，落地时大概率会变成“数数字”的报表工程。我见过有人把“EDR 查杀率 99.9%”直接写进年度报告，却没解释这 99.9% 是基于什么样本量算出来的——这种指标在评审会上最容易被挑战。
3. 搭建一套可落地的评价指标池：维度、权重与计算方法
3.1 指标池设计：每个维度下挂哪些可采集合规指标
框架不能只给维度，必须给到指标粒度才能动手。下面是一套常见做法的参考指标池，涵盖防护、检测、响应、恢复四个维度。这套表可以直接作为你设计自己指标池的起点，但需要根据你的行业和业务规模调整。
| 维度 | 指标名称 | 计算公式 | 采集来源 |
|---|---|---|---|
| 防护 | 边界拦截有效率 | 已拦截请求 / (已拦截+放行后确认恶意) | WAF、IPS 日志 |
| 防护 | 漏洞修复及时率 | 在 SLA 内修复的漏洞数 / 当期发现漏洞总数 | 漏洞管理平台 |
| 防护 | 基线合规率 | 通过基线检查的主机数 / 纳管主机总数 | 配置核查工具 |
| 检测 | 平均检测时间（MTTD） | 从事件发生到确认告警的时长中位数 | SIEM 事件时间戳 |
| 检测 | 告警误报率 | 确认为误报的告警数 / 总告警数 | SOAR 调查记录 |
| 检测 | 高级威胁发现率 | 手工或工具确认的 APT 类事件 / 总安全事件 | 威胁情报平台 |
| 响应 | 平均响应时间（MTTR） | 从确认到遏制的时长中位数 | 工单系统 |
| 响应 | 应急演练完成率 | 实际完成演练次数 / 计划次数 | 演练记录 |
| 恢复 | 数据恢复成功率 | 成功恢复数据的系统数 / 需恢复系统总数 | 备份平台 |
| 恢复 | RTO 达成率 | 在目标时间内恢复的业务系统数 / 总业务系统数 | 灾备演练报告 |
这套指标池有两个设计原则：第一，每个指标都能在现有系统里找到原始数据来源，不需要为了评价单独开发采集工具；第二，每个指标都有明确的业务含义——误报率低说明检测质量好但可能是检测规则太少，配合“高级威胁发现率”一起看才不会被单一指标误导。
3.2 权重分配：用层次分析法替代拍脑袋
权重是评价体系里争议最大的部分——防护和检测谁更重要？新手团队的答案往往是“都重要，各占 25%”。这种做法在对外汇报时经不起追问。更靠谱的方式是用层次分析法（AHP）来确定权重，核心是让决策者两两比较指标的重要性，再通过一致性检验得出权重向量。
具体操作是这样：邀请安全负责人、运维负责人、业务负责人各一名，对四个维度做两两比较。比如“防护能力比检测能力重要多少？”用 1-9 标度打分，1 表示同等重要，9 表示极端重要。三个人分别打分后，对矩阵求特征向量并做归一化，就得到了权重。如果一致性比例（CR）小于 0.1，说明判断矩阵可以接受；如果大于 0.1，说明打分逻辑前后矛盾，需要重新讨论。
一个简化版的做法是直接用专家经验定权重，但要在文档里写清楚权重设定的依据。我一般会建议：防护权重 30%、检测 30%、响应 25%、恢复 15%。理由是这样的——检测和响应是实战中真正决定损失大小的环节，防护再强也有被绕过的概率；恢复能力虽然重要，但对于大多数非核心业务系统，RTO 的容错空间比较大。这个比例可以根据行业特点调：金融行业可以把恢复权重提到 20% 以上，因为停机损失巨大；制造业如果 OT 网络和 IT 网络隔离做得好，可以把防护权重加到 35%。
3.3 得分计算与归一化：百分制分数怎么从异构指标里算出来
指标池里的指标单位各不相同，有的是比率（0-100%），有的是时间（小时），有的是个数。要合成一个总分，必须先做归一化处理。归一化的方法有两种：线性归一化和分段归一化。比率类指标适合线性归一化，用时均值作为基准线，高于均值加分、低于均值减分；时间类指标适合分段归一化，因为 MTTD 从 2 小时降到 1 小时的边际价值，远大于从 50 小时降到 49 小时。
# 归一化计算示例：分段函数处理不同量纲的指标 def normalize(metric_type, value, thresholds): """ metric_type: 'ratio' 表示比率类指标（越大越好） 'time' 表示时间类指标（越小越好） thresholds: 字典，包含优秀线(goal)、合格线(accept)、最差线(floor) 返回 0-100 的分值 """ if metric_type == 'ratio': # 比率类：达到goal打100分，低于floor打0分，中间线性插值 if value >= thresholds['goal']: return 100.0 elif value <= thresholds['floor']: return 0.0 else: return round((value - thresholds['floor']) / (thresholds['goal'] - thresholds['floor']) * 100, 2) elif metric_type == 'time': # 时间类：越小越好，达到goal打100分，超过floor打0分 if value <= thresholds['goal']: return 100.0 elif value >= thresholds['floor']: return 0.0 else: return round((thresholds['floor'] - value) / (thresholds['floor'] - thresholds['goal']) * 100, 2) return 0.0 # 参数说明： # thresholds 需要结合自身实际情况设定。 # 比如 MTTD 的 goal 设 1 小时（3600秒），floor 设 24 小时（86400秒）， # 意味着检测时长超过 24 小时直接记 0 分，低于 1 小时记满分。 # 这里的阈值不是框架给定的，需要你们安全团队和业务方一起拍板。计算出每个指标的分值后，再用加权求和得到维度分，最后四个维度分乘相应权重相加，就是综合防御能力评分。这个总分的绝对值意义不大，真正有价值的是它的时间序列——连续三个月上升说明整改有效，突然下降说明某个维度崩了，需要立刻定位。
4. 从框架文档到落地运行：最小可行实施方案与数据管道
4.1 第一步：盘点现有数据资产，画出指标与数据源的映射关系
框架文档到实际运行之间的鸿沟，往往是“数据拿不到”四个字。很多指标定义得很漂亮，但你的 SIEM 里根本没有对应的日志字段。所以落地的第一步不是建表，而是做数据资产盘点。
打开你的日志源清单，逐个核对：WAF 日志里有没有“拦截/放行”的字段？EDR 的检测结果能不能导出时间戳？漏洞管理平台的 SLA 字段是自动填充还是手工录入？把这些答案整理成一张映射表，每个指标都标注数据源、采集方式（API/日志转发/手工报表）和更新频率。如果某个指标找不到任何数据源，要么换指标，要么先补日志采集，不要硬编。
这一步的产出物是“指标-数据源映射矩阵”，格式可以很简单：指标名称、数据源系统、关键字段、采集方式、责任人。理论上应该覆盖 80% 以上的指标池，剩下 20% 可以在后续迭代中逐步补全。
提示：不要试图一步到位覆盖所有指标。第一版能稳定采集 50% 的指标，并且能连续输出三个月数据，比勉强采全但数据质量参差不齐要可靠得多。
4.2 第二步：搭一个最小可用的评分计算管道（脚本+数据库+报表）
评价体系落地不需要立刻上商业安全度量平台，用常见的开源技术栈就能跑起来。架构很轻：用 Python 脚本从各系统 API 拉取原始数据，清洗后写入 PostgreSQL，再用 SQL 视图计算出各维度得分，最后通过定时任务生成月度报表。
# 伪代码：月度评价数据管道核心逻辑 import requests import psycopg2 from datetime import datetime, timedelta def pull_waf_logs(start_date, end_date): """ 从 WAF API 拉取拦截日志 参数: 起止日期，返回 DataFrame 格式的数据 注意: 分页拉取，避免单次请求数据量过大导致超时 """ all_logs = [] page = 1 while True: resp = requests.get( 'https://waf.example.com/api/v1/logs', params={'from': start_date, 'to': end_date, 'page': page, 'size': 500}, timeout=30 ) data = resp.json() if not data['items']: break all_logs.extend(data['items']) page += 1 return all_logs def calculate_metric_values(conn, month_start, month_end): """ 从日志明细聚合出指标原始值 连接数据库，执行聚合 SQL，将结果写入指标明细表 """ cursor = conn.cursor() # 计算边界拦截有效率：拦截数 / (拦截数 + 放行后确认恶意数) cursor.execute(""" INSERT INTO metric_daily_values (metric_code, stat_date, value) SELECT 'PREV_BLOCK_RATE', stat_date, SUM(CASE WHEN action = 'block' THEN 1 ELSE 0 END)::float / NULLIF(SUM(CASE WHEN action IN ('block', 'pass_malicious') THEN 1 ELSE 0 END), 0) * 100 FROM waf_logs WHERE stat_date BETWEEN %s AND %s GROUP BY stat_date """, (month_start, month_end)) conn.commit() # 参数说明： # 这里的 NULLIF 处理除零异常——当月没有任何恶意请求时， # 该指标直接置空而不是返回 0 分，避免误导。 # 数据管道要设计成幂等的：同一月份重跑不会产生重复数据。数据管道跑通后，最核心的是要加一层数据质量校验——检查采集的日志量级是否异常、是否有大量空值字段、时间戳是否在合理范围内。没有校验的管道跑出来的分，还不如不跑分，因为错误数据会让管理层对评价体系本身失去信任。
4.3 第三步：用基线核对法校准，先跑 3 个月影子模式
评价体系上线最忌“直接替代人工判断”。我见过有团队把框架跑出来的分数直接写进安全月报，结果第一个月分数异常偏低，上级直接质疑整个体系的可信度。稳妥的做法是：先跑 3 个月的影子模式，分数只给自己看，不对外发布；同时用基线核对法做校准——每个月拿评价结果跟实际发生的安全事件做对照。
具体操作是：列出当月发生的所有真实安全事件，看它们在评价体系里是否有对应体现。比如当月发生了勒索软件感染，但检测维度的 MTTD 得分不降反升，说明数据采集或指标定义有问题。反过来，如果某个维度连续三个月分数很高，但团队实际应对告警时明显力不从心，说明指标设计太宽松。影子模式的本质是让指标体系先经过实际对抗的检验，再正式对外输出。
4.4 第四步：正式发布评价结果并建立月度复盘机制
三个月的影子期过了，得分趋势稳定、且能通过基线核对，就可以正式对外发布了。发布形式不一定要做成大屏，先做成一份标准化的月度报告即可。报告应该包含三块内容：总分及环比变化、各维度得分雷达图、TOP3 薄弱指标的根本原因分析。前两块是管理层的，第三块是给安全团队内部用的。
这里有一个常见的执行问题：指标数据由安全团队自己采集、自己计算、自己发布，评分的公正性容易被质疑。解决办法是：让运维团队或独立的合规岗位参与数据核对，安全团队只负责计算和解读，不负责改数据。公信力比分数本身更重要，一次被质疑的数据造假（哪怕是口误），会让整个评价体系作废。
5. 落地避坑指南：评价体系最常见的 5 个翻车现场
5.1 指标定义不清，同一指标两个团队给不出同一个数
现象：安全团队说误报率是 5%，运营团队说是 15%，两边各执一词，数据对不上。原因：误报率的分子分母定义不一致——安全团队把自动确认为误报的告警算进分母，运营团队把所有未处理的告警也算进了分母。解决：每个指标必须定义清楚“分子是什么、分母是什么、排除条件是什么”，并且把这个定义写死在计算脚本的注释里，同时在指标字典里登记定义、变动历史和数据责任人。
5.2 只看总分，不看维度结构，整改优先级完全跑偏
现象：综合防御评分 85 分，看起来不错，但仔细看是防护维度 98 分拉高了总分，检测维度只有 62 分。原因：加权总分天然会掩盖短板——只要权重大的维度得分高，弱势维度的影响就被稀释了。解决：在月度报告中强制加入“最低维度分”的展示；设定红线线值，比如检测维度低于 70 分时，总分封顶 80 分，不允许用其他维度的高分掩盖短板。
5.3 数据采集失败但没有告警，评分悄然失真
现象：某个月 WAF 侧接口升级，日志 API 返回格式变化，采集脚本静默失败，连续两周数据缺失，但系统照常出分了。原因：采集管道没有数据完整性校验，缺失的数据被聚合 SQL 当成了“没有攻击”，导致拦截有效率虚高。解决：在管道里加入数据量波动检测——当采集日志量环比下降超过 30% 时，直接冻结该指标的本期评分，并触发告警通知数据责任人。
5.4 为了拿高分而优化指标，但实际防御能力并没有提升
现象：检测维度得分持续上升，排查后发现团队把“高级威胁发现率”的分子定义改成了“所有经过人工确认的告警”，把普通的端口扫描也算成了高级威胁。原因：指标定义给执行团队留了过大的解释空间，KPI 压力下必然出现指标套利。解决：在框架文档里为每个指标补充“不可接受的定义”说明，比如明确写出“端口扫描和已知漏洞利用尝试不属于高级威胁”；同时每季度随机抽检指标数据的原始凭证。
5.5 框架照搬行业模板，与自身业务脱节
现象：照抄金融行业模板，把“RTO 达成率”权重设得很高，但自身是制造业，核心工厂的 OT 网络和 IT 网络完全隔离，业务系统停机容忍度本来就高，恢复维度的分数对管理层几乎没有指导意义。原因：模板省事了，但也把别人的业务假设搬了过来。解决：在下一年度做一次框架复审，根据上一年暴露出来的真实风险重新调整权重和指标池——权重不能一劳永逸，它应该随着业务结构和安全态势的变化而演变。
6. 让评价体系不止于打分：把它接到攻防演练和预算决策里
评价体系跑顺之后，最有价值的用法不是月度汇报，而是和两项工作深度联动。第一项是攻防演练复盘——每次红蓝对抗或护网行动结束后，把演练中暴露出的薄弱点映射到评价体系的对应维度上，用演练结果反向校准指标权重。如果演练中多次因为检测不及时导致失分，但检测维度权重仍然是 25%，说明你的权重和真实风险已经脱节了。
第二项是安全预算分配。当评价体系积累了两个年度的数据后，你可以做一件很实际的事：把每个维度的得分变化和对应的安全投入做相关性分析。如果检测维度得分一直偏低，但投入检测工具和人力之后连续两个季度都没有明显改善，说明该换的不是投入力度，而是投入方向。这个分析用简单的回归就能做得出来，关键在于数据要持续、稳定地采集，而不是每隔半年才拍一次脑袋。
我个人的习惯是每个季度用这套框架做一次“个人校准”——和团队一起过一遍指标定义和数据质量，特别留意有没有指标已经平庸到失去区分度。如果某个指标连续六个月所有业务线都是满分，它就需要被替换或细化，因为说明它已经测不出差距了。评价体系是一个活的东西，定期维护比初次搭建更重要。框架文档只是给了你一张地图，路还是要自己一步一步走。希望这些基于实操的经验能帮到你，让你在落地评价体系时少走几段弯路。
本文还有配套的精品资源，点击获取
