安全评估标准.pptVIP

通用准则CC TOE概要规范 ST中提供的TOE概要规范定义TOE安全要求的实现方法，它提供了分别满足功能需求和保证需求的安全功能和保证措施的高层定义 第六十二页，共九十八页，2022年，8月28日 通用准则CC CC定义了一系列与已知有效的安全要求集合相结合的概念，该概念可被用来为预期的产品和系统建立安全需求 CC安全要求以类—族—组件这种层次方式组织，以帮助用户定位特定的安全要求 对功能和保证方面的要求，CC使用相同的风格、组织方式和术语。 第六十三页，共九十八页，2022年，8月28日 通用准则CC CC中安全要求的描述方法： 类：类是最通用安全要求的组合，类的所有的成员关注共同的安全焦点，但覆盖不同的安全目的 族：类的成员被称为族。族是若干组安全要求的组合，这些要求有共同的安全目的，但在侧重点和严格性上有所区别 组件：族的成员被称为组件。组件描述一组特定的安全要求集，它是CC定义的结构中所包含的最小的可选安全要求集 第六十四页，共九十八页，2022年，8月28日 通用准则CC 组件由单个元素组成，元素是安全需求最低层次的表达，并且是能被评估验证的不可分割的安全要求 族内具有相同目标的组件可以以安全要求强度（或能力）逐步增加的顺序排列，也可以部分地按相关非层次集合的方式组织 第六十五页，共九十八页，2022年，8月28日 通用准则CC 组件间的依赖 组件间可能存在依赖关系 依赖关系可以存在于功能组件之间、保证组件之间以及功能和保证组件之间 组件间依赖关系描述是CC组件定义的一部分 第六十六页，共九十八页，2022年，8月28日 通用准则CC 组建允许的操作 可以通过使用组件允许的操作，对组件进行裁剪 每一个CC组件标识并定义组件允许的“赋值”和“选择”操作、在哪些情况下可对组件使用这些操作，以及使用这些操作的后果 任何一个组件均允许“反复”和“细化”操作 第六十七页，共九十八页，2022年，8月28日 通用准则CC 这四个操作如下所述： 反复：在不同操作时，允许组件多次使用 赋值：当组件被应用时，允许规定所赋予的参数 选择：允许从组件给出的列表中选定若干项 细化：当组件被应用时，允许对组件增加细节 第六十八页，共九十八页，2022年，8月28日 通用准则CC CC中安全需求的描述方法: ◆包:组件的中间组合被称为包。 ●包允许对功能或保证需求集合的描述，这个集合能够满足一个安全目标的可标识子集 ●包可重复使用，可用来定义那些公认有用的、能够有效满足特定安全目标的要求 ●包可用在构造更大的包、PP和ST中 第六十九页，共九十八页，2022年，8月28日 TCSEC A类为验证保护级 A类的特点是使用形式化的安全验证方法保证系统的自主，而且强制安全控制措施能够有效地保护系统中存储和处理的秘密信息或其他敏感信息 为证明TCB满足设计、开发及实现等各个方面的安全要求以及采用形式化验证方法，系统应提供丰富的文档信息 第三十页，共九十八页，2022年，8月28日 TCSEC A类分为两个类别： 验证设计级（A1级） 超A1级 第三十一页，共九十八页，2022年，8月28日 TCSEC A1级系统在功能上和B3级系统是相同的，没有增加体系结构特性和策略要求 最显著的特点是，要求用形式化设计规范和验证方法来对系统进行分析，确保TCB按设计要求实现 从本质上说，这种保证是发展的，它从一个安全策略的形式化模型和设计的形式化高层规约（FTLS）开始 第三十二页，共九十八页，2022年，8月28日 TCSEC 针对A1级系统设计验证，有5种独立于特定规约语言验证方法的重要准则： 安全策略的形式化模型必须得到明确标识并文档化，以提供该模型与其公理一致的、能够对安全策略提供足够支持的数学证明 应提供形式化的高层规约，包括TCB功能的抽象定义、用于隔离执行域的硬件/固件机制的抽象定义 第三十三页，共九十八页，2022年，8月28日 TCSEC 应通过形式化的技术（如果可能的话）和非形式化的技术证明TCB的形式化高层规约（FTLS）与模型一致 通过非形式化的方法证明TCB的实现（硬件、固件、软件）与形式化的高层规约（FTLS）是一致的。应证明FTLS的元素与TCB的元素是一致的，FTLS应表达用于满足安全策略的一致的保护机制，这些保护机制的元素应映射到TCB的要素 第三十四页，共九十八页，2022年，8月28日 TCSEC 应使用形式化的方法标识并分析隐蔽信道，非形式化的方法可以用来标识时间隐蔽信道，必须对系统中存在的隐蔽信道进行解释 第三十五页，共九十八页，2022年，8月28日 TCSEC A1级系统: 要求更严格的配置管理 要求建立系统安全分