今天本来打算发另一篇文章，这两周一直敲代码，所以没有时间磨练内容，所以先放鸽子了。

在调查ADDBecurommanyHub和Googlesscc这两个云平台的SOC时，我发现老外在SOC的建设

上和国内的理解有点不同，但背后依赖于强大的数据处理交互技术和内部的安全专家规则，特别

是在Chrondymas发表BackSbur时，我惊讶的不是其功能，而是他的pb级日志处理能力，通过调

查各种资料，BackSbur的高性能并不是简单的堆积计算能力考虑到大家的年末总结，我也可以

自由总结。

 

 

熟悉我的同学可能知道我从下半年开始做招聘广告(好的，这篇文章还是广告文)，人手有多少不足

，从今年下半年开始(正确地说上半年快结束的时候)一直埋头于开发和优化公司的安全运营平台，

不是功能难以理解和开发，而是团队的伙伴们实际上在数据处理和清洗的时间上远远超过了很多

功能的开发(大家都是过来人，多少都知道安全运营的业务)实际上，除了安全攻防专家经验的固

化(这一部分实际上是用Plusbook固化到SOAR系统)以外，更重要的是数据分析能力的固化，因

此下半年有机会磨练数据平台，自己研究安全运营平台背后的数据平台的建设。
 

 

前面我们说到了我们实际的安全建模和安全运营工作，大部分都是面向数据的工作，包括写规则

、查日志、做DFIR、追踪等，所以现在很多甲青队的同学，特别是感知和应对的同学，与其说是

防守能力的建设，不如面向数据工作。也许有人说，不是查日志，而是这么麻烦吗？Elastic三件

套直接解决啊。我不否认使用ElasticStack可以解决大多数安全问题(实际上Kibana使用的话，同

样可以作为SIEM使用)。包括我自己一开始就这么想(最初刚加入美团的时候，不知道为什么要用

HIVE查日志，内部也有ES这个分析引擎，直到自己自己分析日志进行检索，才发现事情并不像

我想的那么简单)，但是之后发现成本和公司的数据平台技术受到限制，ES不说吃资源，所需要

的日志在大部分的情况下，实际上没有相同的数据因此，我们需要在计算时间和计算资源之间寻

找平衡点。这个平衡点是在适当的场景中选择适当的计算方法。