应急响应简谈

=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=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4603.html

《应急响应简谈》上有7条评论

  1. 金融企业安全运营建设之路
    https://mp.weixin.qq.com/s/beaJVw8iCky3kitrVt2ZJg

    金融企业信息安全建设初期,在网络层、系统层、应用层、数据层等部署了一系列安全设备和管控措施进行安全管控,并确保其稳定运行,但发现安全状况并没有得到有效改善、安全问题频发,其根本原因是没有进行有效的安全运营,金融企业如何建设有效的安全运营体系呢?

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

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

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

  2. 数据突发事件响应流程
    https://cloud.google.com/security/incident-response/?hl=zh-cn

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

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

  3. 专题·原创 | 潘柱廷:应急与应极 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(数字新媒体产业)领域。未来在关键信息基础设施领域,必然是战争潜力网的所在,也必然是网络灾难的发生地。不管是军事对抗还是抗击灾难,都需要有成建制的、专业化装备的、高素质训练的网军。

发表评论

电子邮件地址不会被公开。 必填项已用*标注