安全评估培训课件.pptx
安全评估安全评估 ToC 安全评估准则 DOD/TCSEC橘皮书 DOD/TNI红皮书 ITSEC CSSC NIST/FIPS CC BS7799 密码设备的评估 安全方案的规划 需求分析 具体方案 基础设施 产品规划 关于安全评估 需要什么样的安全 使用什么技术 买什么产品 对产品的评估 如何部署和实施 对运行系统的现状的评估 标准：关于建立、评估、审计 沿革关系 TCSEC/85/AM ITSEC/90/EU CTCPEC/90/CA FC/91/AM CC/95 (99IS) BS7799/95/EN ISO17799/2000/ISO DOD/TCSEC C级 自主保护级 C级 具有一定的保护能力，采用自主访问控制和审计跟踪 一般只适用于具有一定等级的多用户环境 具有对主体责任及其动作审计的能力 C1级 自主安全保护级 隔离用户与数据，使用户具备自主安全保护的能力 为用户提供可行的手段，保护用户和用户组信息，避免其他用户对数据的非法读写与破坏 适用于处理同一敏感级别数据的多用户环境 C2级 控制访问保护级 比C1级具有更细粒度的自主访问控制 通过注册过程控制、审计安全相关事件以及资源隔离，使单个用户为其行为负责 B级 强制保护级 B级 维护完整的安全标记，并在此基础上执行一系列强制访问控制规则 主要数据结构必须携带敏感标记 提供安全策略模型以及规约 应提供证据证明访问监控器得到了正确的实施 B1级 标记安全保护级 要求具有C2级系统的所有特性 应提供安全策略模型的非形式化描述、数据标记以及命名主体和客体的强制访问控制 消除测试中发现的所有缺陷 - B2级 结构化保护级 要求将B1级系统中建立的自主和强制访问控制扩展到所有的主体与客体 鉴别机制应得到加强，提供可信设施管理以支持系统管理员和操作员的职能 提供严格的配置管理控制 B2级系统应具备相当的抗渗透能力 - B3 安全区域保护级 安全管理员职能 扩充审计机制 当发生与安全相关的事件时，发出信号 提供系统恢复机制 系统具有很高的抗渗透能力 A级 验证保护级 A级 使用形式化的安全验证方法，保证系统的自主和强制安全控制措施能够有效地保护系统中存储和处理的秘密信息或其他敏感信息 为证明满足设计、开发及实现等各个方面的安全要求，系统应提供丰富的文档信息 A1级 验证设计级 在功能上和B3级系统是相同的 要求用形式化设计规范和验证方法来对系统进行分析，确保按设计要求实现 - 超A1级 系统体系结构 安全测试 形式化规约与验证 可信设计环境等 TNI TNI Trusted Network Interpretation of the TCSEC Goto“TNI.htm”“TNIEG.htm” Content Part I Part II APPENDIX A, B, C TNI / I Part I of this document provides interpretations of the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) (DOD-5200.28-STD), for trusted computer/communications network systems. The specific security feature, the assurance requirements, and the rating structure of the TCSEC are extended to networks of computers ranging from isolated local area networks to wide-area internetwork systems. TNI / II Part II of this document describes a number of additional security services (e.g., communications integrity, denial of service, transmission security) that arise in conjunction with networks. Those services available in specific network offerings, while inappropriate for the rigorous evaluation applied to TCSEC related feature and assurance requirements, may receive qualitative ratings. ITSEC ITSEC by European Union Information Technology Security Evaluation Criteria Goto “itsec-en.pdf” Ex递增 E0 无安全保证 E1 有安全目标和关于体系结构设计的非形式化描述 E2 对详细设计有非形式化的描述 - E3 评估源代码或硬件设计图 E4 有对安全目标/策略的基本形式模型 E5 设计和源代码/硬件有紧密的对应关系 E6 安全功能/体系结构设计与安全目标/策略模型一致 CSSCCTCPEC CSSC: CTCPEC Goto “ctcpec1.pdf” Canadian System Security Centre: Canadian Trusted Computer Product Evaluation Criteria It is a computer security standard comparable to the American TCSEC (Orange Book) but somewhat more advanced. It has been superseded by the international Common Criteria standard. 可和TCSEC相比，但更进步 已被国际标准CC替代 NIST/FIPS CC CC 3Parts Part 1Introduction and General Model Part 2Security Functional Requirements Annexes Part 3Security Assurance Requirements refto:/addon_11/CC_Overview.ppt CC / EALEvaluation Assurance Levels EAL1：功能测试 EAL2：结构测试 EAL3：系统测试和检查 EAL4：系统设计、测试和复查 EAL5：半形式化设计和测试 EAL6：半形式化验证的设计和测试 EAL7：形式化验证的设计和测试 EAL1: Functional Test Confidence in current operation is required No assistance from TOE developer Applicable where threat to security is not serious Independent testing against specification and guidance documentation EAL2: Structural Test Requires some cooperation of the developer Adds requirements for configuration list, delivery, high-level design documentation, developer functional testing, vulnerability analysis, and more extensive independent testing EAL3: Methodical Test and Check Requires some positive security engineering at the design stage, with minimal changes to existing practices Added assurance through investigation of product and development environment controls, and high-level design documentation Places additional requirements on testing, development environment controls and TOE configuration management EAL4: Methodical Design, Test, and Review Highest level likely for retrofit of an existing product Additional requirements on design, implementation, vulnerability analysis, low level design documentation, development and system automated configuration management, and an informal security policy model EAL5: Semiformal Design and Test Higher assurance, risk situations where some penetration resistance is needed Requires rigorous commercial development practices and moderate use of specialist engineering techniques Additional requirements on semi-formal functional specification, high-level design, and their correspondence, vulnerability, and covert channel analysis EAL6: Semiformally Verified Design and Tested High Assurance - where penetration resistance is necessary Additional requirements on analysis, layered TOE design, semi-formal low-level design documentation, complete CM system automation and a structured development environment, and vulnerability/covert channel analysis EAL7: Formally Verified Design and Tested Highest assurance where high resistance to penetration is necessary Assurance is gained through application of formal methods in the documentation of the functional specification and high-level design Additional requirements for complet
