ASPIRE

应急响应简谈

=Start=

缘由：

之前在blog中记录过2篇和应急响应直接相关的内容「安全应急响应检查清单」&「安全事件应急响应处理指南」，现在网上和安全应急响应相关的文章也很多，内容、质量也都挺不错的；所以，在此我不准备详细描述应急响应的具体细节，有需要的可以参考本文最后的「参考链接」，这里我只简单谈一下我在一个较大的互联网企业中见到的相关流程和注意事项，以及我个人的一些想法，仅供参考。

正文：

参考解答：
0x01-为什么会有「应急响应」？

随着国家信息化建设进程的加速，计算机信息系统和网络已经成为重要的基础设施。随着网络安全组件的不断增多，网络边界不断扩大，网络安全管理的难度日趋增大，各种潜在的网络信息危险因素与日俱增。虽然网络安全的保障技术也在快速发展，但实践证明，现实中再完备的安全保护也无法抵御所有危险。因此，完善的网络安全体系要求在保护体系之外必须建立相应的应急响应体系。

说得更简单一点就是：应急响应是一个完善的网络安全体系中不可或缺的一环。

在互联网企业中，安全的存在主要是为了保障业务的连续性（更高级一点的——安全可以作为业务的一个属性而存在），使业务不至于因为安全的问题而受到影响。因此，安全响应的功能有以下几点：

【核心】保障业务
【其次】还原攻击链路，明确攻击者意图，提供解决方案，查漏补缺，举一反三，避免再次受到同类攻击的影响
【可选】通过取证走司法途径
【不建议】对攻击者采取反制措施

0x02-互联网企业中常见的「应急响应」事件类型？

常见的有：

  • 被“黑了/拖库”
  • 被入侵
  • 客户信息泄露
  • 被蠕虫
  • 被钓鱼
  • 被劫持
  • 被DDOS
  • ……

基本上只要和「安全」沾边的可能都需要「应急响应」。即便有些时候这事和你没什么关系，但如果有机会的话多去了解了解、学习学习别人是怎么处理的，提高一下自己的姿势水平总没错。

0x03-「应急响应」的一些方法论？

最常见的可能就是——应急响应PDCERF模型了：

  • 准备（Preparation）
  • 检测（Detection）
  • 抑制（Containment）
  • 根除（Eradication）
  • 恢复（Recovery）
  • 跟踪（Follow-up）

这几个步骤相互关联最后形成一个环状。如果针对任何一个较为严重的事件响应无法形成一个闭环，那么这个应急响应就可以说是不合格或者未完成的！

0x04-「应急响应」的一些注意事项？

一个事件的大体生命周期如下：

  1. 事件发生（运维监控人员、客服审核人员、公司外部人员等的上报），发现问题，及时通报
  2. 事件确认：判断事件的真实性和严重性，评估出问题的严重等级，是否向上进行汇报等
  3. 事件响应：各部门通力合作，处理安全问题，具体解决阶段。
  4. 事件关闭：处理完事件之后，需要关闭事件，并写出安全应急处理分析报告，追踪事件中暴露出来的问题是否得到了有效的整改，最后才是完成整个应急响应的过程。

①可以看到，「事件确认」是在「事件响应」之前的，很多时候，从其它地方报出来的问题，不一定是真问题，不一定都需要响应，需要先判断事件的真实性。

②凡事预则立，不预则废！

事前：

  • 规范制度、相关联系名单、技术工具、安全统一平台、安全运营等要提前准备好。
  • 在有条件的情况下，可以考虑借助威胁情报的力量将对抗提前，尽量将问题消灭在襁褓中。

事中：

  • 止损第一！止损第一！止损第一！
  • 事件处理流程化、标准化，最好要有相对应的SOP来保证，尽量减少对处理人员经验的依赖。
  • 安全对外最好只有一个消息出口（内部可以提前讨论、准备好话术），好统一口径，避免给其他部门的人内部不团结、不专业的印象。
  • 不要私下讨论！安全问题，尤其是比较严重的安全问题，不是底下几个安全、运维、开发工程师私下沟通、达成协议就能处理得好的，一定要按照预先准备好的负责人、接口人名单拉群沟通处理，问题越严重、越紧急，需要周知到的相关人员的级别就越高！
  • IM联系不上，就打电话；本人联系不上，就找他leader，直到找到能处理问题的相关人员。
  • 在有高级别人员的群中，说话要注意方式、方法，避免因为处理安全问题而给老板留下不好的印象。
  • 作为一个安全问题处理人员，提出的解决方案要体现出自己的专业性，妥协的话不该是底层的人员说的，这话应该由相关方面的负责人，甚至是整体安全的负责人来说。

事后：

  • 借助5whys分析法进行根因分析，找出所有可能的问题原因。
  • 借助工具跟进、监控todo项，及时掌握问题处理进度，避免待办事项最后无疾而终。

最后想说的是，安全问题不是洪水猛兽，现实中再完备的安全保护也无法抵御所有危险；安全部门一方面可以借助安全问题推动业务方进行改进，另一方面也可以借此检视一下自身的安全防护手段是否生效、是否还存在需要改进的地方，不断完善提高。

参考链接：

=END=

Docker

,
, , ,

《 “应急响应简谈” 》 有 9 条评论

  2. 漫谈网络安全应急要略
    https://mp.weixin.qq.com/s/995Je399tnqcsDweeGTGOA
    `
    要略一：急则治其标，缓则治其本
    要略二：数据安全高于一切
    要略三：举一反三，触类旁通
    要略四：广开言路，以德服人
    要略五：未雨绸缪，防范未然
    要略六：犯罪者，虽远必诛
    `

    回复

  3. 金融企业安全运营建设之路
    https://mp.weixin.qq.com/s/beaJVw8iCky3kitrVt2ZJg
    `
    金融企业信息安全建设初期，在网络层、系统层、应用层、数据层等部署了一系列安全设备和管控措施进行安全管控，并确保其稳定运行，但发现安全状况并没有得到有效改善、安全问题频发，其根本原因是没有进行有效的安全运营，金融企业如何建设有效的安全运营体系呢？

    安全运营定义为：“为了实现安全目标，提出安全解决构想、验证效果、分析问题、诊断问题、协调资源解决问题并持续迭代优化的过程”。

    占据“半壁江山”的安全运营，重点要解决以下问题：
    1）安全运营的第一个目标：将安全服务质量保持在稳定区间。
    2）安全运营的第二个目标：安全工程化能力。

    为确保安全运营架构能够灵活扩展，推荐按功能模块划分成四个模块：安全防护框架、安全运维框架、安全验证框架、安全度量框架。
    （1）安全防护框架的主要功能是通过不断的部署安全监测系统，提供实时检测的能力，称为安全感知器“Sensor”，为安全运维框架提供“天眼”。时下流行的态势感知、入侵感知，笔者理解为主要靠安全防护框架来保障。
    （2）安全运维框架的主要功能是统一采集安全防护框架各Sensor的监测信息，并通过黑白灰名单处理和关联分析，处理监测信息并通过统一展示平台输出告警，进入事件处理平台和流程，人工介入处理。安全运维框架还包括安全事件的定期review和向管理层汇报，这部分可能比单个的事件处理要重要。
    （3）安全验证框架主要功能是综合通过黑盒白盒验证措施，确保安全防护框架和安全运维框架的有效性。
    （4）安全度量框架主要功能是通过一系列安全度量指标衡量评价安全运营质量水平，并针对性持续过程改进，实现质量的螺旋上升。
    `

    回复

  4. 数据突发事件响应流程
    https://cloud.google.com/security/incident-response/?hl=zh-cn
    `
    客户数据的安全至关重要，而数据安全有赖于 Google 与客户的协作。Google 负责保护底层的云端基础架构和服务的安全，而客户在 Google 云端基础架构之上进行构建时，要保护其应用、设备和系统的安全。Google 为客户提供指导和多种安全功能，以实现 Google 级安全做法：
    * 身份和访问权限管理
    * 默认对静态数据和传输中的数据进行加密，无需客户执行任何额外操作
    * 多重身份验证，包括防网上诱骗的硬件第二重安全密钥
    * 广泛的网络安全选项，包括虚拟私有云 (VPC) 和共享 VPC、软件即服务 (SaaS) 和平台即服务 (PaaS) 解决方案的内置 DDoS 防护，以及将上述机制用于基础架构即服务 (IaaS) 解决方案的选项
    * 详细的审核日志

    # 数据突发事件响应流程
    每个数据突发事件都具有特异性，数据突发事件响应流程的目标是保护客户的数据，尽快恢复正常服务，并满足监管和合同合规要求。 Google 的突发事件响应计划的流程如下：
    * 识别
    * 协调
    * 解决
    * 关闭
    * 持续改进
    `

    回复

  7. 专题·原创 | 潘柱廷：应急与应极 PIDCERF修正模型——“抗疫”给网络安全应急带来的思考
    https://mp.weixin.qq.com/s/oWBUilnfSe_BXwidJzeflQ
    `
    发端于2019年底，爆发于2020年初的这一场新冠肺炎疫情，让我们看到了建立多年的疫情应对体系存在的一些问题，同时也看到了我国政府在疫情爆发后的一系列应急措施确实及时有效。不管在哪一个领域，这种级别的超大型灾难都是不多见的，有防灾救灾责任的领域都应当认真借鉴这次大灾的教训和经验，反省自身。

    一、必须面对的一些“客观”事实
    大灾难，不会是最后一次
    安全危害守恒定律
    急与极——急迫与极致
    大灾难总是复杂的，也总是跨域的
    面对灾难，为什么保障体系总是那么脆弱？
    不能因没有阻止灾难发生就全面否定防范体系
    灾难和攻击是有区别的

    二、网络安全应急体系修正模型——PIDCERF
    在网络安全应急领域，有一个被广泛认同的PDCERF模型，六个环节分别是：准备（Preparation）、检测（Detection）、遏制（Containment）、消除（Eradication或Erase）、恢复（Recovery）、后续跟踪（Follow-up）。

    而这次“新冠肺炎疫情”带来的一个教训就是“检测”竟然没有起到应有的作用。并不是基层和前端没有检测没有上报，而是因为整个上报体系是一个复杂系统，受到非技术性因素的干扰，使得足够的检测数据和检测情报被隐瞒和修饰，最终导致对疫情的判断出现重大缺失和延误，错失早期“遏制”的时间窗口。

    受此教训的驱动，笔者将PDCERF模型的六个环节扩展为七个环节，将PDCERF中的D检测，扩展分解为两个环节“I 检测（Inspection）”和“D 研判（Decision）”。拆解出来的两个新环节的工作内容在原有模型中也都有涉及，但特地拆分出来就是要分别有所强调。

    鉴于“新冠肺炎疫情”的教训，“I检测”机制必须有一个前端原始数据的无人干预分析结果的“向上直报”机制。而且，这个向上直报机制不会受到各个层级“D研判”的影响和干预。作为高级别的分析研判机制，不仅要收取下级的分析研判初步结果（局部“小数据”汇集分析），还要收取下面各级的原始数据进行分析（全局覆盖的“大数据”分析）。

    三、从“抗疫”战役中，网络安全还能借鉴到什么
    抗灾都是总体战
    从合规性安全，到检验性安全
    理性看待防范体系的能力极限和副作用
    要解决问题，而不要解决提出问题的人
    平行仿真，提高早期预警能力
    平行仿真，灾难复盘
    隔离式安全，依然是最有效的遏制措施
    网络领域的“方舱医院”是什么？
    网络领域如何依法救灾
    网络灾难的救灾支援队伍在哪里
    网络上的人民战争，“兵民”的人民在哪里
    灾难级网络问题，呼吁网军的建制

    现在国家推出的经济复苏政策中提出的新基建：5G基建、特高压、城际高铁和轨道交通、新能源汽车充电桩、大数据中心、人工智能、工业互联网。有人把这七大领域再加上北斗导航，称呼为新基建八仙。这八仙中有五仙都是直接的TMT（数字新媒体产业）领域。未来在关键信息基础设施领域，必然是战争潜力网的所在，也必然是网络灾难的发生地。不管是军事对抗还是抗击灾难，都需要有成建制的、专业化装备的、高素质训练的网军。
    `

    回复

  8. 干货|应急响应常用工具
    https://www.secpulse.com/archives/190521.html
    `
    # 1 进程分析工具

    ## 1.1 ProcessHacker
    功能：ProcessHacker是一款不错的进程分析工具，可查看所有进程信息，包括进程加载的dll、进程打开的文件、进程读写的注册表……，也可以将特定进程的内存空间Dump到本地，此外还可以查看网络连接。注：查看具体进程的详细信息，双击Processes列表中的进程名字即可。

    ## 1.2 ProcessExplorer
    功能：ProcessExplorer是一款不错的进程分析工具，微软官方推荐工具，稳定性和兼容性相对不错。可查看所有进程的信息，包括其加载的dll、创建的线程、网络连接……，同样可以Dump出进程的内存空间到本地。

    ## 1.3 ProcessMonitor
    功能：ProcessMonitor是一款实时刷新的进程信息监控工具，微软官方推荐工具，稳定性和兼容性也是相对出色。展示的信息很全面，且每一个打开的句柄、注册表、网络连接……都与具体的进程关联起来。

    ## 1.4 XueTr
    功能：XueTr是一个Windows系统信息查看软件，可协助排查木马、后门等病毒，功能众多。

    ## 1.5 PCHunter
    功能：XueTr的增强版，功能和XueTr差不多，可参考上图。推荐更多使用PCHunter，减少出故障的概率。

    ## 1.6 ProcessDump
    功能：可对指定的进程，将其进程空间内的所有模块单独Dump出来，甚至可Dump出隐藏的模块（即进程加载的dll，这里通常是被注入）。注：这是个命令行工具。

    ## 1.7 PsTools
    功能：PsTools是命令行工具集，微软官方推荐，功能多而全，其涵盖的子功能（命令）如下：

    # 2 流量分析工具

    ## 2.1 Wireshark
    功能：Wireshark是一款常用的网络抓包工具，同时也可以用于流量分析。

    ## 2.2 科来网络分析
    功能：科来公司的一款流量分析工具，对比Wireshark要相对易用些（特别是流量分析入门人员），此外，该工具会自动将流量进行归类和统计。在某种意味上，还是比较方便的。

    ## 2.3 TCPView
    功能：查看系统的网络连接详情，每一条连接对应的进程、协议、进程、源目地址、源目端口、连接状态……总之，可展示当前活跃连接的所有详细信息。

    # 3 启动项分析工具

    ## 3.1 AutoRuns
    功能：一款不错的启动项分析工具，微软官方推荐。只要涉及到启动项相关的信息，事无巨细，通通都可以查询得到，非常方便找到病毒的启动项。

    # 4 信息收集工具

    ## 4.1 FastIR
    功能：收集操作系统的关键日志、关键信息，方便后续取证和排查分析。

    ## 4.2 BrowsingHistoryView
    功能：收集浏览器的历史记录，方便追溯域名、URL的访问来源是否源自于用户行为。

    # 5 辅助工具

    ## 5.1 Hash
    功能：文件hash计算工具，可计算文件MD5、SHA1、CRC值，可用于辅助判断文件是否被篡改，或者使用哈希值到威胁情报网站查看是否为恶意文件。

    ## 5.2 ntfsdir
    功能：病毒也有可能是以创建服务启动项的方式保持长久运行，点击Autoruns的Services功能，如下图，检查是否有异常的服务启动项。

    ## 5.3 Unlocker
    功能：可对难以删除的文件进行强制删除（包括锁定的文件），需安装，安装后右键菜单”Unlocker“即可弹出如下界面：

    # 6 Webshell查杀工具

    ## 6.1 wscan
    功能：深信服自研的一款Webshell查杀工具。

    ## 6.2 D盾
    功能：D盾是迪元素科技的一款Webshell查杀工具。

    # 7 专杀工具

    ## 7.1 飞客蠕虫专杀
    功能：专门针对飞客蠕虫病毒进行查杀的工具。飞客蠕虫专杀工具有kidokiller（卡巴斯基出品）、TMCleanTool（趋势科技出品）。

    ## 7.2 Ramnit专杀
    功能：专门针对Ramnit类家族病毒进行查杀的工具。
    FxRamnit是赛门铁克出品的Ramnit专杀工具。注：由于Ramnit是全盘感染性病毒，故此专杀工具运行时间比较长，需耐心等待（FxRamnit常常给人一种”假死“的感觉）。
    `

    回复

  9. 安全事件SOP：基于实践的安全事件简述
    https://mp.weixin.qq.com/s/pm6tS976rq_cBuMO7g9ZhA
    `
    在《应急能力提升7-整体总结与提升》文中提到了：在企业安全运营建设时，大致会经过依赖人工或安全公司提供服务、安全事件处置标准化、自动化响应三个发展阶段。
    本系列文章将聚焦介绍常见的安全事件及标准处置方法，即：安全事件处置SOP。

    01-安全事件概述

    1.1 安全事件定义

    1.2 事件分级原则
    * 事件分级以量化指标为优先原则，在主观量化损失时应按较高的量化损失或更严重的影响作为评估依据；
    * 当判断准确量化存在较大困难或量化所消耗成本较高时，可基于主观判断；
    * 在事件持续过程应根据事件进展动态更新事件级别。

    1.3 安全事件运营
    对于外部攻击导致的安全事件，需要对每一次进行深入分析，找到不足并补强。但针对内部人员导致的安全事件，从发生监测到事后运营，属于单事件运营，起到的防护或警示效果有限。为了进一步让事件发挥出更大的效果，对主机和数据安全事件进行统一化管理，建立以部门为单位的安全风险分数计算、公示机制，并组织违规个人及部门参与安全红线、安全意识培训和考试，以此降低再犯的可能性。

    02-安全事件处置

    2.1 处置原则
    1.责任制原则
    2.快速恢复原则
    3.分级处置原则

    2.2 处置流程
    1.告警响应
    2.分析研判
    3.事件上报
    4.全面处置
    5.总结复盘
    每一次事件，对于安全来说都应该是一次涅槃重生、建设更加安全网络环境的机会。深挖事件产生原因、验证安全防护机制、检验安全监测策略，并做横向思考，根据剖析与总结事件，输出事件报告，其中比较重要的除了事件原因就是一系列可提升现有水平的后续改进项。

    # 网络安全事件处置报告单
    事件名称
    事件ID
    事件级别
    报告日期
    发现来源

    影响概述
    事件影响级别
    外部影响描述：
    内部影响描述：

    系统信息
    系统IP
    影响时长
    负责人
    负责团队

    事件关键时间
    发现时间
    安全初查时间
    漏洞修复时间
    安全复查时间

    事件处置过程
    处置过程
    处置步骤
    参与人员

    影响分析
    法务影响
    业务影响
    数据影响
    安全风险
    其他

    原因分析
    原因分类(□设备设施 □应用系统 □人员 □流程 □外部因素)
    原因分析

    后续改进
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注