文/加菲喵

Apache Log4j2远程代码执行漏洞爆发以来,已有大量安全厂商发布了各种各样的检测方式、漏洞分析文章,安全从业人员能够很好的从相关文档中汲取漏洞相关的技术面知识。但其实对于企业来说,大家更应该关注的是当下次类似的漏洞来了后,我们该通过怎样一种响应流程或者方法,去做到更有序的快速响应?

在漏洞没有成熟的解决方案之初,且POC又被爆出的同时,大部分公司一定都是比较乱的(特别是业务技术栈和漏洞组件是强关联的),这时候等官方补丁包出来再去推动解决,可能数据早就被拖了。那么这时候,安全的同学就要去思考,我们能做哪些事情呢?借此机会,谈一些看法。

一、基础建设

出现这种门槛低、影响大的漏洞,安全团队这个时候一定是会非常迫切的想要了解,我们的资产受影响面到底有哪些?这个问题延伸下来,可以有很多的思考,参考如下:

  • 是否有安全维度的统一资产管理系统,通过一个入口快速盘点影响面?

  • 资产管理系统覆盖的标签是否够全?目前覆盖哪些标签?缺少哪些?

    • IP信息(x.x.x.x)

    • 域名(x.x.x.x)

    • 端口信息 (22、3306)

    • 服务&版本信息 (redis、mysql-x、apache-x.x.x、nginx-x.x.x、ssh)

    • 第三方组件 (log4j-core-*.jar、fastjson-x.jar)

    • 开发框架信息(strust、spring boot、thinkphp)

    • 操作系统(centos、windows、debian、cisco)

    • 资产责任人信息(xxx)

    • 其他资产维度标签

      • 是否涉及用户数据?

      • 是否涉及核心业务?

      • 是否开放外网权限?

      • 其他。。。。。。。

  • 安全团队是否建立了标准化的应急响应流程?指导团队标准化作业?(可参考第二部分)

二、应急响应

假设以上能力均已具备,我们有了资产定位的能力,下一步需要做什么事情呢?

  • 第一阶段,初步影响面确认,根据资产管理系统,初步确认公司是否受到影响,以及那些资产受影响;(这块效果如何,只能看各家前期基建情况了)

  • 第二阶段,风险同步,如果确认公司受影响,根据确认的受影响面,首先应该通知到对应的资产责任人,将漏洞可能造成的影响、官方的解决方案(如有)或缓解措施给到资产责任人,尽到安全应尽的义务;

    • 本阶段建议能够专门指派一个安全同事,通过工单形式记录驱动并对此工单整体闭环负责;

      • 首先创建一个“xxx重大漏洞应急响应工单”,初步记录以下信息:

        • 漏洞的基本背景描述(影响范围/危害)

        • 漏洞的现阶段有效修复方案

      • 将以上工单信息,同步到基础平台(运维)/研发等相关一级负责人或接口人,告知有相关风险存在,安全正在评估相关方案,可关注此工单;(让业务了解安全正在为此努力)

      • 将初步确认的受影响范围以表格形式补充在工单中并通知资产责任人,参考字段如下(优先处理公网/可外部利用资产,如有修复挑战,进行备注以便后续跟进)

        影响资产

        责任人

        公网/内网

        可外部利用

        修复状态

        发现时间备注

        x.x.x.x

        xxxx公网

        待修复

        2021/12/09

  • 第三阶段,多维度快速验证,当有效POC出现,应快速对资产进行黑盒或本地进行快速扫描验证(避免资产管理盲区导致的漏报)

    • 当发现明确漏洞后,第一时间补充到第二阶段建立的工单表格中,并通知到相关责任人;

    • 这部分的验证,也需要有基础的数据、技术支撑,需要考虑扫描的目标源有哪些(IP、域名、后台、接口)?漏洞快速验证的能力是否具备,效率如何?

  • 第四阶段,主动止血 or 监控风险?安全需要考虑到,如果官方没有解决方案、缓解措施失效、业务修复不及时,安全可以主动做哪些事情?

    • 监控措施

      • WAF

      • DNS请求信息的监控(像log4j的例子,云上的dns请求,配合威胁情报数据,了解哪些资产请求过dnslog.cn等平台?有数据的话,是否可快速覆盖告警规则?)

      • NIDS/云上流量

      • RASP/IAST

    • 阻断措施

      • WAF

      • RASP/IAST

      • 主机Agent (针对反弹shell、木马后门重点监控和拦截)

    • 问题点

      • WAF和RASP/IAST,覆盖率、性能是个问题;

      • 规则被绕过的问题,还是需要专人持续对抗;

  • 第五阶段,持续跟踪确保闭环,直至风险完全解决;

    • 持续同步漏洞的最新进展(同步周期以及对象根据不同公司情况把控,建议一天一次/至少同步到部门一级负责人)

      • 安全动作(要让业务部门或老板知道安全做了什么)

        • 什么时候上了什么策略?保障了什么业务?

      • 安全数据

        • 现存数/已修复数/待修复数

        • 上策略后,截止目前抵御了多少次和漏洞相关的攻击?

        • 如有成功入侵的事件,也应记录下来,这个应启动入侵事件应急响应流程,这里具体不过多讨论了;

    • 当工单表格中已记录的资产均已按照最佳解决方案修复且安全验证后,工单结束

    • 最后对本次应急响应的过程进行复盘,分析从工单建立到工单结束的过程中,我们遇到了哪些问题?哪些可以提升?

    • 以上几个阶段,其实是可以并行进行的,安全团队可按照团队情况事先确定好不同阶段中的人员分工,再次发生时大家有序的协同进行即可;

三、思考总结

这种影响面大的漏洞出现,虽然对于安全团队有挑战,其实也是很有帮助的,除了能够通过事件驱动一些平常落地不了的安全管理手段,这也是和业务部门建立信任的一次非常好机会,通过规范、流程、专业的安全运营,能够让业务对安全团队产生一种信任感。(当然,整个过程一团糟就另当别论了。)

同时每次事件发生后,安全团队都可以在过程中通过事前、事中、事后的维度去思考、分析目前自己公司的安全建设中,哪些是有短板的、哪些是可以去提升的?

  • 事前

    • 对漏洞/情报的感知能力

    • 安全维度的资产标签覆盖能力

    • 应急响应能力

  • 事中

    • 同步机制

    • 监控告警

    • 及时止血

    • 快速验证

  • 事后

    • 闭环

    • 溯源

    • 复盘

年底了,各位看官可以按照以上思路,可以对齐下看看有哪些短板,制定明年的OKR了~ :)

加菲喵

声明:本文来自欧赛安圈,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。