基本概念
安全事件（Security Accident） 是指影响一个系统正常工作的情况。这里的系统包括主机范畴内的问题，也包括网络范畴内的问题，例如黑客入侵、信息窃取、拒绝服务攻击、网络流量异常等。
应急响应（Emergency Response） 是指组织为了应对突发/重大信息安全事件的发生所做的准备以及在事件发生后所采取的措施。 应急响应是信息安全防护的最后一道防线！
应急响应体系（Emergency Response System） 是指在突发/重大信息安全事件后对包括计算机运行在内的业务运行进行维持或恢复的各种技术和管理策略和规程。
信息安全应急响应体系的制定是一个周而复始、持续改进的过程，包含以下几个阶段：
- 应急响应需求分析和应急响应策略的确定；
- 编制应急响应计划文档和技术管理规范；
- 应急响应计划的测试、培训、演练和维护。
应急响应目的
应急响应服务的目的是尽可能地减小和控制住网络安全事件的损失，提供有效的响应和恢复指导，并努力防止安全事件的发生。
政策要求
-
《关于加强信息安全保障工作的意见》（中办发『2003』27号文）指出：“信息安全保障工作的要点在于，实行信息安全等级保护制度，建设基于密码技术的网络信任体系，建设信息安全监控体系，重视信息安全应急处理工作，推动信息安全技术研发与产业发展，建设信息安全法制与标准”
-
国家信息安全战略的近期目标：通过五年的努力，基本建成国家信息安全保障体系。
-
为了落实27号文精神国家网络与信息安全协调小组办公室于2003年10月发布了《网络与信息安全信息通报暂行办法》、2004年9月发布了
- 《关于做好重要信息系统灾难备份工作的通知》，2004年8月发布了《关于建立健全基础信息网络和重要信息系统应急协调机制的意见》等文件。这些文件对推动灾难备份和应急响应的发展起到了重要作用。
相关标准
- GB/T 24364-2009 《信息安全技术 信息安全应急响应计划规范》
- GB/T 20988-2007 《信息安全技术 信息系统应急响应规范》
- GB/Z 20985-2007 《信息技术 安全技术 信息安全事件管理指南》
- GB/Z 20986-2007 《信息安全技术 信息安全事件分类分级指南》
应急响应六阶段
第一阶段：准备——让我们严阵以待
- 预防为主
-
微观（一般观点）：
- 帮助服务对象建立安全政策
- 帮助服务对象按照安全政策配置安全设备和软件 扫描，风险分析，打补丁 如有条件且得到许可，建立监控设施
-
宏观：
- 建立协作体系和应急制度
- 建立信息沟通渠道和通报机制
- 电话、即时通讯、email
- 如有条件，建立数据汇总分析的体系和能力 有关法律法规的制定
-
制定应急响应计划
- 资源准备
- 应急经费筹集
- 人力资源
- 指挥调度人员
- 协作人员
- 技术人员
- 专家
- 设备、系统和服务提供商
- 硬件设备准备
- 数据保护设备（磁盘、SAN）
- 冗余设备 （网络链路、网络设备、关键计算机设备
- 软件工具准备
- 备份软件
- 日志处理软件
- 系统软件
- 应急启动盘
- 病毒、恶意软件查杀软件
- 等等
- 现场备份
- 业务连续性保障
- 系统容灾
- 搭建临时业务系统
第二阶段：确认——对情况综合判断
- 确定事件性质和处理人
- 微观（负责具体网络的CERT）：
- 确定事件的责任人：指定一个责任人全权处理，事件，给予必要的资源
- 确定事件的性质： 误会？玩笑？还是恶意的攻击/入侵？ 影响的严重程度， 预计采用什么样的专用资源来修复？
-
宏观（负责总体网络的CERT）：
- 通过汇总，确定是否发生了全网的大规模事件
- 确定应急等级，以决定启动哪一级应急方案
-
事故的标志（征兆和预兆）
- Web服务器崩溃
- 用户抱怨主机连接网络速度过慢
- 子邮件管理员可以看到大批的反弹电子邮件与可疑内容
- 网络管理员通告了一个不寻常的偏离典型的网络流量流向
-
来源
- 网络和主机IDS 、防病毒软件、文件完整性检查软件
- 系统、网络、蜜罐日志
- 公开可利用的信息
- 第三方监视服务
-
确认事故
- 确认网络和系统轮廓： 分析事故的最好技术方法之一
- 理解正常的行为： 基于处理事故的良好准备
- 使用集中的日志管理并创建日志保留策略
- 执行事件关联
- 保持所有主机时钟同步
- 维护和使用信息知识库： 分析事故时的快速参考
- 使用互联网搜索引擎进行研究
- 运行包嗅探器以搜集更多的数据
- 过滤数据
- 经验是不可替代的
- 建立诊断矩阵
- 寻求帮助
诊断矩阵实例
| 征兆 | 拒绝服务 | 恶意代码 | 非授权访问 | 不正确使用 |
|---|---|---|---|---|
| 文件，关键，访问尝试 | 低 | 中 | 高 | 低 |
| 文件，不适当的内容 | 低 | 中 | 低 | 高 |
| 主机崩溃 | 中 | 中 | 中 | 低 |
| 端口扫码，输入的， 不正常的 |
高 | 低 | 中 | 低 |
| 端口扫码，输出的， 不正常的 |
低 | 高 | 中 | 低 |
| 利用带宽高 | 高 | 中 | 低 | 中 |
| 利用电子邮件 | 中 | 高 | 中 | 中 |
- 事故优先级- 服务水平协议
- 服务水平协议（SLA ）：
定义服务目标及双方的预期及责任 - 服务水平协议指标 - 远程应急响应服务 在确认客户的应急响应请求后? 小时内，交与相关应急响应人员进行处理。无论是否解决，进行处理的当天必须返回响应情况的简报，直到此次响应服务结束。 - 本地应急响应服务 对本地范围内的客户，？小时内到达现场；对异地的客户，？小时加路途时间内到达现场。
应急响应 SLA矩阵
| 事故当前或将来可 能的影响 | 高（例如：互联网 连接，公共Web服 务器，防火墙，客 户数据） | 中（例如：系统管 理员工作站，文件和 打印服务器，XYZ 应用数据） | 低（例如：用户工 作站） |
|---|---|---|---|
| ROOT级访问 | 15min | 30min | 1h |
| 非授权的数据修改 | 15min | 30min | 2h |
| 对敏感信息的非 授权访问 |
15min | 1h | 1h |
| 非授权的用户级访问 | 30min | 2h | 4h |
| 服务不可用 | 30min | 2h | 4h |
| 骚扰 | 30min | 不限 | 不限 |
第三阶段：遏制——制止事态的扩大
- 即时采取的行动
- 微观：
- 防止进一步的损失，确定后果
- 初步分析，重点是确定适当的封锁方法
- 咨询安全政策
- 确定进一步操作的风险
- 损失最小化（最快最简单的方式恢复系统的基本功能，例如备机启动）
- 可列出若干选项，讲明各自的风险，由服务对象选择
-
宏观：
- 确保封锁方法对各网业务影响最小
- 通过协调争取各网一致行动，实施隔离
- 汇总数据，估算损失和隔离效果
-
建议组织机构为几类主要的事故建立单独的遏制策略，其标准包括：
- 潜在的破坏和资源的窃取
- 证据保留的需要
- 服务可用性（例如：网络连接，提供给外部当事方的服务）
- 实施战略需要的时间和资源
- 战略的有效性（例如：部分遏制事故，完全遏制事故）
- 解决方案的期限（例如：紧急事故工作区需在4 小时内清除，临时工作区需在两周内清除，永久的解决方案）。
第四阶段：根除——彻底的补救措施
- 长期的补救措施
- 微观：
- 详细分析，确定原因，定义征兆
- 分析漏洞
- 加强防范
- 消除原因
- 修改安全政策
- 宏观：
- 加强宣传，公布危害性和解决办法，呼吁用户解决终端的问题；
- 加强检测工作，发现和清理行业与重点部门的问题
第五阶段：恢复——系统恢复常态
- 微观：
- 被攻击的系统恢复正常的工作状态
- 作一个新的备份
- 把所有安全上的变更作备份
- 服务重新上线
- 持续监控
- 宏观：
- 持续汇总分析，了解各网的运行情况
- 根据各网的运行情况判断隔离措施的有效性
- 通过汇总分析的结果判断仍然受影响的终端的规模
- 发现重要用户及时通报解决
- 适当的时候解除封锁措施
第六阶段：跟踪——还会有第二次吗
- 关注系统恢复以后的安全状况，特别是曾经出问题的地方
- 建立跟踪文档，规范记录跟踪结果
- 对响应效果给出评估
- 对进入司法程序的事件，进行进一步的调查，打击违法犯罪活动
- 事件的归档与统计
- 处理人
- 时间和时段
- 地点
- 工作量
- 事件的类型
- 对事件的处置情况
- 代价
- 细节
应急预案的编制和管理
应急响应预案的制定
-
制定应急响应预案的原则
- 首先，必须集中管理应急响应预案的版本和发布。
- 其次，为了建立有效的版本控制体系，必须建立规范的应急响应预案的问题提交、解决、更新、跟踪、发布的渠道和流程。
- 第三，建立相关的保密管理规定，保证应急响应预案中涉及的秘密信息得到保护。
- 第四，应急响应预案在内容管理方面应注意内容的分布和粒度，可根据版本和内容的更新频度将应急响应的内容进行适当的分布。
- 第五，建立合理的应急响应预案的保管制度，强调存放的安全性和易取得性。
-
成功预案的特点
- 清楚、简洁
- 高级管理层支持/组织承诺
- 不断改进和更新的恢复策略
- 及时的更新维护
- 组织职责分工明确
- 保留、备份和异地存储计划
- 完整记录并定期演练
- 风险得到管理
- 弱点得到优先重视
- 灵活、可适应
应急响应预案的教育、培训和演练
- 在灾难来临前使相关人员了解熟悉恢复流程
- 使应急响应预案得到理解并可以使用
- 促进应急响应预案活动、更新、实用
- 展示恢复的能力
- 达到法律和内部审计要求
演练与演习的类型
- 演练和演习的主要方式有：
- 桌面演练；
- 模拟演练；
- 实战演练等
- 根据演练和演习的深度，可分为：
- 系统级演练；
- 应用级演练；
- 业务级演练等
- 根据演练和演习的准备情况，可分为：
- 计划内的演练和演习；
- 计划外的演练和演习等
预案维护管理
- 核对预案的功能性
- 验证预案文档的精确性和完整性
- 分发更新的文档
- 文档计划分发和发布流程
- 确保相关的团队收到更新的文档
- 依靠维护来改变管理流程
- 提供培训作为持续维护预案的一部分
- 为与应急响应的相关人员开展定期培训，如：复习进修课程或灾难备份研讨会
- 指派培训责任，如：部门经理要确保员工被送去参加培训
- 完成时报告预案维护情况
- 毁掉旧应急响应预案的复印件或电子版本
预案变更管理
- 业务操作的增长或变化
- 如：新的分支、产品和业务功能的增加
- 公司所有权的变化
- 关键人员的变化
- 硬件配置的变化
- 使用新操作系统
- 预案审核和演练后
- 软件/应用软件的变化
- 新的法律或审计要求
- 定期审核和更新——如：每年两次
- 《应急预案管理制度》
- 应急预案变更记录
应急响应体系建立流程
信息安全应急响应计划编制方法
总则
- 编制目的
- 编制依据
- 适应范围
- 工作原则
角色及职责
- 应急响应领导小组
- 应急响应技术保障小组
- 应急响应专家小组
- 应急响应实施小组
- 应急响应日常运行小组
预防和预警机制
检测、 预测、 预警，做到 早发现、早报告、早处置
应急响应流程
- 事件通告
- 信息通报
信息通报分为组织内信息通报和组织外信息通报两部分。组织内信息通报的目的是在信息安全事件发生后迅速通知应急响应日常运行小组，并根据评估结果迅速通知所有相关人员，从而快速有序的实施应急响应计划。组织外信息通报目的是将相关信息及时通报给受到负面影响的外部机构、互联的单位系统以及重要用户，同时根据应急响应的需要，应将相关信息准确通报给相关设备设施及服务提供商（包括电信、电力等）等外部组织，以获得适当的应急响应支持。值得注意的是对外信息通报应符合组织的对外信息发布策略。
- 信息上报
信息安全事件发生后，应按照相关规定和要求，及时将情况上报相关主管或监管单位/部门。
- 信息披露
信息发布的目的是避免信息安全事件影响被误传，同时规范组织内人员信息披露，保证信息的一致性。因此，信息安全事件发生后，应根据信息安全事件的严重程度，指定特定的小组及时向新闻媒体发布相关信息，并且指定的小组应严格按照组织相关规定和要求对外发布信息，同时组织内其它部门或者个人不得随意接受新闻媒体采访或对外发表自己的看法。
- 应急响应流程-呼叫树
| 小组名称 | 姓名 | 在小组中职位 | 联络信息 | ||||
| 工作电话 | 家庭电话 | 手机 | 电子邮件 | 家庭住址 | |||
- 信息上报
| 重大信息安全事件报告表 | |
|---|---|
| 报告时间： x 年x 月x 日x 时x 分 | |
| 单位名称： | 报告人： |
| 联系电话： | 通讯地址： |
| 传真： | 电子邮件： |
| 发生重大信息安全事件的信息系统名称及用途： | |
| 负责部门： | 负责人： |
| 重大信息安全事件的简要描述（如以前出现过类似情况也应加以说明）： | |
| 初步判定的事故原因： | |
| 当前采取的措施： | |
| 本次重大信息安全事件的初步影响状况： | |
| 影响范围： | 严重程度： |
| 值班电话： | 传真： |
- 事件分类与定级
要确定信息安全事件后如何实施应急响应计划，对系统损害性质和程度的评估是非常重要的。这个损害评估应该在能够确保人员安全这个最优先任务的前提下尽快完成。所以，如果可能，应急响应日常运行小组是第一个得到事件通知的小组。损害评估规程对于不同的系统是不同的，但是应该涉及到以下领域： 1. 造成紧急情况或中断的原因； 1. 潜在的附加中断或损失； 1. 受到紧急情况影响的区域； 1. 物理构架（如计算机室结构的完整性、电源、电信以及制热、通风和空调的情况）的状况； 1. 系统设备的总量和功能状态（如具备完整功能、具备部分功能或丧失功能）； 1. 系统设备及其存货的损失类型（如水害、水灾或热能、物理以及电涌影响）； 1. 被更换的项目（如硬件、软件、固件或支持材料）； 1. 估计恢复正常服务所需的时间。
- 我国信息安全事件分类方法
GB/Z 20986-2007《信息安全事件分级分类指南》 - 有害程序事件MI - 网络攻击事件NAI - 信息破坏事件IDI - 信息内容安全事件ICSI - 设备设施故障FF - 灾害性事件DI - 其他信息安全事件OI - 分级要素 - 系统损失 - 信息系统重要程度 - 社会影响
特别重大事件(I级）
特别重大事件是指能够导致特别严重影响或破坏的信息安全事件，包括以下情况： - 会使特别重要信息系统遭受特别严重的系统损失 - 产生特别重大的社会影响
重大事件(II级）
重大事件是指能够导致严重影响或破坏的信息安全事件，包括以下情况： - 会使特别重要信息系统遭受严重的系统损失、或使重要信息系统遭受特别严重- 的系统损失 - 产生重大的社会影响
较大事件(III级）
较大事件是指能够导致严重影响或破坏的信息安全事件，包括以下情况： - 会使特别重要信息系统遭受较大的系统损失、或使重要信息系统遭受严重的系统损失，一般信息系统遭受特别严重的系统损失 - 产生较大的社会影响
一般事件(IV级）
一般事件是指不满足以上条件的信息安全事件，包括以下情况： - 会使特别重要信息系统遭受较小的系统损失、或使重要信息系统遭受较大的系统损失，一般信息系统遭受严重或严重以下级别的系统损失 - 产生一般的社会影响
应急启动
- 启动原则——快速、有序；
- 启动依据——一般而言，对于导致业务中断、系统宕机、网络瘫痪等突发/重大信息安全事件应立即启动应急。但由于组织规模、构成、性质等的不同，不同组织对突发/重大信息安全事件的定义可能不一样，因此，各组织的应急启动条件可能各不相同。启动条件可以基于以下方面考虑：人员的安全和/或设施损失的程度；系统损失的程度（如物理的、运作的或成本的）；系统对于组织使命的影响程度（如保护资产的关键基础设施）；预期的中断持续时间等。只有当损害评估的结果显示一个或多个系统启动条件被满足时，应急响应计划才应被启动。
- 启动方法——由应急响应领导小组发布应急响应启动令。
应急处置
- 恢复顺序
当恢复复杂系统时，恢复进程应该反映出BIA中确定的系统优先顺序。恢复的顺序应该反映出系统允许的中断时间，以避免对相关系统及其应用的重大影响。 - 恢复规程
为了进行恢复操作，应急响应计划应提供恢复业务能力的详细规程。规程应被设定给适当的恢复小组并且通常涉及到以下行动：- 获得访问受损设施和／或地理区域的授权；
- 通知相关系统的内部和外部业务伙伴；
- 获得所需的办公用品和工作空间；
- 获得安装所需的硬件部件；
- 获得装载备份介质；
- 恢复关键操作系统和应用软件；
- 恢复系统数据；
- 成功运行备用设备。
后期处置
- 信息系统重建
在应急处置工作结束后，要迅速采取措施，抓紧组织抢修受损的基础设施，减少损失，尽快恢复正常工作。 通过统计各种数据，查明原因，对信息安全事件造成的损失和影响以及恢复重建能力进行分析评估，认真制定恢复重建计划，迅速组织实施信息系统重建。 - 应急响应总结
应急响应总结是应急处置之后应进行的工作，具体工作包括：- 分析和总结事件发生原因；
- 分析和总结事件现象；
- 评估系统的损害程度；
- 评估事件导致的损失；
- 分析和总结应急处置记录；
- 评审应急响应措施的效果和效率，并提出改进建议；
- 评审应急响应计划的效果和效率，并提出改进建议。
信息安全事件应急响应总结模板
| 信息安全事件应急响应结果报告表 | |
|---|---|
| 原事件报告时间： x 年x 月x 日x 时x 分 | |
| 备案编号： x 年x 月x 日x 第 x 号 | |
| 单位名称： | 报告人： |
| 联系电话： | 通讯地址： |
| 信息系统名称及用途： | |
| 已采用的安全措施： | |
| 信息安全事件的补充描述及最后判定的事故原因： | |
| 本次信息安全事件的初步影响状况： | |
| 事后结果： | 影响范围： |
| 严重程度： | |
| 本次信息安全事件的主要处理过程及结果： | |
| 针对此类信息安全事件应采取的保障信息系统安全的措施和建议： | |
| 报告人签名： | |
应急响应保障措施
-
人力保障
- 管理人力
- 技术人力
-
物质保障
- 财力
- 交通运输
- 通信
-
技术保障
- 应急响应技术支持
- 事件监控与预警
- 应急技术储备
附件
- 具体的组织体系结构及人员职责
- 应急响应计划各小组成员的联络信息
- 供应商联络信息，包括离站存储和备用站点的外部联系点
- 系统恢复或处理的标准操作规程和检查列表
- 支持系统运行所需的硬件、软件、固件和其它资源的设备和系统需求清单
- 供应商服务水平协议（SLA）、与其它机构的互惠协议和其它关键记录
- 备用站点的描述和说明
- 在计划制定前进行的BIA，包含关于系统各部分相互关系、风险、优先级别等
- 应急响应计划文档的保存和分发方法
应急响应工作机构图
职责示例
应急响应领导小组：<b1. 应急响应领导小组是信息安全应急响应工作的组织领导机构，组长应由组织最高管理层成员担任。领导小组的职责是领导和决策信息安全应急响应的重大事宜，主要如下： 1. 对应急响应工作的承诺和支持，包括发布正式文件、提供必要资源（人财物）等； 1. 审核并批准应急响应策略； 1. 审核并批准应急响应计划； 1. 批准和监督应急响应计划的执行； （1. 启动定期评审、修订应急响应计划； 1. 负责组织的外部协作工作。
应急响应组（IRT ）
- 什么是应急响应组（IRT ）
- 应急响应组就是机构可以借助的网络安全专业组织。
- 为什么需要成立应急响应组
- 容易协调响应工作
- 提高专业知识
- 提高效率
- 提高先期主动防御能力
- 更加适合于满足机构的需要
- 提高联络功能
- 提高处理制度障碍方面的能力
从应急组织到应急体系：信息安全保障的必要条件
- 现实表明，单一的应急组织已经不能应对当今的网络安全威胁，我国的应急体系正是在实际工作的经验总结中逐渐形成的：平台从点到环到面；应急体系从点到树到网
- “现实世界中发生的任何事情，在网络世界中都可以找到与之对 应的事件”
- SARS 事件反映出社会防疫应急体系的重要
- 红色代码、尼姆达、SQL 杀手、口令蠕虫等具有和现实世界中的疫病相同的特点
- 处理方式也具有同样的特点：隔离--- 分析--- 治疗
- 不同之处：“病人”不自知；隔离缺乏法律依据或技术手段；应
- 急缺乏成熟体系和工作制度…. .
国际信息安全应急响应组织
- 美国计算机紧急事件响应小组协调中心 （Computer Emergency Response Team/Coordination Center, CERT/CC）
- 事件响应与安全组织论坛（Forum of Incident Response and Security Teams, FIRST）
- 亚太地区计算机应急响应组（Asia Pacific Computer Emergency Response Team, APCERT）
- 欧洲计算机网络研究教育协会（Trans-European Research and Education Networking Association, TERENA)
- 国家计算机网络应急技术处理协调中心 （National Computer network Emergency Response technical Team/Coordination Center of China, CNCERT/CC）
- 中国教育和科研计算机网紧急响应组(China Education and Research Network Computer Emergency Response Team, CCERT)
- 国家计算机病毒应急处理中心
- 国家计算机网络入侵防范中心
- 国家863计划反计算机入侵和防病毒研究中心
信息系统应急计划一般过程
- 美国SP800-34 信息技术系统应急计划/预案指南：七步走
- 第一步：制定应急计划/预案策略条款
- 第二步：进行业务影响分析
- 第三步：确定防御性控制
- 第四步：制定恢复策略
- 第五步：IT应急计划/预案的制定
- 第六步：计划/预案的测试、培训和演习
- 第七步：计划/预案的维护
