简析企业供应链安全的风险挑战与管理实践

简析企业供应链安全的风险挑战与管理实践

　　正元造价软件,音乐渐弱软件,数夫软件供应链安全事件的频频爆发，使得供应链安全管理越来越被政府和企业重视。企业供应链中可能导致安全风险的因素非常复杂，如果没有良好的供应链安全管理和风险控制，由于供应链导致的安全风险会急剧增加，企业甚至难以了解攻击是如何发生，这样就难以避免和防范下一次类似的攻击。

　　与企业信息安全管理类似，供应链安全管理并不是纯粹的IT问题，而是人、流程和知识的综合因素。在供应链庞杂的环境中，需要从攻击者的角度进行安全防御建设。与传统的信息安全不同的是，供应链安全涉及到物理世界与信息世界的交互，两者之间并无间隙，且相互影响。

　　第三方数据泄露或数据聚合：供应商存储的客户数据泄露或供应商通过数据分析获取客户机密/秘密

　　除此之外，还包括企业自身在技术活动中引入的第三方技术，比如开发人员在编程中引用的第三方开源或商业组件、调用的SDK（Software Development Kit）、使用的开发工具或运维工具（IDE、IDE插件、数据库连接管理工具、服务器连接管理工具）等。

　　当下很多企业在从事诸如驻场服务、驻场咨询、现场交付等等活动的过程中，还会涉及到与供应商或供应商人员的身份认证、授权、权限管理以及数据分享的问题，比如企业在财务审计中需要将财报信息同步给事务所人员、安全公司驻场为企业提供渗透测试服务、供应商交付人员在企业办公场所进行产品交付、配置工作。

　　所以供应链安全本质上是企业管理自身管理范围之外的一系列相关企业、产品、技术、人员、流程，并期望相关企业和人员具备不低于企业自身安全水平的安全成熟度。

　　当前，每家企业都需要借助其他供应商的能力完善自身的生产能力，在选择供应商和进行采购活动之前，企业自身需要完善相关的供应商管理制度或机制。

　　根据ISO27002（信息安全控制实用规则），涉及到供应商安全的规范包括：

　　供应商关系的信息安全：供应商遵守的信息安全策略、供应商协议的安全问题、信息和通信技术供应链；

　　供应商关系的信息安全是指企业应当与供应商就供应产品或服务过程中，供应商人员应当遵守的最低安全要求和安全策略，确保供应商对于企业信息资产的访问是安全可控的，并明确双方合作中安全风险的处置原则和要求。供应商服务交付管理是为保障供应商的交付物保持一定的安全和质量水准，并确保交付变更不会带来新的安全风险。

　　根据SOC2（美国注册会计师协会开发的针对行业服务的审计标准）的合规要求，企业在供应商管理中需要具备：

　　在选择和评估供应商时，需要评估供应商的商务信息和技术能力，商务信息包括：法人、注册地、员工规模、注册资本、股权结构、融资信息、企业资质、过去三年工商变更信息或工商处罚信息，技术能力包括：安全资质、安全白皮书、安全实践描述（基础安全、数据安全、漏洞管理、人员管理等）、开发实践描述（开发团队、开发流程等）。

　　商务信息可以通过被动调查的方式从诸如天眼查、企查查获取供应商的相关信息，技术能力可以通过问卷调查的方式由供应商主动提供，调查的方式除供应商自述之外，还可要求提供相关的系统截图或代码截图证明相关的能力。

　　更进一步，可以在供应商的授权下，采用穿行测试、漏洞测试的方法，对于供应商系统进行安全审查和评估，范围包括安全合规、安全要求、安全设计、安全漏洞，确保供应商的提供的产品符合企业的安全要求。

　　供应商的配置管理和质量管理是怎样的，如何确保不会因配置导致安全风险，以及确保质量符合要求；

　　数据管理生命周期中数据采集、存储、使用、销毁是如何的，包括保护、加密、留存、销毁；

　　人员安全是如何实践的，包括人员背景审查和审计、关键岗位保密协议和能力验证等等；

　　在设定供应商的准入门槛，评估供应商符合要求之后，相关的供应商应当进入企业的供应商名单。在与供应商进行合同签约过程中，依然要考虑合同内容中的安全要求、责权信息，明确双方的义务与权利，以及SLA中的产品、服务等级、质量以及赔偿方式和赔偿内容。

　　供应链中相同的第三方产品或服务不应当只有当前已采购的，还应当维护一定量的备用供应商和后备产品服务。这需要企业在供应链管理中考虑以下三点：

　　供应链的安全风险等级：供应商提供的产品或服务在保密性、完整性、可用性方面对企业造成的风险级别；

　　在风险识别过程中，有很大的机会能够发现企业内部的重复采购或无效采购，尤其是没有统一的采购部门，或采购部门没有记录和管理采购内容的情况。在没有统一采购部门的情况下，安全部门可以和财务部门进行协作，安全部门的供应链风险评估结果与财务部门进行同步，前者把握风险关，后者把控资金关，避免无效采购或重复采购。

　　对于已经合作的供应商，企业应当每年进行一次供应商评估，定期评估可以让企业掌握供应商的企业风险和产品/服务风险，避免由于供应商风险造成的企业自身风险。定期评估的内容可参考上文供应商管理和采购部分的内容。

　　对于在产品使用和服务过程中出现的安全事件，企业应当进行验证、记录、反馈，并督促供应商整改，对于事件的严重等级按照风险进行划分，并基于供应商准入门槛以及合同中的要求评估是否继续采用该供应商的产品或服务。对于发生严重事件并影响到企业安全的供应商，或持续不符合供应要求的供应商，企业可以采用供应商降级或解约的方式将供应商从供应商名单中剔除。

　　质量不佳的供应商不仅无法维持企业供应链安全的质量和要求，而且会消耗企业大量的管理成本、运营成本与供应商进行反复沟通、整改、验证工作，最终的结果可能依然不符合要求，勉强的合作让企业的采购得不偿失。

　　第三方技术指的是围绕技术引用和实现的技术工具、接口和组件，由于更偏向技术应用，因此往往不在企业的采购清单和计划中，由部门或员工自行进行选择和使用。

　　技术工具在企业采购中属于小众需求，或不被企业重视的采购需求，在国内多数企业依靠员工自行解决相关的工具需要，除了供应链的安全风险，技术工具还会引起知识产权纠纷。对于技术工具带来的供应链风险和影响，常见的方案有三种：

　　企业通过采购终端管控系统来实现对于所有员工电脑终端的管理，需要在员工电脑端安装管控软件（员工无法自行卸载，需要管理员密码），管控系统通常还带有网络准入功能，与企业内部的员工账户体系打通可以实现电脑终端的身份认证，同时通过管理端可以检查、限制甚至操作电脑终端的软件运行情况，从而可以对员工使用的应用情况进行统一检查和管理。但该方案需要专门的岗位对终端管控系统进行管理和运营，人员的疏忽和运营的疏忽都会造成该方案形同虚设。

　　通过设立软件白名单库，结合企业内网的限制（无法从外网下载软件安装包），可以实现软件来源的限制，确保员工使用的软件都是来自白名单库。但白名单库中软件更新后，员工电脑的软件迟迟未更新同样会带来风险，因此也可以采取终端管控+软件白名单的方式，保障软件白名单库提供安全可靠的软件。

　　目前越来越多企业开始采用云桌面的方式来彻底解决终端工具风险的问题，即轻终端、重云端。企业员工通过身份验证访问云端桌面进行日常办公，包括研发工作，可以确保所有的软件在云端都是可控且安全的，但缺陷是会由于网络不稳定或网络延迟造成办公效率降低。

　　无论是企业自研的软件，还是采购的第三方软件或硬件，都可能会存在和需要调用第三方技术接口或使用第三方SDK的情况，由于接口或SDK可能是个人开发，或接口服务提供，因此很难对供应商进行评估和管理。因此，企业应当对于技术接口和SDK的调用进行梳理和安全评估，确保即便接口提供方出现的安全风险，也在企业可承受范围之内。对于不得不用的接口调用，可以通过网络边界的流量限制和流量监测确保接口不会被滥用。

　　开发过程中必不可少的会用到不同开发语言的组件或库，这些组件大多是由个人开发者开发并开源的，虽然方便了开发过程，加速了开发进度，但个人维护的组件常常因为种种原因无法及时更新或升级，以至于一旦被人发现存在某种漏洞，使用组件的企业便需要快速响应和处理。

　　因此SCA（Software Composition Analysis）工具应运而生，SCA是一类工具的统称，可以通过分析源代码识别其中引用的开源组件信息（名称、版本、校验值）、组件漏洞、开源协议等信息，从而帮助开发人员和安全人员快速对于企业代码中的开源风险进行识别。全面、清晰、深入地掌握软件成分和物料清单，有助于在出现新的安全漏洞时进行快速响应和排查。SCA工具从开发阶段到部署阶段都可以运用。

　　供应链安全问题是人、流程和知识的问题，而非纯粹的技术问题。在解决软件研发过程的供应链安全问题时，需要贴合SDLC（软件开发生命周期）考虑供应链安全风险。为此，Goolge提出了SLSA（Supply-chain Levels for Software Artifacts）框架，微软提出了SCIM（Supply Chain Integrity Model）框架以及CNCF（云原生计算基金会）的软件供应链最佳实践，三种框架都强调对于源代码、第三方依赖、构建系统、制品、发布、部署的安全性。

　　以SLSA框架为例，SLSA是一个标准清单和控制框架，用于缓解软件项目中的代码和软件包的供应链风险。SLSA框架从三个方面评估软件供应链的安全等级，分别是源码、构建和依赖，并可划分为4个级别：

　　Level 1：构建过程是完全脚本化或自动化，且能够基于结果识别来源源码；

　　Level 2：使用有身份认证能力的版本控制和托管服务，确保构建来源是可信的；

　　开发人员提交代码变更需要多因子身份认证（如用GPG签名commit）及提交时间戳，必须采用类似GitLab或GitHub的版本控制系统，确保能够跟踪每次变更、代码分支/标签/Ref或提交人；

　　每一个进入最终版本的提交都必须经过至少一个其他合格的审查员的评审，确保代码的正确性、安全性、需求吻合和代码质量等等；

　　构建流程应当是完全自动化的，且构建环境应该具有隔离性（构建过程不受其他构建影响）、封闭性（构建过程应包含所有依赖关系）、无参化（构建结果只受源代码影响）和短暂性（每次构建都在专门的容器或虚拟机中进行）。

　　不足的是，对于最终用户而言，虽然可以使用哈希值进行软件包来源校验，但无法确保软件包的构建来源是可靠的，仅仅通过校验哈希值无法解决这个问题。因此，构建安全的软件供应链构建流程便尤为重要。

　　英国国家网络安全中心（NCSC）提出了供应链安全管理准则，分为4个部分的12条：