风险处置和监控是风险管理的关键环节，通过选择合适的策略降低风险并持续监控。
四、风险处置
4.1 风险处置策略
四种风险处置策略：
策略选择指南：
| 策略 | 适用场景 | 示例 | 优点 | 缺点 |
|---|---|---|---|---|
| 规避 | 风险过高且可避免 | 停止使用有风险的系统、放弃高风险功能模块 | 彻底消除风险 | 可能影响业务 |
| 缓解/降低 | 风险可接受但需控制 | 部署安全控制措施 | 平衡风险和成本 | 无法完全消除 |
| 转移 | 可通过第三方承担 | 购买保险、外包 | 降低自身损失 | 需要额外成本 |
| 接受 | 风险很低或成本过高 | 接受低风险 | 节省成本 | 保留风险 |
4.2 风险处置策略详解
4.2.1 风险规避（Risk Avoidance）
🚫 风险规避策略
定义： 通过停止或避免导致风险的活动来消除风险。
适用场景：
- 风险太高，无法接受
- 风险处置成本过高
- 存在可行的替代方案
- 业务功能可以放弃
典型措施：
- 🛑 停止使用存在高风险的系统
- ❌ 放弃高风险的业务功能模块
- 🔄 选择更安全的替代方案
- 📋 不开展高风险业务活动
案例：放弃高风险功能模块
💼 实际案例
场景： 某公司的信息系统中部分涉及金融交易的功能模块风险太高。
风险评估结果：
- 资产价值：高
- 威胁可能性：高
- 脆弱性严重程度：高
- 综合风险等级：极高
处置建议： 采用风险规避策略，放弃这个功能模块。
理由：
- 风险太高，难以接受
- 加固成本可能超过收益
- 存在其他替代方案
- 避免潜在的重大损失
4.2.2 风险降低/缓解（Risk Mitigation）
📉 风险降低策略
定义： 通过采取安全措施降低风险发生的可能性或减少风险的影响。
适用场景：
- 风险可以通过控制措施降低
- 完全规避风险会影响业务
- 处置成本合理
- 残余风险可接受
典型措施：
- 🛡️ 部署防火墙、IDS/IPS
- 🔐 实施访问控制
- 🔄 建立备份和恢复机制
- 📋 制定安全策略和流程
- 👥 开展安全培训
风险降低的实施步骤：
风险降低实施流程：
├── 1. 识别风险
│ └── 确定需要降低的风险
├── 2. 分析风险
│ ├── 评估当前风险水平
│ └── 确定可接受的风险水平
├── 3. 选择控制措施
│ ├── 技术控制
│ ├── 管理控制
│ └── 物理控制
├── 4. 实施控制措施
│ ├── 制定实施计划
│ ├── 分配资源
│ └── 执行实施
└── 5. 评估效果
├── 测量残余风险
└── 验证是否达到目标4.2.3 风险转移（Risk Transfer）
🔄 风险转移策略
定义： 将风险转移给第三方承担，通常通过合同或保险方式实现。
适用场景：
- 存在可以承担风险的第三方
- 转移成本低于自行承担
- 第三方更有能力处理风险
- 需要分散风险
典型措施：
- 💰 购买网络安全保险
- 🤝 外包给专业安全服务商
- 📋 签订责任转移合同
- ☁️ 使用云服务（部分风险转移）
风险转移的注意事项：
⚠️ 风险转移的局限性
不能完全转移的风险：
- 声誉损失
- 客户信任损失
- 法律责任（某些情况）
- 业务中断影响
需要注意：
- 📋 仔细审查合同条款
- 💰 评估转移成本
- 🔍 验证第三方能力
- 📊 保留必要的监督权
4.2.4 风险接受（Risk Acceptance）
✅ 风险接受策略
定义： 在充分了解风险的情况下，决定接受风险及其后果。
适用场景：
- 风险很低，可以接受
- 处置成本远高于风险损失
- 没有可行的处置方案
- 残余风险在可接受范围内
要求：
- 📋 必须经过正式评估
- 👔 需要管理层批准
- 📝 形成书面记录
- 🔄 定期重新评估
4.3 风险处置策略对比
四种策略的对比分析：
| 策略 | 风险消除程度 | 成本 | 业务影响 | 适用风险等级 | 决策难度 |
|---|---|---|---|---|---|
| 规避 | 完全消除 | 可能很高 | 可能很大 | 极高风险 | 高 |
| 降低 | 部分降低 | 中等 | 较小 | 高/中风险 | 中 |
| 转移 | 转移损失 | 中等 | 较小 | 中风险 | 中 |
| 接受 | 不消除 | 最低 | 无 | 低风险 | 低 |
4.4 风险处置计划
风险处置计划内容：
风险处置计划：
├── 风险描述
│ ├── 风险识别号
│ ├── 风险描述
│ └── 风险等级
├── 处置策略
│ ├── 选择的策略
│ ├── 策略依据
│ └── 预期效果
├── 实施措施
│ ├── 具体措施
│ ├── 责任人
│ ├── 时间计划
│ └── 资源需求
└── 监控机制
├── 监控指标
├── 监控频率
└── 报告机制六、残余风险
6.1 残余风险概述
残余风险是风险管理中的一个重要概念，指采取了安全措施后仍然存在的风险。
💡 残余风险的正确理解
残余风险的定义和特点：
📊 什么是残余风险
- 采取了安全措施后，仍然可能存在的风险
- 在综合考虑了安全成本与效益后不去控制的风险
- 基于成本效益分析决定接受
🔍 残余风险的管理要求
- 应受到密切监控
- 会随着时间的推移而发生变化
- 可能会在将来诱发新的安全事件
📝 残余风险的报告和批准
- 应将残余风险清单告知组织的高管
- 使其了解残余风险的存在和可能造成的后果
- 需要管理层正式批准
⚠️ 常见误区：追求最小残余风险
- 不应以最小残余风险值作为目标
- 应该在成本效益平衡的基础上降低风险
- 追求最小残余风险可能导致成本过高
- 应该追求可接受的残余风险水平
残余风险的正确理解：
残余风险管理原则：
残余风险管理：
├── 1. 识别残余风险
│ ├── 评估风险处置效果
│ ├── 确定剩余风险
│ └── 形成残余风险清单
├── 2. 评估残余风险
│ ├── 评估风险水平
│ ├── 判断是否可接受
│ └── 考虑成本效益
├── 3. 报告残余风险
│ ├── 向管理层报告
│ ├── 说明风险性质
│ └── 说明可能后果
├── 4. 批准残余风险
│ ├── 管理层审批
│ ├── 正式接受
│ └── 承担责任
└── 5. 监控残余风险
├── 持续监控
├── 定期评估
└── 及时调整残余风险的特点：
| 特点 | 说明 | 管理要求 |
|---|---|---|
| 不可完全消除 | 总会存在一定风险 | 接受现实 |
| 动态变化 | 随时间和环境变化 | 持续监控 |
| 需要批准 | 必须获得管理层批准 | 正式接受 |
| 成本效益 | 基于成本效益分析 | 平衡投入 |
| 可能演变 | 可能诱发新事件 | 及时应对 |
为什么不追求最小残余风险：
⚠️ 常见误区
错误观念：追求最小残余风险值
❌ 问题：
- 成本可能无限增长
- 投入产出比不合理
- 可能影响业务运营
- 不符合实际需求
✅ 正确做法：
- 追求可接受的残余风险水平
- 基于成本效益分析
- 平衡安全与业务需求
- 符合组织风险承受能力
成本效益分析示例：
📊 图表说明
这是帮助理解的示例数据，非真实数据
从图表可以看出：
- 方案1-2：成本效益比较好
- 方案3：成本开始快速上升
- 方案4：成本远超风险降低效果
- 最优选择：方案2或方案3
- 不应追求方案4（最小残余风险）
残余风险决策流程：
残余风险决策：
├── 1. 评估残余风险
│ ├── 风险水平：中等
│ ├── 进一步降低成本：100万元
│ └── 预期风险降低：10万元/年
├── 2. 成本效益分析
│ ├── 投资回收期：10年
│ ├── 成本效益比：1:0.1
│ └── 结论：不划算
├── 3. 决策
│ ├── 不再进一步降低
│ ├── 接受当前残余风险
│ └── 实施监控措施
└── 4. 批准和监控
├── 向管理层报告
├── 获得正式批准
└── 建立监控机制五、定量风险评估在风险处置中的应用
定量风险评估的详细方法和计算公式请参考：风险评估方法
定量评估在风险处置中的应用：
💡 ALE在风险处置决策中的作用
使用ALE进行处置决策：
📊 计算风险大小
- 使用ALE量化风险损失
- 为不同风险排序
- 确定处置优先级
💰 成本效益分析
- 比较安全投入与ALE降低
- 计算投资回报率
- 选择最优处置方案
🎯 处置效果评估
- 对比处置前后ALE
- 验证处置措施有效性
- 调整处置策略
六、风险监控
8.1 风险监控的目的
风险监控的关键活动：
- 📊 监控风险状态变化
- 🔍 评估处置措施有效性
- 🆕 识别新的风险
- 🔄 更新风险评估
- 📋 报告风险状况
8.2 持续改进
风险管理的持续改进循环：
Plan"] --> B["执行
Do"] B --> C["检查
Check"] C --> D["改进
Act"] D --> A style A fill:#e3f2fd,stroke:#1976d2 style B fill:#e8f5e9,stroke:#388e3d style C fill:#fff3e0,stroke:#f57c00 style D fill:#f3e5f5,stroke:#7b1fa2
七、安全管理问题
9.1 组织安全问题的主要原因
在许多组织机构中，产生总体安全性问题的根源需要被正确识别。
💡 安全问题的根源：缺少安全性管理
主要原因：缺少安全性管理
在许多组织机构中，产生总体安全性问题的主要原因是缺少安全性管理。
为什么是管理问题：
📋 管理是基础
- 技术措施需要管理来统筹
- 缺少管理导致技术措施零散
- 管理不善使技术措施失效
- 管理是系统性问题的根源
选项分析：
A. ✅ 正确：缺少安全性管理
- 这是总体安全问题的主要原因
- 管理缺失导致系统性问题
- 影响所有安全层面
B. ❌ 不是主要原因：缺少故障管理
- 故障管理只是安全管理的一部分
- 不是总体安全问题的根源
- 属于运维管理范畴
C. ❌ 不是主要原因：缺少风险分析
- 风险分析是安全管理的一部分
- 不是总体问题的根源
- 属于安全管理的具体工作
D. ❌ 不是主要原因：缺少技术控制机制
- 技术控制是实施层面
- 即使有技术，缺少管理也会失效
- 不是系统性问题的根源
安全管理的重要性：
缺少安全管理的典型表现：
| 表现 | 后果 | 影响 |
|---|---|---|
| 无安全策略 | 缺少指导方向 | 安全工作零散、无效 |
| 无组织保障 | 职责不清 | 安全工作无人负责 |
| 无管理流程 | 操作不规范 | 安全措施难以落实 |
| 无考核机制 | 缺少激励约束 | 安全要求难以执行 |
| 无审计监督 | 问题发现不及时 | 安全风险积累 |
安全管理与技术控制的关系：
安全体系结构：
├── 安全管理（基础层）
│ ├── 安全策略
│ ├── 组织架构
│ ├── 管理流程
│ ├── 制度规范
│ └── 考核机制
├── 技术控制（实施层）
│ ├── 访问控制
│ ├── 加密保护
│ ├── 安全监控
│ └── 安全审计
└── 人员管理（支撑层）
├── 安全意识
├── 技能培训
└── 责任落实
管理缺失 → 技术措施失效 → 安全问题产生9.2 程序变动的控制
当对于程序变动的手工控制收效甚微时，需要采取更有效的控制方法。
💡 程序变动控制的最佳实践
最有效的方法：自动软件管理
当手工控制收效甚微时，自动软件管理是最有效的方法。
为什么选择自动软件管理：
🤖 自动化优势
- 减少人为错误
- 提高执行一致性
- 强制执行流程
- 自动记录审计轨迹
📊 效率提升
- 快速响应变更
- 降低管理成本
- 减少人工干预
- 提高变更速度
选项分析：
A. ✅ 正确：自动软件管理
- 最有效的解决方案
- 解决手工控制的问题
- 提供系统化管理
B. ❌ 不够有效：书面化制度
- 仍然依赖人工执行
- 无法解决手工控制的根本问题
- 执行一致性难以保证
C. ❌ 不够有效：书面化方案
- 与书面化制度类似
- 仍然是手工控制
- 无法从根本上解决问题
D. ❌ 不够有效：书面化标准
- 仍然依赖人工遵守
- 缺少强制执行机制
- 效果有限
自动软件管理系统的功能：
自动软件管理的优势：
| 特性 | 手工控制 | 自动管理 |
|---|---|---|
| 一致性 | 低 | 高 |
| 准确性 | 低 | 高 |
| 效率 | 低 | 高 |
| 审计轨迹 | 不完整 | 完整 |
| 强制执行 | 弱 | 强 |
| 人为错误 | 高 | 低 |
| 可追溯性 | 差 | 好 |
| 成本 | 低（短期） | 高（短期）、低（长期） |
自动软件管理的实现：
自动软件管理工具链：
├── 版本控制系统
│ ├── Git
│ ├── SVN
│ └── Mercurial
├── 持续集成工具
│ ├── Jenkins
│ ├── GitLab CI
│ ├── GitHub Actions
│ └── Azure DevOps
├── 代码审查工具
│ ├── Gerrit
│ ├── Review Board
│ └── Crucible
├── 自动测试工具
│ ├── JUnit
│ ├── Selenium
│ └── pytest
└── 部署管理工具
├── Ansible
├── Kubernetes
└── Docker自动化的安全价值：
💡 自动化的安全价值
安全控制的一致性：
- 每次变更都经过相同的安全检查
- 不会因人为疑忽而遗漏安全步骤
- 强制执行安全策略
完整的审计轨迹：
- 所有变更都有记录
- 可以追溯问题来源
- 支持安全事件调查
快速响应安全问题：
- 快速修复漏洞
- 快速回滚有问题的变更
- 减少安全窗口期
八、风险模型与ISMS
10.1 信息安全风险模型
信息安全风险模型阐述了资产所有者、资产、脆弱性、威胁、安全措施之间的关系。
💡 风险模型的关键要素
风险模型中的关键关系：
正确理解：
- 资产价值由所有者确定，不是使用者
- 提高脆弱性会提高安全风险
- 降低安全威胁会降低安全风险
- 提高安全措施会降低安全风险
错误说法分析：
A. ❌ 错误：资产价值由使用者确定
- 资产价值应由所有者确定
- 所有者对资产有最终决定权
- 使用者只是使用资产，不决定其价值
- 所有者承担资产损失的后果
B. ✅ 正确：提高脆弱性会提高安全风险
- 脆弱性越高，风险越大
- 符合风险计算公式
C. ✅ 正确：降低安全威胁会降低安全风险
- 威胁降低，风险降低
- 符合风险管理原理
D. ✅ 正确：提高安全措施会降低安全风险
- 安全措施增强，风险降低
- 这是风险处置的目标
信息安全风险模型：
风险要素关系：
| 要素 | 决定者/拥有者 | 对风险的影响 | 控制方式 |
|---|---|---|---|
| 资产 | 所有者 | 价值越高，风险越大 | 资产分类、价值评估 |
| 威胁 | 外部/内部 | 威胁越大，风险越大 | 威胁情报、监控预警 |
| 脆弱性 | 资产固有 | 脆弱性越高，风险越大 | 漏洞修复、加固 |
| 安全措施 | 组织实施 | 措施越强，风险越小 | 技术控制、管理控制 |
10.2 风险处置时机
风险处置措施的采用需要考虑成本效益，在合适的时机采取行动。
💡 风险处置的时机选择
何时采用风险处置措施：
通常在安全投入小于负面影响损失的情况下采用风险处置措施。
决策原则：
📊 成本效益分析
- 比较安全投入与潜在损失
- 计算投资回报率
- 考虑长期效益
选项分析：
A. ❌ 不合理：负面影响损失小于安全投入
- 投入大于收益
- 不符合成本效益原则
- 不应采用处置措施
B. ❌ 临界点：负面影响损失和安全投入持平
- 投入等于收益
- 处于决策临界点
- 需要考虑其他因素
C. ❌ 不明确：负面影响损失和安全投入都很小
- 情况不明确
- 需要具体分析
- 不是决策依据
D. ✅ 正确：安全投入小于负面影响损失
- 投入小于收益
- 符合成本效益原则
- 应该采用处置措施
风险处置决策矩阵：
| 安全投入 vs 潜在损失 | 决策 | 理由 |
|---|---|---|
| 投入 > 损失 | 不处置或接受风险 | 不划算 |
| 投入 = 损失 | 谨慎决策 | 临界点 |
| 投入 < 损失 | 采用处置措施 ✅ | 划算 |
| 投入 << 损失 | 优先处置 | 非常划算 |
成本效益分析示例：
风险处置决策案例：
场景1：
- 潜在损失：100万元/年
- 安全投入：30万元/年
- 决策：✅ 采用处置措施（投入 < 损失）
- ROI：(100-30)/30 = 233%
场景2：
- 潜在损失：10万元/年
- 安全投入：50万元/年
- 决策：❌ 不采用处置措施（投入 > 损失）
- 考虑：接受风险或寻找更经济的方案
场景3：
- 潜在损失：50万元/年
- 安全投入：50万元/年
- 决策：⚠️ 谨慎决策（投入 = 损失）
- 考虑：其他因素（合规要求、声誉影响等）10.3 ISMS基础
信息安全管理体系（ISMS）是基于业务风险的方法来建立、实施、运作、监视、评审、保持和改进信息安全。
💡 ISMS的核心理念
ISMS是基于业务风险的方法
信息安全管理体系不是基于信息安全本身，而是基于业务风险的方法。
为什么是业务风险：
🎯 业务导向
- 信息安全服务于业务目标
- 保护业务连续性
- 支持业务发展
📊 风险驱动
- 识别业务风险
- 评估风险影响
- 优先处理高风险
💰 成本效益
- 平衡安全投入与业务价值
- 避免过度保护
- 确保投资回报
选项分析：
A. ❌ 不准确：基于信息安全
- 过于技术导向
- 忽视业务需求
- 可能导致过度保护
B. ✅ 正确：基于业务风险
- 以业务为中心
- 风险驱动决策
- 符合ISMS标准
C. ❌ 不准确：基于信息系统防护
- 过于狭隘
- 只关注技术层面
- 忽视管理和业务
D. ❌ 不准确：基于安全风险
- 应该是业务风险
- 安全风险是业务风险的一部分
ISMS的PDCA循环：
策划"] --> B["Do
实施"] B --> C["Check
检查"] C --> D["Act
改进"] D --> A A --> A1["风险评估
制定计划"] B --> B1["实施控制
运行体系"] C --> C1["监控评审
内部审核"] D --> D1["持续改进
管理评审"] style A fill:#e3f2fd,stroke:#1976d2 style B fill:#e8f5e9,stroke:#388e3d style C fill:#fff3e0,stroke:#f57c00 style D fill:#f3e5f5,stroke:#7b1fa2
10.4 等级保护测评周期
信息系统安全保护等级不同，测评周期也不同。
💡 等级保护测评周期
三级系统的测评周期：
信息系统安全保护等级为3级的系统，应当每年进行一次等级测评。
等级保护测评周期要求：
| 保护等级 | 测评周期 | 说明 | |---------|---------|------| | 一级 | 自主测评 | 可自行决定 | | 二级 | 每2年至少一次 | 建议每2年 | | 三级 | 每年至少一次 ✅ | 每年必须 | | 四级 | 每半年至少一次 | 每半年必须 |
选项分析：
A. ❌ 错误：0.5年（半年）
- 这是四级系统的要求
- 三级系统不需要这么频繁
B. ✅ 正确：1年
- 三级系统每年测评一次
- 符合等级保护要求
C. ❌ 错误：2年
- 这是二级系统的要求
- 三级系统要求更严格
D. ❌ 错误：3年
- 周期过长
- 不符合等级保护要求
等级保护体系：
等级保护制度：
├── 定级备案
│ ├── 确定保护等级
│ ├── 专家评审
│ └── 主管部门审批
├── 安全建设
│ ├── 安全设计
│ ├── 安全实施
│ └── 安全验收
├── 等级测评
│ ├── 一级：自主测评
│ ├── 二级：每2年
│ ├── 三级：每1年 ✅
│ └── 四级：每半年
└── 监督检查
├── 日常监督
├── 专项检查
└── 整改落实九、总结
信息安全风险管理的核心要点：
- 背景建立：风险管理的第一步，调查系统、分析环境
- 风险评估：识别资产、威胁、脆弱性并进行评估
- 风险处置：选择合适的策略降低风险
- 风险监控：持续监控和改进
🎯 关键要点
- 背景建立是风险管理的第一步
- 背景建立的依据包括政策法规、机构使命和系统特性
- 背景建立阶段调查系统、分析环境，形成描述报告和需求报告
- 资产、威胁、脆弱性的识别和赋值属于风险评估阶段
- 风险处置有四种策略：规避、缓解、转移、接受
- 风险管理是一个持续的过程
💡 实践建议
- 建立系统化的风险管理流程
- 定期进行风险评估
- 根据风险等级制定处置计划
- 持续监控风险状态
- 建立风险管理文档体系
- 培养全员风险意识