【HW系列】事中迎战(3):情报处置

news/2024/11/15 19:44:50/文章来源:https://www.cnblogs.com/o-O-oO/p/18328295

本章为该系列的第13篇,也是事中迎战的第3篇。井喷的情报算是演练期间的一大特色了,这一篇我们聊聊如何搞定这些情报。

一、 情报收集

古往今来,情报一直都是兵家必争之地,演练期间尤其明显,各种情报的密度要比往常高很多,它们从四面八方传来,给我们带来了很多困扰。
情报的来源是我们首要关注的点,情报源直接决定了情报的质量,演练期间的情报来源有以下三个渠道:

1.1 安全公司

很多安全公司在演练期间会建立专门的支持中心,其中情报是其为客户赋能的一项服务。一般安全公司会基于遍布全国的值守项目,汇总来自一线的真实信息,经过研判后再发给客户作参考,可信度比较高。

1.2 行业组织

为了实现行业的联防联控,一些行业组织也会面向全行业收集情报并共享。演习期间,您的企业可以与这些行业组织(如监管机构)建立联系,以扩充自身的情报来源。

1.3 小道消息

各种小道消息绝对是一大亮点,在演练前各种小道消息就开始满天飞了,有通过公开媒体传的,也有口口相传的,真真假假,说什么的都有,相比前两类可信度低一些。
曾经参与过一个防守单位的应急响应,当时这起事件也在行业里快速传开了,真是看热闹不嫌事大,圈子里说什么的都有。不过很多时候,我们我们对于小道消息都是宁信其有,不信其无。

二、情报分类

情报主要分为以下6个类型:

恶意ip恶意域名恶意样本钓鱼邮箱漏洞情报
攻击事件

其中恶意ip、恶意域名、恶意样本和钓鱼邮箱就是传统的IoC,漏洞情报在演练期间出现的频率会比平时高很多,攻击事件则是平日里关注较少的情报,比如供应商被攻陷、外联单位被攻陷等,如果我们能及时掌握正在发生的攻击事件,有助于我们提前采取应对策略。

三、情报处置

3.1 IoC的处置

由于防守方缺少足够的分析数据,对IoC的研判能力有限,大部分时候只能无条件相信。很多防守单位对IoC情报采取的是简单粗暴的处置方式,即所有IoC一律加入黑名单封禁到演练结束。其实我不赞成一股脑全盘封禁的做法,不在乎IoC准确度,短期里进行大量无差别的封禁,总觉得哪里不对。
这种一刀切的封禁一定会带来误封问题,往届的演练中,一个子公司误封了总公司的IP没有及时恢复,后来听说那个子公司被罚的挺惨的,也有防守单位误封了CDN地址,导致业务中断的,这种事情数不胜数。
在加黑名单前,可以结合情报标签进行初步研判,对于CDN、IDC这类可以做特殊处理,我们已知的白名单一律不能加黑,比如外联单位、分子公司、总公司的IP和域名。
如果您的企业决定演练期间对情报IoC进行全盘封禁的话,那么不要有侥幸心理,误封禁是一定会发生的,哪怕这次的演练没发生,也一定会在未来的某次演练中发生。
如果“既要”全盘封禁,“又要”保证业务,那就“还要”做好配套的事后补救措施,安全永远是为业务保驾护航,不是将其击沉,演练不是影响业务的理由。建立业务反馈机制,及时了解业务受影响的情况,并制定快速解封通道,出现问题后可以快速恢复业务。

3.2 漏洞情报处置

此时不搏更待何时,每年这个时候,攻击队会把自己的0day杀手锏拿出来,听说去年演练期间有超过100个0day漏洞被利用,铺天盖地的漏洞情报也让防守方疲于应对。
防守方需要建立漏洞处置机制,明确好漏洞定级标准和修复时限,规定好安全、研发和运维的沟通渠道,结合资产管理平台定位受影响的资产,定点推送相关负责人根据时限要求修复。
不仅是在演习期间,一套成形的漏洞处置流程在日常漏洞治理工作中也适用,如果您的企业已建立了漏洞处置机制,那就按照既有的方式处理即可,我个人觉得演习期间处置方式与平时没什么不一样。
对于新公开的漏洞,还要同步收集PoC,已公开PoC的漏洞,一定要及时配置防护规则,并提高告警的威胁等级。漏洞修复终究还是有延迟的,及时上防护规则可以通过安全运营手段进行风险缓释。对于攻击队来说,演练期间公开的PoC是重点利用的手段,曾经和国内第一梯队的攻击队交流,演练期间收集到的新漏洞,他们直接架扫描器把所有靶标扫一遍再说,如果防守单位没有及时做好处置就会面临被攻击的风险,打的就是时间差,实战中因为1day被突破的例子也是数不胜数,各防守单位还需要重视。

3.3 攻击事件情报处置

“xx单位被打穿了”、“xx单位出局了”……这类的攻击事件是我们喜闻乐见的,能给压抑的防守工作带来了很多乐趣。吃瓜的同时,还要留意一些与我们相关的攻击事件,除了直接攻击我们的事件,与我们有关的供应链、外联单位的攻击事件也要重视,得到情报后,最好与相关单位取得联系,及时做好应对措施,防止我们成为攻击链条中的下一环。

四、 情报共享

如果您所在的行业有情报共享渠道的话,在安全监控的过程中可以汇总自己的独家情报,面向全行业分享,实现行业的联防联控。如果我们在情报共享方面表现突出,还有可能获得行业组织的嘉奖,对于防守方来说这些荣誉都是硬通货,在做演练工作汇报的时候都是加分项。

五、 总结

找到靠谱的情报源,针对IoC、漏洞、攻击事件等类型的情报,制定不同的处置策略,如果行业内有情报共享渠道,还可以将我们的独家情报面向全行业分享。
如果这篇文章你只能记住一件事的话,那请记住:多渠道收集,分类型处理。

原创 十九线菜鸟学安全

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/773043.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【HW系列】事中迎战(2):安全事件监控与处置

本章为该系列的第12篇,也是事中迎战的第2篇,这一节让我们聊聊演练期间工作量最大的一项任务----安全事件监控与处置。一、 角色分组 还记得【红蓝/演练】-事前准备(1)之演练组织中介绍的组织架构吗,实战阶段的主力军就是以下三个组: 监控组,负责对安全告警进行处置,及时闭…

【HW系列】事前准备(10):事前阶段小结

本章为该系列的第10篇,也是事前准备阶段的第10篇,通过本章做个小结,来结束事前准备阶段的介绍,从下一篇开始,将正式进入事中迎战阶段。 有幸观摩过一场线下沙龙,在讨论过程中,我发现不同性质的企业,安全的建设方案完全不一样。当时在讨论邮件安全的议题,一位互联网公司…

基于Hive的大数据分析系统

1.概述 在构建大数据分析系统的过程中,我们面对着海量、多源的数据挑战,如何有效地解决这些零散数据的分析问题一直是大数据领域研究的核心关注点。大数据分析处理平台作为应对这一挑战的利器,致力于整合当前主流的各种大数据处理分析框架和工具,以实现对数据的全面挖掘和深…

【HW系列】事前准备(3):人员筹备

本章为该系列的第3篇,也是事前准备阶段的第3篇。 防护体系不是只有安全设备,人员也是防护体系中的重要因素,特别是强对抗场景下,需要提前准备好保障的人员,保障有人进行7*24小时监控,出现突发事件有能力协助处置。如果自己的人力资源不足,可以在预算范围内采购安全公司的…

Mybatis-plus之自动填充

开发时遇到这个bug原因:Mybatis-plus自动填充时选到了update,导致首次insert时id为null,但是数据库表不允许为null因此报错。 解决:填充策略改为insert_update即可Linux等环境软件安装

【HW系列】事前准备(1):演练组织

有幸多次参与过网络攻防对抗,有国家级、省市级的演习,有客户组织的模拟攻防、也有公司内部的红蓝对抗,打过攻击也参与过防守,现在回顾一下,其实有很多经验值得好好总结,因此萌生了站在防守视角把“红蓝/演练”写成系列文章的想法,来聊聊防守方那些事。 本章为该系列的第…

Fiddler学习】Fiddler教程,比较经典全面(转)

https://github.com/gabrielxvx/zh-fiddler简介 Fiddler(中文名称:小提琴)是一个HTTP的调试代理,以代理服务器的方式,监听系统的Http网络数据流动,Fiddler可以也可以让你检查所有的HTTP通讯,设置断点,以及Fiddle所有的“进出”的数据(我一般用来抓包),Fiddler还包含一…

【HW系列】事前准备(5):互联网风险收敛

本章为该系列的第5篇,也是事前准备阶段的第5篇。前4篇重点讲的是组织方面的准备工作,从这一篇开始,让我们正式进入安全技术防控的部分,这一篇来聊聊如何进行互联网风险收敛。一、互联网系统下线 系统下线是最直接有效的方法,也是防守方常用的手段,所以演习前会看到很多来…

马斯克: 教育是解决问题, 而不是教工具

1. 马斯克: 教育是解决问题, 而不是教工具[3,4,6] 2. 老天爷的教的方法 我理解这就跟游戏一样, 从环境中持续获得反馈, 体会乐趣, 修正不足, 而不是在工具方法和原理中消磨意志力. 实践中学习是我们天生的 比如我们学说话,不是先学拼音,学走路,也不先学力学原理,而是直接模…

征服 Docker 镜像访问限制:KubeSphere v3.4.1 成功部署全攻略

近期,KubeSphere 社区的讨论中频繁出现关于 Docker 官方镜像仓库访问受限的问题。 本文旨在为您提供一个详细的指南, 展示在 Docker 官方镜像访问受限的情况下,如何通过 KubeKey v3.1.2 一次性成功部署 KubeSphere v3.4.1 以及 Kubernetes v1.28.8 集群。这将帮助您克服访问…

Redis变慢的原因及排查方法-系统方面

原因1:实例内存达到上限 1)排查思路 如果 Redis 实例设置了内存上限 maxmemory,那么也有可能导致 Redis 变慢。 当我们把 Redis 当做纯缓存使用时,通常会给这个实例设置一个内存上限 maxmemory,然后设置一个数据淘汰策略。而当实例的内存达到了 maxmemory 后,你可能会发现…

Layer Normalization

一、Layer Norm 1.1 介绍 LayerNorm(Layer Normalization)是2016年提出的,随着Transformer等模型的大规模推广,LayerNorm出现频率也随之越来越高。其大体思想类似于BatchNorm,对输入的每个样本进行归一化处理,具体就是计算每个输入的均值和方差,归一化到均值为0,方差为…