400-888-8888

网站建设 APP开发 小程序

知识

分享你我感悟

您当前位置>首页 >> 知识 >> 软件开发

供应链安全|美NSA和CISA发布《软件供应链安全开发实践指南》译文

发表时间:2022-11-21 17:58:26

文章来源:火狐体育

浏览次数:0

  近日,美国国家安全局(NSA),NSA、网络安全和基础设施安全局 (CISA) 和国家情报总监办公室 (ODNI)联合发布《供应商软件供应链指南》,以解决国家关键基础设施面临的威胁。NSA认为网络攻击的目标是企业利用网络空间来侵入、禁用、或恶意控制计算环境或基础设施,破坏数据的完整性或窃取受控信息。NSA在通告中指出:软件供应链周期容易受到攻击,并面临潜在损害的风险。软件供应商可以在本次指南中获得指导,通过软件安全检查、保护软件、生产安全良好的软件等措施保护组织免遭损失。NSA在通告中指出,该指南是对SolarWinds攻击事件调查结果的反馈。据悉,NSA、CISA、ODNI联合组建的持久安全框架工作组(ESF)对该事件的调查结果表明,需要创建一套行业和政府评估的方法,重点关注软件供应商的需求。

  软件供应链中未得到缓解的漏洞给企业带来了巨大的风险。本文章对软件供应链的开发、生产和分销以及管理流程提出了可操作的建议,以提高这些流程的抗风险能力。所有组织都有责任建立软件供应链安全实践,以降低风险,但组织在软件供应链生命周期中的角色决定了这种责任的形式和范围。

  供应商作为开发商和客户之间的联络人或中间人,因此,对以下方面负有主要责任。

  安全的软件开发和交付系统的目标是帮助保护软件代码、出处和完整性,从而为软件供应链的破坏创造弹性或完全防止其破坏。本节描述的威胁情景与NISTSP800-218一致;通过采用安全软件开发框架(SSDF)来减轻软件漏洞的风险。本节情景的目的是为开发人员、供应商和客户之间应该存在的沟通机制提供高级指导。

  应建立并实施政策,规定安全交付软件所需的检查。这些政策应该是每个在软件开发生命周期(SDLC)中发挥作用的人都可以访问和了解的,并且应该包括通知客户漏洞、用于缓解的机制以及寿命终止(EOL)支持。

  7.通过利用国际公认的标准(如NISTSSDF)来验证组织检查,这有助于确保在软件发布前和整个软件生命周期内满足软件功能和安全要求;

  所有形式的代码都应受到保护,以防止未经授权的访问和篡改,并且在整个SDLC中都应采用*小特权原则。这是确保交付给客户的代码包括所有需要的安全功能,以及这些功能按设计运行的关键。这包括代码中没有额外的、可能会降低安全性的功能,如后门或硬编码的密码。

  识别和审查受信任的架构师、开发人员、测试人员和具有完成项目所需技能的文档人员;

  根据个人的能力和兴趣,将其分配到一个或多个设计、编码和质量保证(QA)任务,并在安全访问控制系统中为其相应的项目角色注册权限;

  验证每个被分配的个人的公司发行的开发系统是否符合所有公司的安全标准,包括全盘加密、*低密码复杂性、补丁管理;防病毒和入侵检测系统、基于Al的端点保护平台和端点检测和响应、数据丢失预防(DLP)等;

  确保代码库、构建和测试环境至少具有与其他关键网络功能相同的安全保护措施,如网络分割、防火墙、监控、自动加密和远程备;。

  确保只有企业发放的或批准的开发系统才能使用多因素认证(MFA)或基于行为分析的连续认证来访问开发、构建和测试环境,并且只能通过具有物理安全性的办公网络或通过安全的虚拟专用网络(VPN)。确保检测、报告和调查失败的访问尝试。这对移动或远程工作的员工尤为重要;

  使用保护敏感签名密钥的代码签名系统交付数字签名的代码和相关支持文件,并使用硬件保护,如联邦信息处理标准(FIPS)140-2/-3硬件安全模块(HSM)。这要求至少有两个人激活签名密钥并批准软件发布包(即代码、支持文件和元数据);

  审查人员、任务、系统和政策,以确保它们继续保持适当、必要和完整。按计划和在事件触发时进行审查;

  承诺更快上市、更好的可扩展性和管理以及更低的成本的软件开发过程,同时保持相同的开发安全和完整性水平;

  应根据需要扩大这些做法,以解决与端点和操作云安全相关的任何其他认证挑战。

  供应商应提供一种机制,通过在整个软件生命周期内对代码进行数字签名来验证软件发布的完整性。

  由于代码签名只在代码签署后提供保护,为了减少签署前的代码篡改和恶意代码注入风险,建议企业考虑实施可验证构建过程,作为签署代码前的检查点;

  b)可验证的构建系统应该由生产构建环境的一个逻辑隔离的二级镜像组成,该镜像与生产构建环境的编译和打包程序同时进行,独立编译和打包代码;

  c)两个并行操作的哈希结果可以进行比较,如果验证为匹配,则可以对生产构建工件进行签名;

  d)*终修订的二进制代码应使用由受信任的证书机构颁发的代码签名证书进行签名,并提供一个机制来验证这些签名;

  用于代码签名操作的私钥应安全地存储在HSM上,以降低代码签名密钥被盗的风险。

  b)访问存储在HSM或代码签署基础设施上的密钥材料和程序的系统应受到适当的基础设施安全控制的保护。

  c)应通过适当的基础设施安全控制措施来保护代码签署业务,以减少代码签署密钥误用和滥用的风险。

  b)如果在允许第三方供应商的架构中没有第三方供应商的签名验证机制,则应开发并提供一种定制的程序化方法。

  通过将已发布的软件转移到归档状态,这通常是一个成本较低的存储区域,组织可以节省资金,并为更关键的软件项目分配快速的存储。这个过程也可以通过减少员工打开正在开发的文件和访问相关元数据的时间来加快生产力。以下的缓解措施可以帮助减少相关的风险和威胁。

  3.档案库应具有有限访问权限,并以只读模式存储,在只读模式下创建档案,以保持其完整性。

  4.用于存储档案的媒体由组织决定,决定通常取决于其方便性、可靠性和可用性;

  5.归档数据的过程通常是使用软件自动完成的。归档软件所提供的特点和功能取决于供应商,但大多数在每个平台上都有标准功能;

  系统管理员配置要归档的软件的时间、地点和频率。创建一个归档策略来确定移动数据背后的规则;

  与其他归档规则相结合,保留策略。保留策略决定了在数据被覆盖或销毁之前,存档的可用时间。典型的备份保留政策是30天,但归档数据在被销毁前可能会保留更长时间。归档和合规标准可能有保留政策的要求,所以组织应确保配置不违反监管标准;

  为了实现这一目标,安全要求必须是准确和完整的,代码必须满足这些要求,并应解决任何可利用的漏洞。

  使用熟练的软件架构师和安全专业人员进行威胁和风险评估,以了解不同的部署场景、事件和操作错误如何影响软件满足其要求的能力;

  记录设计和操作假设,以便更容易评估需求和其他变化对安全的影响。在整个开发周期中重新审视设计假设和决定;

  软件开发人员利用持续交付或持续部署方法,为其SaaS产品整合安全。以下是可能被利用的示例场景:

  攻击者或不知情的员工可能会将有漏洞的代码引入资源库,从而触发自动构建和部署;

  单个SaaS解决方案中不同模块之间的安全要求差异,可能导致所有组件的验证不足。

  攻击者或恶意内部人员可能会破坏由第三方供应商提供的未经供应商或第三方供应商验证的模块。

  在SaaS供应商和所有相关的分包商和第三方供应商之间建立、执行和验证共同的安全要求;

  定义用于执行软件产品安全评估的通用工具,负责代码开发的所有各方都必须使用这些工具;

  在*低权限的执行环境中执行任何未从安全角度完全审查的代码,直到该代码能够被完全评估;

  供应商、第三方供应商和客户之间的合同协议可能会连带;第三方软件是额外漏洞的潜在来源;

  供应商在做出使用第三方提供的软件组件的风险决策时,排除了某些常见的因素;

  在软件工程质量、*小加密密钥长度、确定批准的加密算法、确定批准的库或编译器选项方面未能成功地表达安全要求;

  1.验证第三方软件是否符合安全要求;这可以减少与使用获得的软件模块和服务有关的风险;

  如果适用,通过合同协议向第三方供应商传达安全要求。合同协议还应包括漏洞披露/缓解要求,或事件报告;

  如果可能的话,应签订合同协议。该协议应详细说明安全要求,并要求诸如及时披露漏洞和SDLC实践;

  只有在第三方软件符合安全要求[NISTSSDF P0.2]的情况下,才可提供其副本,并应说明符合的具体安全要求。副本只能从组织维护的只读位置获得;

  维护一个只读的位置,上面有经批准的第三方软件,并标明符合[NIST SSDF PS.1]的安全要求;

  构建过程是完全还是增量,决定了它是使用从未见过还是*后一次构建状态来执行。全面构建检查依赖关系,编译所有的源文件,按顺序构建所有的部分,并将其组装成一个构建工件。在增量构建的实例中,构建会检查和比较源文件和其他依赖目标的文件,以确定自上次构建以来的修改情况。如果有修改存在,目标将被重新构建。否则,上次构建的文件将被重新使用。

  能够接触到生产构建环境中的软件流程和工具的攻击者可能会在组件中插入恶意软件;

  用于编译和构建软件组件的过程必须被正确配置为默认安全,以确保所有二进制生产代码工件的完整性。应实施以下控制措施来强化软件编译和构建过程。

  组织应该为参与软件编译和构建的所有工具建立和维护一个可信的工具链;这些工具应该被配置为已知的安全基线状态,通过维护在配置管理数据库中的清单进行记录和跟踪,持续监测新出现的安全漏洞,并按照规定的修复时间线,接受适当的安全更新;

  所有的构建过程应该是自动化的,所产生的脚本和元数据应该安全地存储在一个版本控制系统中,访问权限仅限于负责构建组件的个人;

  应使用非交互式服务账户来调用自动构建流程,以确保构建输出是由服务生成的,且不可伪造;

  执行自动编译和打包流程的服务账户的认证凭证应使用经批准的方法进行验证,以验证该流程是可信的;

  自动构建过程应该生成并维护一个构建清单,识别构建者、源、入口点和参数,以确保构建的可重复性

  应启用安全编译器设置,以帮助防止或限制某些类型的安全问题的有效性,*明显的是缓冲区溢出。

  组织应该考虑实施可验证的构建过程,包括一个逻辑上隔离的生产构建环境的二级镜像,它与生产构建环境同时独立编译和构建软件组件。然后可以比较这两个平行操作的哈希结果,以验证构建过程的完整性。

  软件应该包括操作和安全功能,在进行信息安全评估时,应该考虑这两方面。这对采购、管理和部署过程尤其重要。组织利用具有强大安全功能的软件包,可以减少信息安全风险暴露,并减少进一步问题的可能性。在计算总拥有成本、风险缓解和控制、运营成本以及计算整体商业价值时,软件技术的基础软件质量和安全性应该是一个考虑因素。

  配置管理和纠正措施过程为现有软件提供安全保障,变更评估过程防止违反安全要求;

  安全保证包括SDLC和CI/CD的需求、设计、实施、测试、发布和维护阶段的活动)代码覆盖率,衡量单元测试覆盖率;

  2.审查和/或分析人类可读的代码,以确保其符合既定的安全保障计划,识别漏洞并验证是否符合既定要求。

  供应商必须设法提供允许客户访问其授权的信息和资源的软件,同时防止客户访问其未授权的信息。为了实现这一目标,供应商和开发人员应协同工作,帮助确保所有已知的漏洞得到缓解。

  所有的代码和系统都应根据相关的威胁模型进行持续审查,并根据需要进行修改,以确保代码和系统不存在结构性漏洞;

  7.安全测试应该是每个软件组件的质量保证计划的一部分,应该包括以下内容(见NISTSSDF):

  发布前,使用标准的公司认可的工具对所有代码进行静态(提示)和动态源代码分析。测试结果应被记录下来,所有发现的漏洞都应被分析和缓解;

  所有安全测试的结果都应该被记录下来,包括任何常见的漏洞评分系统(CVSS)的分数,安全缺陷应得到缓解和验证;

  客户有时急于快速安装软件,并可能偶尔在未完成适当配置或未完全理解配置选项的情况下在运行环境中使用软件。为了防止这些行为导致破坏,软件在安装时应要求*低限度的访问,允许客户在需要时明确启用额外的访问。

  4.要求客户在首次登录后立即更改默认的管理认证凭证;如果可能,建议建立MFA;

  5.要求所有管理账户凭证足够复杂(密码)或具有足够的加密强度(证书)。如果可能,任何账户的访问尝试都应涉及MFA,通过具有物理安全和/或安全VPN的办公网络,和/或基于行为分析的连续认证(见NISTSP 800-207);

  7.密码恢复程序必须要求控制台或物理访问。密码重置程序应该恢复到初始状态。

  供应商应尽力确保提供给客户的任何软件中没有公开的或容易识别的漏洞。此外,采购软件的客户非常希望获得有关所购软件的来源和安全性的透明信息。以下的控制措施旨在使组织的安全软件开发过程透明化。如果不执行这些步骤并保持遵守的证据,可能会降低对软件质量足以在客户的网络中运行的信心。

  1.建立由架构师、开发人员、测试人员、密码学家等人员组成的漏洞评估小组,其目标是识别软件中得可利用缺陷。

  2.对于软件能力,定义一个流程,使用已知环境分析,监测与软件能力相关的漏洞,并对组合系统中的各个单元进行未知环境的模糊测试;

  3.对于软件组件,定义一个流程,使用已知的环境分析,使用源码或二进制组成分析工具来监测与确定的软件组件相关的漏洞,并对组合系统中的各个单元进行未知环境模糊测试;

  5.建立全公司范围内的产品安全事件响应(PSIRT)的中央团队。面向公众的PSIRT信息应便于外部研究人员报告组织产品的漏洞;

  6.所有已知的安全问题和/或漏洞都应在组织的缺陷跟踪工具中作为产品缺陷进行跟踪。跟踪的项目应包括CVSS评分、对组件的具体影响以及任何其他相关的支持数据;

  7.根据可能构成软件组件或软件包的多种因素和复杂性,提供足够的人力和资源、软件测试以及测试时间。因素可能包括负载、分支、竞赛条件等;

  9.参考与第三方软件和与软件相关的开放源码组件相关的SBOM(或类似机制)。在问题公布后,建立并遵循企业对嵌入式组件升级的指导;

  快速采用和获取SaaS工具和产品可能有内在的风险,并可能*终影响组织的整体安全态势。

相关案例查看更多