简介《网络安全防御能力评价体系框架》PDF是360政企安全推出的实战化网络安全能力度量与评价方法面向企业CISO、安全架构师与蓝队评估人员解决传统等保、ISO27001等体系“看似完善却难以预判真实攻击效果”的痛点。资源为单个PDF文件大小7.38MB内容来自360政企安全专家何帆2021年2月的报告系统梳理了从安全规划困惑、传统度量方法局限性到实战化评价方法网络攻击全景知识库、安全产品实战检验、攻击者模拟服务及360评价体系框架的完整逻辑。框架参考了C2M2成熟度模型、NIST CSF的IPDRR模型、MITRE ATTCK威胁框架及DodCAR/GovCAR评估方法并给出网络拓扑分析、资产盘查、攻击向量评估、成熟度定级等落地步骤能帮助读者建立“以攻防实战成熟度分级”的评估思路。目前已有257人学习适合需要构建或优化本单位安全防御能力评估体系的从业者参考。1. 网络安全防御能力评价体系框架是什么先把“能力”变成可考核的分值很多团队在季度汇报时都会被问住明明漏扫做了、防火墙上了、安全运维也轮值了但领导追问“我们现在的防御能力到底能打几分”时却拿不出一张统一口径的评分表。原因是漏洞数量、告警处置率、补丁覆盖率这些零散数据很难直接回答“能力”这个抽象问题。网络安全防御能力评价体系框架这类文档目的就是把资产、防御、监测、响应、管理这些方向的定性描述翻译成一套带指标、带权重、带证据链的量化分值。它适合甲方安全负责人、合规岗位的同事以及想往安全管理方向转的安全工程师照着框架建评分表回答“现在什么水平、相比上个季度有没有变好、短板在哪里”这三个最基本的问题。2. 评价维度怎么拆从资产、防御、监测到响应的五层映射2.1 先把评价对象分层资产层、防御层、监测层、响应层、管理层一份评价体系如果没有分层指标就会混在一起。常见做法是先按能力域把评价对象拆成五个层资产层关注“我们有多少东西要保护、这些东西是否被准确记录”防御层关注“边界、终端、身份这三道防线是否生效”监测层关注“流量和日志是否看得见、告警是否有人处理”响应层关注“出了问题能不能控制住、能不能恢复”管理层关注“制度、基线、培训和考核是否闭环”。分层不是一成不变的小团队可以把监测和响应合并成一层大团队甚至可以拆出“供应链”或“数据安全”单独成层。但不管怎么分每一层都要能对应到具体的安全岗位和系统否则评价结果出来后不知道该找谁负责。2.2 评价体系框架里最常见的指标映射表能力域到证据源把分层落实到指标最常用的方式是做一张“能力域 → 一级指标 → 证据源 → 评价方式”的映射表。证据源是评价体系里最容易忽略但最关键的字段没有证据源的指标最终都会变成靠人拍脑袋打分。能力域一级指标证据源评价方式资产层资产台账完整率资产管理系统导出清单、IP 存活扫描结果抽样比对计算覆盖率资产层关键资产识别率资产清单里的业务重要度标记人工复核标记是否合理防御层边界防护策略有效性防火墙策略审计报告规则冗余和放通情况核查防御层终端防护覆盖率EDR/杀毒控制台在线率报表在线率低于阈值扣分监测层日志采集覆盖率日志平台接入资产数对比计算接入率与留存天数监测层告警及时处置率工单系统闭合记录按期闭合率换算得分响应层应急预案有效性演练脚本、演练过程录屏按演练完成度和响应时长打分管理层基线合规率基线核查工具导出结果不合规项数量扣分这张表的价值在于每一个指标都绑定了证据源和评价方式。做评价时不需要争论“安全意识重不重要”只需要问一句“这个指标的证据从哪来”。拿不出来的指标要么降权要么从评价体系里先摘掉等条件成熟再补。2.3 为什么不能只盯漏洞数脆弱性指标和能力指标的差别刚开始搭评价体系的人最容易犯的错误是把“漏洞扫描结果”当成评价的全部。漏洞数是脆弱性指标它只能说明“哪些地方存在弱点”不能说明“这些弱点是否真的会被利用、被利用后能不能发现、发现后能不能挡住”。一套系统可能有很多低危漏洞但边界防护和监测做得好外部根本接触不到另一套系统漏洞很少可一旦被攻破内网横向移动完全没有监测手段。所以评价体系框架里脆弱性指标只占防御层的一小部分。能力指标更关注“防御机制是否在持续起作用”策略是否生效、告警是否有人处理、应急响应是否真的能在限定时间内完成。这也是为什么很多框架会把“漏洞闭环率”作为指标而不是“漏洞数量”——闭环率描述的是一个持续运转的过程数量只是一个瞬时快照。2.4 证据链是评价体系的地基一个检查项对应一份记录做评价时常见翻车场景是汇报人拿出一张自查表上面全是“已整改”“已完成”但问他要原始记录拿不出来。所以框架文档里一定要把“证据链”单独定义清楚。一个完整的证据链至少包含四部分原始记录日志、报告、控制台截图、时间戳证明不是临期补做的、责任人证明有人对结果负责、复核状态谁确认过这个结果有效。我自己会把每个检查项都绑定一个“证据包命名规范”比如资产完整性_季度抽检_20250331_张三复核.json。名字里带上维度和时间归档时方便查复评时也方便对比。没有证据链的评分评分再高也是一个黑匣子领导和审计都信不过。3. 指标量化与权重分配把定性结论变成可比较的分值3.1 先统一量纲百分制、等级制还是成熟度模型评价体系里最常见的坑是量纲不统一。有人用百分制有人用五分制还有人直接用“高、中、低”定性最后汇总时全乱套。我建框架时会先规定所有一级指标最终都换算成 0100 分再按区间映射成等级。得分区间等级含义90100A 级能力完善可持续运行7589B 级能力有效存在少量短板6074C 级能力基本具备有明显风险4059D 级能力不足急需整改039E 级能力缺失或失控换算规则要写清楚。比如“告警按期闭合率”本身就是百分比可以直接用而“应急预案有效性”这类定性指标要先把完成情况拆成若干检查点每个检查点二分制通过得满分不通过得零分再折算成百分制。总之每个指标在打分前都得明确“原始值”如何换算成 100 分制否则后面汇总时全是玄学。3.2 权重怎么定从“拍脑袋”到层次分析法的简化路径权重是整个评价体系里争议最多的地方。最粗糙的做法是开会拍脑袋但每次人员变动权重就要吵一轮。稍微可靠一点的做法是用层次分析法的简化版把能力域两两比较问“资产层的完整性和防御层的有效性相比哪个对整体防御能力影响更大”用 15 分记录相对重要程度再归一化得到权重。我常用的一组初始权重是资产层 20%、防御层 30%、监测层 25%、响应层 15%、管理层 10%。这组权重适合大多数内部系统为主、外部攻击面较小的企业。如果是面向公网的业务系统监测层和响应层的权重通常会提高到 30% 和 20%因为暴露面大发现和响应速度比绝对防御更重要。权重不需要一步到位但每次调整都要记录调整理由至少要能回答“为什么防御层比管理层权重大”这个问题。3.3 用一张评分表跑通单个能力域打分步骤与最低通过线单域打分可以拆成五步第一步列出该能力域下方的检查项清单第二步给每个检查项分配权值同一能力域内所有检查项权值之和为 100第三步逐个检查项采集证据第四步按预设规则给每个检查项打分第五步加权汇总得到能力域得分。能力域检查项权值评分规则证据要求防御层边界防火墙策略定期审计30有审计记录且近半年执行过得满分审计报告 PDF防御层终端防护在线率40在线率 ≥ 95% 满分每低 1% 扣 10 分控制台导出截图防御层漏洞闭环率30高危漏洞 30 天内闭环率 ≥ 90% 满分漏洞平台工单列表建议给每个能力域都设一条最低通过线我一般设为 60 分。低于 60 分的域即使总分合格也要在评价报告里单列“红区”警示。这个约束很重要能防止总分被强势域拉高后掩盖了单域的严重短板。3.4 一个辅助计算脚本从检查项结果自动汇总得分评价表一旦超过 20 个检查项手工算分就容易出错。我会把所有检查项结果放在一个 JSON 文件里用 Python 脚本解析并自动汇总各域分值。下面是一个最小实现import json # 每个检查项记录“所属能力域”、“权重”、“得分(0~100)” data [ {domain: 防御层, item: 边界防火墙策略定期审计, weight: 30, score: 100}, {domain: 防御层, item: 终端防护在线率, weight: 40, score: 80}, {domain: 防御层, item: 漏洞闭环率, weight: 30, score: 70}, ] def aggregate(items, min_pass60): domain_scores {} for it in items: d it[domain] domain_scores.setdefault(d, {total_weight: 0, weighted_score: 0}) domain_scores[d][total_weight] it[weight] domain_scores[d][weighted_score] it[weight] * it[score] result {} for d, v in domain_scores.items(): avg v[weighted_score] / v[total_weight] result[d] {score: round(avg, 1), pass: avg min_pass} return result if __name__ __main__: print(json.dumps(aggregate(data), ensure_asciiFalse, indent2))这个脚本的逻辑很简单同一能力域内把“权重 × 得分”累加再除以总权重得到加权平均分。关键参数是min_pass也就是最低通过线默认 60 分。实际使用时我会把输出结果再加工成 CSV方便在复评时做季度环比。脚本本身不是评价体系的核心核心是数据不能造假——脚本只能避免算错不能挽救录错的原始分数。4. 基线检查怎么落到数据源把评价框架接进日常工作4.1 评价数据从哪来漏扫、基线核查、日志审计、渗透测试、靶场演练评价体系框架里的指标再完整没有数据源支撑就是空中楼阁。我习惯把数据源分成五类漏洞扫描报告提供脆弱性数据基线核查工具提供配置合规数据日志审计提供监测有效性的证据渗透测试提供“防线能不能被突破”的直接验证网络安全靶场演练则用来检验响应层的真实水平尤其是应急预案是不是纸面文章。这五类数据源的产出频率不一样。漏扫和基线核查可以按月跑日志审计按周看渗透测试按季度做一次靶场演练至少半年一次。频率不同的数据源对应到评价指标上要做到“看趋势而不是看快照”单次渗透测试的失败不代表整体能力差但连续两次靶场演练都没能在限定时间内止血那就说明响应层确实有问题。4.2 基线检查项怎么映射到评分项一个检查项清单模板把基线检查的结果映射到评价体系是很多团队卡住的地方。基线核查工具一般会输出几百条检查项不可能每条都进评价表。我的做法是先把基线检查项按“影响面”分成三类核心项直接影响边界安全、账号安全、补丁状态、重要项影响运行稳定和数据保护、一般项影响审计合规和运维规范。评价体系只取核心项和部分重要项并给每个评分项绑定明确的评分规则。基线类别检查项示例映射评分项评分规则核心项系统默认管理员账号是否禁用账号安全全部合规满分每发现 1 台不合规扣 15 分核心项高危端口是否对外暴露边界防护不合规端口清零满分每存在 1 个扣 20 分重要项审计日志是否留存 180 天以上日志合规留存达标满分不达标按比例扣分重要项关键补丁是否在发布后 30 天内安装补丁管理安装率 ≥ 95% 满分每低 1% 扣 5 分注意“核心项”要设置一票否决机制只要存在高危端口对外暴露或者默认管理员账号未禁用对应能力域直接判定为“不合格”不参与加权计算。这样能避免多个普通检查项的高分把高危问题掩盖掉。4.3 没有现成数据源怎么办先用半年建立三条最小证据链很多中小企业刚开始搭评价体系时会发现平台没有工具不全连资产清单都是靠人脑记的。这种情况不用硬上大而全的体系我建议先用半年时间建三条最小证据链资产台账证据链每周导出一份资产清单哪怕先用 Excel 手工管、漏洞闭环证据链把每次漏扫和修复记录留档、应急演练证据链每季度做一次桌面推演留脚本和会议纪要。三条证据链对应资产层、防御层和响应层先把这三个域跑通。监测层如果实在没有日志平台可以用“告警响应记录表”先手工记录。半年后数据攒够了再补齐全部能力域的评分。这个节奏比一开始就追求全覆盖要靠谱得多至少第一份评价报告里每个分数背后都有真实记录。4.4 复评周期季度复评和年度深评怎么配合评价体系做一次容易持续运转难。我会把复评拆成两个节奏季度复评只抽查关键指标比如终端在线率、漏洞闭环率、补丁安装率一个月内完成数据采集和打分年度深评做全量核查所有检查项都要过一遍并在季度趋势数据的基础上做能力域间对比分析。季度复评的核心是看趋势比如“漏洞闭环率从 75% 提到 82%”比单纯一个分数有价值得多。年度深评则要回答“整体等级是否提升”并输出下一年度的整改优先级。复评时最忌讳的是更换评价口径比如去年权重资产层 20%今年改成 25%又没有保留旧口径的原始数据导致环比失真。所以每次改口径都要保存一份“口径版本快照”复评时用同一口径算或者做新旧口径的双轨对比。5. 避坑指南评价体系落地最容易翻车的五个地方5.1 评分区间不统一有人打百分制有人打五分制汇总时全乱套现象评价表发下去之后有人按 0100 打分有人按 15 打分还有人直接填“好、中、差”收上来之后根本无法汇总。强行换算之后发现同一个检查项在两组人手里差出三倍的分差。原因框架文档里只写了“请评分”没有预先定义每个检查项的分制、换算规则和打分锚点。评分人对“合格”的理解完全靠自觉结果自然五花八门。解决所有检查项在评分表里都预置好分制统一为 0100 整数分并在每个检查项后面写上打分锚点例如“在线率 ≥ 95% 为 100 分每低 1% 扣 10 分低于 80% 记 0 分”。评分人只能选分不能自创规则。5.2 基线数据缺失结果靠人拍脑袋填现象某个能力域的证据源根本不存在但检查项又必须填于是负责人凭印象填了 85 分汇报时被追问“这个分数怎么来的”答不上来。原因评价表里有些指标是从别的框架抄来的当前团队根本没有对应的系统和工具支撑这些指标。框架定义和实际能力之间差了一整条证据链。解决评价体系上线前做一次“证据源盘点”每个检查项旁边标注当前可用的证据源名称。没有证据源的检查项先移出正式评价表单独放进“建设计划”里等平台补齐后再纳入打分。宁可评分表少一列也不能让数据空洞。5.3 权重长期不动评分结果和现实脱节现象权重是两年前定的当时网络边界是主要风险防御层权重 35%。两年后业务迁到云上边界逐步收缩数据安全成了主要矛盾但防御层权重还是最高的。原因权重没有和风险变化联动。评价体系如果权重多年不变得分会逐渐失真权重高的能力域分数再好也解决不了当前最痛的数据泄露问题。解决每年在复评之前做一次“权重重估”参考当前的安全事件统计、审计发现和业务形态变化来调整权重。调整后保留新旧两套权重算出来的分数在年报里说明权重调整带来的得分变化避免环比数据被误解。5.4 只看总分能力域短板被高分掩盖现象总评 78 分看起来已经是 B 级水平。但拆开看监测层只有 48 分告警几乎处于失控状态只是防御层和管理层分数高把总分拉上来了。原因评价报告只输出一个总分没有设置单域最低通过线。管理者看到总分合格自然认为整体安全无虞忽略了局部失效的能力域。解决在评价规则里加一条硬约束任何能力域得分低于 60 分整体等级最高只能评为 C 级。雷达图放到报告最前面五个能力域各占一个轴任何一个轴明显向内凹陷都能一眼看出短板。5.5 评价结果和整改流程脱节评完就完事现象季度评价报告出来了低分项列得很清楚但下个季度再看低分项还是原来的低分项。评价体系变成了例行公事对实际安全建设毫无推动作用。原因评价流程到“出报告”就结束了没有把低分项转换成整改任务单也没有指定责任人和整改期限。评价和整改之间断了一环。解决每个季度评价结束后自动把低于 60 分的检查项生成整改任务单写明责任人、整改要求和复查时间。下个季度复评时先核对上一期的整改项是否关闭再继续正常打分。“评价 → 整改 → 复评核对”形成闭环评价体系才能真正推动能力提升。6. 进阶用法用雷达图和环比趋势驱动整改闭环评价体系跑顺之后不要停在“算分”这一步。我习惯把每季度的五个能力域得分做成雷达图留存并用一个 CSV 文件记录每次评分的明细。两张图的组合最有说服力一张是同季度五域的雷达图一张是同域名连续四个季度的得分折线。前者能看出短板后者能看出改进速度。汇报时我一般只拿这两张图领导追问细节时再用检查项清单应对。另一个值得试的用法是把评价体系当作“方案对比工具”。比如采购新的安全产品或者调整网络架构时用同一套检查项对改造前和改造后分别打分对比分值变化。这比自己凭感觉判断“新方案有没有用”要客观得多。网络安全靶场演练也可以配合使用在靶场里复现同样的攻击场景看防护方案调整前后的防突破时间和溯源时长变化这些数据可以直接作为评分项的证据而不是只写在演练报告里给人翻。最后说一个我自己的教训早年做评价报告时只给总分结果一个监测能力几乎为零的团队拿了高分第二个月就被真实攻击打了个措手不及。之后我强制要求任何评价必须附带能力域雷达图和原始证据清单没有这两样东西的报告一律不发。诚实面对数据比粉饰总分重要得多。希望这套方法能帮你在推进网络安全防御能力评价体系时少走几步弯路。本文还有配套的精品资源点击获取