安全分析在软件开发中的应用及安全关键Java的任务模式

# 安全分析在软件开发中的应用及安全关键Java的任务模式 ## 1. 安全分析在模型驱动开发中的应用 ### 1.1 安全依赖与逻辑门表示 在安全依赖中，由于缺乏更多信息，对于更高级别的安全感知组件或功能的故障，我们需假设最坏情况并使用“或”门。即只要支持该门的组件中有一个发生故障，该门就会输出“真”。而缓解措施是根据风险降低程度来阻止故障传播，用“与”门表示，只有缓解措施定义中声明的故障模式才会被缓解。 ### 1.2 示例分析 以“Consult SFPL (System Flight Plan)”这一功能为例，它需要满足安全目标“SO_1: The probability of detected and undetected corruption for greater than 5 minutes shall be no greater than 10 - 5 per hour”。该功能由“FDM (Flight Data Management)”组件支持，为实现安全目标，采用了缓解措施“MM_1: Processing servers are replicated on different nodes”。 通过安全配置文件，将约束SO_1与“Consult SFPL”功能关联起来。在模型转换中，将组件表示为带有“SafeAwareComponent”构造型的包，用带有“MMApplied”构造型的约束表示MM_1的应用。 在故障树分析（FTA）中，“Consult SFPL”和“FDM”映射为“或”门产生的派生事件，“FDM”的“Error”和“Loss”故障模式映射为基本事件。由于“Corruption”故障模式已被缓解，使用“与”门来降低其发生概率，即只有当该故障模式发生且缓解措施未能阻止其传播时，“FDM”的损坏才会在系统层面显现。 这个简单示例在系统模型较小时，可手动在安全工具中创建FTA。但当系统模型增大或需要保持系统模型与安全分析的一致性时，自动生成安全分析的优势就会凸显。在验证中，对包含21个安全感知功能、19个安全感知组件、5个缓解措施定义和9个缓解措施应用的大型安全模型进行了测试。 ### 1.3 分析结果评估 安全分析的最后一步是安全人员在安全工具中对分析结果进行评估。安全工具会提供表格（FMECA）、树（FMECA）和图表（FTA）来展示模型。安全分析师可通过这些来检查架构中与安全相关的元素如何协同工作。 FMECA可通过设置系统故障模式的严重性来指示功能故障模式的严重性。FTA可提供最小割集列表，即共同发生会导致危险的底层故障组合，尤其要关注只有一个元素的组合。 安全分析的一个目标是为安全感知组件分配软件保证级别（SWAL）。降低组件的SWAL可降低其开发成本，但需提供合理依据，如安全分析和缓解措施。为组件分配SWAL并不意味着计算软件的故障率，因此SWAL不能像硬件故障率那样用于安全评估过程。对于硬件，可在安全分析模型中将组件的SWAL映射为故障率，从而使安全工具提供量化结果。 ### 1.4 当前实现场景 目前需要集成UML建模工具和安全工具。采用Eclipse Modeling Framework (EMF) 作为通用框架，用于创建元模型、实例存储库和实现转换。具体操作步骤如下： 1. 使用UML建模工具（UML 1.X或UML 2.0工具）创建ATM模型，定义和部署配置文件，并将模型导出到EMF。 2. 使用安全工具的FMECA和FTA模块进行分析计算、生成报告等。 其实现场景的流程可用以下mermaid流程图表示： ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A(UML元模型):::process --> B(UML模型):::process C(外部模型):::process --> B B --> D ```