网络安全应急响应服务方案怎么写？包含哪些阶段？一文带你了解！

一、服务范围及流程

1.1 服务范围

为采购人提供安全事件应急响应和处理服务，在发生信息破坏事件（篡改、泄露、窃取、丢失等）、大规模病毒事件、网站漏洞事件等信息安全事件时，提供应急响应专家协助处置。

1.2 服务流程及内容

该服务流程并非一个固定不变的教条， 需要应急响应服务人员在实际中灵活变通，可适当简化，但任何变通都必须纪录有关的原因。详细的记录对于找出事件的真相、查出威胁的来源与安全弱点、找到问题正确的解决方法，甚至判定事故的责任，避免同类事件的发生都有着极其重要的作用。

突发事件应急处理流程包括：

• 准备阶段（Preparation）
• 检测阶段（Examination）
• 抑制阶段（Suppresses）
• 根除阶段（Eradicates）
• 恢复阶段（Restoration）
• 总结阶段（Summary）。

如下图所示：

二、准备阶段

• 目标：在事件真正发生前为应急响应做好预备性的工作。
• 角色：技术人员、市场人员。
• 内容：根据不同角色准备不同的内容。
• 输出：《准备工具清单》、《事件初步报告表》、《实施人员工作清单》

2.1 负责人准备内容

• 制定工作方案和计划；
• 提供人员和物质保证；
• 审核并批准经费预算、恢复策略、应急响应计划；
• 批准并监督应急响应计划的执行；
• 指导应急响应实施小组的应急处置工作；
• 启动定期评审、修订应急响应计划以及负责组织的外部协作。

2.2 技术人员准备内容

（一）服务需求界定

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

• 应急响应小组应了解应急服务对象的各项业务功能及其之间的相关性，确定支持各种业务功能的相关信息系统资源及其他资源，明确相关信息的保密性、完整性和可用性要求；
• 对服务对象的信息系统，包括应用程序，服务器，网络及任何管理和维护这些系统的流程进行评估，确定系统所执行的关键功能，并确定执行这些关键功能所需要的特定系统资源；
• 应急响应小组采用定性或定量的方法，对业务中断、系统宕机、网络瘫痪等突发安全事件造成的影响进行评估；
• 应急响应小组协助服务对象建立适当的应急响应策略，应提供在业务中断、系统宕机、网络瘫痪等突发安全事件发生后快速有效的恢复信息系统运行的方法；
• 应急响应小组为服务对象提供相关的培训服务，以提高服务对象的安全意识，便于相关责任人明确自己的角色和责任，了解常见的安全事件和入侵行为，熟悉应急响应策略。

（二）主机和网络设备安全初始化快照和备份

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

• 对主机系统做一个标准的安全初始化的状态快照， 包括的主要内容有：
  • 日志及审核策略快照等。
  • 用户账户快照；
  • 进程快照；
  • 服务快照；
  • 自启动快照
  • 关键文件签名快照；
  • 开放端口快照；
  • 系统资源利用率的快照；
  • 注册表快照；
  • 计划任务快照等等；
• 对网络设备做一个标准的安全初始化的状态快照， 包括的主要内容有：
  • 路由器快照；
  • 防火墙快照；
  • 用户快照；
  • 系统资源利用率等快照。
• 信息系统的业务数据及办公数据均十分重要，因此需要进行数据存储及备份。目前，存储备份结构主要有DAS、SAN 和NAS，以及通过磁带或光盘对数据进行备份。各服务对象可以根据自身的特点选择不同的存储产品构建自己的数据存储备份系统。

工具包的准备：

• 应急服务提供者应根据应急服务对象的需求准备处置网络安全事件的工具包，包括常用的系统基本命令、其他软件工具等；
• 应急服务提供者的工具包中的工具最好是采用绿色免安装的， 应保存在安全的移动介质上，如一次性可写光盘、加密的U 盘等；
• 应急服务提供者的工具包应定期更新、补充；

必要技术的准备：

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

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

• Windows系统检测技术规范；
• Unix系统检测技术规范；
• 网络安全事故检测技术规范；
• 数据库系统检测技术规范；
• 常见的应用系统检测技术规范；

（2）攻击检测技术，包括以下技术：

• 异常行为分析技术；
• 入侵检测技术；
• 安全风险评估技术；

（3）攻击追踪技术；

（4）现场取样技术；

（5）系统安全加固技术；

（6）攻击隔离技术；

（7）资产备份恢复技术。

2.3市场人员准备内容

• 和服务对象建立长期友好的业务关系；
• 和服务对象签订应急服务合同或协议；
• 建立预防和预警机制，及时上报。

（1）预防和预警机制

• 市场人员要严格按照应急响应负责人的安排和建议，及时提醒服务对象提高防范网络攻击、病毒入侵、网络窃密等的能力，防止有害信息传播，保障服务对象网络的安全畅通。
• 将协会网络信息中心会发布的病毒预防警报以及更新的防护策略及时有效地告知服务对象，做好防护策略的更新。

（2）信息系统检测和报告

• 按照“早发现、早报告、早处置”的原则，市场人员要加强对服务对象信息系统的安全检测结果的通告，收集可能引发信息安全事件的有关信息、进行分析判断。
• 如服务对象发现有异常情况或有信息安全事件发生时，要立即向协会网络信息中心应急响应负责人报告，并填写事件初步报告表。
• 要求服务对象持续监测信息系统状况，密切关注应急响应负责人提出初步行动对策和行动方案，听从指令和安排，及时减小损失。

三、检测阶段

• 目标：接到事故报警后在服务对象的配合下对异常的系统进行初步分析，确认其是否真正发生了信息安全事件，制定进一步的响应策略，并保留证据。
• 角色：应急服务实施小组成员、应急响应日常运行小组；
• 内容：
  • 检测范围及对象的确定；
  • 检测方案的确定；
  • 检测方案的实施；
  • 检测结果的处理。
• 输出：《检测结果记录》

3.1 实施小组人员的确定

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

3.2 检测范围及对象的确定

• 应急服务提供者应对发生异常的系统进行初步分析，判断是否正真发生了安全事件；
• 应急服务提供者和服务对象共同确定检测对象及范围；
• 检测对象及范围应得到服务对象的书面授权。

3.3 检测方案的确定

• 应急服务提供者和服务对象共同确定检测方案；
• 应急服务提供者制定的检测方案应明确应急服务提供者所使用的检测规范 ；
• 应急服务提供者制定的检测方案应明确应急服务提供者的检测范围，其检测范围应仅限于服务对象已授权的与安全事件相关的数据，对服务对象的机密性数据信息未经授权的不得访问；
• 应急服务提供者制定的检测方案应包含实施方案失败的应变和回退措施；
• 应急服务提供者和服务对象充分沟通，并预测应急处理方案可能造成的影响。

3.4检测方案的实施

（1）检测搜集系统信息

记录时使用目录及文件名约定：

在受入侵的计算机的D盘根目录下（D:\）（如果无D盘则在其他盘根目录下）建立一个qihoo目录，目录中包含以下子目录：

• artifact：用于存放可疑文件样本
• cmdoutput：用于记录命令行输出结果
• screenshot：用于存放屏幕拷贝文件
• log：用于存放各类日志文件

文件格式：

• 命令行输出文件缺省仅使用TXT格式。
• 日志文件及其他格式尽量使用TXT、CSV和其他不需要特殊工具就可以阅读的格式。
• 屏幕拷贝文件应该使用JPG格式。
• 可疑文件样本最好加密压缩为zip格式，默认密码为：wljslmz

搜集操作系统基本信息

• 右键点击“我的电脑>属性” 将“常规”、“自动更新”、“远程”3 个选卡各制作一个窗口拷贝（使用 Alt+PrtScr ）。并保存到 qihoo\screenshot 目录下，文件名称应该使用：系统常规 -01、自动更新-01、远程-01 等形式命名。
• 进入 CMD 状态，“开始 > 运行 > cmd”，进入 D 盘根目录下的 wljslmz 目录，执行一下命令：

netstat -nao > netstat.txt (网络连接信息)
tasklist > tasklist.txt （当前进程信息）
ipconfig /all > ipconfig.txt（IP 属性）
ver > ver.txt （操作系统属性）
....................................

日志信息：

• 目标：导出所有日志信息；
• 说明：进入管理工具，将“管理工具 > 事件察看器”中，导出所有事件，分别使用一下文件名保存： application.txt、security.txt、system.txt。

帐号信息：

• 目标：导出所有帐号信息；
• 说明：使用 net user，net group，net local group 命令检查帐号和组的情况，使用计算机管理查看本地用户和组，将导出的信息保存在 D:\wljslmz\user中

（2）主机检测

日志检查：

• 目标：
  • 从日志信息中检测出未授权访问或非法登录事件；
  • 从IIS/FTP 日志中检测非正常访问行为或攻击行为；
• 说明：
  • 检查事件查看器中的系统和安全日志信息，比如：安全日志中异常登录时间，未知用户名登录；
  • 检查%WinDir%\System32\LogFiles 目录下的WWW 日志和FTP 日志，比如WWW 日志中的对shell.asp 文件的成功访问。

帐号检查：

• 目标：检查帐号信息中非正常帐号，隐藏帐号；
• 说明： 通过询问管理员或负责人， 或者和系统的所有的正常帐号列表做对比，判断是否有可疑的陌生的账号出现， 利用这些获得的信息和前面准备阶段做的帐号快照工作进行对比。

进程检查：

• 目标：检查是否存在未被授权的应用程序或服务
• 说明：使用任务管理器检查或使用进程查看工具进行查看，利用这些获得的信息和前面准备阶段做的进程快照工作进行对比，判断是否有可疑的进程。

服务检查：

• 目标：检查系统是否存在非法服务
• 说明：使用“管理工具”中的“服务”查看非法服务或使用360 安全卫士、Wsystem 察看当前服务情况，利用这些获得的信息和准备阶段做的服务快照工作进行对比。

自启动检查：

• 目标：检查未授权自启动程序
• 说明：检查系统各用户“启动”目录下是否存在未授权程序。

网络连接检查：

• 目标：检查非正常网络连接和开放的端口
• 说明：关闭所有的网络通讯程序，以免出现干扰，然后使用ipconfig,netstat –an 或其它第三方工具查看所有连接，检查服务端口开放情况和异常数据的信息。

共享检查

• 目标：检查非法共享目录。
• 说明：使用net share 或其他第三方的工具检测当前开放的共享，使用$是隐藏目录共享，通过询问负责人看是否有可疑的共享文件。

文件检查：

• 目标：检查病毒、木马、蠕虫、后门等可疑文件。
• 说明：使用防病毒软件检查文件，扫描硬盘上所有的文件，将可疑文件进行提取加密压缩成.zip，保存到 wljslmz\artifact目录下的相应子目录中。

查找其他入侵痕迹：

• 目标：查找其它系统上的入侵痕迹，寻找攻击途径
• 说明：其它系统包括：同一IP 地址段或同一网段的系统、同一域的其他系统、拥有相同操作系统的其他系统。

3.5 检测结果的处理

（1）确定安全事件的类型

经过检测，判断出信息安全事件类型。

信息安全事件可以有以下 7 个基本分类：

• 有害程序事件：蓄意制造、传播有害程序，或是因受到有害程序的影响而导致的信息安全事件。
• 网络攻击事件：通过网络或其他技术手段，利用信息系统的配置缺陷、协议缺陷、程序缺陷或使用暴力攻击对信息系统实施攻击，并造成信息系统异常或对信息系统当前运行造成潜在危害的信息安全事件。
• 信息破坏事件：通过网络或其他技术手段，造成信息系统中的信息被篡改、假冒、泄漏、窃取等而导致的信息安全事件。
• 信息内容安全事件：利用信息网络发布、传播危害国家安全、社会稳定和公共利益的内容的安全事件。
• 设备设施故障：由于信息系统自身故障或外围保障设施故障而导致的信息安全事件，以及人为的使用非技术手段有意或无意的造成信息系统破坏而导致的信息安全事件。
• 灾害性事件：由于不可抗力对信息系统造成物理破坏而导致的信息安全事件。
• 其他信息安全事件：不能归为以上6个基本分类的信息安全事件。

（2）评估突发信息安全事件的影响

• 采用定量和/或定性的方法，对业务中断、系统宕机、网络瘫痪数据丢失等突发信息安全事件造成的影响进行评估；
• 确定是否存在针对该事件的特定系统预案，如有，则启动相关预案；如果事件涉及多个专项预案，应同时启动所有涉及的专项预案；
• 如果没有针对该事件的专项预案，应根据事件具体情 况 ，采取抑制措施，抑制事件进一步扩散。

四、抑制阶段

• 目标：及时采取行动限制事件扩散和影响的范围，限制潜在的损失与破坏，同时要确保封锁方法对涉及相关业务影响最小。
• 角色：应急服务实施小组、应急响应日常运行小组。
• 内容：
  • 抑制方案的确定；
  • 抑制方案的认可；
  • 抑制方案的实施；
  • 抑制效果的判定；
• 输出：《抑制处理记录表》

4.1 抑制方案的确定

• 应急服务提供者应在检测分析的基础上，初步确定与安全事件相对应的抑制方法，如有多项，可由服务对象考虑后自己选择；
• 在确定抑制方法时应该考虑：
  • 全面评估入侵范围、入侵带来的影响和损失；
  • 通过分析得到的其他结论，如入侵者的来源；
  • 服务对象的业务和重点决策过程；
  • 服务对象的业务连续性。

4.2 抑制方案的认可

• 应急服务提供者应告知服务对象所面临的首要问题；
• 应急服务提供者所确定的抑制方法和相应的措施应得到服务对象的认可；
• 在采取抑制措施之前，应急服务提供者要和服务对象充分沟通，告知可能存在的风险，制定应变和回退措施，并与其达成协议。

4.3 抑制方案的实施

• 应急服务提供者要严格按照相关约定实施抑制，不得随意更改抑制的措施的范围，如有必要更改，需获得服务对象的授权；
• 抑制措施包含但不仅限于以下几方面：
  • 确定受害系统的范围后，将被害系统和正常的系统进行隔离，断开或暂时关闭被攻击的系统，使攻击先彻底停止；
  • 持续监视系统和网络活动，记录异常流量的远程IP、域名、端口；
  • 停止或删除系统非正常帐号，隐藏帐号，更改口令，加强口令的安全级别；
  • 挂起或结束未被授权的、可疑的应用程序和进程；
  • 关闭存在的非法服务和不必要的服务；
  • 删除系统各用户“启动”目录下未授权自启动程序；
  • 使用netshare或其他第三方的工具停止所有开放的共享；
  • 使用反病毒软件或其他安全工具检查文件，扫描硬盘上所有的文件，隔离或清除病毒、木马、蠕虫、后门等可疑文件；
  • 设置陷阱，如蜜罐系统；或者反击攻击者的系统。

4.4抑制效果的判定

• 防止事件继续扩散，限制了潜在的损失和破坏，使目前损失最小化；
• 对其它相关业务的影响是否控制在最小。

五、根除阶段

• 目标：对事件进行抑制之后，通过对有关事件或行为的分析结果，找出事件根源，明确相应的补救措施并彻底清除。
• 角色：应急服务实施小组、应急响应日常运行小组。
• 内容：
  • 根除方案的确定；
  • 根除方案的认可；
  • 根除方案的实施；
  • 根除效果的判定；
• 输出：《根除处理记录表》

5.1 根除方案的确定

• 应急服务提供者应协助服务对象检查所有受影响的系统，在准确判断安全事件原因的基础上，提出方案建议；
• 由于入侵者一般会安装后门或使用其他的方法以便于在将来有机会侵入该被攻陷的系统，因此在确定根除方法时，需要了解攻击者时如何入侵的，以及与这种入侵方法相同和相似的各种方法。

5.2 根除方案的认可

• 应急服务提供者应明确告知服务对象所采取的根除措施可能带来的风险，制定应变和回退措施，并得到服务对象的书面授权；
• 应急服务提供者应协助服务对象进行根除方法的实施。

5.3 根除方案的实施

• 应急服务提供者应使用可信的工具进行安全事件的根除处理，不得使用受害系统已有的不可信的文件和工具；
• 根除措施易包含但不仅限与以下几个方面：
  • 改变全部可能受到攻击的系统帐号和口令，并增加口令的安全级别；
  • 修补系统、网络和其他软件漏洞；
  • 增强防护功能：复查所有防护措施的配置，安装最新的防火墙和杀毒软件，并及时更新， 对未受保护或者保护不够的系统增加新的防护措施；
  • 提高其监视保护级别，以保证将来对类似的入侵进行检测；

5.4 根除效果的判定

• 找出造成事件的原因，备份与造成事件的相关文件和数据；
• 对系统中的文件进行清理，根除；
• 使系统能够正常工作。

六、恢复阶段

• 目标：恢复安全事件所涉及到得系统，并还原到正常状态，使业务能够正常进行，恢复工作应避免出现误操作导致数据的丢失。
• 角色：应急服务实施小组、应急响应日常运行小组。
• 内容：
  • 恢复方案的确定；
  • 恢复信息系统；
• 输出：《恢复处理记录表》

6.1 恢复方案的确定

• 应急服务提供者应告知服务对象一个或多个能从安全事件中恢复系统的方法，及他们可能存在的风险；
• 应急服务提供者应和服务对象共同确定系统恢复方案，根据抑制和根除的情况，协助服务对象选择合适的系统恢复的方案，恢复方案涉及到以下几方面：
  • 如何获得访问受损设施或地理区域的授权；
  • 如何通知相关系统的内部和外部业务伙伴；
  • 如何获得安装所需的硬件部件；
  • 如何获得装载备份介质；如何恢复关键操作系统和应用软件；
  • 如何恢复系统数据；
  • 如何成功运行备用设备
• 如果涉及到涉密数据，确定恢复方法时应遵循相应的保密要求 。

6.2 恢复信息系统

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

七、总结阶段

• 目标：通过以上各个阶段的记录表格，回顾安全事件处理的全过程，整理与事件相关的各种信息，进行总结，并尽可能的把所有信息记录到文档中。
• 角色：应急服务实施小组、应急响应日常运行小组。
• 内容：

（1）事故总结:

• 应急服务提供者应及时检查安全事件处理记录是否齐全，是否具备可塑性，并对事件处理过程进行总结和分析；
• 应急处理总结的具体工作包括但不限于以下几项：
  • 事件发生的现象总结；
  • 事件发生的原因分析；
  • 系统的损害程度评估；
  • 事件损失估计；
  • 采取的主要应对措施；

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

• 事故报告:
  • 应急服务提供者应向服务对象提供完备的网络安全事件处理报告；
  • 应急服务提供者应向服务对象提供网络安全方面的措施和建议。

7.1 交付

安全事件处置完成，系统得到恢复。找到安全事件发生原因并提供安全解决方案。

提供交付物： 《XX 系统（事件）应急响应报告》 ，并经采购人相关负责人的书面确认。