读《长安十二时辰》有感——SIEM/SOC 建设要点—Elastic Stack 实战手册

本文涉及的产品
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
简介: 最近读了马伯庸老师的小说《长安十二时辰》(也有改为《长安二十四时辰》的网剧,之所以改成二十四时辰,我觉得也是非常的不认可原著里面的时间观念吧?

970X90.png

· 更多精彩内容,请下载阅读全本《Elastic Stack实战手册》

· 加入创作人行列,一起交流碰撞,参与技术圈年度盛事吧

创作人:李捷

最近读了马伯庸老师的小说《长安十二时辰》(也有改为《长安二十四时辰》的网剧,之所以改成二十四时辰,我觉得也是非常的不认可原著里面的时间观念吧?

别说是十二时辰,即便是二十四时辰,我还是认为也不可能这么短的时间内构筑这么多事情,这是一部以唐朝为背景,讲述短短二十四小时内发生在长安城内,攻防双方围绕入侵 & 防御、检查 & 规避、攻击 & 应对 等系列主题,展开的一场场惊心动魄故事的小说。

这不仅让我想到了最近一直在研究的 SIEM/SOC 的建设,特此有感,写下本文。

攻防演练的悠久历史

围绕我们安全的主题,特别是具体到企业内部的安全建设,其实对我们绝大多数人来说,并不像想象中的那么的陌生和遥远。细想一下,如果把企业想象成一座城堡的话,攻击方和防守方之间的反复较量,其实就相当于一场持续的、没有硝烟的城堡攻防战争。就像小说《长安十二时辰》里面的故事一样,事情都会围绕长安城这座城市展开。

现实中的现代网络攻防,和历史上的古典城堡攻防事件是类似,对于一个“城堡”的攻防双方来说,从理念和需具备的能力上来讲没有什么新的东西,一切都有迹可循,我们完全能从历史的长河中发现已有的案例,来对标正在发生的事情;也可以在历史中进行归纳总结,得出城堡攻防的关键因素,用于指导现代的网络攻防。

安全分析&网络攻防的本质

我相信,虽然马伯庸老师在准备这本小说的时候,查阅了大量的资料,参考文献、古籍,甚至是去西安实地考察了很多回,但是他一定没有去学习过,如何构建一个安全信息和事件管理系统(SIEM),或是如何建设一个安全运营中心(SOC)。

但让我特别惊奇的是,马老师在写这样一部历史玄幻类小说的时候,居然完完全全的描述出了现代网络攻防双方,所需要到的各种能力和技术。特别是守城一方,在《长安十二时辰》中,马老师大量描述了作为守城方的靖安司所构建的系统,非常独创的杜撰出了一些在唐代不可能具备的能力,但又是现代攻防中必须具备的实实在在的能力。

安全是一个数据问题

首先,安全的本质是一个数据的问题,我们只有对企业内外部,所有的安全关联数据都拥有可见性的时候,才能够有效检查、有效的追踪、有效的分析,然后才能揪出漏洞、渗透、入侵,进而采取行动进行补救、缓解、修复和应对。

因此,我们可以看到,在《长安十二时辰》中,马伯庸老师为主管城防的靖安司配备的第一个能力就是大数据,其最大的特点之一是它是一个巨大的文库,可以随时查阅朝廷各部的文书资料,施展大案牍术做大数据的搜索。

而在安全里面,构建一个安全的大数据系统也是第一要务,这也是现在 SIEM 和 SOC 的底层核心。安全大数据具有以下要求。

安全数据 —— 不能有盲点

在小说里面,我们可以看到,细到每天进出长安城的人口,货物都有记录,分门别类,记录登录时间,停留地点,货物类型。并且,这些数据都是长久存储的历史数据。因此,我们看到靖安司的全面数据,帮助主角快速查到了突厥狼崽行踪、查到猛火雷原料的去向。

因此,对于企业攻防来说,有全面的数据是开展安全工作的主要前提,无论是即时发现,还是事后追溯,还是可疑事件的威胁捕获,还是用于建模分析的异常检测,都需要全面的实时数据和全量的历史数据。

因此,全面和不能有盲点是指:

  • 采集的数据要全
  • 保存的数据要久

安全数据 —— 要有规范,且能关联

在小说里面,靖安司不仅有大量的门禁数据,而且可以随时查阅朝廷各部的文书资料,这里涉及到大量数据的理解和关联的问题,其中有个情节,就是将户部的物品采购记录,结合城门的出入记录,发现了突厥狼卫偷运的猛火雷原料的问题。

通过小说我们不难发现,数据的整合分析是一件非常重要的事情。在现在企业内部,我们有不同的域,也有大量的网络设备,安全设备,数据来自不同的厂商、不同的部门。安全部门要能够通读这些数据,首先就要有一个统一的数据规范和标准,对不同日志提取出来的字段,有一致的解释、命名和类型,然后,要具备跨数据源的关联分析能力。这样,数据才不会成为一个个的数据孤岛,能够协同。《长安十二时辰》里面虽然没有特别强调和描述,但是其设定和从历史古代文书的规范看,就是靖安司(朝廷)必须具备良好规范的数据,并且能够随时调取,并关联分析。

数据系统要有快速分析和处理数据的能力

在小说中设定我们拥有足够的数据是比较轻松的事情,但大数据的处理能力,却无法通过大数据系统来提供。马老师在《长安十二时辰》中的设定,是通过最强大脑来提供大数据的处理能力,靖安司中的徐宾能够过目不忘,能施展大案牍术做大数据的搜索,他作为小说中前期的关键人物,在数个场景中通过强大的脑力,快速的找到数据里关于案情相关信息的记录,是推动剧情的关键。因此,安全分析系统必备的能力是要能在海量数据中进行快速检索。

注意,这里强调的点有两个:一是海量数据,前面我们说过了,数据要全面且要保存足够长时间。第二个是速度,速度是关键,天下武功唯快不破,对于安全攻防,速度直接代表了金钱,代表了挽救大厦于将倾的能力。无论是规则引擎的事件扫描,还是威胁捕获时的即兴搜索,都需要查询速度作为支撑

Elastic Security 的大数据基础

整个 Elastic Security 以 Elasticsearch 为基础来构建。我们通过 Elastic Security 来构建企业SIEM 或者 SOC 的时候,就可以很轻松的应对安全大数据的问题。

  • 首先,Elasticseach 本身是一个分布式的大数据搜索引擎,天然具备横向扩容的能力,可以存储海量的安全数据;
  • 并且 Elasticseach 以 json document 的形式存储数据,具备动态可变的 schema/mapping,可以灵活存储不同类型的结构化数据和非结构化数据,并随意添加新的字段,使其能够吸纳任意来源、格式、类型的安全数据;
  • 而对比其他具备搜索能力的大数据系统,Elasticseach 的优势在于首屈一指的全文检索、模糊查询能力,结合丰富的多维分析能力,内置的机器学习能力,高并发的支撑能力,再加上海量数据的毫秒级查询响应,使得 Elasticseach 能轻松应对安全大数据分析的工作。

1.png

除了避免数据盲点和提供足够的数据分析能力,其实对于构建 SIEM 或者 SOC 的一个重要考虑因素是单位数据的存储成本。

可以明确的一点是,安全运维数据,绝对是一个非常庞大的数据集,它包含来自不同域的数据(生产域,办公域,互联网域等),来自不同设备的数据(应用,硬件,网络,数据库等),并且因为回溯和审计的需求,可能需要保存很长的时间。迫于成本,我们可能会放弃部分数据,进而造成某些事件不可见或不可回溯、审计的问题。

而在最新的 Elasticsearch 7.10 版本上,我们提出了一个完美的解决方案,通过数据层和可搜索快照,我们能以极低的成本来维护所需的所有安全数据

2.png

安全建设需要对内外部环境梳理

马伯庸老师为靖安司配备的第二个能力,就是将其设为一个内外部数据和情报的中枢。

内部环境的梳理

小说中有一重要的概念,就是长安城“108坊”,靖安司内有长安城的沙盘模型,坐在屋子里,就能俯瞰长安全城。要把整个长安城的所有建筑,通道,马路,下水道都梳理清楚不是一件容易的事,并且这些资产还是可变的,可能有变动,有新增,有删除,虽然不易,但却必须。靖安司构建的这个沙盘模型对于快速的检查安全隐患,分析对手意图、潜入方式、攻击手段等,都有至关重要的作用。

同样,企业内部要能够梳理所有的安全资产、拓扑和漏洞:

  • 知道自己拥有哪些资产,动态掌握资产的信息
  • 分清楚企业内部的各种边界和域环境
  • 明了这些资产在不同域中的上下游网络链路和通道
  • 同时,能进行漏洞扫描,知道哪些资产上存在隐患

通过梳理这些数据,再结合我们之前谈到的安全数据(安全信息和事件),我们才能够做到知己知彼。了解自身的结构,有针对性的进行补救和补强,再去分析对手的可能行为,对核心资产和边缘资产进行不同级别的有效防护。

外部情报的汇入

仅了解自己是不够的,还需要足够的了解对手,方能做到百战不殆。小说中,靖安司不仅有长安城的所有信息,还掌握着长安城外的所有情报(对手情报),在突厥狼卫的剧情中,能够及时调阅和突厥相关的信息,了解到突厥可汗,突厥宰相和突厥狼卫的关系,方才知道幕后另有黑手。在现代安全攻防中,外部的威胁情报同样重要,比如,最新发布的零日漏洞,最新威胁的检测方式,最新的黑 ip,黑 url 等各种威胁情报,都是我们了解对手攻击,进行有针对性防御的重要信息

Elastic Security 对安全环境的梳理

Elastic Security 通过 Elasticsearch 强大的数据吸纳能力,以及丰富的开箱即用的数据源,和Kibana 上构建的基础架构分析能力,能够有效的帮助掌握内部动态、实时的安全资产信息

3.png

4.png

5.png

同时,通过功能强大的数据摄入模块,可有效的丰富和完善内外部威胁情报

6.png

7.png

完善的监控体系和有效的信息传导

马伯庸老师为靖安司配备的第三个能力是望楼体系。

靖安司在长安城的中心,有一座非常高大的建筑叫大望楼,它是望楼体系的核心,围绕大望楼,在整个长安城内一层层的分布着很多小望楼,每个望楼上都有士兵,可以通过旗和鼓声打出暗号,在整个长安城内传递信息。正是有了这个诡异的设定,整个故事才可以架设在十二个时辰的设定上。

这里给我们带来的启示点是:

  • 是安全的检测和响应必须要具有实时性,安全事件能够在不同的端点,部门进行快速的流转,并形成闭环
  • 另外要有安全的处理中心,能够统一的快速发起安全相关事件的处置和响应

因此,构建一个 SIEM/SOC 就是我们企业的靖安司,能够汇聚跟安全相关的信息,一旦检测出安全问题,能够通过这个安全运营中心中的“大望楼”,快速的下发相关操作。

比如,告警快速触达相关的安全分析人员进行告警分析,确认是否是需要处理的安全事件;当确认安全事件后,可以快速的升级,触达到对应的业务,网络,机架等部门进行安全处置和响应,有一个整体且闭环的完成安全运维流程

8.png

SIEM/SOC 三要素 —— 人、技术、流程

保卫长安光有个靖安司是不够的,静安司的核心并不是这个机构本身,而是其中的人,技术和流程。

企业安全需要仰仗具备不同能力的安全人员

在小说中,如果没有李泌(主角,Security Director/SOC manager),张小敬(主角,Security Analyst), 徐宾,姚汝能(Security Architect/Engineer)等人去规划,执行对应的安全工作,是不可能有最终的对抗胜利的。

我们要始终把安全建设,看成是一种攻防对抗的行为。所有的安全设施都只是工具,是让防御方用来抗衡入侵方的工具,不是依仗的主体。关键还是人和人之间的对抗,安全人员必须划分不同的角色,具备不同的技能。我们既要有安全的主管,又要有捕快;既要有防御工事的工人,又要有巡逻的士兵;

安全人员的思维方式

在小说中,主角李泌和张小敬,从突厥狼卫,到守捉郎,再到蚍蜉,再到最后的幕后黑手。一直的思维方式就是居安思危,一直假设有更加深层次的威胁,才最终能让幕后黑手浮出水面。做安全的,无论是在古代还是现代,永远不能有万事具备,高枕无忧的想法。

以下几点是现在面向各种APT攻击的安全人员必须具备的思维方式:

  • 假设侵入已经存在
  • 以检测(Detection)为导向的防御
  • 聚焦于漏洞利用阶段 (post-exploitation focus)

image.png

其实,这也是警示安全人员,千万不要沉迷于对已知威胁的防御,那只是工具该干的事。一个城堡总会有意向不到的漏洞,安全设备的边界防御固然重要,但这只是基础,而被渗透是必然,安全人员的工作重心应该是对可疑事件和未知威胁的捕获

必须组建威胁捕获团队

因此,我们看到,在《长安十二时辰》中,整个故事是以李泌和张小敬为主的安全团队,主动出击为引线而展开的。最有效的防御从来不是被动式的,所谓进攻就是最好的防御,无论是以前还是现代,我们都需要有四大名捕这样的捕快能主动出击,针对各种可以的事件,主动探查蛛丝马迹背后隐藏的信息,在一次有计划的攻击(Kill chain)完整完成之前,将其找出,并终止。

当然,现在不是每个企业都有足够的人力和资源去组建威胁捕获团队,但在财力允许的情况下,这是必须放在日程上的一件事。因为你的对手可能是处心积虑以企业为目标的黑客,这是一场脑力的对决,一个猫鼠的游戏,不是仅仅依赖购买几个设备和工具(捕鼠夹)就能稳操胜券的对局。

当然,我们仍然要为威胁捕获团队配备即兴搜索所需要的高效分析工具:

9.png

技术的对决

在现代的安全攻防中,不仅仅是脑力的对决,也是一场技术的对决,攻防双方都可能使用最新的技术,穷尽不同的方法,尝试去达到各自的目标。黑客也会使用云技术,也会用大数据,用机器学习生产 DGA 算法,会发动大量的僵尸机、肉鸡进行饱和攻击,同理,防守方也需要掌握对应的技术,进行有效的检测和响应。EDR,NTA,UEBA 都是构建 SOC 必须具备的技术能力,而 MITRE ATT&CK 则是知识库,帮助我们更好的了解对手的策略,技术和流程。

10.png

11.png

能够闭环处置的流程

在《长安十二时辰》中,我们也看到,整个长安城的安全,绝不仅仅是靖安司一个部门就能保证的。在不同的场景需要不同部门的参与,比如最终的灯会,我们看到有户部,工部,旅贲军,右骁卫,龙武卫,禁军等各个部门都需要参与其中,户部安排民众的出游时间,路线;工部负责灯会工程的建设,旅贲军,右骁卫,龙武卫,禁军有各自的防御任务,靖安司处置安全事件,需要其他部门的配合,否则就根本没有办法在熙熙攘攘,复杂运转的长安城中有效保证安全。

回到我们的现代网络攻防,当我们发生一个安全事件的时候,绝不仅仅是安全部门的事情,会涉及到业务,机架,网络,中间件,运维等不同部门,只有形成一个能闭环处置的流程,由安全发起,到最终安全检验完成,中间通过很多部门的配合才能够完成时间的处置。因此,有一个行之有效的闭环流程非常的重要,我们在构建一个 SIEM/SOC 的时候,就需要工具有这样的能力:能发起工单,对接企业内部的流程系统(ITOM),能设置合理的权限,能让不同的部门在统一的数据上协作。才能让流程有效运行起来

12.png

而在单一系统上构建这样的能力,更是能够事半功倍

13.png

14.png

15.png

SIEM/SOC 的建设的注意事项

通过分析《长安十二时辰》这个小说里面描写的惊心动魄的古代长安城的攻防场景,我们可以更加直观的了解到现今企业安全攻防,特别是现在国家级别黑客组织的兴起,各种 APT 组织,使用更为完善的攻击工具,更为系统的社交工程,更为丰富、复杂、耐心的攻击方式和链路,让我们的企业安全面临极大的挑战,就像《长安十二时辰》里面,一层套一层的攻击,不到最后,你都不知道究竟是谁在攻击你,究竟他潜伏了多久。

对手在持续的进步,持续的发展,因此,一个 SIEM/SOC 的建设也是一个持续优化和改进的过程。并且这里必须是人、技术和流程三位一体的持续改进,如果没有持续的投入是很难获得成效的。

可以查看Elastic Security 7.10上的最新功能,了解 Elastic Security 带给我们的新能力。

Elastic Security 7.10: https://www.elastic.co/blog/whats-new-elastic-security-7-10-0-correlation-cloud-visibility-detection
创作人简介:
李捷,专注于 Elastic Stack 的解决方案的设计和咨询。13 年软件行业从业经验,从嵌
入式开发,到后端 J2EE 应用和前端界面开发。从爬虫脚本,到区块链和大数据分析。
从开发工程师,到测试工程师和项目经理。 拥有全栈开发经验和丰富的项目实施经验,
同时也是一个活跃的知识分享者和社区活动者。
博客: https://lex-lee.blog.csdn.net/
相关实践学习
使用阿里云Elasticsearch体验信息检索加速
通过创建登录阿里云Elasticsearch集群,使用DataWorks将MySQL数据同步至Elasticsearch,体验多条件检索效果,简单展示数据同步和信息检索加速的过程和操作。
ElasticSearch 入门精讲
ElasticSearch是一个开源的、基于Lucene的、分布式、高扩展、高实时的搜索与数据分析引擎。根据DB-Engines的排名显示,Elasticsearch是最受欢迎的企业搜索引擎,其次是Apache Solr(也是基于Lucene)。 ElasticSearch的实现原理主要分为以下几个步骤: 用户将数据提交到Elastic Search 数据库中 通过分词控制器去将对应的语句分词,将其权重和分词结果一并存入数据 当用户搜索数据时候,再根据权重将结果排名、打分 将返回结果呈现给用户 Elasticsearch可以用于搜索各种文档。它提供可扩展的搜索,具有接近实时的搜索,并支持多租户。
相关文章
|
7月前
|
数据可视化 安全 关系型数据库
写给工程师的 MacBook 商用级大模型知识库部署方案(上)
写给工程师的 MacBook 商用级大模型知识库部署方案(上)
570 2
|
运维 安全 中间件
云计算万字长文 - 企业上云策略全览与最佳实践(长文)1
云计算万字长文 - 企业上云策略全览与最佳实践(长文)
544 0
|
存储 JSON 监控
APM监控 · 入门篇 · Android端测监控平台建设(1)
APM 全称 Application Performance Management & Monitoring (应用性能管理/监控) 性能问题是导致 App 用户流失的罪魁祸首之一,如果用户在使用我们 App 的时候遇到诸如页面卡顿、响应速度慢、发热严重、流量电量消耗大等问题的时候,很可能就会卸载掉我们的 App。这也是我们在目前工作中面临的巨大挑战之一,尤其是低端机型。
2942 0
APM监控 · 入门篇 · Android端测监控平台建设(1)
|
2月前
|
Web App开发 存储 监控
iLogtail 开源两周年:UC 工程师分享日志查询服务建设实践案例
本文为 iLogtail 开源两周年的实践案例分享,讨论了 iLogtail 作为日志采集工具的优势,包括它在性能上超越 Filebeat 的能力,并通过一系列优化解决了在生产环境中替换 Filebeat 和 Logstash 时遇到的挑战。
|
5月前
|
存储 弹性计算 数据可视化
|
7月前
|
新零售 人工智能 供应链
写给工程师的 MacBook 商用级大模型知识库部署方案(下)
写给工程师的 MacBook 商用级大模型知识库部署方案(下)
355 2
|
7月前
|
NoSQL 关系型数据库 API
写给工程师的 MacBook 商用级大模型知识库部署方案(中)
写给工程师的 MacBook 商用级大模型知识库部署方案(中)
274 1
|
存储 测试技术 数据库
云计算万字长文 - 企业上云策略全览与最佳实践(长文)2
云计算万字长文 - 企业上云策略全览与最佳实践(长文)
158 0
“阿里味”GitHub新春上新NO.1软件架构设计与业务架构融合手册
软件架构设计的本质,是对问题域空间反复运用演绎、抽象、归纳等方法,进而找到适合当前阶段的设计方案的过程。既要考虑软件随业务发展的纵横向扩展性,也要考虑软件自身的可行性、稳定性和可维护性等技术因素。
|
消息中间件 缓存 分布式计算
真牛!阿里最新发布这份《亿级高并发系统设计手册》涵盖所有操作
前言 我们知道,高并发代表着大流量,高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案,从而抵抗巨大流量的冲击,带给用户更好的使用体验。这些方案好似能操纵流量,让流量更加平稳得被系统中的服务和组件处理。 那我们改如何应对大流量的三种方式? 第一种方法:Scale-out。 第二种方法:使用缓存提升性能 第三种方法:异步处理 面试京东,阿里这些大厂遇到这些问题改怎么办? 秒杀时如何处理每秒上万次的下单请求? 如何保证消息仅仅被消费一次? 如何降低消息队列系统中消息的延迟?
下一篇
无影云桌面