如何根据GJB 102A开展软件安全性分析 —— 下篇
对于从事功能安全的朋友们来说，横向对比通用的IEC 61508-3、轨交行业的EN 50128/EN 50657、汽车行业的ISO 26262-6等对软件的安全性考量，或许能够从本文中得到一些借鉴和启发。
以下为原文：
前言
在<上篇>中，我们介绍了GJB 102A的现状、解读、建议等。今天，我们继续介绍GJB 102A应用详细步骤。
上 篇
1、GJB 102A的型号应用现状
2、GJB 102A与其他标准的关系
3、GJB 102A的不足
4、GJB 102A的使用建议
下 篇
5、GJB 102A应用的详细步骤
第一步，分析软件特点，确定适用条款
第二步，根据适用条款，形成细化准则
第三步，根据分析准则，选取失效模式
第四步，根据失效模式，评估影响后果
第五步，根据影响后果，形成安全需求
6、增量步骤 证明自己的软件符合GJB 102A
第六步，过程举证，结果举证，列出举证矩阵
第七步，根据举证矩阵，回溯标准条款，得到安全结论
GJB 102A的全部条款约350项。对于不同特点的软件不能全部套用，需要从标准条款中选择出适用的部分。
选择的原则是根据软件特点剪裁不适用的要求。例如，对于一个不含界面的嵌入式软件，“5.3.4.3 人机界面设计”不适用；而对于状态场景多的软件，“5.2.2.2 安全运行模式、运行状态与条件”则更为适用。
如何分析软件“特点”呢？
并没有通用的定义，软件特点可以是软件固有特性，例如，
军用软件测评实验室分类的嵌入式软件与非嵌入式软件；
按照软件使用特点可分为机电软控制类、数据处理类、信息系统类等等；
按照软件规模可以分为大、中、小等；
按照软件领域可分为机载、弹载、星载、船载、车载等等；
按照软件接口可分为传感器、数字总线、数字开关等等。
也可以是比较主观的特点，例如，
软件某类功能、某个接口易出问题（需着重分析）；
某功能涉及安全关键；
某功能属于迭代开发等等。
以下是一些进行软件特点分析的示例：
-- 领域特点 --
依据软件所在的航空、航天、船舶、兵器等领域特点，分析应考虑的安全性要求。例如，航空领域的安全关键软件通常包含冗余设计、BIT自测试等，那么适用的标准条款如“5.2.2.3 容错和容失效—冗余设计”、“5.3.3 容错和容失效的设计—b)机内测试”就应该作为重点对标条款。
示例1 下面是某机载关键级软件的一个安全性适用条款选择片断。
软件特点包括：设备级冗余设计、软件功能级冗余设计、BIT自测试功能、状态场景多等。
因此，选择了：
“5.2.2.3 容错和容失效—冗余设计”
“5.2.2.3 容错和容失效-冗余管理/转换逻辑”
“5.3.3 容错和容失效的设计—b)机内测试”
“5.2.2.2 安全运行模式、运行状态与条件”等等。
-- 软件使用特点 --
依据机电软控制、数据处理、信息系统等软件使用特点，分析应考虑的安全性要求。
例如，机电软控制类软件，适用的标准条款如“5.3.2 配合硬件或系统设计的考虑事项”、“5.3.3 容错和容失效的设计-- a)故障/失效检测、隔离和恢复”等等。
数据处理类软件，适用的标准条款如“5.2.2.6 数据”、“5.2.2.3 容错和容失效”、“5.2.2.4 危险命令处理”等等。
示例2 下面是某监测仪表软件的一个安全性适用条款选择片断。
软件特点包括：接口数据监测、数据处理、数据报警、信息通信处理等。
因此，选择了
“5.2.2.6 数据”
“5.2.2.3 容错和容失效”
“5.2.2.4 危险命令处理”“5.3.1 c)故障检测、恢复和安全保护”
“5.3.6 数据安全性设计”等等。
-- 软件项目阶段 --
软件安全性工作是可以迭代、阶段性推进的，划分工作阶段，每个阶段选择不同的标准条款，作为首轮、二轮、…、回归阶段的安全性目标。
示例3 下面是某信号处理软件的一个安全性适用条款选择片断。
信号处理软件功能依靠大量软件外部接口输入输出完成，软件接口数量多，因此将软件安全性分析划分为三个阶段：
阶段一 接口安全性分析；
阶段二 功能安全性分析；
阶段三 迭代与总结。
在阶段一，进一步将软件接口分为“驻留设备接口、外部输入接口、外部输出接口、接口通信、人机交互接口、软硬件交互接口”等类别，分别选择适用标准条款。
标准提出的是目标，达到目标的途径有多种。所以在第一步确定了适用条款后，还需要制定达到条款的具体方法。这个具体方法往往是制约标准落地的难处，我们在这里，给这些具体方法起名叫“安全性准则”，当然，叫它“具体指南”、“实施规程”也是可以的，不同组织有不同习惯。
在上篇中提过，需求阶段是软件安全性工作的重点，今天我们主要介绍根据GJB 102A条款形成的软件安全性需求分析准则。
举例说明，对于GJB 102A条款
“5.3.2 配合硬件或系统设计的考虑事项→h）机械限位控制：
对具有机械安全限位要求的硬件设备，软件应对输入给硬件的控制数据进行极限限位和容错处理，以避免不当的输入信息造成系统安全问题或设备故障。”
实施难点
在工程中实施本条款时，往往产生这样的困难，面对此条款，不知该如何操作，具体来说就是：
不知道该分析什么对象（哪些硬件设备）？
怎么分析（限位要求是硬件，和“软件”功能怎么产生关系）？
分析什么细节（哪些机械安全限位要求）？
使用什么数据分析（极限限位包括哪些情况，参见第三步）？
……
如何把条款中的要求具体化落地？如果不落实这些问题，那么这个条款就有可能做成“虚的”。这就是准则要起的作用。
针对本条款存在较大自由度的内容，研究制定如下的分析准则：
1 针对条款中硬件设备、机械安全限位要求、极限限位 ——
硬件设备 → 软件控制的硬件作动机构；
机械安全限位要求 → 作动机构的机械位置边界，软件需要通过作动机构到软件的输入接口获取；
极限限位 → 软件对作动机构的机械位置边界进行极限限位。
综上，形成安全性分析准则1.1：
软件控制一个作动机构产生位移运动，通过输入接口获取作动机构的机械位置边界，对机械位置边界输入进行检查，分析软件对边界输入处理的正确性，是否对作动机构的机械位置边界进行极限限位。
2 针对条款中输入给硬件的控制数据、极限限位、容错处理 ——
输入给硬件的控制数据 → 软件控制硬件作动机构，向作动机构输出控制指令；
极限限位 → 软件控制作动机构的机械位置边界进行极限限位；
容错处理 → 异常、与功能要求不一致的软件控制指令处理。
综上，形成安全性分析准则2.1：
软件控制一个作动机构产生位移运动。对软件控制指令进行检查，分析控制指令“导致作动机构运动未到达、超出机械位置边界”等情况下输出的正确性；
形成安全性分析准则2.2：
软件控制一个作动机构产生位移运动。对软件控制指令进行检查，分析控制指令“导致作动机构与功能要求的运动起始位置、运动停止位置、运动方向、运动速率不一致”等情况下输出的正确性。
3 针对条款中不当的输入信息、系统安全问题或设备故障 ——
不当的输入信息 → 异常、与功能要求不一致的硬件作动机构控制；
系统安全问题或设备故障 → 硬件作动机构不符合机械位置边界、作动机构故障。
综上，形成安全性分析准则3.1：
软件控制作动机构产生位移运动。对作动机构进行检查，分析当作动机构故障时、与软件控制指令规定的运动起始位置、运动停止位置、运动方向、运动速率不一致的情况；
形成安全性分析准则3.2：
软件控制作动机构产生位移运动。对作动机构进行检查，分析当作动机构故障时、运动不符合机械位置边界要求的情况。
在日常的安全性工作中，可以参考上述方法，建立和积累属于自己专业的软件安全性准则，成为工作的基础和知识。类似这样：
分析准则细化了安全性分析的实施，但要想更落在实处，还需要具体数据的支撑。在安全性这个专业里，就是失效模式数据。每一条分析准则对应一组失效模式数据，通过这些失效模式数据，逐一去分析和评估可能的安全性问题，达到符合标准条款的目的。
失效模式数据来源于对软件历史失效经验的总结：按照分析准则描述的软件要素，从历史经验中归纳失效规律，形成失效模式数据，也就是失效的“等价类”。
举例说明，第二步中的安全性分析准则2.2：
软件控制一个作动机构产生位移运动。对软件控制指令进行检查，分析控制指令“导致作动机构与功能要求的运动起始位置、运动停止位置、运动方向、运动速率不一致”等情况下输出的正确性。
安全性分析准则中的要素：
运动起始位置 | |
运动停止位置 | |
当前位置 | |
机械限定位置 |
历史经验中，这些要素发生过哪些失效规律？总结出哪些失效模式数据？
其他典型的失效模式数据片段，示例如下：
经过失效模式的积累，建立软件失效模式数据库，在软件项目中持续复用、迭代失效模式数据，逐步扩充经验数据，也是支撑标准实施的有效手段。
更多关于失效模式库的内容可参考：软件失效模式数据库的作用。
针对具体软件，从分析准则对应的失效模式中，选出可能发生的失效模式。从这步开始，就可以进入到软件FMEA表格填写的流程了：
针对软件失效模式，由失效模式触发的软件功能出发，分析对软件配置项级功能、软件所处的设备以及系统、乃至系统功能的影响。从系统运行安全与任务完成的角度，识别软件失效可能导致的系统危险。
此外，还要考虑软件向系统的反馈，软件失效有可能影响与之交互的其他硬件设备、系统，也有可能影响软件所在的上级系统、直至整机。
因此，分析软件失效影响时尽可能多考虑：
软件失效是否会导致系统失效？会导致哪些系统失效？
软件失效会不会影响人员操作？误导用户？……
软件失效引起的后果是否会导致危险？
并进一步评估，软件导致的系统危险，系统是否已经通过自顶向下的方式识别，并分配了软件安全性需求，如果没有，是否需要迭代至系统安全性分析过程，例如故障树分析过程？……
等等。
根据软件的安全影响后果，对软件失效模式制定控制措施。
常用的控制措施包括：
功能优化控制措施：选取更优化的功能设计方案，提出新的软件功能或安全性需求。
设计改进控制措施：改进当前功能设计方案，基于当前软件功能需求补充安全性需求。
监测告警控制措施：从监控、诊断、告警提示等角度，提出故障告警的安全性需求。
人工干预控制措施：从人为干预、处理的角度，提出人为操作规范及软件安全性需求，人为操作规范如：用户手册规定强制的操作方式，培训规范的操作流程等。
这些控制措施有些需要软件落实，有些需要系统落实，有些需要硬件落实，有些需要人员落实。可以根据失效的安全影响后果，结合研制成本与资源分配，采用其中一种或多种方式。
需要软件落实的控制，形成软件安全性需求，实现对软件失效的防护，确保软件不导致系统危险发生。
至此，实现了选择标准条款、制定细化准则、使用失效模式数据、形成安全需求的过程。软件安全性分析结果的示意如下（灰色是原始软件需求，红色是安全性分析出的软件失效，蓝色是针对软件失效获取的安全性需求）：
对于已经开展了软件安全性工作的项目，研制人员如何在工程审查及验收活动中，证明软件符合标准要求？
目前在军用型号工作中，此环节既受到用户重视，又缺乏支撑手段。在这里，我们推荐一种举证方法来推动此问题的解决。因为目前标准中没有给出此环节的指导，因此我们称之为 “增量过程” 。
我们对照每一项标准目标，提供针对目标开展工作的证据，包括工作中各项活动的过程和结果的资料性证据（特别是数据），证明已经开展了符合标准要求的工作。
可以利用举证矩阵的形式来实施此工作，对于GJB 102A的符合性举证，我们可以给出如下举证矩阵：
标准目标 | 生命周期阶段 | 活动 | 输出 | 证据 | 结论 |
A | B | C | D | E | F |
A 标准目标：按照“第一步，分析软件特点，确定适用条款”，明确软件适用的标准条款，逐一列举；
B 生命周期阶段：例如计划阶段、需求阶段、设计阶段、实现阶段、验证阶段、验收阶段等；
C 活动：列举对应不同标准目标，已经开展的工作与活动，例如FMEA分析、需求审查、设计审查、代码审查、动态测试、评审等等；
D 输出：列举获得的工作输出，例如软件安全性需求、软件失效的控制措施、用户操作规范等等；
E 证据：提供工作输出有效的证据，应当是具有配置管理标识的文件，例如，《软件失效风险分析报告》、《软件需求规格说明》、《软件设计说明》、《软件配置项/系统测试报告》、评审意见等等；
F 结论：提供“是否符合”标准要求的结论。
举证矩阵示例如下：
软件研制人员完成举证矩阵之后，给出符合标准条款的证据。接下来，对这些证据进行验证的人员登场，给出软件项目是否符合标准的结论。
验证角色可以是：研发组织内部的独立验证人员、外部的专家或验证机构、用户委托验证代表等等，视不同领域工程实际情况而定。比如在某些军用软件领域以评审会的方式进行审查验证，在民用领域则开展了更为规范的委任代表审定或是认证咨询机构审定等等。
根据第六步的输出，通过资料审查、过程复现、质询访谈等方式，回溯第一步输出的适用标准条款是否都得到了符合：
当审查和验证这些安全性证据时，评审是常用的办法，作为评审专家，在有限的时间内做出尽量充分客观的评价也是挑战性工作，此时辅以检查单类似的工具是一个值得推荐的办法。
下面是针对XX电子控制器软件，安全性评审专家使用的检查单片段示例：
这组检查单共分为软件输入接口、功能处理逻辑、工作状态、输出接口等4大类，数据失效、时序失效、通信失效、故障策略、余度策略、设备状态、软硬件耦合、逻辑处理、状态场景等9小类，包含检查内容247项，覆盖适用的GJB 102A条款128项。
至此，下篇内容结束。
- 用户评论