GB/T 18492-2001
前言
本标 准 等 同采用国际标准ISO/IEC1 5026:1998《信息技术系统及软件完整性级别》。
本标 准 定 义了与完整性级别相关的概念，定义了确定完整性级别和软件完整性需求的过程，并提出
对每个过程的需求。
本标 准 由 中华人民共和国信息产业部提出。
本标 准 由 中国电子技术标准化研究所归口。
本 标 准 由中国电子技术标准化研究所负责起草
本标 准 主要起草人:胡九川、罗锋盈、蔡愉祖。
GB/T 18492-2001
ISO/IEC前言
ISO ( 国际 标准化组织)和IEC国际电工委员会)是世界性的标准化专门机构。国家成员体(它们都
是ISO或IEC的成员国)通过国际组织建立的各个技术委员会参与制定针对特定技术范围的国际标
准。ISO和IEC的各技术委员会在共同感兴趣的领域内进行合作。与ISO和IEC有联系的其他官方和
非官方国际组织也可参与国际标准的制定工作。
对于 信 息 技术，ISO和IEC建立了一个联合技术委员会，即ISO/IECJ TC1。由联合技术委员会提
出的国际标准草案需分发给国家成员体进行表决。发布一项国际标准，至少需要75写的参与表决的国
家成员体投票赞成。
国际 标 准 ISO/IEC 15026由ISO/IECJ TC1信息技术联合技术委员会SC7软件工程分技术委员
会制定。
标准分享网 www.bzfxw.com 免费下载
中华人民共和国国家标准
信息技术系统及软件完整性级别
GB /T1 8492-2001
idt ISO/IEC 15026:1998
Information technology-System and software integrity levels
范围
本标 准 介 绍了软件完整性级别的概念和软件完整性需求，定义了与完整性级别相关的概念，定义了
确定完整性级别和软件完整性需求的过程，并提出对每个过程的需求。本标准不规定专门的一组完整性
级别或软件完整性需求。它们必须依据某一项目的基础在该项目中加以确定。本标准仅适用于软件。系
统完整性级别和非软件部件的完整性级别仅在本标准中被用来确定软件部件的完整性级别。
本标 准 可 供软件产品或包含软件产品的系统的开发者、使用者、采购者和评估人员使用，向他们提
供关于这些产品和系统在管理上和技术上的支持。
软件 完 整 性级别表示软件特性的取值范围，该范围对将系统风险保持在可容忍的限度内是必需的。
对于执行缓减功能的软件而言，此特性是指软件必须执行缓减功能的可靠性。对于因其失效而导致一个
系统威胁的软件而言，此特性是指对该失效的频率或概率的限制。
软件 完 整 性需求是软件开发中软件工程过程所必需满足的需求，是软件工程产品所必需满足的需
求;或是为提供与软件完整性级别相适应的软件置信度而对软件在某一时段的性能的需求。
本标 准 未 规定将确定软件完整性级别(的工作)同整个系统工程生存期过程结合在一起的方法。
引用标准
下 列 标 准所包含的条文，通过在本标准中引用而构成为本标准的条文。本标准出版时，所示版本均
为有效。所有标准都会被修订。使用本标准的各方应探讨使用下列标准最新版本的可能性。
GB /T 5 271.1--2000 信息技术词汇第1部分:基本术语(eqvI SO/IEC 2382-1:1993)
GB /T 5 271.20 -1994 信息技术词汇20部分系统开发(idtI SO/IEC 2382-20:1990)
GB /T 6 583-1994 质量管理和质量保证术语(idtI SO 8402:1994)
GB /T 8 566-2001 信息技术软件生存周期过程GdtI SO/IEC 12207;1995)
IEC 5 0- 191:1990 国际电工词汇，191章:可信性和服务质量
IEC 3 00 -3-9:1995 可信性管理第3部分:应用指南第9章:技术系统的风险分析
定义
除下 述 定 义所作的修改或补充外，GB/T 5271.1 ,GB/T 5271.20 ,GB/T 6583和IEC5 0-191中给
出的定义适用于本标准
3.1 部件component
在一 个 特 定的分析层次上考虑的系统中带有分立结构的实体。诸如一个组合或软件模块。
3.2 置信度degree of confidence
在本 标 准 中，置信度仅用于表示软件同其需求相符合的置信度。
3.3设计机构design authority
中华人民共和国国家质f监舒检验检疫总局2001-11一02批准2002-06-01实施
GB/T 18492-2001
负责 产 生 系统设计的人或组织。
3.4 失效failure
一个 项 未 能或不能在预先规定的限制内执行某个要求的功能的状况。
3.5 故障隔离fault isolation
子 系统 防 止它的一个故障引发其他子系统发生相应故障的能力。
3.6 功能function
系统 的预 期行为的一个方面。
3.7 引发事件initiating event
能 导致 一 个威胁的事件。
3.8 完整性保证机构integrity assurance authority
负责 评 估 完整性需求的符合性的独立的人或组织。
3.9 完整性级别integrity level
项 的某 个 特性的取值范围的一种表示，该特性取值范围对将系统风险保持在可容忍的限度内是必
需的。对于执行缓减功能的项，此特性是指项必须执行缓减功能的可靠性。对于因其失效能导致一个威
胁的项，此特性是指对该失效的频率或概率的限制。
3.10 项item
能够 作 为 单独考虑的一个实体，如一个零件、部件、子系统、设备或系统。一个项可以包括硬件、软件
或两者兼而有之。
3.11缓减功能mitigating function
缓减 功 能 是这样的功能，若其成功地提供，它将防止引发事件转变成为具体的威胁。
112 风险risk
一个 给 定 威胁发生的概率及该威胁发生后的潜在不利后果的函数。
3.13 风险维:isk dimension
对 系统 进 行风险评估采用的一种视点(如安全性、经济性、安全保密性)。
3.14 安全性，afety
对 系统 在 规定的条件下不导致危害人类生命、健康、财产或环境的一个状态的期望值。
3.15 安全保密性security
对 系统 各 项的保护，使其免于受到偶然的或恶意的访问、使用、更改、破坏及泄露
3.16 软件完整性级别software integrity level
软件 项 的 完整性级别。
3.17 子系统subsystem
子 系统 是 作为较大系统的一部分的任何系统。
3.18 系统system
一 个 集 成的复合体，它由一个或多个过程、硬件、软件、设施和人员组成，提供满足明确陈述的要求
或目标的能力。
3.19 系统性失效systematic failure
以确 定 的 方式与某个确凿的原因相关的失效，该失效仅能通过设计、制造过程、操作规程、文档或其
他相关因素的更改才能排除。
3.20 系统完整性级别system integrity level
系统 的 完 整性级别。
3.21威胁threat
系统 或 系 统环境的一种状态，它能导致一个或多个给定的风险维内的负面作用。
标准分享网 www.bzfxw.com 免费下载
Gs/T 18492-2001
4 符号和缩略语
本标准中没有使用符号。缩略语在文中第一次出现时用全称表示。
5 软件完整性级别框架
5.1 如何使用本标准
独立 的 完 整性保证机构是正确应用本标准的基础。完整性保证机构是负责验证完整性需求符合性
的人或组织。设计机构与完整性保证机构通过协商所作出的决定都要文档备案。需要协商的决策内容
包括确定相关风险维、使用的具体的完整性级别、为每个级别规定的明确的标准、对具体的设计结构特
征所允许的受益度，以及因软件被分配一个特定的完整性级别而产生的对该软件的需求。
本标 准 中 描述的过程同整体系统工程的过程有区别，但本标准无意防止这些标准同系统工程的过
程相集成。无论这些过程如何被实现，它们与本标准的符合性意味着本标准中的所有需求均需予以
满足。
5.2 提 供 了确定完整性级别和软件完整性需求的过程概貌。第6,7和a章更详细地描述了这些过
程并定义对这些过程所提出的需求。
5.2 概貌
图 1示 出 了一个决定系统和软件完整性级别，以及软件完整性需求所要求的过程概貌。表1列出了
确定系统完整性级别、软件完整性级别和软件完整性需求三个主要过程的各自的输人和箱出。
风险分析桩体系统工程
图1 确定和应用软件完整性级别的过程概貌
本标准中采用了基于风险(分析)的完整性级别的确定方法。所以，确定相应系统完整性级别的第一
GB/T 18492-2001
步是进行风险分析。IEC 300-3-9提供了执行风险分析的指南。为了实施风险分析，必须获取关于系统、
系统环境、以及与系统相关的风险维方面的足够信息。风险分析应粗盖设计机构与完整性保证机构之间
商定的所有相关的诸如安全性、经济性和安全保密性等风险维。
.对 在 风 险分析中标识出来的任何风险，必须予以评估以确定该风险是否可以容忍。一旦系统设计经
过分析和评价有可容忍的风险，就为系统分配一个系统完整性级别。系统完整性级别反映了系统中存在
的在最坏情况下的风险。
系统 中 软 件的完整性级别最初被分配为与系统的完整性级别相同的级别。可以对系统的设计加以
分析，以确定系统设计中是否存在为软件分配一个比系统完整性级别低的完整性级别的体系结构特征。
表 1 输 人 和 输 出
一
一
一
一
出一
一
一
输一
燮_里__」-_ 输入
系统完整性级别确定
一一相关风险维
一一系统定义
一环境定义
-一系统体系结构(若可提供)
— 风险
一一威胁
-一可容忍频率/威胁发生的概率
— 引发事件
— 引发事件的频率1概率
— 系统完整性级别
— 子系统/软件完整性级别
-一被确认的降低完整性级别的体系结构
特 性
软件完整性级别确定
— 系统完整性级别
一 子系统2软件体系结构
— 威胁清单以及对侮个威胁而言:
— 威 胁可容忍频率或威胁发生的概
率
一 可 能 导致威胁发生的引发事件
— 引 发事件的期望频率或每个引发
事 件 发 生 的 概 率
软件完整性需求的
确定
一一子系统/软件完整性级别软件完整性需求
系统 是 由 一个或多个部件组合集成的。一个部件可以是单独的软件、单独的硬件或由分解为更细的
部件组成的子系统。最初，系统的完整性级别将分配给系统的任何软件部件。确定软件完整性级别涉及
实施对系统体系结构的分析，以便确定子系统的完整性级别能否低于系统的完整性级别。这样的实施过
程可以循环地进行，直至仅包含软件的子系统的完整性级别得以确定;或者包含软件的子系统的完整性
级别被设计机构和完整性保证机构所认可，该认可的级别可以分配给子系统中的任何软件部件。
很可 能 在 系统的体系结构分析的过程中，将发现在先前的风险分析中未曾遇到的新的威胁和风险。
因此，有必要将新的风险信息加以考虑而重新实施风险分析。
软件 完 整 性级别或者是表示提供缓减功能的可靠程度的分配，或者是表示对可能导致威胁产生的
失效频率的限制的分配。由于软件失效是严重的系统性失效，所以软件完整性级别表示一种置信度指
标，其表示可靠地提供缓减功能的真实程度，或者表示不导致某威胁产生失效的真实程度。
软件 完 整 性级别的确定和应用是整个风险分析过程的一部分。在系统和软件产品的生存周期内实
施风险管理，而且可能随不同层次的设计细节的确定或随设计的改进而反复进行。图I示出了整个系统
工程过程与风险分析、风险评价和风险控制等风险管理过程之间的相互关系。
如果 系 统 设计的改进可消除或降低风险，或者当系统和软件完整性级别被分配而发现新的威胁或
者系统设计不能具有可容忍的风险，那么风险管理将重复进行。
软件 完 整 性级别用来确定如何控制风险。相对于软件部件而言，就是明确哪些在软件和软件工程方
面的需求，从而获得在系统风险中起相应作用的软件的置信级别。这些需求就是软件完整性需求。
标准分享网 www.bzfxw.com 免费下载
GB/T 18492-2001
6 系统完整性级别的确定
系统 完 整 性级别对应于与系统相关的风险可容忍性级别。由于系统的失效可导致一个威胁产生、或
者在系统所包含的在其环境中缓减引发事件后果的功能可能导致一个威胁产生，故系统与风险相关联。
确定系统完整性级别的步骤如下:
a) 实 施 风险分析，确定系统相关的风险级别。风险分析是利用可供采用的信息发现的威胁，并且估
计与这些威胁相关的风险的过程。
b) 风 险 评估是判断风险的可容忍度的过程。风险分析与风险评估的结论可能导致对系统设计的修
改以消除或降低风险，进而可能需要重复进行风险分析和评估。
c) 只 要 具有可容忍风险的系统设计被确认，系统的完整性级别即可确定。完整性级别的准确级别
数、区别不同级别的标准均由设计机构和完整性保证机构协商确定。
6.1 风险分析
实施 风 险分析要回答如下三个基本问题:
什 么 可 能导致错误?(通过威胁识别)
发生 的 可 能性如何?(通过频率分析)
后果 是 什 么?(通过后果分析)
利用 这 些 分析的结果，可以计算风险。对于每个识别出的风险，其风险分析的输出为:
a) 用 合 适的术语表述风险;
b) 与 风 险相关的威胁;
c) 与 每 个威胁相关的引发事件;以及
d) 引 发 事件发生的假设频率。
经过 风 险 分析而得出的风险表述可用于风险评估过程以确定风险是否可以容忍。在系统和软件完
整性级别的确定过程中，风险分析的所有结果，可用于确定对系统中软件部件所需求的完整性级别。
风险 分 析 的适用指南是IEC3 00-3-9《技术系统的风险分析》。由于在IEC 300-3-9中用到安全性方
面的专门术语，术语“危害(hazard)”和“伤害(harm)”必须分别被解释成“威胁”和“负面作用”。
风险 分 析 可以覆盖安全性、经济性和保密性等诸多风险维。要覆盖的具体的风险维应由设计机构和
完整性保证机构确定。
6.1.1 威胁识别
应把 与 系 统相关的威胁同可能导致威胁的引发事件一起识别。若系统失效，按规定的系统操作或者
系统在其环境中执行缓减引发事件后果的功能可导致威胁的产生，则这些威胁同系统相关联.发现先前
未曾识别出来的威胁，将采用适于具体情况的方法，并将方法记录备案(见IEC 300-3-9)。在识别威胁过
程中应考虑系统体系结构(若可提供)，以确保系统中所使用技术的特定的失效模式也得到考虑。
6.1.2 频率分析
频率 分 析 用来估计经威胁识别而确定的每个引发事件发生的可能性。当系统的一个失效是一个引
发事件，频率分析不用来估计失效发生的可能性，而是用来确定与可容忍风险目标相一致，并且是可实
际达到的失效的频率的限度。
用相 关 的 历史数据估计事件频率，用诸如故障树或事件树分析(IEC3 00-3-9)等技术来综合它，或
用专家判断来估计事件频率。
在 系统 完 整性级别的确定过程中实施频率分析，系统将视作一个黑盒子，系统的体系结构亦将不予
以考虑系统的体系结构将在软件完整性级别的确定过程中考虑。经频率分析而得出的事件频率可以
用定量的词语表述，或者用定性的词语表述频率的范围(如频繁的、可能的、偶然的、间接性的、不可能的
或难以置信的)。
频率 分 析 中，要考虑到某些引发事件与其他事件相结合而导致威胁的产生，或者作为一个事件后果
cB/T 18492-2001
的部分情形。
6.1.3 后果分析
如 果引 发 事件发生，后果分析用来估计威胁的严重性。要明确指出可缓减引发事件后果的任何措
施。每一个威胁归入为一个后果类，这些后果类描述了后果的不同程度的严重性(如灾难性、重大性、严
重性、次要性)。
6门.4 风险计算
与每 个 威 胁相关的风险，可用风险矩阵来计算。风险矩阵将引发事件发生的频率同引发事件产生的
后果的严重性联系了起来。在风险矩阵中，对每一个频率与严重性的组合配对指定一个风险类(如高风
险、中等风险、低风险或微小风险)。表2为IEC 300-3-9中一个风险矩阵的例子。
表2 风险矩阵的例子
发生频率频率(每年) 后果的严重性
灾难性重大性严重性次要性
频繁性> 1 高高高中等
可能性I- 10-1 高高中等低
偶然性10-'--10-z 高高低低
间接性10-1^10-0 高高低低
不可能性10-`-10-` 高中等低徽小
难以t信G 10-s 中等中等微小徽小
设计 机 构 和完整性保证机构需对所采纳的计算风险的风险矩阵达成一致意见。达成对风险矩阵的
一致性意见需要对引发事件发生频率的适当范围、后果类及其定义、与每一个频率范围和后果类相关的
风险类。
6.2 风险评估
设计 机 构 和完整性保证机构要对通过风险分析而得出的风险的可容忍性进行裁决口在某些地区，这
样裁决要依据该地区立法机构所建立的法规来进行。
6.3 系统完整性级别的确定
最初 分 配 给系统的完整性级别同赋给与系统相关的威胁最高风险类相对应。完整性级别数同已确
定的风险类的数量相对应。表3给出风险等级到系统完整性级别的映射例子。
表 3 风 险 等 级 映 射 到 系 统 完 整 性 级 别
风险等级系统完整性级别
高A
中等B
低C
微小D
本标准没有明确指出完整性级别的级别数或完整性级别的记法。
了软件完整性级别的确定
软件 完 整 性级别是系统完整性级别在包含软件部件或仅包含软件部件或仅包含软件的子系统上的
分配。一个子系统的软件完整性级别最初与系统的完整性级别相同。
除非 因 进 行以下四个方面的考虑而使软件完整性级别相应降低，子系统的软件完整性级别与系统
的完整性级别相同:
标准分享网 www.bzfxw.com 免费下载
cB/T 18492--2001
a) 考 虑 系统的缓减子系统失效后果的体系结构特征。不考虑将导致一个系统威胁产生;
b) 考 虑 系统的提供冗余缓减功能体系结构特征，这些特征使引发事件被缓减，尽管有单个或多个
子系统的失效已经分配了缓减功能;
c) 考 虑 子系统在识别引发事件或缓减功能方面的作用。
了门软件完整性级别确定前提
a) 系 统 被赋予了一个完整性级别;
b) 系 统 的体系结构特征被充分地、详细地予以定义，从而能够识别子系统的作用和它们的接口;
c) 确 定 完整性级别的过程输人:
-— 系 统 的 完 整性级别
一 关 于 威 胁 的清单，并且对一个威胁要提供以下信息:
— 可 能 导 致 威 胁 产 生 的 引 发事件
— 每 个 引 发 事 件 产 生 的 设 计频率或概率
— 系 统 体 系 结构的充分的、详细的定义。该定义便于确定每个子系统的作用和识别系统体系
结构 中具 有 缓 减作用的特征;
d) 输 出 为软件完整性级别。
7.2 软件完整性级别的降低
确 定 一 个可能降低的软件完整性级别，必须执行下列步骤:
a) 识 别 出构成整个系统的子系统的集合;
b> 确 定 任何子系统是否孤立地或与其他子系统状态相结合地导致威胁产生。若子系统孤立地失效
导致产生一个威胁，则赋予子系统与系统的完整性级别相同的完整性级别。若子系统与其他子系统状态
相结合地失效而导致一个威胁，则根据7. 3中定义的评估过程而得到的结果，子系统的完整性级别可能
降低。7.3 中定义的评估过程是非强制性的，只有需要一个较低的子系统完整性级别才实施该过程;
c) 确 定 任何子系统是否孤立地或与其他子系统状态相结合地失效将导致不能提供某个缓减功能。
若子系统孤立地失效导致不能提供缓减功能，则赋予子系统与系统的完整性级别相同的完整性级别。若
子系统与其他子系统状态相结合地失效而导致不能提供缓减功能，则根据7. 4中定义的评估过程而得
到的结果，子系统的完整性级别可能降低。7.4中定义的评估过程是非强制性的，只有需要一个较低的
子系统完整性级别才实施该过程;
d) 确 定 是否有包含软件部件的子系统，这样的软件的失效不能导致产生威胁，并且软件的功能与
任何系统事件的缓减无关。任何这样的软件应赋予最低的完整性级别。必须实施故障隔离以确保软件
失效不导致产生威胁。设计机构和完整性保证机构必须在足够的体系结构特征方面取得一致意见，以确
保充分的故障隔离。如果通过失效处理机制达到了故障隔离，应分配给该机制有与系统完整性级别相同
的软件完整性级别。
从指 定 的 系统完整性级别降低软件的完整性级别，体系结构特征所带来的收益程度，必须由设计机
构和完整性保证机构予以规定并认可。
重复 使 用 上述包含步骤a)至步骤d)的过程，直到所有仅包含软件的子系统的完整性级别被设计机
构和完整性保证机构所接受，并将其赋予这些子系统的任何软件部件。
了.3 降低因其失效可能导致一个威胁的软件完整性级别
对 于那 些 因其失效而导致产生威胁的系统，其完整性级别部分取决于对同系统叮容忍的风险目标
相一致的系统失效频率的限制。若仅在某一特别状态下软件与其他子系统相结合而失效，导致威胁产
生，则可以对软件失效频率的限制适当放宽。频率分析可以用于决定对软件失效频率的最宽松的限制，
这种最宽松的限制同可容忍的风险目标相一致，同时，频率分析要将子系统之间的依赖关系加以考虑。
确定较紧的对软件失效频率的限制，以进行重复风险计算，进而明确在风险等级和由此通常的在很低级
别上的软件完整性级别是否有任何变化。
GB/'r 18492-2001
失效 处 理 机制可用于检测软件失效并采取行动防止软件失效变为引发事件在这些情况下，即使失
效发生和失效处理机制无效，软件失效仅能成为一个引发事件。失效处理机制的例子如下:
a) 数 据 完整性检查(软件机制);
b) 硬 件 看门狗计时器(硬件机制);
。) 人 工 恢复(人工机制)。
只要 冗 余 子系统之间的通用模式失效可以避免，冗余能阻止失效导致威胁产生。当软件多样性用于
缓减因对软件失效频率的限制而造成的压力，软件多样性带来的受益程度，以及对充分多样性的规定必
须受到设计机构和完整性保证机构的认可。
7.4 降低因其失效可能导致不能提供缓减功能的软件完整性级别
若子 系 统 与其他子系统状态相结合的失效仅导致不提供减缓功能，则软件的可靠性会低于系统对
缓减功能的要求。正如7.3中所指出，用于频率分析的技术可用于确定软件可靠性的系统所要求的可靠
性的降低程度。
8 软件完整性需求确定
8.1 置信度
软 件 完 整性级别或者是表示提供缓减功能的所要求的可靠性程度的分配，或者是对可能导致威胁
产生的所要求的失效频率的限制的分配。由于软件失效严格说是系统性失效的函数，所以软件完整性级
别表示置信度指标，其表示可靠地提供缓减功能的真实程度，或者表示不导致某威胁产生失效的真实程
度。软件及其生存周期过程所要求的需求也称作软件完整性需求，如果被满足，将提供必需的置信度。
在软 件 中 获取置信的一些策略如下:
a) 采 用 一些技术，使错误的引入最小化;
b) 采 用 /应用验证和确认技术，把错误的检测最大化;
。) 通 过 操作历史表明/证明软件可靠地提供缓减功能，或失效率低于规定的限制
8.2 在软件中获得置信度的方法
表 4简 要 地给出了一些软件工程活动、活动输出的属性和可用来获得不同的置信度的实现这些属
J性的方法的例子。本标准不打算规定采用某个特定的软件生存期GB/T 8566中描述的其他生存周期
过程同样适用。
若 软件 已 存在和己运行了一段时间，软件的置信可通过评价它的运行历史得到。运行历史提供的置
信度依赖于各种因素，如软件的复杂性、成功操作的历史和使用软件的方法同按规程使用软件的方法之
间的相似性等
8.3 软件置信度与完整性级别的联系
本标 准 未 规定为了得到适合干给定的软件完整性级别的置信度所要满足的特殊需求
对 于为 达 到每个完整性级别软件所必需的置信度所要满足的需求，设计机构和完整性保证机构应
就其达成协议。
表 4 过 程 活 动 、 属 性 和 置 信 度 例 子
活动属性对于每一完整性级别中获得置信度的方法
软件需求分析
精确性、完整性
正确性、抽象性
一致性、可验证性
飞.结构化方法
2. (1)加上半形式化记法
3. (1功AF形式化记法
魂·(3)加上形式化证明
标准分享网 www.bzfxw.com 免费下载
cB/T 18492-2001
表4(完)
活动属性对于每一完整性级别中获得置信度的方法
软件设计
需求分析的可追踪性、可验证性、模块性、抽
象性
1.结构化方法
2. (1)加上半形式化记法
3. (1)加上形式化记法
4.(3)加上形式化证明
软件编码
设计的可追踪性、程序结构的无歧义性、程
序设计语言的标准化、可维护胜
1.结构编程
2. (1)加上强类型语言
3 (1)加上对语言安全子集的限制
4.(3)加上形式化证明
350