等级保护2.0标准中，以三级要求为例，技术部分要求共计84项，管理部分要求共计127项（占比达60%）。“三分技术,七分管理”一直是网络安全领域的至理名言，足见管理在整个网络安全中的重要性。然而，在等级测评过程中，测评机构很少将管理制度存在缺失或管理不到位的情况判定为“高风险”。实际上，许多安全事件往往就发生在这些管理的缺失或者不到位上。根据以往发生严重安全事件的分析，笔者对等级保护2.0标准中，如落实不到位可能引发严重安全事故或存在重大安全隐患的管理要求，提出可判高风险的场景。例如，管理制度严重缺失、未建立网络安全领导小组、外包开发代码审计措施缺失、上线前未通过安全测试、未将重要运维操作纳入变更管理制度、未对运维工具进行管控、未制定应急预案及培训演练等情况。
对于未建立网络安全领导小组或其最高领导由单位主管领导担任或授权的情况：大量实践证明，网络信息安全的落实，需要从上至下的推动。因此，网络安全领导小组的最高领导是否由单位主要领导担任或授权,将直接反映出该单位或企业对于信息安全保障工作的重视程度，有助于推进各项保障措施的落实。
对于外包开发代码审计措施缺失的情况：长期以来，外包开发一直存在着诸多不稳定的因素。例如，外包开发公司的开发人员流动大、水平参差不齐、安全技能和意识弱。外包团队往往只注重对功能需求的完成，而不太顾及代码质量与安全问题，极有可能导致相关程序存在重大安全隐患。因此，对外包开发进行代码审计是保障程序安全、降低外包开发风险的重要手段。尤其是针对涉及金融、民生、基础设施等重要核心领域的三级及以上系统。
对于上线前未通过安全测试的情况：上线前安全测试作为应用系统正式运行前重要环节，在整个网络安全保障活动中扮演者重要角色。通过上线前的安全测试，可以检测相关应用系统是否存在安全隐患，是否具备足够安全保障措施，是否具备上线运行条件，最大限度的预防和减低重大网络安全事件的发生。因此，在《高风险判定指引》中，明确系统上线前未通过安全性测试，或未对相关高风险问题进行安全评估仍旧“带病”上线的，可判定为高风险。
对于未将重要运维操作纳入变更管理制度的情况：2015年携程瘫痪事件，按照携程一季度财报公布的数据，携程宕机的损失为平均每小时106.48万美元。就其原因，就是运维操作失误导致的。因此，变更管理制度中应明确重要运维操作的相关流程。
对于未制定应急预案及培训演练的情况：《网络安全法》第二十五条已明确规定：网络运营者应当制定网络安全事件应急预案，及时处置系统漏洞、计算机病毒、网络攻击、网络侵入等安全风险；在发生危害网络安全的事件时，立即启动应急预案，采取相应的补救措施，并按照规定向有关主管部门报告；而仅仅制定一份应急预案是远远不够的，还需要定期进行培训和演练，不然应急预案是否能执行，是否能应急，都将打上一个问号。因此，《高风险判定指引》中，明确指出未制定重要事件的应急预案，未明确重要事件的应急处理流程、系统恢复流程等内容，以及未定期对相关人员进行应急预案培训，未根据不同的应急预案进行应急演练，无法提供应急预案培训和演练记录等情况，可判定为高风险。
结束语
随着科技技术的发展以及新形势下安全威胁的变化，《高风险判定指引》并不可能覆盖所有情况，部分判例在执行过程中仍存在讨论的空间，但对于等级保护测评工作来说，却是一次有益的尝试。《高风险判定指引》如同提供给测评机构一把尺子。这把尺子，需要根据实际情况进行使用，不能生搬硬套；这把尺子，不仅让实际风险能被真实揭露，也为了让网络运营者能重视测评结果、认可测评结果，真正地提高排除高风险隐患，切实提高安全防范水平。
最后我们看到，提升测评认可度，不仅要统一风险判定的尺子，还需要确保尺子测量“标的物”的真实、准确，也就是提高每一条测评记录准确度、不放过每一个安全问题。只有这样，才能发挥风险判定的真正作用。后期，上海测评中心将通过研究利用人工智能“语义倾向分析”提升测评中的记录质量；通过研究不同安全要求之间的内在关联，捕捉每一个可能遗漏的安全问题，为最后的风险判定打好基础。
《网络安全等级保护测评高风险判定指引》——管理制度篇
安全管理制度
01
管理制度
1.1 管理制度建设
对应要求：应对安全管理活动中的各类管理内容建立安全管理制度。
判例内容：未建立任何与安全管理活动相关的管理制度或相关管理制度无法适用于当前被测系统的，可判定为高风险。
适用范围：所有系统。
满足条件（任意条件）：
1、未建立任何与安全管理活动相关的管理制度。
2、相关管理制度无法适用于当前被测系统。
补偿措施：无。
整改建议：建议按照等级保护的相关要求，建立包括总体方针、安全策略在内的各类与安全管理活动相关的管理制度。
安全管理机构
01
岗位设置
1.1 网络安全领导小组建立
对应要求：应成立指导和管理网络安全工作的委员会或领导小组，其最高领导由单位主管领导担任或授权。
判例内容：未成立指导和管理信息安全工作的委员会或领导小组，或其最高领导不是由单位主管领导委任或授权，可判定为高风险。
适用范围：3级及以上系统。满足条件（同时）：1、3级及以上系统；2、未成立指导和管理信息安全工作的委员会或领导小组，或领导小组最高领导不是由单位主管领导委任或授权。补偿措施：无。
整改建议：建议成立指导和管理网络安全工作的委员会或领导小组，其最高领导由单位主管领导担任或授权。
安全建设管理
01
产品采购和使用
1.1 网络安全产品采购和使用
对应要求：应确保网络安全产品采购和使用符合国家的有关规定。
判例内容：网络关键设备和网络安全专用产品的使用违反国家有关规定，可判定为高风险。
适用范围：所有系统。
满足条件：网络关键设备和网络安全专用产品的使用违反国家有关规定。
补偿措施：无。
整改建议：建议依据国家有关规定，采购和使用网络关键设备和网络安全专用产品。（《网络安全法》第二十三条规定网络关键设备和网络安全专用产品应当按照相关国家标准的强制性要求，由具备资格的机构安全认证合格或者安全检测符合要求后，方可销售或者提供。国家网信部门会同国务院有关部门制定、公布网络关键设备和网络安全专用产品目录，并推动安全认证和安全检测结果互认，避免重复认证、检测。）
1.2 密码产品与服务采购和使用
对应要求：应确保密码产品与服务的采购和使用符合国家密码管理主管部门的要求。判例内容：密码产品与服务的使用违反国家密码管理主管部门的要求，可判定为高风险。适用范围：所有系统。满足条件：密码产品与服务的使用违反国家密码管理主管部门的要求。补偿措施：无。
整改建议：建议依据国家密码管理主管部门的要求，使用密码产品与服务。
02
外包软件开发
2.1 外包开发代码审计
对应要求：应保证开发单位提供软件源代码，并审查软件中可能存在的后门和隐蔽信道。
判例内容：对于涉及金融、民生、基础设施等重要行业的业务核心系统由外包公司开发，上线前未对外包公司开发的系统进行源代码审查，外包商也无法提供相关安全检测证明，可判定为高风险。适用范围：涉及金融、民生、基础设施等重要核心领域的3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、涉及金融、民生、基础设施等重要行业的业务核心系统；
3、被测单位为对外包公司开发的系统进行源代码安全审查；
4、外包公司也无法提供第三方安全检测证明。
补偿措施：
1、开发公司可提供国家认可的第三方机构出具的源代码安全审查报告/证明，可视为等效措施，判符合。
2、可根据系统的用途以及外包开发公司的开发功能的重要性，根据实际情况，酌情提高/减低风险等级。
3、如第三方可提供软件安全性测试证明（非源码审核），可视实际情况，酌情减低风险等级。
4、如被测方通过合同等方式与外包开发公司明确安全责任或采取相关技术手段进行防控的，可视实际情况，酌情降低风险等级。
5、如被测系统建成时间较长，但定期对系统进行安全检测，当前管理制度中明确规定外包开发代码审计的，可根据实际情况，酌情减低风险等级。
整改建议：建议对外包公司开发的核心系统进行源代码审查，检查是否存在后门和隐蔽信道。如没有技术手段进行源码审查的，可聘请第三方专业机构对相关代码进行安全检测。
03
测试验收
3.1 上线前安全测试
对应要求：应进行上线前的安全性测试，并出具安全测试报告，安全测试报告应包含密码应用安全性测试相关内容。
判例内容：系统上线前未通过安全性测试，或未对相关高风险问题进行安全评估仍旧“带病”上线的，可判定为高风险。安全检查内容可以包括但不限于扫描渗透测试、安全功能验证、源代码安全审核。适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、系统上线前未进行任何安全性测试，或未对相关高风险问题进行安全评估仍旧“带病”上线。
补偿措施：
1、如被测系统建成时间较长，定期对系统进行安全检测，管理制度中相关的上线前安全测试要求，可根据实际情况，酌情减低风险等级。
2、如系统安全性方面是按照技术协议中的约定在开发过程中进行控制，并能提供相关控制的证明，可根据实际情况，酌情减低风险等级。
3、可视系统的重要程度，被测单位的技术实力，根据自检和第三方检测的情况，酌情提高/减低风险等级。
整改建议：建议在新系统上线前，对系统进行安全性评估，及时修补评估过程中发现的问题，确保系统不“带病”上线。
安全运维管理
01
漏洞和风险管理
1.1 安全漏洞和隐患的识别与修补
对应要求：应采取必要的措施识别安全漏洞和隐患，对发现的安全漏洞和隐患及时进行修补或评估可能的影响后进行修补。
判例内容：未对发现的安全漏洞和隐患及时修补，会导致系统存在较大的安全隐患，黑客有可能利用安全漏洞对系统实施恶意攻击，如果安全漏洞和隐患能够构成高危风险，可判定为高风险。适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、通过漏洞扫描，发现存在可被利用的高风险漏洞；
3、未对相关漏洞进行评估或修补，对系统安全构成重大隐患。补偿措施：如果安全漏洞修补可能会对系统的正常运行造成冲突，应对发现的安全漏洞和隐患进行评估，分析被利用的可能性，判断安全风险的等级，在可接受的范围内进行残余风险评估，明确风险等级，若无高危风险，可酌情降低风险。
整改建议：建议对发现的安全漏洞和隐患进行及时修补评估，对必须修补的安全漏洞和隐患进行加固测试，测试无误后，备份系统数据，再从生产环境进行修补，对于剩余安全漏洞和隐患进行残余风险分析，明确安全风险整改原则。
02
网络和系统安全管理
2.1 重要运维操作变更管理
对应要求：应严格控制变更性运维，经过审批后才可改变连接、安装系统组件或调整配置参数，操作过程中应保留不可更改的审计日志，操作结束后应同步更新配置信息库。判例内容：未对运维过程中改变连接、安装系统组件或调整配置参数进行变更审批，且未进行变更性测试，一旦安装系统组件或调整配置参数对系统造成影响，有可能导致系统无法正常访问，出现异常，可判定为高风险。适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、未建立变更管理制度，对于重大变更性运维过程无审批流程；
3、变更过程未保留相关操作日志及备份措施，出现问题无法进行恢复还原。补偿措施：无。
整改建议：建议对需要作出变更性运维的动作进行审批，并对变更内容进行测试，在测试无误后，备份系统数据和参数配置，再从生产环境进行变更，并明确变更流程以及回退方案，变更完成后进行配置信息库更新。
2.2 运维工具的管控对应要求：应严格控制运维工具的使用，经过审批后才可接入进行操作，操作过程中应保留不可更改的审计日志，操作结束后应删除工具中的敏感数据。判例内容：未对各类运维工具（特别是未商业化的运维工具）进行有效性检查，未对运维工具的接入进行严格的控制和审批，运维工具中可能存在漏洞或后门，一旦被黑客利用有可能造成数据泄露，可判定为高风险。适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、未对各类运维工具（特别是未商业化的运维工具）进行有效性检查，如病毒、漏洞扫描等；对运维工具的接入也未进行严格的控制和审批；操作结束后也未要求删除可能临时存放的敏感数据。
补偿措施：
1、如使用官方正版商用化工具，或自行开发的，安全可供的运维工具，可根据实际情况，酌情降低风险等级。
2、如对于运维工具的接入有严格的控制措施，且有审计系统对相关运维操作进行审计，可根据实际情况，酌情降低风险等级。
整改建议：如果必须使用运维工具，建议使用商业化的运维工具，严禁运维人员私自下载第三方未商业化的运维工具。
2.3 运维外联的管控对应要求：应保证所有与外部的连接均得到授权和批准，应定期检查违反规定无线上网及其他违反网络安全策略的行为。判例内容：制度上服务器及终端与外部连接的授权和批准制度，也未定期对相关违反网络安全策略的行为进行检查，存在违规外联的安全隐患，一旦内网服务器或终端违规外联，可能造成涉密信息（商密信息）的泄露，同时增加了感染病毒的可能性，可判定为高风险。适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、管理制度上无关于外部连接的授权和审批流程，也未定期进行相关的巡检；
3、无技术手段检查违规上网及其他网络安全策略的行为。补偿措施：在网络部署了相关的准入控制设备，可有效控制、检查、阻断违规无线上网及其他违反网络安全策略行为的情况下，如未建立相关制度，未定期进行巡检，可酌情降低风险等级。
整改建议：建议制度上明确所有与外部连接的授权和批准制度，并定期对相关违反行为进行检查，可采取终端管理系统实现违规外联和违规接入，设置合理的安全策略，在出现违规外联和违规接入时能第一时间进行检测和阻断。
03
恶意代码防范管理
3.1 外来接入设备恶意代码检查
对应要求：应提高所有用户的防恶意代码意识，对外来计算机或存储设备接入系统前进行恶意代码检查等。判例内容：外来计算机或存储设备本身可能已被感染病毒或木马，未对其接入系统前进行恶意代码检查，可能导致系统感染病毒或木马，对信息系统造成极大的危害，可判定为高风险。适用范围：所有系统。
满足条件（同时）：
1、未在管理制度或安全培训手册中明确外来计算机或存储设备接入安全操作流程；
2、外来计算机或存储设备接入系统前未进行恶意代码检查。补偿措施：无。
整改建议：建议制定外来接入设备检查制度，对任何外来计算机或存储设备接入系统前必须经过恶意代码检查，再检查无误后，经过审批，设备方可接入系统。
04
变更管理
4.1 需求变更管理
对应要求：应明确变更需求，变更前根据变更需求制定变更方案，变更方案经过评审、审批后方可实施。判例内容：未明确变更管理流程，未对需要变更的内容进行分析与论证，未制定详细的变更方案，无法明确变更的需求与必要性；变更的同时也伴随着可能导致系统无法正常访问的风险，可判定为高风险。适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、无变更管理制度，或变更管理制度中无变更管理流程、变更内容分析与论证、变更方案审批流程等相关内容。补偿措施：无。
整改建议：建议系统的任何变更均需要管理流程，必须组织相关人员（业务部门人员与系统运维人员等）进行分析与论证，在确定必须变更后，制定详细的变更方案，在经过审批后，先对系统进行备份，然后在实施变更。
05
备份与恢复管理
5.1 数据备份策略
对应要求：应根据数据的重要性和数据对系统运行的影响，制定数据的备份策略和恢复策略、备份程序和恢复程序等。判例内容：未明确数据备份策略和数据恢复策略，以及备份程序和恢复程序，无法实现重要数据的定期备份与恢复性测试，一旦系统出现故障，需要恢复数据，存在无数据可恢复的情况，或者备份的数据未经过恢复性测试，无法确保备份的数据可用，可判定为高危风险。此外，如有相关制度，但未实施，视为制度内容未落实，可判定为高风险。适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、无备份与恢复等相关的安全管理制度，或未按照相关策略落实数据备份。
补偿措施：
1、未建立相关数据备份制度，但若已实施数据备份措施，且备份机制符合业务需要，可酌情降低风险等级。
2、如系统还未正式上线，则可检查是否制定了相关的管理制度，目前的技术措施（如环境、存储等）是否可以满足制度中规定的备份恢复策略要求，可根据实际情况判断风险等级。
整改建议：建议制定备份与恢复相关的制度，明确数据备份策略和数据恢复策略，以及备份程序和恢复程序，实现重要数据的定期备份与恢复性测试，保证备份数据的高可用性与可恢复性。
06
应急预案管理
6.1 应急预案制定
对应要求：应制定重要事件的应急预案，包括应急处理流程、系统恢复流程等内容。判例内容：未制定重要事件的应急预案，未明确重要事件的应急处理流程、系统恢复流程等内容，一旦出现应急事件，无法合理有序的进行应急事件处置过程，造成应急响应时间增长，导致系统不能在最短的事件内进行恢复，可判定为高风险。适用范围：所有系统。满足条件：未制定重要事件的应急预案。补偿措施：如制定了应急预演，但内容不全，可根据实际情况，酌情降低风险等级。
整改建议：建议制定重要事件的应急预案，明确重要事件的应急处理流程、系统恢复流程等内容，并对应急预案进行演练。
6.2 应急预案培训演练
对应要求：应定期对系统相关的人员进行应急预案培训，并进行应急预案的演练。判例内容：未定期对相关人员进行应急预案培训，未根据不同的应急预案进行应急演练，无法提供应急预案培训和演练记录，可判定为高风险。适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、未定期对系统相关的人员进行应急预案培训；
3、未进行过应急预案的演练。补偿措施：如系统还未正式上线，可根据培训演练制度及相关培训计划，根据实际情况判断风险等级。
整改建议：建议定期对相关人员进行应急预案培训与演练，并保留应急预案培训和演练记录，使参与应急的人员熟练掌握应急的整个过程。
附表:
