写在前面

如果将大中型企业的信息安全比作一座城池，那么，外部攻击者相当于城外汹涌而来，四面围困的『十万大军』，企业安全团队的安全建设工作就相当于要在这个城墙参差不齐且四处是豁口的大城外构筑一条防线，将这些攻击者牢牢挡在门外。
但是，外部攻击者数量庞大，源源不绝，只要找到一处薄弱点，就可长驱直入，而安全团队人力捉襟见肘，不仅要将防线建设的「滴水不漏」，还要时刻注意「内鬼」、「间谍」，这从一开始就是一场不对等的对抗。
面对这样的态势，防守方应该如何着手呢？借用军事理论的思想，在战略上，相对弱势的防守方应该集中力量，争取在每一个局部占据绝对优势，保证每一个具体战役的胜利。

这样，在全体上，我们是劣势（就数量来说），但在每一个局部上，在每一个具体战役上，我们是绝对的优势，这就保证了战役的胜利。随着时间的推移，我们就将在全体上转变为优势，直到歼灭一切敌人。
——《十大军事原则》

那么，具体到企业安全建设，应该怎样取得局部优势呢？
不难想到，对于企业安全团队，他们最大的优势是内部信息的透明。身处企业内部，能方便地知道总共有哪些域名，知道每个应用有哪些接口，分别对应了什么参数，知道所有的机器上都跑着什么进程，开放了什么端口服务，知道中间件、研发框架、三方依赖的具体情况等等，基于这样的信息差，企业安全可以将自己处于劣势的总人力用来提升最薄弱的地方。
但是，「能方便地知道」不代表已经知道，「信息透明」不代表获取到了信息。获取信息、消化信息，构建局部优势，打造企业安全「全局视野」，也是一个浩大的工程。本文将从这一主题入手，以「全局视野」为目标，理一理各类安全能力的演进思路。

两个前提

在整理思路之前，有两个前提需要先明确下来，以作为后续推导的基础。

安全风险依附于资产而存在

安全风险都会有它影响的实体，这个实体往往会指向资产。此处的资产不仅仅局限于以往运维角度的资产，如服务器、域名等等，也会包括用户数据、服务器信息等广义的资产。所以，只有资产信息足够全，足够准，才能更好地发现潜在风险。

变更容易引发风险

风险从无到有会经历一个变动的过程，而风险又往往依附于资产而存在，所以这个变动会大概率对应在一次资产相关的变更上，比如应用迭代、扩缩容、回滚等等，但不表示全部都是由变更引起的。

建设思路

确定了两个前提，那么后续的建设思路也清晰起来，即

• 全面、准确收集资产信息
• 及时感知变更

安全资产

资产是个老生常谈的问题，它代表着一家公司在互联网的汪洋大海中的准确坐标，也是外部攻击者在日常着重积累的重要信息分类。

数据范围

首先来看数据收集的范围，传统定义中的资产主要包括域名、IP、虚拟机、容器、物理机、LB、DB、代码库等，这也是外部攻击者重点关注的部分，用于寻找公网敞口，伺机进入内网。这部分数据甲方有着天然的优势，在公司发展过程中，对应的管理系统一直在不断使用和演进。虽然随着时间的推移，技术架构必然会发生转变，上游的各类原始数据源不可避免地会存在重叠、遗漏和错误，但至少还有原始数据，抽象出一个清洗和计算的中间逻辑层之后，可以产出一份初步的结果，通过持续地迭代优化清洗计算的质量，可以满足绝大部分的需要。
但资产数据只做到这个粒度是不能支持「全局视野」的目标的，打个比方，一个攻击者已经收集到了某公司的一批域名和公网IP，他并不能立即停止信息收集工作进入实质的漏洞挖掘阶段，而是要进一步探测域名后的各种接口、IP开放的端口服务等等。同理，对于甲方来讲，只有域名、IP级别的粒度，对于日常查询和安全运营可能足够使用，但对于更好地发现风险，还是像一个高度近视的人一样模糊，只有更进一步地细化资产数据的粒度，才能给近视的人戴上眼镜。
那么，安全资产的粒度应该细化到什么程度呢？我认为应该到「可以直接进入实质漏洞挖掘阶段」的程度。例如，知道某IP的某端口开放了Redis服务，下一步即可直接测试是否存在未授权访问等问题；知道某接口地址和对应的请求参数、认证条件、功能场景，可以直接测试对应场景下是否存在漏洞（如看到富文本编辑可测试XSS等）。这些东西在原本正常的安全测试流程中，大部分也是通过各类自动化工具收集而来（如Nmap扫端口，爬虫爬页面接口等），对甲方理应在日常的安全建设中逐步积累完善。如域名IP相关的Web应用或RPC服务，需要细化到有哪些接口地址、需要什么请求参数、权限认证采用哪一种体系、提供了什么功能（如文件上传、Groovy脚本、富文本编辑等）；虚拟机、容器需要细化到有哪些常驻进程、开放端口、有什么系统软件包（RPM、DEB等）、业务进程相关的依赖（如Java应用的Jar包，Python应用的pip包等）。
这部分的数据与域名、IP粒度的数据不同，很可能并没有原始数据可以参考，只能依赖自建。Web应用可以从原始的流量数据里清洗，得到域名+接口+请求参数，再根据请求包响应包中的一些特征，提取出对应的功能场景和可能存在的风险；虚拟机、容器可以依赖运维通道，下发一些信息采集任务获取机器内部的进程、端口等信息。通过这些手段，得到一份能供安全工程师参考，无需再手工收集的细粒度资产信息。

数据质量

接下来看数据质量，资产数据要做到可靠，必须保证全面和准确。但现实情况是，资产强依赖了很大一部分上游运维系统的数据，原始数据从总体上可能较全面，但准确不足，我们只能通过清洗和计算变得相对准确。
那么意外情况如何规避呢，如果有些资产上游数据源里都没有怎么办？可以从攻击者的视角，收集一个相对大范围的目标列表（比如一级域名xxx.com，B段/C段IP等），通过一些扫描、枚举的方式得到一份数据，再将资产数据与之碰撞，提前检验是否会有意外情况。因为一旦有真实入侵事件发生，攻击者大概率也会用类似的手段收集信息，当我们已经对这种情况做了预判处理时，前述的「意外情况」被恶意利用的概率会大大降低。

关联资产

最后看关联资产，前面提到的资产范围都属于日常运维中关注较多的部分，如域名、IP，及由这些数据细化后的部分。随着业务的不断发展，技术形态的日益多元，一些之前没有投入很多精力关注的产品逐渐变得重要起来。
如数据存储类的各种大数据计算集群（如Hadoop、Spark及其他流/批处理），机器学习相关的GPU集群等，虽然在底层硬件资源上，依然是物理机、虚拟机、容器那一套，但从安全角度来看，前面提到的细化资产的方法已经不再适用，因为这些业务在流量上可能完全体现不出来它的细节，在机器内部也看不到可疑暴露的端口服务，而真正的攻击敞口存在于应用内或应用间的数据流转过程中，例如公网一处Web服务记录了用户提交的数据，由大数据集群中的流处理任务对这些用户数据进行分析，当流处理任务调用了低版本的fastjson，攻击者本来只是想对公网Web应用做下测试，却最终打下了后台的计算集群，更危险地是，各类防护措施往往会优先照顾暴露在公网的业务，后台应用防护水位缺失，这种攻击路径的破坏性可能更大。
「安全风险依附于资产而存在」，这是前文所述的前提之一，在这种新形态下也不例外。虽然新形态业务的风险评估一直是个难题，但落在安全资产的角度上，可以着重加强代码库、镜像/基线、供应链相关的收集能力，毕竟最终风险落下去的实体，大概率还是会出在研发的代码、镜像/基线中的各类软件、供应链中的各种依赖中。

变更感知

「变更感知」中的变更，一方面指应用对应资产信息的变更，例如Web接口、机器开放端口的新增、删除等，这部分由于和新应用上线的表现类似，即使没有变更感知的能力，也能通过正常的资产收集的途径发现；另一方面，则是指资产信息内在的变化，最常见的，Web接口地址、参数均不变，内部逻辑出现了变化，理论上讲应该算作一个全新的接口，但如果没有强大的代码分析能力，安全工程师可能直到下次出现漏洞都不会知道这段代码被改过。
因此，变更感知应该深度结合SDL流程和白盒代码分析，将重点放在代码的变动如何反映在资产上，这样我们才能将存量业务的风险控制得更好。

总结

回顾过去的一些安全工作经历，很多具体的事都是一个个小点，是因为当时一些特例和形势作出的必要的「救火」措施，从整体来看感觉缺了一些能一以贯之的推导过程。本文摒除外部的威胁形势，整理过去零散的思考，以充分消化企业安全团队信息透明的优势为出发点，尝试推导出一个「全局视野」的建设思路。受限于工作经历和视野，还有很多不足之处，希望能多多交流。