信息系统安全保护轮廓文档格式.docx

信息系统安全保护轮廓文档格式.docx

《信息系统安全保护轮廓文档格式.docx》由会员分享，可在线阅读，更多相关《信息系统安全保护轮廓文档格式.docx（59页珍藏版）》请在冰豆网上搜索。

TOE描述同样提供了评估的内容。

TOE描述中提供的信息将用在评估的过程中，来判别是否存在矛盾。

由于一个PP一般不仅仅指代一个特定的应用，其所描述的TOE特征可以是假设。

如果TOE是一个产品或系统，其首要功能是安全，PP的这部分内容将被用作是对TOE更广泛应用前景的叙述。

3.3TOE安全环境

TOE安全环境应描述TOE所应用环境的安全方面，以及TOE期望被采用

的方式。

陈述应包括如下内容：

a）假设描述了TOE的应用或想要应用的环境的安全方面，如：

有关TOE的使用信息，包括可能的应用，潜在的资产价值，对使用的可能的限制。

关于TOE使用环境的信息，包括物理的，人员的以及连接的方面。

b）威胁应当包括所有对TOE内部受特殊保护的资产的威胁。

应当申明的是，不是所有在此环境中遇到的可能的威胁必需列举出来，列举出来的仅是与安全的TOE运行相关的那部分。

威胁应以一个辩明的威胁代理者，一次攻击的方式描述，而资产是攻击的主体。

威胁代理者应当通过这些方面叙述，如专业知识，可用的资源和动机。

攻击应当通过攻击方法，可利用脆弱点和机会来描述。

如果仅仅从组织的安全法规以及假设来推导，那么，威胁的描述就可以忽略了。

c）组织的安全法规的描述应确认和解释任何TOE必须遵守的组织的安全法规，解释和说明对于陈述任何一条法规都是必须的，这样有利于指定明确的安全目标。

如果TOE是分布式的，则TOE环境的各个独立的范围的安全环境的方方面面（假设，威胁，组织安全法规）必须讨论。

3.4安全目标

安全目标这部分应当定义对TOE和其环境的安全目标。

其内容应当涵盖已辩明的安全环境的所有方面。

安全目标应当反映所陈述的目的，应能对抗所有已识别的威胁，并覆盖所有辩明的组织安全法规和假设。

具体有如下的安全目标：

a）TOE的安全目标应明确陈述，还须追踪到TOE会遭遇到的已知的威胁以及TOE须遵守的组织安全法规的各个方面。

b）环境的安全目标同样须明确陈述，还应追踪到TOE没有完全遭遇到的已辩明的威胁或TOE须不完全遵守的组织安全法规及假设的各个方面。

须注意的是，环境的安全目标也许是对TOE安全环境的假设部分的完全或部分重复叙述。

3.5IT安全需求

PP的这部分内容详细定义了TOE及其环境应满足的IT安全需求。

IT安全

需求具体包括如下内容：

a）TOE安全需求定义了为了达到TOE的安全目标，TOE及其评估证据必须满足的功能的和保证的安全需求。

TOE的安全需求叙述如下：

1）TOE安全功能需求应当适当选择本文附录一内的功能组件来定义TOE的功能上的要求。

为了涵盖每一方面的要求，附录一的同一个组件有可能重复使用或使用同一需求的不同方面。

当在TOE安全保证需求有组件AVA_SOF.1（EAL2和更高），TOE安全功能需求应通过概率和排列算法保证其最低的强度等级。

所有的功能应当满足最低的等级，该等级需是如下等级中的一个：

SOF-Basic,SOF-Medium,SOF-High。

等级的选择应当与已确定的TOE安全目标一致。

作为TOE安全功能评估强度的一部分（AVA_SOF.1），应当对每一单独的TOE安全功能要求强度和TOE的总体最低安全强度等级进行评估。

2）TOE安全保证需求的陈述应作为一个被附录二的保证组件扩张的EALs。

当PP中存在明确的不包含在附录二中的额外的保证需求时，也须扩展EAL。

b）IT环境安全需求应确定需被TOE的IT环境满足的IT安全需求，如果TOE对IT环境的依赖关系尚需证实，PP的这部分内容可以删除。

注意到，在现实中常常非常有用的非IT环境的安全需求不要求作为PP的正式内容，因为它们与PP的实施不直接相关。

c）在对TOE以及其IT环境的安全功能和保证需求的叙述中应使用如下的一般条件：

1）所有的IT安全需求应当从附录一和附录二中选择，如果其中某些需求不是摘自附录一和附录二，PP中应当明确的说明，该需求不是摘自附录。

2）任何明确说明的非摘自附录的需求应当正确而不含糊的陈述，这样，评估及示范才可行，其具体的等级和描述方式应参考附录里的功能和保证需求。

3）当选择了一些指定了必须的操作的安全需求时，PP应当使用这些操作去放大这些需求的等级，从而能够示范是否达到安全目标。

任何PP内没有执行的所要求的操作应当标明。

4）通过使用需求组件中的操作，在必要时，TOE安全需求陈述应有选择地规定或禁止特定安全机制的使用。

5）所有IT安全需求之间的相关性都应满足，通过在TOE的安全需求或环境的需求中包含该相关联的需求来满足相关性。

3.6使用注释

PP的这部分包含了对TOE的使用、评估、构造所必需考虑的额外相关的有益支撑信息。

3.7基本原理

PP的这部分内容提供了PP评估所需的证据。

这些证据能够证明PP内的需求是完整而连贯的，它可以为TOE在其安全环境内提供一套有效的IT安全抵抗措施。

该基本原理内容包括如下：

a）安全目标原理应表明所有陈述的安全目标可追踪到TOE安全环境

中确定的所有方面。

b）安全需求原理应表明这一系列安全需求能够满足并追踪到安全目标。

如：

1）TOE及其IT环境的各个功能和保证需求组件的组合满足所提出的安全目标。

2）这一系列需求一起形成了一个相互支撑、内部连贯的整体。

3）安全需求的选择是合理的，下列任一条件下需要特别的证明：

●所选择的需求没有包含在附录一和附录二中；

●所选择的保证需求没有指定一个EAL；

●相关性不满足。

4）PP的功能等级所选择的强度，以及任意功能明确要求的强度，与

TOE的安全目标是统一的。

附录一

信息技术安全评估

通用准则（CommonCriteria）

安全功能需求

（Securityfunctionalrequirements）

1安全功能需求内容结构

1.1概述

本章定义了CC功能需求的内容和叙述方式，为ST中包含的新的组件（components）的组织要求提供指导。

功能需求是以类（Class），属（Family），组件（component）的结构形式描述的。

1.1.1类结构

图1.1以图表的形式图解了功能类结构，每一功能类包含一个类名，类介绍，一个或多个功能属。

图1.1功能类结构

1.1.1.1类名称

类名称提供了功能类的识别和分类的必要信息。

每一个功能类有一个独特的名字。

分类信息都包含一个三个字符的短名字。

类名称也用在类的属名字规范中。

1.1.1.2类简介

类简介阐述了满足安全目标的属的基本内容或方法。

功能类的定义在要求的规范中并不反映正式的分类法。

类简介提供了一个图表来描述类所包含的属以及每一属中组件的承接关系。

1.1.2属结构

图1.2表示了功能属的结构。

1.1.2.1属名称

属名称提供了识别和分辨功能属所必须的分类和描述信息。

每一功能属有一独特的名称。

分辨信息包含一个七字符的短名，开始三个字符表示对应的类名称，类名称后是下划线和属的短名，形式如XXX_YYY。

1.1.2.2属行为

属行为概述了功能属的安全目标和功能需求。

详细描述如下：

a）如果TOE包含了属的一个组件，则属安全目标叙述了在TOE的帮助下能解决的安全问题。

b）功能需求描述概括了组件中包含的所有需求。

这些描述可以帮助PPs，STs的作者判别该属是否与其特殊的需求相关。

1.1.2.3组件级别

功能属包含了一个或多个组件，其中任何一个组件可选为PPs,STs的内容。

本节的目的是，一旦该属被用户选作他们功能需求的必须部分，为用户提供选择合适功能组件的信息。

1.1.2.4管理

管理需求为PP/ST作者在考虑一个组件的管理行为时提供信息。

管理需求详细包含在管理类（FMT）的组件中。

1.1.2.4审计

如果类FAU里的需求，安全审计，包含在PP/ST中，审计需求包含了PP/ST作者可选择的审计事件。

1.1.3组件结构

图1.3表示了功能组件结构。

组件

依赖关系

功能元素

组件识别

管理

组件等级

属行为

属名称

功能属

图1.2功能属结构图1.3功能组件结构

1.1.3.1组件识别

组件识别为组件的识别、分辨、注册和前后引用提供了描述信息。

1.1.3.2功能元素

每一个组件提供了一系列的元素，每一个元素是独立的。

一个功能元素是一个不可再分的安全需求。

1.1.3.3依赖关系

当一个组件不能自我满足，必须依赖于其他组件的功能时，这样组件之间的依赖关系就产生了。

每一个组件提供了对其它功能和置信组件的依赖关系列表。

2类FAU：

安全审计

安全审计主要涉及的工作是对有关安全活动的信息的识别、记录、存储和分析（这里有关安全活动是指由TSP所控制的活动）。

通过对审计结果的检查，可以决定已发生了何种安全相关活动及其执行者。

2.1安全审计自动响应（FAU_ARP）

属FAU_ARP定义了当检测到预示着某种潜在的安全入侵行为后，系统应采取的响应措施。

FAU_ARP.1安全警报，一旦检测到潜在的入侵行为时，TSF应采取的行动。

关联性：

FAU_ARP.1。

2.2安全审计数据产生（FAU_GEN）

属FAU_GEN定义了记录在TSF控制下发生的安全相关事件的需求。

它确定了审计的级别，列举了应被TSF审计的事件的类型，规定了在不同的审计记录类型中应提供的最小审计信息。

FAU_GEN.1规定了可审计事件的级别，确定了每一记录中的数据列表。

FPT_STM.1。

FAU_GEN.2用户身份链接。

它将被审计事件与单个用户身份链接起来。

FAU_GEN.1,FIA_UID.1

FAU_GEN.1.1能产生下列审计事件的审计记录：

a.审计功能的开启和关闭；

b.所有审计事件的审计等级[最低限度、基本级、详细级、未指定]；

c.[分配：

其它未被特别定义的审计事件]。

FAU_GEN.1.2在每一审计记录中至少应包含以下信息：

a.事件发生的日期、时间、事件类型、主体身份和事件结果；

b.对于每一审计事件的类型，是以包含在PP/ST中的功能元件的可审计事件的定义为基准。

FAU_GEN.2.1应能将每一审计事件和导致该事件的用户联系起来。

2.3安全审计分析（FAU_SAA）

FAU_SAA定义通过分析系统行为和审计数据寻找可能的或确实存在的安全侵害的方式的需求。

FAU_SAA.1潜在侵害分析，混合规则设置基础上的基本阈值检测是必需的。

FAU_GEN.1.

FAU_SAA.2基于一般检测的轮廓。

TSF维持系统使用的独立轮廓，这里轮廓代表了轮廓目标群（profiletargetgroup）成员执行的历史使用模式。

一个轮廓目标群是指与TSF相互作用的一个或多个用户（个人或组织）。

每一个轮廓目标群成员分配一个独立的怀疑度等级（suspicionrating）。

FIA_UID.1

FAU_SAA.3简单攻击试探法。

TSF应能检测签名事件的发生，签名事件代表对TSP实施的严重威胁。

签名事件的搜索实时进行或以post-collectionbatch-mode方式进行。

无。

FAU_SAA.4复杂攻击试探法。

TSF应能够检测多步入侵企图。

TSF能比较区分系统事件和入侵企图的事件。

2.4安全审计回顾（FAU_SAR）

FAU_SAR定义了授权用户可借助审计工具对审计数据进行回顾。

FAU_SAR.1提供了从审计记录读取信息的能力。

FAU_GEN.1

FAU_SAR.2受限制的审计回顾，要求除了FAU_SAR.1授权的用户外，其它用户均不能读取审计数据的信息。

FAU_SAR.1

FAU_SAR.3可选择的审计回顾，要求审计回顾工具可根据一定的准则来选择审计数据进行回顾。

2.5安全审计事件选择（FAU_SEL）

FAU_SEL定义了在TOE运行过程中，从可审计事件中选取或排除事件的需求。

FAU_SEL.1选择审计事件。

定义了根据PP/ST作者所指定的属性，从审计事件列表中选取事件的能力。

关联性：

FAU_GEN.1,FMT_MTD.1

2.6安全审计事件存贮（FAU_STG）

FAU_STG定义了对TSF建立和维持安全审计跟踪的需求。

FAU_STG.1受保护的审计跟踪存贮，提出了对审计跟踪的要求，防止审计跟踪记录被非法删除或修改。

FAU_STG.2审计数据有效性保证，对在非正常条件下保证TSF维持审计数据提出需求。

FAU_STG.3如果审计数据丢失时的行动措施，定义了如果审计跟踪阈值超出时的行动。

FAU_STG.1

FAU_STG.4当审计跟踪数据满时，预防审计数据丢失的行动。

3类FCO：

通讯

类FCO考虑的是参与数据交换的双方的身份认证问题，它确保信息发送方不能抵赖其所发送的信息，接收方也不能否认其接收到的信息。

3.1发送者的不可抵赖性（FCO_NRO）

FCO_NRO确保当发送者发出信息后，其身份信息不可成功地抵赖，要求TSF能提供一种方法，确保在信息交流过程中，信息接收方同时应收到发送者身份的信息，该信息能被接收者和其他人核实。

FCO_NRO.1发送者选择性证据要求TSF提供给主体要求发送者信息证据的能力。

FCO_NRO.2发送者执行证据，要求传递信息时TSF能始终产生发送者的证据。

3.2接收者的不可抵赖性（FCO_NRR）

FCO_NRR要求TSF提供一种方法，确保发送者能得到接收者收到信息的证据，这种证据能被发送者和其他人核实。

FCO_NRR.1接受者选择性证据要求TSF提供给主体要求接收者信息证据的能力。

FCO_NRR.2接收者执行证据，要求接收信息时TSF能始终产生接收者的证据。

4类FCS：

密码支持

FCS要求采用加密功能来帮助满足几种高级目标，这些包括（但不局限于）：

识别和授权；

不可抵赖；

安全通道等；

加密功能的应用可以是硬件，软件或软硬件相结合。

4.1密钥管理（FCS_CKM）

密钥在其生命周期内必须管理好，FCS_CKM对TSF定义了如下的动作要求：

密钥产生，密钥发布，密钥访问和密钥取消。

FCS_CKM.1要求按照指定算法产生密钥，密钥长度根据指定的标准产生。

FCS_CKM.2或FCS_COP.1,FCS_CKM.4,FMT_MSA.2

FCS_CKM.2密钥发布，根据指定的发布方法和标准发布密钥。

FDP_ITC.1或FCS_CKM.1,FCS_CKM.4,FMT_MSA.2

FCS_CKM.3密钥访问，要求根据指定标准，按照特定的密钥访问方法执行密钥访问。

FDP_ITC.1或FCS_CKM.1,FCS_CKM.4,FMT_MSA.2

FCS_CKM.4密钥废除，基于指定标准，按照特定方法废除密钥。

FDP_ITC.1或FCS_CKM.1,FMT_MSA.2

4.2密码操作（FCS_COP）

为了密码操作正确，操作必须符合指定算法和密钥长度。

典型的密码操作包括数据加密/解密，数值签名产生/核实，哈希运算（信息摘要），密钥加/解密，密钥协议。

FCS_COP.1要求按照指定算法和密钥长度执行密码操作，指定算法和密钥长度是以一个要求的标准产生的。

5类FDP：

用户数据保护

该类包含的属对保护用户数据有关的TOE安全功能和TOE安全功能策略规定了要求。

类FDP能被分成四个属。

5.1访问控制策略（FDP_ACC）

FDP_ACC确定访问控制SFPs（通过名字），并定义了形成TSP识别的访问控制部分的控制策略范围。

控制范围由以下三个要素表示：

受该策略控制的主体；

受该策略控制的客体；

受控主体和受控客体之间的操作。

FDP_ACC.1子集访问控制。

FDP_ACF.1

FDP_ACC.2完全访问控制。

5.2访问控制功能（FDP_ACF）

FDP_ACF描述实施了FDP_ACC中指定的访问控制策略的特定功能的规则。

叙述了安全属性使用和策略特征。

FDP_ACF.1访问控制基础上的安全属性允许TSF根据安全属性实施访问。

进而，TSF或许具有根据安全属性明确认可和否定对客体访问的能力。

FDP_ACC.1,FMT_MSA.3

5.3数据鉴别（FDP_DAU）

数据鉴别允许团体对信息的真实性负责（如对信息数值签名）。

FDP_DAU提供了保证特定单元数据有效性的方法，从而也可用来验证信息内容没有伪造或恶意篡改。

FDP_DAU.1基本数据鉴别，要求TSF能够保证客体信息内容的真实性。

无

FDP_DAU.2用保证人身份进行数据鉴别，额外要求TSF能建立提供真实性保证的主体的身份。

5.4输出TSF控制（FDP_ETC）

FDP_ETC定义了从TOE输出用户数据的功能，信息一旦输出，其安全属性和保护要么被明确保留，要么被忽略。

FDP_ETC.1无安全属性的用户数据输出，当超出TSF输出用户数据时，TSF实施合适的SFPs。

通过这种功能输出的用户数据没有相关的安全属性。

FDP_ACC.1或FDP_IFC.1

FDP_ETC.2带安全属性的用户数据输出，要求TSF用合适的SFPs将输出用户数据与安全属性正确而明确的联系起来。

5.5信息流控制策略（FDP_IFC）

FDP_IFC确定信息流控制SFPs（通过名字），并定义了形成TSP识别的信息流控制部分的控制策略范围。

受该策略控制的信息；

导致受控信息流进和流出策略控制主体的操作。

FDP_IFC.1子信息流控制。

FDP_IFF.1

FDP_IFC.2完全信息流控制。

5.6信息流控制功能（FDP_IFF）

FDP_IFF描述了实施由FDP_IFC指定的信息流控制SFPs的特定功能的规则，同时FDP_IFF也规定了该策略的控制范围。

它由两种需求组成：

一种叙述一般的信息流功能问题；

另一种叙述非法信息流（如：

转变信道）。

这种分类的产生是由于，在某种意义上，所谓的非法信息流是与信息流控制SFP的余下部分垂直的，它们本质上围绕着信息流控制SFP，造成对该策略的侵害。

这样，他们要求限制和防止非法信息流发生的特定功能。

FDP_IFF.1简单安全属性，要求信息的安全属性，关于促使信息流动主体的安全属性，扮演信息接收者主体的安全属性。

规定了该功能必需实施的规则，描述该功能如何推导安全属性。

FDP_IFC.1,FMT_MSA.3

FDP_IFF.2根据FDP_IFF.1简单安全属性的要求扩展分级的安全属性，通过要求TSP中所有的信息流控制SFPs使用分级的安全属性，从而形成网格结构。

FDP_IFF.3受限制的非法信息流，要求SFP包括非法信息流，但不是一定要删除它。

AVA_CCA.1,FDP-IFC.1

FDP_IFF.4非法信息流的部分删除，要求SFP包含删除某些（不一定是所有）非法信息流的内容。

AVA_CCA.1,FDP_IFC.1

FDP_IFF.5无非法信息流，要求SFP能删除所有的非法信息流。

AVA_CCA.3,FDP-IFC.1

FDP_IFF.6非法信息流监测，要求SFP能监测指定和最大容量的非法信息流。

5.7超出TSF控制的输入（FDP_ITC）

FDP_ITC规定了输入TOE的用户数据的保护机理，使输入用户数据具有合适的安全属性并能被妥善地受到保护。

涉及的内容有输入的限制，安全属性的指定，对用户安全属性的解释。

FDP_ITC.1无安全属性的用户数据输入，要求用户数据被正确地赋予安全属性。

FDP_ACC.1或FDP_IFC.1,FMT_MSA.3

FDP_ITC.2带安全属性的用户数据输入，要求安全属性能正确表示用户数据，并能正确而明晰地与用户数据联系在一起。

FDP_ACC.1或FDP_IFC.1,FTP_ITC.1或FTP_TRP.1,FPT_TDC.1

5.8TOE内部传递（FDP_ITT）

当用户数据通过内部信道在TOE各部分之间传递时，FDP_ITT提出了对用户数据的保护需求。

它与FDP_UCT和FDP_UIT相反，FDP_UCT和FDP_UIT是对用户数据通过外部信道在不同的TSFs之间传递时的保护需求。

FDP_ITT.1基本的内部传输保护，要求用户数据在TOE个部分之间传递时能受到保护。

FDP_ITT.2基于具有FDP_ITT.1以外的SFP相关属性的值分离用户数据。

FDP_ITT.3完整性监测。

FDP_ACC.