MUNIK解读ISO26262：软件开发阶段(四)-软件安全分析

 

-原创文章，转载需授权，否则必究

引言：

完成软件架构设计之后，需要进行有效的安全分析方法去检查验证这个架构，以保证当前设计的架构能够应对硬件问题和软件问题的威胁。软件架构安全分析方法包括SW-FMEA、SW-FTA及SW-DFA，其中应用最多的是SW-FMEA和SW-DFA。本文主要讲述SW-FMEA和SW-DFA在设计中的作用，以及在设计中如何开展和实施。

 

1 软件安全分析-FMEA

 

1.1 SW-FMEA分析的目的

 

软件安全分析FMEA即SW-FMEA在软件架构层面执行安全导向分析的，主要的目的是识别软件的失效模式，研究分析各失效模式的原因和后果，并找到消除和减少其有害后果的方法，从而尽早发现潜在的问题并采取相应的措施，从而提高软件的可靠性和安全性。

 

1.2 SW-FMEA分析的范围

 

          FMEA分析的范围：与软件开发的范围有关，可以是应用层和底层，也可以只包含应用层或者软件底层。具体如下图所示：

图一、软件FMEA分析范围

 

1.3 SW-FMEA分析的流程

 

     软件FMEA依据FMEA分析的六步法，具体的流程如下图所示：

图二、软件FMEA分析流程

 

• 进行软件FMEA分析时首先要确定软件系统的范围和边界，根据软件开发范围定义出对外接口，分析层面，在软件架构设计图中确定分析对象；
• 然后对确定好的范围内软件架构图的结构进行分析，分析的最终对象是软件单元模块，明确软件单元模块和涉及到的软件组件和软件单元之间的关系，以及上下单元之间的关系，信息传递的关系，为功能分析奠定基础；
• 功能分析主要是给架构图中个软件单元模块分配相关的功能，详细描述每个功能以及影响，将安全要求分配给子模块，用于后续失效影响分析；
• 失效分析主要是对软件最底层的软件单元分析，找出所有可能的失效模式和失效原因，并生成一个失效链；
• 风险分析是针对现有失效模式严重度的评估和安全机制评估，以及制定的预防控制措施的评估，为后边的优化奠定基础；
• 优化主要是对当前分析对象中识别出未考虑安全措施并可能违反安全目标的故障时，应确定后续的改进和优化活动，例如设计新的安全措施以降低风险。还应该评估和验证这些改进和优化的有效性。

注意，一旦确定了这些改进和优化要求，如果涉及到变更流程应通过变更过程更新设计要求，并根据更新的要求设计新的架构，直到分析对象的所有可能违反安全目标的故障都被考虑并采取相应的安全措施，并有效降低风险和影响。 

 

1.4 S/O/D评估标准

 

严重性等级(S)、事件发生率(O)和检测度(D)的评估标准，来源于FMEA手册 详见AIAG_VDA_FMEA_Handbuch_1. Ausgabe 2019_Englisch，手册里具体评分准则如下图所示。

图三、严重度评分准则

图四、时间发生率评分准则

图五、探测度评分准则

 

1.5 SW-FMEA分析报告示例

 

软件FMEA分析报告主要列举出：

• 软件组件和软件组件之间的接口或硬件组件和软件组件之间的接口的失效模式；
• 分析失效模式对上一层级的影响和最终软件需求的影响，尤其是与功能安全相关的影响；
• 在明确失效模式和失效后果的基础上，去寻找造成失效的原因，并且对原因施加控制措施即可。

下图为一个充电控制器中底层硬件驱动模块的软件FMEA分析示例，从架构分析、功能分析、失效分析、风险分析、优化展开仅供参考。

 

图六、FMEA分析示例

 

2 软件安全分析-DFA

 

2.1  SW-DFA分析的目的

 

 FMEA用来进行单点故障分析，因此在考虑某个底层故障时既不考虑其他故障对自身的影响，也不考虑对其他故障的影响；但是对于一个真实的系统而言，往往会出现底事件A发生故障同时导致底事件B和底事件C发生故障，所以FMEA分析的结果是不完整的，对完整性的弥补将由相关失效分析来完成。

 

软件相关失效分析即SW-DFA是在软件架构层面执行安全导向分析的，主要的目的是通过分析其潜在原因或引发因素，确认设计中充分实现了要求的独立性或免于干扰；及如有必要，定义安全措施，以减轻可能的相关失效。

 

2.2 SW-DFA分析的范围

 

DFA分析包括两个部分：验证软件单元之间不受干扰和验证软件单元之间的独立性。如下图所示独立性受到共因失效和级联失效的威胁，而免于干扰仅受级联失效的威胁：

图七、相关失效分析

共因失效和级联失效之间的区别如下图所示

图八、级联失效和共因失效

级联失效：由一个根本原因[内部或外部]导致某个相关项的要素的失效，进而引起相同或不同相关项的另一个要素或多个要素的失效。级联失效是独立的失效，不是共因失效。

 

共因失效：由单一特定事件或根本原因直接导致一个相关项中两个或多个要素的失效，该事件或根本原因可来自所有这些要素的内部或外部。共因失效是相互依赖的失效，而不是级联失效。

 

在软件设计中通常可以从一下几点考虑级联失效：

1. 时间和调度问题造成级联失效。例如：由于其他模块运行时间过长导致目标模块无法运行，死锁、活锁、饥饿等现象导致模块运行停滞或者延迟，软件模块之间的同步性问题或者优先级问题导致程序执行次序出现问题。
2.  存储空间问题造成级联失效。例如：目标储存区域被其他软件模块误纂改，软件模块之间对于同一个存储空间的读写操作配合问题导致数据不一致，栈溢出等问题。
3. 软件模块之间的通讯问题造成的级联失效。例如：软件模块之间通讯接口配置失效导致无法通讯，最终导致数据无法更新和计算等问题。

 

在软件设计中通常可以从一下几点考虑共因失效：

1. 调度策略的设计问题，因一个调度执行错误因而产生多处错误。
2.  软件架构设计过程中采用ASIL分解的冗余设计，但是互为冗余的两部分使用相同的设计，比如相同的时钟基准等。
3. 配置/标定参数错误导致多个软件模块同时失效。
4. 设计中的某个规范未遵守而导致多个模块同时失效。比如，全局变量使用太多，全局变量被无意中修改后导致多个模块失效。
5.  共享资源的使用，比如：共同使用的时钟模块失效，对各个模块的失效；内存失效导致与内存有关联的模块失效。

 

2.3 SW-DFA分析的流程

 

软件DFA分析的过程就是在定义的范围内识别出软件单元之间是否存在级联失效和共因失效，找出软件单元之间是否存在潜在的相关失效，然后对潜在的相关失效进行判定是否为相关失效引发源（DFI）并找出耦合因子类型，然后对每个耦合因子进行深入的分析，找出失效原因和失效模式，最后根据失效原因制定相关的安全措施来避免和控制系统性失效的发生，最后需要对安全措施进行评估证明控制和避免相关故障的有效性，并对整个DFA报个进行审核。审核的重点是分析的完整性，首先考虑是否有遗漏的DFI，然后考虑安全措施的合理性。一般直接将安全措施转换为安全需求来控制相关失效的发生。

 

具体的流程如下图所示：

图九、软件DFA分析流程

 

其中：评估每个软件单元或者一组软件单元之间的相关项，应着重考虑软件单元的独立性和免于干扰。识别模块之间是否存在共因失效和级联失效，罗列潜在失效模块时，如果把所有软件单元进行配对分析的话，这个工作量会很大，因此也需要做提前的分类和筛选的。

 

比如可以分为以下几个类型

1.  软件架构设计中进行ASIL分解出来的独立模块，分解后的两个单元，要考虑两个单元之间是否完全独立；
2. 不同的ASIL单元导出的不受干扰的模块，要素共存的情况存在后也要考虑低等级和高等级之间的交互；
3.  由冗余的设计导出的独立模块，冗余设计要重点考虑共因失效；
4.  从软件FMEA重复出现的失效模式导出的软件模块，重复出现的失效模式大多是冗余设计；

 

2.4  软件耦合因子

 

软件相关分析最终要确定耦合因子，软件耦合因子指软件单元之间的共同特性或者是共同的关系。比如：两个软件单元使用MCU内部同一个RAM区域；延时函数被多个软件单元使用；函数的调用，计算结果的传递等等。总之耦合因素主要来源于7个方面如下图所示：

图十、软件DFA分析流程

 

1. 共享资源： 例如被2个软件组件使用的驱动程序、RAM、数据库等；
2. 共享信息输入：两个软件函数的全局常亮或者变量，也就是两个函数使用的一个输入参数（一个软件函数计算的结果被多个其他软件函数调用）；
3. 环境抗干扰能力不足：这个一般对硬件层面的影响比较大，不直接适用软件本身，但是可能影响硬件影响软件的行为，硬件设计抗电磁干扰不强的话，影响数据的采集和传输等；    
4. 系统耦合：相同的软件工具如IDE（集成开发环境）、编译器、软件配置器，相同的变成和建模语言（主要指的是软件开发系统）；
5. 相同类型的组件：主要是C语言中的宏定义，还是就是项目的数据库和标准软件模块被划分到了共享资源里了；
6. 通讯：全局变量的数据流、消息传递、传递参数的函数的调用；
7. 非预期接口：由于使用相同的内存空间，导致可能出现错误的内存分配和内存泄漏。

 

实际设计中我们会通过SW-FMEA和SW-DFA的结果不断地完善软件架构设计，从而就引出了安全机制。安全机制的研究又是一个独立的主题，具体的技术细节，怎么落实，会有专栏去详细拆解分析，请大家持续关注。