不同行业的软件安全标准介绍和对比_do-178下载

本文链接：https://blog.csdn.net/2401_84264662/article/details/138295307

EN 50126 和 EN 50129 关注系统层需求， EN 50128 关注软件层需求

预告：下一篇讲继续介绍基于以上标准，各个行业的认证、鉴定、信用批准，以及各个标准的技术比较。

【参考文献目录】

Emmanuel Ledinot(1), Jean-Marc Astruc(2), Jean-Paul Blanquart(3), A cross-domain comparison of software development assurance
P. Baufreton1, JP. Blanquart2, JL. Boulanger3，Multi-domain comparison of safety standards，2010

引言

上一篇文章简要介绍了各个行业主要的安全标准，这一篇继续分享— 基于各行业的安全标准，怎样进行软件认证、工具鉴定、信用批准等方面。

首先，我们来看两个概念----

认证 Certification Vs. 评估 Assessment

谈到安全标准，我们就避不开两个基本概念：认证和评估。

评估 Assessment： 为某个实体（个人、组织或人工产品）授予某置信水平的一系列活动。其有效性依赖于：项目、参与者、使用情况、时间线。
认证 Certification: 评估申请人向认证机构证明其工程过程，表明制造商通过遵守安全标准来确保对安全目标的监管。认证旨在验证在一个领域（如能源或运输）提供安全关键产品或服务的工业行为者确实提供了安全的产品或服务。认证涉及申请人，标准条例，管理局和必须独立或部分独立于申请人的评估机构。

大多情况下，这些标准条例是由国际组织成员国设立的，成员国同意建立共同的规则来防止共同的风险。比如： ICAO在民航，IAEA核工业，联合国在航天工业。某些情况下，标准条例在国家级生效，然后在国际层面上解决跨境互操作性问题。比如铁路行业，欧洲成员国目前正在执行标准的统一进程 — 相互接受其国家证书。

*注意：工业领域的认证并不会导致责任从申请人转移到认证机构。在发生严重事故的情况下，涉及的制造商或服务提供者是唯一可以起诉的实体。*

此外，还有一个概念也经常被提及，那就是鉴定 Qualification：

鉴定针对**特定项目中的特定任务，**是为一个实体（可以是一个组织、一个人、一个工具）提供置信水平的一系列活动。

例如，用鉴定来确保通过使用工具自动化的软件生命周期过程将导致与手动执行过程相同或更高质量的输出。

目前，无论是航空、轨道、汽车等领域，还是工业领域，都对工具使用有着特别的要求，如果通过使用工具，消除或者自动化了部分人工工作，都需要根据所涉及的软件安全级别，对所使用的工具进行相应等级的工具鉴定。这实际上是把软件开发人员的部分工作转移到了工具开发商那边。

各行业对评估和认证的信用批准

根据各行业的不同情况，管理局和评估机构可能是同一机构（例如，民用航空局的FAA和EASA），也可能只有颁发证书的机构，但没有与申请人（例如工业自动化和航天业）独立的评估机构的情况。

申请人和评估机构之间的利益无关，是核工业（IRSN）、铁路（ERA，EPSF，STRM-TG）和航空（EASA-FAA）认证的关键要求。

航空

由FAA或EASA等独立机构负责飞机及其嵌入式系统的安全认证。

认证通常适用于飞机或发动机类型。

认证机构将软件视为安装在认证飞机或发动机中的机载系统或设备的一部分; 也就是说，认证机构不会将该软件作为唯一的独立产品。目前，计算机硬件和软件必须做为每次安装的一个“系统”被批准。

航天

适用于欧洲航天领域的一系列标准，由ECSS、欧洲航天标准化合作，欧洲航天局，国家航天机构和欧洲工业协会为发展和维持共同目标而合作制定。

ECSS标准不是法律强制的，而是通过合同逐案提出、采用、修改。这并不意味着航天业不会以更严格的方式进行认证 — 大多数国家对于在其领土上发射的航天设备，都制定了与发射装置、航天器、发射程序有关的特定法律规则，以及相应的许可证制度。

汽车领域

SAE ISO 26262提供了一系列要求，即所谓的确认措施，以确保对E/E方面的安全性进行适当的评估。

执行确认措施的行为人员应具有与负责发展和释放生产的人员的最低程度的独立性。 **ASIL（汽车安全完整性等级）**越高，所需的独立性就越高。值得注意的是，所需的最高独立性, 可能允许在同一家公司内。

确认措施包括：

**安全评估，**以验证关键的可交付成果，

安全审计，以验证过程的适当性，

评估整个安全项目的安全评估。

轨道交通

主要认证标准是法律要求的欧洲铁路标准 CENELEC 5012x系列标准，它们是欧盟铁路行业的“实践守则”，也是铁路安全相关应用审批的先决条件和促进市场准入的国际标准，在欧洲各国具有法律的约束力。

认证和鉴定根据符合特定标准和/或规范要求确定。可能需要第三方认证，或进行自我评估。

比较成熟的评估体系包括：英国CASS安全评估框架、德国TUV评估体系等，他们主要以EN铁路标准为基准，依托第三方评估机构对已有线路和在建项目的进行安全性论证。

工业自动化

标准IEC 61508 不提供任何类型的认证。

欧洲机械业指令（EMD）要求完成具有CE标识的认证 — 由制造商完成自我认证。

核工业

所有使用核能的国家都设立了安全管理局，以控制其使用，保护人民和环境免受辐射的有害影响。比如在法国，安全管理局是ASN大学，其技术支持是无线电保护和核保安学院（IRSN）。核电厂不是去提交“认证”申请，而是通过授权运营。根据ASN的提案，授权必须通过政府的正式法令。

一张图总结：

各行业的申请人、评估机构与认证机构

我们可以看到，通常在航空、轨道、航天、核能领域，都要求由独立的第三方机构进行认证，而自动化、汽车领域，并没有强制要求第三方认证（近年来，汽车行业随着自动驾驶的快速发展，安全性要求进一步提升，已经有改变的趋势）。

不同行业，评估和认证独立性要求严格程度递增

预告：不小心写太长，下一篇继续介绍各行业标准的技术比较。

【参考文献目录】

Emmanuel Ledinot(1), Jean-Marc Astruc(2), Jean-Paul Blanquart(3), A cross-domain comparison of software development assurance
P. Baufreton1, JP. Blanquart2, JL. Boulanger3，Multi-domain comparison of safety standards，2010

引言

上两篇文章简要总结了不同行业的软件安全标准概况和认证、取证，这篇接着来说说各个标准在技术上的具体差别。

Jessie Yang：不同行业的软件安全标准介绍和对比（上篇）9 赞同 · 0 评论文章

Jessie Yang：不同行业的软件安全标准介绍和对比（中篇）5 赞同 · 0 评论文章

各个标准的软件安全标准技术比较

不同行业对于软件安全的标准和要求各有特点，基本上可以从几个方面来做个比较和总结：

集成安全系统 Vs. 独立安全系统
规定目标 Vs. 规定方法
严重程度和保证级别分类
容错或故障预防
概率评估与确定性分析
安全案例

1)集成安全系统 Vs. 独立安全系统

根据不同应用和领域，“安全”是通过不同架构来确保的。

比如，核电、机械自动化、航天和轨道领域通常采用一个专门的安全系统：安全由一个相对独立的系统来监控和保证，与执行所需功能的系统区分开来。而汽车和航空领域，安全性通常是“集成”在功能系统中。

在具体实践中，这种选择是根据风险与保护系统的结构来确定。例如，如果没有特定的安全状态，分离的保护系统是没有作用的，因为在保护系统故障时，不可能将受控设备驱动到安全状态。因此，必须专注于安全控制系统，而不是去开发专用的独立保护系统。

汽车行业，硬件成本是关键的设计驱动。因此，不会考虑专用的独立保护系统。在大多数应用中，控制系统提供内置机制来检测故障并将系统置于安全状态。在某些情况下，当可以使用另一个系统的现有功能作为保护机制时，则会考虑外部安全。

2）规定目标 Vs. 规定方法

各个安全标准，或者对满足高级别安全目标的方法进行规定，或者对目标进行规定，至于方法，则完全由申请人负责。

**方法规范性标准，**在严格按照作者所设想条件的情况下，易于使用。然而，它不能很好地应对新技术、方法和工具的出现。
目标规范性标准可适用于各种技术、生命周期、工具等，但需要在使用前进行解释 ; 并且解释可能存在问题，可能与标准作者的意图有很大差异。

在这两个极端之间，不同的标准采取了各种立场：

IEC 61508和EN 50128是指定方法的，因为它“建议”、“强烈建议”甚至“命令”具体的方法来实现安全目标；

ED-12 / DO-178 一般认为是目标性规定标准；

ISO / DIS 26262和ECSS，通过建议技术方法，混合了一些针对目标的要求。

3）严重程度和保证级别分类

在各个行业领域中，标准都有 “级别”的分类，比如安全完整性级别、关键类别等。其思想是将系统（或功能，组件等）与潜在故障的最坏后果（严重程度）相关联 ，某些领域（例如汽车）里，可能与曝光频率相结合。经典的基于风险评估的方法中，每个“级别”对发生故障的可能性设置了限制，从而将风险控制在可接受的范围内。

关键类别通常都是分配给功能, 这样就定义了用于开发（和验证）该功能的实施元素（系统\硬件\软件项目）的（部分）需求，以便针对不同类别适当地处理可能的故障来源：

随机硬件故障：对于每个类别，安全标准定义了目标最大故障率、导致故障的最小独立错误数。
影响系统、硬件或软件设计的开发错误：安全标准定义了适用于所有开发和验证过程的要求，特别是开发和验证流程。对于不同的关键类别（或类似概念)，有着不同的要求，定义不同的DAL（开发保证级别）。其思想是，不试图量化评估由于这些错误而导致的故障概率，而是考虑满足这些要求，提供了与风险严重程度相当水平的信心。

所有标准在基本原则上都是一致的，并且都认为必须强制隔离不同级别元素之间的故障传播。但是，针对如何对后果的严重程度定义和排序，以及如何分配关键类别（例如，是否以及如何，通过在较低级别采用某种冗余方案，来实现某个级别的功能），标准之间存在着明显的差异。

IEC 61508 分为SIL 1-4 ，EN50128分为SIL 0-4 ，ISO / DIS 26262分为ASIL A，B，C，D
ED-12 / DO-178 分为 DAL A，B，C，D ，其中A级针对灾难性后果，为最高级别

每个类别相关的要求甚至其性质也存在差异。

ED-12B / DO-178B对不同的级别规定了过程目标
IEC 61508或EN 50128明确列出了不同级别推荐的技术
ISO / DIS 26262和ECSS，通过建议技术方法，混合了一些针对目标的要求。

4）容错和故障预防

基本上，各个领域中，容错都是在系统级别要求，而不是在软件层面进行要求：软件标准基本上针对如何实现无错误的软件，或明确规定（IEC 60880 或 EN 50128），或隐含要求（ED-12 / DO-178等），通常是通过对过程（例如，清晰全面的文档、遵守规范、设计和代码标准）和产品（例如，验证、确定性结构、管理并行性、完全由输入确定功能的行为）提出要求。

软件标准（如 IEC 60880）通常要求的自检，主要面向随机硬件故障的检测，例如内存损坏或传输错误。在检测到故障的情况下，标准不要求继续正常处理，但要求采取预定义的行为（例如，将输出设置到安全位置）。软件不考虑对自身错误的容错，因为检测和重新配置算法，可能比功能软件本身更复杂，反而增加错误的可能性。

IEC 60880等标准要求自检不会对预期功能产生不利影响。
轨道行业标准 CENELEC EN 50128 指出，不建议软件的向后和向前恢复、动态重新配置和/或故障校正。

**在系统级别或顶层架构上，可以通过冗余设计，实现对潜在软件容错。**例如，系统内的次计算机可以监视主计算机，并使用不同的算法检查其输出的合理性，或者基于涉及不同物理测量的不同算法，两个不同的系统可以独立地触发给定的安全动作。这些架构解决方案之间的选择主要取决于底层受控过程的特征。

5）概率评估与确定性分析

航空，自动化，汽车，核能，铁路和航天领域的可靠性标准中，系统故障风险量化方法是相同的。

各个领域的标准都没有要求/支持对软件故障的概率评估。与硬件相反，软件被统一视为确定性的人为因素，功能故障只会由规范、设计或实现中的错误引起。 因此，软件安全的建设、评估和衡量，通过设计保证来统一处理 ---- 通过基于流程和产品开发活动的标准组合来实施。各个标准根据不同质量和开发活动目标，对于回避开发缺陷的策略的严格程度可分为3~5个级别。但是，每个级别的残余故障或功能障碍无法量化，对于可能引发系统故障的残余软件故障，是通过容错机制来处理的---- 这些机制无论是在软件还是硬件中实现，仍然是确定性的。

概率评估一方面可以量化组件级硬件故障的可能性，另一方面，可以量化系统级别针对用户的灾害事件的可能性。所有的标准都在系统级别，根据灾害事件的严重程度来设置基于概率的目标，从而防范这些事件。

基于“分而治之”的策略，作为实践中唯一易行的方法，各个标准明确或暗示推荐，针对系统级失效行为的概率评估方法不依赖于系统级行为分析 ---- 而是依赖于架构建模，其中可能包括时间依赖的容错重配置逻辑，通过可靠性图表、故障树或状态机捕获事件到功能、功能到部件的依赖关系。

所有标准中，一方面，由设计保证策略规定局部行为（硬件或软件）的确定性分析，另一方面，基于严重程度的概率目标规定了通过“全局功能 – 部件”依赖关系图对事件进行概率分析。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！