- 一、信息安全工程
- 二、信息安全管理体系（ISMS）
- 三、等级保护政策发展历程
- 四、P2DR模型
- 五、信息安全需求来源
- 六、风险评估阶段
- 七、信息安全策略变更
- 八、ISMS变更通知
- 九、信息安全策略文档
- 十、应急响应计划
- 十一、信息安全事件分级
- 十二、符合性管理
- 十三、数据备份方案
- 十四、SSE-CMM与系统工程
- 十五、总结
一、信息安全工程
1.1 信息安全工程的正确理念
💡 信息安全工程的核心原则
同步规划、同步建设：
- 在规划阶段合理规划信息安全
- 在建设阶段同步实施信息安全建设
- 安全与功能并重，不可偏废
graph TB
A["信息化建设"]
B["规划阶段"]
C["建设阶段"]
D["运行阶段"]
A --> B
A --> C
A --> D
B --> B1["✅ 规划信息安全"]
B --> B2["✅ 安全需求分析"]
B --> B3["✅ 安全架构设计"]
C --> C1["✅ 同步实施安全建设"]
C --> C2["✅ 安全功能开发"]
C --> C3["✅ 安全测试"]
D --> D1["✅ 安全运维"]
D --> D2["✅ 持续改进"]
style B1 fill:#e8f5e9,stroke:#388e3d
style C1 fill:#e8f5e9,stroke:#388e3d
style D1 fill:#e8f5e9,stroke:#388e3d
1.2 信息安全工程的常见误区
❌ 错误做法
误区一：功能优先论
- ❌ 认为系统功能实现是最重要的
- ✅ 正确：功能与安全同等重要
误区二：事后加固论
- ❌ 先实施系统，而后对系统进行安全加固
- ✅ 正确：同步规划、同步建设
误区三：安全无关论
- ❌ 信息化建设没有必要涉及信息安全建设
- ✅ 正确：信息安全是信息化建设的重要组成部分
信息安全工程理念对比：
| 做法 | 描述 | 是否正确 | 问题 |
|---|---|---|---|
| 功能优先 | 系统功能实现最重要 | ❌ | 忽视安全重要性 |
| 事后加固 | 先建系统后加固 | ❌ | 成本高、效果差 |
| 同步建设 | 规划和建设阶段同步实施安全 | ✅ | 正确做法 |
| 安全无关 | 不涉及信息安全建设 | ❌ | 完全错误 |
二、信息安全管理体系（ISMS）
2.1 ISMS的PDCA模型
GB/T 22080-2008《信息技术 安全技术 信息安全管理体系 要求》指出，建立信息安全管理体系应参照PDCA模型进行。
graph TB
A["ISMS PDCA模型"]
B["Plan
建立ISMS"] C["Do
实施和运行ISMS"] D["Check
监视和评审ISMS"] E["Act
保持和改进ISMS"] A --> B B --> C C --> D D --> E E --> B B --> B1["制定ISMS方针"] B --> B2["风险评估"] B --> B3["选择控制措施"] C --> C1["实施控制措施"] C --> C2["培训和意识教育"] C --> C3["运行管理"] D --> D1["监控和测量"] D --> D2["内部审核"] D --> D3["有效性测量"] E --> E1["纠正措施"] E --> E2["预防措施"] E --> E3["持续改进"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#e8f5e9,stroke:#388e3d style D fill:#fff3e0,stroke:#f57c00 style E fill:#f3e5f5,stroke:#7b1fa2
建立ISMS"] C["Do
实施和运行ISMS"] D["Check
监视和评审ISMS"] E["Act
保持和改进ISMS"] A --> B B --> C C --> D D --> E E --> B B --> B1["制定ISMS方针"] B --> B2["风险评估"] B --> B3["选择控制措施"] C --> C1["实施控制措施"] C --> C2["培训和意识教育"] C --> C3["运行管理"] D --> D1["监控和测量"] D --> D2["内部审核"] D --> D3["有效性测量"] E --> E1["纠正措施"] E --> E2["预防措施"] E --> E3["持续改进"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#e8f5e9,stroke:#388e3d style D fill:#fff3e0,stroke:#f57c00 style E fill:#f3e5f5,stroke:#7b1fa2
2.2 ISMS各阶段的工作内容
PDCA各阶段详细活动：
| 阶段 | 名称 | 主要活动 | 关键输出 |
|---|---|---|---|
| Plan | 建立ISMS | 制定ISMS方针、风险评估、选择控制措施 | ISMS方针、风险评估报告 |
| Do | 实施和运行ISMS | 实施控制措施、培训和意识教育、运行管理 | 控制措施实施记录 |
| Check | 监视和评审ISMS | 监控和测量、内部审核、有效性测量、管理评审 | 审核报告、评审报告 |
| Act | 保持和改进ISMS | 纠正措施、预防措施、持续改进 | 改进计划 |
⚠️ 注意区分
内部审核属于Check阶段，不是Act阶段：
- ✅ "实施内部审核"是监视和评审ISMS阶段（Check）的工作内容
- ❌ 不是保持和改进ISMS阶段（Act）的工作内容
- Act阶段主要是根据Check阶段发现的问题采取纠正和预防措施
2.3 ISO 27001控制措施范围
💡 ISO 27001常规控制措施
若一个组织声称自己的ISMS符合ISO/IEC 27001或GB/T 22080标准要求，其信息安全控制措施通常在以下方面实施常规措施：
包括的控制领域：
- ✅ 信息安全方针
- ✅ 信息安全组织
- ✅ 资产管理
- ✅ 人力资源安全
- ✅ 物理和环境安全
- ✅ 通信和操作管理（通信安全）
- ✅ 访问控制
- ✅ 信息系统获取、开发与维护
- ✅ 安全事件管理
- ✅ 业务连续性管理
- ✅ 符合性（合规性）
- ✅ 供应商关系
不属于控制措施范围：
- ❌ 规划与建立ISMS（这是PDCA的Plan阶段，不是控制措施）
- ❌ 业务安全性审计（不是标准控制领域）
💡 详细的ISO标准体系和标准化组织信息，请参考《CISP学习指南：系统工程、密码算法与标准》
2.4 ISO 27001资产管理控制措施
若组织声称其ISMS符合ISO/IEC 27001或GB/T 22080标准要求，需要在资产管理方面实施常规控制。
graph TB
A["资产管理"]
B["对资产负责"]
C["信息分类"]
A --> B
A --> C
B --> B1["资产清单"]
B --> B2["资产责任人"]
B --> B3["资产可接受使用"]
C --> C1["分类指南"]
C --> C2["信息标记"]
C --> C3["信息处理"]
style B fill:#e3f2fd,stroke:#1976d2
style C fill:#e8f5e9,stroke:#388e3d
资产管理的两个控制目标：
| 控制目标 | 目的 | 控制措施 |
|---|---|---|
| 对资产负责 | 识别组织资产并明确保护责任 | 资产清单、资产责任人、资产的可接受使用 |
| 信息分类 | 确保信息受到适当级别的保护 | 分类指南、信息的标记和处理 |
2.5 ISMS管理层职责
在组织中，信息安全方针的制定和颁布有明确的职责划分。
💡 方针制定职责
正确做法：
- ✅ 由组织的管理层制定并颁布
- ✅ 为组织的ISMS建设指明方向
- ✅ 提供总体纲领，明确总体要求
错误做法：
- ❌ 由信息技术责任部门（如信息中心）制定并颁布
管理层在ISMS中的关键职责：
| 职责 | 说明 | 重要性 |
|---|---|---|
| 制定方针 | 制定并颁布信息安全方针 | 战略层面 |
| 确保目标 | 确保ISMS目标和计划得以制定 | 明确、可度量 |
| 传达要求 | 将安全目标、方针传达全组织 | 全员覆盖 |
| 风险管理 | 了解风险，决定可接受级别 | 风险决策 |
三、等级保护政策发展历程
3.1 等级保护发展时间线
我国等级保护政策的发展经历了以下阶段：
timeline
title 等级保护政策发展历程
1994 : 思想提出 : 计算机系统安全保护等级划分思想提出
1999-2003 : 试点阶段 : 等级保护工作试点
2003-2007 : 政策颁布 : 等级保护相关政策文件颁布
2007-2008 : 标准发布 : 等级保护相关标准发布
2017 : 法律确立 : 网络安全法将等级保护制度作为基本策略
3.2 等级保护发展的正确顺序
💡 等级保护发展五个阶段
正确顺序：②⑤①③④
-
② 计算机系统安全保护等级划分思想提出（1994年）
- 《计算机信息系统安全保护等级划分准则》（GB 17859-1999）的前身
-
⑤ 等级保护工作试点（1999-2003年）
- 在部分地区和行业开展试点工作
-
① 等级保护相关政策文件颁布（2003-2007年）
- 中办发[2003]27号文件
- 《信息安全等级保护管理办法》（2007年）
-
③ 等级保护相关标准发布（2007-2008年）
- 等级保护系列标准陆续发布
-
④ 网络安全法将等级保护制度作为基本策略（2017年）
- 《中华人民共和国网络安全法》正式实施
发展历程关键节点：
| 时间 | 阶段 | 关键事件 | 意义 |
|---|---|---|---|
| 1994年 | 思想提出 | 等级划分思想提出 | 理论基础 |
| 1999-2003年 | 试点 | 开展试点工作 | 实践探索 |
| 2003年 | 政策颁布 | 中办发[2003]27号 | 政策确立 |
| 2007-2008年 | 标准发布 | 系列标准发布 | 标准体系 |
| 2017年 | 法律确立 | 网络安全法实施 | 法律保障 |
四、P2DR模型
4.1 PDR模型与P2DR模型对比
PDR模型：
- Protection（防护）
- Detection（检测）
- Response（响应）
P2DR模型：
- Policy（策略）
- Protection（防护）
- Detection（检测）
- Response（响应）
graph TB
A["P2DR模型"]
B["Policy
策略"] C["Protection
防护"] D["Detection
检测"] E["Response
响应"] A --> B B --> C B --> D B --> E C --> D D --> E E --> C B --> B1["安全策略"] B --> B2["指导方针"] C --> C1["防护措施"] D --> D1["漏洞监测"] E --> E1["响应处置"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#e8f5e9,stroke:#388e3d style D fill:#fff3e0,stroke:#f57c00 style E fill:#f3e5f5,stroke:#7b1fa2
策略"] C["Protection
防护"] D["Detection
检测"] E["Response
响应"] A --> B B --> C B --> D B --> E C --> D D --> E E --> C B --> B1["安全策略"] B --> B2["指导方针"] C --> C1["防护措施"] D --> D1["漏洞监测"] E --> E1["响应处置"] style B fill:#e3f2fd,stroke:#1976d2 style C fill:#e8f5e9,stroke:#388e3d style D fill:#fff3e0,stroke:#f57c00 style E fill:#f3e5f5,stroke:#7b1fa2
4.2 P2DR模型的核心特点
💡 P2DR模型的四个强调
与PDR模型相比，P2DR模型更强调：
-
控制和对抗
- 主动的安全控制
- 与威胁的对抗能力
-
动态性
- 强调系统安全的动态性
- 持续的安全保障过程
-
漏洞监测
- 以安全检测为核心
- 及时发现安全漏洞
-
网络安全
- 提高网络安全整体水平
- 自适应填充"安全间隙"
P2DR模型的循环机制：
P2DR循环：
策略（Policy）
↓
防护（Protection）
↓
检测（Detection）← 漏洞监测
↓
响应（Response）← 控制和对抗
↓
改进防护 ← 动态性
↓
（循环继续）⚠️ 完整答案记忆
与PDR模型相比，P2DR模型则更强调控制和对抗，即强调系统安全的动态性，并且以安全检测、漏洞监测和自适应填充"安全间隙"为循环来提高网络安全。
五、信息安全需求来源
5.1 信息安全需求的来源
📋 信息安全需求来源
信息安全需求主要来自以下三个方面：
✅ 法律法规与合同条约的要求
- 国家法律法规
- 行业监管要求
- 合同约定
- 国际条约
✅ 组织的原则、目标和规定
- 组织战略目标
- 业务需求
- 管理方针
- 内部规章制度
✅ 风险评估的结果
- 资产识别
- 威胁分析
- 脆弱性评估
- 风险处置需求
5.2 威胁情报与需求来源的区别
⚠️ 注意区分
安全架构和安全厂商发布的漏洞、病毒预警不是信息安全需求的直接来源。
威胁情报的性质：
- 这些是安全威胁情报
- 属于风险评估的输入信息
- 不是需求的直接来源
- 需要通过风险评估转化为需求
信息安全需求来源对比：
| 选项 | 是否为需求来源 | 说明 |
|---|---|---|
| 法律法规与合同条约 | ✅ 是 | 外部强制性要求 |
| 组织原则、目标和规定 | ✅ 是 | 内部管理要求 |
| 风险评估结果 | ✅ 是 | 基于风险的需求 |
| 漏洞病毒预警 | ❌ 否 | 威胁情报，非直接需求来源 |
六、风险评估阶段
6.1 风险评估的主要工作
🔍 风险评估阶段的工作内容
风险评估阶段应该做的工作包括：
✅ 对ISMS范围内的信息资产进行鉴定和估价
- 识别信息资产
- 确定资产价值
- 明确资产责任人
✅ 对信息资产面对的各种威胁和脆弱性进行评估
- 威胁识别
- 脆弱性分析
- 威胁与脆弱性匹配
✅ 对已存在的或规划的安全控制措施进行界定
- 现有控制措施评估
- 控制措施有效性分析
- 残余风险识别
6.2 不属于风险评估阶段的工作
❌ 风险评估阶段不做的事
根据评估结果实施相应的安全控制措施不是风险评估阶段应该做的。
原因：
- 这属于风险处置阶段的工作
- 风险评估只是识别和分析风险
- 实施控制措施是后续阶段的任务
风险管理流程：
graph TB
A["风险管理流程"]
B["风险评估"]
C["风险处置"]
D["风险监控"]
A --> B
B --> C
C --> D
D --> B
B --> B1["资产识别和估价"]
B --> B2["威胁和脆弱性评估"]
B --> B3["现有控制措施界定"]
B --> B4["风险分析和评价"]
C --> C1["选择控制措施"]
C --> C2["实施控制措施"]
C --> C3["接受残余风险"]
D --> D1["监控风险变化"]
D --> D2["评估控制有效性"]
style B fill:#e3f2fd,stroke:#1976d2
style C fill:#e8f5e9,stroke:#388e3d
style D fill:#fff3e0,stroke:#f57c00
七、信息安全策略变更
7.1 信息安全策略变更的原因
🔄 策略变更的触发因素
信息安全策略需要变更的原因包括：
✅ 每年至少一次管理评审
- 定期评审安全策略
- 确保策略适应性
- 持续改进
✅ 业务发生重大变更
- 新业务上线
- 业务流程调整
- 组织架构变化
✅ 管理机构发生变更
- 高层管理变动
- 组织重组
- 职责调整
7.2 不是策略变更原因的选项
❌ 设备变更不是策略变更原因
设备发生变更不是信息安全策略变更的原因。
原因：
- 设备变更属于技术层面
- 不影响安全策略的制定
- 策略是战略层面的指导方针
- 设备变更只需调整技术措施
策略变更原因对比：
| 变更原因 | 是否触发策略变更 | 层次 | 说明 |
|---|---|---|---|
| 管理评审 | ✅ 是 | 管理层 | 定期评审机制 |
| 业务变更 | ✅ 是 | 业务层 | 业务需求驱动 |
| 机构变更 | ✅ 是 | 组织层 | 组织架构调整 |
| 设备变更 | ❌ 否 | 技术层 | 技术实施层面 |
八、ISMS变更通知
8.1 ISMS变更通知所属阶段
📢 ISMS变更通知
**"通知相关人员ISMS的变更"是建立信息安全管理体系保持和改进（Act）**阶段的活动。
PDCA各阶段活动对比：
| 阶段 | 名称 | 主要活动 | 是否包括变更通知 |
|---|---|---|---|
| Plan | 规划和建立 | 制定方针、风险评估、选择控制 | ❌ 否 |
| Do | 实施和运行 | 实施控制、培训、运行管理 | ❌ 否 |
| Check | 监视和评审 | 监控、审核、评审 | ❌ 否 |
| Act | 保持和改进 | 纠正、预防、改进、变更通知 | ✅ 是 |
Act阶段的关键活动：
Act阶段（保持和改进）：
├── 纠正措施
│ ├── 识别不符合项
│ ├── 分析原因
│ └── 实施纠正
├── 预防措施
│ ├── 识别潜在问题
│ ├── 预防性改进
│ └── 风险控制
├── 持续改进
│ ├── 优化流程
│ ├── 提升效率
│ └── 增强有效性
└── 变更管理
├── 通知相关人员ISMS变更 ✅
├── 更新文档
└── 培训和沟通九、信息安全策略文档
9.1 高层目标信息安全策略的位置
📄 信息安全管理手册
在信息安全管理体系中，带有高层目标的信息安全策略是被描述在信息安全管理手册中。
ISMS文档体系：
graph TB
A["ISMS文档体系"]
B["信息安全管理手册"]
C["信息安全管理制度"]
D["信息安全指南和手册"]
E["信息安全记录文档"]
A --> B
A --> C
A --> D
A --> E
B --> B1["高层目标"]
B --> B2["安全策略"]
B --> B3["组织架构"]
B --> B4["职责分工"]
C --> C1["具体制度"]
C --> C2["管理规定"]
C --> C3["操作规程"]
D --> D1["操作指南"]
D --> D2["技术手册"]
D --> D3["用户手册"]
E --> E1["审计记录"]
E --> E2["事件记录"]
E --> E3["变更记录"]
style B fill:#e3f2fd,stroke:#1976d2
ISMS文档层次对比：
| 文档类型 | 层次 | 内容 | 是否包含高层目标策略 |
|---|---|---|---|
| 信息安全管理手册 | 战略层 | 高层目标、安全策略、组织架构 | ✅ 是 |
| 信息安全管理制度 | 管理层 | 具体制度、管理规定 | ❌ 否 |
| 信息安全指南和手册 | 操作层 | 操作指南、技术手册 | ❌ 否 |
| 信息安全记录文档 | 记录层 | 审计记录、事件记录 | ❌ 否 |
十、应急响应计划
10.1 应急响应计划制定过程
🚨 应急响应计划的制定
信息安全应急响应计划的制定是一个周而复始的、持续改进的过程。
包括的阶段：
- ✅ 应急响应需求分析和应急响应策略的制定
- ✅ 编制应急响应计划文档
- ✅ 应急响应计划的测试、培训、演练和维护
10.2 不在应急响应计划制定过程中的阶段
❌ 应急响应计划的废弃与存档
应急响应计划的废弃与存档不在应急响应计划制定过程中。
原因：
- 应急响应计划是持续改进的过程
- 不存在"废弃"的概念
- 只有更新和维护
- 存档是文档管理的一般性工作
应急响应计划生命周期：
graph TB
A["应急响应计划生命周期"]
B["需求分析"]
C["策略制定"]
D["计划编制"]
E["测试演练"]
F["培训教育"]
G["维护更新"]
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
G --> B
B --> B1["识别关键业务"]
B --> B2["分析威胁场景"]
C --> C1["确定响应策略"]
C --> C2["定义响应流程"]
D --> D1["编写计划文档"]
D --> D2["明确角色职责"]
E --> E1["桌面演练"]
E --> E2["实战演练"]
F --> F1["人员培训"]
F --> F2["意识教育"]
G --> G1["定期评审"]
G --> G2["持续改进"]
style B fill:#e3f2fd,stroke:#1976d2
style C fill:#e8f5e9,stroke:#388e3d
style D fill:#fff3e0,stroke:#f57c00
style E fill:#f3e5f5,stroke:#7b1fa2
十一、信息安全事件分级
11.1 我国信息安全事件分级要素
📊 信息安全事件分级
我国信息安全事件分级的分级要素包括：
✅ 信息系统的重要程度
- 关键信息基础设施
- 重要信息系统
- 一般信息系统
✅ 系统损失
- 经济损失
- 业务中断时间
- 数据损失程度
✅ 社会影响
- 公众影响范围
- 社会稳定影响
- 国家安全影响
11.2 不是分级要素的选项
❌ 系统保密级别不是分级要素
系统保密级别不是我国信息安全事件分级的分级要素。
原因：
- 保密级别是涉密系统的分类标准
- 信息安全事件分级针对所有系统
- 两者是不同的分类体系
- 保密级别属于保密管理范畴
信息安全事件分级标准：
| 级别 | 名称 | 系统重要程度 | 系统损失 | 社会影响 |
|---|---|---|---|---|
| 特别重大 | I级 | 关键信息基础设施 | 特别严重 | 全国性影响 |
| 重大 | II级 | 重要信息系统 | 严重 | 跨省影响 |
| 较大 | III级 | 重要信息系统 | 较重 | 跨市影响 |
| 一般 | IV级 | 一般信息系统 | 一般 | 局部影响 |
十二、符合性管理
12.1 符合性管理概述
✅ 符合性管理
符合性管理确保组织的信息安全实践符合相关法律法规和内部政策。
符合性包括：
- 法律法规的符合性
- 组织安全策略方针的符合性
- 行业标准的符合性
- 合同要求的符合性
12.2 符合性管理的错误描述
❌ 符合性管理错误理解
错误说法：仅在组织内部使用的信息系统不必考虑来自外部的法律法规的要求
为什么错误：
- 所有信息系统都必须遵守法律法规
- 内部使用不等于可以豁免法律要求
- 数据保护法、网络安全法等适用于所有系统
- 违法行为不因系统用途而免责
符合性管理的正确理解：
符合性管理要点：
├── 法律法规符合性
│ ├── 适用于所有系统（包括内部系统）
│ ├── 网络安全法
│ ├── 数据安全法
│ ├── 个人信息保护法
│ └── 行业监管要求
├── 组织策略符合性
│ ├── 内部安全策略
│ ├── 管理制度
│ └── 操作规程
├── 审核检查
│ ├── 尽量减少对系统的影响
│ ├── 选择合适的审核时间
│ ├── 使用非侵入式方法
│ └── 制定审核计划
└── 隐私保护
├── 用户个人隐私保护
├── 数据最小化原则
├── 知情同意
└── 数据安全措施十三、数据备份方案
13.1 数据备份方案的考虑因素
💾 数据备份方案设计
制定数据备份方案时，需要考虑的两个关键因素为：
✅ 适合的备份时间
- 业务低峰期
- 对业务影响最小
- 备份窗口时间
✅ 恢复数据的最大允许时间（RTO）
- Recovery Time Objective
- 业务可容忍的中断时间
- 决定备份策略和技术选择
13.2 数据备份的其他考虑因素
完整的备份方案考虑因素：
| 因素 | 说明 | 重要性 |
|---|---|---|
| 备份时间 | 何时进行备份 | 高 |
| RTO | 恢复时间目标 | 高 |
| RPO | 恢复点目标（数据丢失容忍度） | 高 |
| 备份介质 | 磁盘、磁带、云存储 | 中 |
| 备份位置 | 本地、异地、云端 | 高 |
| 备份数据量 | 全量、增量、差异 | 中 |
| 备份频率 | 每日、每周、实时 | 高 |
| 保留策略 | 保留多长时间 | 中 |
备份策略类型：
graph TB
A["备份策略"]
B["全量备份"]
C["增量备份"]
D["差异备份"]
A --> B
A --> C
A --> D
B --> B1["备份所有数据"]
B --> B2["恢复速度快"]
B --> B3["占用空间大"]
C --> C1["只备份变化数据"]
C --> C2["占用空间小"]
C --> C3["恢复速度慢"]
D --> D1["备份自上次全量后的变化"]
D --> D2["折中方案"]
D --> D3["恢复速度中等"]
style B fill:#e3f2fd,stroke:#1976d2
style C fill:#e8f5e9,stroke:#388e3d
style D fill:#fff3e0,stroke:#f57c00
十四、SSE-CMM与系统工程
14.1 SSE-CMM作用对象
🏗️ SSE-CMM模型
**SSE-CMM（Systems Security Engineering Capability Maturity Model）**系统安全工程能力成熟度模型可以对以下组织产生作用：
✅ 获取组织（Acquisition Organization）
- 采购安全产品和服务的组织
- 评估供应商安全能力
✅ 工程组织（Engineering Organization）
- 开发和实施安全系统的组织
- 评估自身安全工程能力
✅ 认证组织（Certification Organization）
- 评估和认证安全能力的组织
- 提供第三方评估服务
14.2 SSE-CMM不作用的对象
❌ 采购组织不是SSE-CMM术语
采购组织不是SSE-CMM标准中使用的术语，正确的术语是获取组织（Acquisition Organization）。
SSE-CMM作用对象对比：
| 组织类型 | 是否为SSE-CMM术语 | 说明 |
|---|---|---|
| 获取组织 | ✅ 是 | Acquisition Organization |
| 工程组织 | ✅ 是 | Engineering Organization |
| 认证组织 | ✅ 是 | Certification Organization |
| 采购组织 | ❌ 否 | 非标准术语 |
14.3 系统工程霍尔三维结构模型
📐 霍尔三维结构模型
系统工程霍尔三维结构模型从时间维、逻辑维、知识维三个坐标对系统工程进行程序化。
霍尔三维结构模型：
霍尔三维结构模型：
├── 时间维（Time Dimension）
│ ├── 规划阶段
│ ├── 拟定方案阶段
│ ├── 研制阶段
│ ├── 生产阶段
│ ├── 安装阶段
│ ├── 运行阶段
│ └── 更新阶段
├── 逻辑维（Logic Dimension）
│ ├── 明确问题
│ ├── 确定目标
│ ├── 系统综合
│ ├── 系统分析
│ ├── 优化
│ ├── 决策
│ └── 实施
└── 知识维（Knowledge Dimension）
├── 工程技术
├── 医学生物
├── 社会科学
├── 经济管理
├── 法律法规
└── 其他专业知识三维模型示意：
graph TB
A["霍尔三维结构模型"]
B["时间维"]
C["逻辑维"]
D["知识维"]
A --> B
A --> C
A --> D
B --> B1["规划→研制→运行"]
C --> C1["问题→分析→决策"]
D --> D1["工程→管理→法律"]
style B fill:#e3f2fd,stroke:#1976d2
style C fill:#e8f5e9,stroke:#388e3d
style D fill:#fff3e0,stroke:#f57c00
十五、总结
🎯 关键要点
信息安全工程：
- 信息安全工程要在规划阶段合理规划，建设阶段同步实施
- 不能先实施系统后加固，更不能忽视安全建设
- 安全与功能并重，不可偏废
ISMS管理体系：
- ISMS遵循PDCA模型：Plan-Do-Check-Act
- 制定ISMS方针是Plan阶段工作
- 实施培训和意识教育是Do阶段工作
- 进行有效性测量和内部审核是Check阶段工作
- ISO 27001资产管理包括对资产负责和信息分类
- 信息安全方针由管理层制定并颁布，不是IT部门
等级保护发展：
- 等级保护发展顺序：思想提出→试点→政策→标准→法律
- 1994年思想提出，2017年法律确立
- 经历了理论、实践、政策、标准、法律五个阶段
P2DR模型：
- P2DR模型强调控制和对抗、动态性、漏洞监测、网络安全
- P2DR通过检测-监测-响应循环填充安全间隙
- 比PDR模型增加了Policy（策略）要素
🔗 相关内容
更多相关知识点：
- 等级保护定级要素和工作流程 → 标准规范与管理实践
- 系统工程方法论和标准体系 → 系统工程、密码算法与标准
💡 实践建议
- 在信息化建设初期就规划安全
- 建立完善的ISMS管理体系
- 遵循PDCA持续改进
- 实施P2DR动态防御策略
- 定期评估和优化安全措施