首页 购物车 询价
www.GB-GBT.com

[PDF] GB/T 20274.2-2008 - 自动发货. 英文版

标准搜索结果: 'GB/T 20274.2-2008'
标准号码内文价格美元第2步(购买)交付天数标准名称状态
GB/T 20274.2-2008 英文版 145 GB/T 20274.2-2008 3分钟内自动发货[PDF] 信息安全技术 信息系统安全保障评估框架 第2部分：技术保障 有效

基本信息
标准编号 GB/T 20274.2-2008 (GB/T20274.2-2008)
中文名称 信息安全技术 信息系统安全保障评估框架 第2部分：技术保障
英文名称 Information security technology -- Evaluation framework for information systems security assurance -- Part 2: Technical assurance
行业 国家标准 (推荐)
中标分类 L80
国际标准分类 35.040
字数估计 157,110
发布日期 2008-07-18
实施日期 2008-12-01
引用标准 GB/T 20274.1
标准依据 国家标准批准发布公告2008年第14号(总第127号)
发布机构 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会
范围 GB/T 20274的本部分建立了信息系统安全技术保障的框架, 确立了组织机构内启动、实施、维护、评估和改进信息安全技术体系的指南和通用原则。GB/T 20274的本部分定义和说明了信息系统安全技术体系建设和评估中反映组织机构信息系统安全的技术体系架构能力级, 以及组织机构信息系统安全的技术要求。GB/T 20274的本部分适用于启动、实施、维护、评估和改进信息安全技术体系的组织机构和涉及信息系统安全技术工作的所有用户、开发人员和评估人员。

GB/T 20274.2-2008: 信息安全技术 信息系统安全保障评估框架 第2部分：技术保障 GB/T 20274.2-2008 英文名称: Information security technology -- Evaluation framework for information systems security assurance -- Part 2: Technical assurance ICS ３５．０４０ L８０ 中华人民共和国国家标准 １　范围 GB/T ２０２７４的本部分建立了信息系统安全技术保障的框架，确立了组织机构内启动、实施、维护、 评估和改进信息安全技术体系的指南和通用原则。GB/T ２０２７４的本部分定义和说明了信息系统安全 技术体系建设和评估中反映组织机构信息安全的技术体系架构能力级，以及组织机构信息系统安全的技术要求。 GB/T ２０２７４的本部分适用于启动、实施、维护、评估和改进信息安全技术体系的组织机构和涉及 信息系统安全技术工作的所有用户、开发人员和评估人员。 ５　信息安全技术保障 ５．１　安全技术保障概述 信息系统安全保障评估框架-安全技术保障主要用于评估信息系统中系统级的安全技术体系框架 和安全技术解决方案，即对信息技术系统（信息技术系统：作为信息系统一部分的执行组织机构信息功 能的用于采集、创建、通信、计算、分发、处理、存储和／或控制数据或信息的计算机硬件、软件和／或固件 的任何组合）进行安全评估。在信息系统安全保障评估框架的技术、管理和工程保障中，安全技术保障 同GB/T １８３３６《信息技术安全性评估准则》间有着最直接和紧密的关系；信息系统安全保障评估准的 安全技术体系框架和安全技术解决方案直接建立在经过GB/T １８３３６准则评估认可的产品和产品系统之上。 在信息系统安全保障评估框架安全技术保障中，它的评估对象（ＴＯＥ）是构成信息系统的所有计算 机硬件、软件和／或固件的任何组合。信息系统安全保障评估框架安全技术保障，首先要求信息系统的 用户为其评估对象（即信息技术系统）建立和完善其安全技术体系架构；在完成其信息技术系统安全技 术体系架构后，基于此安全技术体系架构，对信息技术系统进行高层分析、确定相关安全目的；最后用规 范化的安全技术保障控制组件类进行描述。 ５．２　安全技术体系架构能力级 安全技术体系架构构建过程，是组织机构根据其系统安全风险评估的结果和系统安全策略的要求， 并参考相关安全技术体系架构的标准和最佳实践，结合组织机构信息技术系统的具体现状和需求，建立 的符合组织机构信息技术系统安全战略发展规划的整体安全技术体系框架；它是组织机构信息技术系 统安全战略管理的具体体现。安全技术体系架构能力是组织机构执行系统安全技术能力的整体反映， 是组织机构在进行信息安全技术体系框架管理并达到预定成本、功能和质量目标的度量的体现。 ５．３　安全技术保障控制要求范例 本条描述本部分中安全技术保障控制要求所使用的范例。图１和图２描述了范例的一些关键概 念。本条为这些图和图中没有的其他关键概念提供文字描述。所讨论的关键概念以粗斜体突出表示。 图１　安全技术保障控制要求范例（单个TOE） 本部分是一个可为评估对象（ＴＯＥ）规定安全功能要求的目录。ＴＯＥ是包含电子存储媒体（如磁 盘）、外设（如打印机）和计算能力（如ＣＰＵ时间）等资源的ＩＴ产品或系统（同时带有用户和管理员指南 文档），可用于处理和存储信息，是被评估的对象。 ＴＯＥ评估主要关系到：确保对ＴＯＥ资源执行了规定的ＴＯＥ安全策略（ＴＳＰ）。ＴＳＰ定义了一些规 则，通过这些规则ＴＯＥ支配对其资源的访问，这样ＴＯＥ就控制了其所有信息和服务。 而ＴＳＰ又由多个安全功能策略（ＳＦＰ）所构成。每一ＳＦＰ有其控制范围，定义了该ＳＦＰ控制下的 主体、客体和操作。ＳＦＰ由安全功能（ＳＦ）实现，ＳＦ的机制执行该策略并提供必要的能力。 图２　分布式TOE内的安全功能图 为正确执行ＴＳＰ而必须依赖的ＴＯＥ中的那些部分，统称为ＴＯＥ安全功能（ＴＳＦ）。ＴＳＦ包括实施 安全所直接或间接依赖的ＴＯＥ中的所有软件、硬件和固件。 参照监视器是实施ＴＯＥ的访问控制策略的抽象机。参照确认机制 是参照监视器概念的实现，它 具有以下特性：防篡改、一直运行、简单到能对其进行彻底的分析和测试。ＴＳＦ 可能包括一个参照确认 机制或ＴＯＥ运行所需要的其他安全功能。 ＴＯＥ可能是一个包含硬件、固件和软件的单个产品，也可能是一个分布式产品，内部包括多个单独 的部分，每一部分都为ＴＯＥ提供一个特别的服务，并且通过一个内部通信信道与ＴＯＥ其他部分相连 接。该信道可以与处理器总线一样小，也可能是包含在ＴＯＥ中的一个内部网络。 当ＴＯＥ由多个部分组成时，ＴＯＥ的每一部分可拥有自己的ＴＳＦ部分，此部分通过内部通信信道 与ＴＳＦ的其他部分交换用户数据和ＴＳＦ数据。这种交互称为ＴＯＥ内部传输。在这种情况下，这些 ＴＳＦ的分离部分抽象地形成一个复合的ＴＳＦ来实施ＴＳＰ。 ＴＯＥ接口可能限于特定的ＴＯＥ使用，也可能允许通过外部通信信道与其他ＩＴ产品交互。这些与 其他ＩＴ产品的外部交互可以采取两种形式： ａ）　“远程可信ＩＴ产品”的安全策略和本地ＴＯＥ的ＴＳＰ已在管理上进行了协调和评估。这种情 况下的信息交换称为ＴＳＦ间传输，如同它们是在不同可信产品的ＴＳＦ之间。 ｂ）　远程ＩＴ产品可能没有被评估，因此它的安全策略是未知的，如图１．２中所示的“不可信ＩＴ产 品”。这种情况下的信息交换称为ＴＳＦ控制外传输，如同在远程ＩＴ产品中没有ＴＳＦ（或它的策略特性未知）。 可与ＴＯＥ或在ＴＯＥ中发生的、并服从ＴＳＰ规则的交互集合称为ＴＳＦ控制范围（ＴＳＣ）。ＴＳＣ包 括一组根据主体、客体和ＴＯＥ内的操作定义的交互集，但不必包括ＴＯＥ的所有资源。 一组交互式（人机接口）或编程 （应用编程接口）接口，通过它，ＴＳＦ访问、调配ＴＯＥ资源，或者从 ＴＳＦ中获取信息，称为ＴＳＦ接口（ＴＳＦＩ）。ＴＳＦＩ定义了为执行ＴＳＰ而提供的ＴＯＥ功能的边界。 用户在ＴＯＥ的外部，因此也在ＴＳＣ的外部。但为请求ＴＯＥ执行服务，用户要通过ＴＳＦＩ和ＴＯＥ 交互。本标准安全功能要求关心两种用户：人类用户和外部ＩＴ实体。人类用户进一步分为本地人类 用户，他们通过ＴＯＥ设备（如工作站）直接与ＴＯＥ交互，或远程人类用户，他们通过其他ＩＴ产品间接与ＴＯＥ交互。 用户和ＴＳＦ间的一段交互期称为用户会话。可以根据各种考虑来控制用户会话的建立，如：用户 鉴别、时段、访问ＴＯＥ的方法和每个用户允许的并发会话数。 本标准使用术语“已授权”来表示用户具有执行某种操作所必需的权力或特权。因此术语“授权用 户”表示允许用户执行ＴＳＰ定义的操作。 为表达需要管理员责任分离的要求，本标准相关的安全功能组件（来自子类ＦＭＴ＿ＳＭＲ）明确说明 要求管理性角色。角色是预先定义的一组规则，这些规则建立起用户和ＴＯＥ间所允许的交互。ＴＯＥ 可以支持定义任意数目的角色。例如，与ＴＯＥ安全运行相关的角色可能包括“审计管理员”和“用户账号管理员”。 ＴＯＥ包括可用于处理和存储信息的资源。ＴＳＦ的主要目标是完全并正确地对ＴＯＥ所控制的资源和信息执行ＴＳＰ。 ＴＯＥ资源能以多种方式结构化和利用。但是，本标准作出了特殊区分，以允许规定所期望的安全 特性。所有由资源产生的实体能以两种方式中的一种来表征：实体可能是主动的，意指他们是ＴＯＥ内 部行为发生的原因，并导致对信息执行操作；实体也可能是被动的，意指它们是发出信息或存入信息的容器。 主动的实体称为主体。ＴＯＥ内可能存在以下几种类型的主体： ａ）　代表授权用户，遵从ＴＳＰ所有规则的那些实体（例如：ＵＮＩＸ进程）； ｂ）　作为特定功能进程，可以轮流代表多个用户的那些实体 （例如：在客户／服务器结构中可能找到的功能）； ｃ）　作为ＴＯＥ自身一部分的那些实体（例如：可信进程）。 本部分所述的安全功能针对上述列出的各种主体执行ＴＳＰ。 被动实体（即信息存储器）在本部分中被称作“客体”。客体是可以由主体执行操作的对象。在一个 主体（主动实体）是某个操作的对象（例如进程间通信）的情况下，该主体也可以作为客体。 客体可以包含信息。在ＦＤＰ类中说明信息流控制策略时，需要这个概念。 用户、主体、信息和客体具有确定的属性，这些属性包括使ＴＯＥ正确运转的信息。有些属性，可能 只是提示性信息（即，增加ＴＯＥ的用户友好性），如文件名，而另一些属性，可能专为执行ＴＳＰ而存在， 如访问控制信息，后面这些属性通常称为“安全属性”。在本部分中，属性一词将用作“安全属性”的简 称，除非另有说明。但正如ＴＳＰ规定的那样，无论属性信息的预期目的如何，对属性加以控制还是必要的。 ＴＯＥ中的数据分为用户数据和ＴＳＦ数据，图３表明了这种关系。用户数据是存储在ＴＯＥ资源中 的信息，用户可以根据ＴＳＰ对其进行操作，而ＴＳＦ对它们并不附加任何特殊的意义。例如，电子邮件 消息的内容是用户数据。ＴＳＦ数据是在进行ＴＳＰ决策时ＴＳＦ使用的信息。如果ＴＳＰ允许的话，ＴＳＦ 数据可以受用户的影响。安全属性、鉴别数据以及访问控制表都是ＴＳＦ数据的例子。 有几个用于数据保护的ＳＦＰ，诸如访问控制ＳＦＰ和信息流控制ＳＦＰ。实现访问控制ＳＦＰ的机制， 是基于控制范围内的主体属性、客体属性和操作来决定建立它们的策略，这些属性用于控制主体可以对 客体执行的操作的规则集中。 实现信息流控制ＳＦＰ的机制，是基于控制范围内的主体和信息的属性以及制约主体对信息操作的 一组规则来决定它们的策略。信息的属性，可能与容器属性相关联（也可能没有关联，如多级数据库），在信息移动时与其相随。 图３　用户数据和TSF数据的关系 本部分涉及的两种特殊ＴＳＦ数据，鉴别数据和秘密，可以是但不必一定是相同的。 鉴别数据用于验证向ＴＯＥ请求服务的用户声明的身份。最通用的鉴别数据形式是口令。口令要 成为有效的安全机制，依赖于对其进行保密。但是，不是所有形式的鉴别数据都需要保密，生物测定学 鉴别设备（例如，指纹阅读器、视网膜扫描仪）就不依赖于数据保密，因为这些数据只有一个用户拥有，其他人不能伪造。 本部分功能要求中用到的术语“秘密”，对鉴别数据适用，对其他为执行一特定ＳＦＰ而必须保密的 数据也同样适用。例如，依靠密码功能保护在信道中传输信息的保密性的可信信道机制，其强度应与用 来保持密钥的秘密以防止未授权泄露的方法的强度相当。 因此，不是所有的鉴别数据都需要保密；也不是所有的秘密都被用作鉴别数据。图４说明了秘密和 鉴别数据间的关系，指出了常见的鉴别数据和秘密的数据类型。 图４　“鉴别数据”和“秘密”的关系 ６　信息安全技术保障控制结构 ６．１　综述 本章定义了本部分的技术要求的内容和形式，并为需要向ＩＳＳＴ中添加新组件的组织提供指南。 技术要求以类、子类和组件来表达。 ６．１．１　信息安全技术保障控制类结构 图５以图表的形式阐明了安全技术保障控制类的结构。每个安全技术保障控制类包括一个类名、 类介绍及一个或多个安全技术保障控制子类。 图５　安全技术保障控制类结构 ６．１．１．１　类名 类名提供标识和划分安全技术保障控制类所必需的信息。每个安全技术保障控制类都有一个唯一 的名称，类的分类信息由三个字符的简名组成。类的简名用于该类中的子类的简名规范中。 ６．１．１．２　类介绍 类介绍描述这些子类满足安全目标的通用意图或方法。安全技术保障控制类的定义不反映要求规 范中的任何正式分类法。 类介绍用图来描述类中的子类和每个子类中组件的层次结构，见６．１．１的解释。 ６．１．２　信息安全技术保障控制子类结构 图６以框图形式说明安全技术保障控制子类的结构。 图６　安全技术保障控制子类结构 ６．１．２．１　子类名 子类名部分提供标识和划分安全技术保障控制子类所必需的分类和描述信息。每个安全技术保障 控制子类有一个唯一的名称。子类的分类信息由七个字符的简名组成，开头三个字符与类名相同，后跟 一个下划线和子类名，例如ＸＸＸ＿ＹＹＹ。唯一的简短子类名为组件提供主要的引用名。 ６．１．２．２　子类行为 子类行为是对安全技术保障控制子类的行为的叙述性描述，陈述其安全目的，以及对技术要求的一 般描述。以下是更详细的描述： ａ）　子类的安全目的阐述在包含该子类的一个组件的ＴＯＥ的帮助下，可以解决的安全问题； ｂ）　技术要求的描述总结组件中包含的所有安全要求。该描述针对ＰＰ、ＳＴ和技术包的作者，他们 希望评价该子类是否与他们的特定需求相关。 ６．１．２．３　组件层次 安全技术保障控制子类包含一个或多个组件，任何一个组件都可被选择包含在ＰＰ、ＳＴ和技术包 中。本条的目的是，一旦子类被认为是用户安全要求的一个必要或有用的部分时，就应向用户提供选择 恰当的安全技术保障控制组件的信息。 安全技术保障控制子类描述部分描述所用组件和它们的基本原理。组件的更多细节包含在每个组件中。 安全技术保障控制子类内组件间的关系可能是也可能不是层次化的。如果一个组件相对另一个组 件提供更多的安全，那么该组件对另一个组件来说是有层次的。 如６．１．２条所述，子类的描述中提供了关于子类内组件层次结构的图示。 ６．１．２．４　管理 管理要求包含ＰＰ／ＳＴ作者应考虑的作为给定组件的管理活动的信息。管理要求在管理类（ＦＭＴ）的组件里详述。 ＰＰ／ＳＴ作者可以选择已指出的管理要求或者可以包括其他没有列出的管理要求，因而这些信息应认为是提示性的。 ６．１．２．５　审计 如果ＰＰ／ＳＴ中包含来自类ＦＡＵ（安全审计）中的要求，则审计要求包含供ＰＰ／ＳＴ作者选择的可审 计的事件。这些要求包括按ＦＡＵ＿ＧＥＮ（安全审计数据产生）子类的组件所支持的以各种不同详细级 别表示的安全相关事件。例如，一个审计记录可能包括下述行动：最小级---安全机制的成功使用；基 本级---安全机制的成功使用以及所涉及到的安全属性的相关信息；详细级---所有对机制配置的改 变，包括改变前后的实际配置值。 显然可审计事件的分类是层次化的。例如，当期望“基本级审计产生”时，所有标识为最小级和基本 级的可审计事件都应通过适当的赋值操作包括在ＰＰ／ＳＴ内，只是高级事件仅仅比低级事件提供更多的 细节。当期望“详细级审计产生”时，所有标识为最小级、基本级和详细级的可审计事件都应包括在ＰＰ／ＳＴ内。 ＦＡＵ类更详尽地解释了管理审计的规则。 ６．１．３　信息安全技术保障控制组件结构 图７描绘安全技术保障控制组件的结构。 图７　安全技术保障控制组件结构 ６．１．３．１　组件标识 组件标识提供标识、分类、注册和交叉引用组件时所必需的描述性信息。下列各项作为每个安全技 术保障控制组件的部分： ａ）　一个唯一的名字，该名字反映了组件的目的。 ｂ）　一个简名，即安全技术保障控制组件名的唯一简写形式。简名作为分类、注册和交叉引用组 件的主要引用名。简名反映出组件所属的类和子类以及在子类中组件的编号。 ｃ）　一个从属于表。这个组件所从属于的其他组件列表，以及该组件可用来满足与所列组件间的依赖关系。 ６．１．３．２　技术元素 为每一组件提供了一组元素。每个元素都分别定义并且是相互独立的。 技术元素是一个安全技术要求，如果进一步划分将不会产生有意义的评估结果。它是GB ２０２７４．２ 中标识和认同的最小安全技术要求。 当建立包、ＰＰ或ＳＴ时，不允许从一个组件中只选择一个或几个元素，必须选择组件的全部元素。 每个技术元素名都有一个唯一的简化形式。例如，元素名ＦＤＰ＿ＩＦＦ．４．２意义如下：Ｆ---技术要 求，ＤＰ---“用户数据保护”类，＿ＩＦＦ---“信息流控制技术”子类，．４---第四个组件，名为“部分消除非 法信息流”，．２-该组件的第２个元素。 ６．１．３．３　依赖关系 当一个组件本身不充分而要依赖于其他组件的技术，或依赖于与其他组件的交互才能正确发挥其 技术时，就产生了安全技术保障控制组件间的依赖关系。 ......