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

news/2024/11/16 3:21:10/文章来源:https://www.cnblogs.com/o-O-oO/p/18328291

本章为该系列的第12篇,也是事中迎战的第2篇,这一节让我们聊聊演练期间工作量最大的一项任务----安全事件监控与处置。

一、 角色分组

还记得【红蓝/演练】-事前准备(1)之演练组织中介绍的组织架构吗,实战阶段的主力军就是以下三个组:

监控组,负责对安全告警进行处置,及时闭环安全事件或疑似安全事件。
分析研判组,负责处理监控组提交的安全事件工单,对攻击事件进行深入分析,为事件做最终定性,针对成功攻击的事件制定防御方案。处置组,负责对安全风险进行收敛,包括漏洞修复、策略调优等。

二、 监控支撑体系

根据实际的运转经验,演练期间可采用三级支撑体系,即:

一线监控,对原始告警进行监控和初步研判。二线研判,对疑似安全事件进行分析和定性。
三线技术研究,对疑难杂症提供更深入的技术支持。

一线监控

一线监控由监控组承担,核心要求是快速响应。演练这种特殊时期,要保证每一台安全设备都有人监控,可以一人盯一个设备,也可以一人盯多个,主要看人力资源的情况。特殊时期,每一条告警都要逐条分析,拿不准的就抛出来联动排查。对于疑似安全事件的,要及时提交到二线进行处置,避免过多投入精力而影响监控时效性。
一线监控通常由驻场人员承担,为了保证一线的工作质量,一定要对其提出工作要求,在商务阶段就可以将相关要求和交付物落在合同条款中,每个班次人员至少要提交工作日报。

二线研判

二线研判由分析研判组承担,核心要求是准确。当有疑似安全事件发生时,一线监控人员需要将事件升级,由二线研判人员进一步分析,如认定为安全事件,二线人员需要根据事件的具体情况联系处置组进行处置,该下线下线,该修漏洞修漏洞,必要时还需要启动应急响应。
对于单一告警源无法研判的事件,二线人员还要组织一线的联动排查。对于有条件的防守单位,建议二线由企业内部员工承担,此岗位需要具备一定的攻防技术和事件处置经验,能识别攻击类型,能判断被攻击目标是否失陷,能抑制风险,能提出解决方案……冰冻三尺非一日之寒,防守单位在日常工作中就需要培养此类人员,关键时候能起大作用。

三线技术研究

有一定技术门槛的课题可以传递到三线进行技术研究,比如逆向分析、0day分析、溯源反制等。三线可以借助安全公司背后的技术能力做支撑,体量大一点的安全公司,在特殊时期都会建立自己的指挥中心或安全服务中台,以支撑全国的项目需求。
演练期间有采购安全公司驻场服务的防守单位,必要时可以向安全公司申请专业的技术支持。如果本单位二线研判人员具备足够强的技术能力和精力,也可以不依赖于安全公司的支撑,这样能保证内部的安全事件不外漏。活能干就行,谁干不重要。

三、协同联动作战室

战时涉及的人员很多,有事全靠吼是不行的,为了保证各事项高效处理,最好通过工单系统进行线上流转,同时建立内部沟通群组同步信息,如果企业没有部署私有聊天工具,注意不要在群中泄露敏感信息。

在实践中,我见过比较好的做法是搭建线上协同作战室,可同时提供工单和沟通的功能,每个需要调查的安全事件都创建事件沟通群,在群中可以指派处置人,事件处置完毕后将事件群标记为已处置,处置过程都保存在沟通群中,方便回溯,且沟通内容不会通过公网传播。

四、 总结

安全事件的高效监控和处置,核心是建立联动机制,包括设计组织流程和技术平台支撑。如果这篇文章你只能记住一件事的话,那请记住:多级支撑,协同作战。

原创 十九线菜鸟学安全

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

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

相关文章

【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,方差为…

20、flask-进阶-自定义静态文件static和模板文件templates的路径配置

自定义static目录和templates目录的路径原本flask默认的static和templates目录是在App目录下的:如下图如果想把这两个目录更改位置,如放在根目录下:代码如下: __init__.pyfrom flask import Flask from .views import blue from .exts import init_exts import os# 获取项目…