《应急响应服务方案（上）》2023-11-10

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

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

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

² 应急预案的详细制订；

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

1.1 应急响应原则

实时原则

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

规范性原则

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

最小性原则

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

保密性原则

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

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.2 组织人员准备内容

制订工作方案和计划；

提供人员和物质保证；

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

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

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

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

1.6.3 技术人员准备内容

1. 服务需求界定

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

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

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

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

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

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

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

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

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

日志及审核策略快照；

用户账户快照；

进程快照；

服务快照；

自启动快照；

关键文件签名快照；

开放端口快照；

系统资源利用率的快照；

注册表快照；

计划任务快照等；

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

路由器快照；

安全设备快照；

用户快照；

系统资源利用率等快照。

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

3. 工具包的准备

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

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

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

4. 必要技术的准备

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

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

Windows系统检测技术规范；

UNIX系统检测技术规范；

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

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

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

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

异常行为分析技术；

入侵检测技术；

安全风险评估技术；

攻击追踪技术。

现场取样技术。

系统安全加固技术。

攻击隔离技术。

资产备份恢复技术。

1.6.4 检测阶段

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

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

内容：包括以下几项。

检测范围及对象的确定；

检测方案的确定；

检测方案的实施；

检测结果的处理；

1.6.5 实施小组人员的确定

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

1.6.6 检测范围及对象的确定

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

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

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

1.6.7 检测方案的确定

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

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

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

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

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

1.6.8 检测方案的实施

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

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

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

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

主机检测

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

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

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

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

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

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

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

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

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