应急响应服务方案

随着网络信息化建设的不断深入，加强各类设备、系统以及信息与网络安全等方面应对应急事件的处理能力将是运维项目面临的一项重要任务。为确保系统及机房安全与稳定，以保证正常运行为宗旨，按照“预防为主，积极处置”的原则，本着建立一个有效处置应急事件，建立统一指挥、职责明确运转有序、反应迅速处置有力的安全体系的目标，将正在发生或已发生事故的损害程度减轻到最低，确保系统和数据安全，特制定本应急保障方案。

在应急事件发生时，通过应急事件处置与应急响应机制，保障计算机信息系统继续运行或紧急恢复，可归纳为3个方面：

² 紧急事件或安全发生时的影响分析；

² 应急预案的详细制订；

² 应急预案的演练与完善。

1.1 应急响应原则

u 实时原则

应急响应服务中心配备了7X24的人员值班机制，保证接受客户在任意时间提出的服务请求。并在接到客户的服务请求以后，在1个小时之内给予响应。

u 规范性原则

对于每一次应急事件的发生都有严格的事件记录，记录事件处理的全部过程，对于现场处理事件由用户签署认可建议。

u 最小性原则

事件处理过程中，将事件对整个系统的影响降低到最小，强化处理前的分析与备份工作。

u 保密性原则

对于所有事件的处理内容、时间、地点，严格遵从保密原则，不向任何的第三方透漏。

1.2 应急处理原则

为保证系统连续、稳定、高效地运行，最大限度地节省和保护用户的投资， 我方公司不仅提供完善技术支持和售后服务，还将充分考虑各种突发事件的应急 策略，根据教育系统的硬件配置、应用需求、地理环境等因素, 提供系统的应急 方案，及时解决突发的设备故障问题，确保系统安全高效的运行。

1. 预防为主。立足安全防护，加强预警，重点保护基础信息网络和信息系统安全、稳定，从预防、监控、应急处理、应急保障等环节，在管理、技术、人员等方面采取多种措施充分发挥各方面的作用，共同构筑安全保障体系。故障预防，维护一个良性的系统关键在于维护和故障预防。所以，我们将协助用户建立 正常运转时的维护和异常检测系统。

2. 快速反应。应急事件发生时，按照快速反应机制，及时获取充分而准确的信息，跟踪研判，果断决策，迅速处置，最大程度地减少危害和影响。建立设备基线，在设备正常运转时，尤其是在设备安装调试完成，系统试运行结束时，经过 不断的调整，我们得到一个全面运行良好的系统，应当认真记录此时的系统各项 运行参数，存档保留，这将是日后判断系统是否正常运转的基准线。异常事件，对于系统运行过程中的异常现象应当认真加以分析，在我方技术工程师的协 助下查明其原因。切不可忽略。日志审阅，定期检查设备运行日志，分析设备运行状态，作出设备运行状况表，及早发 现潜在的问题并加以解决。

设备应急

备件

对故障除了及时维修外，最便捷的解决办法就是备品备件。当故障发生时， 可以从我们设立的一级备品/备件管理中心立即获得有关维修件，在我们的工程师 协助下迅速恢复系统。

备机

对于设备的硬件故障非常复杂的情况，我们为了保证用户网络系统的尽快运 行，我方针对本项目提供相应备机。这样，即使设备故障在短时间内不能及时解 决，我方可以及时启用备机，确保用户迅速得到无故障运行的设备。

突发事件应急

可能发生的突发事件分类

根据定制化服务器系统突发事件的发生原因、性质和机理，突发事件主要分 为以下四类：

故障类事件： 指定制化服务器软硬件故障、配置丢失、人为误操作等导致业 务中断、系统宕机、瘫痪等情况。

攻击类事件：指定制化服务器系统感染计算机病毒、非法入侵导致业务中断、 系统宕机、网络瘫痪等情况。

灾害类事件： 指因火灾、地震、台风等不可抗力因素导致机器损毁，造成业 务中断、系统宕机、业务瘫痪等情况。

供货实施应急类：指在项目设备供货阶段和实施阶段过程中，由于某种原因 造成了中断情况。

应急级别定义

我们项目服务支持小组根据用户所突发的事件首先进行业务故障分级，按照 不同的应急级别，提供不同的业务服务，我们项目服务支持小组的工程师，会根 据不同的应急故障等级，提供不同的 IT 解决方案，并且快速解决故障问题。

我们根据系统故障的破坏程度，对系统应急故障级别分为四级，通过四级级 别及时发布预警，过渡到应急预案；通过应急预案及时解决突发事件；防止系统 突发事件发生或扩散，并及时向用户汇报。并四级故障级别如下所述。

维修及突发事件应急方案

经过多年的不断总结和完善，我方拥有一套完整的系统故障应急方案，通过 我方突发事件应急方案并紧密协调厂商，项目系统可得到反应迅速、精密准确的 解决方案服务。

 应急技术服务团队

人员组成

为应付系统的各种突发故障，我方专家支持小组统一领导和调度我方公司的 各级服务体系，进行服务资源优化，保证及时有效地投入解决各种突发故障；我 方还安排了专家支持小组工程师作为应急支持人员。

时间安排

对于突发事件的响应不受工作日与非工作日的限制，我们将竭尽全力协调公 司内的资源，为用户提供援助。

联系方式

我们向用户提交应急工程师的工作档案和联系方式，并经常更新此联系表， 以保持联系人员的可用性。

3. 分级负责。按照“谁主管，谁负责”的原则，建立和完善安全责任制及联动工作机制。根据各负责人的职能，各司其职，加强各负责人的协调与配合，共同履行应急处置工作的管理职责。

4. 以人为本。把保障人员以及客户利益的安全作为首要任务。

5. 常备不懈。加强技术储备，规范应急处置措施与操作流程，定期进行预案演练，确保应急预案切实有效，实现网络与信息安全突发公共事件应急处置的科学化、程序化与规范化。

1.3 应急响应服务

应急事件响应，是当应急事件发生后迅速采取的措施和行为，其目的是以最快的速度恢复系统的保密性，完整性和可用性，降低应急事件对业务系统造成的损失。

针对运维服务项目，除有驻场工程师进行日常巡检和维护的工作外，还成立信息系统运维4S组，提供应急响应服务。当设备、软件和基础网络出现故障时，原则上由驻场运维工程现场解决，如果现场服务工程无法解决，事件升级为后台技术支持团队解决。保障在1小时内做出明确响应和安排，2小时内提供诊断报告和故障解决方案。

同时，根据客户的具体情况，制定和编写信息系统应急预案，保障客户信息系统的可靠，安全的运行。

1.3.1 应急事件的影响程度

通常在事件爆发的初期很难界定事件的起因具体是什么，所以，通常又通过安全威胁事件的影响程度分为单点损害、局部损害和整体损害3类。

单点损害：只造成独立个体的不可用，应急事件影响程度弱。

局部损害：造成某一系统或一个局部网络不可使用，应急事件影响程度较强。

整体损害：造成整个网络系统的不可使用，应急事件影响程度强。

1.3.2 应急事件的影响级别分类

确定事件影响程度的级别。不同的威胁级别，处理方法也不相同。根据对业务系统的影响程度从大到小的顺序将应急事件划分成4个等级。

第一级应急事件 P1 引起重要业务系统或有重要影响的应用系统宕机，系统重新引导后无法正常工作与恢复的事故，或造成安全泄密事件；

第二级应急事件 P2 重复发生或重复再现的并产生较强影响作用，导致系统正常运行的事故；

第三级应急事件 P3 间歇产生、随机产生的事故，但不影响系统的正常运行；

第四级应急事件 P4 一般性事件，与业务系统运行或产品使用要关的问题，不影响整个系统的正常运行。

1.3.3 应急事件的优先级处理

（1） 事件处理要素

事件处理要素分为管理层面和技术层面；P1、P2级事件的启动和指挥由应急总负责人负责；P3、P4级事件的启动应急领导小组负责。事件动态由应急工作小组人员收集并及时反馈给应急领导小组，应急领导小组决定信息的共享、沟通、处置。信息系统事件发生后，事发部门立即启动相关应急预案，实施处置并及时报送信息。

（2） 分级响应

发生P1、P2级事件，由应急工作小组初步判定事件级别后，将信息通知应急领导小组并注意持续监控事态、收集信息、做出应急准备；应急领导小组响应判断为P1、P2级事件后，立即通知应急总负责人，并由应急总负责人启动应急预案。

发生P3、P4级事件，由应急工作小组初步判定事件级别后，将信息通知应急领导小组并注意持续监控事态、收集信息、做出应急准备；应急领导小组响应判断为P3、P4级事件后，立即启动应急预案。

应急事件的级别应置于动态调整控制中。

（3） 指挥与协调

P1、P2级事件，由应急工作小组收集信息，应急领导小组做出预判，并迅速通知应急总负责人，由应急总负责人进行指挥和决策。

P3、P4级事件，由应急领导小组进行指挥和决策，并及时将处理过程、报告等上报应急总负责人。

（4） 信息共享和处理

P1、P2级事件，由应急工作小组收集信息并提交给应急领导小组和应急总负责人，由应急总负责人决定信息的分发、共享和处置。

P3、P4级事件，由应急领导小组决定信息的分发、共享和处置，并上报应急总负责人。

1.3.4 应急事件响应

当客户系统发生紧急事件时，对应的处理方法原则是首先保护或恢复计算机、网络服务等，使其恢复正常运行，然后再对事件进行追查．因此对于客户紧急事件响应服务主要包括准备、识别事件（判定应急事件类型）、抑制（缩小事件的影响范围）、解决问题、恢复以及后续跟踪。

Ø 准备工作；

Ø 建立客户事件档案；

Ø 与客户就故障级别进行定义；

Ø 准备应急事件紧急响应服务相关资源；

Ø 为一个应急事件的处理取得管理方面支持；

Ø 组建事件处理队伍；

Ø 提供易实现的初步报告；

Ø 制定一个紧急后备方案；

Ø 随时与管理员保持联系；

Ø 识别事件；

Ø 在指定时间内指派安全服务小组去负责此事件；

Ø 事件抄送专家小组；

Ø 初步评估，确定事件原因；

Ø 保护可追查的线索，诸如立即对日志、数据进行备份；

Ø 联系客户系统的相关服务商、厂商；

Ø 缩小事件的影响范围；；

Ø 确定系统继续运行的风险，决定是否关闭系统及采取其他措施；

Ø 与客户相关工作人员保持联系、协商；

Ø 根据需求制订相应的应急措施；

Ø 解决问题；

Ø 事件的起因分析；

Ø 事后取证调查；

Ø 后门检查；

Ø 漏洞分析；

Ø 提供解决方案；

Ø 结果提交专家小组审核；

Ø 后续工作；

Ø 检查是不是所有的服务都已经恢复；

Ø 其发生的原因是否已经处理；

Ø 应急响应步骤是否需要修改；

Ø 生成紧急响应报告；

Ø 拟定一份事件记录和跟踪报告；

Ø 事件合并、录入信息知识库。

1.4 应急响应保障措施

（1） 工具保障

我们建立了一套专门用于应急响应工具库，保证提供应急响应服务的工程师一人一套工具；为防止光盘损坏和丢失，并将此工具库进行了多套备份；同时指定了专业技术人员进行工具库的管理与维护，包括工具的测试、版本升级与维护等。

（2） 技术和人员保障

公司拥有一支技术精湛、专业、稳定的技术团队，多位在网络、主机、数据库、安全等多个领域具体丰富的实践经验的资深工程师。

公司指定技术专员整理技术经验和心得并录入知识信息数据库，一方面供技术部定期组织培训会议使用（对典型案例进行分析和学习），另一方面供TS客服中心查询以电话远程技术指导。

公司建立了图书室，图书室内目前拥有信息安全类、计算机应用类、网络管理类、分级保护相关资料与规范、等级保护相关资料与规范等方面书籍，以方便技术人员借阅。

公司定期组织技术人员进行专项技术培训学习，并以考试的方法检查技术人员的掌握情况，有针对性的对技术人员进行帮助和指导。

公司鼓励员工报考知名厂商技术认证，进行更专业的技术学习，并在考试费用上给予报销。

（3） 交通保障

紧急事件，公司应急车辆保障，可以保证在突发应急事件时能做出快速响应，第一时间赶到事件现场进行处置。

（4） 财力保障

公司有专门的经费和审批流程，确保在应急响应处理过程中需要的款项能迅速到位，保障应急事件的处理和故障恢复。

1.5 应急响应组织保障

1.5.1 组织机构与职责

针对项目，我公司成立专门应急处置小组，包含：应急领导小组和应急工作小组。

（1） 应急领导小组

应急领导小组是信息安全应急响应工作的组织领导机构，组长由组织最高管理层成员担任。职责是统一领导信息系统的应急事件的公司内部应急处理工作，发起研究重大应急决策和部署，决定实施和终止应急预案，领导和决策信息安全应急响应的重大事宜，主要职责如下：

² 制订工作方案；

² 提供人员和物质保证；

² 审核并批准经费预算；

² 审核并批准恢复策略；

² 审核并批准应急响应计划；

² 批准并监督应急响应计划的执行；

² 指导应急响应实施小组的应急处置工作；

² 启动定期评审、修订应急响应计划以及负责组织的外部协作。

（2） 应急工作小组

应急工作小组由运维服务小组人员组成，主要职责包含：落实应急领导小组布置的各项任务；组织制定应急预案，并监督执行情况；掌握应急事件处理情况，及时向应急领导小组报告应急过程中的重大问题。具体职责如下：

² 编制应急响应计划文档；

² 应急响应的需求分析，确定应急策略和等级以及策略的实现；

² 备份系统的运行和维护，协助灾难恢复系统实施；

² 信息安全应急事件发生时的损失控制和损害评估；

² 组织应急响应计划的测试和演练。

1.5.2 组织的外部协作

依据信息应急事件的影响程度，如需向其他第三方设备供应商或软件开发商寻求支持时，将联系第三方服务单位提供协作和技术支持。

1.6 应急响应流程

应急响应流程共包括6个阶段，分别是准备阶段、检测阶段、抑制阶段、根除阶段、恢复阶段、总结阶段。应急响应流程如下图所示，对于每个阶段都有其应完成的目标、实施人员角色以及阶段的结果输出。

1.6.1 准备阶段

目标：在事件真正发生前为应急响应做好预备性的工作。

角色：组织人员，技术人员

内容：根据不同角色准备不同的内容。

编出：准备工具清单、事件初步报告表和实施人员工作清单。

1.6.1.1 组织人员准备内容

制订工作方案和计划；

提供人员和物质保证；

审核并批准经费预算、恢复策略、应急响应计划；

批准并监督应急响应计划的执行；

指导应急响应实施小组的应急处置工作；

启动定期评审、修订应急响应计划以及负责组织的外部协作。

1.6.1.2 技术人员准备内容

1. 服务需求界定

首先要对整个信息系统进行评估，明确应急需求，具体应包含以下内容：

² 了解各项业务功能及其之间的相关性，确定支持各种业务功能的相关信息系统资源及其他资源，明确相关信息的保密性、完整性和可用性要求；

² 对信息系统，包括应用程序、服务器、网络及任何管理和维护这些系统的流程进行评估，确定系统所执行的关键功能，并确定执行这些关键功能所需要的特定系统资源；

² 采用定性或定量的方法，对业务中断、系统宕机、网络瘫痪等应急事件造成的影响进行评估；

² 协助客户建立适当的应急响应策略，提供在业务中断、系统宕机、网络瘫痪等应急事件发生后快速有效的恢复信息系统运行的方法；

² 为用户提供相关的培训服务，以提高用户的安全意识，便于相关责任人明确自己的角色和责任。了解常见的应急事件和入侵行为，熟悉应急响应策略。

2. 主机和网络设备安全初始化快照和备份

在系统安全策略配置完成后，要对系统优生 次初始安全状态快照。这样，如果以后出现事故后对该服务器做安全检测时，通过将初始化快照做的结果与检测阶段做的快照进行比较，就能够发现系统的改动或异常。

对主机系统做一个标准的安全初始化的状态快照，包括的主要内容有：

² 日志及审核策略快照；

² 用户账户快照；

² 进程快照；

² 服务快照；

² 自启动快照；

² 关键文件签名快照；

² 开放端口快照；

² 系统资源利用率的快照；

² 注册表快照；

² 计划任务快照等；

对网络设备做一个标准的安全初始化的状态，包括的主要内容有：

² 路由器快照；

² 安全设备快照；

² 用户快照；

² 系统资源利用率等快照。

信息系统的业务数据及办公数据均十分重要，因此需要进行数据存储及备份。目前，存储备份结构主要有DAS、SAN和NAS，以及通过磁带或光盘对数据进行备份。可根据不同的特点选择不同的存储产品构建自己的数据存储备份系统。

3. 工具包的准备

² 根据用户的需求准备处置网络应急事件的工具包，包括常用的系统基本命令、其他软件工具等；

² 工具包中的工具采用绿色免安装的，保存在安全的移动介质上，如一次性可写光盘、加密的U盘等；

² 工具包应定期更新、补充。

4. 必要技术的准备

上述是针对应急响应的处理涉及的安全技术工具涵盖应急响应的事件取样、事件分析、事件隔离、系统恢复和攻击迫踪等各个方面，构成了网络安全应急响应的技术基础。所以应急响应服务实施成员还应该掌握一些必要的技术手段和规范，具体包括以下内容。

系统检测技术，包括以下检测技术规范：

² Windows系统检测技术规范；

² UNIX系统检测技术规范；

² 网络安全牢固检测技术规范；

² 数据库系统检测技术规范；

² 常见的应用系统检测技术规范。

攻击检测技术．包括以下技术

² 异常行为分析技术；

² 入侵检测技术；

² 安全风险评估技术；

² 攻击追踪技术。

² 现场取样技术。

² 系统安全加固技术。

² 攻击隔离技术。

² 资产备份恢复技术。

1.6.2 检测阶段

目标：接到事故报警后在用户的配合下对异常的系统进行初步分析，确认其是否真正发生了信息应急事件，并制订进一步的响应策略，并保留证据。

角色：应急服务实施小组成员、应急响应日常运行小组。

内容：包括以下几项。

² 检测范围及对象的确定；

² 检测方案的确定；

² 检测方案的实施；

² 检测结果的处理；

1.6.2.1 实施小组人员的确定

应急响应负责人根据《事件初步报告表》的内容，初步分析事故的类型、严重程度等，以此来确定应急响应小组的实施人员的名单。

1.6.2.2 检测范围及对象的确定

对发生异常的系统进行初步分析，判断是否真正发生了应急事件；

与用户共同确定检测对象及范围；

检测对象及范围应得到用户的书面授权。

1.6.2.3 检测方案的确定

与用户共同确定检测方案；

制订的检测方案应明确所使用的检测规范；

制订的检测方案应明确检测范围，其检测范围应仅限于用户已授权的与应急事件相关的数据，对用户的机密性数据信息未经允许不得访问；

制订的检测方案应包含实施方案失败的应变和回退措施；

与用户充分沟通，并预测应急处理方案可能造成的影响。

1.6.2.4 检测方案的实施

检测搜集系统信息：记录使用目录及文件名约定。

搜集操作系统基本信息：包含网络连接信息、进程信息、IP属性、操作系统属性。

日志信息:导出所有日志信息

账号信息:导出所有账号信息

主机检测

² 日志检查：从日志信息中检测出未授权访问或非法登录整件；

² 账号检查：检查账号信息中非正常账号、隐藏账号。

² 进程检查：检查是否有未被授权的应用程序或服务。

² 服务检查：检查系统是否存在非法服务。

² 自启动检查：检查未授权自启动程序。

² 网络连接检查：检查非正常开放的端口。

² 共享检查：检查非法共享目录。

² 文件检查：检查病毒、木马、蠕虫、后门等可疑文件。

² 查找其他入侵痕迹：查找其他系统上的入侵痕迹，寻找攻击途径。

1.6.2.5 检测结果的处理

1. 确定应急事件的类型

经过检测，判断出信息应急事件类型。信息应急事件有以下7个基本分类。

² 有害程序事件：蓄意制造、传播有害程序，或是因受到有害程序的影响而导致的信息应急事件。

² 网络攻击事件：通过网络或其他技术手段，利用信息、系统的配置缺陷、协议缺陷、程序缺陷或使用暴力攻击对信息系统实施攻击，并造成信息系统异常或对信息系统当前运行造成潜在危害的信息应急事件。

² 信息破坏事件：通过网络或其他技术手段造成信息系统中的信息被篡改、假冒、泄露、窃取等而导致的信息应急事件。

² 信息内容应急事件：泄漏危害国家安全、社会稳定和公共利益的内容的安全。

² 设备设施故障：由于信息系统自身故障或外围保障设施故障而导致的信息应急事件，以及人为的使用非技术手段有意或无意地造成信息系统破坏而导致的信息应急事件。

² 灾害性事件：由于不可抗力对信息系统造成物理破坏而导致的信息应急事件。

² 其他信息应急事件：不能归入以上6个基本分类的信息应急事件。

2. 评估突发信息应急事件的影响

采用定量和/或定性的方法，对业务中断、系统宕机、网络瘫痪、数据丢失等突发信息应急事件造成的影响进行评估；

确定是否存在针对该事件的特定系统预案，如有，则启动相关预案；如果事件涉及多个专项预案，应同时启动所有涉及的专项预案；

如果没有针对该事件的专项预案，应根据事件具体情况，采取抑制措施，抑制事件进一步扩散。

1.6.3 抑制阶段

目标：及时采取行动限制事件扩散和影响的范围，限制潜在的损失与破坏，同时要确保封锁方法对涉及相关业务影响最小。

角色：应急服务实施小组、应急响应日常运行小组．

内容：包括以下儿项．

² 抑制方案的确定；

² 抑制方案的认可；

² 抑制方案的实施；

² 抑制效果的判定。

输出：抑制处理记录表。

1.6.3.1 抑制方案的确定

1. 在检测分析的基础上，初步确定与应急事件相对应的抑制方法，如有多项，可由用户考虑后自己选择。

2. 在确定抑制方法时应该考虑：

² 全面评估应急事件的影响和损失；

² 通过分析得到的其他结论；

² 用户的业务和重点决策过程；用户的业务连续性。

1.6.3.2 抑制方案的认可

² 告知用户所面临的首要问题；

² 确定的抑制方法和相应的措施得到用户的认可；

² 在采取抑制措施之前，与用户充分沟通，告知可能存在的风险，制订应变和回退措施，并与其达成协议。

1.6.3.3 抑制方案的实施

1. 严格按照相关约定实施抑制，不得随意更改抑制的措施的范围，如有必要更改，须获得用户的授权。

2. 抑制措施应包含但不限于以下几方而：

² 确定受害系统的范围后，将受害系统和正常的系统进行隔离，断开或暂时关闭被影响的系统，使攻击先彻底停止；

² 持续监视系统和网络活动，记录异常流量的远程IP、域名、端口；

² 停止或删除系统非正常账号，隐藏账号，更改口令，加强口令的安全级别；

² 挂起或结束未被授权的、可疑的应用程序和进程；

² 关闭存在的非法服务和不必要的服务；

² 删除系统各用户“启动”目录下未授权自启动程序；

² 使用工具或命令停止所有开放的共享；

² 使用反病毒软件或其他安全工具检查文件，扫描硬盘上所有的文件，隔离或清除病毒、木马、蠕虫、后门等可疑文件；

1.6.3.4 抑制效果的判定

是否防止了事件继续扩散，限制了潜在的损失和破坏，使目前损失最小化；

对其他相关业务的影响是否控制在最小。

1.6.4 根除阶段

目标：对应急事件进行抑制之后，通过对有关事件或行为的分析结果，找出事件根源，明确相应的补救措施并彻底清除事件。

角色：应急服务实施小组、应急响应日常运行小组．

内容：包括以下几项。

² 根除方案的确定；

² 根除方案的认可；

² 根除方案的实施；

² 根除效果的判定。

输出：根除处理记录表。

1.6.4.1 根除方案的确定

协助用户检查所有受影响的系统，在准确判断应急事件原因的基础上，提出方案建议；

由于入侵者一般会安装后门或使用其他的方法以便于在将来有机会侵入该被攻击的系统，因此在确定根除方法时，需要了解攻击者是如何入侵的，以及与这种入侵方法相同和相似的各种方法。

1.6.4.2 根除方案的认可

明确告知用户所采取的根除措施可能带来的风险，制度应变和回退措施，并得到用户的书面授权；协助用户进行根除方法的实施。

1.6.4.3 根除方案的实施

1. 使用可信的工具进行应急事件的根除处理，不得使用受害系统已有的不可信的文件和工具。

2. 根除措施宜包含但不限于以下几个方面：

² 改变全部可能受到攻击的系统账号和口令，并增加口令的安全级别；

² 修补系统、网络和其他软件漏洞；

3. 增强防护功能，复查所有防护措施的配置，安装最新的安全设备和杀毒软件，并及时更新，对未受保护或者保护不够的系统增加新的防护措施；

4. 提高其监视保护级别，以保证将来对类似的入侵进行检测。

1.6.4.4 根除效果的判定

² 找出造成事件的原因，备份与造成事件相关的文件和数据；

² 对系统中造成事件的文件进行清理，根除；

² 使系统能够正常工作。

1.6.5 恢复阶段

目标：恢复应急事件所涉及的系统，并还原到正常状态，使业务能够正常进行，恢复工作应避免出现误操作导致数据的丢失。

角色：应急服务实施小组、应急响应日常运行小组。

内容：包括以下儿项。

² 恢复方案的确定；

² 恢复信息系统。

输出：恢复处理记录表。

1.6.5.1 恢复方案的确定

1. 告知用户一个或多个能从应急事件中恢复系统的方法，及它们可能存在的风险。

2. 和用户共同确定系统恢复方案，根据抑制和根除的情况，协助用户选择合适的系统恢复的方案，恢复方案涉及以下几方面：

² 如何获得访问受损设施或地理区域的授权；

² 如何通知相关系统的内部和外部业务伙伴；

² 如何获得安装所需的硬件部件；

² 如何获得装载备份介质，如何恢复关键操作系统和应用软件；

² 如何恢复系统数据；

² 如何成功运行备用设备。

3. 涉及涉密数据，确定恢复方法时应遵循相应的保密要求。

1.6.5.2 恢复信息系统

1. 按照系统的初始化安全策略恢复系统。

2. 恢复系统时，应根据系统中各子系统的重要性，确定系统恢复的顺序。

3. 恢复系统过程宜包含但不限于以下方面：

² 利用正确的备份恢复用户数据和配置信息；

² 开启系统和应用服务，将受到入侵或者怀疑存在漏洞而关闭的服务修改后重新开放；

² 连接网络，服务重新上线，并持续监控、持续汇总分析，了解各网的运行情况。

4. 当不能彻底恢复配置和清除系统上的恶意文件，或不能肯定系统在根除处理后是否已恢复正常时，应选择彻底重建系统。

5. 协助用户验证恢复后的系统是否正常运行。

6. 帮助用户对重建后的系统进行安全加固。

7. 帮助用户为重建后的系统建立系统快照和备份。

1.6.6 总结阶段

目标：通过以上各个阶段的记录表格，回顾应急事件处理的全过程，整理与事件相关的各种信息，进行总结，并尽可能地把所有信息记录到文档中．

角色：应急服务实施小组、应急响应日常运行小组。

内容：包括以下几项．

² （l）事故总结；

² （2）事故报告。

输出：应急响应报告表．

1.6.6.1 事故总结

1. 及时检查应急事件处理记录是否齐全，是否具备可塑性，并对事件处理过程进行总结和分析。

2. 应急处理总结的具体工作包括但不限于以下几项：

² 事件发生的现象总结；

² 事件发生的原因分析；

² 系统的损害程度评估；

² 事件损失估计；

² 采取的主要应对措施；

² 相关的工具文档（如专项预案、方案等）归档。

1.6.6.2 事故报告

² 向用户提供完备的网络应急事件处理报告；

² 向用户提供措施和建议。

1.7 各类应急事件处理预案

1.7.1 设备发生被盗或人为损害事件应急预案 

发生设备被盗或人为损害设备情况时，运维人员或使用人员应立即报告应急领导小组，同时保护好现场。

应急领导小组接报后，通知用户保卫部门、相关领导，一同核实审定现场情况，清点被盗物资或盘查人为损害情况，做好必要的影像记录和文字记录。

用户单位和当事人应当积极配合公安部门进行调查， 并将有关情况向应急领导小组汇报。

应急领导小组安排运维服务小组、用户单位及时恢复系统正常运行，并对事件进行调查。运维服务小组和用户单位应在调查结束后一日内书面报告应急领导小组。事态或后果严重的，应向相关领导汇报。

1.7.2  通信网络故障应急预案 

发生通信线路中断、路由故障、流量异常、域名系统故障后，运维人员经初步判断后，应及时上报运维服务小组和应急领导小组。

运维服务小组接报告后，应及时查清通信网络故障位置，隔离故障区域，并将事态及时报告应急领导小组，通知相关通信网络运营商查清原因；同时及时组织相关技术人员检测故障区域，逐步恢复故障区与服务器的网络联接，恢复通信网络，保证正常运转。

事态或后果严重的，应向应急指挥办公室和相关领导汇报。

应急处置结束后，运维服务小组应将故障分析报告，在调查结束后一日内书面报告应急领导小组。

1.7.3 不良信息和网络病毒事件应急预案 

发现不良信息或网络病毒时，运维人员应立即断开网线，终止不良信息或网络病毒传播，并报告运维服务小组和应急领导小组。

运维服务小组应根据应急领导小组指令，采取隔离网络等措施，及时杀毒或清除不良信息，并追查不良信息来源。

事态或后果严重的，应向相关领导汇报。

处置结束后 ,运维服务小组应将事发经过、造成影响、处置结果在调查工作结束后一日内书面报告应急领导小组。

1.7.4 服务器软件系统故障应急预案 

发生服务器软件系统故障后，运维服务小组负责人应立即组织启动备份服务器系统，由备份服务器接管业务应用，并及时报告应急领导小组；同时安排相关责任人将故障服务器脱离网络，保证系统状态不变，取出系统镜像备份磁盘，保持原始数据。

运维服务小组应根据应急领导小组的指令，在确认安全的情况下，重新启动故障服务器系统；重启系统成功，则检查数据丢失情况，利用备份数据恢复；若重启失败，立即联系相关厂商和上级单位，请求技术支援，作好技术处理。

事态或后果严重的，应向应急领导小组汇报。

处置结束后,运维服务小组应将事发经过、处置结果等在调查工作结束后一日内报告应急领导小组。

1.7.5 黑客攻击事件应急预案 

当发现网络被非法入侵、网页内容被篡改，应用服务器上的数据被非法拷贝、修改、删除，或通过入侵检测系统发现有黑客正在进行攻击时，运维人员或系统管理员应断开网络，并立即报告应急领导小组。

接报告后，应急领导小组应立即指令运维服务小组核实情况，关闭服务器或系统，修改防火墙和路由器的过滤规则，封锁或删除被攻破的登陆账号，阻断可疑用户进入网络的通道。

运维服务小组应及时清理系统，恢复数据、程序，恢复系统和网络正常；情况严重的，应向应急领导小组汇报，并请求支援。

处置结束后 ,运维服务小组应将事发经过、处置结果等在调查工作结束后一日内报告应急领导小组。

1.7.6 核心设备硬件故障应急预案 

发生核心设备硬件故障后，运维服务小组应及时报告应急领导小组，并组织查找、确定故障设备及故障原因，进行先期处置。

若故障设备在短时间内无法修复运维服务小组应启动备份设备，保持系统正常运行；将故障设备脱离网络，进行故障排除工作。

运维服务小组故障排除后，在网络空闲时期，替换备用设备；若故障仍然存在，立即联系相关厂商，认真填写设备故障报告单备查。

事态或后果严重的，应向应急领导小组汇报。

处置结束后 ,运维服务小组应将事发经过、处置结果等在调查工作结束后一日内报告应急领导小组。

1.7.7 业务数据损坏应急预案 

发生业务数据损坏时，运维服务小组应及时报告应急领导小组，检查、备份业务系统当前数据。

运维服务小组负责调用备份服务器备份数据，若备份数据损坏，则调用磁带机中历史备份数据，若磁带机数据仍不可用，则调用异地备份数据。

业务数据损坏事件超过 2小时后，运维服务小组应及时报告应急领导小组，及时通知业务部门以手工方式开展业务。

运维服务小组应待业务数据系统恢复后，检查历史数据和当前数据的差别，由相关系统业务员补录数据；重新备份数据，并在工作结束后一日内报告应急领导小组。

1.8 
应急事件响应建议

1.8.1 应急事件现场处理

系统应急事件现场处理方案选择一般有以下几种方式。

1. 紧急消除

应急事件处理最核心的问题是消除当前威胁，主要是指消除应急事件的原因。如果应急事件属于计算机病毒，用杀毒软件进行消除。

如果应急事件属入侵者，应当首先对入侵者进行监视、跟踪，确定入侵行为的痕迹并消除之（例如新账号和被监控文件被修改），然后利用完整性检查工共进行检查，最后摆脱入侵者。

2. 紧急恢复

恢复系统可以采取现场联机恢复和关闭网络连接恢复两种方法。

一旦攻击发生，如果不能采取关机和关闭网络连接的措施，就采取现场联机恢复。

3. 切换

如果采用了双机备份的系统结构，可以采用联机切换方式，先切换再恢复。

4. 监视

发现入侵者后，监视入侵者的行为是必要的．监视时，可采用系统服务了解攻击者使用了哪个进程，监视网络出入的情况，采用它机监视的方法，要注意反监视问题的处理。

应急事件发生时要记录事件现场。在记录应急事件时，要记录平件的每一环节，包括事件的时间、地点。要打印拷贝、记录拷贝时间、记录对话内容，并尽可能采用自动化的记录方法。

5. 报警

攻击自动发现系统可发现攻击行为，并为系统管理员和信息系统安全员发出报警信号。报警可以通过声音、e-mail、手机、电话等方式表现。

1.8.2 应急事件的事后处理

系统应急事件事后处理包括事件后消除，弥补系统脆弱性，分析原因，总结教训，完善安全策略，服务和过程。

1. 事件后消除

消除威胁是应急事件处理最核心的问题，主要是指消除应急事件的原因。

如果应急事件的原因是厂商的后门软件、间谍软件，不管厂商以什么目的采用了这些软件，只要断定这些所谓后门软件可以被攻击者利用，需要向厂商提出交涉，消除该软件或关闭厂商保留的端口。

如果应急事件的原因是程序化入侵，则删除入侵程序。

如果应急事件的原因是破坏和删除文件，则使用拷贝文件恢复。

2. 弥补系统脆弱性

当发现网络系统漏洞时，修补操作是必需的。修补的方法包括包装程序、代理程序、隐藏程序、控制程序和改正程序错误等。

应急事件的发生暴露了信息系统的脆弱性。发现漏洞后可以提出修补漏洞的方法，实施修补过程。

3. 分析原因

应急事件的原因分析是必要的，分析清楚原因，提出改进的办法。

4. 总结教训

根据应急事件的损失和后果，处罚或批评负有责任者。通过对应急事件的处理，可明确在安全管理方面的缺陷，有针对性地加强和完善管理制度。

5. 完善安全策略、结构、服务和过程

发生应急事件后，对信息系统的安全策略、安全结构、安全服务和过程进行全面的检查，并对其进行修改和完善。

6. 系统应急事件责任划分

明确系统应急事件的责任。攻击成功往往与系统管理员的工作失误有关。由于系统管理员、信息系统安全员和操作员对信息系统安全都有自己的职责，要检查有关人员的失职问题。

有些应急事件的发生与安全结构不合理有关，或是信息系统安全措施落后造成的。

1.8.3 应急保障措施

1. 应急人力保障

加强信息安全人才培养，强化信息安全宣传教育，建设一支高素质、高技术的信息安全核心人才和管理队伍，提高信息安全防御意识。

2. 物质条件保障

安排一定的资金用于预防或应对信息安全应急事件，提供必要的交通运输保障，优化信息安全应急处理工作的物资保障条件。

3. 技术支撑保障

设立信息安全应急响应中心，建立预警与应急处理的技术平台，进一步提高应急事件的发现和分析能力。从技术上逐步实现发现、预警、处置、通报等多个环节和不同的网络、系统、部门之间应急处理的联动机制。

1.8.4 应急体系完善

以往的应急管理体系主要以经验式、运动式的模式为主，难以适应日益严峻的信息安全形势的发展。一个组织机构信息安全应急体系建设的关键是通过有计划地开展科学完善的应急体系与机制建设，把原来以应急处置为重点的被动应急管理模式，逐步转变为强调事前防灾，以应急准备为核心的主动应急管理模式。通过建设科学完善的信息安全应急体系及机制，不断提高对于应急能力，即“主动式”应急理念。

1. 应急预案体系

应急预案体系建设是一个组织应急工作的基础，应按照“结构完整、层次清晰、上下统一、内外衔接、覆盖全面”的要求，计划开展应急预案体系建设，形成“横向到边、纵向到底、上下对应、内外衔接”的应急预案休系，预案内容实用、可操作性强，涵盖自然灾害、事故灾难、社会安全等3类信息安全应急事件。

组织的应急预案体系由总体应急预案、专项应急预案和现场处置方案构成。其中，总体应急预案是应急预案体系的总纲，是组织机构应对各类应急事件的总体方案。专项应急预案是针对具体的信息安全应急事件、危险源和应急保障制定的方案；现场处置方案是针对特定的场所、设备设施、岗位，针对典型的信息安全应急事件，制定的处置流程和措施。

2. 应急培训演练

为了更好地落实应急预案中的整体工作流程、各项工作内容，在信息安全突发事发生后能够做到即刻响应、有序处理、立即恢复，需要通过定期培训的方式提高人员的应急处置能力，将信息应急事件对业务系统带来的损失降到最低，对此，可以成立应急培训基地，编制应急培训教材，定期组织开展信息安全应急理论讲座和技能培训。培训内容可以包括应急管理人员的组织协调、资源调配、信息汇报等应急处置技能，企业应急抢险队员、一般管理人员、生产人员的应急抢险意识和技能等。组织开展特定应急课题研究，结合信息系统安全运行事件进行分析，开展各种规模、形式的应急演练，构建适合并具有相应组织机构特点的应急支撑体系。

3. 应急队伍能力

应急队伍是应急体系建设的重要组成部分，是防范和应对信息安全应急事件的主要力量。为提升应急队伍的综合实力，依托现有的专业队伍，整合各类专业的技术力量，组建并不断完善各类信息应急事件应急响应队伍，且配备专业设备和资源，并加强培训和演练。

应急队伍的人员构成和设备、资源配置要符合主辅专业搭配、内外协调并重、理论和技能兼备等适应各种信息安全应急事件状态的应急要求。应急队伍成员在履行岗位职责、参加本单位正常生产经营活动或运行维护工作的同时，应按照信息应急事件应急队伍工作计划安排，定期参加技能培训、设备保养和预案演练等活动。应急事件发生后．由应急队伍统一集中处置，直至应急处置结束，业务恢复正常。

加强专家队伍管理，建立专家参与应急工作的长效机制。建设和完善应急专家信息库，邀请内外部专业人员，形成专家资源共享机制，为组织机构信息安全应急事件应急响应工作提供决策建议、专业咨询、理论指导和技术支持。