“功能安全产品实现技术”系列讲座第8讲 安全相关产品的软件实现(二)
2014-01-31廖丽华尹宝娟
廖丽华 尹宝娟
(上海工业自动化仪表研究院1,上海 200233;上海仪器仪表自控检验测试所2,上海 200233;环境保护部核与辐射安全中心3,北京 100082)
0 引言
安全相关产品的软件实现的前期工作主要是软件设计,主要包括软件架构设计、支持工具选择、软件系统设计以及编码实现的整个过程。软件设计主要是从软件安全要求规范与E/E/PE系统架构出发,根据其确定的功能需求设计软件系统的整体架构、选取合适的支持工具、划分功能模块、确定每个模块的实现算法以及代码的编写规则,形成具体的设计方案。
当软件执行不同安全完整性等级的安全功能时,所有的软件都被认为属于最高安全完整性等级,除非在设计中表明不同安全完整性等级的安全功能之间的充分独立性。同时应证明独立性在空间域和时间域上均得到实现,或任何对独立性的违背均得到控制,且对独立性的论证应文档化。
在软件的整个设计阶段选取技术和措施时,应考虑软件设计的下列属性:①有关软件安全要求规范的完整性;②有关软件安全要求规范的正确性;③防止固有设计错误;④简单性和易懂性;⑤行为的可预见性;⑥可验证和可测试的设计;⑦故障裕度;⑧抵御外部事件造成的共因失效。
在安全相关软件的实现过程中,也强调软件的验证活动,以保证每个阶段的工作都是正确的。软件的验证活动主要是验证每个阶段的输入、使用方法和准则、输出、进度、资源、风险、假设、作用和职责;验证的标准是前一阶段输出文档的要求和约束条件;验证的目的是判断该阶段的设计结果是否满足前一阶段的目的和要求;整个验证过程必须具有追溯性和重复性。
1 软件架构设计
从安全角度讲,软件架构阶段是软件开发中确定基本安全策略的阶段。软件架构定义软件的主要组件和子系统,包括它们如何实现内部连接,如何获得所要求的属性,特别是安全完整性,还定义软件的整体行为、软件组件的接口和相互作用。主要软件组件包括操作系统、数据库、EUC输入/输出子系统、通信子系统、应用程序、编程和诊断工具等;在某些工业领域中,软件架构可称作功能描述或功能设计规范。
软件架构在组件的非安全失效时受到架构约束的限制,而选取的开发方法不仅应满足该约束,而且要将其应用于开发和严格的确认技术,使其与要求的系统能力保持定性一致。考虑到软件架构设计阶段中输入文档的要求,故其设计还须满足软件安全要求规范和E/E/PE系统硬件架构设计的所有规定及其约束条件。如果软件组件的系统能力低于其提供的安全功能的安全完整性等级,组件应与其他组件组合使用,以使组合的系统能力等于安全功能的安全完整性等级。
软件架构设计的最终目的是创建的软件架构要满足不同的安全完整性等级中对软件安全规定的要求;评价由E/E/PE系统安全相关系统硬件结构对软件的要求对受控设备安全性的影响;为满足要求的安全完整性等级,选择合适的工具集(包括语言和编译器、系统接口、用户界面、数据格式及其表示法),并应用于软件整个安全生命周期的辅助验证、确认、评估和修改。
软件架构设计应由软件提供方、开发人员共同建立和细化,其主要设计内容如下。
(1)为满足软件安全要求规范规定的安全完整性等级,应选择并论证一组必要的技术和措施。这些技术和措施包括故障裕度(与硬件一致)和故障避免的软件设计策略,包括(适用时)冗余和多样性。
(2)根据组件/子系统的划分,对每一部分应提供以下信息:
①组件/子系统是否已被验证,如果是,则需提供它们的验证条件;
②每一个子系统/组件是否安全相关;
③子系统/组件的软件系统性能力。
(3)确定所有软件/硬件相互作用(已由系统架构决定),并评价和细化它们的重要性。
(4)使用符号表示法表示清楚定义的或限制清楚定义特性的结构。
(5)选择用于保持所有数据安全完整性的设计特性。这种数据可包括装置输入/输出数据、通信数据、操作界面数据、维护数据和内部数据库数据。
(6)规定适当的软件架构集成测试来保证软件架构/系统满足软件安全要求规范要求的安全完整性等级(需要硬件开发人员参与)。
软件架构设计阶段的验证活动完全结束后应产生的文档有:软件架构设计、软件架构集成测试规范、软件/可编程电子集成测试规范与系统安全相关软件方面的确认计划。
2 支持工具
软件支持工具可以分为在线工具与离线工具,在线支持工具应作为安全相关系统的软件组件来考虑,而离线支持工具只作为软件开发活动相关的密切相关部分。在开发过程中,应当使用合适的离线工具支持软件开发,通过降低引入或无法检测到故障的可能性来增加软件的完整性。
软件开发生命周期阶段包括以下相关工具。
(1)转换或翻译工具,将软件或设计表述从抽象级别转换到另一个级别,设计优化工具、编译器、汇编器、链接器、打包器、装载器和代码生成工具。
(2)验证和确认工具,例如静态代码分析器、测试覆盖监视器、原理证明辅助工具和仿真器等。
(3)诊断工具,用于在运行条件下维护和监视软件。
(4)基础设施工具,如开发支持系统。
(5)配置控制工具,如版本控制工具。
工具确认结果应文档化并包括以下内容。
(1)确认活动按时间先后顺序记录。
(2)所用工具产品手册的版本。
(3)被确认的工具功能。
(4)使用的工具和设备。
(5)确认活动的结果,确认的文档化结果应陈述软件已通过确认或失败的原因。
(6)测试用例及其后续分析的结果。
(7)预期结果和实际结果的差异。
开发所有安全相关软件的编程语言应根据合适的编程语言编码标准来使用。编程语言编码标准须规定良好的编程习惯,禁止不安全的语言特性(例如:未定义的语言特性、非结构化设计等),促进代码的可读性,便于验证和测试,并指定源代码文档化的规程。
3 软件系统设计
软件系统设计主要是将软件架构中的主要组件划分为一个软件模块系统;规定适当的软件系统集成测试,以保证软件系统满足在所要求安全完整性等级上的软件安全要求规范;设计并细化软件模块。以结构化方法设计软件仍是一种良好的实践,包括将软件组织成模块化的结构,并分离出安全相关部分;包括范围检测和其他预防数据输入错误的特性、使用以往确认过的软件模块并能提供便于未来软件修改的设计。最终生成的软件应具有模块化、可测试性和可安全修改的能力。
进入软件设计阶段的输入文档及要求:E/E/PE安全相关系统的要求规范、软件架构设计、支持工具和编码标准、开发工具的选择与系统安全相关软件方面的确认计划。
对于软件架构设计中的每一个主要组件/子系统,设计的进一步细化不仅应根据基于软件模块的划分,而且应规定每个软件模块的设计以及应用于每个软件模块的验证。如果使用已知系统性能力的软件组件组合来执行安全功能,应对组件组合应用软件架构的系统性能力要求。已有软件可能是依照本标准的要求进行开发的,但也可能不是,所以当一个已有的软件组件被复用实现所有或部分安全功能时,为确保系统的安全完整性,该组件应同时满足以下要求。
(1)适用于运行时库程序或一个解释程序。
(2)满足以下符合性路线之一。
①路线1:符合性开发,符合本标准的要求,以避免并控制软件中的系统性故障。
②路线2:经使用证明,提供组件已在使用中证明的证据。
③路线3:非符合性开发评估。
(3)提供安全手册以给出足够精确和完整的组件描述,使得一个整体或部分依赖于已有软件组件的特定安全功能的完整性评估成为可能。
为遵守路线3,一个已有软件组件应满足下列要求。
(1)组件的软件安全要求规范在其新应用中应文档化。
(2)软件组件的使用论证应提供满足规定的期望安全属性的证据。
(3)组件设计应文档化,并具备一定程度的精确性和充分性,以对其符合规范要求和所需系统性能力提供证据。
(4)(1)和(2)所需的证据应覆盖硬件与软件的集成。
(5)应有证据表明,组件已采用系统性方法进行验证与确认,该方法包括文档化的测试和对所有组件设计和代码的复审。
(6)如果软件组件提供安全相关系统中不需要的功能,那么应提供证据表明不需要的功能不会阻止E/E/PE系统满足其安全要求。满足此要求的方法包括:从构造中移除这些功能、禁止这些功能、适当的系统架构、广泛的测试。
(7)应有证据表明已经识别了软件组件的所有可信失效机制并采取了适当的缓解措施与异常处理。
(8)组件使用计划应识别软件组件的配置、软件和硬件运行时环境和编译/连接系统(如有必要)。
(9)使用组件的论证仅对应用遵从组件符合项安全手册所做的假设时有效。
好的软件系统设计应能提高模块的独立性,例如:模块规模适中,合适的深度、宽度、扇出和扇入,模块的作用域应在控制域之内,降低模块接口的复杂性,模块功能可以预测但也要防止其过分局限;尽量做到高内聚、低耦合。
软件系统设计阶段的验证活动完全结束后应产生的文档有:软件系统设计规范、软件系统集成测试规范、软件模块设计规范与软件模块测试规范。
4 编码实现
软件的编码除了要符合已选择的开发工具中的编码语言外,还要选择与其相应的编码标准,并符合开发语言与测试工具的一些行内规则。其规则总结如下。
(1)编写“README”文件,列出条件编译开关,与机器相关、芯片相关、版本的文件等信息。
(2)每个函数前加入注释块,描述函数功能、输入参数和返回值,必要时应说明其功能、用法、重要设计决策与作用。
(3)对每个变量加以短注释。
(4)每个小代码段前注释其功能或作用。
(5)有些关键变量的范围控制采用断言编程。
(6)避免看上去不易区分的标志符。
(7)缩略格一律使用空格键,而不要用制表键。
(8)代码段不应被“注释掉”;当源代码段不需要被编译时,应该使用条件编译来完成。
(9)删除一切不需要的代码,尽量优化。
(10)函数的嵌套层次要控制在3层及3层以内。
(11)函数的行数尽可能控制在200行以内。
(12)函数的参数个数尽可能不要超过5个。
5 结束语
本文所述安全生命周期的阶段可以根据功能安全相关产品的软件系统的大小进行裁剪。在小型系统中,软件架构设计和系统设计可整合在一起。在大型系统中,支持工具和编码标准可用独立的文档说明,否则可以衔接在软件架构设计后面或者软件系统设计前面,但是一定要在这两个阶段之间详细论证选取的方法及理由。