如何基于ISO26262导入ISO21434：项目安全管理篇

前言：ISO26262，作为汽车行业的功能安全标准，已经在汽车行业应用10年有余。ISO21434作为汽车行业产品信息安全标准，于2021年8月底正式发布，引起了很多家OEM和供应商强烈关注。ISO21434以ISO26262为框架，两个标准相似度很高，本文对两者进行对比，并对如何基于ISO26262的项目功能安全管理的基础上，导入ISO21434给出建议。 

1. Role and Responsibilities

• ISO26262要求：项目中，项目经理应确保组织提供了从事功能安全活动所需的资源。需要确保项目中，指派了功能安全经理。
• ISO21434要求：项目中，应该明确信息安全活动的人员职责，并告知相关人员。

【导入建议】这部分，两个标准的要求，基本一样的。实际项目操作中，组建项目团队，明确每个人在项目中的工作职责。

2. Impact Analysis at item level

ISO26262要求：

• 项目启动时，要在item层面进行影响分析，确定是全新开发还是基于现有的item进行改动；
• 如果是基于现有的item进行改动，需要进行影响分析改动对于功能安全的影响，明确哪些安全活动受到影响；

ISO21434要求：针对复用的item，需要进行复用分析，分析改动对于信息安全的影响，包括对于安全声明和复用的item假定的确认。

【导入建议】这部分，两个标准思路基本一样。可以基于现有的功能安全impact analysis的模板，修改影响分析部分为对于信息安全活动和工作产出物的影响，分析改动对于信息安全的影响时，还要包括对于安全声明和复用的item假设的确认。另外，需要提醒，识别item变化时，除了考虑item本身的改动，还需要特别关注item运行环境的变化。

3. Impact Analysis at element level

ISO26262要求：

• 如果复用现有的element，需要在element层级进行影响分析，包括明确变更、分析复用的element是否满足所分配的安全需求、确定哪些安全活动受影响（包括对复用的element假设的确认）、评估现有的文档是否足够支持集成活动。
• 如果满足ISO26262-8第12章软件组件鉴定和第13章硬件组件鉴定的要求，则该组件可以复用。
• 如果满足ISO26262-10中SEooC (Safety Element out of Context)中的要求，则该组件可以复用。

ISO21434要求：

• 针对复用的element需要复用分析，分析改动对于信息安全的影响（包括对于安全声明和复用的element假设的确认）、分析复用的element是否满足所分配的安全需求、评估现有的文档是否足够支持集成活动。
• 针对off-the-shelf component，应确认所分配的安全需求是否满足、是否适合项目的应用场景、现有文档是否足够支持信息安全活动。
• 对于component out-of-context，假设的安全需求和接口是否可以接受、确认安全声明是否可以接受。

【导入建议】此部分ISO21434的内容对应ISO26262中的element impact analysis, HW and SW component qualification, SEooC approach.

• 对于element impact analysis，可以基于现有的功能安全element impact analysis的模板，修改影响分析部分为对于信息安全活动和工作产出物的影响，分析改动对于信息安全的影响时，还要包括对于安全声明的确认。
• 对于off-the-self component, ISO21434没有ISO2626中的硬件和软件组件鉴定活动那么复杂。可以基于现有的硬件和软件组件鉴定报告，修改为信息安全的鉴定报告，至少包括确认所分配的安全需求是否满足、是否适合项目的应用场景、现有文档是否足够支持信息安全活动；
• 对于component out-of-context，两个标准基本要求是一致的，但是信息安全还要确认component out-of-context的安全声明是否可以接受。

4.  Activities tailoring

• ISO26262要求: 基于项目，对功能安全活动进行裁剪，并记录裁剪理由。
• ISO21434要求: 信息安全活动，可以被裁剪。需要对裁剪掉的活动，说明理由。

【导入建议】两者要求一致，只不过裁剪的活动对象不同而已。

5. Planning, coordination and progress of safety activities

ISO26262要求：

• 功能安全经理应该计划、协调、监控、维护功能安全活动。
• 安全活动的计划，应包括活动目标、依赖关系、所需资源、时间计划（开始和结束时间）、工作产出物。
• 功能安全计划应逐步细化更新，工作产出物要保持更新，直至产品发布。
• 功能安全计划中的工作产出物，要在系统开发开始前，纳入到配置管理、变更管理、文档管理。

ISO21434要求：

• 信息安全策划阶段，要确定产品是否和ISO21434相关。
• 安全计划，要包括活动目标、依赖关系、所需资源、时间计划（开始和结束时间）、工作产出物。
• 计划、协调、监控、维护信息安全活动的职责应该被明确。
• 信息安全计划中的工作产出物，要纳入到配置管理、变更管理、文档管理。

【导入建议】这部分，两者要求一致。ISO21434中多出确定产品是否和ISO21434相关的判断，可以参考如下步骤：

6. Safety case / cybersecurity case

• ISO26262要求: 应按照安全计划，建立安全档案，以提供论证产品达成功能安全。安全档案应逐步收录安全生命周期内的工作产出物。
• ISO21434要求: 应该编写安全档案，提供产品达成信息安全的论证。

【导入建议】这部分，两者要求一致。参考safety case的模板，制定cybersecurity case的模板。

7. Confirmation measure / cybersecurity assessment

ISO26262要求: 此部分标准内容较多，不再一一描述。

注：可参考本公众号文章：

• ​​ISO26262中的认可措施与Automotive SPICE评估之间的关系​​

ISO21434要求:

• 执行cybersecurity assessment的人员，应保持独立性（可参考ISO26262独立性要求）。
• Cybersecurity assessment需要包括：安全计划和安全计划中的工作产出物，信息安全风险的处置，安全措施的有效性。
• Assessment report应包括结果：接受、条件接受、拒绝。如果是条件接受，应列明接受的条件。

【导入建议】此部分，ISO26262能覆盖ISO21434的所有要求。ISO21434此部分没有太多内容，建议项目中，可以按照ISO26262的assessment的流程进行操作。

8. Release for production

ISO26262要求: 有足够的证据和信心达成功能安全（参照assessment report的结果和安全档案），才能进行产品量产发布。生产发布报告中，要包括如下内容：

• 发布人和签字；
• 发布产品的版本；
• 发布的产品的配置；
• 发布日期。

ISO21434要求: 满足以下条件，才能进行产品量产发布。

• 信息安全档案中的论据是令人信服的；
• 通过信息安全评估；
• 对于post-development的要求被接受。

【导入建议】可以在现有的产品发布的基础上，加入信息安全负责人的签字批准，并定义批准的准则：

• 信息安全档案中的论据是令人信服的；
• 通过了信息安全评估；
• 对于post-development的要求被接受。

9. Distributed development

ISO26262要求:

• 供应商选择原则，需要考虑供应商的功能安全能力；
• RFQ中，对供应商提出满足ISO26262的正式要求，确定供货范围、安全需求、硬件定量目标值；
• 起草和签订DIA；
• 开发过程中，监控供应商；
• 双方对于POSD阶段的约定。

ISO21434要求:

• 供应商能力评估，需要考虑供应商信息安全的能力；
• RFQ中，对供应商提出满足ISO21434的正式要求，确定供货范围、安全需求
• 双方的分工，体现在接口开发协议中。

【导入建议】此处可以参考ISO26262的做法，制订客户-供应商的接口协议，明确双方分工。在接口开发协议中，还需要明确工作产出物的机密等级。

推荐阅读：

• ​​如何基于ISO26262导入ISO21434：总体安全管理篇​​​
• ​​基于ISO26262导入ISO21434：产品开发篇​​
• ​​汽车信息安全 TARA 分析方法实例简介​​
• 
  
• 文章转载自公众号：仨人谈起