软件架构的安全分析

谈思实验室 2025-01-15 17:56 174浏览 0评论 0点赞

工程师必看：B2900隐藏的15个超频测试模式 4.23杭州！半导体产业链测试全链路解密

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

安全导向软件分析过程

软件架构层级的安全分析及相关失效分析的作用是支持设计规范和设计验证活动。此分析也可以揭示给定安全要求的不完整性或不一致性。软件架构层级的安全导向分析在软件开发中的作用,以及软件安全要求、软件架构设计和安全计划间基本的交互关系如下：

软件架构层级安全分析的目的和重要性

动态特性分析：软件架构层面的失效多具有动态过程，难以通过软件安全开发流程约束识别出来。
软件可解释性：机器学习(AI)等非白盒模型的应用降低了软件可解释性，增加了失效可能性，基于架构的安全分析有助于从逻辑层面分析潜在失效问题。
分析对象：软件安全分析的对象是软件架构，重点在于分析架构动态特性可能带来的功能安全问题，而非具体的软件单元层面代码级别的语法、逻辑等错误。

软件架构层级安全分析的内容

重点问题：分析不同ASIL等级或安全和非安全相关软件共存时，避免要素之间的干扰问题(FFI)，包括时序和执行、内存、信息交换。
颗粒度选择：根据软件架构的复杂度，选择一个在项目周期内可实施的颗粒度，但颗粒度不可过大，以保证分析的有效性和完整性。

软件安全分析方法

FMEA与FTA：

ISO 26262, Part 6附录E提到可以采用归纳或演绎的方法，实际操作中推荐采用归纳分析方法，即FMEA(或STPA)，因为FMEA由原因到结果的分析过程更适合软件安全分析的需求。

避免软件要素间的干扰（Freedom from Interference, FFI）

避免不同软件要素之间的相互干扰，包括以下几个方面：

时序和执行：包括死锁、活锁、执行时间的不正确分配以及软件要素间的不正确同步。
存储：涉及内容损坏、数据不一致（例如在数据获取期间发生更新）、堆栈上溢或下溢以及对已分配给其他软件要素的内存进行读或写访问。免受空间干扰意味着一个软件分区不应该更改另一个软件分区的代码或数据。软件设备之间的内存和存储应该是分开的，以防止代码和数据损坏。这涉及到读取、写入和执行权限的设置。
信息交换：包括信息重复、信息丢失、信息延迟、信息插入、信息伪装或错误寻址、信息顺序错误、信息损坏、从发送者到多个接收者的不对称信息发送、发送者的信息只被部分接收者接收，或通信通道的访问阻塞。

ISO 26262提出了“要素共存（Coexistence of Elements）”的概念，目的是防止较低ASIL等级要素或QM要素的失效导致较高ASIL等级要素失效。如果能够证明对分配给要素的每个安全要求，某个子要素不会干扰任何分配了较高ASIL等级的其他子要素，则应仅视该子要素为较低ASIL等级的子要素。否则，应将不具备免于干扰证据的共存安全相关子要素的最高ASIL等级分配给该子要素。

相关失效分析（DFA）

独立性与干扰性：相关失效分析侧重于查找使独立性和免干扰性失效的单一原因/事件，包括级联失效和共因失效。
分析方法：通过识别级联失效来验证要素之间的干扰性，通过识别级联和共因失效来验证要素之间的独立性。

时序干扰导致级联失效的示例

使用引导词的架构分析

引导词是系统地进行安全分析并支持完整性论据的一种手段。可以用来识别软件架构中的薄弱点、故障和失效。

选择合适的引导词取决于被检查的功能、行为、特性、接口或交换数据的特征，这需要根据上下文和分析工程师的判断来确定。

在设计中选择引导词的示例如下：

空白（NONE）：设计或操作要求的指标和事件完全不发生，例如无流量、无催化剂。
过量（MORE）：同标准值相比，数值偏大，例如温度、压力、流量等。
无需求（UNdemanded）：系统或组件在不应该激活时被激活。
过多（Excessive）：系统或组件的输出或行为超出了预期。
不足（Insufficient）：系统或组件的输出或行为低于预期。
损失（Loss）：系统或组件的功能完全丧失。
缺乏（Lack）：系统或组件缺少必要的功能或特性。
不稳定（Erratic）：系统或组件的行为不可预测，时好时坏。
振荡（Oscillating）：系统或组件的输出或行为在两个或多个状态之间快速变化。
间歇性（Intermittent）：系统或组件的功能偶尔出现故障。
降级（Degraded）：系统或组件的性能降低，但仍在工作。
早期（Early）：系统或组件在预期时间之前发生行为或输出。
晚期（Late）：系统或组件在预期时间之后发生行为或输出。
反向（Reversed）：系统或组件的行为或输出方向与预期相反。
卡住（Stuck）：系统或组件在某一状态卡住，无法移动或变化。

这些引导词可以帮助分析人员系统地识别和讨论潜在的设计偏差及其可能的后果，从而确保分析的完整性和系统安全性。选择合适的引导词取决于所检查的功能、行为、特性、接口或交换数据的特征。

软件安全分析步骤

步骤一：分析范围及对象的确定，以软件架构输入作为安全分析的基础，选择合适的软件架构颗粒度。
步骤二：软件模块结构分析，罗列分析对象对应的软件架构中所有的软件模块，并初步区分是否和安全相关。
步骤三：失效模式分析，逐个分析软件模块的失效模式，使用引导词生成问题去检查架构要素的特定功能或特性。
步骤四：制定安全改进措施，根据识别出的失效模式，制定相应的安全改进措施，必要时导出相应的软件安全需求，并进行软件架构更新。

安全措施制定策略

软件架构层级的安全分析和相关失效分析为我们提供了选择适当安全措施的依据，这些措施旨在防止、探测和控制可能违反安全要求或安全目标的故障和失效。在确定安全措施时，我们应考虑以下策略：

评估每个已识别故障的关键性，考虑其是否违反安全目标或安全要求，以及相应的ASIL等级。
通过改进架构设计，消除或降低已识别薄弱环节的关键性。
确认开发期间安全措施的有效性，并评估这些措施是否能够充分减轻已识别故障的危害。
评估安全机制的有效性，以减轻开发期间措施不足的关键故障影响。
考虑软件架构设计的复杂性，以及软件组件的复杂性，对安全措施的选择和实施产生影响。

例如，对于复杂的软件系统，仅依赖开发期间的安全措施可能不够充分。根据上述策略，我们认识到，在运行期间并不总是需要执行预防、探测和控制故障或失效的安全机制。因此，在制定安全措施时，应综合考虑系统的复杂性、关键性以及现有措施的有效性，以确保安全目标的实现。通过这种方式，我们能够更有效地管理和减轻软件系统中的安全风险。

来源：智能苑

end