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

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. 应急队伍能力

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

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

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