怎样写一份符合标准的风险评估报告？

0x0 前言

文章作者是一个在二线城市做安服管理滴，但是确对安全本身有处女座一般的要求。其实很多刚入行或转行到网络安全的萌新，不知道或者也说不清风险评估需要些什么，具备些什么过程？

怎么写一份规范的风险评估报告？这还真不一两句能说清的，如果想了解一下看下此文档吧。

0x1 标准依据

网络安全讲究条款依据，怎么算一个合格的风险评估？国标文件详见《YD/T 2252-2011 网络与信息安全风险评估服务能力评估方法》（百度一下到处都有）

当然我们这里不是来讲标准的，而是关键的过程，找到这个标准文件注意力请放在第四页的这个表格上。

这 4 个阶段 16 个控制项非常重要，简单说标准文件已经表明风险评估不是一个文档，还应该有很多众多的过程文档，申请文档，结论文档组成。

截图部分文档其实本身严格得说也不全，但是至少 4 个阶段可以体现出来了。

0x2 主要过程与阶段

此段以阶段形式来讲解风险评估主要过程。

评估准备阶段：

这个阶段标准文件中主张 4 个控制措施、服务需求界定、服务合同签订、服务方案制定、人员和工具准备。

服务需求界定：主要跟客户商议，服务范围比如多少个服务器啊，什么时候开工，什么时候结束。

服务合同签订：简单说签合同，定价格。写明交付什么东西为验收标准，写明双方责任义务以及违约条款。

服务方案制定：工作计划，工作周期，项目开始起止日期等。涉及到每个工作所涉及的安排不同技能人员和工作内容。

人员和工具准备：项目组架构图，项目成员联系名单，以及甲方负责人需要配合工作的人员联系名单等（运维人员联系名单），评估中可能用到的工具介绍和影响等。

风险识别阶段：

这个阶段标准文件中主张 4 个控制措施：资产识别、威胁识别、脆弱性识别、已有措施确认。

资产识别：识别客户对项目内容的所有设备，一般情况主要是硬件，如涉及业务服务器和计算机，周边设备打印机，加密盒，网络的相关设备。标识资产重要程度我一般以 1-5 分值来标识重要程度，因为你问客户只有一句话，我的东西都重要 ╮(╯▽╰)╭。自行判断吧。

威胁识别：主要讲可能发生的危险，但是目前并没有发生，比如停电，地震，漏水，硬件故障人员误操作等。一旦出现会影响这个业务系统可能性的。建议是做个表格列出威胁对应相对的结果以及可能发生程度进行标识。一般调查问卷访谈询问类调查。属于这类的威胁调查内容。

脆弱性识别：一般脆弱性通常说的两个方面：系统本身的存在问题和配置不当造成的问题，前者说的主要是就是微软操作系统的本身漏洞需要打补丁这类，后者比如一些防火墙策略设之不当或者密码复杂度不当造成的问题等。我们常说的 「漏洞扫描」「渗透测试」「主机基线检查」 应该归结于这个部分。

已有措施确认：比较好理解就是客户已经有的安全措施是否有效，你需要进行确认和记录。比如客户有防火墙，你需要用工具或者访问的方式测试防火墙相关策略是否有效，如果安全措施有效对应的之前调查到的风险值可以适当调整降低。

风险分析阶段：

这个阶段标准文件中主张 4 个控制措施：风险分析模型、风险计算方法、风险分析与评价、风险评估报告。

风险分析模型和风险计算方法（两个合在一起说）：根据你之前的工作和收集到的相关漏洞和调查问卷的情况来综合分析基本可以开始写风险评估报告了。这是风险评估理论上的重要环节，但是实际过程中很多安全公司文档写了一堆计算方法，实际风险值不是根据描述的方式算的，可以说是随意填的。毕竟认真写这部分涉及到很大的人力成本。

一般客户也不会深究这个，毕竟代数函数一堆一般人也懒得挑刺，对于客户实际影响不大，客户关注主要还是结果。

一般来说风险计算方法常用的是矩阵法和相乘法，

矩阵法的概念：Z=f(x,y)。函数 f 采用矩阵形式表示。以要素 x 和要素 y 的取值构建一个二维矩阵，矩阵内 m´n 个值即为要素 Z 的取值。

相乘法的概念：z=f(x,y)=xy，当 f 为增量函数时，Ä可以为直接相乘，也可以为相乘后取模等。

碍于篇幅不赘述可以具体可以百度。

风险分析与评价：简单说目前风险现状，还有那些需要整改的部分，现状有那些安全隐患。

风险评估报告：风险评估报告应该包含你之前工作的一些重要结果，如渗透测试成功的截图和服务器，主机基线不合格的主机和具体项目，但是风险评估报告不是所有报告的堆叠，自行节选比较问题严重和突出的部分。报告中还需要包括，风险的整改建议和办法，已有措施的作用和具体条目。还有剩余的风险处置办法客户是接受风险还是整改等。关于接受风险和之后的处置办法可能一个报告不好体现。可以写两次就是客户自行整改前的情况和自行整改后的情况。进行对比，还有哪些风险无法整改的，及时体现和告知客户。

风险处置阶段：

PS:按照标准文件要求风险处置部分是跟风险评估报告分开的，但是也有甲方要求风险评估报告和风险处置部分写在一起，毕竟因为这部分对于风险整改非常重要。但是也有一些合同特殊原因将风险评估和风险处置拆成两个文档，一方面防止甲方不给后续尾款，另一方面有底牌在手始终是好的。

这个阶段标准文件中主张 4 个控制措施：风险处置原则、安全整改建议、组织评审会、残余风险处置。

风险处置原则：哪些漏洞需要修复？哪些等级以上的漏洞需要修复？比如中高危漏洞一定要修复，关于业务方面的中间件漏洞，需要业务重启下线修复等。

安全整改建议：就是具体漏洞如何整改，如何操作。但是注意一般安全厂商不负责整改，提供方法交给甲方维护人员或三方公司。如需安全厂商整改价格另议。

组织评审会：说到这个会议，其实每完成一个小阶段的工作建议告知客户，可以说当刷存在感。这里评审会就是告知和讨论具体哪些漏洞不能整改，哪些能整改，哪些漏洞客户接受风险。

残余风险处置：对于无法整改的漏洞，可以在网络层禁止其他方式访问，访问不到漏洞就无法攻击，我这只是一个思路，漏洞的修复和规避方式也是各种各样的，也可以上安全设备等。