应急响应服务方案

1、应急响应服务方案目录应急响应原则错误 !未定义书签。应急处理原则错误 !未定义书签。应急响应服务错误 !未定义书签。应急事件的影响程度错误 !未定义书签。应急事件的影响级别分类错误 !未定义书签。应急事件的优先级处理错误 !未定义书签。应急事件响应 应急响应保障措施 应急响应组织保障 组织机构与职责 组织的外部协作 应急响应流程错误 !未定义书签。错误 !未定义书签。 错误 !未定义书签。 错误 !未定义书签。 错误 !未定义书签。 错误 !未定义书签。准备阶段错误 !未定义书签。检测阶段错误 !未定义书签。抑制阶段错误 !未定义书签。根除阶段错误 !未定义书签。恢复阶段错误 !未定义书签。总

2、结阶段错误 !未定义书签。各类应急事件处理预案错误 !未定义书签。设备发生被盗或人为损害事件应急预案错误 !未定义书签。通信网络故障应急预案错误 !未定义书签。不良信息和网络病毒事件应急预案错误 !未定义书签。服务器软件系统故障应急预案错误 !未定义书签。黑客攻击事件应急预案错误 !未定义书签。核心设备硬件故障应急预案错误 !未定义书签。应急体系完善错误 !未定义书签。业务数据损坏应急预案 应急事件响应建议 应急事件现场处理 应急事件的事后处理错误 !未定义书签。 错误 !未定义书签。 错误 !未定义书签。 错误 !未定义书签。应急保障措施错误 ! 未定义书签。随着网络信息化建设的不断深入，

3、加强各类设备、 系统以及信息与网络安全等方面应对应急 事件的处理能力将是运维项目面临的一项重要任务。 为确保系统及机房安全与稳定， 以保证 正常运行为宗旨，按照 “预防为主，积极处置 ”的原则，本着建立一个有效处置应急事件，建 立统一指挥、 职责明确运转有序、 反应迅速处置有力的安全体系的目标， 将正在发生或已发 生事故的损害程度减轻到最低，确保系统和数据安全，特制定本应急保障方案。 在应急事件发生时， 通过应急事件处置与应急响应机制， 保障计算机信息系统继续运行或紧 急恢复，可归纳为 3 个方面： 紧急事件或安全发生时的影响分析； 应急预案的详细制订； 应急预案的演练与完善。应急响应原则 实

4、时原则 应急响应服务中心配备了 7X24的人员值班机制，保证接受客户在任意时间提出的服务请求。 并在接到客户的服务请求以后，在 1 个小时之内给予响应。规范性原则 对于每一次应急事件的发生都有严格的事件记录， 记录事件处理的全部过程， 对于现场处理 事件由用户签署认可建议。最小性原则 事件处理过程中，将事件对整个系统的影响降低到最小，强化处理前的分析与备份工作。 保密性原则 对于所有事件的处理内容、时间、地点，严格遵从保密原则，不向任何的第三方透漏。 应急处理原则 预防为主。立足安全防护，加强预警，重点保护基础信息网络和信息系统安全、稳定，从预 防、监控、应急处理、应急保障等环节，在管理、技术

5、、人员等方面采取多种措施充分发挥 各方面的作用，共同构筑安全保障体系。快速反应。应急事件发生时，按照快速反应机制，及时获取充分而准确的信息，跟踪研判， 果断决策，迅速处置，最大程度地减少危害和影响。分级负责。按照 “谁主管，谁负责 ”的原则，建立和完善安全责任制及联动工作机制。根据各 负责人的职能， 各司其职， 加强各负责人的协调与配合， 共同履行应急处置工作的管理职责。 以人为本。把保障人员以及客户利益的安全作为首要任务。常备不懈。 加强技术储备，规范应急处置措施与操作流程，定期进行预案演练，确保应急预 案切实有效，实现网络与信息安全突发公共事件应急处置的科学化、程序化与规范化。应急响应服务

6、应急事件响应， 是当应急事件发生后迅速采取的措施和行为， 其目的是以最快的速度恢复系 统的保密性，完整性和可用性，降低应急事件对业务系统造成的损失。针对运维服务项目，除有驻场工程师进行日常巡检和维护的工作外，还成立信息系统运维 4S组，提供应急响应服务。当设备、软件和基础网络出现故障时，原则上由驻场运维工程 现场解决， 如果现场服务工程无法解决， 事件升级为后台技术支持团队解决。 保障在 1 小时 内做出明确响应和安排， 2小时内提供诊断报告和故障解决方案。同时， 根据客户的具体情况，制定和编写信息系统应急预案， 保障客户信息系统的可靠，安 全的运行。应急事件的影响程度通常在事件爆发的初期很难

7、界定事件的起因具体是什么，所以， 通常又通过安全威胁事件的影响程度分为单点损害、局部损害和整体损害3 类。单点损害：只造成独立个体的不可用，应急事件影响程度弱。 局部损害：造成某一系统或一个局部网络不可使用，应急事件影响程度较强。 整体损害：造成整个网络系统的不可使用，应急事件影响程度强。应急事件的影响级别分类确定事件影响程度的级别。 不同的威胁级别， 处理方法也不相同。 根据对业务系统的影响程 度从大到小的顺序将应急事件划分成 4 个等级。第一级应急事件 P1 引起重要业务系统或有重要影响的应用系统宕机， 系统重新引导后无 法正常工作与恢复的事故，或造成安全泄密事件；第二级应急事件 P2 重

8、复发生或重复再现的并产生较强影响作用， 导致系统正常运行的事 故；第三级应急事件 P3 间歇产生、随机产生的事故，但不影响系统的正常运行； 第四级应急事件 P4 一般性事件， 与业务系统运行或产品使用要关的问题， 不影响整个系 统的正常运行。应急事件的优先级处理 事件处理要素 事件处理要素分为管理层面和技术层面； P1、P2 级事件的启动和指挥由应急总负责人负责；P3、P4级事件的启动应急领导小组负责。事件动态由应急工作小组人员收集并及时反馈给 应急领导小组，应急领导小组决定信息的共享、沟通、处置。信息系统事件发生后，事发部 门立即启动相关应急预案，实施处置并及时报送信息。分级响应发生P1、P

9、2级事件，由应急工作小组初步判定事件级别后，将信息通知应急领导小组并注意持续监控事态、收集信息、做出应急准备；应急领导小组响应判断为P1、P2级事件后，立即通知应急总负责人，并由应急总负责人启动应急预案。发生P3、P4级事件，由应急工作小组初步判定事件级别后，将信息通知应急领导小组并注意持续监控事态、收集信息、做出应急准备；应急领导小组响应判断为P3、P4级事件后，立即启动应急预案。应急事件的级别应置于动态调整控制中。指挥与协调P1、P2级事件，由应急工作小组收集信息，应急领导小组做出预判，并迅速通知应急总负 责人，由应急总负责人进行指挥和决策。P3、P4级事件，由应急领导小组进行指挥和决策，

10、并及时将处理过程、报告等上报应急总 负责人。信息共享和处理P1、P2级事件，由应急工作小组收集信息并提交给应急领导小组和应急总负责人，由应急 总负责人决定信息的分发、共享和处置。P3、P4级事件，由应急领导小组决定信息的分发、共享和处置，并上报应急总负责人。 应急事件响应 当客户系统发生紧急事件时，对应的处理方法原则是首先保护或恢复计算机、网络服务等， 使其恢复正常运行， 然后再对事件进行追查 因此对于客户紧急事件响应服务主要包括准备、 识别事件（判定应急事件类型） 、抑制（缩小事件的影响范围） 、解决问题、恢复以及后续跟 踪。准备工作；建立客户事件档案； 与客户就故障级别进行定义； 准备应急

11、事件紧急响应服务相关资源； 为一个应急事件的处理取得管理方面支持； 组建事件处理队伍；提供易实现的初步报告；制定一个紧急后备方案； 随时与管理员保持联系； 识别事件；在指定时间内指派安全服务小组去负责此事件； 事件抄送专家小组；初步评估，确定事件原因； 保护可追查的线索，诸如立即对日志、数据进行备份； 联系客户系统的相关服务商、厂商；缩小事件的影响范围； ； 确定系统继续运行的风险，决定是否关闭系统及采取其他措施； 与客户相关工作人员保持联系、协商；根据需求制订相应的应急措施；解决问题； 事件的起因分析； 事后取证调查； 后门检查； 漏洞分析；提供解决方案； 结果提交专家小组审核； 后续工作；

12、检查是不是所有的服务都已经恢复； 其发生的原因是否已经处理； 应急响应步骤是否需要修改； 生成紧急响应报告；拟定一份事件记录和跟踪报告； 事件合并、录入信息知识库。应急响应保障措施工具保障 我们建立了一套专门用于应急响应工具库，保证提供应急响应服务的工程师一人一套工具； 为防止光盘损坏和丢失， 并将此工具库进行了多套备份； 同时指定了专业技术人员进行工具 库的管理与维护，包括工具的测试、版本升级与维护等。技术和人员保障 公司拥有一支技术精湛、专业、稳定的技术团队，多位在网络、主机、数据库、安全等多个 领域具体丰富的实践经验的资深工程师。公司指定技术专员整理技术经验和心得并录入知识信息数据库，

13、一方面供技术部定期组织培 训会议使用 （对典型案例进行分析和学习） ，另一方面供 TS 客服中心查询以电话远程技术指 导。公司建立了图书室， 图书室内目前拥有信息安全类、计算机应用类、网络管理类、 分级保护 相关资料与规范、等级保护相关资料与规范等方面书籍，以方便技术人员借阅。公司定期组织技术人员进行专项技术培训学习，并以考试的方法检查技术人员的掌握情况， 有针对性的对技术人员进行帮助和指导。公司鼓励员工报考知名厂商技术认证，进行更专业的技术学习，并在考试费用上给予报销。 交通保障紧急事件， 公司应急车辆保障， 可以保证在突发应急事件时能做出快速响应， 第一时间赶到 事件现场进行处置。财力保障

14、公司有专门的经费和审批流程， 确保在应急响应处理过程中需要的款项能迅速到位， 保障应 急事件的处理和故障恢复。应急响应组织保障 组织机构与职责 针对项目，我公司成立专门应急处置小组，包含：应急领导小组和应急工作小组。应急领导小组 应急领导小组是信息安全应急响应工作的组织领导机构，组长由组织最高管理层成员担任。 职责是统一领导信息系统的应急事件的公司内部应急处理工作， 发起研究重大应急决策和部 署，决定实施和终止应急预案，领导和决策信息安全应急响应的重大事宜，主要职责如下： 制订工作方案；提供人员和物质保证；审核并批准经费预算；审核并批准恢复策略； 审核并批准应急响应计划； 批准并监督应急响应计

15、划的执行； 指导应急响应实施小组的应急处置工作； 启动定期评审、修订应急响应计划以及负责组织的外部协作。应急工作小组 应急工作小组由运维服务小组人员组成， 主要职责包含： 落实应急领导小组布置的各项任务； 组织制定应急预案， 并监督执行情况； 掌握应急事件处理情况， 及时向应急领导小组报告应 急过程中的重大问题。具体职责如下：编制应急响应计划文档； 应急响应的需求分析，确定应急策略和等级以及策略的实现； 备份系统的运行和维护，协助灾难恢复系统实施； 信息安全应急事件发生时的损失控制和损害评估；组织应急响应计划的测试和演练。 组织的外部协作依据信息应急事件的影响程度， 如需向其他第三方设备供应商

16、或软件开发商寻求支持时， 将 联系第三方服务单位提供协作和技术支持。应急响应流程应急响应流程共包括 6 个阶段，分别是准备阶段、检测阶段、抑制阶段、根除阶段、恢复阶 段、总结阶段。 应急响应流程如下图所示，对于每个阶段都有其应完成的目标、实施人员角 色以及阶段的结果输出。准备阶段 目标：在事件真正发生前为应急响应做好预备性的工作。角色：组织人员，技术人员内容：根据不同角色准备不同的内容。编出：准备工具清单、事件初步报告表和实施人员工作清单。组织人员准备内容制订工作方案和计划；提供人员和物质保证；审核并批准经费预算、恢复策略、应急响应计划；批准并监督应急响应计划的执行；指导应急响应实施小组的应急

17、处置工作；启动定期评审、修订应急响应计划以及负责组织的外部协作。 技术人员准备内容服务需求界定首先要对整个信息系统进行评估，明确应急需求，具体应包含以下内容： 了解各项业务功能及其之间的相关性，确定支持各种业务功能的相关信息系统资源及其他资源，明确相关信息的保密性、完整性和可用性要求；对信息系统，包括应用程序、服务器、网络及任何管理和维护这些系统的流程进行评估，确 定系统所执行的关键功能，并确定执行这些关键功能所需要的特定系统资源； 采用定性或定量的方法， 对业务中断、系统宕机、网络瘫痪等应急事件造成的影响进行评估； 协助客户建立适当的应急响应策略，提供在业务中断、系统宕机、网络瘫痪等应急事件

18、发生后快速有效的恢复信息系统运行的方法；为用户提供相关的培训服务，以提高用户的安全意识， 便于相关责任人明确自己的角色和责任。了解常见的应急事件和入侵行为，熟悉应急响应策略。主机和网络设备安全初始化快照和备份在系统安全策略配置完成后，要对系统优生次初始安全状态快照。这样，如果以后出现事故后对该服务器做安全检测时，通过将初始化快照做的结果与检测阶段做的快照进行比较， 就能够发现系统的改动或异常。对主机系统做一个标准的安全初始化的状态快照，包括的主要内容有：日志及审核策略快照；用户账户快照；进程快照； 服务快照； 自启动快照； 关键文件签名快照； 开放端口快照；系统资源利用率的快照；注册表快照；计

19、划任务快照等；对网络设备做一个标准的安全初始化的状态，包括的主要内容有： 路由器快照；安全设备快照；用户快照； 系统资源利用率等快照。信息系统的业务数据及办公数据均十分重要， 因此需要进行数据存储及备份。 目前， 存储备 份结构主要有 DAS SAN和NAS,以及通过磁带或光盘对数据进行备份。可根据不同的特点 选择不同的存储产品构建自己的数据存储备份系统。工具包的准备根据用户的需求准备处置网络应急事件的工具包, 包括常用的系统基本命令、 其他软件工具 等；工具包中的工具采用绿色免安装的, 保存在安全的移动介质上, 如一次性可写光盘、 加密的 U 盘等；工具包应定期更新、补充。 必要技术的准备

20、上述是针对应急响应的处理涉及的安全技术工具涵盖应急响应的事件取样、事件分析、 事件隔离、 系统恢复和攻击迫踪等各个方面, 构成了网络安全应急响应的技术基础。 所以应急响 应服务实施成员还应该掌握一些必要的技术手段和规范,具体包括以下内容。系统检测技术,包括以下检测技术规范：Windows 系统检测技术规范； UNIX 系统检测技术规范； 网络安全牢固检测技术规范； 数据库系统检测技术规范； 常见的应用系统检测技术规范。 攻击检测技术包括以下技术 异常行为分析技术； 入侵检测技术； 安全风险评估技术； 攻击追踪技术。现场取样技术。 系统安全加固技术。攻击隔离技术。 资产备份恢复技术。检测阶段 目

21、标：接到事故报警后在用户的配合下对异常的系统进行初步分析,确认其是否真正发生了信息应急事件,并制订进一步的响应策略,并保留证据。 角色：应急服务实施小组成员、应急响应日常运行小组。内容：包括以下几项。 检测范围及对象的确定； 检测方案的确定； 检测方案的实施； 检测结果的处理； 实施小组人员的确定 应急响应负责人根据事件初步报告表的内容,初步分析事故的类型、严重程度等,以此 来确定应急响应小组的实施人员的名单。检测范围及对象的确定对发生异常的系统进行初步分析，判断是否真正发生了应急事件； 与用户共同确定检测对象及范围；检测对象及范围应得到用户的书面授权。检测方案的确定 与用户共同确定检测方案；

22、 制订的检测方案应明确所使用的检测规范； 制订的检测方案应明确检测范围，其检测范围应仅限于用户已授权的与应急事件相关的数 据，对用户的机密性数据信息未经允许不得访问； 制订的检测方案应包含实施方案失败的应变和回退措施； 与用户充分沟通，并预测应急处理方案可能造成的影响。检测方案的实施 检测搜集系统信息：记录使用目录及文件名约定。 搜集操作系统基本信息：包含网络连接信息、进程信息、 IP 属性、操作系统属性。 日志信息 :导出所有日志信息 账号信息 :导出所有账号信息 主机检测日志检查：从日志信息中检测出未授权访问或非法登录整件； 账号检查：检查账号信息中非正常账号、隐藏账号。 进程检查：检查是

23、否有未被授权的应用程序或服务。服务检查：检查系统是否存在非法服务。 自启动检查：检查未授权自启动程序。网络连接检查：检查非正常开放的端口。 共享检查：检查非法共享目录。文件检查：检查病毒、木马、蠕虫、后门等可疑文件。 查找其他入侵痕迹：查找其他系统上的入侵痕迹，寻找攻击途径。检测结果的处理 确定应急事件的类型 经过检测，判断出信息应急事件类型。信息应急事件有以下7 个基本分类。有害程序事件： 蓄意制造、 传播有害程序， 或是因受到有害程序的影响而导致的信息应急事 件。网络攻击事件：通过网络或其他技术手段，利用信息、系统的配置缺陷、协议缺陷、程序缺 陷或使用暴力攻击对信息系统实施攻击， 并造成信

24、息系统异常或对信息系统当前运行造成潜 在危害的信息应急事件。信息破坏事件： 通过网络或其他技术手段造成信息系统中的信息被篡改、假冒、泄露、 窃取 等而导致的信息应急事件。信息内容应急事件：泄漏危害国家安全、社会稳定和公共利益的内容的安全。设备设施故障： 由于信息系统自身故障或外围保障设施故障而导致的信息应急事件， 以及人 为的使用非技术手段有意或无意地造成信息系统破坏而导致的信息应急事件。 灾害性事件：由于不可抗力对信息系统造成物理破坏而导致的信息应急事件。其他信息应急事件：不能归入以上 6 个基本分类的信息应急事件。 评估突发信息应急事件的影响采用定量和 / 或定性的方法，对业务中断、系统宕

25、机、网络瘫痪、数据丢失等突发信息应急 事件造成的影响进行评估；确定是否存在针对该事件的特定系统预案， 如有， 则启动相关预案； 如果事件涉及多个专项 预案，应同时启动所有涉及的专项预案； 如果没有针对该事件的专项预案， 应根据事件具体情况， 采取抑制措施， 抑制事件进一步扩 散。抑制阶段目标： 及时采取行动限制事件扩散和影响的范围， 限制潜在的损失与破坏， 同时要确保封锁 方法对涉及相关业务影响最小。角色：应急服务实施小组、应急响应日常运行小组内容：包括以下儿项 抑制方案的确定； 抑制方案的认可； 抑制方案的实施； 抑制效果的判定。 输出：抑制处理记录表。抑制方案的确定在检测分析的基础上， 初

26、步确定与应急事件相对应的抑制方法， 如有多项， 可由用户考虑后 自己选择。在确定抑制方法时应该考虑： 全面评估应急事件的影响和损失； 通过分析得到的其他结论； 用户的业务和重点决策过程；用户的业务连续性。抑制方案的认可 告知用户所面临的首要问题； 确定的抑制方法和相应的措施得到用户的认可； 在采取抑制措施之前，与用户充分沟通， 告知可能存在的风险，制订应变和回退措施， 并与 其达成协议。抑制方案的实施严格按照相关约定实施抑制， 不得随意更改抑制的措施的范围， 如有必要更改， 须获得用户 的授权。抑制措施应包含但不限于以下几方而：确定受害系统的范围后， 将受害系统和正常的系统进行隔离， 断开或暂

27、时关闭被影响的系统， 使攻击先彻底停止；持续监视系统和网络活动，记录异常流量的远程IP、域名、端口；停止或删除系统非正常账号，隐藏账号，更改口令，加强口令的安全级别； 挂起或结束未被授权的、可疑的应用程序和进程； 关闭存在的非法服务和不必要的服务；删除系统各用户 “启动”目录下未授权自启动程序； 使用工具或命令停止所有开放的共享； 使用反病毒软件或其他安全工具检查文件， 扫描硬盘上所有的文件， 隔离或清除病毒、 木马、 蠕虫、后门等可疑文件；抑制效果的判定是否防止了事件继续扩散，限制了潜在的损失和破坏，使目前损失最小化； 对其他相关业务的影响是否控制在最小。根除阶段找出事件根源，明确目标：对应

28、急事件进行抑制之后，通过对有关事件或行为的分析结果， 相应的补救措施并彻底清除事件。角色：应急服务实施小组、应急响应日常运行小组. 内容：包括以下几项。根除方案的确定； 根除方案的认可； 根除方案的实施； 根除效果的判定。 输出：根除处理记录表。 根除方案的确定 协助用户检查所有受影响的系统，在准确判断应急事件原因的基础上，提出方案建议； 由于入侵者一般会安装后门或使用其他的方法以便于在将来有机会侵入该被攻击的系统，因此在确定根除方法时，需要了解攻击者是如何入侵的，以及与这种入侵方法相同和相似的各种方法。根除方案的认可明确告知用户所采取的根除措施可能带来的风险，制度应变和回退措施，并得到用户的

29、书面授权；协助用户进行根除方法的实施。根除方案的实施使用可信的工具进行应急事件的根除处理，不得使用受害系统已有的不可信的文件和工具。 根除措施宜包含但不限于以下几个方面：改变全部可能受到攻击的系统账号和口令，并增加口令的安全级别； 修补系统、网络和其他软件漏洞；增强防护功能，复查所有防护措施的配置，安装最新的安全设备和杀毒软件，并及时更新， 对未受保护或者保护不够的系统增加新的防护措施；提高其监视保护级别，以保证将来对类似的入侵进行检测。 根除效果的判定找出造成事件的原因，备份与造成事件相关的文件和数据； 对系统中造成事件的文件进行清理，根除； 使系统能够正常工作。恢复阶段目标：恢复应急事件所

30、涉及的系统， 并还原到正常状态， 使业务能够正常进行，恢复工作应 避免出现误操作导致数据的丢失。角色：应急服务实施小组、应急响应日常运行小组。内容：包括以下儿项。 恢复方案的确定； 恢复信息系统。输出：恢复处理记录表。 恢复方案的确定 告知用户一个或多个能从应急事件中恢复系统的方法，及它们可能存在的风险。 和用户共同确定系统恢复方案，根据抑制和根除的情况， 协助用户选择合适的系统恢复的方案，恢复方案涉及以下几方面： 如何获得访问受损设施或地理区域的授权； 如何通知相关系统的内部和外部业务伙伴； 如何获得安装所需的硬件部件；如何获得装载备份介质，如何恢复关键操作系统和应用软件； 如何恢复系统数据

31、；如何成功运行备用设备。 涉及涉密数据，确定恢复方法时应遵循相应的保密要求。恢复信息系统 按照系统的初始化安全策略恢复系统。 恢复系统时，应根据系统中各子系统的重要性，确定系统恢复的顺序。 恢复系统过程宜包含但不限于以下方面：利用正确的备份恢复用户数据和配置信息； 开启系统和应用服务，将受到入侵或者怀疑存在漏洞而关闭的服务修改后重新开放； 连接网络，服务重新上线，并持续监控、持续汇总分析，了解各网的运行情况。 当不能彻底恢复配置和清除系统上的恶意文件， 或不能肯定系统在根除处理后是否已恢复正 常时，应选择彻底重建系统。协助用户验证恢复后的系统是否正常运行。 帮助用户对重建后的系统进行安全加固。

32、帮助用户为重建后的系统建立系统快照和备份。总结阶段目标： 通过以上各个阶段的记录表格， 回顾应急事件处理的全过程， 整理与事件相关的各种 信息，进行总结，并尽可能地把所有信息记录到文档中角色：应急服务实施小组、应急响应日常运行小组。 内容：包括以下几项（l）事故总结；（ 2 ）事故报告。输出：应急响应报告表事故总结及时检查应急事件处理记录是否齐全， 是否具备可塑性， 并对事件处理过程进行总结和分析。 应急处理总结的具体工作包括但不限于以下几项：事件发生的现象总结；事件发生的原因分析； 系统的损害程度评估； 事件损失估计； 采取的主要应对措施； 相关的工具文档（如专项预案、方案等）归档。事故报告

33、向用户提供完备的网络应急事件处理报告； 向用户提供措施和建议。各类应急事件处理预案 设备发生被盗或人为损害事件应急预案 发生设备被盗或人为损害设备情况时， 运维人员或使用人员应立即报告应急领导小组， 同时 保护好现场。应急领导小组接报后，通知用户保卫部门、相关领导，一同核实审定现场情况，清点被盗物 资或盘查人为损害情况，做好必要的影像记录和文字记录。用户单位和当事人应当积极配合公安部门进行调查， 并将有关情况向应急领导小组汇报。 应急领导小组安排运维服务小组、 用户单位及时恢复系统正常运行， 并对事件进行调查。 运 维服务小组和用户单位应在调查结束后一日内书面报告应急领导小组。事态或后果严重的

34、， 应向相关领导汇报。通信网络故障应急预案 发生通信线路中断、路由故障、流量异常、域名系统故障后，运维人员经初步判断后，应及 时上报运维服务小组和应急领导小组。运维服务小组接报告后， 应及时查清通信网络故障位置， 隔离故障区域， 并将事态及时报告 应急领导小组， 通知相关通信网络运营商查清原因； 同时及时组织相关技术人员检测故障区 域，逐步恢复故障区与服务器的网络联接，恢复通信网络，保证正常运转。 事态或后果严重的，应向应急指挥办公室和相关领导汇报。应急处置结束后， 运维服务小组应将故障分析报告， 在调查结束后一日内书面报告应急领导 小组。不良信息和网络病毒事件应急预案 发现不良信息或网络病毒

35、时， 运维人员应立即断开网线， 终止不良信息或网络病毒传播， 并 报告运维服务小组和应急领导小组。运维服务小组应根据应急领导小组指令，采取隔离网络等措施，及时杀毒或清除不良信息， 并追查不良信息来源。事态或后果严重的，应向相关领导汇报。处置结束后 ,运维服务小组应将事发经过、 造成影响、处置结果在调查工作结束后一日内书 面报告应急领导小组。服务器软件系统故障应急预案发生服务器软件系统故障后， 运维服务小组负责人应立即组织启动备份服务器系统， 由备份 服务器接管业务应用， 并及时报告应急领导小组； 同时安排相关责任人将故障服务器脱离网 络，保证系统状态不变，取出系统镜像备份磁盘，保持原始数据。

36、运维服务小组应根据应急领导小组的指令， 在确认安全的情况下， 重新启动故障服务器系统； 重启系统成功， 则检查数据丢失情况，利用备份数据恢复；若重启失败，立即联系相关厂商 和上级单位，请求技术支援，作好技术处理。事态或后果严重的，应向应急领导小组汇报。处置结束后 ,运维服务小组应将事发经过、处置结果等在调查工作结束后一日内报告应急领 导小组。黑客攻击事件应急预案 当发现网络被非法入侵、网页内容被篡改，应用服务器上的数据被非法拷贝、修改、删除， 或通过入侵检测系统发现有黑客正在进行攻击时， 运维人员或系统管理员应断开网络， 并立 即报告应急领导小组。接报告后， 应急领导小组应立即指令运维服务小组

37、核实情况， 关闭服务器或系统， 修改防火 墙和路由器的过滤规则，封锁或删除被攻破的登陆账号，阻断可疑用户进入网络的通道。 运维服务小组应及时清理系统，恢复数据、程序，恢复系统和网络正常；情况严重的，应向 应急领导小组汇报，并请求支援。处置结束后 ,运维服务小组应将事发经过、 处置结果等在调查工作结束后一日内报告应急领 导小组。核心设备硬件故障应急预案 发生核心设备硬件故障后， 运维服务小组应及时报告应急领导小组， 并组织查找、 确定故障 设备及故障原因，进行先期处置。若故障设备在短时间内无法修复运维服务小组应启动备份设备， 保持系统正常运行； 将故障 设备脱离网络，进行故障排除工作。运维服务小

38、组故障排除后，在网络空闲时期， 替换备用设备； 若故障仍然存在，立即联系相 关厂商，认真填写设备故障报告单备查。事态或后果严重的，应向应急领导小组汇报。处置结束后 ,运维服务小组应将事发经过、 处置结果等在调查工作结束后一日内报告应急领 导小组。业务数据损坏应急预案发生业务数据损坏时， 运维服务小组应及时报告应急领导小组， 检查、 备份业务系统当前数 据。运维服务小组负责调用备份服务器备份数据， 若备份数据损坏， 则调用磁带机中历史备份数 据，若磁带机数据仍不可用，则调用异地备份数据。业务数据损坏事件超过 2 小时后，运维服务小组应及时报告应急领导小组，及时通知业务 部门以手工方式开展业务。运

39、维服务小组应待业务数据系统恢复后， 检查历史数据和当前数据的差别， 由相关系统业务 员补录数据；重新备份数据，并在工作结束后一日内报告应急领导小组。应急事件响应建议应急事件现场处理 系统应急事件现场处理方案选择一般有以下几种方式。紧急消除应急事件处理最核心的问题是消除当前威胁， 主要是指消除应急事件的原因。 如果应急事件 属于计算机病毒，用杀毒软件进行消除。如果应急事件属入侵者， 应当首先对入侵者进行监视、 跟踪， 确定入侵行为的痕迹并消除之 （例如新账号和被监控文件被修改） ，然后利用完整性检查工共进行检查， 最后摆脱入侵者。 紧急恢复恢复系统可以采取现场联机恢复和关闭网络连接恢复两种方法。

40、 一旦攻击发生，如果不能采取关机和关闭网络连接的措施，就采取现场联机恢复。 切换如果采用了双机备份的系统结构，可以采用联机切换方式，先切换再恢复。 监视发现入侵者后， 监视入侵者的行为是必要的 监视时， 可采用系统服务了解攻击者使用了哪 个进程，监视网络出入的情况，采用它机监视的方法，要注意反监视问题的处理。 应急事件发生时要记录事件现场。 在记录应急事件时， 要记录平件的每一环节， 包括事件的 时间、 地点。要打印拷贝、 记录拷贝时间、 记录对话内容， 并尽可能采用自动化的记录方法。 报警攻击自动发现系统可发现攻击行为， 并为系统管理员和信息系统安全员发出报警信号。 报警 可以通过声音、 e

41、-mail 、手机、电话等方式表现。应急事件的事后处理 系统应急事件事后处理包括事件后消除， 弥补系统脆弱性，分析原因， 总结教训， 完善安全 策略，服务和过程。事件后消除 消除威胁是应急事件处理最核心的问题，主要是指消除应急事件的原因。如果应急事件的原因是厂商的后门软件、间谍软件，不管厂商以什么目的采用了这些软件， 只要断定这些所谓后门软件可以被攻击者利用， 需要向厂商提出交涉， 消除该软件或关闭厂 商保留的端口。如果应急事件的原因是程序化入侵，则删除入侵程序。 如果应急事件的原因是破坏和删除文件，则使用拷贝文件恢复。弥补系统脆弱性 当发现网络系统漏洞时， 修补操作是必需的。 修补的方法包括

42、包装程序、代理程序、隐藏程 序、控制程序和改正程序错误等。应急事件的发生暴露了信息系统的脆弱性。 发现漏洞后可以提出修补漏洞的方法， 实施修补 过程。分析原因 应急事件的原因分析是必要的，分析清楚原因，提出改进的办法。总结教训根据应急事件的损失和后果， 处罚或批评负有责任者。 通过对应急事件的处理， 可明确在安 全管理方面的缺陷，有针对性地加强和完善管理制度。完善安全策略、结构、服务和过程 发生应急事件后，对信息系统的安全策略、安全结构、安全服务和过程进行全面的检查，并 对其进行修改和完善。系统应急事件责任划分 明确系统应急事件的责任。攻击成功往往与系统管理员的工作失误有关。由于系统管理员、 信息系统安全员和操作员对信息系统安全都有自己的职责，要检查有关人员的失职问题。 有些应急事件的发生与安全结构不合理有关，或是信息系统安全措施落后造成的。应急保障措施 应急人力保障 加强信息安全人才培养， 强化信息安全宣传教育， 建设一支高素质、 高技术的信息安全核心 人才和管理队伍，提高信