【SDL实践指南】安全风险评估规范

信息安全风险管理是信息安全保障工作中的一项重要基础性工作，其核心思想是对管理对象面临的信息安全风险进行管控。信息安全风险管理工作贯穿于信息系统生命周期(规划、设计、实施、运行维护和废弃)的全过程主要工作过程包括风险评估和风险处理两个基本步骤。风险评估是对风险管理对象所面临的风险进行识别、分析和评价的过程，风险处理是依据风险评估的结果，选择和实施安全措施的过程

• 资产(Asset)：对组织具有价值的信息或资源，是安全策略保护的对象

• 业务战略(Business Strategy)组织为实现其发展目标而制定的一组规则或要求

• 可用性(Availability)：数据或资源的特性，被授权实体按要求能访问和使用数据或资源

• 完整性(Integrity)：保证信息及信息系统不会被非授权更改或破坏的特性。包括数据完整性和系统完整性

• 机密性(Confidentiality)：数据所具有的特性，即表示数据所达到的未提供或未泄露给非授权的个人、过程或其他实体的程度

• 资产价值(Asset value)：资产的重要程度或敏感程度的表征，资产价值是资产的属性，也是进行资产识别的主要内容

• 信息安全风险(Information security risk)：人为或自然的威胁利用信息系统及其管理体系中存在的脆弱性导致安全事件的发生及其对组织造成的影响

• 信息安全风险评估(Information Security Risk Assessment)：依据有关信息安全技术与管理标准对信息系统及由其处理、传输和存储的信息的保密性、完整性和可用性等安全属性进行评价的过程，它要评估资产面临的威胁以及威胁利用脆弱性导致安全事件的可能性并结合安全事件所涉及的资产价值来判断安全事件一旦发生对组织造成的影响

• 安全事件(Security Incident)指系统、服务或网络的一种可识别状态的发生，它可能是对信息安全策略的违反或防护措施的失效或未预知的不安全状况

• 安全措施(Security measure)保护资产、抵御威胁、减少脆弱性、降低安全事件的影响以及打击信息犯罪而实施的各种实践、 规程和机制

• 安全需求(Security Requirement)为保证组织业务战略的正常运作而在安全措施方面提出的要求

风险评估中各要素的关系如下图所示：

方框部分的内容为风险评估的基本要素，椭圆部分的内容是与这些要素相关的属性，风险评估围绕着资产、威胁、脆弱性和安全措施这些基本要素展开，在对基本要素的评估过程中，需要充分考虑业务战略、资产价值、安全需求、安全事件、残余风险等与这些基本要素相关的各类属性，上图中的风险要素及属性之间存在着以下关系：

• 业务战略的实现对资产具有依赖性，依赖程度越高，要求其风险越小

• 资产是有价值的，组织的业务战略对资产的依赖程度越高，资产价值就越大

• 风险是由威胁引发的，资产面临的威胁越多则风险越大并可能演变成为安全事件

• 资产的脆弱性可能暴露资产的价值，所以资产具有的脆弱点越多那么风险越大

• 脆弱性是未被满足的安全需求，威胁利用脆弱性危害资产

• 风险的存在及对风险的认识导出安全需求

• 安全需求可通过安全措施得以满足，需要结合资产价值考虑实施成本

• 安全措施可抵御威胁，降低风险

• 残余风险有些是安全措施不当或无效，需要加强才可控制的风险，而有些则是在综合考虑了安全成本与效益后不去控制的风险

• 残余风险应当受到密切监视，它可能会在将来诱发新的安全事件

风险分析原理如下图所示：

风险分析中要涉及资产、威胁、脆弱性三个基本要素，每个要素有各自的属性，资产的属性是资产价值，威胁的属性可以是威胁主体、影响对象、出现频率、动机等，脆弱性的属性是资产弱点的严重程度，风险分析的主要内容为：

• 对资产进行识别并对资产的价值进行赋值

• 对威胁进行识别，描述威胁的属性并对威胁出现的频率赋值

• 对脆弱性进行识别，同时对具体资产的脆弱性的严重程度赋值

• 根据威胁及威胁利用脆弱性的难易程度判断安全事件发生的可能性

• 根据脆弱性的严重程度及安全事件所作用的资产的价值计算安全事件的损失

• 根据安全事件发生的可能性以及安全事件出现后的损失，计算安全事件一旦发生对组织的影响，即风险值

风险评估的实施流程如下图所示：

前期准备

基本概述

风险评估的准备是整个风险评估过程有效性的保证，组织实施风险评估是一种战略性的考虑，其结果将受到组织业务战略、业务流程、安全需求、系统规模和结构等方面的影响，因此在风险评估实施前，应该

• 进行系统调研

• 确定风险评估的目标

• 确定风险评估的范围

• 确定评估依据和方法

• 组建适当的评估管理与实施团队

• 获得最高管理者对风险评估工作的支持

确定目标

根据满足组织业务持续发展在安全方面的需要、法律法规的规定等内容，识别现有信息系统及管理上的不足以及可能造成的风险大小

确定范围

风险评估范围可能是组织全部的信息及与信息处理相关的各类资产、管理机构，也可能是某个独立的信息系统、关键业务流程与客户知识产权相关系统或部门等

组建团队

风险评估实施团队，由管理层、相关业务骨干、信息技术等人员组成的风险评估小组，必要时可组建由评估方、被评估方领导和相关部门负责人参加的风险评估领导小组，聘请相关专业的技术专家和 技术骨干组成专家小组

风险评估实施团队应做好评估前的表格、文档、检测工具等各项准备工作，进行风险评估技术培训和保密教育，制定风险评估过程管理相关规定，可根据被评估方要求，双方签署保密合同，必要时签署个人保密协议

系统调研

系统调研是确定被评估对象的过程，风险评估小组应进行充分的系统调研为风险评估依据和方法 的选择、评估内容的实施奠定基础，调研内容至少应包括：

• 系统边界

• 数据和信息

• 主要的硬件、软件

• 系统和数据的敏感性

• 业务战略及管理制度

• 主要的业务功能和要求

• 支持和使用系统的人员

• 网络结构与网络环境，包括内部连接和外部连接

• 其他

系统调研可以采取问卷调查、现场面谈相结合的方式进行，调查问卷是提供一套关于管理或操作控制的问题表格，供系统技术或管理人员填写，现场面谈则是由评估人员到现场观察并收集系统在物理、环境和操作方面的信息

确定依据

根据系统调研结果，确定评估依据和评估方法，评估依据包括(但不限于)：

• 系统安全保护等级要求

• 系统互联单位的安全要求

• 系统本身的实时性或性能要求等

• 现行国际标准、国家标准、行业标准

• 行业主管机关的业务系统的要求和制度

根据评估依据应考虑评估的目的、范围、时间、效果、人员素质等因素来选择具体的风险计算方法并依据业务实施对系统安全运行的需求确定相关的判断依据，使之能够与组织环境和安全要求相适应

制定方案

风险评估方案的目的是为了后面的风险评估实施活动提供一个总体计划，用于指导实施方开展后续工作，风险评估方案的内容一般包括(但不仅限于)：

• 团队组织：包括评估团队成员、组织结构、角色、责任等内容

• 工作计划：风险评估各阶段的工作计划，包括工作内容、工作形式、工作成果等内容

• 时间进度安排：项目实施的时间进度安排

获得支持

上述所有内容确定后，应形成较为完整的风险评估实施方案，得到组织最高管理者的支持、批准；对管理层和技术人员进行传达，在组织范围就风险评估相关内容进行培训，以明确有关人员在风险评估中的任务

资产识别

资产分类

机密性、完整性、可用性是评价资产的三个安全属性。风险评估中资产的价值不是以资产的经济价值来衡量，而是由资产在这三个安全属性上的达成程度或者其安全属性未达成时所造成的影响程度来决定的。安全属性达成程度的不同将使资产具有不同的价值，而资产面临的威胁、存在的脆弱性、以及已采用的安全措施都将对资产安全属性的达成程度产生影响，为此有必要对组织中的资产进行识别

在一个组织中资产有多种表现形式，同样的两个资产也因属于不同的信息系统而重要性不同，而且对于提供多种业务的组织，其支持业务持续运行的系统数量可能更多，这时首先需要将信息系统及相关的资产进行恰当的分类，以此为基础进行下一步的风险评估。在实际工作中具体的资产分类方法可以根据具体的评估对象和要求，由评估者灵活把握，根据资产的表现形式可将资产分为数据、软件、 硬件、服务、人员等类型。下表列出了一种资产分类方法

资产赋值

保密性赋值

根据资产在保密性上的不同要求将其分为五个不同的等级，分别对应资产在保密性上应达成的不同程度或者保密性缺失时对整个组织的影响，下表提供了一种保密性赋值的参考：

完整性赋值

根据资产在完整性上的不同要求将其分为五个不同的等级，分别对应资产在完整性上缺失时对整 个组织的影响，下表提供了一种完整性赋值的参考：

可用性赋值

根据资产在可用性上的不同要求将其分为五个不同的等级，分别对应资产在可用性上应达成的不同程度，下表提供了一种可用性赋值的参考

资产重要性等级

资产价值应依据资产在机密性、完整性和可用性上的赋值等级，经过综合评定得出。综合评定方法 可以根据自身的特点选择对资产机密性、完整性和可用性最为重要的一个属性的赋值等级作为资产的 最终赋值结果，也可以根据资产机密性、完整性和可用性的不同等级对其赋值进行加权计算得到资产的最终赋值结果，加权方法可根据组织的业务特点确定

本标准中为与上述安全属性的赋值相对应，根据最终赋值将资产划分为五级，级别越高表示资产越重要，也可以根据组织的实际情况确定资产识别中的赋值依据和等级，下表中的资产等级划分表明了不同等级的重要性的综合描述，评估者可根据资产赋值结果确定重要资产的范围并主要围绕重要资产进行下一步风险评估

威胁识别

威胁分类

威胁可以通过威胁主体、资源、动机、途径等多种属性来描述。造成威胁的因素可分为人为因素和环境因素，根据威胁的动机人为因素又可以分为恶意和非恶意两种，环境因素包括自然界不可抗的因素和其它物理因素，威胁作用形式可以是对信息系统直接或间接的攻击，在机密性、完整性、可用性等方面造成损害也可能是偶发的或蓄意的事件

在对威胁进行分类前应考虑威胁的来源，下表提供了一种威胁来源的分类方法：

对威胁进行分类的方式有多种，针对上表的威胁来源可以根据其表现形式将威胁分为以下几类，下表提供了一种基于表现形式的威胁分类方法：

威胁赋值

判断威胁出现的频率是威胁赋值的重要内容，评估者应根据经验和(或)有关的统计数据来进行判断，在评估中需要综合考虑以下三个方面以形成在某种评估环境中各种威胁出现的频率

• 以往安全事件报告中出现过的威胁及其频率的统计

• 实际环境中通过检测工具以及各种日志发现的威胁及其频率的统计

• 近一两年来国际组织发布的对于整个社会或特定行业的威胁及其频率统计，以及发布的威胁预警

可以对威胁出现的频率进行等级化处理，不同等级分别代表威胁出现的频率的高低，等级数值越大，威胁出现的频率越高，下表提供了威胁出现频率的一种赋值方法，在实际的评估中威胁频率的判断依据应在评估准备阶段根据历史统计或行业判断予以确定并得到被评估方的认可

脆弱性识别

脆弱性识别

脆弱性是资产本身存在的，如果没有被相应的威胁利用，单纯的脆弱性本身不会对资产造成损害，而且如果系统足够强健则严重的威胁也不会导致安全事件发生并造成损失，即威胁总是要利用资产的脆弱性才可能造成危害

资产的脆弱性具有隐蔽性，有些脆弱性只有在一定条件和环境下才能显现，这是脆弱性识别中最为困难的部分，不正确的、起不到应有作用的或没有正确实施的安全措施本身就可能是一个脆弱性

脆弱性识别是风险评估中最重要的一个环节，脆弱性识别可以以资产为核心，针对每一项需要保护的资产识别可能被威胁利用的弱点并对脆弱性的严重程度进行评估，也可以从物理、网络、系统、 应用等层次进行识别，然后与资产、威胁对应起来，脆弱性识别的依据可以是国际或国家安全标准，也可以是行业规范、应用流程的安全要求，对应用在不同环境中的相同的弱点其脆弱性严重程度是不同的，评估者应从组织安全策略的角度考虑、判断资产的脆弱性及其严重程度，信息系统所采用的协议、 应用流程的完备与否、与其他网络的互联等也应考虑在内

脆弱性识别时的数据应来自于资产的所有者、使用者以及相关业务领域和软硬件方面的专业人员等，脆弱性识别所采用的方法主要有：问卷调查、工具检测、人工核查、文档查阅、渗透性测试等

脆弱性识别主要从技术和管理两个方面进行，技术脆弱性涉及物理层、网络层、系统层、应用层等各个层面的安全问题，管理脆弱性又可分为技术管理脆弱性和组织管理脆弱性两方面，前者与具体技术活动相关，后者与管理环境相关

对不同的识别对象其脆弱性识别的具体要求应参照相应的技术或管理标准实施，例如:对物理环境的脆弱性识别应按GB/T 9361中的技术指标实施，对操作系统、数据库应按GB 17859-1999中的技术指标实施，对管理脆弱性识别方面应按GB/T 19716-2005的要求对安全管理制度及其执行情况进行检查，发现管理漏洞和不足，下表提供了一种脆弱性识别内容的参考

脆弱性赋值

以根据对资产的损害程度、技术实现的难易程度、弱点的流行程度，采用等级方式对已识别的脆弱性的严重程度进行赋值，由于很多弱点反映的是同一方面的问题或可能造成相似的后果，赋值时应综合考虑这些弱点以确定这一方面脆弱性的严重程度

对某个资产其技术脆弱性的严重程度还受到组织管理脆弱性的影响，因此资产的脆弱性赋值还应参考技术管理和组织管理脆弱性的严重程度，脆弱性严重程度可以进行等级化处理，不同的等级分别代表资产脆弱性严重程度的高低，等级数值越大，脆弱性严重程度越高，下表提供了脆弱性严重程度的一种赋值方法

安全措施确认

在识别脆弱性的同时评估人员应对已采取的安全措施的有效性进行确认，安全措施的确认应评估其有效性，即是否真正地降低了系统的脆弱性，抵御了威胁，对有效的安全措施继续保持以避免不必 要的工作和费用，防止安全措施的重复实施，对确认为不适当的安全措施应核实是否应被取消或对其进行修正或用更合适的安全措施替代

安全措施可以分为预防性安全措施和保护性安全措施两种，预防性安全措施可以降低威胁利用脆弱性导致安全事件发生的可能性，如入侵检测系统，保护性安全措施可以减少因安全事件发生后对组织或系统造成的影响

已有安全措施确认与脆弱性识别存在一定的联系，一般来说安全措施的使用将减少系统技术或管理上的脆弱性，但安全措施确认并不需要和脆弱性识别过程那样具体到每个资产、组件的脆弱性，而是一类具体措施的集合，为风险处理计划的制定提供依据和参考

安全风险分析

风险计算原理

在完成了资产识别、威胁识别、脆弱性识别以及对已有安全措施确认后将采用适当的方法与工具确定威胁利用脆弱性导致安全事件发生的可能性，综合安全事件所作用的资产价值及脆弱性的严重程度判断安全事件造成的损失对组织的影响，即安全风险。本标准给出了风险计算原理，以下面的范式形式化加以说明

风险值=R（A，T，V）= R(L(T，V)，F(Ia，Va ))

其中R表示安全风险计算函数；A表示资产；T表示威胁；V表示脆弱性；Ia表示安全事件所作用的资产价值；Va表示脆弱性严重程度；L表示威胁利用资产的脆弱性导致安全事件发生的可能性；F表示安全事件发生后产生的损失，有以下三个关键计算环节

a）计算安全事件发生的可能性

根据威胁出现频率及弱点的状况计算威胁利用脆弱性导致安全事件发生的可能性，即安全事件发生的可能性=L(威胁出现频率，脆弱性)＝L(T，V )

在具体评估中应综合攻击者技术能力(专业技术程度、攻击设备等)、脆弱性被利用的难易程度(可访问时间、设计和操作知识公开程度等)、资产吸引力等因素来判断安全事件发生的可能性

b）计算安全事件发生后的损失

根据资产价值及脆弱性严重程度，计算安全事件一旦发生后的损失，即安全事件的损失=F(资产价值，脆弱性严重程度)＝F(Ia，Va )

部分安全事件的发生造成的损失不仅仅是针对该资产本身，还可能影响业务的连续性，不同安全事件的发生对组织造成的影响也是不一样的，在计算某个安全事件的损失时应将对组织的影响也考虑在内，部分安全事件损失的判断还应参照安全事件发生可能性的结果，对发生可能性极小的安全事件(例如：处于非地震带的地震威胁、在采取完备供电措施状况下的电力故障威胁等)可以不计算其损失

c）计算风险值

根据计算出的安全事件发生的可能性以及安全事件的损失，计算风险值，即：

风险值=R(安全事件发生的可能性，安全事件造成的损失)＝R(L(T，V)，F(Ia，Va )

评估者可根据自身情况选择相应的风险计算方法计算风险值，如矩阵法或相乘法，矩阵法通过构造一个二维矩阵形成安全事件发生的可能性与安全事件的损失之间的二维关系，相乘法通过构造经验函数将安全事件发生的可能性与安全事件的损失进行运算得到风险值

风险结果判定

为实现对风险的控制与管理可以对风险评估的结果进行等级化处理，可以将风险划分为五级，等级越高，风险越高，评估者应根据所采用的风险计算方法来计算每种资产面临的风险值，根据风险值的分布状况为每个等级设定风险值范围并对所有风险计算结果进行等级处理，每个等级代表了相应风险的严重程度

风险等级处理的目的是为风险管理过程中对不同风险的直观比较以确定组织安全策略，组织应当综合考虑风险控制成本与风险造成的影响，提出一个可接受的风险范围，对某些资产的风险，如果风险计算值在可接受的范围内则该风险是可接受的风险，应保持已有的安全措施，如果风险评估值在可接受的范围外，即风险计算值高于可接受范围的上限值，是不可接受的风险，需要采取安全措施以降低、 控制风险。另一种确定不可接受的风险的办法是根据等级化处理的结果，不设定可接受风险值的基准，达到相应等级的风险都进行处理

风险处理计划

对不可接受的风险应根据导致该风险的脆弱性制定风险处理计划，风险处理计划中明确应采取的弥补弱点的安全措施、预期效果、实施条件、进度安排、责任部门等，安全措施的选择应从管理与技术两个方面考虑，安全措施的选择与实施应参照信息安全的相关标准进行

残余风险评估

在对于不可接受的风险选择适当安全措施后为确保安全措施的有效性可进行再评估，以判断实施安全措施后的残余风险是否已经降低到可接受的水平，残余风险的评估可以依据本标准提出的风险评估流程实施，也可做适当裁减。一般来说安全措施的实施是以减少脆弱性或降低安全事件发生可能性为目标的，因此残余风险的评估可以从脆弱性评估开始，在对照安全措施实施前后的脆弱性状况后再次计算风险值的大小

某些风险可能在选择了适当的安全措施后残余风险的结果仍处于不可接受的风险范围内，应考虑是否接受此风险或进一步增加相应的安全措施

风险评估记录

风险评估记录

记录风险评估过程的相关文档，应符合以下要求(但不仅限于此)：

a）确保文档发布前是得到批准的 

b）确保文档的更改和现行修订状态是可识别的 

c）确保文档的分发得到适当的控制并确保在使用时可获得有关版本的适用文档

d）防止作废文档的非预期使用，若因任何目的需保留作废文档时，应对这些文档进行适当的标识

风险评估过程中形成的相关文档还应规定其标识、储存、保护、检索、保存期限以及处置所需的控制，相关文档是否需要以及详略程度由组织的管理者来决定

风险评估文档

风险评估文档是指在整个风险评估过程中产生的评估过程文档和评估结果文档，包括(但不仅限于此)：

a) 风险评估方案：阐述风险评估的目标、范围、人员、评估方法、评估结果的形式和实施进度等

b) 风险评估程序：明确评估的目的、职责、过程、相关的文档要求，以及实施本次评估所需要的 各种资产、威胁、脆弱性识别和判断依据

c) 资产识别清单：根据组织在风险评估程序文件中所确定的资产分类方法进行资产识别，形成资产识别清单，明确资产的责任人/部门

d）重要资产清单：根据资产识别和赋值的结果，形成重要资产列表，包括重要资产名称、描述、 类型、重要程度、责任人/部门等

e) 威胁列表：根据威胁识别和赋值的结果，形成威胁列表，包括威胁名称、种类、来源、动机及 出现的频率等

f) 脆弱性列表：根据脆弱性识别和赋值的结果，形成脆弱性列表，包括具体弱点的名称、描述、 类型及严重程度等

g) 已有安全措施确认表：根据对已采取的安全措施确认的结果，形成已有安全措施确认表，包括 已有安全措施名称、类型、功能描述及实施效果等

h) 风险评估报告：对整个风险评估过程和结果进行总结并详细说明被评估对象、风险评估方法、 资产、威胁、脆弱性的识别结果、风险分析、风险统计和结论等内容

i) 风险处理计划：对评估结果中不可接受的风险制定风险处理计划，选择适当的控制目标及安全 措施，明确责任、进度、资源并通过对残余风险的评价以确定所选择安全措施的有效性

j) 风险评估记录：根据风险评估程序，要求风险评估过程中的各种现场记录可复现评估过程，并作为产生歧义后解决问题的依据

信息系统生命周期

风险评估应贯穿于信息系统生命周期的各阶段中。信息系统生命周期各阶段中涉及的风险评估的原 则和方法是一致的，但由于各阶段实施的内容、对象、安全需求不同使得风险评估的对象、目的、要 求等各方面也有所不同。具体而言，在规划设计阶段，通过风险评估以确定系统的安全目标；在建设验收阶段，通过风险评估以确定系统的安全目标达成与否；在运行维护阶段，要不断地实施风险评估以识别系统面临的不断变化的风险和脆弱性，从而确定安全措施的有效性，确保安全目标得以实现。因此每个阶段风险评估的具体实施应根据该阶段的特点有所侧重地进行，有条件时应采用风险评估工具开展风险评估活动

规划阶段风险评估

规划阶段风险评估的目的是识别系统的业务战略以支撑系统安全需求及安全战略等，规划阶段的评估应能够描述信息系统建成后对现有业务模式的作用，包括技术、管理等方面并根据其作用确定系统建设应达到的安全目标

本阶段评估中，资产、脆弱性不需要识别，威胁应根据未来系统的应用对象、应用环境、业务状况、 操作要求等方面进行分析，评估着重在以下几方面：

a）是否依据相关规则，建立了与业务战略相一致的信息系统安全规划，并得到最高管理者的认可

b）系统规划中是否明确信息系统开发的组织、业务变更的管理、开发优先级

c）系统规划中是否考虑信息系统的威胁、环境，并制定总体的安全方针

d）系统规划中是否描述信息系统预期使用的信息，包括预期的应用、信息资产的重要性、潜在的价值、可能的使用限制、对业务的支持程度等

e）系统规划中是否描述所有与信息系统安全相关的运行环境，包括物理和人员的安全配置，以及明确相关的法规、组织安全策略、习惯、专门技术和知识等

设计阶段风险评估

设计阶段的风险评估需要根据规划阶段所明确的系统运行环境、资产重要性，提出安全功能需求，设计阶段的风险评估结果应对设计方案中所提供的安全功能符合性进行判断，作为采购过程风险控制的依据

本阶段评估中应详细评估设计方案中对系统面临威胁的描述，将使用的具体设备、软件等资产及其安全功能需求列表，对设计方案的评估着重在以下几方面：

a) 设计方案是否符合系统建设规划，并得到最高管理者的认可

b) 设计方案是否对系统建设后面临的威胁进行了分析，重点分析来自物理环境和自然的威胁， 以及由于内、外部入侵等造成的威胁

c) 设计方案中的安全需求是否符合规划阶段的安全目标，并基于威胁的分析，制定信息系统的总体安全策略

d) 设计方案是否采取了一定的手段来应对系统可能的故障

e) 设计方案是否对设计原型中的技术实现以及人员、组织管理等方面的脆弱性进行评估，包括设计过程中的管理脆弱性和技术平台固有的脆弱性

f) 设计方案是否考虑可能随着其他系统接入而产生的风险

g) 系统性能是否满足用户需求，并考虑到峰值的影响，是否在技术上考虑了满足系统性能要求的方法

h) 应用系统（含数据库）是否根据业务需要进行了安全设计

i) 设计方案是否根据开发的规模、时间及系统的特点选择开发方法，并根据设计开发计划及用户需求，对系统涉及的软件、硬件与网络进行分析和选型

j) 设计活动中所采用的安全控制措施、安全技术保障手段对风险的影响。在安全需求变更和设计变更后，也需要重复这项评估

设计阶段的评估可以以安全建设方案评审的方式进行，判定方案所提供的安全功能与信息技术安全技术标准的符合性，评估结果应体现在信息系统需求分析报告或建设实施方案中

实施阶段风险评估

实施阶段风险评估的目的是根据系统安全需求和运行环境对系统开发、实施过程进行风险识别，并对系统建成后的安全功能进行验证，根据设计阶段分析的威胁和制定的安全措施在实施及验收时进行质量控制

基于设计阶段的资产列表、安全措施，实施阶段应对规划阶段的安全威胁进行进一步细分，同时评估安全措施的实现程度从而确定安全措施能否抵御现有威胁、脆弱性的影响，实施阶段风险评估主要对系统的开发与技术/产品获取、系统交付实施两个过程进行评估

开发与技术/产品获取过程的评估要点包括：

a) 法律、政策、适用标准和指导方针：直接或间接影响信息系统安全需求的特定法律；影响信息系统安全需求、产品选择的政府政策、国际或国家标准

b) 信息系统的功能需要：安全需求是否有效地支持系统的功能

c) 成本效益风险 ：是否根据信息系统的资产、威胁和脆弱性的分析结果，确定在符合相关法律、 政策、标准和功能需要的前提下选择最合适的安全措施

d) 评估保证级别：是否明确系统建设后应进行怎样的测试和检查，从而确定是否满足项目建设、 实施规范的要求。

系统交付实施过程的评估要点包括：

a) 根据实际建设的系统，详细分析资产、面临的威胁和脆弱性

b) 根据系统建设目标和安全需求，对系统的安全功能进行验收测试；评价安全措施能否抵御安全 威胁

c) 评估是否建立了与整体安全策略一致的组织管理制度； 

d) 对系统实现的风险控制效果与预期设计的符合性进行判断，如存在较大的不符合，应重新进行信息系统安全策略的设计与调整

运维阶段风险评估

运行维护阶段风险评估的目的是了解和控制运行过程中的安全风险，是一种较为全面的风险评估，评估内容包括对真实运行的信息系统、资产、威胁、脆弱性等各方面

a）资产评估：在真实环境下较为细致的评估，包括实施阶段采购的软硬件资产、系统运行过程中生成的信息资产、相关的人员与服务等，本阶段资产识别是前期资产识别的补充与增加

b）威胁评估：应全面地分析威胁的可能性和影响程度。对非故意威胁导致安全事件的评估可以参 照安全事件的发生频率；对故意威胁导致安全事件的评估主要就威胁的各个影响因素做出专业判断； 

c）脆弱性评估：是全面的脆弱性评估。包括运行环境中物理、网络、系统、应用、安全保障设备、 管理等各方面的脆弱性。技术脆弱性评估可以采取核查、扫描、案例验证、渗透性测试的方式实施；安全保障设备的脆弱性评估，应考虑安全功能的实现情况和安全保障设备本身的脆弱性；管理脆弱性评估可以采取文档、记录核查等方式进行验证； 

d）风险计算：根据本标准的相关方法，对重要资产的风险进行定性或定量的风险分析，描述不同资产的风险高低状况。

运行维护阶段的风险评估应定期执行，当组织的业务流程、系统状况发生重大变更时也应进行风险评估，重大变更包括以下情况(但不限于)：

a）增加新的应用或应用发生较大变更；

b）网络结构和连接状况发生较大变更； 

c）技术平台大规模的更新； 

d）系统扩容或改造； 

e）发生重大安全事件后或基于某些运行记录怀疑将发生重大安全事件； 

f）组织结构发生重大变动对系统产生了影响

废弃阶段风险评估

当信息系统不能满足现有要求时，信息系统进入废弃阶段，根据废弃的程度又分为部分废弃和全部废弃两种，废弃阶段风险评估着重在以下几方面：

a）确保硬件和软件等资产及残留信息得到了适当的处置，并确保系统组件被合理地丢弃或更换； 

b）如果被废弃的系统是某个系统的一部分，或与其他系统存在物理或逻辑上的连接，还应考虑系统废弃后与其他系统的连接是否被关闭； 

c）如果在系统变更中废弃，除对废弃部分外，还应对变更的部分进行评估，以确定是否会增加风险或引入新的风险；

d）是否建立了流程，确保更新过程在一个安全、系统化的状态下完成。

本阶段应重点对废弃资产对组织的影响进行分析并根据不同的影响制定不同的处理方式，对由于系统废弃可能带来的新的威胁进行分析并改进新系统或管理模式，对废弃资产的处理过程应在有效的监督之下实施，同时对废弃的执行人员进行安全教育，信息系统的维护技术人员和管理人员均应该参与此阶段的评估

基本概述

信息安全风险评估分为自评估和检查评估两种形式。信息安全风险评估应以自评估为主，自评估和检查评估相结合、互为补充

自行评估 

自评估是指信息系统拥有、运营或使用单位发起的对本单位信息系统进行的风险评估。自评估应在本标准的指导下，结合系统特定的安全要求进行实施。周期性进行的自评估可以在评估流程上适当简化，重点考察自上次评估后系统发生变化后引入的新威胁以及系统脆弱性的完整识别，以便于两次评估结 果的对比。但系统发生本标准6.5节中所列的重大变更时，应依据本标准进行完整的评估。 

自评估可由发起方实施或委托风险评估服务技术支持方实施，由发起方实施的评估可以降低实施的费用、提高强信息系统相关人员的安全意识，但可能由于缺乏风险评估的专业技能，其结果不够深入准确；同时受到组织内部各种因素的影响，其评估结果的客观性易受影响。委托风险评估服务技术支持方实施的评估，过程比较规范、评估结果的客观性比较好，可信程度较高；但由于受到行业知识技能及业务了解的限制，对被评估系统的了解，尤其是在业务方面的特殊要求存在一定的局限。但由于引入第三方本身就是一个风险因素，因此对其背景与资质、评估过程与结果的保密要求等方面应进行控制，此外为保证风险评估的实施，与系统相连的相关方也应配合以防止给其他方的使用带来困难或引入新的风险

检查评估

检查评估是指信息系统上级管理部门组织或国家有关职能部门依法开展的风险评估。
检查评估可依据本标准的要求，实施完整的风险评估过程。
检查评估也可在自评估实施的基础上，对关键环节或重点内容实施抽样评估，包括以下内容(但不仅限于)
a）自评估队伍及技术人员审查
b）自评估方法的检查
c）自评估过程控制与文档记录检查
d）自评估资产列表审查
e）自评估威胁列表审查
f）自评估脆弱性列表审查
g）现有安全措施有效性检查
h）自评估结果审查与采取相应措施的跟踪检查
i）自评估技术技能限制未完成项目的检查评估
j）上级关注或要求的关键环节和重点内容的检查评估
k）软硬件维护制度及实施管理的检查
l）突发事件应对措施的检查

检查评估也可委托风险评估服务技术支持方实施，但评估结果仅对检查评估的发起单位负责，由于检查评估代表了主管机关，涉及评估对象也往往较多，因此要对实施检查评估机构的资质进行严格管理

在本公众号回复"001"下载《信息安全技术  信息安全风险评估规范》GB_T 20984-2007》PDF版本在线查阅

原文始发于微信公众号（七芒星实验室）：【SDL实践指南】安全风险评估规范