风险管理基础与背景建立是信息安全保障的核心工作，通过系统化的方法识别、评估和处置安全风险，确保信息资产的安全。
一、风险管理概述
1.1 计算机系统的主要弱点
从风险分析的观点来看，计算机系统存在多个潜在的弱点，其中最主要的弱点是系统输入输出。
💡 为什么系统输入输出是最主要弱点
系统输入输出的脆弱性：
🔓 输入环节的风险
- 数据来源不可控
- 容易受到恶意输入攻击
- 输入验证不足导致注入攻击
- 缓冲区溢出风险
📤 输出环节的风险
- 敏感信息泄露
- 输出未经适当过滤
- 错误信息暴露系统细节
- 数据完整性难以保证
为什么是最主要弱点：
🌐 与外部环境的交互接口
- 系统输入输出是与外部世界交互的必经之路
- 数据来源不可控，可能来自任何地方
- 无法完全预测输入的内容和格式
- 是攻击者最容易接触的部分
相比其他环节的特点：
- 内部处理：相对封闭，可控性强
- 通信网络：可通过加密、防火墙等技术防护
- 输入输出：直接暴露于外部，防护难度最大
系统输入输出的安全挑战：
输入输出安全防护措施：
| 环节 | 主要风险 | 防护措施 |
|---|---|---|
| 输入 | 恶意输入、注入攻击 | 输入验证、参数化查询、白名单过滤 |
| 处理 | 逻辑漏洞、权限绕过 | 安全编码、权限检查、异常处理 |
| 输出 | 信息泄露、XSS攻击 | 输出编码、敏感信息脱敏、错误处理 |
| 通信 | 窃听、篡改 | 加密传输、数字签名、安全协议 |
1.2 风险与保护的关系
风险的大小直接决定了保护措施的必要性和优先级。
💡 风险与保护的正确关系
基本原则：风险越大，越需要保护
这是风险管理的基本原则，风险水平决定了保护措施的投入和优先级。
核心要点：
🎯 优先保护高风险资产
- 风险等级决定保护优先级
- 高风险资产获得最多资源投入
- 合理配置安全资源
💰 资源分配原则
- 根据风险等级分配预算
- 避免资源浪费
- 确保成本效益最优
常见误区：
- ❌ 认为风险大就不需要保护（完全违背基本原则）
- ❌ 认为风险小反而需要更多保护（资源配置不合理）
- ❌ 只关注中等风险而忽视高风险（优先级错误）
风险等级与保护措施的关系：
风险驱动的保护策略：
| 风险等级 | 保护优先级 | 投入水平 | 典型措施 |
|---|---|---|---|
| 极高 | 最高 | 最大 | 多层防护、实时监控、专人负责 |
| 高 | 高 | 较大 | 强化控制、定期审计、应急预案 |
| 中 | 中 | 适中 | 基本控制、定期检查 |
| 低 | 低 | 较小 | 标准控制、例行检查 |
| 极低 | 最低 | 最小 | 基础控制、接受风险 |
1.3 信息安全策略体系中的强制性规则
在信息安全策略体系中，不同类型的文件具有不同的约束力。
💡 安全策略体系的层次
强制性规则：标准（Standard）
在信息安全策略体系中，**标准（Standard）**属于计算机或信息安全的强制性规则，必须严格遵守。
策略体系层次：
📋 安全策略（Security Policy）
- 高层次的指导原则
- 体现管理层意图
- 相对宏观和原则性
- 不是强制性的具体规则
📏 标准（Standard）
- ✅ 强制性规则
- 必须遵守的具体要求
- 可测量、可审计
- 违反会受到处罚
📖 方针（Guideline）
- 建议性指导
- 最佳实践参考
- 不具有强制性
- 可以根据情况调整
📝 流程（Procedure）
- 具体操作步骤
- 实施方法说明
- 可以有一定灵活性
- 不是强制性规则本身
策略体系对比：
Policy"] C["标准
Standard"] D["方针
Guideline"] E["流程
Procedure"] A --> B A --> C A --> D A --> E B --> B1["指导原则
非强制"] C --> C1["强制性规则
必须遵守"] D --> D1["建议性指导
非强制"] E --> E1["操作步骤
有灵活性"] style C fill:#ffcdd2,stroke:#c62828 style C1 fill:#ffcdd2,stroke:#c62828
策略体系文件特征对比：
| 文件类型 | 约束力 | 灵活性 | 详细程度 | 示例 |
|---|---|---|---|---|
| 安全策略 | 指导性 | 高 | 宏观 | 信息安全方针 |
| 标准 | 强制性 ✅ | 低 | 具体 | 密码强度标准、访问控制标准 |
| 方针 | 建议性 | 高 | 中等 | 安全配置指南 |
| 流程 | 操作性 | 中 | 详细 | 变更管理流程 |
标准的强制性体现：
标准的强制性特征：
├── 明确的要求
│ ├── 密码必须至少12位
│ ├── 必须包含大小写字母、数字和特殊字符
│ └── 密码必须每90天更换一次
├── 可测量性
│ ├── 可以通过技术手段验证
│ └── 可以通过审计检查
├── 强制执行
│ ├── 系统自动强制
│ └── 违反会受到处罚
└── 适用范围
├── 明确适用对象
└── 无例外情况1.4 信息安全风险评估工作意见
📜 《关于开展信息安全风险评估工作的意见》
文件背景：
该意见是指导我国信息安全风险评估工作的重要文件，明确了风险评估的原则、形式和要求。
核心原则：
📊 严密组织
- 建立健全的组织体系
- 明确职责分工
- 加强统筹协调
📋 规范操作
- 遵循标准规范
- 按照流程执行
- 保证评估质量
🔬 讲求科学
- 采用科学方法
- 基于客观事实
- 综合分析判断
🎯 注重实效
- 着眼解决实际问题 -提出可行建议
- 促进安全改进
风险评估形式：
根据《关于开展信息安全风险评估工作的意见》，信息安全风险评估分为自评估和检查评估两种形式。
💡 风险评估的两种形式
自评估（主要形式）：
🏢 组织自身开展
- 由组织内部人员实施
- 更了解系统实际情况
- 能够及时发现问题
- 促进持续改进
🔍 检查评估（补充形式）：
- 由外部机构实施
- 提供客观公正的视角
- 起监督和验证作用
- 专业性强
关系：
- 应以自评估为主
- 两种形式相互结合、互为补充
- 共同保障评估质量
风险评估的关键要求：
📋 贯穿全过程
- 风险评估不是一次性工作
- 应贯穿于系统全生命周期
- 包括规划、设计、实施、运行、维护各阶段
- 持续监控和改进
👥 加强组织领导
- 需要高层支持和组织保障
- 明确职责分工
- 提供充足资源
- 建立协调机制
两种评估形式对比：
| 特征 | 自评估 | 检查评估 |
|---|---|---|
| 实施主体 | 组织自身 | 外部机构 |
| 主要作用 | 自我检查、持续改进 | 监督检查、验证效果 |
| 开展频率 | 定期开展 | 按需开展 |
| 了解程度 | 深入了解 | 相对表面 |
| 重要性 | 主要形式 | 补充形式 |
| 优势 | 了解实际、及时发现 | 客观公正、专业性强 |
风险评估的全过程管理：
1.2 风险管理流程
信息安全风险管理是一个系统化的过程，包括多个关键阶段。
💡 风险管理流程的关键阶段
风险管理流程：
我国标准《信息安全风险管理指南》（GB/Z24364）给出了信息安全风险管理的内容和过程。风险评估之后的关键阶段是风险处理（也称风险处置）。
为什么是风险处理：
✅ 风险处理的定位
- 风险评估之后的关键阶段
- 包括制定和实施风险处置方案
- 采取措施降低、转移、规避或接受风险
其他概念的区别：
- 风险计算：是风险分析阶段的一部分，不是独立的主要阶段
- 风险预测：不是标准流程中的独立阶段
- 风险评价：是风险评估阶段的一部分，不是评估之后的独立阶段
风险管理的关键阶段：
| 阶段 | 主要活动 | 目标 | 输出 |
|---|---|---|---|
| 背景建立 | 确定范围、调查系统、分析环境 | 建立风险管理基础 | 系统描述报告、安全需求报告 |
| 风险评估 | 识别资产、威胁、脆弱性 | 评估风险水平 | 风险评估报告 |
| 风险处置 | 制定和实施处置方案 | 降低风险 | 风险处置计划 |
| 风险监控 | 持续监控和审查 | 确保有效性 | 监控报告 |
二、背景建立
2.1 背景建立概述
🎯 背景建立的重要性
背景建立是信息安全风险管理过程中实施工作的第一步，为后续的风险评估和处置奠定基础。
背景建立的核心任务：
2.2 背景建立的依据
✅ 正确理解：背景建立的依据
背景建立的依据包括：
📋 国家、地区、行业的相关政策、法律、法规和标准
- 网络安全法
- 等级保护制度
- 行业安全标准
- 合规要求
🎯 机构的使命
- 组织的战略目标
- 核心业务使命
- 发展规划
💼 信息系统的业务目标和特性
- 系统的业务功能
- 业务流程
- 业务重要性
- 系统特点
依据的作用：
| 依据类型 | 作用 | 示例 |
|---|---|---|
| 政策法规 | 确定合规要求 | 网络安全法、等级保护 |
| 机构使命 | 明确保护重点 | 核心业务系统 |
| 业务目标 | 确定安全需求 | 可用性、完整性要求 |
| 系统特性 | 识别安全风险 | 技术架构、数据敏感度 |
2.3 背景建立的输出文档
背景建立阶段的主要输出：
📋 背景建立阶段的文档输出
背景建立阶段主要输出两类文档：
📊 系统描述报告
- 描述信息系统的业务目标、业务特性
- 描述管理特性和技术特性
- 提供系统全貌
🔒 安全需求报告
- 分析信息系统的体系结构和关键要素
- 分析信息系统的安全环境和要求
- 明确安全需求
背景建立阶段不包括的内容：
⚠️ 常见错误：混淆背景建立和风险评估
错误说法：背景建立阶段应识别需要保护的资产、面临的威胁以及存在的脆弱性，并分别赋值，同时确认已有的安全措施，形成需要保护的资产清单。
❌ 为什么这是错误的：
这个描述混淆了背景建立和风险评估两个阶段的工作。
背景建立阶段（第一步）：
- ✅ 调查信息系统
- ✅ 分析信息系统
- ✅ 确认已有安全措施
- ❌ 不包括识别资产、威胁、脆弱性并赋值
- ❌ 不包括形成资产清单
风险评估阶段（第二步）：
- ✅ 识别资产
- ✅ 识别威胁
- ✅ 识别脆弱性
- ✅ 对资产、威胁、脆弱性进行赋值
- ✅ 形成资产清单
风险评估文档的正确归属：
| 文档类型 | 所属阶段 | 主要内容 |
|---|---|---|
| 风险评估方案 | 准备阶段 | 目的、范围、目标、步骤、预算、进度 |
| 风险评估方法和工具列表 | 准备阶段 | 评估方法、测试工具 |
| 风险评估准则要求 | 准备阶段 | 参考标准、分析方法、分类标准 |
| 系统描述报告 | 背景建立 | 业务、管理、技术特性 |
| 安全需求报告 | 背景建立 | 体系结构、安全环境、安全要求 |
| 已有安全措施列表 | 背景建立/风险要素识别 | 技术和管理安全措施 |
| 资产清单 | 风险评估 | 需要保护的资产列表 |
| 威胁列表 | 风险评估 | 面临的威胁 |
| 脆弱性列表 | 风险评估 | 存在的脆弱性 |
| 风险评估报告 | 风险评估 | 风险分析结果 |
💡 《已有安全措施列表》在风险评估中的位置
所属阶段：风险要素识别阶段
为什么在这个阶段：
📋 风险要素识别的完整内容
- 识别需要保护的资产
- 识别面临的威胁
- 识别存在的脆弱性
- 确认已有的安全措施
🔍 已有安全措施的关键作用
- 了解现有防护能力的基线
- 识别安全控制的缺口和不足
- 为后续的风险分析提供重要依据
- 避免在风险处置时重复建设
- 评估剩余风险的大小
列表包含的内容类型：
- 技术措施：防火墙、入侵检测系统、加密系统
- 管理措施：安全策略、管理流程、制度规范
- 物理措施：门禁系统、监控设备、环境控制
- 人员措施：安全培训、背景调查、职责分离
风险评估各阶段文档对比：
风险评估文档体系：
├── 准备阶段
│ ├── 风险评估方案
│ ├── 风险评估方法和工具列表
│ └── 风险评估准则要求
├── 背景建立阶段
│ ├── 系统描述报告
│ └── 安全需求报告
├── 风险要素识别阶段
│ ├── 资产清单
│ ├── 威胁列表
│ ├── 脆弱性列表
│ └── 已有安全措施列表 ✅
├── 风险分析阶段
│ ├── 风险计算结果
│ └── 风险矩阵
└── 风险评价阶段
├── 风险评估报告
└── 风险处置建议2.4 背景建立的主要活动
背景建立阶段的三大活动：
1. 调查信息系统
📊 系统调查的内容
调查信息系统的业务目标、业务特性、管理特性和技术特性，形成信息系统的描述报告。
调查内容：
💼 业务目标
- 系统的业务功能
- 支持的业务流程
- 业务重要性
🏢 业务特性
- 业务类型
- 用户群体
- 业务量
- 业务时间要求
⚙️ 管理特性
- 组织结构
- 管理流程
- 人员配置
- 管理制度
🖥️ 技术特性
- 系统架构
- 技术平台
- 网络拓扑
- 数据流向
系统描述报告内容：
信息系统描述报告：
├── 系统概述
│ ├── 系统名称和版本
│ ├── 系统定位和作用
│ └── 系统范围和边界
├── 业务描述
│ ├── 业务目标
│ ├── 业务流程
│ ├── 业务特性
│ └── 用户群体
├── 管理描述
│ ├── 组织结构
│ ├── 管理流程
│ ├── 人员配置
│ └── 管理制度
└── 技术描述
├── 系统架构
├── 技术平台
├── 网络拓扑
└── 数据流向2. 分析信息系统
🔍 系统分析的内容
分析信息系统的体系结构和关键要素，分析信息系统的安全环境和要求，形成信息系统的安全需求报告。
分析内容：
🏗️ 体系结构分析
- 系统层次结构
- 组件关系
- 接口定义
- 数据流向
🔑 关键要素分析
- 关键资产
- 关键流程
- 关键人员
- 关键技术
🌐 安全环境分析
- 外部威胁
- 内部威胁
- 技术环境
- 法律环境
📋 安全要求分析
- 机密性要求
- 完整性要求
- 可用性要求
- 合规性要求
安全需求报告内容：
信息系统安全需求报告：
├── 体系结构分析
│ ├── 系统层次
│ ├── 组件关系
│ └── 接口定义
├── 关键要素识别
│ ├── 关键资产
│ ├── 关键流程
│ └── 关键人员
├── 安全环境分析
│ ├── 威胁分析
│ ├── 环境分析
│ └── 约束条件
└── 安全需求定义
├── 机密性需求
├── 完整性需求
├── 可用性需求
└── 合规性需求3. 确认已有安全措施
已有安全措施的调查：
- 🔐 技术安全措施
- 📋 管理安全措施
- 🏢 物理安全措施
- 👥 人员安全措施
2.5 软件后门风险
软件供应商或制造商可能在产品中安装"后门"程序，这种情况面临的主要风险需要特别关注。
💡 软件后门的主要风险
软件后门面临的最主要风险：软件中止和黑客入侵
当软件供应商或制造商在产品中安装后门程序时，主要面临以下风险：
🚫 软件中止风险
- 供应商可能通过后门远程禁用软件
- 可能导致业务突然中断
- 失去对系统的控制权
- 无法继续使用关键功能
🔓 黑客入侵风险
- 后门可能被黑客发现和利用
- 成为系统的安全漏洞
- 绕过正常的安全控制
- 导致未授权访问
其他相关概念：
📡 远程监控和远程维护
- 这些是后门的功能特性
- 远程维护可能是合法的业务需求
- 本身不是主要风险，但可能被滥用
风险识别要点：
- 软件中止和黑客入侵是最主要的两个风险
- 直接威胁系统可用性和安全性
- 需要重点防范
软件后门的风险场景：
后门风险的影响：
| 风险类型 | 影响 | 严重程度 | 防护措施 |
|---|---|---|---|
| 软件中止 | 业务中断、系统不可用 | 高 | 合同约束、备份方案、多供应商策略 |
| 黑客入侵 | 数据泄露、系统被控制 | 高 | 代码审计、安全测试、监控检测 |
| 远程监控 | 隐私泄露、商业机密泄露 | 中 | 网络隔离、流量监控 |
| 远程维护 | 可能被滥用 | 低-中 | 访问控制、审计日志 |
防范软件后门的措施：
软件后门防范策略：
├── 采购阶段
│ ├── 选择可信供应商
│ ├── 审查合同条款
│ ├── 要求源代码审计
│ └── 明确禁止后门条款
├── 部署阶段
│ ├── 代码安全审计
│ ├── 安全配置检查
│ ├── 网络隔离部署
│ └── 禁用不必要功能
├── 运行阶段
│ ├── 网络流量监控
│ ├── 异常行为检测
│ ├── 定期安全扫描
│ └── 访问日志审计
└── 应急准备
├── 制定应急预案
├── 准备替代方案
├── 数据备份策略
└── 供应商应急联系2.6 关键系统的开发方式选择
对于具有任务紧急性和核心功能性的计算机应用程序系统，开发和维护方式的选择直接影响系统的安全性和可控性。
💡 关键系统应该内部实现
核心系统的开发方式：内部实现
从风险的观点来看，具有任务紧急性和核心功能性的计算机应用程序系统的开发和维护项目应该内部实现。
为什么选择内部实现：
🔒 安全性考虑
- 核心代码不外泄
- 减少供应链风险
- 避免后门风险
- 完全自主可控
⚡ 紧急性要求
- 快速响应需求变化
- 不依赖外部资源
- 灵活调整优先级
- 及时处理紧急问题
🎯 核心功能保护
- 保护商业机密
- 维护竞争优势
- 确保业务连续性
- 积累核心能力
其他开发方式的风险：
⚠️ 外部采购实现
- 依赖外部供应商，存在供应链风险
- 可能有后门风险
- 不适合核心关键系统
⚠️ 合作实现
- 核心代码可能外泄，控制权分散
- 协调成本高，不适合紧急任务
❌ 多来源合作实现
- 风险最分散，协调最复杂
- 安全性最难保证
- 最不适合核心系统
不同开发方式的风险对比：
开发方式选择决策矩阵：
| 系统特征 | 内部实现 | 外部采购 | 合作实现 | 多来源合作 |
|---|---|---|---|---|
| 核心功能性 | ✅ 最适合 | ❌ 不适合 | ⚠️ 谨慎 | ❌ 不适合 |
| 任务紧急性 | ✅ 最适合 | ⚠️ 谨慎 | ⚠️ 谨慎 | ❌ 不适合 |
| 安全敏感性 | ✅ 最适合 | ❌ 不适合 | ⚠️ 谨慎 | ❌ 不适合 |
| 通用功能 | ⚠️ 可以 | ✅ 适合 | ✅ 适合 | ⚠️ 可以 |
| 非核心功能 | ⚠️ 可以 | ✅ 适合 | ✅ 适合 | ✅ 适合 |
内部实现的优势：
内部实现的优势：
├── 安全性
│ ├── 代码完全自主
│ ├── 无供应链风险
│ ├── 无后门风险
│ └── 可控的安全措施
├── 灵活性
│ ├── 快速响应变化
│ ├── 灵活调整优先级
│ ├── 自主决策
│ └── 不受外部约束
├── 可控性
│ ├── 完全掌控进度
│ ├── 质量自主把控
│ ├── 技术路线自主
│ └── 维护完全自主
└── 能力建设
├── 积累核心技术
├── 培养专业团队
├── 形成技术壁垒
└── 长期竞争优势内部实现的挑战：
⚠️ 内部实现的要求
需要具备的条件：
- 👥 足够的技术团队
- 💰 充足的资源投入
- ⏱️ 合理的时间规划
- 🎯 明确的技术路线
- 📚 完善的知识积累
可能面临的挑战：
- 开发周期可能较长
- 初期投入较大
- 需要持续的人才投入
- 技术风险需要自行承担
2.7 背景建立的常见误区
⚠️ 常见错误理解
错误说法：背景建立阶段应识别需要保护的资产、面临的威胁以及存在的脆弱性，并分别赋值，同时确认已有的安全措施，形成需要保护的资产清单。
❌ 为什么这是错误的：
这个描述混淆了背景建立和风险评估两个阶段的工作内容。
正确理解：
-
背景建立阶段
- ✅ 调查系统特性
- ✅ 分析安全环境和要求
- ✅ 确认已有安全措施
- ❌ 不包括识别资产、威胁、脆弱性并赋值
-
风险评估阶段
- ✅ 识别资产
- ✅ 识别威胁
- ✅ 识别脆弱性
- ✅ 进行赋值
- ✅ 形成资产清单
背景建立 vs 风险评估：
| 阶段 | 主要工作 | 输出 |
|---|---|---|
| 背景建立 | 调查系统、分析环境、确认措施 | 系统描述报告、安全需求报告 |
| 风险评估 | 识别资产、威胁、脆弱性并赋值 | 资产清单、风险评估报告 |