应急响应服务方案.docx
《应急响应服务方案.docx》由会员分享，可在线阅读，更多相关《应急响应服务方案.docx（27页珍藏版）》请在冰豆网上搜索。
应急响应服务方案
应急响应服务方案
随着网络信息化建设的不断深入，加强各类设备、系统以及信息与网络安全等方面应对应急事件的处理能力将是运维项目面临的一项重要任务。
为确保系统及机房安全与稳定，以保证正常运行为宗旨，按照“预防为主，积极处置”的原则，本着建立一个有效处置应急事件，建立统一指挥、职责明确运转有序、反应迅速处置有力的安全体系的目标，将正在发生或已发生事故的损害程度减轻到最低，确保系统和数据安全，特制定本应急保障方案。
在应急事件发生时，通过应急事件处置与应急响应机制，保障计算机信息系统继续运行或紧急恢复，可归纳为3个方面：
✧紧急事件或安全发生时的影响分析；
✧应急预案的详细制订；
✧应急预案的演练与完善。
1.1应急响应原则
◆实时原则
应急响应服务中心配备了7X24的人员值班机制，保证接受客户在任意时间提出的服务请求。
并在接到客户的服务请求以后，在1个小时之给予响应。
◆规性原则
对于每一次应急事件的发生都有严格的事件记录，记录事件处理的全部过程，对于现场处理事件由用户签署认可建议。
◆最小性原则
事件处理过程中，将事件对整个系统的影响降低到最小，强化处理前的分析与备份工作。
◆性原则
对于所有事件的处理容、时间、地点，严格遵从原则，不向任何的第三方透漏。
1.2应急处理原则
1.预防为主。
立足安全防护，加强预警，重点保护基础信息网络和信息系统安全、稳定，从预防、监控、应急处理、应急保障等环节，在管理、技术、人员等方面采取多种措施充分发挥各方面的作用，共同构筑安全保障体系。
2.快速反应。
应急事件发生时，按照快速反应机制，及时获取充分而准确的信息，跟踪研判，果断决策，迅速处置，最大程度地减少危害和影响。
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事故报告
✧向用户提供完备的网络应急事件处理报告；
✧向用户提供措施和建议
升级会员 