从一个实践场景谈“从资产发现到风险监测”模式解决方案的应用 – 作者:shiftf2

一、前言

所谓“从资产发现到风险监测”模式的解决方案，是在广义的Web安全领域而言，指蕴含了“通过资产发现过程后，再基于资产数据做风险监测”这样一个基本过程的各种解决方案。比如市面上那些输入一个主域名后自动进行资产和漏洞发现的安全产品，都可以看作是此类。

个人印象里，类似“资产发现”、“风险感知”这类的概念在前几年里被提的比较多，大家那时候比较普遍地开始以工程化思维实践着这方面的工作。在甲方做安全运维的、在安全公司做产品和服务的、民间白帽子等，都以各自的方式或多或少地实践着“从资产发现到风险监测”模式的解决方案。本文主要谈谈在笔者经历过的一个场景中“从资产发现到风险监测”模式解决方案的实践应用。

二、一个实践场景

1. 背景介绍

我们作为安全服务提供商，客户为某政府单位的信息中心。该单位下属有十数个业务单位，各业务单位总共有上百个信息系统。这些信息的服务器都放置在中心机房，信息中心负有对其进行安全监管的职责。信息中心掌握机房网络的管理权限，但各服务器的管理权限由各自所属的业务单位掌握。

现在面临的问题是，因各种现实的原因，各业务单位对各自的信息系统缺乏基本管理更不谈安全管理。而信息中心也缺乏安全监测的机制，搞不清当前到底有哪些信息系统哪些开放服务，搞不清哪些信息系统存在安全风险，也不知道每天新出风安全漏洞里哪些会对我有影响哪些无影响。

针对上述情况，我们给客户设计了一个整体的解决方案，其中就确立了“从资产发现到风险监测”这样一条基本过程，即要基于实时可靠的资产数据去有条理地做风险监测工作。

本文所谓数据可靠，以熟知的端口数据举例来说：数据没什么遗漏，实际有100个开放端口找到了99个；数据有效率是足够高的，提供的100个开放端口中99个是有效的；数据是足够高精确的，100个开放端口对应的服务99个都识别对了；数据是足够稳定的，什么时候来取数据都是这么可靠的。

2. 基础逻辑构建

在实施工程之前，我们首先要在逻辑上保证“从资产发现到风险监测”这个过程在实践中的可行性。显然，这个过程会涉及到资产发现和风险监测这两个过程。二者作为独立过程已经有很多现实的可行经验存在，但这还不足以得出“从资产发现到风险监测”这个整体过程可行的结论。“从资产发现到风险监测”这个过程不是一次性或间断性的存在，是持续地存在。在一个持续过程中，怎么保证它总是可用的？在这个过程里风险监测依赖于资产发现过程的结果，那么首先要解决一个问题：怎么保证资产数据的可靠？

显然，风险监测过程需要的是一个长期综合的、经过加工和补充的资产数据。换言之，资产发现过程和风险监测过程二者不能直接衔接，中间需要一个“长期综合、加工补充”的过程来串联。从而，我们把“从资产发现到风险监测”这个过程从逻辑上划分为资产发现、资产管理(串联过程）、风险监测三个过程。

资产管理过程中的资产数据存放我们称之为归档区，自动化资产发现的结果由审核机制后进入资产数据归档区，资产数据归档区的数据由失效监控机制剔除归档区，失效机制的依据是资产长期状态而非当前状态，于是归档区便保证了资产数据的质量。

现在，我们有了在项目里实践“从资产发现到风险监测”这个过程的基础逻辑架构了。

3. 一些“高层设计”

我在内部会用到“高层设计”这个概念，最初也是从别处看到的这个词，挺符合我想表达的那种感觉，就拿来用了。我们做一个事的核心目的与具体的实施内容这两端之间总是有串联的逻辑，我所谓高层设计就是指这些串联逻辑中比较关键的以及更靠近核心目的一端的内容。简单来说，可以认为就是那些我们在事前考虑的比较多的东西，好比我们要买房子首先会考虑需要的户型、能承当的首付额度、月供能力等，这些就是我们做买房子这个事的高层约束。由于这些内容约束着落地但本身不是事情的落地，所以说高层。

在基础逻辑之上，我们需要做一些一高层设计，对整个实施过程建立一些高层的逻辑约束，对实施过程中一些关键的问题制定解决方案。从而能基本确保整个过程在项目实践中是可行的且是能满足我们实际需要的。

资产发现过程使用白盒+黑盒模式   

白盒指我们能以获取网络设备配置、侦听网络流量等方式进行资产发现。黑盒指我们通过外部盲目、暴力、猜解等方式进行资产发现。以端口扫描来举例，我们可以对所有IP的所有/常用端口进行扫描来发现开放端口，这叫黑盒模式。我们也可以获得出口防火墙的NAT映射表来对指定IP和端口进行探测，这叫白盒模式。黑盒或白盒任一模式单独运行都要能提供比较可靠的资产数据，常态下我们使用白+黑模式以提供高质量的资产发现结果。

为什么需要任一模式单独运行也能提供比较可靠的资产数据，对于白盒模式，一是我们不能获得足够的白盒资源，再者很多白盒资源我们不能自动化、实时化调用，这些不只是单纯的技术问题。而黑盒模式，无法保证其能长期持续地提供可靠数据。所以有两种模式可用，才能最大程度保证我们的服务不会中断。

以IP地址作为资产数据的根键   

资产发现过程一是需要有一个资产根键，其可以关联所有资产信息，正如市面上很多类似产品使用主域名作串联一样；二是需要一个资产发掘的界线。而客户单位所有要监管的资产都在中心机房，其外网IP地址范围是确定的，在范围里的都是客户的资产，不在范围里的都不是客户资产，正好满足了这两个要求。

端口数据和Web应用系统数据是两项关键数据   

端口数据指以开放端口、对应服务及一些其它属性构成的开放端口列表数据集，端口数据为什么是关键数据这个不必要阐述了。这里提供可靠的端口数据，这个是不难实现的。

Web应用系统数据指由Web应用系统的地址及一些相关属性构成的Web应用系统列表数据集。我们说的安全监测的主要便是指Web安全，而Web应用系统是Web安全的主体。不管端口扫描也好、服务识别也好、子域名挖掘也好，都有一个重要的目的就是寻找Web应用系统。所以Web应用系统列表是资产发现的一个核心目的，也是后续安全监测的主要输入数据。

要维持一个可靠的Web应用系统列表，这里面临两个实际问题：

1.去重问题，同一HTTP服务下有多个主机名(URL中的Host)指向同一个Web应用，如果不去重，会对后续工作产生很大干扰。

2.二级目录问题。客户单位半数以上的Web应用系统部署在二级目录，资产发现过程可以有效保障发现根目录的应用，但不能保障发现二级目录的应用。若不能保证二级目录应用的发现效率，整个过程便失去大半的核心意义。

去重的问题经过实际测试比较好解决，二级目录是更关键也是更棘手的问题。如果不存在二级目录的应用，那么以下这个技术过程：

IP地址–>端口扫描–>HTTP服务识别–>匹配子域名–>去重–>得到Web应用系统列表

每一步都有成熟的技术方案，那么从IP地址开始到得到Web应用列表整个过程便可工程化实现。而有了二级目录的问题，这个过程便被打断：

IP地址–>端口扫描–>HTTP服务识别–>匹配子域名–>去重-/->二级目录应用发现–>得到Web应用系统列表

实践证明通过“猜解（暴力+字典） + 流量监听 + 其它手段）”可以解决二级目录发现源问题，剩下便是构造从源中提取有效记录的算法并把整个过程工程化。

建立数据归档和失效机制   

我们在基本的逻辑架构里确立了资产管理环节，也就是说自动化程序产生的原始数据要加工进入归档区，通过归档区确保数据质量。归档机制和失效机制就归档区的新陈代谢机制。归档区的本质是用于综合多轮次数据结果、综合资产的多轮次状态、人为地较准数据。那么其能确保数据质量的前提是，资产数据在一个相对长的时期内来看，其抖动极小。以端口数据来说，试想如果今天开放的这100个端口，明天开放的是另100个端口，后天开放的又大不相同，那归档区就失去了意义。只有今天明天后天虽有所不同，但综合一段时间（一个月）的数据看，其变动都是在某120个端口范围内。那么归档区只要在这段时期维持了这120个端口，那数据质量便有保证。我们这里的场景中正是如此。

只有过程本身的东西是必要的   

这个就不是什么设计了，是我们去做这个事的一个基本策略，这里写出来是因为它非常关键。我们遵循这样的策略：只有构成“从资产发现到风险监测”这个过程本身的东西是必须实现的，对于这个过程附加的东西能顺手实现的去做，否则也不用管它。

所谓过程本身的东西和附加的东西，过程本身的东西即是构成过程的一部分，是实现过程本身必不可少的，过程附加的东西不属于此类。我们赶路是取经这个过程本身的事情，而把路边树上挂着的熊孩子放下来背他回家，这是附加的事情。现实里来自这种附加的东西的需求压力是非常大的，不排除这些阻力，我们的根本目的就很难实现。一些附加的东西，什么任务定制、资产风险权值、风险态势之类的，会把整个事情的很多过程耦合在一起，事情就大大地复杂了。

而基于这个策略，我们就可以把整体过程在工作上分离为三个环节：

1.资产管理环节，主要开发和运维一个实现资产管理逻辑的B/S系统，提供数据输入输出的接口；

2.资产发现环节，主要实现资产发现的系列任务脚本，和资产管理系统对接；

3.风险监测环节，执行我们熟知的风险监测层面的工作，不同的是，里面不再需要去做资产发现的工作，直接去资产管理平台调用就可以了。

而这些环节各自做好自己的工作后，我们所预期的实现“从资产发现到风险监测”过程这个事情也就成了。

4. 小结

前面谈到的那些逻辑和关键问题都说得通以后，便面临具体对这些过程的设计和实现。围绕资产发现、资产管理、风险监测各个环节，实现各环节自身的运行机制和各环节之间的衔接机制，执行相应的工作过程……这里面都是些具体的工程实施了，在技术上我们也没有什么创新或独到之处，都是些大家所熟知的东西，这些就没什么好谈的了。

从实际的成果来看，我们认为基本上取得了预期效果，后续的风险监测环节也变得非常清晰有序起来，针对性人工检测、自动化扫描、全量预警排查等各方面工作都可以说是做得相对到位且高效的，可以说这是一个相对成功的实践。

取得这个结果有两个关键前提：一是，相比笔者也经历过的一些其它场景，这个场景里客户的需求和网络环境都非常契合“从资产发现到风险监测”这一过程的应用，这也是我们为什么会制定这样的解决方案；二者，在实施过程中我们只需要关注核心过程，不需要考虑太多其它附加的东西，从而要实现的逻辑总的来说是比较简单的。

二、谈谈一些市面上的相关产品

注意：这里谈市面上的这类产品，一方面这是两年多以前对某几款此类产品的理解，我并不了解它们的现状（没有交流机会了）；另一方面这是基于我所面对的场景，必须要考虑到这些产品并非就是针对我所面对的场景来设计的。

最开始我们的考虑是使用已经成形的解决方案，也考察过几款市面上的几款产品，但最后都被认为不能满足实际需求而推翻。抛开其它层面的因素，回到“从资产发现到风险监测”这个过程本身，具体推翻的理由基本都能在高层设计这部分内容看到端倪，这里只谈一些主观感受：

1）从第一感觉来看，这些产品给我很强烈的感受就是攻击者视角，黑盒式思维。做这些产品多为初创的安全公司，多是以前从事渗透测试类岗位的工程师设计出来的。黑盒机制必然伴随低效、不可靠的问题，从一个全局的运维管理视角来看，黑盒机制只能作为PlanB使用，作为没有办法的办法、有办法的辅助办法存在。所以一个以黑盒机制作为主要机制的解决方案，必然难以满足运维管理角度的需求。

2）从基本逻辑架构上来看，它们都是一种“基于资产发现的风险监测解决方案”式设计，本质上以产出安全漏洞为核心。虽然一些产品能看到一些类似资产管理的操作功能，但并没有真正从逻辑上把资产管理的过程独立出来，而是和资产发现的过程耦合在一起。这样资产发现的结果缺少缓冲空间，没有留下足够的运维补充的空间。换言之，其不能保障“从资产发现到风险监测”这个过程中任一环节，对我们来说就成了鸡肋。

3）从产品的功能概念上来看，它们几乎都涉及到了“从资产发现到风险监测”的全过程各个层面，包括本身的和附加的。但这些涉及并没有真正解决这个层面的问题，是名而非实。在我看来现实里这个全过程是一个综合人、物、事的过程，这个过程不大可能够汇聚到一个产品中去。产品是被设定的东西，更适合处理一些单调的过程，换言之产品的视角应该是其中某些过程而非全过程。我想这些产品之所以这么设计，很多并非“从资产发现到风险监测”这个过程本身的逻辑所驱使，而是因为产品的销售需要，这就使得产品陷入了内在矛盾。

三、结语

经过这几年时间的实践，大家对“从资产发现到风险监测”这个过程实践都会有各自的沉淀。笔者本人来说，比较关注此类安全产品的现状，从设计到实际应用到市场形势等。针对某一个场景里实践这个过程，并不会有太大的问题，但要针对更普遍的场景设计一款成功的产品出来，则是一个挑战。本文也是希望能够抛砖引玉，有更多同仁能来谈谈“从资产发现到风险监测”这个话题。

*本文作者：shiftf2，转载请注明来自FreeBuf.COM

来源：freebuf.com 2018-08-08 10:00:17 by: shiftf2