本文翻译自《Security Development Lifecycle》。
4.0 设计和开发的最佳实践
4.4 测试和验证
本节概述了在车辆开发生命周期中可能进行的网络安全测试,以及在某些情况下可能适用的测试方法。虽然测试证明所实施的系统工作正常,但验证是考虑系统是否根据要求和规范开发的首要过程。这包括检查是否已为目标系统指定并正确实施了安全设计原则(如“最低权限”)。
4.4.1利益相关者
参与该阶段的主要利益相关者包括OEM以及一级和二级供应商。通常,二级供应商与OEM的互动很少。但是,当一级供应商采购二级供应商的服务或产品时,“OEM角色”的注意事项可能适用于该一级供应商。这种方法支持供应链安全工作。利益相关者各自的作用及其互动的性质将在下文中进一步描述。
OEM角色
OEM执行系统级验证、用户验收测试、安全验证测试,并根据需要实施补救措施。OEM还负责进行最终(生产)风险评估。
供应商角色
供应商执行安全验证测试,并提供证据(报告)以证明实现满足安全需求。
每当一级供应商将二级供应商提供的解决方案集成到其产品中时,他们的角色就会从承包商转变为委托人。为了确保供应链的安全,一级供应商对二级供应商开发的零件或软件进行验证。在这种情况下,上述相关项由二级供应商提供给一级供应商。
这一概念具有很大的优势,即安全风险在供应链上下传播,因此一级供应商负责的产品中不会出现未知的安全问题。
此外,即使二级供应商和OEM本身之间没有合同或协议,OEM也可以执行更好的风险管理工作。
第三方角色
第三方可以支持OEM或供应商进行独立验证和安全验证测试。
4.4.2输入
测试和验证阶段的输入是需求和实施阶段的输出。其中包括实施的系统和支持基础设施、确认审查或评估以及安全测试结果,如渗透测试结果、代码审查和自动代码分析的结果,这些结果可与测试方法的评估结合使用,以确定特定产品或组织的正确测试类型。
实施阶段针对微调测试计划活动提供了一个更详细的实施计划。由开发人员提供或自行编写的安全相关功能的测试用例可以与现有或临时测试结果一起用作输入,以使测试计划和活动更加全面。
与网络安全相关的测试计划过程通常与公司现有的测试规划流程(如客户功能验证)没有实质性差异。
4.4.3过程
网络安全测试
实际测试发生在产品实现阶段期间和之后的多次迭代中。网络安全测试是“健康检查”的一种重要形式,用于证明安全需求的正确实施,并在发现漏洞后为残余风险评估提供输入。在车辆及其生态系统的实施过程中,在计划的里程碑进行网络安全测试有助于公司确保计划的保障措施有效,识别潜在的漏洞,并在车辆部署前进行补救。漏洞发现得越早,用于补救的时间和预算就越少。
内部网络安全验收流程
内部网络安全验收并不能保证产品在受到网络攻击下100%安全。但它可以提供一个证明,表明在当前条件下,产品足够强大,能够抵御先前评估的攻击者画像的尝试。
内部网络安全验收流程是向开发项目的相关利益相关者提供最终确认的一种方式,即所有与安全相关的工作都已完成。这将保证网络安全控制得到正确实施,常见漏洞得到评估并在必要时修复,网络安全测试也已进行,表明安全保障措施如预期那样发挥作用。可以在整个产品生命周期的计划里程碑处对每个组件/软件开发项目进行此确认。内部网络安全验收作为一种工具,可以让安全团队将偏差上报给管理层,并优先考虑关键项目。然而,安全工作并没有随着网络安全的验收而结束,因为系统长期公开暴露在不受控制的环境中会逐渐增加滥用和误用的风险。
为了向OEM高级管理层提供内部网络安全验收(即对整个车辆及其生态系统的保证),需要收集和汇总每个组件/软件项目的验收文件。该验收过程中的相关信息和相关项应包括总体测试计划、已执行的功能测试、渗透测试和源代码审计、未解决漏洞的数量及其风险评级、开放测试或测试用例等。如果组件/软件项目因工作不完整(如测试结果缺失或漏洞未修复)而无法验收,则需要评估车辆及其生态系统的总体风险。
理想情况下,所有评估都已在车辆部署前进行。所有验收相关文件可用于跟踪安全团队和开发人员的工作进度(例如,在无法及时修复漏洞且高级管理层已决定接受风险的情况下)。在车辆部署之前,可以按照《AUTO ISAC风险评估和管理最佳实践指南》中的说明处理在验收过程中和验收过程之后识别的残余风险。
网络安全验收流程可能与组织现有的开发流程有关,如车辆功能安全的内部审批流程。这样做的好处是,网络安全测试将嵌入开发过程,提高整体的安全意识。如果流程是完整的,并且所有利益相关者都经过了尽职关心 ( due care ) 和尽职审查(dure diligence ) ,那么它也是一个向高级管理层提供信息的好工具。
为了长期提高安全水平,根据最终评估,可以将针对未来项目的建议传达给开发项目团队、车辆架构团队和管理层。
4.4.4输出
测试和验证阶段最重要的输出是测试结果的报告。根据这些报告,可以采取进一步的步骤。然后,该验收文件可用于向高级管理层表明,在产品开发阶段已采取了应有的尽职关心 ( due care ) 和尽职审查(dure diligence )。以下流程描述了公司如何创建此类文件。
残余风险评估
残余风险评估既可以作为安全设计生命周期的一部分,在生产开始前进行,也可以在生产期间定期进行,以应对不断演变的威胁。这适用于已知的残余风险,因为发现或公布新的攻击方法,或由于新的或更便宜的工具而降低攻击成本,可能会随着时间的推移改变风险缓解的成本/效益评估。在生产之前,当做出接受残余风险的初步决定时,也需将攻击风险随着时间的推移而改善的趋势纳入考虑。《AUTO ISAC威胁检测、监控和分析最佳实践指南》中描述的公司威胁监控功能可能支持识别新的攻击趋势。
产品在供应链中的地位可以在不同层面上减少残余风险。例如,在一级或更低级别供应商的零部件中发现的残余风险可以在较高的系统级别上得到减少。因此,供应商与客户分享其威胁模型和缓解措施是很有价值的,然后客户可以接受或开发缓解措施以转移风险。在产品的供应链利益相关者之间共享所有风险评级方法和流程,以支持所有相关网络和风险管理团队的风险评级和处理工作,这是很有帮助的。有关组织如何处理这些残余网络风险的更多信息,请参阅《AUTO ISAC风险评估和管理最佳实践指南》。
扫一扫关注我
微信号|Swim_Lab
公众号|水湾实验室
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...