CN102779253A - 一种基于图尔敏模式的软件安全性论证方法 - Google Patents

Abstract

本发明公开了一种基于图尔敏模式的软件安全性认证方法。该方法以需要认证的软件安全性目标为核心，提供支持目标成立的事实证据，质疑时，给出赋予事实证据支持目标成立的正当理由及用于强化正当理由权威性陈述的支援；如目标不是完全成立，则需明确目标实现程度的限定词；给出阻止从正当理由得出目标成立的反驳，从而实现以软件安全性目标为核心的安全性认证方法。本发明是一种更自由更宽泛的软件安全性论证方法，能更直接更清晰地表明软件安全性目标是如何满足的，同时能更有效地促进开发方开展安全性保障工作的积极性，从而更主动地提高了软件安全性。

Description

一种基于图尔敏模式的软件安全性论证方法

技术领域

本发明属于软件安全性工程领域，涉及其中的软件安全性论证方法，具体涉及一种基于图尔敏模式的软件安全性论证方法。

背景技术

安全性是指不发生导致人员伤亡、职业病、设备损坏或财产损失的意外事件的能力。安全关键系统（Safety-Critical System）的控制和安全防护是计算机的一个非常重要的应用领域。随着安全关键系统中软件（被称为安全软件（Safety-CriticalSoftware））比重的增加，软件也存在安全性问题，因此，安全关键软件在投入使用前对其进行认证，判定是否达到了系统所要求的安全性是一项基本要求。

目前，对于软件安全性论证国内外不同行业有不同的标准，例如民航的DO-178B[1]、铁路的EN 50128[2]、美军的NASA-STD-8719[3][4]及三军联合手册[5]等。这些软件安全性标准从实际可操作的角度更加深入地认识到保证软件系统安全的难度。由于技术的不成熟，目前标准中很少包含软件的定量（基于概率的）安全性论证，而是定义了软件安全认证所需的实践。虽然这些标准在提倡的技术和验证的方法等一些细节上存在不一致，但论证的基本原理是一致的：根据提供软件安全性工程过程的一些证据（Evidence）来表明软件的安全性达到了相应的要求，这种面向过程的完全遵循标准的安全认证存在不足：一方面是要求遵循的开发过程、工具和技术与软件失效率的降低之间没有必然的联系，是如何满足软件安全性要求并不清楚；另一方面容易造成这样的误解：软件安全性由标准的制定者负责，而不是软件的开发方。

图尔敏模式[6]是非形式逻辑刻画日常论证的一种重要方式，是由英国的非形式逻辑奠基人图尔敏提出的。图尔敏提出了一个由主张(claim)、资料(data)、正当理由(warrants)、支援(backing)、限定词(qualifier)和反驳(rebuttal)等6个功能要素构成的过程性模式,称为图尔敏论证模式。其中,主张、资料和正当理由作为图尔敏论证模式的基本证中都必须出现,构成了论证的基本模式。支援、限定词和反驳对于所有的论证来说并非必然出现,称为补充要素。随着非形式逻辑研究在我国的兴起，越来越多的学者已经关注图尔敏模式。

发明内容

本发明为了克服现有的软件安全性论证方法的不足，将图尔敏模式的论证思想运用到软件安全性论证领域，以安全性目标（Claim）为核心，软件安全性工程活动为事实证据（Evidence），链接安全性目标与证据是正当理由（Warrant），说明事实证据是如何支持目标的成立；而事实证据则是支持正当理由，为正当理由提供事实依据。本发明给软件安全性论证提供了一个全新的、有效的视角。

本发明提供了一种基于图尔敏模式的软件安全性论证方法，该方法包括以下步骤：

步骤1：提出软件安全性论证目标（Claim），即试图在软件安全性论证中证明为已经满足的结论。

步骤2：提供支持软件安全性论证目标的事实证据（Data）。如果受到质疑，则需要转入步骤3，否则转入步骤5。

步骤3：给出赋予该‘事实证据’具有导出‘软件安全性论证目标’结论的资格的推论规则，即“正当理由(Warrants)”。如果受到质疑，则转入步骤4，否则转入步骤5。

步骤4：明确正当理由背后起保证作用的支援（Backing），用于强化正当理由权威性的支援性陈述。

步骤5：给出“软件安全性目标”实现程度的限定词（Qualifier）。

步骤6：如果存在，给出阻止从正当理由得出目标成立、具有保留机能的陈述的例外情况或反驳（Rebuttal）。

所属步骤1中的软件安全性论证目标是一个断言或断定（assertion），是用来指所陈述的、试图在论证中证明成立的结论的术语。软件安全性论证目标是二元的，只能成立或不成立，不存在第三种情况。如“代码中不存在死循环”。这就是正确的软件安全性论证目标，而“代码中存在多少错误”就不是一个正确的目标，因为它是无法去论证的。

为了更好地理解所属步骤1中的软件安全性目标，可以在软件安全性目标确定时补充有助于理解的相关附属信息，包括软件安全性论证目标所提时的背景信息、包含的术语及缩略语等。目标要被论证，那么它就不能让人存有疑问，必须对目标涉及的所有需要解释的术语进行实例化。如目标“软件的安全性是可接受的吗？”，为了更好地论证目标，就需要对“软件”、“可接受”两个概念做出界定。

所属步骤1中的软件安全性论证目标的获取离不开系统环境。软件安全性要求源于系统的安全性要求。软件是否安全，最终需通过系统体现出来。因此，论述一个软件是否安全应该看其是否会对系统的安全性产生影响。获取软件安全性论证目标的具体过程包括：1）：明确整体系统的整体风险；2）明确可容忍风险水平；3）获取必要的风险降低；4）根据必要的风险降低进一步明确整体系统的安全性要求；5）确定系统中软件的安全性要求；6）转化为软件安全性论证目标。

所属步骤2的事实证据是论证软件安全性目标成立的首要工作。事实证据一般为与软件安全性工程相关的一些活动的记录或产生的数据，如安全性分析结果、测试数据等，可以用于支持软件安全性论证目标，是软件安全性论证的基础和根基。为了更好地理解所提供的事实证据，必要时，也可对其相关的附属信息进行说明。

即使提供的事实证据是正确并且是充分的，有可能还无法使接受方接受软件安全性论证，一般也会受到这样的质疑：为何“事实证据”能支持“软件安全性论证目标”的成立，支持的理由或规则是什么？可能追问“软件安全性目标”和“事实证据”是否具有必然的关联性，“事实证据”是如何证明“软件安全性目标”的实现，此时，需要提供正当理由。

所属步骤3中的正当理由是指能赋予“‘证据’事实具有导出‘软件安全性论证目标’结论的资格”的推论规则，即“证据”和“目标”之间具有的关联性。如目标“软件的开发符合DO178B标准”，正当理由可以定为“DO178B标准中的规定”。同一个目标可以用多种不同角度的正当理由进行分解。为了更好地理解所给出的正当理由，必要时，也可对其相关的附属信息进行说明。

在论证过程中，当质疑正当理由的合适性“为什么相信这个正当理由是有道理的？”，需要提供正当理由的支援。

所属步骤3中的正当理由的开发可以从软件安全性需求、软件安全性部件和软件安全性代码层面进行着手。从系统角度提出的软件安全性要求都将进一步分析并最终转换为软件安全性需求，所以，论证软件安全性目标的实现可以论证软件安全性需求层面的实现。而软件安全性需求还将向前链接到设计和源代码。为了使认证更为充分，软件安全性正当理由可以进一步考虑软件安全性部件和软件安全性单元层面的实现。

对于每一个层面，首先需要考虑每个层面的元素的获取，之后从验证/确认（评审、分析和测试）的角度说明每个级别元素的正确实现。软件失效模式在验证/确认中起着非常关键的因素，只要表明对应的各种失效模式均不发生时即可说明各个级别元素的实现。

所属步骤3中的软件安全性需求获取是正当理由开发的起点。软件安全性需求获取可以直接从系统所提的软件安全性要求映射到软件安全性需求，也可通过SFTA、ETA、STPA等分析方法从自顶向下补充软件安全性需求，亦可对软件需求进行SFMEA、HAZOP等分析方法从自底向上补充软件安全性需求，还可根据软件具体特点从软件安全性通用需求库选择补充软件安全性需求。

所属步骤4中的支援是用来强化正当理由权威性的支援性陈述。为了提高所属步骤3中正当理由开发中所提的验证/确认结果的置信度，即评审、分析和测试的结果更可信，需要进一步从人员素质、软件工具的使用情况、软件过程的规范性、软件方法的正确性和软件相关环境的合理性等过程因素进行正当理由的支援。

所属步骤5中的限定词回答了“对达到目标有多大程度地确信”，表明了“事实证据”借助“正当理由”对“目标”支持的力度或程度。正当理由有不同的种类，授予它们所证明的目标以不同程度的说服力。一些正当理由能担保毫无疑义地接受一个目标，即可以用副词“必然”来修饰主张，或者省略限定词;而另一些正当理由却只能担保从证据到目标的步骤或者是试验性的，或者是需要某种条件的、允许例外，或者有所限制。这时，就需要用其他的限定词，如“大概”、“可能”、“或然”、“百分之五的确信度”等来修饰目标。在论证开始，可能有大量的建议是不完全确定的，它们作为一种“可能性”，是承认它们有权被考虑。

采用基于图尔敏模式进行软件安全性论证的优点：

（1）能更直接更清晰地表明软件安全性目标是如何满足的。该方法是基于目标的、采用一定推理规则的、依此提供事实证据支持的一种安全性论证方法，对目标的实现更为直接，用合理性理由对目标的实现更为清晰。

（2）能更有效地促进开发方开展安全性保障工作的积极性。该方法要求开发方提供事实证据用来支持软件安全性目标的实现，若需要，还应提供相应地正当理由、支援、反驳及限定词等信息，从而将软件安全性的责任更多地转移给软件开发方，能更好地提升开发方开展安全性工作的主动性。

（3）是一种更自由更宽泛的安全性论证方法。该方法不局限具体的软件开发技术、开发过程等，可以根据软件具体的特点，围绕软件性性论证目标，采取适合软件本身的软件方法。

附图说明

图1是软件安全性论证模式示意图；

图2是软件安全性论证目标获取流程图；

图3是软件安全性需求获取流程；

图4是软件安全性论证正当理由开发方法。

具体实施方式

下面结合附图和实施例对本发明进一步说明。

为了便于本领域普通技术人员理解和实施本发明，下面结合附图对本发明作进一步详细、深入地描述，应当理解，此处所描述的实施例仅用于说明和解释本发明，并不用于限定本发明。

图1描述了基于图尔敏模式的软件安全性论证模式。软件安全性目标是软件安全性论证最终要满足的对象，软件安全性论证是围绕软件安全性目标进行的：

软件安全性论证模式包括七元组：<Claim,Data,Warrant,Backing,Qualifier,Auxiliary Info,Rebuttal>，其中：

1）Claim代表软件安全性目标，能用是/否来回答的一个断言。

2）Data代表与软件安全性相关的事实证据，用来支持软件安全性目标。

3）Warrant代表正当理由，提供支持软件安全性目标的推理规则。

4）Backing代表支援，用来支持正当理由。

5）Qualifier代表限定词，用来表示软件安全性目标成立的程度。

6）Auxiliary Info代表附加信息，用来对Claim、Data及Warrant进行补充说明。

7）Rebuttal代表反驳，是软件安全性目标成立的例外情况。

软件安全性论证过程如下：

首先，需要提供支持“软件安全性目标”的“事实证据”，有一定的事实组成，必要时，提供与其相关的辅助信息进行补充说明；

其次，当质疑“事实证据”支持“软件安全性目标”实现的推理规则时，提供相应的正当理由，在“事实证据”和“软件安全性目标”之间起桥梁作用。“正当理由”是一个推理许可，用以说明“事实证据”是如何支持“软件安全性目标”；而“支援”反过来支持“正当理由”；“附属信息”对“正当理由”进行补充说明；

然后，根据已有的“事实证据”和“正当理由”，给出“软件安全性目标”成立的“限定”，表示“事实证据”通过“正当理由”提供给“软件安全性目标”的力量大小。

最后，对于“软件安全性目标”成立有例外的条件，则需提供为“软件安全性目标”论证提供“反驳”。

图2描述软件安全性论证目标的获取流程。软件安全性的讨论离不开系统环境，软件安全性要求源于系统的安全性要求。软件是否安全，最终需通过系统体现出来。因此，论述一个软件是否安全应该看其是否会对系统的安全性产生影响。软件所属整体系统中除受控设备外，可能包含若干可编程电子安全相关系统与和其它技术安全相关系统（比如减压阀）。对于危险的控制可由可编程电子安全相关系统、其它技术安全相关系统和外部安全设施来完成。只有将软件与所在的系统结合起来考虑，分析软件安全性才有意义。获取软件安全性论证目标的具体流程包括：

步骤1：明确整体系统的整体风险

通过初步危险分析（PHA）、功能危险分析（FHA）或其它的危险分析方法获取系统危险，分析危险的后果和可能性，明确整体系统的整体风险。

步骤2：明确可容忍风险水平

根据当时具体情况明确系统中哪些风险可接受和容忍的。

步骤3：获取必要的风险降低

根据系统的整体风险和可容忍风险确定哪些风险必须降低或消除，从而达到系统的可容忍风险水平。

步骤4：根据必要的风险降低进一步明确整体系统的安全性要求

步骤5：确定系统中软件的安全性要求

在系统的安全性要求，明确哪些是软件的安全性要求。软件安全性要求一般包括二个方面：1）危险原因，能引起危险；2）危险控制，用于预防危险、降低危险发生可能性或者降低危险影响。如果这些需求不执行，或者执行不正确，或者不按规定顺序执行就可能导致危险发生或使危险状态存在。

步骤6：转化为软件安全性论证目标

软件安全性要求需要进一步转换成具有主谓结构的软件安全性论证目标，还应进一步补充诸如背景、术语和缩略语等辅助信息，以便进一步理解安全性论证目标。

图3描述了软件安全性需求获取流程。从系统角度确定的软件安全性要求将随着软件开发进一步转化为软件安全性需求，更好地指导后续的软件开发。

软件安全性需求从各种不同的来源中获得，通常可以分为二类：通用的和特定的。通用的软件安全性需求从一些需求和最佳实践的集合中推导出来，这些需求和最佳实践的集合可以在不同的项目和环境中用于解决共同的软件安全性问题。特定的软件安全性需求是系统独特的功能能力或者约束。为了完整地标识出所有的软件安全性需求，制定了如下步骤的软件安全性需求获取流程。

步骤1：从软件安全性要求直接映射到软件安全性需求。软件安全性要求是从系统危险的观点查看软件，将初步的危险原因和危险控制映射到软件，这些就是软件安全性需求的一部分；

步骤2：通过SFTA、ETA、STPA等分析方法从自顶向下补充软件安全性需求。通过对系统设计需求进行自顶向下的分析，系统需求可以在早期标识出系统危险，并规定哪些功能是安全关键的，将这些功能的失效作为分析的顶事件，就可找出失效的原因链，与软件相关的原因可转换为软件安全性需求；

步骤3：对软件需求进行SFMEA、HAZOP等分析方法从自底向上补充软件安全性需求。通过对软件功能或设计数据进行失效模式影响分析(FMEA)、危险和操作性分析(HAZOP)等自底向上分析，对系统需求允许但不期望的设计实现进行分析，可标识出新的软件安全性需求；

步骤4：根据软件具体特点从软件安全性通用需求库选择补充软件安全性需求。

图4描述了软件安全性论证中正当理由的开发方法。软件安全性正当理由的目的是给出“事实证据”支持“软件安全性目标”实现的推理规则。软件安全性目标是系统所要求的软件安全性要求转换而来，而从系统角度提出的软件安全性要求都将进一步分析并最终转换为软件安全性需求，所以，论证软件安全性目标的实现可以论证软件安全性需求层面的实现。而软件安全性需求还将向前链接到设计和源代码。为了使认证更为充分，软件安全性正当理由可以进一步考虑软件安全性部件和软件安全性单元层面的实现。

对于每一个层面，首先需要考虑每个层面的元素的获取，之后从验证/确认（评审、分析和测试）的角度说明每个级别元素的正确实现。软件失效模式在验证/确认中起着非常关键的因素，只要表明对应的各种失效模式均不发生时即可说明各个级别元素的实现。

为了提高验证/确认结果的置信度，即评审、分析和测试的结果更可信，需要进一步从人员素质、软件工具的使用情况、软件过程的规范性、软件方法的正确性和软件相关环境的合理性等过程因素进行正当理由的支援。

[1]RTCA DO-178B Software Considerations in Airborne Systems and Equipment Certification[S].1992.

[2]CENELEC,EN 50128 Railway Applications:Softare for Railway Control and ProtectionSystems[S].European Committee for Electro technical Standardisation,1997.

[3]NASA-STD-8719.13B NASA software safety standard[S].2004.

[4]NASA-GB-8719.13NASA Software Safety Guidebook[S].2004.

[5]Joint Software System Safety Committee,SOFTWARE SYSTEM SAFETY HANDBOOK[S].1999.

[6]Stephen Toulmin.The Uses of Argument[M].Cambridge University Press.1999:97-107.

Claims (6)

1.一种基于图尔敏模式的软件安全性论证方法，其特征在于包含以下步骤：

（1）提出软件安全性论证目标（Claim），即试图在软件安全性论证中证明为已经满足的结论，并进一步明确软件安全性目标的辅助信息（Auxiliary Info）。

（2）提供支持软件安全性论证目标的事实证据（Data），并进一步明确事实证据的辅助信息。事实证据一般为与软件安全性工程相关的一些活动的记录或产生的数据，如安全性分析结果、测试数据等。如果受到质疑，则转入步骤3，否则转入步骤5。

（3）给出赋予该‘事实证据’具有导出‘软件安全性论证目标’结论的资格的推论规则，即“正当理由(Warrants)”，并进一步明确正当理由的辅助信息。如果受到质疑，则转入步骤4，否则转入步骤5。

（4）明确正当理由背后起保证作用的支援（Backing），用于强化正当理由权威性的支援性陈述。

（5）给出“软件安全性目标”实现程度的限定词（Qualifier）。

（6）如果存在，给出阻止从正当理由得出目标成立、具有保留机能的陈述的例外情况或反驳（Rebuttal）。

2.根据权利要求1所述的基于图尔敏的软件安全性论证方法，其特征：包括七元组：<Claim,Data,Warrant,Backing,Qualifier,Auxiliary Info,Rebuttal>，其中：1）Claim代表软件安全性目标，能用是/否来回答的一个断言。2）Data代表与软件安全性相关的事实证据，用来支持软件安全性目标。3）Warrant代表正当理由，提供支持软件安全性目标的推理规则。4）Backing代表支援，用来支持正当理由。5）Qualifier代表限定词，用来表示软件安全性目标成立的程度。6）Auxiliary Info代表附加信息，用来对Claim、Data及Warrant进行补充说明。7）Rebuttal代表反驳，是软件安全性目标成立的例外情况。

3.根据权利要求1所述的提出软件安全性论证目标，其特征：软件安全性论证目标是一个断言或断定，用来指所陈述的、试图在论证中证明成立的结论的术语。软件安全性论证目标是二元的，只能成立或不成立，不存在第三种情况。软件安全性目标获取包括以下步骤：

（1）通过初步危险分析（PHA）、功能危险分析（FHA）或其它的危险分析方法获取系统危险，分析危险的后果和可能性，明确整体系统的整体风险。

（2）根据当时具体情况明确系统中哪些风险可接受和容忍的，明确可容忍风险水平。

（3）根据系统的整体风险和可容忍风险确定哪些风险必须降低或消除，获取必要的风险降低。

（4）根据必要的风险降低进一步明确整体系统的安全性要求。

（5）在系统的安全性要求，从危险原因和危险控制明确哪些是软件的安全性要求。

（6）软件安全性要求需要进一步转换成具有主谓结构的软件安全性论证目标，还应进一步补充诸如背景、术语和缩略语等辅助信息，以便进一步理解安全性论证目标。

4.根据权利要求1所述的给出赋予该‘事实证据’具有导出‘软件安全性论证目标’结论的资格的推论规则，即“正当理由(Warrants)”，其特征是：软件安全性目标是系统所要求的软件安全性要求转换而来，而从系统角度提出的软件安全性要求都将进一步分析并最终转换为软件安全性需求，所以，论证软件安全性目标的实现可以论证软件安全性需求层面的实现。而软件安全性需求还将向前链接到设计和源代码。为了使认证更为充分，软件安全性正当理由可以进一步考虑软件安全性部件和软件安全性单元层面的实现。对于每一个层面，首先需要考虑每个层面的元素的获取，之后从验证/确认（评审、分析和测试）的角度说明每个级别元素的正确实现。软件失效模式在验证/确认中起着非常关键的因素，只要表明对应的各种失效模式均不发生时即可说明各个级别元素的实现。

5.根据权利要求1所述的明确正当理由背后起保证作用的支援，其特征是：为了提高验证/确认结果的置信度，即评审、分析和测试的结果更可信，需要进一步从人员素质、软件工具的使用情况、软件过程的规范性、软件方法的正确性和软件相关环境的合理性等过程因素进行正当理由的支援。

6.根据权利要求3所述的软件安全性要求都将进一步分析并最终转换为软件安全性需求，即需要完成软件安全性需求的获取，其特征是包括以下步骤：

（1）从软件安全性要求直接映射到软件安全性需求。软件安全性要求是从系统危险的观点查看软件，将初步的危险原因和危险控制映射到软件，这些就是软件安全性需求的一部分；

（2）通过SFTA、ETA、STPA等分析方法从自顶向下补充软件安全性需求。通过对系统设计需求进行自顶向下的分析，系统需求可以在早期标识出系统危险，并规定哪些功能是安全关键的，将这些功能的失效作为分析的顶事件，就可找出失效的原因链，与软件相关的原因可转换为软件安全性需求；

（3）对软件需求进行SFMEA、HAZOP等分析方法从自底向上补充软件安全性需求。通过对软件功能或设计数据进行失效模式影响分析(FMEA)、危险和操作性分析(HAZOP)等自底向上分析，对系统需求允许但不期望的设计实现进行分析，可标识出新的软件安全性需求；

（4）根据软件具体特点从软件安全性通用需求库选择补充软件安全性需求。

Images