安全架构和设计/安全产品评估方法和标准
外观
< 安全架构和设计
- 安全评估会检查系统的安全相关部分,即 TCB、访问控制机制、参考监控器、内核和保护机制。这些组件之间的关系和交互也会被评估。
- 有不同的方法来评估系统并为其分配保证级别。有两个原因解释了为什么存在不止一种类型的保证评估流程
- 方法和意识形态随着时间的推移而演变,并且
- 世界各地对计算机安全的看法不同,对安全某些方面的评级也不同
- 评估程序在安全产品供应商和客户之间建立信任关系。
评估标准
- 信息技术安全评估准则 (ITSEC) - 欧盟
- 可信计算安全评估准则 (TCSEC) - 美国
- 通用准则 - ITSEC 和 TCSEC 的混合体
彩虹系列是一套书籍,涵盖了所有安全领域,如
- 红皮书 - 网络安全
- 橙皮书 - 操作系统安全
- 黄皮书 - 安全风险管理
- 紫皮书 - 数据库安全
最初只有橙皮书存在,但其他书籍已经发展到涵盖所有安全领域,因此该系列被称为彩虹系列 |
概述
- TCSEC 由美国国防部开发,并发布在橙皮书中,因此也称为橙皮书
- 它主要解决机密性,但不解决完整性,主要解决政府和军事需求。
- 它用于评估产品是否包含供应商声称的安全性,以及产品是否适合特定应用或功能。
- 它用于在评估过程中审查产品的功能、有效性和保证,并使用为解决安全需求的典型模式而设计的类别。
- TCSEC 提供一个分类系统,分为不同的保证级别,其中 A 代表最高级别,D 代表最低级别。
- A:验证保护
- B:强制保护:变体 - B1<B2<B3
- C:酌情保护:变体 -C1<C2
- D:最低安全
级别是同心圆的。即如果产品在 B2 级别获得保证,这意味着它满足 D、C1、C2 和 B1
标准
- 安全策略 - 策略必须明确、定义良好,并由系统内的机制执行。
- 识别 - 个人主体必须被唯一识别。
- 标签访问 - 访问控制标签必须与对象正确关联。
- 文档 - 必须提供文档,包括测试、设计和规范文档、用户指南和手册。
- 问责制 - 必须捕获和保护审计数据以执行问责制。
- 生命周期保证 - 软件、硬件和固件必须能够单独测试,以确保它们在整个生命周期内以有效的方式执行安全策略。
- 持续保护 - 安全机制和系统整体必须在不同的情况下持续地以可预测和可接受的方式执行。
即使评估是根据上述类别独立完成的,但最终分配的评级是这些项目的总和。 |
保证级别
- D 类:最低保护 - 它保留给已评估但未达到更高类别的标准和要求的系统。
- C 类:酌情保护 - C 评级类别包含两个单独的保证评级。
- C1:酌情安全保护
- 基于个人和/或团体。
- 它需要用户和信息的隔离,并提供对个体实体的识别和身份验证。
- 需要此评级的环境类型是用户以相同敏感性级别处理信息的类型;因此,不需要严格的访问控制和审计措施。
- 这将是一个安全问题较小的可信环境
- C2:受控访问保护
- 用户需要单独进行身份验证才能提供更精确的访问控制和审计功能。
- 逻辑访问控制机制用于执行身份验证和每个个人身份的唯一性
- 需要 C2 评级系统的环境类型是用户可信但需要一定程度的问责制的环境。
- 总的来说,C2 被认为是商业应用程序最合理的类别,但保护级别仍然相对较弱
- C1:酌情安全保护
- B 类:强制保护 - 强制访问控制通过使用安全标签执行。体系结构基于 Bell-LaPadula 安全模型,并且必须提供参考监控器执行的证据
- B1:标记安全
- 每个数据对象必须包含一个分类标签,每个主体必须包含一个安全级别标签。
- 当主体尝试访问对象时,系统必须比较主体和对象的安全性标签,以确保请求的操作是可以接受的。
- 离开系统的數據也必须包含准确的安全标签。
- 安全策略基于非正式陈述,设计规范经过审查和验证。
- 此安全评级适用于需要系统处理机密数据的环境。
- B2:结构化保护
- 安全策略已明确定义并记录在案,系统设计和实现经过更彻底的审查和测试程序。
- 此类别要求更严格的身份验证机制以及层之间定义明确的接口。
- 主体和设备需要标签,系统不得允许隐蔽通道。
- 需要 B2 系统的环境类型是处理敏感数据且对渗透和破坏具有较强抵抗力的环境。
- B3:安全域
- 在此类别中,每种保护机制都提供了更多粒度,并且不需要支持安全策略的编程代码被排除在外。
- 参考监控器组件必须足够小,以便能够正确测试并且防篡改
- 系统必须能够在不损害安全级别的情况下从故障中恢复。
- 需要 B3 系统的环境类型是高度安全的环境,处理非常敏感的信息,并且对渗透具有很强的抵抗力。
- B1:标记安全
- A 类:验证保护 - 正式方法用于确保所有主体和对象都受到必要的酌情和强制访问控制。设计、开发、实施和文档以正式和详细的方式进行审查
- A1:验证设计
- 正式技术用于证明 TCB 规范与安全策略模型之间的等价性。
- 在 A1 系统开发过程中,更严格的变更配置到位,并且可以验证整体设计
- 需要 A1 系统的环境类型是最安全的安全环境。这种类型的环境处理绝密信息,并且在没有严格的身份验证、限制和审计的情况下,不能充分信任任何使用系统的人。
- A1:验证设计
TCSEC 神话
- 它专门关注操作系统,而不关注网络、数据库等其他问题。
- 它主要关注安全的一个属性,即机密性,而不关注完整性和可用性。
- 它使用政府分类,而不是商业行业使用的保护分类。
- 它拥有相对较少的评级,这意味着许多不同的安全方面没有得到独立评估和评级。
概述
- 红皮书,也称为可信网络解释 (TNI),处理网络和网络组件的安全评估主题。
- 与橙皮书类似,红皮书没有提供有关如何实现安全机制的具体细节;相反,它提供了一个框架来保护不同类型的网络。
- 它对网络和网络组件内部发生的数据的机密性和操作进行评级。
红皮书中解决的安全问题
- 通信完整性
- 身份验证防止冒充和重播攻击。机制包括数字签名、加密、时间戳和密码。
- 消息完整性保护协议头、路由信息和数据包有效载荷不被修改。机制包括消息认证和加密。
- 不可否认性确保发送者无法否认发送消息。机制包括加密、数字签名和公证。
- 拒绝服务攻击预防
- 业务连续性确保网络即使在遭受攻击的情况下也能保持可用性。机制包括容错和冗余系统,以及在紧急情况下重新配置网络参数的能力。
- 网络管理监控网络性能,识别攻击和故障。机制包括允许网络管理员监控和限制资源访问的组件。
- 妥协保护
- 数据机密性保护数据在传输过程中不被以未经授权的方式访问。机制包括访问控制、加密和对电缆的物理保护。
- 流量机密性确保未经授权的实体无法通过流量分析了解路由信息或通信频率。机制包括填充消息、发送噪声或发送虚假消息。
- 选择性路由以避免特定威胁的方式路由消息。机制包括网络配置和路由表。
概述
- 由于 TCSEC 是由美国开发的,ITSEC 是由欧盟开发的,以解决所有安全评估问题。
- ITSEC 具有两个主要的评估属性
- 功能 - 当评估系统的保护机制的功能时,会检查和衡量为主体提供的服务,例如访问控制机制、审计、身份验证等。
- 保证 - 保证是指对保护机制及其有效性和持续执行能力的信心程度。通常通过检查开发实践、文档、配置管理和测试机制来测试保证。
评估标准
ITSEC 具有 10 个等级 F1 到 F10 来评估功能要求,以及 7 个等级 E0 到 E6 来评估保证要求。
- 安全功能要求
- F00:识别和认证
- F01:审计
- F02:资源利用
- F03:可信路径/信道
- F04:用户数据保护
- F05:安全管理
- F06:产品访问
- F07:通信
- F08:隐私
- F09:保护产品安全功能
- F10:密码支持
- 安全保证要求
- E00:指南文件和手册
- E01:配置管理
- E02:漏洞评估
- E03:交付和操作
- E04:生命周期支持
- E05:保证维护
- E06:开发
- 测试
ITSEC 评级
- 评级基于有效性和正确性。
- 有效性是指 TOE 满足供应商指定的安全性要求。此分析着眼于构造和操作漏洞以及易用性,以确保适当的安全设置不会妨碍生产力。- 评级功能
- 正确性涉及 TOE 的构建方式以及实施问题。这种类型的分析着眼于架构设计、安全机制如何实施策略以及操作文档和环境。- 评级保证。
TCSEC 与 ITSEC
- TCSEC 将功能和保证捆绑在一个评级中,而 ITSEC 分别评估这两个属性。
- ITSEC 比 TCSEC 提供更大的灵活性。
- ITSEC 处理完整性、可用性和机密性,而 TCSEC 仅处理机密性。
- ITSEC 还处理网络化系统,而 TCSEC 处理独立系统。
概述
- 通用准则是 ISO 试图将多个组织聚集在一起以合并和调整现有和新兴评估标准(如 TCSEC、ITSEC、加拿大可信计算机产品评估准则 [CTCPEC] 和联邦标准)的结果。
- 它是通过美国、加拿大、法国、德国、英国和荷兰国家安全标准组织之间的合作开发的。
- 在通用准则模型下,对产品进行评估并分配评估保证级别 (EAL)
CC 的好处
- 通过减少评级的复杂性并消除理解不同评估方案中不同评级的定义和含义的必要性来帮助消费者。
- 帮助制造商,因为现在他们可以构建一套特定的要求来满足他们的产品在国际上的销售,而不是必须满足具有不同规则和要求的多个不同评级。
CC 保证级别
- 通用准则有七个保证级别,范围从 EAL1(最低),其中进行功能测试,到 EAL7(最高),其中进行彻底的测试并验证系统设计。
- EAL 1 功能测试
- EAL 2 结构测试
- EAL 3 系统测试和检查
- EAL 4 系统设计、测试和审查
- EAL 5 半正式设计和测试
- EAL 6 半正式验证设计和测试
- EAL 7 正式验证设计和测试
保护配置文件
- 保护配置文件是一种机制,CC 在其评估过程中使用它来描述目前市场上没有的产品的实际需求。
- 保护配置文件特征
- 包含安全要求集、其含义和理由,以及预期产品所需的相应 EAL 评级。
- 描述环境假设、目标以及功能和保证级别期望。每个相关威胁都列出来,以及如何通过特定目标来控制它。
- 证明每个保护机制强度的保证级别和要求。
- 为消费者或其他人提供一种识别特定安全需求的方法;这是要克服的安全问题。
- 提供实现必要安全级别的必要目标和保护机制,以及系统开发过程中可能出现的问题清单。
- 保护配置文件部分
- 描述性元素 提供配置文件的名称以及要解决的安全问题的描述。
- 理由 证明配置文件并提供更详细的描述,说明要解决的实际问题。说明环境、使用假设和威胁,以及关于符合此配置文件的产品和系统可以支持的安全策略的指南。
- 功能要求 建立一个保护边界,这意味着要消除的边界内的威胁或妥协。产品或系统必须强制执行本节中建立的边界。
- 开发保证要求 识别产品或系统在开发阶段(从设计到实施)必须满足的特定要求。
- 评估保证要求 建立评估的类型和强度。
CC 组件
- 保护配置文件 - 对所需安全解决方案的描述。
- 评估目标 - 提议提供所需安全解决方案的产品。
- 安全目标 - 供应商对满足所需安全解决方案的安全功能和保证机制的书面解释;换句话说,“这就是我们的产品的功能及其工作方式。”
- 软件包 - EAL - 功能和保证要求捆绑在一起以供重复使用。此组件描述了要实现特定 EAL 评级必须满足的要求。
认证
- 认证是对安全组件及其合规性进行的全面技术评估,以进行授权。
- 认证过程可以使用安全评估、风险分析、验证、测试和审计技术来评估特定系统的适当性。
- 认证过程的目标是确保系统、产品或网络适合客户的用途。
授权
- 授权是管理层正式接受系统整体安全性和功能的充分性。
- 认证是对安全机制进行的技术审查,评估其有效性。授权是管理层正式接受认证过程结果中的信息。