GB/T 20261-2020 代替 GB/T 20261-2006 信息安全技术 系统安全工程 能力成熟度模型
Information security technology – System security engineering – Capability maturity model
（ISO/IEC 21827:2008, Information technology – Security techniques – Systems security engineering – Capability maturity model, MOD）
意义和作用：
（1）对组织的意义：帮助组织建立完善的系统安全工程管理体系，提高安全工程的实施效率和质量，降低信息系统的安全风险。同时，通过能力成熟度的评估和改进，组织可以不断提升自身的竞争力，满足业务发展和法律法规的要求。
（2）对行业的影响：为信息安全行业提供了一个统一的标准和规范，促进了行业内的技术交流和合作，推动了信息安全技术的发展和应用。此外，该标准的实施也有助于提高整个行业的安全工程能力水平，保障国家信息安全
术语和定义
1 可核查性 accountibility
确保可将一个实体的行动唯一地追踪到此实体的特性。
2 认可 accreditation
权力机构为了对以下三个方面给出正式的认同、批准并且接受他们残余风险所釆取的规程：
1） 有关自动化系统的运行，其中该系统运行在特定的安全模式下，使用一套特定的防护措施；
2） 有关承担特定任务的安全机构或个人；
3） 有关针对目标环境的安全服务。
3 评估 assessment
系统化的检验一个实体满足所规约的需求的程度。当用于可交付件时，与评价是同义的。
4 资产 asset
对组织有价值的任何东西。
5 保障 assurance
为使他人获得可交付件满足其安全目标的信心，而履行的适当行为和过程。
6 保障论据 assurance argument
由证据和推理支持的、清楚地证明保障需要是如何得到满足的一组结构化保障声明。
7 保障声明 assurance claim
系统满足安全需要的断言或支持性断言。
注：保障声明既针对直接威胁（例如，防止系统数据遭受外部攻击），也针对间接威胁（例如，使系统代码漏洞尽可能小）。
8 保障证据 assurance evidence
可以据以做出保障声明判断或者结论的数据。
注：保障证据可由观察项、测试结果、分析结果和评估结果构成。
9 真实性 authenticity
确保主体或者资源的身份正是所声称的特性。真实性适用于用户、进程、系统和信息之类的实体。
10 可用性 availability
根据授权实体的要求可访问和可使用的特性。
11 基线 baseline
经过一个正式评审并通过的规约或产品，作为后续开发的基础。对其变更只有通过正式的变更控制规程方可进行。
12 基本实践 base practices；BP
系统工程过程中应存在的性质，只有当所有这些性质完全实现后，才可说满足了这个过程域的要求。
注：一个过程域由基本实践(BP)组成。
13 能力 capability
组织、体系或过程实现产品并使其满足要求的本领。
14 认证 certification
对可交付件是否符合规定需求所给出的正式保证陈述的规程。可由第三方执行认证或自行认证。
15 保密性 confidentiality
使信息不泄露给未授权的个人、实体、过程，或不被其利用的特性。
16 一致性 consistency
在某一系统或构件中，各文档或各部分之间统一的、标准化的和无矛盾的程度。
17 正确性 correctness
针对规定的安全要求，产品或者系统显示其正确实现这些要求的表现。
18 客户 customer
供方提供的产品的接收者。
注 1：在合同条件下，客户叫做买方。
注 2：客户可以是最终客户、用户、受益人或买方。
注 3：客户可以是组织外部的，也可以是组织内部的，见 ISO 9000。
19 有效性 effectiveness
对某一系统或者产品，在建议的或实际的运行使用环境下，表示其提供安全程度的特性。
20 工程组 engineering group
对与特定工程学科相关的项目或组织活动负责的人群（包括管理人员和技术人员）。
注：工程学科包括硬件、软件、软件配置管理、软件质量保障、系统、系统测试和系统安全。
21 证据 evidence
过程和（或）产品的可直接测量的特征，它体现具体活动满足规定要求的客观的、可表明的证明。
22 信息安全事态 information security event
表明一次可能的信息安全违规或某些控制失效的发生。
23 信息安全事件 information security incident
与可能危害组织资产或损害其运行相关的、单个或多个被识别的信息安全事态。
24 完整性 integrity
准确和完备的特性。
25 维护 maintenance
交付后为了纠正缺陷、改进性能以及其他属性或适应环境变化而对系统或组件进行修改的过程。
26 方法学 methodology
定义系统或产品的完整开发途径的标准、规程和支持方法的集合。
27 渗透轮廓 penetration profile
对渗透所要求的活动的定义。
28 规程 procedure
对执行一个给定任务所采取动作历程的书面描述。
29 过程 process
将输入转换成输出的相互关联或相关作用的活动集。
30 过程域 process area；PA
一组相关系统工程过程的性质，当这些性质全部实施后则能够达到过程域定义的目的。
31 可靠性 reliability
与预期行为和结果一致的特性。
32 残余风险 residual risk
风险处置后余下的风险。
注 1：残余风险可能包含未识别的风险。
注 2：残余风险也可以被称为“保留风险”。
33 风险 risk
对目标的不确定性影响。
注 1：影响是指与期望的偏离（正向的或反向的）。
注 2：不确定性是对事态及其结果或可能性的相关信息、理解或知识缺乏的状态（即使是部分的）。
注 3：风险常被表征为潜在的事态和后果，或者它们的组合。
注 4：风险常被表示为事态的后果（包括情形的改变）和其发生可能性的组合。
注 5：在信息安全管理体系的语境下，信息安全风险可被表示为对信息安全目标的不确定性影响。
注 6：信息安全风险与威胁利用信息资产或信息资产组的脆弱性对组织造成危害的潜力相关。
34 风险分析 risk analysis
理解风险本质和确定风险等级的过程。
注 1：风险分析提供风险评价和风险处置决策的基础。
注 2：风险分析包括风险估算。
35 风险管理 risk management
指导和控制组织相关风险的协调活动。
36 安全策略 security policy
用于治理组织及其系统内如何管理、保护和分发资产（包括敏感信息）的规则、指导和实践，特别是那些影响系统及相关要素的。
37 安全相关要求 security related requirement
直接作用于系统安全运行或者强制执行规定安全策略的要求。
38 系统 system
具有物理存在和既定目的的、完全由集成的、交互的组件组成的离散的可区分实体，每个组件不单 独符合所要求的总体目的。
注 1：在实践中，系统是“在旁观者眼中的”，通常用联合名词来澄清其含义（例如，产品系统、飞机系统）。另一种方式是使用上下文依赖的同义词（例如，产品、飞机）进行简单取代，尽管这可能使系统原理观点变得模糊。
注 2：系统在其生存周期中，为了满足自身的需求，可能需要其他系统。例如，一个运行系统可能需要一个系统用于概念化、开发、生产、运行、支持或处置。
39 威胁 threat
不论是内部还是外部引起的，可能对信息、程序或系统造成损害或者波及其他损害的，敌对者的能力、意图和攻击方式，或者任何环境或事件。
40 威胁方 threat agent
故意或意外的人为威胁的原发方和/或发起方。
41 确认 validation
通过提供客观证据，证实满足特定预期使用或应用要求的行为。
42 验证 verification
通过提供客观证据，证实满足规定要求的行为。
注：也可称为符合性测试。
43 脆弱性 vulnerability
可能被一个或多个威胁利用的资产或控制的弱点。
44 工作产品 work product
在执行任何过程中产生出的所有文档、报告、文件、数据等。
注：一个工作产品可能被一个过程使用、生产或者改变。
暂无评论内容