大咖话安全第三期 | 周明昊：漫谈安全风险治理中的数字化

大家好，我是嘉实基金信息安全负责人周明昊。应安世加Jacky邀稿，写一篇在大咖话安全中分享的文章。

非常感谢因为这次机会，也促使我在年末做总结的时候，沉下心来思考：这一年中做的各类项目、参与的种种琐事中，有没有一条主脉络，能够对整体工作成果进行衡量的？是否有能提炼出共性的内容，能帮助安全人员更好地开展工作的？

第一层的公司，还处在信息安全管理的石器时代，安全人员只能自求多福，这里不费笔墨。我们把关注重点放在第二层的公司，有相当大比例的公司也正处于这一水平。在这一层的管理者心智是开明的，但他需要来自安全人员的有效输入，如果输入的内容质量高，有说服力，就能够促使安全工作得到管理上的支持。但如果输入质量不够，或没有给到他想要的点，他的关注的兴趣可能会逐渐丧失。

所以我们要做的是给管理者提供持续地、高质量的输入，让信息安全风险情况成为管理的一个常态化指标，给管理者提供便捷地参与风险治理的途径，从而在呈现问题——解决问题中形成一个良好的正反馈，使安全风险管理工作得到长效地支持，并等待合适的契机推动管理水平进入第三层。

如何做这个“输入”，我们可以探讨一种思路：把信息安全工作的成果数字化，以数据为核心实现简明直观的呈现。常见的内容有两种：1. 日常运行情况——安全运营数据，2. 需要关注的问题——风险管理数据。

安全运营的数字化相对简单，确定好要呈现哪些数据即可，我倾向用“主动型”的数据，如漏洞扫描系统次、渗透测试次数、安全评审次数、弱口令整改次数等指标能体现工作过程，可以反映出安全运营的健康度和效率。而攻击事件次数、阻断攻击次数等“被动型”数据个人感觉在实践中表现力较弱，但也许有的管理者关注此类数据，可以按需调整。

而风险管理的数字化难度要显著大于安全运营，以下篇幅都是关于本文重点探讨的主题——安全风险治理的数字化。

以公募基金行业为例，公司内部有非常多的业务系统， 这些系统往上对应到几大业务板块。公司的运作理念是以业务为核心的。那我们就适合把风险以业务系统为单位展示，并将风险后果与业务板块自身的目标挂钩，以引起业务板块管理者的重视。基于这个场景的分析，我们得到了基础需求：以业务系统为单位进行风险评分，展示出风险值的构成，并描述风险对业务的影响。

风险值的设计目标是反映系统当前的实际风险水平，单一维度的数值很难实现这个效果，因此常见的情况是由多个方面的评价加权计算得出。根据安全建设阶段的不同，将会有不同的因子可供选择，建设初期不用过于追求完美，只要把现有的数据运用上，把首要的问题呈现出来即可。本例中选取的因子来自于漏洞扫描结、渗透测试和残余风险记录。

因为嘉实在上一阶段的安全建设中，已经实现了漏洞扫描结果管理与资产信息的关联，所以直接就能得到每个业务系统的高危漏洞主机数、漏洞修复率等数据，我们选择在风险值计算中把这些数据用上。但是考虑到漏洞的实际危害和服务器所处的位置、基于版本检测或是原理扫描、漏洞利用工具的传播程度等多方面因素有关，漏洞主机数量和修复率这两个指标也存在不同程度地失真情况（如服务器数量多的系统更容易出现多台有漏洞的主机，只出现一台有漏洞主机但是没及时修复则会导致漏洞修复率为0）。所以我们面临两个选择，制定一个复杂的基于漏洞的评分算法，或简单地评分并给其一个较小的权重。这里我选择后者，暂时屏蔽不同漏洞之间差异，只以系统的高危漏洞主机数、漏洞修复率作为一个权重较小的统计学意义上的因子，将有特别影响漏洞摘出去通过其它方式进行计算。

而渗透测试的结果因本身就是人工判断后产出的，其定为高危而尚未修复的问题都是值得关注的，给一个中等的风险值权重。这部分值的获取可以通过要求渗透测试工程师按特定模板出具报告，由后台扫描文档解析后获得。

给残余风险指标一个高权重有以下三方面好处：一是风险值所包含的内容更加地丰富结论更有说服力，二是让许多零碎的安全风险能够在此机制中得到持续追踪，三是这部分评分有较大的主观自由度，在数字化早期可以有灵活地调整修正的空间，使最终的风险分值贴近实际情况，而不至于失真。以后随着安全和IT管理数字化的愈发成熟，残余风险中的部分内容是可以摘出去自动获取和计算的。但是当前为了不给系统带来太大的复杂度，我们这里可以先制定个纸面上的标准，按照一套原则去人工录入残余风险的具体内容和其评分。

然后我们还有一个步骤，明确“风险对业务影响”的描述规则。这部分我初步想法是先人工填写，未来建立一套映射关系，对每个风险的输入都有一个关联的风险后果，风险后果关联到业务板块上有一个业务后果。后果的具体内容就可以发散了，可以按最坏的情况考虑，如下例：

互联网业务服务器A存在MS17-010漏洞——>风险后果为远程获取服务器权限——>业务的后果为业务中断/业务数据外泄、公司声誉受到损害、客户流失、被监管处罚……

举这个例子主要是因为大家对此类场景比较熟悉，一般来说这个级别的漏洞更容易出现在不重要的边缘服务器或办公电脑上，其对业务能造成何种威胁就要结合安全人员对自身环境的熟悉程度，以及对各类攻击手法的理解来发挥了，实际情况的映射肯定比这个例子要复杂一些。

做完以上几个部分后，风险治理数字化的基础工作就完成了，我们有了构成风险值的因素，有了获取他们的渠道，有了根据权重计算出总分的算法，有了对业务影响的描述规则。接下来的工作就是代入产品经理的角色，让数字化的展示对你的“用户”更加友好。为此，我们可能会有一系列的扩展需求：

排序和视图：管理者习惯于何种呈现方式，更关注整体情况还是风险值最高的系统？

工作流：是否希望通过数字化展示的系统直接下发工作流任务？系统中是否要纳入业务对风险的反馈和跟踪？

上下文信息：是否需要同时展示业务系统的相关信息，如系统责任人、开发方等。

关注按钮：这是在写这篇文章时突然想到的，可以给管理者提供一个关注按钮，他看到关心的风险条目后可点击“关注”。然后该系统的责任人就会收到一封邮件“某某领导已关注该风险，请在周会中就该事项进行说明”，当风险关闭后，可再将结果自动通知到管理者。用这种方式给管理者一种参与感，提升其使用体验。

最后提一下数字化过程中一定会遇到的问题——数据质量问题。风险治理数字化的输入，最关键的部分来自其它系统，IP与系统的对应关系、系统与责任人的对应关系、这些数据如不准确，都可能造成结果的南辕北辙。这里也许需要引入一个发现问题、建立机制、推动数据质量逐渐提升的治理框架。这本身不是一个安全问题，我在这方面也所知不多，这里就不做展开了，相信大家有更好的了解渠道。

花了几天时间写到这里，泛泛地从数字化的驱动力谈到在风险治理中的实现，这篇文章差不多要收尾了。我认为自身也正处于数字化进程的早期阶段，有许多细节问题还要进一步磨合和完善的，希望大家能取其精华去其糟粕，结合自身公司的情况走一条适合的道路，在数字化的大趋势下，共同前行。