让安全团队列出组织拥有的每一项面向互联网的资产,你会得到一个自信但不完整的答案。这并非出于疏忽。外部攻击面持续变化,而这些变化几乎都不会经过安全团队的审批流程。
市场部搭建了一个活动子域名。某个团队上线了一个预发布环境后就遗忘了它。一次收购带来了从未被清点过的基础设施。某个云服务默认生成了一个公开端点。某个供应商在你三年前委托的子域名上托管了内容。这些都不会产生一张工单。
外部攻击面监控是持续发现和评估实际可从互联网访问的内容的实践,而不是依据资产登记表上应该存在的内容。
攻击面监控涵盖的内容
外部攻击面是外部人员无需凭证即可访问的所有内容:域名和子域名、IP 范围及其上监听的服务、云存储端点、暴露的管理面板和仪表盘、API 端点、证书、DNS 记录,以及以你的名义运行的第三方服务。
有三个特性使其成为一个监控问题而非审计问题。
它在没有通知的情况下发生变化。 从资产出现到安全团队中有人知晓之间的间隔,就是最重要的窗口期,而季度审查会使这个窗口期长达一整个季度。
它超出了你所配置的范围。 委托出去的子域名、供应商托管的服务和收购来的基础设施都是你攻击面的一部分,但通常不会出现在你的资产清单中。
值得关注的资产往往是被遗忘的资产。 一个维护中的生产服务会被打补丁并被监控。而两年前上线的某个项目的预发布服务器则两者都没有,但它却处于同一个攻击面上。
重要的发现来源
发现工作主要是针对公开来源的收集问题,而没有任何单一来源是足够的。
证书透明度日志。 每一个受公开信任的证书都会被记录下来,这使得 CT 成为最可靠的子域名发现来源。它能找到没有人主动宣传的主机,包括那些从未打算公开却听起来像是内部使用的名称。
被动 DNS 和 DNS 枚举。 历史和当前的解析数据,可以揭示那些不再出现在你的区域文件中但仍能在某处解析的主机。
注册机构和 WHOIS。 域名所有权和注册数据,有助于找到多年前收购或防御性注册但从未被清点过的域名。
ASN 和 IP 范围数据。 归属于你组织的地址空间,这是攻击面网络侧的锚点。
云服务商范围。 你账户中的公开端点,这通常是攻击面增长最快的部分。
公开的代码和软件包仓库。 不是为了寻找机密信息(那是另一门独立的学科),而是因为仓库中会引用主机名、端点和基础设施,这些信息是发现工作可能会遗漏的。
招聘信息和公开的技术内容。 招聘列表会详细列出技术栈。这是关于你自身足迹的合法开源情报,同时也是攻击者最先阅读的内容。
这些方法背后的 OSINT 收集方法在用于威胁情报和 OSINT 的住宅代理中有所涉及。
你自己的网络看到的是一个更友好的互联网
这部分内容常让团队感到意外,也是认真对待观测视角这一点最有力的论据。
从公司出口扫描你自己的攻击面,会产生一个系统性偏乐观的画面,因为你自己的地址通常已被列入白名单。WAF 规则会豁免它们。地理限制不适用于它们。速率限制对它们放宽。预发布环境对办公室网段是开放的。一个针对公司 IP 设置了防火墙的资源,从内部看是可访问且正常的,但从其他任何地方看都是不可见的,而这恰恰是你试图测量的那个区别。
反过来的情况也会发生。一个本应是内部使用的服务,由于规则范围设置错误而从外部可访问,而你永远不会从一个被该规则豁免的观测点看到这一点。
地理位置会加剧这个问题。CDN 和 WAF 配置通常因地区而异,一个服务可能在某个地理位置暴露,而在另一个地理位置被阻止。一个在多个市场拥有客户的组织,在每个市场都有各自的攻击面,而从一个国家进行观测只能报告一个国家的攻击面。
使用你关心地区的住宅出口,意味着能够像普通外部人员一样观测你自己的攻击面。使用 Shifter 网关时,观测点在凭证中针对 p.shifter.io:443 设置:
customer-USERNAME-country-de-sid-easm-de-04-ttl-600:PASSWORDcountry-de 设置观测点,sid-easm-de-04 在一次扫描过程中保持一个出口不变,从而使结果可归因于单一观测点,而不是混杂多个观测点的结果。保持请求速率适中,并在出错时进行退避,详见速率限制和请求限流。产品视图见网络安全和 OSINT 代理页面。
保持在授权边界之内
攻击面监控是对你拥有或经合同授权可以评估的资产的观测。这个边界需要明确、书面记录,并且要比你的好奇心更窄。
监控,而非利用。 发现和识别是一项活动。探测漏洞以确认其存在是另一项活动,它属于一个有范围限定、经过授权的测试,并有其自己的协议。
获取书面授权,包括针对子公司和供应商的授权。 看起来属于你的资产可能是由第三方在不允许你测试的条款下运营的。
在被动方法可行的地方保持收集的被动性。 证书透明度、被动 DNS 和注册数据完全不需要与资产进行交互,而它们能找到大部分重要的内容。
与法务部门以及你自己的检测团队进行协调。 监控没有人被告知过的流量会浪费一次事件响应周期,而且是反复浪费。
持续意味着差异比对,而非重新扫描
攻击面监控的产出不是一份资产清单。它是相对于已知基线的一系列变化流,因为清单太庞大以至于无法逐条审查,而变化才是携带风险的部分。
维护一个资产基线,每项资产记录:首次发现时间、最后发现时间、解析地址、开放服务、证书详情及签发者、托管服务商、观测到的地理位置,以及所属团队。然后针对状态转变而非状态本身发出警报:
| 变化 | 为何重要 |
|---|---|
| 出现新主机 | 有东西被部署了,而安全团队并不知情 |
| 服务变为可访问 | 某个端口或端点被打开,无论是有意还是无意 |
| 证书即将过期,或由意外的签发者新签发 | 过期会导致服务中断;意外签发可能表明发生了劫持 |
| DNS 记录指向新的位置 | 包括指向已停用的服务商,这是典型的子域名劫持设置 |
| 主机停止解析而 DNS 记录仍然存在 | 攻击者可以声明所有权的悬空记录 |
| 技术指纹发生变化 | 某个组件被替换,或出现了已知存在漏洞的版本 |
悬空记录值得特别关注。一个指向已不存在的云资源的 CNAME 记录不是一个表面问题,因为接下来任何能够注册该资源的人都会继承你的子域名。
节奏应该跟随风险。证书透明度接近实时,值得持续消费。每周进行一次完整枚举通常就足够了。关键资产则需要更快的循环周期。
让发现的问题有人负责,否则什么都不会被修复
一个成熟监控项目的失败模式,是拥有一份庞大而准确的清单,却没有人对其采取行动。
每项资产都需要在发现时(而非事件发生时)就记录一个负责团队。发现的问题需要一个反映暴露程度和资产关键性的严重性模型,而不仅仅是扫描器给出的分数。同时还需要有一条途径,让无人认领的资产变成某个人的问题,因为无人认领的资产正是会演变成事件的那些。
追踪那个反映真实风险的指标:资产出现在互联网上的时间与出现在你清单中的时间之间的间隔。缩短这个数字才是这个项目存在的意义。
常见问题
这与漏洞扫描有什么不同?
漏洞扫描评估你已经知道的资产。攻击面监控找到你不知道的那些资产,这就是为什么它要先行且持续运行。
如果我们已经从自己的基础设施进行扫描,还需要外部观测点吗?
需要,因为你的基础设施通常已被列入白名单,并被豁免于你试图验证的那些控制措施。从内部扫描测量到的是一个比你的攻击者所看到的更友好的互联网。
证书透明度本身就足够了吗?
它是单一最富有成效的来源,但并不足够。它会遗漏那些从未获得公开证书的主机,并且对哪些服务实际在监听没有任何说明。
我们如何处理属于某次收购的资产?
将该次收购视为一个新的攻击面,并明确针对它运行发现流程,而不是假设其清单是准确的。收购来的基础设施始终是一个组织足迹中记录最不完整的部分。
结论
你无法防御一个你不知道其存在的资产,而登记表总会滞后于现实。持续的外部攻击面监控通过从不被你自己的控制措施豁免的观测点发现实际可访问的内容,并针对变化而非重述清单发出警报,从而弥合这一差距。
从多个公开来源进行发现,从你的用户所在的地区进行观测,将收集工作保持在书面授权边界之内,与基线进行差异比对,并为每项资产指定一个负责人。收集层的费率见定价页面。