《{安全生产管理}信息系统安全保护轮廓》由会员分享，可在线阅读，更多相关《{安全生产管理}信息系统安全保护轮廓（58页珍藏版）》请在金锄头文库上搜索。
1、上海格尔软件股份有限公司信息系统安全保护轮廓(PP)产生办法1 前言所谓安全保护轮廓（PP），具体来说，就是为了满足一系列的安全目标而提出的一整套相对应的功能和保证需求。一个PP可以重复使用于一些不同的应用中。PP对于不同的团体均具有重要的意义。它叙述了用户实际的安全方法，为开发者提供了一套开发的基准，为学术界描述了一些很好的安全配置方法，为评估者提供了评估的标准。PP定义了对应一类TOEs的独立于应用的一系列安全需求。这些TOEs能满足用户对IT安全的需要。因而，用户能够不参考任何特定的TOE去构造或引用一个PP来描述他们自己的IT安全需要。PP应作为一个基于用户服务的文件来描述，尽量使PP
2、用户不再去参考那些对于他们很难用到的资料。安全保护的原理应当明确的阐述，如果需要，可以单独提出。PP可以是由用户来制定，也可以是由IT产品研发方来制定，同时也可以由任何其它对此感兴趣的团体来制定。PP给予了用户一种查阅特殊安全需求的方式，同时也使将来对这些需求进行评估变得简单易行。一般而言，在安全目标（ST）中所包含的TOE的安全需求都应当在一个已存在的PP中详细叙述过，与PP中的需求保持一致。由一些已存在的PPs可以产生一个新的PP。2 PP的内容结构TOE安全功能需求TOE安全保证需求保护轮廓（PP）PP介绍PP标识PP概述TOE描述TOE安全环境假设威胁安全组织策略安全目标对TOE的安全
3、目标对环境的安全目标IT安全需求TOE安全需求对IT环境的安全需求PP使用注释基本原理安全目标基本原理安全需求基本原理 图1 PP内容构架3 PP基本内容3.1 PP介绍PP介绍这部分内容应当包括执行PP注册登记所必需的文件管理和概要信息。内容如下：a) PP识别应当提供对PP识别、编制目录、注册、参照所必需的标签和描述信息。b) PP概述应当用简短的形式总结PP。概述必需足够详细，从而能够引起PP用户的兴趣。在PP目录和注册中，概述应独立出来作为摘要。3.2 TOE描述TOE描述这部分内容能帮助读者对于TOE安全需求的理解，应当对其产品型号以及一般的IT特征加以叙述。TOE描述同样提供了评估
4、的内容。TOE描述中提供的信息将用在评估的过程中，来判别是否存在矛盾。由于一个PP一般不仅仅指代一个特定的应用，其所描述的TOE特征可以是假设。如果TOE是一个产品或系统，其首要功能是安全，PP的这部分内容将被用作是对TOE更广泛应用前景的叙述。3.3 TOE安全环境TOE安全环境应描述TOE所应用环境的安全方面，以及TOE期望被采用的方式。陈述应包括如下内容：a) 假设描述了TOE的应用或想要应用的环境的安全方面，如：有关TOE的使用信息，包括可能的应用，潜在的资产价值，对使用的可能的限制。 关于TOE使用环境的信息，包括物理的，人员的以及连接的方面。b) 威胁应当包括所有对TOE内部受特殊
5、保护的资产的威胁。应当申明的是，不是所有在此环境中遇到的可能的威胁必需列举出来，列举出来的仅是与安全的TOE运行相关的那部分。威胁应以一个辩明的威胁代理者，一次攻击的方式描述，而资产是攻击的主体。威胁代理者应当通过这些方面叙述，如专业知识，可用的资源和动机。 攻击应当通过攻击方法，可利用脆弱点和机会来描述。如果仅仅从组织的安全法规以及假设来推导，那么，威胁的描述就可以忽略了。c) 组织的安全法规的描述应确认和解释任何TOE必须遵守的组织的安全法规，解释和说明对于陈述任何一条法规都是必须的，这样有利于指定明确的安全目标。如果TOE是分布式的，则TOE环境的各个独立的范围的安全环境的方方面面（假设
6、，威胁，组织安全法规）必须讨论。3.4 安全目标安全目标这部分应当定义对TOE和其环境的安全目标。其内容应当涵盖已辩明的安全环境的所有方面。安全目标应当反映所陈述的目的，应能对抗所有已识别的威胁，并覆盖所有辩明的组织安全法规和假设。具体有如下的安全目标：a) TOE的安全目标应明确陈述，还须追踪到TOE会遭遇到的已知的威胁以及TOE须遵守的组织安全法规的各个方面。b) 环境的安全目标同样须明确陈述，还应追踪到TOE没有完全遭遇到的已辩明的威胁或TOE须不完全遵守的组织安全法规及假设的各个方面。须注意的是，环境的安全目标也许是对TOE安全环境的假设部分的完全或部分重复叙述。3.5 IT安全需求
7、PP的这部分内容详细定义了TOE及其环境应满足的IT安全需求。IT安全需求具体包括如下内容：a) TOE安全需求定义了为了达到TOE的安全目标，TOE及其评估证据必须满足的功能的和保证的安全需求。TOE的安全需求叙述如下：1） TOE安全功能需求应当适当选择本文附录一内的功能组件来定义TOE的功能上的要求。为了涵盖每一方面的要求，附录一的同一个组件有可能重复使用或使用同一需求的不同方面。当在TOE安全保证需求有组件AVA_SOF.1(EAL2和更高)，TOE安全功能需求应通过概率和排列算法保证其最低的强度等级。所有的功能应当满足最低的等级，该等级需是如下等级中的一个：SOF-Basic, SO
8、F-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的实施不直接相
9、关。c) 在对TOE以及其IT环境的安全功能和保证需求的叙述中应使用如下的一般条件：1） 所有的IT安全需求应当从附录一和附录二中选择，如果其中某些需求不是摘自附录一和附录二，PP中应当明确的说明，该需求不是摘自附录。2） 任何明确说明的非摘自附录的需求应当正确而不含糊的陈述，这样，评估及示范才可行，其具体的等级和描述方式应参考附录里的功能和保证需求。3） 当选择了一些指定了必须的操作的安全需求时，PP应当使用这些操作去放大这些需求的等级，从而能够示范是否达到安全目标。任何PP内没有执行的所要求的操作应当标明。4） 通过使用需求组件中的操作，在必要时，TOE安全需求陈述应有选择地规定或禁止特定
10、安全机制的使用。5） 所有IT安全需求之间的相关性都应满足，通过在TOE的安全需求或环境的需求中包含该相关联的需求来满足相关性。3.6 使用注释PP的这部分包含了对TOE的使用、评估、构造所必需考虑的额外相关的有益支撑信息。3.7 基本原理PP的这部分内容提供了PP评估所需的证据。这些证据能够证明PP内的需求是完整而连贯的，它可以为TOE在其安全环境内提供一套有效的IT安全抵抗措施。该基本原理内容包括如下：a) 安全目标原理应表明所有陈述的安全目标可追踪到TOE安全环境中确定的所有方面。b) 安全需求原理应表明这一系列安全需求能够满足并追踪到安全目标。如：1） TOE及其IT环境的各个功能和保
11、证需求组件的组合满足所提出的安全目标。2） 这一系列需求一起形成了一个相互支撑、内部连贯的整体。3） 安全需求的选择是合理的，下列任一条件下需要特别的证明：l 所选择的需求没有包含在附录一和附录二中；l 所选择的保证需求没有指定一个EAL；l 相关性不满足。4） PP的功能等级所选择的强度，以及任意功能明确要求的强度，与TOE的安全目标是统一的。 附录一信息技术安全评估通用准则(Common Criteria)安全功能需求(Security functional requirements)1安全功能需求内容结构1.1 概述本章定义了CC功能需求的内容和叙述方式，为ST中包含的新的组件（comp
12、onents）的组织要求提供指导。功能需求是以类(Class)，属(Family)，组件(component)的结构形式描述的。1.1.1 类结构图1.1以图表的形式图解了功能类结构，每一功能类包含一个类名，类介绍，一个或多个功能属。功能类类名称类介绍功能属图1.1 功能类结构1.1.1.1 类名称类名称提供了功能类的识别和分类的必要信息。每一个功能类有一个独特的名字。分类信息都包含一个三个字符的短名字。类名称也用在类的属名字规范中。1.1.1.2 类简介类简介阐述了满足安全目标的属的基本内容或方法。功能类的定义在要求的规范中并不反映正式的分类法。类简介提供了一个图表来描述类所包含的属以及每一
13、属中组件的承接关系。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 组件级别功能属包含了一个或多个
14、组件，其中任何一个组件可选为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：安全审计安全审计主要涉及的工作是对有关安全活动的信息的识别、记录、存储和分析（这里有关安全活动是
