前言

信息安全是网络发展和信息化进程的产物，近几年，无论是国家层面，还是企业本身，都对信息安全愈发的重视。风险管理的理念也逐步被引入到信息安全领域，并迅速得到较为广泛的认可。风险评估逐步成为信息安全管理的最为重要的手段之一。那如何规范的实施风险评估，保证信息系统的安全，成为很多企业安全负责人认真考虑的问题。

一、参考标准

1.1国外标准

NIST SP800-26 《Security Self-Assessment Guide forInformation Technology Systems》

NIST Special Publication 800-30 《Risk ManagementGuide for Information Technology Systems》

OCTAVE：Operationally Critical Threat, Asset, andVulnerability Evaluation Framework

ISO/IEC 17799:2000 《信息技术——信息安全管理实施细则》

ISO/IEC 27001:2005 《信息技术——信息安全管理实施规范》

AS/NZS 4360:1999 《风险管理》

ISO/IEC TR 13335 《信息技术安全管理指南》

1.2国内标准

GB/T 20984-2007《信息安全技术 信息安全风险评估规范》

GB/T 31509-2015《信息安全技术 信息安全风险评估实施指南》

GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》

GB/T 18336-2001《信息技术 安全技术 信息技术安全性评估准则》

二、前期准备

2.1 确定评估目标

因风险评估主要目标是信息系统，故开展风险评估开展之前，首先需要了解的就是此次风评的目标，可以是整个单位的所有信息系统，或者单个系统，单个系统的我们一般都是叫做专项风险评估。

2.2 确定评估范围

确定好风险评估的目标后，就需要对此目标的边界进行定义，可以从以下几个方面考虑：

1）待评估系统的业务逻辑边界（如独立的系统可以不需考虑），例如跟哪些系统有数据交互，避免关联系统被渗透，从而导致此系统也被渗透，可以例举出；

2）网络及设备载体边界，这里最好有网络拓扑图，那样会比较清晰的看到支撑此系统的硬件设备情况，是否有冗余配置，例如服务器、交换机、路由器、安全设备等；

3）物理环境边界，主要讲的是机房的环境，有没有监控设备、防水、防雷、防潮、异常告警，其实等保测评时会考虑这方面，如机房太远或不方便查看，可以看看系统对应的最新测评报告；

4）组织管理权限边界，主要是需要明确目标系统是谁负责开发、维护、管理等。

2.3 组建评估团队

可能有同学会问，为什么需要组建团队去做这个事情呢？

经历过风险评估同学都知道，这工作是极其复杂的，会涉及非常多的方面，当然如果是传说中的“一个人的安全部”，预算又吃紧的单位，那就只能仰天长叹，默默搬砖吧，希望下面的内容对你有帮助。

下图是标准理想状态的团队组成，大厂或者预算充足的ZF单位才有这样的高配，单位可以根据公司内部的情况组建团队，也可以委托第三方有风险评估资质的公司负责。

2.4工作计划

风险评估是一个复杂繁琐的工作，常需要阶段性汇报，中间会有许多过程文档产生，这也有利于项目主管了解项目进度，因此详细的实施计划肯定是不可缺少的。

可以参考如下内容：

实施流程：

实施日程表：

2.5评估方案

前面都说到了风险评估非常复杂繁琐，评估方案肯定是必须要有的，方案中应包括一下内容：

1）风险评估工作框架：风险评估目标、评估范围、评估依据等；

2）评估团队组织：包括评估小组成员、组织结构、角色、责任；领导小组和专家组（可无）

3）评估工作计划：包含各阶段工作内容、工作形式、工作成果、工作实施时间安排等

4）风险规避：保密协议、评估方法、评估工具、应急预案等

5）项目验收方式：包括验收方式、验收依据、验收结论等（适用于委托第三方的单位）

可参考如下内容：

三、实施过程及阶段

3.1实施流程

风险评估模型：

3.2系统调研

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

a)系统等保测评等级

b)主要的业务功能和要求

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

d)系统边界，包括业务逻辑边界、网络及设备载体边界、物理环境边界、组织管理权限边界等

e)主要的硬件、软件

f)数据和信息

g)系统和数据的敏感性

h)支持和使用系统的人员

i)信息安全管理组织建设和人员配备情况

j)信息安全管理制度

k)法律法规及服务合同

系统调研可以采取问卷调查、现场面谈相结合的方式进行。

我们一般都先要求填写问卷调查，对问卷调查有疑问的地方采取现场访谈的方式进行了解，这样更容易理解

3.3资产识别

资产识别工作主要是参考GB/T 20984--2007中的分类列明评估范围内的各项资产，包括硬件、软件、数据、服务、人员和其他等六类资产，但是我们一般都会有根据标准要求将资产分类为硬件、软件、文档和数据、人员、业务应用、物理环境、组织管理等七类资产。详细见《资产识别分类参考表》，有感兴趣或需要的同学可以私信我获取。

资产识别小组需要对评估范围内的资产进行了逐项分析，比对资产清单，结合系统运行现状，识别出评估范围内的信息资产，形成了《资产识别表》；

参考《资产重要性程度判断准则》为每个资产进行了重要性程度赋值。资产识别和赋值结果记录在《资产识别表》中。

可以参考如下表格制定《资产识别表》：

3.3.1 资产重要性确定

资产识别小组依据资产对主要业务、运作及声誉影响程度确定重要资产的基准线（阀值），在基准线以上资产确定为重要资产，填入《重要资产赋值表》；例如资产重要性程度大于等于30的资产被判定为重要资产。

3.3.2CIA三性赋值

所谓CIA三性指的是保密性、完整性、可用性，资产识别小组依据《信息安全风险评估规范（GB/T20984-2007）》对于保密性、可用性、完整性的定义，分别在《重要资产赋值表》中填资产的保密性等级值、完整性等级值和可用性等级值。等级值划分为很高（5）、高（4）、中等（3）、低（2）、很低（1）五个等级。

可以参考如下表格制定《重要资产赋值表》：

3.4威胁识别

威胁识别小组通过查阅安全设备、日志和以往的安全事件记录，分析信息资产在物理环境、网络、人员、设备故障、恶意代码及病毒等方面可能出现的情况，依据《资产面临的威胁列表》，分析系统资产潜在的威胁，最终确认形成了《威胁识别表》。依据经验，建议威胁识别放在脆弱性识别之后，因为威胁都是通过利用资产的脆弱性才有可能造成危害。

可以参考如下表格制定《威胁识别表》：

3.5脆弱性识别

脆弱性识别小组针对不同类型的重要资产分组进行脆弱性分析，可以从技术和管理两个方面进行，技术方面：运用工具扫描、基线核查、渗透测试等方式，从物理环境、网络、主机系统、应用系统、数据和文档等方面查找资产的脆弱性；管理方面:通过文档查阅、问卷调查、当面访谈的方式，从人员、组织管理等两方面进行脆弱性识别；最终形成《脆弱性识别表》。每种资产的详细识别内容，因篇幅有限，这里就不赘述了。

可以参考如下表格制定《脆弱性识别表》：

3.5.1基线核查

基线核查可以从物理环境、网络、安全设备、主机系统、应用系统、数据库等方面进行核查确认，每个方面都可以参考《GBT 31509-2015 信息安全技术 信息安全风险评估实施指南》中附录B安全技术脆弱性核查表，单位也可根据自身情况确定核查项，不过主机系统的基线核查建议采用脚本的方式执行截图保存，那样能提高效率，节省时间。

主机系统基线核查脚本：

3.5.2 主机层扫描

主机层的检测主要是采用主机层扫描设备或软件进行，各大厂商都有主机层的扫描工具，不过建议采用绿盟的极光进行扫描。

注意以下几点：

1）按照重要资产识别中的各类资产IP进行扫描；

2）在WAF或者防火墙上添加扫描设备IP至白名单，不然容易引发告警；

3）应在非业务时间段进行，以防扫描影响业务；

3.5.3应用层检测

对评估目标使用工具进行应用层扫描，例如AWVS、APPSCAN等，对扫描的结果进行验证、确认，加入到脆弱性资产识别表中，预算可以的单位建议做渗透测试或者内部团队安全检测，这样能尽可能多的发现风险点，不过进行应用层扫描或者渗透测试时，应注意以下几点：

1）只对应用系统中的重要资产进行渗透测试或扫描；

2）在WAF上添加渗透白名单；

3）不在业务时间段渗透或者扫描；

4）规定不允许获取敏感数据，不能备份数据；

5）上传的webshell测试完成后，必须删除；

6）所有渗透测试结果必须有截图；

3.6已有安全措施确认

在识别脆弱性的同时，脆弱性识别小组应对已采取的安全措施的有效性进行确认，结果做为不可接受风险处理计划的依据。对有效的安全措施继续保持，以避免不必要的工作和费用，防止安全措施的重复实施。对确认为不适当的安全措施应核实是否应被取消或对其进行修正，或用更合适的安全措施替代。

可以通过访谈、现场调查的方式进行处理记录；但设计到技术方面的措施，建议实际操作验证会更合适。安全措施有效性确认不需要具体到每个资产，可以覆盖多个资产。有效的安全措施可以降低多个资产的脆弱性。

已有安全措施确认表可参考如下：

可以参考以下步骤实施：

1、记录并确认已有的安全措施；

2、现场测试安全措施是否有效；

3、记录查验结果，形成《已有安全措施确认表》

3.7风险分析方法

风险分析小组采用矩阵法计算出风险系数，然后按照《深圳市信息安全风险评估实施指南》中“资产风险值＝资产重要性程度值×威胁风险系数”的公式，计算资产风险值，经项目负责人批准确认形成《资产风险值表》。

威胁风险系数计算矩阵：

注：

1.本矩阵用来确定威胁的风险系数。

2.矩阵横轴为威胁的影响程度，纵轴为威胁发生的可能性，横纵交点为威胁风险系数。

针对威胁风险系数判断准则：

3.8资产风险值等级划分

风险值等级的划分是可以根据单位大情况调整的，如评估的是内部系统，例如OA，内部办公的系统，可以将风险对应的值设置的更高些，例如，对外访问的系统风险等级为“中”的风险值设置为100-150，但是内部系统风险等级为“中”的风险值可以为150-200。可以根据具体的情况设置。

风险等级划分可以参考如下表格：

3.9不可接受风险划分

不可接受的风险划分经风险分析小组确定并经项目负责人批准，我们应该可以设定风险值=阈值作为不可接受风险值，这需要根据单位的实际情况跟领导的要求来确定，有的单位对安全要求很高，风险等级为“低”以上都需要处理，参考上面的表格，那就是风险值为80以上的风险项都需要处理，有的单位对安全要求不是特别高，只需风险等级为“中”以上处理即可，参考上面的表格，那阈值为175，所有风险值>=175的风险项都需处理。

3.10风险分析结果

风险分析小组根据前期的工作，进行风险分析，形成《资产风险值表》：

3.11风险统计

资产风险情况：

风险接受情况：

3.12不可接受风险处理计划

不可接受风险找出来后，肯定需要对不可接受风险制定处理计划，最好能详细到每项风险对应的处理步骤及方法，以及截至时间，那样才有可能保证完成，当然还需对《已有安全措施确认表》中的风险项进行，确认是否能暂不处理或延长截至时间等。

《不可接受风险处理计划》可以参考如下表：

3.13专家评审

组织评审会是风险评估活动结束的重要标志，邀请单位领导、主要评估人员、信息安全专家等参与，项目组长及相关人员需对评估技术路线、工作计划、实施情况、达标情况进行汇报，并解答评审人员的质疑。

四、工作总结

工作总结是肯定需要写的，必须跟领导或风险评估方汇报一下此次风险评估的内容，当前发现了多少风险，什么时候能处理完成，还有哪些方面需要加强，到此整个风险评估的工作才结束，至于风险处置计划那后续还需跟进处理才行。

以上涉及的标准文档，如果有感兴趣的同学需要可以私信我获取。针对上面风评的步骤或内容，如有不足的地方，可以交流、斧正。

最后附带一下整个风险评估工作流程图：

*本文原创作者：jary123，本文属于FreeBuf原创奖励计划，未经许可禁止转载