J0ker的CISSP之路:系统架构和设计之安全标准

简介:
 
    在《J0ker的CISSP之路》系列的上一篇文章《保护机制》里,J0ker给大家介绍了CISSP CBK中提到的,同时也是现实产品中最常使用的几个保护机制。在实践中采购一个信息技术产品之前,我们一般都会先了解目标产品的安全程度。但如果由不同需求的人员来对产品进行评估,如果没有统一的标准,结果也是千差万别——这样就产生对统一标准的需求,因此世界上的许多国家和组织推出了自己的产品安全评估标准,其中使用最广泛的就是CISSP CBK中介绍到的TCSEC(橘皮书)、TNI(红皮书)、ITSEC和CC这几种。
     在了解这些安全评估标准之前,我们先要了解一下基本的概念:产品和系统。我们知道,所有的安全评估标准,所针对的对象都是产品或系统,那这里所提到的产品和系统到底指的是什么?在CISSP Official Guide里面提到,“产品”,指的是某个特定的可以使用在其设计目标场合的应用程序,或在某些预定义的规则下操作的应用程序,操作系统作为一个整体来看,就是一个产品;而“系统”则是指完成某个特定目标或者在某个特定场合下操作的许多产品的集合。明白这两个概念之间的差异,对理解安全评估标准很有帮助。
说完了最基本的概念,J0ker开始给大家介绍CISSP CBK上所提到的安全评估标准:
    TCSEC,也就是俗称的橘皮书(Orange Book),它是第一个被广泛接受的安全评估标准,由美国国防部于1985年提出,目的在于评估所部署系统的安全程度。TCSEC评估产品的出发点基于三个:
   ◆功能,目标系统所具有的安全功能,比如用户验证和审计;
   ◆有效性,安全功能的使用是否满足所需要提供的安全级别;
   ◆认可度:授权机构对系统所提供的安全级别的认可程度。
   TCSEC把评估对象的安全程度分成了4个等级:A、B、C和D,安全程度从A到D逐级下降,确定为A的产品具有最高的安全性,而D等级的产品则完全没有安全性的考虑。这四个等级的分级标准包括:
   ◆安全策略:目标系统的安全策略设置是强制或自主式访问控制策略
   ◆物件标记:是否对系统内的物件根据敏感程度的不同进行标记
   ◆使用者识别:使用者必须经过识别和验证
   ◆审计:安全相关的事件必须进行日志记录
   ◆保证性:指:1.操作保证性,比如系统架构、对执行域的保护、系统完整性;2.生命周期保证性,如设计方法、安全测试和设置管理等
   ◆文档:用户和管理员应该了解如何安装和使用系统的安全功能,测试人员也需要文档去进行测试
  ◆持续保护:保护机制本身不容易被干扰或破坏
  根据这些分级标准,TCSEC的4个安全等级再细分为7个等级,这些等级的名字和详细内容如下:
分级
安全功能
A1 
(  Verified Security  )
A1 级等于 B3 级,它提供最高的安全性,并设有系统安全管理员这一角色,不过A1级别系统的部署和维护成本也是非常高的,现实中只有极少数的系统要求达到这一安全级别。
B1  、  B2  、 B3 (  Mandatory Protection  )
B1 级( Labeled protection )是安全等级 B 中最低一级,要求提供满足强制访问控制策略的模型,数据标签、已命名的访问者及访问目标控制、更详细的文档和测试、文档 / 源代码 / 目标代码需要经过分析,这个安全等级常用于 Compartment 环境
B2 级( Structured Protection )在 B1 的基础上,增加了更多系统设计要求。其中,要求实现规范的安全模型,隐蔽信道分析、更强的验证方式和可信机房管理。
B3 级( Security Domains )是安全等级 B 中最强的一级,它在 B2 的基础上增加的新元素是安全管理,包括安全事件的自动通知、安全管理员的支持等
C1  、  C2  (  Discretionary Protection  )
C1 级( Discretionary Security Protection )主要用于多用户环境,只提供防止用户的数据被其他用户修改或破坏的基本保护功能
C2 级( Controlled Access Protection )在 C1 的基础上增加了用户登录和审计功能,并使用 DAC 访问控制,尽管 C2 的安全功能较弱,但 C2 级是较适合用于商用系统和程序的安全级别,常见的 MS Windows 和 Linux 都是属于 C2 级别
D
(  Minimal Protection  )
只提交给 TCSEC 评估,自身没有部署安全措施的系统都属于 D 级。
 
     因为TCSEC是1960年代开始设计,并于1985年成型的标准,由于当时安全观点的局限性,TCSEC的评估目标只涉及了保密性,而没有涉及完整性和可用性的评估。因为逐渐不适合现代信息环境和新标准的纷纷推出,美国于2000年废除了TCSEC。
 
    TNI:TNI也称为红皮书(Red Book),由于TCSEC存在评估对象只对单一系统,并且没有完整性评估的缺点,1987年提出了TNI安全标准。TNI用于评估电信和网络系统,它基于TCSEC,同样使用了TCSEC中的ABCD分级方法。
    TNI中的关键功能如下:
     ◆完整性:TNI使用了Biba安全模型来保证数据的完整性,并使用了信息源/目标认证、加密等方法来保证信息传输的完整性
     ◆标签:在使用和TCSEC类似的保密性标签之外,TNI还加入了完整性标签,以进行强制访问控制
     ◆其他安全服务,主要可分成以下几个类型:通讯完整性,包括验证、通讯域完整性、抗抵赖性;拒绝服务防御:操作持续性、基于协议的保护和网络管理;威胁保护:数据保密性和通讯保密性。
 
     ITSEC:在TCSEC标准推出不久,许多欧洲国家也在酝酿推出自己的安全评测标准,结果便是ITSEC的推出。ITSEC于1990年推出第一版草稿,并最终于1995年又欧盟会议批准。尽管ITSEC借用了TCSEC的许多设计思想,但因为TCSEC被认为过分死板,因此ITSEC的一个主要目标就是为安全评估提供一个更灵活的标准。ITSEC和TCSEC的主要区别在于,ITSEC不单针对了保密性,同时也把完整性和可用性作为评估的标准之一。
    ITSEC的制定认识到IT系统安全的实现通常是要将技术和非技术手段结合起来,技术手段用来抵御威胁,而组织和管理手段则用来指导实现。因此ITSEC对目标的评估基于两个因素:有效性和准确性,有效性表明评估目标能够在多大程度上抵御威胁,而准确性则表明系统的设计和操作在多大程度上保证安全性。
    为了涵盖这两个方面,ITSEC使用了“评估目标(TOE)“这一概念,它表述了目标产品的操作安全需求和面临的威胁,而另外一个概念,”安全目标(Security Objectives)“,则表述了目标产品所要满足的安全功能和评估级别。ITSEC的安全等级划分与ITSEC不同,他分为功能性等级(F)和保证性等级(E),这两个等级的具体内容如下:
功能性F:
功能性等级(  F  )
内容
F1-F5
和 TCSEC 安全等级所提供的功能相同
F6
有高完整性要求的系统和应用程序(如数据库系统)
F7
有高可用性要求或特殊要求的系统
F8
有通信完整性要求的系统
F9
有高保密性要求的系统(如加密系统)
F10
网络要求高的保密性和完整性
 
确定性等级E:
确定性等级( E )
内容
E0
无要求
E1
有安全目标和 TOE 的描述,满足安全目标的测试
E2
要求具体设计的描述,测试证据需要加以评估,配置管理,分发控制
E3
需要进行源代码和结构评估,安全机制的测试证据需要加以评估
E4
安全策略模型、需要有安全增强功能、架构设计和详细设计
E5
具体设计和源代码必须相符,并需要使用源代码进行漏洞分析
E6
TOE 的强制标准、安全策略模型的实施
 
     E3级别被认为是最常用的安全产品评估标准,安全操作系统或数据库系统通常会使用F2+E3这个结合来进行评估。下面是J0ker做的一个ITSEC和TCSEC的简单对比表格:
ITSEC
TCSEC
E0
D
F1 + E1
C1
F2 + E2
C2
F3 + E3
B1
F4 + E4
B2
F5 + E5
B3
F5 + E6
A1
F6
系统提供高完整性
F7
系统提供高可用性
F8
系统提供通信时的数据完整性
F9
系统提供高保密性 ( 如加密设备 )
F10
网络要求高的保密性和完整性
 
     在1990年代的早期,TCSEC渐渐不能适应信息技术的发展,美国开始对其进行升级,但不久美国就终止了升级行动,转而和加拿大及欧洲联合制定一个国际统一的安全评估标准,这个联合行动的最终结果便是CC的制定。CC,也即常说的通用准则(Common Criteria),在1999年通过了ISO的认可,称为ISO15408。中国加入WTO之后,按照WTO的规则接受CC为信息系统产品安全评估标准,并制定了相应的国家标准GB18336。
     CC保留了ITSEC的灵活性,并结合了美国联邦准则(FC)的保护轮廓(Protection Profile)及预定义安全级别。
      CC的关键概念有:
     ◆评估对象—— TOE(Target of Evaluation)
     ◆保护轮廓——PP (Protection Profile)
     ◆安全目标——ST( Security Target)
     ◆功能(Function)
     ◆保证(Assurance)
     ◆组件(Component)
     ◆包(Package)
     ◆评估保证级——EAL( Evaluation Assurance Level)
 
     其中保护轮廓是CC最重要的概念,它满足了以下的要求:
     ◆表达一类产品或系统的用户需求
     ◆组合安全功能要求和安全保证要求
     ◆技术与需求之间的内在完备性
     ◆提高安全保护的针对性、有效性
     ◆安全标准
     ◆有助于以后的兼容性
     ◆同TCSEC级类似
     CC是平时大家在工作和实践中最有可能接触到的标准,因此大家可以结合工作中的经验来记忆和理解CC的内容。CISSP考试中对安全标准的考核主要是考概念,TCSEC安全等级的内容、ITSEC和CC里面名词的识记等。最后J0ker把TCSEC、ITSEC和CC做一个比较作为本文的结束:
 
CC  标准
美国 TCSEC
欧洲 ITSEC
--
D: 最小保护
E0
EAL1- 功能测试
--
--
EAL2- 结构测试
C1: 任意安全保护
F1+E1
EAL3- 方法测试和检验
C2: 控制存取保护
F2+E2
EAL4- 方法设计,测试和评审
B1: 标识安全保护
F3+E3
EAL5- 半正式设计和测试
B2: 结构保护
F4+E4
EAL6- 半正式验证的设计和测试
B3: 安全域
F5+E5
EAL7- 正式验证的设计和测试
A1: 验证设计
F6+E6
 
下集预告:《访问控制系统和方法1》,J0ker将带大家进入下一个CBK,并介绍访问控制系统和方法的概念,敬请期待!









本文转自J0ker51CTO博客,原文链接:http://blog.51cto.com/J0ker/53051,如需转载请自行联系原作者

相关文章
|
人工智能 安全 Cloud Native
Nacos 3.0 架构升级,AI 时代更安全的 Registry
随着Nacos3.0的发布,定位由“更易于构建云原生应用的动态服务发现、配置管理和服务管理平台”升级至“ 一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台 ”。
|
存储 设计模式 人工智能
AI Agent安全架构实战:基于LangGraph的Human-in-the-Loop系统设计​
本文深入解析Human-in-the-Loop(HIL)架构在AI Agent中的核心应用,探讨其在高风险场景下的断点控制、状态恢复与安全管控机制,并结合LangGraph的创新设计与金融交易实战案例,展示如何实现效率与安全的平衡。
2222 0
|
人工智能 运维 安全
AI 安全架构概述
AI 安全架构涵盖数据采集、模型训练、推理部署等阶段,确保安全性、隐私与合规。其核心组件包括数据层、模型层、推理层、应用层和运维层,针对数据安全威胁(如数据投毒)、模型窃取、对抗攻击及系统漏洞等风险,提出数据加密、对抗训练、联邦学习等防御策略,并强调开发前、开发中和部署后的最佳实践,以降低 AI 解决方案的安全风险。
1779 14
|
存储 监控 安全
132_API部署:FastAPI与现代安全架构深度解析与LLM服务化最佳实践
在大语言模型(LLM)部署的最后一公里,API接口的设计与安全性直接决定了模型服务的可用性、稳定性与用户信任度。随着2025年LLM应用的爆炸式增长,如何构建高性能、高安全性的REST API成为开发者面临的核心挑战。FastAPI作为Python生态中最受青睐的Web框架之一,凭借其卓越的性能、强大的类型安全支持和完善的文档生成能力,已成为LLM服务化部署的首选方案。
1544 3
|
存储 安全 前端开发
如何开发一套EHS 健康安全环境管理系统?(附架构图+流程图+代码参考)
本文介绍如何开发一套完整的EHS(健康、安全和环境)管理系统,涵盖系统核心模块、技术架构、数据库设计、前后端开发示例及上线建议,帮助企业提升安全管理效率与合规性。
|
传感器 安全 前端开发
如何开发一套EHS健康安全环境管理系统中的风险管理板块?(附架构图+流程图+代码参考)
本文详解企业EHS(健康·安全·环境)系统中的风险管控板块,强调其核心在于构建“识别—评估—巡检—治理—验证”的闭环流程,将风险数据可视化并转化为可落地的行动指引。内容涵盖风险管控的意义、功能边界、系统架构、LEC评估方法、巡检流程、看板设计、开发技巧、落地建议、实现效果及代码参考,帮助技术团队和EHS负责人快速掌握系统搭建要点,提升企业安全管理水平。
|
监控 安全 数据安全/隐私保护
销售易CRM:技术架构与安全性能的深度解析
销售易CRM基于云计算与微服务架构,融合高可用性、弹性扩展及模块化开发优势,为企业提供灵活定制化的客户关系管理解决方案。系统采用多层次安全防护机制,包括数据加密、细粒度权限控制和实时监控审计,确保数据安全与隐私保护。某金融机构的成功案例表明,销售易CRM显著提升了数据安全性和系统性能,同时满足行业合规要求。作为数字化转型的利器,销售易CRM助力企业实现可持续发展与市场竞争力提升。
|
监控 安全 Cloud Native
企业网络架构安全持续增强框架
企业网络架构安全评估与防护体系构建需采用分层防御、动态适应、主动治理的方法。通过系统化的实施框架,涵盖分层安全架构(核心、基础、边界、终端、治理层)和动态安全能力集成(持续监控、自动化响应、自适应防护)。关键步骤包括系统性风险评估、零信任网络重构、纵深防御技术选型及云原生安全集成。最终形成韧性安全架构,实现从被动防御到主动免疫的转变,确保安全投入与业务创新的平衡。
1271 2
|
监控 安全 Cloud Native
云原生安全:Istio在微服务架构中的安全策略与实践
【10月更文挑战第26天】随着云计算的发展,云原生架构成为企业数字化转型的关键。微服务作为其核心组件,虽具备灵活性和可扩展性,但也带来安全挑战。Istio作为开源服务网格,通过双向TLS加密、细粒度访问控制和强大的审计监控功能,有效保障微服务间的通信安全,成为云原生安全的重要工具。
457 2