联盟团标 网络安全等级保护测评高风险判定指引
Categories:
2 分钟阅读
T/ISEAA 001-2020 网络安全等级保护测评高风险判定指引 | Async Wiki.js
基本介绍
编制背景
在近几年全国等级保护报告抽查活动中，发现全国各家测评机构对安全问题的风险判断尺度差异很大。
分析其原因
- 各测评对象的现场实际情况各不相同，但是在报告中未进行详细描述；
- 安全问题风险分析主观性判断较强，测评人员的个人能力、经验以及对标准条款的理解不同，都可能影响最后的风险判定结果；
- 有个别测评机构在风险判断上，尺度明显较松，出现测评报结论与风险不符。
因此，中关村测评联盟委托全国多家测评机构，组织共同制定了《网络安全等级保护测评高风险判定指引》。
编制目的
- 集全国各家机构经验，基于”一般应用系统场景“，提出一些应判高风险的场景，给测评人员—个参考尺度，使等保测评工作更加标准化，规范化；
- 与等保标准各等级中的核心要求相对应，把一些基础的、必须做到的要求明确提出来，从而提高被测系统的防护能力。
当前状态
从2018年6月立项起，至2020年11月，共经历了5次全国测评机构征求意见，2次测评机构小范围征求意见，2次专家会，修订了十余版，于2020年11月5日直发布，12月1日实施。
总共收录了69条判例，对应40余标准要求。
编制思路
问题1：哪些问题应判为高风险？高风险判定得原则是什么？
- 不符合国家法律法规、行业主管部门明确规定的情况，应判为高风险。
要求测评人员：关注、了解网络安全法及国家、行业主管部门发布各项规定。 - 不符合或未实现《基本要求》中各等级、层面核心要求及基本安全功能，且无等效或补偿措施降低风险等级的情况，应判为高风险。
要求测评人员：把握等保各级核心要求、基本安全功能，强调底线意识。 - 通过技术测试发现被测目标存在可被高度利用，并可能对被测系统产生严重后果的情况，应判为高风险。
要求测评人员：重视技术测试，尤其是以攻击者的视角去审视目标系统的安全性，贴近实战。
问题2：高风险判例是否应该“一刀切”？
在“补偿因素”中会提出一些可缓解风险的具体措施以及可与其他层面控制点进行整体分析从而综合判断风险等级的分析方向供测评师参考，当然，测评师应
在报告中要对实际情况以及相关风险进行详细描述及分析。
问题3：提出的高风险问题是否能够进行整改？
所有提出“高风险”场景在正常情况下均是能够进行整改，并在附录的“整改建议”中会给出针对性，可落地实现的整改意见。
特别注意
- 《指引》不可能枚举所有场景，也不可能覆盖所有行业系统；对于一些特定行业的系统（比如工控系统），测评人员可以根据本隹内容，结合行业主管部门要求、系统特点、现有措施等综合进行风险分析；
- 对于《指引》未涉及的场景，或虽然不在《指引》明确的适用范围内，但确实可能产生重大安全隐患的情况，测评人员须结合实际情况，对安全问题所引发的风险等级做出客观判断；
- 《指引》中的"补偿因素"也不可能枚举所有可缓解措施；如果测评过程中发现存在未列出的安全措施，但确实可以降低风险等级，测评人员可结合实际情况，对安全问题引发的风险等级做出客观判断；
- 目前《指引》还不完整，对于扩展要求井没有针对性的案例，测评人员可结合实际情况以及前面提到的高风险判定原则做出客观判断。
判例要点
判例结构
标准要求：该条判例可以对应哪条等保要求；
适用范围：明确该条判例所适用的系统等级；
判例场景：描述该条判例具体的场景及要素（在正式稿中将"判例内容“和"满足条件"做了合并）；
补偿因素：提出一些可缓解风险等级的场景、措施，或提出可以从哪些维度进行综合风险分析，供测评师参考。
注：整改建议将以附录的形式出现，给出针对性的，可落地实现的整改意见。
安全物理环境（2项）
一、防火：机房防火措施缺失
标准要求：机房应设置火灾自动消防系统，能够自动检测火情、自动报警，并自动灭火。
适用范围：二级及以上系统。
判例场景（任意）：
- 机房无任何有效消防措施，例如无检测火情、感应报警、灭火设施，手提式灭火器等消防设备未进行年检或已无法正常使用等情况，
- 机房所采取的灭火系统或设备不符合国家的相关规定。
补偿因素：机房安排专人值守或设置了专人值守的监控系统，并且附近有符合国家消防标准的灭火设备，一旦发生火灾，能及时进行灭火，可根据实际措施效果酌情判定风险等级。
二、电力：机房无短期备用电力供应措施
标准要求：应提供短期的备用电力供应，至少满足设备在断电情况下的正常运行要求。
适用范围：二级及以上系统。
判例场景（任意）：
- 机房无短期备用电力供应设备，例如UPS、柴油发电机、应急供电车等；
- 机房现有备用电力供应无法满足定级对象短期正常运行。
补偿因素：对于机房配备多路供电，可从供电方同时断电发生概率等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：机房要有必要的短期备用供电设备/措施。
底线解读：要有合规的消防措施，一旦发生火灾，能及时灭火。
安全通信网络（3项）
一、网络架构：网络区域划分不当
标准要求：应划分不同的网络区域，并按照方便管理和控制的的原则为各网络区域分配地址。
适用范围：二级及以上系统。
判例场景：重要网络区域与非重要网络在同一子网或网段，例如承载业务系统的生产网络与员工日常办公网络，面向互联网提供服务的服务器区与内部网络区域在同一子网或网段等。
补偿因素：同网之间有技术手段实现访问控制，可根据实际措施效果，酌情判定风险等级。
底线解读：合理划分网络区域，不要"打统账"，混在一张大网里，要为后期进访问控制提供便利。
二、网络架构：重要网络区域边界访问控制措施缺失
标准要求：应避免将重要网络区域部署在边界处，重要网络区域与其他网络区间应采取可靠的技术隔离手段。
适用范围：二级及以上系统。
判例场景：在网络架构上，重要网络区域与其他网络区域之间（包括内部区界和外部区域边界）无访问控制设备实施访问控制，例如重要网络区域与互联网等外部非安全可控网络边界处、生产网与员工日常办公网之间、生产网与无线网络接入区之间未部署访问控制设备实现访问控制措施等。
补偿因素：无
底线解读：重要网络边界之间要部署访问控制设备进行访问控制，尤其是互联网边界、办公网、运维网等。
三、通信传输：重要数据明文传输
标准要求：应采用密码技术保证通信过程中娃的保密性。
适用范围：三级及以上系统。
判例场景：鉴别数据、个人敏感信息或重要业务数据等以明文方式在不可控网络环境中传输。
补偿因素:
- 使用多种身份鉴别技术、限定管理地址等措施，获得的鉴别信息无法直接登录应用系设备，可根据实际措施效果酌情判定风险等级；
- 可从核查对象的作用、重要程度以及信息泄露后对整个系统或个人产生的影响等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读:分析数据保护需求，对有传输保密性保护需求的数据进行必要的保护。
安全区域边界（5项）
一、安全审计：网络安全审计措施缺失
标准要求：应在网络边界、重要网络节点进行安全审计，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计。
适用范围：二级及以上系统。
判例场景（所有）：
- 在网络边界、关键网络节点无法对重要的用户行为进行日志审计；
- 在网络边界、关键网络节点无法对重要安全事件进行日志审计。
补偿因素：无。
注：网络安全审计指通过对网络边界或重要网络节点的流量数据进行分析，从而形成的网络安全审计数据。
底线解读：对于重要的用户行为及安全事有日志记录，对重要事件可追溯。
二、边界防护：无线网络管控措施缺失
标准要求：应限制无线网络的使用，保证无线网络通过受控的边界设备接入内部网络。
适用范围：三级及以上系统。
判例场景：内部重要网络与无线网络互联，且不通过任何受控的边界设备，或边界设备控制策略设置不当，一旦非授权接入无线网络即可访问内部重要资源。
补偿因素：对于必须使用无线网络的场景，可从无线接入设备的管控和身份认证措施、非授权接入的可能性等角度进行风险分析，根据分析结果，酌情判定风险等级。
底线解读：谨慎使用无线网络，避免非授权终端通过无线网络访问重要资源。
三、入侵防范：外部网络攻击防御措施缺失
标准要求：（二级）应在关键网络节点处监视网络攻击行为。（三级、四级）应在关键网络节点处检测、防止或限制从外部发起的网络攻击行为。
适用范围：二级及以上系统。
判例场景（任意）：
- 二级系统关键网络节点无任何网络攻击行为检测手段，例如未部署IDS入侵检测系统；
- 三级及以上系统关键网络节点对外部发起的攻击行为无任何防护手段，例如未部署IPS入侵防御设备、WEB应用防火墙、反垃圾邮件、态势感知系统或抗DDoS设备等；
- 网络攻击/防护检测措施的策略库/规则库半年及以上未更新，无法满足防护需求。
补偿因素：主机设备部署入侵防范产品，且策略库、规则库更新及时，能够对攻击行为进行检测、阻断或限制，可根据实际措施效果，酌情判定风险等级。
注：策略更新时间、防护设备仅是举例参考，具体应结合业务场景及安全需求。
底线解读：按照系统所面临的威胁，要有必要的抵御外部攻击能力。
四、入侵防范：内部网络攻击防御措施缺失
适用范围：三级及以上系统。
判例场景（任意）：
- 关键网络节点对内部发起的攻击行为无任何检测、防护手段，例如未部署IDS入侵检测系统、IPS入侵防御设备、态势感知系统等；
- 网络攻击/防护检测措施的策略库/规则库半年及以上未更新，无法满足防护需求。
补偿因素：
- 对于主机设备部署入侵防范产品，可从策略库/规则库更新情况、对攻击行为的防护能力等角度进行综合分析，根据分析结果，酌情判定风险等级；
- 对于重要网络区域与其他内部网络之间部署防火墙等访问控制设备，且对访问的目标地址、目标端口、源地址、源端口、访问协议等有严格限制，可从现有措施能否对内部网络攻击起到限制作用等角度进行综合风险分析，根据分析结果，酌情判定风险等级；
- 对于与互联网完全物理隔离或强逻辑隔离的系统，可从网络、终端采取的管控，攻击源进入内部网络的可能性等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：内部网部井非绝对安全，要对”东西向"攻击有所防范。
五、恶意代码和垃圾邮件防范：恶意代码防范措施缺失
标准要求：应在关键网络节点处对恶意代码进行检测和清除，并维护恶意代码防护机制的升级和更新。
适用范围：二级及以上系统
判例场景(同时)：
- 主机层无恶意代码检测和清除措施，或恶意代码库一月以上未更新；
- 网络层无恶意代码检测和清除措施，或恶意代码库一月以上未更新。
补偿因素：
- 对于使用Linux、Unix、Solaris、CentOS、AlX、Mac等非Windows操作系统的二级系统，主机和网络层均未部署恶意代码检测和清除产品，可从总体防御措施、恶意代码入侵的可能性等角度进行综合风险分析，根据分析结果酌情判定风险等级;
- 与互联网完全物理隔离或强逻辑隔离的系统，其网络环境可控，并采取USB介质管控、部署主机防护软件软件白名单等技术措施，能有效防范恶意代码进入被测主机/网络，可根据实际措施效果，酌情判定风险等级；
- 主机设备采用可信基的防控技术，对设备运行环境进行有效度量，可根据实际措施效果，酌情判定风险等级。
底线解读：非windows系统并非绝对安全，对于恶意代码要采取必要的防范措施。
安全计算环境（11项）
一、身份鉴别（设备、应用）：存在弱口令或相同口令
适用范围：二级及以上系统
判例场景（任意）：
- 网络设备、安全设备、主机设备 (包括操作系统、数据库等）存在可登录的弱口令账户（包括空口令、无身份鉴别机制）;
- 大量设备管理员账户口令相同，单台设备口令被破解将导致大量设备被控制。
补偿因素：
- 对于业务场景需要，使用无法设置口令或口令强度达不到要求的专用设备（应用系统），可从设备登录方式物理访问控制、访问权限、其他防护措施、管理制度等角度进行综合风险分析，根据分析结果，酌情判定风险等级；
- 对于互联网前端系统的注册用户存在弱口令，可从对单个用户、整个应用系统所可能造成的影响等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：弱口令问题是安全大忌，杜绝低级错误。
二、身份鉴别（应用）：应用系统口令策略缺失
适用范围：二级及以上系统
判例场景：应用系统无用户口令长度、复杂度校验机制，例如可设置6位以下，单个、相同、连续数字/字母/字符等易猜测的口令。
补偿因素：
- 应用系统采用多种身份鉴别、访问地址限制等技术措施，获得的口令无法直接登录应用系统，可根据实际措施效果，酌情判定风险等级；
- 对于仅内网访问的内部管理系统，可从内网管控、人员管控、实际用户口令质量等角度进行综合风险分析，根据分析结果，酌情判定风险等级；
- 对于部分专用软件、老旧系统等无法添加口令复杂度校验功能，可从登录管控措施、实际用户口令质量口令更换频率等角度进行综合风险分析，根据分析结果，酌情判定风险等级;
- 对于特定应用场景中的口令，例如PIN码、电话银行系统查询口令等，可从行业要求。行业特点等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：最大限度上提升口令质量，防止口令被轻易破解。
三、身份鉴别（应用）：应用系统口令暴力破解防范机制缺失
标准要求：应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相措施。
适用范围：二级及以上系统。
判例场景：通过互联网登录的应用系统登录模块未提供有效的口令暴力破解防范机制。
补偿因素：
- 应用系统采用多种身份鉴别、访问限制等技术措施，获得口令珊去直接登录应用系统，可根据实际措施效果酌情判险等级；
- 对于互联网前端系统的注册用户，可从登录后用户获得的业务功能、账户被盗后的影响程度等角度进行综合风险分析，根据分析结果，酌情判定风险等级；涉及到资金交易、个人隐私、信息发布、重要业务操作等的前端系统，不宜降低风险等级；
- 对于无法添加登录失败处理功能的应用系统，可从登录、登录终端限制等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：身份鉴别基础安全防护功能，对口令暴力破解攻击要有防范机制。
四、身份鉴别（设备）：设备未采用多种身份鉴别技术
标准要求：应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。
适用范围：三级及以上系统。
判例场景（所有）：
- 关键网络设备、关键安全设备、关键主机设备（操作系统）通过不可控网络环境进行远程管理；
- 设备未采用两种或两种以鉴别技术对用户身份进行鉴别。
补偿因素：
- 远程管理过程中，多次采用同一种鉴别技术进行身份鉴别，且每次鉴别信息不相同，例如两次口令认证措施（两次口令不同），可根据实际措施效果，酌情判定风险等级；
- 对于采取登录止限制、绑定管理终端等其他技术手段降低用户身份被滥用的威胁，可从措施所起到的防护效果等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：三级系统，提高身份鉴别强度，强度大于”1“。
五、身份鉴别（应用）：应用系统未采用多种身份鉴别技术
判例场景：通过互联网登录的系统，在进行涉及大额资金交易、核心业务、关键指令等重要操作前未使用两种或两种以上鉴别技术对用户身份进行鉴别。
补偿因素：
- 在身份鉴别过程中，多次采用同一种鉴别技术进行身份鉴别,且每次鉴别信息不相同，例如两次口令认证措施（两次口令不同），可根据实际措施效果酌情判险等级；
- 在完成重要操作前的不同阶段使用不同的鉴别方式进行身份鉴别，可根据实际措施效果，酌情判定风险等级；
- 对于用户群体为互联网个人用剜可从行业主管部门的要求、用户身份被滥用后对系统或个人造成影响等角度进行综合风险分析，根据分析结果，酌情判定风险等级；
- 对于采取登录地址限制、绑定设备等其他技术手段降低用户身份被滥用的威胁，可从措施所起到的防护效果等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：三级系统，提高身份鉴别强度强度大于”1“。
六、安全审计（设备、应用）：设备/应用系统安全审计措施缺失
标准要求：应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计。
适用范围：二级及以上系统。
判例场景（所有）：
- 关键网络设备、关键安全设备、关键主机设备（包括操作系统、数据库等）、应用系开启任何可审计功能，无法对重要的用户行为和重要安全事件进行审计；
- 未采用堡垒机、第三方审计工具等技术手段或所采用的辅助审计措施存在漏记/旁路等缺陷，无法对重要的用户行为和重要安全事件进行溯源。
补偿因素：
对于日志记录不全或有审计数据但无直观展示等情况，可从审计记录内容、事件追溯范围等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：基本安全功能，对于重要事件能够追溯。
七、访问控制（应用）：应用系统访问控制机制存在缺陷
标准要求：应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则。
适用范围：二级及以上系统。
判例场景：应用系统访问控制策略缺陷，可越权访问系能模块或查看、操作其他用户的数据，例如存在非授权访问系统功能模块了权限漏洞，低权限用户越权访问高权限功能模块等。
补偿因素：
- 对于部署在可控网络环境的应用系统，可从现有的防护措施、用户行为监控等角度进行综合风险分析，根据分析结果，酌情判断风险等级；
- 可从非授权访问模块的重要程度、影响程度、越权访问的难度等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：应用系统不能存在访问控制类缺陷，避免重要操作越权敏感信息泄露。
八、入侵防范（设备）：互联网设备存在已知高危漏洞
标准要求：应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞。
适用范围：二级及以上系统。
判例场景（所有）：
- 网络设备、安全设备、主机设备（包括操作系统、库等）可通过互联网管理或访问（包括服务、管理模块等）；
- 该设备型号、版本存在外界披露的高危安全漏洞；
- 未及时采取修补或其他有效防范措施。
补偿因素：通过访问地址限制或其他有效防护措施，无法通过互联网利用该高危漏洞，可根据实际措施效果，酌情判定风险等级。
底线解读：互联网设备不留高风险漏洞，把安全隐患降到最低。
九、入侵防范（应用）：应用系统数据有效性检验功能缺失
标准要求：应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求。
判例场景（所有）：
- 应用系统存在SQL注入、跨站脚本、上传漏洞等可能导致敏感数据泄露、网篡改、服务器被入侵等安全事件的发造成严重后果的高危漏洞；
- 未采取WEB应用防火墙、云盾等技术防护手段对高危漏洞进行防范。
补偿因素：对于不与互联网交互的内网系统，可从应用系统的重要程度、漏洞影响程度、漏洞利用难度、内部网络管昔施等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：应用系统不能存在可能导致敏感数据泄露、网页篡改、服务器被入侵等的高风险漏洞。
十、数据备份恢复（数据安全）：数据备份措施缺失
标准要求：应提供重要数据的本地数据备份与恢复功能。
适用范围：二级及以上系统。
判例场景（任意）：
- 应用系统未提供任何重要数据备份措施，一旦遭受数据破坏，无法进行恢复；
- 重要数据、源代码等备份到互联网网盘、代码托管平台等不可控环境，可能造成重要信息泄露。
补偿因素：对于采用多数据中心或冗余方式部署，重要数据存在多个副本的情况，可从技术实现效果、恢复效果等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
十一、个人信息保护（数据安全）：违规采集和存储个人信息
标准要求：应仅采集和保存业务必需的用户个人信息。
适用范围：二级及以上系统。
判例场景（任意）：
- 在未授权情况下，采集、存储用户个人隐私信息；
- 采集、保存法律法规、主管部门严令禁集、保存的用户隐私信息。
补偿措施：无。
底线解读：高度重视个人信息保护。
底线解读：重要数据一定要做备份，但是备份文件不能乱存，避免信息泄露。
安全管理中心（2项）
一、集中管控：运行监控措施缺失
标准要求：应对网络链路、安全设备、网络设备和服务器等的运行状况进行集中监测。
适用范围：高可用性的三级及以上系统。
判例场景：对网络链路、安全设备、网络设备和服务器等的运行状况无任何监控措施，发生故障无法及时对故障进行定位和处理。
补偿因素：无。
底线解读：对于关键设备要有监控，出现问题，及时掌握，及时处置。
二、集中管控：审计记录存储时间不满足要求
标准要求：应对分散在各个设备上的审计数据进行收集汇总和集中分析，并保证审计记录的留存时间符合法律法规要求。
适用范围：三级及以上系统。
满足条件：关键网络设备、关键安全设备、关键主机设备（包括操作系统、数据库等）的重要操作、安全事件等审计记录的留存不满足法律法规规定的相关要求（不少于六个月）。
补偿因素：对于被测对象上线运行时间不足六个月，可从当前日志保存情况、日志备份策略、日志存储容量等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：要有符合《网络安全法》日志保存时间要求的能力。
管理部分（6项）
一、岗位设置：未建立网络安全领导小组
标准要求：应成立指导和管理网络安全工作的委员会或领导小组，其最高领导由单位主管领导担任或授权。
适用范围：三级及以上系统。
判例场景：未成立指导和管理信息安全工作的委员会或领导小组，或其最高领导未由单位主管领导担任或授权。
补偿因素：无。
底线解读：需要体现对网络安全的重视程度。
二、外部人员访问管理：外部人员接入网络管理措施缺失
标准要求：应在外部人员接入受控网络访问系统前先提出书面申请，批准后由专人开设账户、分配权限，并登记备案。
适用范围：二级及以上系统。
判例场景：
- 管理制度中未明确外部人员接入受控网络访问系统的申请、审批流程，以及相关安全控制要求；
- 无法提供外部人员接入申请、审批等相关记录证据。
补偿因素：无。
底线解读：外部人员不可靠，要有防范措施。
三、产品采购和使用：违规采购和使用网络安全产品
标准要求：应确保网络安全产品采购和使用符合国家的有关规定。
适用范围：三级及以上系统。
满足条件：网络安全产品的采购和使用违反国家有关规定（如采购、使用安全产品未获得销售许可证、未通过国家有关机构的安全检测等情况）。
补偿因素：对于使用开源、自研的网络安全产品（非销售类安全产品），可从该网络安全产品的作用、功能、使用场景、国家及行业主管部门的要求等角度进行综合风险分析，充分考虑该网络安全产品未通过专业机构检测，一旦出能缺陷、安全漏洞等问题对定级对象带来的影响，根据分析结果，酌情判定风险等级。
注：《计算机信息系统安全专用产品检测和销售许可证管理办法》规定安全专用产品应获得公安部颁发的销售许可证。
底线解读：起关键作用的安全设备要进行检测，最大程席保障设备安全可靠。
四、外包软件开发：外包开发代码审计措施缺失
标准要求：应保证开发单是供软件源代码，并审查软件中可能的后门和隐蔽信道。
适用范围：三级及以上系统。
判例场景（所有）：
- 涉及国计民生的核心业务系统，被测单位未对开发单位开发的系统进行源代码安全审查；
- 开发单位未提供任何第三方机构提供的安全性检测证明。
补偿因素：
- 定级对象建成时间较长，虽未进行源代码安全审查，但定期进行安全检测，并能够提供安全检测报告且当前管理制度中明确规定外包开发代码审计，可根据实际措施效果酌情判定风险等级；
- 对于被测单位通过合同等方式与开发单位明确安全责任并采取相关技术手段进行防控，可从已采取的技术防范措施进行综合分析，根据分析结果，酌情判定风险等级；
- 对于部分模块外包开发的情况，可从外包开发模块的用途、重要性等角度进行综合风险分析，根据分析结果，酌情判定风险等级。
底线解读：重视外包开发质量，不要过分"信任"开发单位。
五、测试验收：上线前未开展安全测试
标准要求：应进行上线前的安全性测试，并出具安全测试报告，安全测试报告应包含密码应用安全性测试相关内容。
适用范围：三级及以上系统。
判例场景：系统上线前未开展任何安全性测试，对测试发高风险问题进行安全评估和整改。
补偿因素：定级对象建成时间较长，上线前虽未进行安全性测试，但上线后定期开展安全检测，且检测未发现高危风险隐患，可根据实际措施效果酌情判定风险等级。
注：安全测试内容包括但不限于等级保护测评、扫描渗透测试、安全功能验证、源代码安全审核等。
底线解读：上线前要做安全测试，不能“带病"上线。
六、应急预案管理：重要事件应急预案缺失
标准要求：应制定重要事件的应急预案，包括应急处理流程、系统恢复流程等内容。
适用范围：二级及以上系统。
判例场景（任意）：
- 未制定重要事件的应急预案；
- 应急预案内容不完整，未明确重要事件的应急处理流程、恢复流程等内容，一旦出现应急事件，无法合理有序的进行应急事件处置。
补偿因素：无。
底线解读：要制定应急预案。
总结
- 《指引》不可能枚举所有场景，也不可能覆盖所有行业系统，不可能解决所有问题；参考时还是需要现场测评人员结合行业主管部门要求、系统特点、现有措施等综合进行风险分析；
- 报告中的描述应尽可能准确、详细，尤其是"整体测评结果分折"部分，要结合被测系统特点及系统实际情况；
- 等保安全要求是有底线的，不是任意系统都能给"通过"的结果，一些氐安全措施都没有，基础安全功能都未实现的系统，结论就应该为"差"，要求用户整改。