*全文为黄乐本人口述，FreeBuf仅做整理，无任何修饰或故事化，原味呈现最真实的企业安全人心声

作者简介

黄乐，央视网网络安全部副总监。在央视网主要负责网络安全架构的设计和建设。主要包括攻防对抗技术研究、安全检测及防御体系建设、安全播出管理平台建设、漏洞治理平台研发、威胁感知平台研发、应急响应系统研发等工作。同时，提出了“重检测，轻防御”的安全架构设计理念，并通过“快速及格、逐步迭代”的思路快速落地了央视网安全播出管理平台。拥有十年网络架构设计经验，五年安全体系建设及管理经验，清流派企业安全沙龙创始人，两个安全公众号主理人。清流派企业安全沙龙是安全行业甲方闭门沙龙，每月邀请各企业安全部门负责人从多个方面探讨企业安全建设及管理的思路和经验。

风险管理是一个比较大的概念，对于央视网来说，我们并不是在进行安全建设之初就设计了风险管理的目标，而是在大量基础工作和频繁对抗的过程中，逐步积累而形成的体系的雏形，再将这个雏形不断的完善，才形成了一个相对完整的风险管理体系。本文将先从风险的三个基本要素（资产、脆弱性和威胁）分别展开管理思路，最后再将这三要素整合到一起。

一、资产

资产管理对企业安全管理的重要性不言而喻，对于央视网安全团队来说，关注资产的信息主要是IP、服务、url、负责人（部门）这几个要素。至于其他要素不在本文讨论范围内，央视网安全团队也主要致力于对这几个要素的检测和管理。

1.1 IP&服务

为了安全检查的全面性，安全部门的资产发现至少要确认IP、端口和服务，至于业务线和负责人的信息可以交给资产管理相关的部门来完善。具体方法如下：

技术选型：经过多方面考虑我们还是选择功能非常成熟的Masscan和nmap，通过gowoker调度多个Masscan进程完成端口探测，再将探测结果通过gowoker发送给多个nmap进程，完成服务的探测。

1.2 域名

对于域名盘点来说，采用爬虫是非常顺理成章的思路，通过横向比较我们采用“幽灵蛛”（https://github.com/henrylee2cn/pholcus）作为爬虫工具，并在此基础上针对央视网改造了动态url的爬取方法。目前效率为：一台sever限制一个主域爬15层，2个小时内完成140万个链接的任务。但这些url不能直接送给扫描器，因为140万个URL里有大量框架相同，仅内容不同的url。为了进一步减少扫描器的压力，我们对这些url进行了压缩。大概方式是将url的目录结构变为树形结构图，再通过不同的节点判断页面框架的一致性，目前我们用这种方法将1.7亿个url压缩到了100万以内，而且有进一步优化的空间。

DNS解析记录，通过DNS解析记录一方面可以进一步补足域名库，另一方面可以评估域名的被访问频率，在扫描任务积压时，优先扫描访问量较大的域名（当然要在系统承载能力范围之内）。

1.3 流量解析

主动扫描的方式探测资产（无论是IP还是域名），都会存在漏报问题，虽然原因不一样，但是结果都是漏报。我们进一步采用了流量解析的方式对资产做进一步收集。由于央视网有商业流量探针，我们仅需要将流量探针数据接入公司统一的数据平台（ELK）中，再周期性的对ELK中的数据进行字段提取即可。

1.4 资产下线

前面三个方法重点都放在了新上线资产发现上。但是对于资产下线或者闲置资产的管理也是非常重要的。从笔者的经验上看，大部分入侵的第一步都是从一些无人关注的老旧资产开始的。判断资产下线方式如下：①主动扫描的方式可以定义几个扫描周期内没有发现该资产就定义为下线（我们定义的数值是3），但访问不到的情况在安全团队看来是问题不大的。②流量解析方式可以定义一个时间周期某个资产（IP或者url）没有被访问就定义为下线（我们定义的数值是7天）。

二、脆弱性

脆弱性管理方面，我们主要从漏洞、基线和合规三个维度来进行管理，由于篇幅所限，我从漏洞管理角度出发给介绍一下脆弱性管理的整体思路。

2.1 扫描工具

2.1.1 商业扫描器

商用扫描器抛开价格因素，各个方面都要好于免费和开源的产品（没有花钱的不是）。早些年商用扫描器的产品形态都是“硬件盒子”。其特点是：

① 单个硬件扫描效率有限；

② 基于特征的扫描会有误报的情况；

③ 没有资产管理模块，整理报告比较费时；

④ 输出报表不够友好。

所以这类扫描器适用于资产规模不大（少于5000台sever）的环境中。

近些年很多厂商逐渐认识到了传统扫描器的局限性，推出了基于云服务的漏洞扫描产品。目前笔者了解到的云服务产品主要特点是：减少了低版本漏洞的数据，同时用POC的方式降低误报率、用云的方式实现平行扩展的能力、将人工服务整合到产品中、加入了一些漏洞管理功能。但问题是：云服务的方式无法实现对内网的扫描、对漏洞信息的保护是个双方需要互信的过程。

2.1.2 自主研发

前文可以看到，无论是免费、开源或者是商业产品都有不同的问题。我们需要的是全面的、低误报的、高效的、可扩展的、与资产关联的、可定制的、带有管理功能的漏洞扫描系统（要求有点多）。这么“变态”的要求，估计没有哪个产品能全部满足。那么就只剩下自主研发一条路可以走了。自主研发的内容比较多，笔者将用单独的一节来介绍。这里先简单介绍一下设计原则：

① 功能一定不是越全越好，从紧急功能开始，向非重要的延伸；

② 用开源扫描器改造最方便，可以从开源入手，逐步改造，直到最终完全重构；

③ 尽量减少独立创造的环节，如前文所述，企业中的安全部门不是用来炫技的，用最有效的办法解决问题是关键。

所以，优先考虑整合已有功能，小步快走，迭代（而非设计）出一款适合自己的产品。

2.2 漏洞管理

漏扫报告整理工作是非常耗时，且技术含量不高的工作。很多漏扫和渗透工程师宝贵且昂贵的工作时间都耗散在这方面的工作上。笔者团队开发漏洞管理主要致力于解决日常工作的一些痛点。系统主要分为主要从资产、数据整合、流程、分析和展现五个维度。

资产库带入：通过资产库的带入，系统可以通过IP或URL信息自动将漏洞信息整合，并分配给相关的负责人，这大大减少了查询和沟通的时间。

数据整合：主要是将数据散乱的数据整理成可读性更好的形式，比如针对某个软件的低版本漏洞有几十个，在数据整合过程中可以压缩成一条，细节隐藏在详情中。再通过自定义的算法重新将漏洞分出优先级，从而指导运维和开发有次序的修复漏洞；

流程：流程是一个类似于工单系统的模块，一方面可以规范漏洞发布点，避免信息泄露；另一方面流程的相关数据保留下来后可以为后面的数据分析和综合展示提供数据；

分析：有了漏洞数据和流程数据，我们可以根据自己的需求做各种各样的分析，从通用的漏洞类型分布、漏洞数量曲线，到深入一些的“部门未修复漏洞数量排名”、“系统脆弱性评分”等等，这给安全部门一个很好的抓手，督促业务部门整改漏洞。

展示：将上述的分析通过大屏展示的方式放到比较显眼的地方，是非常有必要的。一方面体现安全团队的工作量，另一方面可以提高相关部门和领导对漏洞管理工作的重视程度。

关于资产和漏洞管理的整体架构，由于篇幅问题仅做了思路上的描述，更多细节读者可参考我以前写的一篇文章《漏洞治理平台的设计与实现》。

2.3 从漏洞管理到脆弱性管理

漏洞管理是脆弱性的一部分（当然是很重要的一部分），我们在漏洞管理系统的技术上正在进一步增加基线和合规方面的信息，将漏洞管理系统升级为脆弱性管理系统。这两方面工作由于与漏洞管理的思路大同小异，所以这里仅提出一些必要的关注点：

基线检测：由于标准的基线检测描述较为模糊，需要根据企业实际情况做大量的定制化检查脚本，所以建议通用检查策略仅做重要的检查项，这样方便基线检测脚本落地。另外，对于最新技术和自主研发技术的基线，通用策略中无法提供参考，可以在等级保护及行业相关标准中寻找匹配项。基线检测方面的工作，笔者曾经合小伙伴们在“清流派企业安全沙龙”第六期详细探讨过，并形成了纪要。（具体内容点击这里）

合规性管理：这个模块主要针对无法通过机器检测方式得到答案的检测项，比如：某系统是否多机房部署？系统密码复杂度及修改周期要求等。这些需要通过问卷的形式下发给业务部门，建议问卷系统设计过程中可以给出默认选项，方便相关负责人填写问卷。从笔者经验来看，系统的复杂程度和系统推广的难度成正比的关系，所以强烈建议在系统设计的时候要充分考虑易用性。

三、威胁管理

央视网威胁管理系统的总体思路与业内流行的“态势感知”或“威胁感知”的概念比较类似。我们以数据为基础，通过大量分析策略输出报警和展现的相关数据，最终由一些联动系统负责完成封堵，由展示系统完成综合展现。

策略上，我们偏重于“事中检测”。因为事前成本太高，央视网这样的中小型团队无法支撑相关的算法开发工作；而事后为时已晚，善后处理的再好也难以挽回安全事件造成的损失，所以我们尽量避免把数据分析的工作放在事后。威胁管理体系总体结构图如下：

我们简单展开一下每个层面的建设思路。

3.1 数据

数据采集方面，现在有很多开源工具可以实现企业的绝大部分需求，这里不再赘述。在数据选择方面，笔者经常能看到的是两种方式①通过数据找需求，②通过需求找数据。笔者建议采用方法②能有效减少系统设计过程中的盲点。所以，虽然我们把数据放在第一个讲，但我们实际工作经常是先明确分析场景，再去寻找相关数据，如果数据无法获得，在回头调整分析场景。

3.2 策略集

这是整个系统最重要的部分。这里说的策略是对数据的分析逻辑，而策略集就是大量逻辑的组合。对于策略集的建设笔者团队采用了与安全厂商联合开发的方式，原因有二：

① 商业产品没办法解决所有问题，采用商业产品做安全检测是很多企业的选择，任何产品都有它的劣势。但这还不是最重要的，笔者认为企业的安全需求是千差万别的，而且攻防双方的手段更是不断变化。商业产品出于通用性的考虑，分析策略不太可能非常全面，另一方面对于新的攻击手段，很多商业产品也不支持深度定制，或者深度定制的成本非常高。

② 我们的团队规模和能力都无法支持全面的自主研发。相信国内大部分企业都没有能力全面研发一款产品（那些行业内的头部企业不在讨论范围内，他们不仅能自研还能输出），从另一个角度来说，企业需要的也不是一个完全自主可控的安全产品，而是解决实际问题。

我们对整体策略集的开发采用了“快速及格、逐步提高”的建设思路。

所谓“快速及格”，就是通过购买商业产品或者与商业公司联合开发的方式，快速的建设一套标准的威胁检测系统。如果采用商业产品需要对产品的开放性和集成能力有全面的了解，否则后期基于这套系统做集成就会变的非常困难。有了这套系统仅仅达到了一个及格线，要达到最终目的就需要“逐步提高”来实现。

顾名思义，逐步提高是一个长期的过程，从笔者的经验来看，这个过程是企业安全从及格到优秀的重要过程。我们通过两种方式实现“逐步提高”：

不浪费任何一次应急：笔者曾经在以前的文章中提出过一个“体系化应急”的思路（具体内容点击这里），总体思路就是通过应急事件发现问题，经过相应的安全建设后保证安全事件0复发。这个思路我们最早的应用就是在威胁感知策略集完善的工作中。在基础检测策略ready的情况下，入侵事件悄无声息的发生意味着什么？当然是系统检测能力存在缺陷，明确了这个缺陷就意味着我们的系统检能力有提升的空间，而通过完善基础数据和策略集的分析手段就可以避免同样事件再次发生。

安全服务落地：很多企业都会购买不同类型的安全服务。笔者团队早年间采购安全数据分析服务的时候，采用的是人直接分析数据的方式，我们每天安全数据大概在450万条左右，现在看可以确定人肉分析的方式是肯定无法完成工作的。从“策略集”建设思路确定开始，安全分析人员的工作有了一个转变——由分析数据到制定分析策略，这些策略由一个小型开发团队变成工具，后面的数据分析工作如下图，这是个重要的改变。

分析策略开发流程

分析策略运行及优化流程

在上述两个流程中，只有标红的两个环节——“制定分析策略”以及“关键结果校验”需要安全服务团队介入，其他环节完全由企业安全团队把控。安全服务的可控性更强。另外，就算安全服务因为任何原因重点，安全分析工作也不至于停滞，最多是不能更新而已。

最后说明一下，由于我们选择的是联合开发的方式，所以通过通过安全服务的策略集开发是在基础分析能力ready的基础上进行的。

3.3 展示

展示这里不准备多说方法，有了丰富的分析策略，相信展示大屏的设计就不是什么问题，但是根据笔者经验，UI的设计根据使用人群的不同，一般要分2-3个层面。针对不同人群的设计思路会有些不同，我们简单分析一下。

高层：能看懂，别炫技。很多高层领导都不是安全专业出身，甚至不是技术出身。所以，给高层看的展示内容一定要让人很容易看得懂。千万不能从技术角度炫技，这个层面需要展现哪些高层真正关心的内容。

中层：效率高，别造假。对于给平行部门间展示或通报的界面，主要是让相关人员快速、方便的了解必要的内容。同时，通报的数据一定要客观，造假和主管评判是大忌，不利于部门间的沟通。

基层：可定制，别复杂。给基层员工的界面，考虑到需求多种多样，而且基层员工普遍动手能力较强。美观程度并不重要，最好能方便的定制界面，让使用者很容易得到自己想要的内容。

3.4 联动

联动原则上不是威胁感知系统标准的能力模块，但没有“联动”，“感知”的意义就不存在了。就像去医院检查，发现医院只能发现病症，而不能治病，这是很荒唐的事。所以，在感知的基础上一定要有联动。而且，联动最终一定是自动化的（对于某些策略），策略自动化有至少有三个好处：

缩减封堵时间：在自动化封堵之前，笔者团队日常封堵恶意IP的间隔是24小时，这个封堵只能说聊胜于无，24小时的时间足够入侵者做任何事了。自动封堵上线之后，极端情况可以将封堵时间缩减到5分钟（理论上时间间隔可以无限缩小，但数据量太小不利于分析的准确性）。这可以极大的压缩入侵者的入侵事件。

避免误操作：就算每天人肉封IP是可行的，但是对防火墙和ACL的频繁操作会极大的增加误操作的可能性，影响整个系统的稳定性。自动封堵可以避免这个问题。

7*24小时工作：我们永远不知道入侵者什么时候会发起攻击，一个早9晚6的团队根本无法应对这种情况，就算996也不行。所以，我们需要一个永不休息的“机器人”帮我们做一些基础的工作。

当然，不是所有的问题都能够自动化处置。所以，定义好规则，在紧急时刻通过各种方式通知应急团队处置安全事件也是很重要的。

四、风险管理

笔者认为，风险管理绝不仅仅将资产、脆弱性和威胁单独管理这么简单。我们需要将这三个维度的数据充分关联，并形成最终的分析结果。这类关联场景分析理论上是无穷无尽的，我们需要根据实际情况设计场景并开发相关的分析策略。这是笔者团队正在着力解决的重要问题之一，我列举几个简单的场景，希望能抛砖引玉，给读者一些启发。

威胁评分：我们在设计威胁感知系统的初期（2015年），定义了一个威胁评分的机制。为了使这个评分更加准确，我们将外部攻击数据（IDS数据或其他类似数据）与内部资产和脆弱性数据相关联。如果某攻击IP的攻击类型与资产信息和脆弱性信息高度匹配，系统将大幅提高其威胁评分。这个方法很适合处理IDS这类“单向”数据，而目前有些产品可以更精确的定位失陷主机。这种方法处理的优势是可以在主机真正失陷前分析出更具威胁的行为，将处置时间提前。

另类失陷主机判断：这是个更简单的逻辑，仅需要在“攻击者”IP表中找到自己的IP地址，这个IP有很大概率已经失陷。这仅仅是将企业IP地址段做了一个匹配而已。在企业没有专业失陷主机检测能力的情况下，这种方法可以有效的弥补产品能力的不足。

0day漏洞处置：0day漏洞爆发后，通过资产信息匹配就可以快速判断网内的影响范围，有助于快速制定应急处置方案。另外，如果漏洞还没有有效的处置方法，而且业务无法下线。可以通过威胁管理系统，重点分析外部IP的漏洞影响资产的访问情况，制定应急封堵措施，快速封堵恶意访问IP。

上述三个分析方法都很简单，主要用途也仅仅是抛砖引玉。但笔者认为这些方法“高级”的地方在于没有局限于某一个维度的数据和分析能力，而是用很简单、低成本的方式一定程度的解决企业面临的安全风险。

本文是笔者团队对于风险的管理在技术上的一些手段和方法，文章中列举的手段不一定通用 ，希望能给读者带来一些启发。

*FreeBuf官方报道，未经许可禁止转载