浅谈企业级供应链投毒应急安全能力建设

'''在此之前写了不少企业安全建设实践方面的文章，那建设的效果怎么样呢？唯有在日常的工作场景中应用，通过实战的检验，才能做出判断。本文将通过介绍供应链投毒的应急响应流程，引入coa投毒的应急响应实例，并提取出常规企业安全建设所需的安全能力。'''

1 企业安全视角下的威胁情报

这里的威胁情报是从企业安全建设角度出发，主要包括漏洞预警、安全事件和供应链投毒。

• 漏洞预警：指软件、组件的0day及Nday的漏洞信息，通常关注名称、受影响版本、风险等级、修复方法、POC或EXP。通过订阅软件官方的更新、安全社区、安全媒介等渠道获取，与内部资产信息进行关联碰撞，评估受影响面及推动修复。
• 安全事件：指公司相关的安全漏洞被外部披露、数据被拖出来挂卖等事件，通过爬取暗网、Twitter、国外社区等获取，一旦发现很可能就是已经被攻击。
• 供应链投毒：指公司使用了植入后门等恶意代码的软件，导致可能会牵连遭受攻击。投毒点包括攻击软件开发工程师、代码仓库、开发环境、编译环境等整条从开发到使用环节的链路，较为典型的有phpstudy-2019、SolarWinds-2020、PyPI代码库恶意软件包-2021。

2 供应链投毒应急响应流程

针对重点关注的三类威胁情报，基本的应急流程都可归纳为：从情报收集 - -> 情报研判 - -> 情报处置 - -> 情报闭环四个流程。然而最不同就是处置部分，简要流程图如下：

本文仅针对供应链投毒应急响应展开讨论，通过对NPM官方仓库coa的恶意投毒案例应急，并分析需要用到哪些安全能力。（如上图蓝色部分）

2.1 收集情报

如何快速获取供应链投毒信息？比较常见的是通过爬虫或订阅方式，个人感觉比较及时和高效的则是高质量微信群、微信朋友圈，特别应该关注安全能力对外输出的公司。情报的来源是渠道，有价值的监控渠道可分为：官方渠道和安全媒介：

• 官方渠道：根据公司使用的软件、组件等基础设施而定。比如os层面的centos、Ubuntu、windows等及系统服务，虚拟化技术类软件，DB类，大数据开源组件类等。

• 安全媒介：主流的安全媒介及微信公众号，个人比较推荐TSRC和奇安信CERT，情报信息比较及时也比较全。除此之外还有一些也可以作为常态化关注：

2.2 情报研判

根据情报，关联资产，排查处置。不得不提到资产问题，基础问题始终绕不开，在此不作深入讨论。但有个比较现实的问题需要面对：受影响结果排查出来，如果范围很广怎么办？

• 资产分级先后排序：抓重点，两拳相害取其轻。将资产进行分级，可参考业务方对业务系统的定级，可以分为：互联网侧资产，内网重要资产和内部一般资产，应急的优先级也从左往后依次降低。在资源有限的情况下，面对每日新增的漏洞和情报，应该制定应急的优先级、范围和必要的操作动作进行支撑，也算是给应急同学一个保障。

2.3 情报处置

处置阶段的动作究竟包括哪些？主要依赖于情报本身包含的信息和企业自身安全能力，并把保障业务放在首位。

• 边界阻断及时止损：通常的做法是在安全设备上进行IOC阻断、IP封禁等操作，也有人称热补丁堵住漏洞或者攻击。前者倒是可以做，后面的做法有待考虑。但及时止损肯定是正确的做法，可执行的动作也比较多，具体需要结合实际情况和场景进行判断。
• 常见情报处置动作：如响应流程图中所示，处置动作可以包括资产查询判断影响范围、边界阻断、NTA拉黑名单创建告警规则、受影响业务加固追踪、整改项验证等内容。其中部分场景可以做成SOAR，实现（半）自动化流程。故在日常的安全运营工作中，应该有意储备这方面能力，为应急止损或消除风险争取时间。

2.4 情报闭环

从响应到内部整改完成，甚至到外部PR（如sonar未授权api问题，某行业要求供应链厂商自查后给出纸质说明）等结束，说明情报已经处理完毕。接下来还可以做两方面的事情，以达到不断自我提升的效果：

• 总结沉淀：记录情报处置的前因后果，并进行归档。无论是对事件处理者，还是对后续入职的人员，都是一份值得学习的参考资料，同时也是团队知识和能力的沉淀。
• 反思复盘：按照情报的处理流程，进行演练复盘。流程是否通畅？有不足或不顺的地方，需要完善与优化；执行某一动作时，是否耗时太长？能够自动化的，需要尽快上SOAR，不能自动化的需要写SOP；是否暴露出其他安全建设的薄弱点？未能覆盖的，需要进行安全建设规划并举一反三发现其他薄弱环节。

3 coa供应链投毒背景简介

coa是 Command-Option-Argument 的缩写，Node.js 项目的命令行选项解析器，已经3年没有进行版本更新。攻击者通过发布新版本并植入恶意ioc进行投毒，并频繁发布了五个版本，但官方很快就对这些版本进行下架。依赖coa的组件或框架应该由于时间短暂而影响不大，不过“同一时间”同步npm官方仓库的镜像站可能会受到影响。

3.1 最开始无IOC的情报

首先看到的信息来自www.bleepingcomputer.com，在11-04发布了文章《Popular 'coa' NPM library hijacked to steal user passwords》，描述coa被污染的版本包括：2.0.3、2.0.4、2.1.1、2.1.3和3.1.3。

3.2 含IOC及分析的情报

随后在11-05，腾讯安全应急响应中心发布《安全通知 | NPM官方仓库遭遇coa等恶意包投毒攻击》，详细进行了事件描述和简要分析，并补充了受影响版本、平台和IOC：

通过这篇文章，一般企业也能够根据提供的信息进行应急响应。不过有些细节还是需要注意，比如：没有详细说明coa被投毒的时间，不太好确定排查IOC访问记录的时间区间；没有分析前端框架react的受影响版本；没有说明是否还有其他组件依赖coa而导致受影响…（BTY，不得不佩服并感谢大厂的自身安全能力及对外输出。）

4 coa供应链投毒实战应急

先排除自动化程度不说，关注企业在面对供应链投毒时能做的动作，终究还是受现有的安全能力所限制。

4.1 初级水平

关键词：人肉排查 出口阻断

• 出口阻断：在获知IOC的情况下才能操作，须对公司出口进行（统）管控为前提。就一般企业而言，很难有能力分析出IOC，就只能等大厂进行分享。封禁IOC，一般也是通过在防火墙或交换机上做ACL实现，但是交换机上的ACL条数有限且较难管理，须提前规划。
• 人肉排查：主要以人员询问的方式，没有很有力的工具支撑。效果往往取决于责任心，往往花费了时间和精力，效果甚少。即使是没凑效的招，在询问时也需要针对潜在的目标人选，如本次coa是前端相关，直接找前端负责人沟通，请其在团队内部排查并给反馈，可提升排查效率。

4.2 进阶水平

关键词：指哪儿打哪儿式软件排查 终端中毒情况排查 出口阻断

• 指哪儿打哪儿式软件排查：根据公布的受影响组件及版本信息，使用公司内部的SCA工具进行排查，包括coa、rc、react。疑问点在于react，究竟是那个版本受影响？

为了准确判断，访问react官方更新日志，最新版本V17.0.2在今年03-22发布，时间上来看在coa的IOC访问时间（11-03）之前很久。出于严谨性考虑，下载最新版本进行分析，确认引用了coa三个版本，均不受影响。

• 终端中毒情况排查：根据公布的IOC，借助公司edr和sysmon对员工终端进行访问记录排查。范围是有了，但是时间呢？参照IOC开始有请求的时间11-04来进行查看。结果取决于终端的覆盖率和日志传递及解析全路径的有效性，当前没发现有访问记录，但为了确保万无一失，也将IOC同步到覆盖率更高的NTA设备上，并设置检测和告警规则。

4.3 高阶水平

关键词：横向软件及依赖排查 终端中毒情况排查 出口阻断

【Q：只关注以上两个引用coa开源组件就够了吗？】

• 横向软件及依赖排查：答案无疑是不够的，若已经通过sca工具进行全面扫描与检查，则可以稍微安心。基础安全工作做得好的情况，会将开源组件当做安全资产进行管理，以应对应急事务。

5 从结果反推企业安全建设能力

【Q：要想做好供应链投毒的应急，需要储备哪些安全能力？】

每一个安全应急响应的操作，都映射着一种安全能力。故针对此次coa投毒的应急响应，分析企业需要哪些安全能力以应对投毒场景？

5.1 安全能力投射图

每一个环节都会涉及到安全工程师，人力毫无疑问是第一生产力。此外，追根溯源还是企业的基础安全建设能力，包括：

• 边界安全防护能力：较为理想情况下，边界防火墙管住对外的业务，只需要对其ACL策略进行运营即可。当遇到供应链投毒的场景，直接在出口禁止对IOC的双向访问。但是实际场景中也存在防火墙管不了的情况，这取决于业务形态、网络位置、防火墙覆盖率等多种因素。统一原则就是尽可能的在出口进行把关，无论是业务系统还是办公网。
• 终端安全能力：指终端上的监控工具或管控软件，比如微软的sysmon或安全厂商的edr产品，对终端日志进行采集及分析。在遇到针对开源组件库进行供应链投毒攻击时，重点考虑研发团队终端访问IOC情况。排查时应注意时间范围，关注的日志一定是要在供应链投毒攻击之前，而不是现在。
• 软件成分分析能力：目前主要有源代码扫描和二进制文件扫描两种方式，源码层面可以读取程序的配置文件信息，比如JAVA的maven文件，最佳嵌入环节在CI过程中，有开源的工具如OWASP DEPENDENCY CHECK，也有不少成熟的商业产品；针对二进制文件扫描，本质就是拆解编译好的文件进行分析，拆解的颗粒度可以到协议、库文件等。另外这两种扫描也可以在同一个场景中进行互补使用 - - 外购软件安全管理，若能够获取源代码，可以直接进行源码层面检测；若供应商不提供源代码，可以使用源码检测客户端工具进行特征采集，再导入源码检测工具中与漏洞库进行识别碰撞出已知CVE漏洞；若供应商不提供源代码，还可以直接使用二进制检测工具进行扫描，从而评估其在开源组件方面的安全性。
• 软件成分资产库：软件成分分析的工程化能力体现，开源组件种类的全面性和准确性依赖于SCA工具的检测能力和覆盖面。比如公司整体业务都走cicd的话，把工具嵌入CI流程中实现自动化是较为高效的。很多业务都还在谈论ip、port、service、process等这些常规的安全资产，不过随着供应链攻击在实战中的频繁出现、国家相关部门的进一步要求，想必开源组件将作为安全资产之一，加入常规安全运营工作。最佳的状态是能通过 “组件-版本”关联到公司的“产品-版本”，通过检索“产品-版本”能够获取该产品中的所有“组件-版本”，这在应急响应场景中十分重要。

5.2 单项能力深广度

指企业安全建设能力在专业方向上的强弱度和覆盖度，即深度为强弱度、广度对应覆盖度。如果说把企业的单项安全能力比作一个二维平面，那么强弱度就可以代表长、覆盖度表示宽，二者的乘积就表示该方向上的安全能力。但是每个度又不是单纯的因子，受影响的因素也比较多。

此处以软件成分分析能力举例，企业对开源组件的安全管理程度主要取决于安全产品能力和应用实践能力，大致关系如下：

• 安全产品能力（深度）： SCA工具对于软件中的依赖包、依赖包中的依赖包、程序动态执行时拉取的组件库的检测能力等属于深度（强弱度）；
• 安全产品能力（广度）：SCA工具对语言的覆盖度，比如不支持C语言但是公司内部有用到，则属于广度（覆盖度）；
• 应用实践能力（广度）：说直白一点就是落地能力，每个公司的现状不一样、遇到的棘手问题也不一样，及时具备相同的安全产品能力取得的效果也会有差异。基本上取决于基础安全设施，非安全团队的管控流程，安全团队及人员能力等综合问题。