第一部分:进入先进安全监控世界的旅程

每天处理数百个安全警报是一项挑战。尤其是当很多误报浪费了我们的时间，占用了我们太多宝贵的时间来筛选。让我告诉你我们的安全团队是如何解决这个问题的，因为我们围绕JFrog产品构建了安全性。hth华体会最新官方网站

首先，让我向大家介绍一下我们的团队。

JFrog的安全工程师

JFrog Security - CSO办公室专注于保护客户数据，确保云基础设施的安全性，提供最高的产品和应用安全标准，并应对新出现的安全威胁。了解更多关于JFrog保安>

性能、可扩展性、易用性和灵活性

作为我们努力提高我们的流程和更好地满足我们不断增长的需求的一部分，我们决定从零开始建立我们的安全监控系统，并使其成为一流的。在研究了不同的方法后，我们决定创造一个可能会被认为是非常规的解决方案，包括以下两个主要部分:

1. 集装箱化我们的日志运输组件
2. 使用消息传递队列

这篇博文的目的是分享我们如何在高层次上解决每个曾经使用过传统安全监控系统的安全工程师/架构师所感受到的主要痛点。

那么，这篇博文是写给谁的呢?

• 如果您要决定您的安全监控系统/解决方案的架构应该是什么-这是为您准备的。
• 如果您厌倦了追踪日志收集器中的健康问题、导致索引问题的数据峰值，或者只是因为请求太多而导致数据库崩溃，那么这款应用非常适合您。

这篇博文将描述我们决定采用这些解决方案和最终架构的原因。希望分享我们的用例可以为您和您的组织提供额外的指导。这将是第一部分三篇博文,包括:安全监视(又名SIEM),自动化(又名SOAR)和机器人(又名聊天机器人)。

让我们从我们选择的解决方案的关键要点和建议开始。

注意:我们的团队选择解决所有问题并重新开始。但是，您可以选择只处理现有安全监视的某些部分，例如技术、警报通道或处理。

1.集装箱化日志运输组件

在大多数传统的安全监控系统中，日志发送者可能是您最大的故障点。这是因为保持它的运行可能是一项非常具有挑战性的任务，特别是在一个复杂的体系结构中，您会发现数十或数百个不同的服务。使用日志托运人的容器化版本会有很大帮助。

的好处：

• 节省大量的计算资源2022世界杯阿根廷预选赛赛程没有许多实例来运行服务。
• 更有弹性在“服务”死亡时设置重启策略的能力。
• 无争议的复苏如果服务失败或损坏，则无需重新构建服务。
• 增加了一层安全由于服务是隔离的，因此可以将凭据和其他秘密分开。

2.使用消息传递队列(MQ)

接下来，我们选择使用缓冲区(又名排队系统)。在本例中，我们选择使用卡夫卡。

的好处：

• 吸收峰值和过载-时不时地，你会收到一大堆你绝对没有预料到或从尺寸角度准备的原木。消息传递队列可以避免数据丢失、损坏和服务中断等问题。
• 备份-虽然它不是一个备份系统，你应该备份你的数据使用快照，桶等。使用消息传递队列可以帮助处理瞬时更改。升级一个版本，需要停止SIEM一个小时?没问题!您的某个节点是否更改了配置?来吧!
• 负载平衡并非所有日志摄取解决方案都知道如何实现流量负载平衡，MQ可以通过允许使用者平均分配负载来帮助实现这一点。

一个简单架构的例子:

(来源:“刚好够弹性栈用Kafka“elastic.co)

在左边，我们可以看到我们的日志托运人(例如DB, Filebeat, Syslog等)将数据发送到Logstash(如果日志托运人支持，也可以直接发送到MQ)，然后将其发送到消息队列(Kafka)。然后，使用者从MQ获取数据，并将其发送到SIEM (ELK Stack)。

每个环境都有自己的要求。这里有一些可用的指南，详细介绍了如何调整不同组件的大小:

• Elasticsearch -大小和容量规划
• Elasticsearch -服务定价计算器
• 对Elasticsearch集群的日志和指标进行基准测试和调整
• Elasticsearch指南-调整索引速度
• Elasticsearch指南-调整搜索速度
• Elasticsearch计算器

最终架构和基础设施

以下是我们最终架构的主要组成部分和动机:

日志来源/托运人

• 弹性组件可以避免兼容性问题。维护较少数量的组件类型更容易。例如，升级所有托运人只需要更改Docker镜像版本。
• 较小数量的分支(尽可能多)使事情变得简单，并帮助我们节省维护基础设施的时间。

消息队列(又名Kafka，如上所述)

• AWS管理基础设施，并为我们提供托管服务。
• 我们只管理应用方面的内容(主题、复制、保留、监控)。

Logstash“集群”

• 由于Logstash不能真正作为HA/Cluster运行，所以它不能被认为是一个集群。但是，让它作为Kafka的消费者执行基本上意味着与队列一起工作将允许平衡负载，从而在Kafka主题中产生更多分区。使用相同数量的线程来消耗它，可以让我们以一种平衡的方式更快地读取信息，并避免任何Logstash或Elasticsearch都不喜欢的峰值。
• 使用Logstash将日志整合到单个管道中，可以更容易地控制:日志操作，标记，丰富(例如Maxmind地理信息)，甚至将您喜欢的防火墙日志与来自MISP的OSINT匹配(资源:https://owentl.medium.com/enriching-elk-with-threat-intelligence-4813d3addf78）

Elasticsearch / Kibana

• 网上有很多很棒的Kibana入门教程，比如Docker上的弹性堆栈(ELK)．

更多额外的收获:

• 外包给托管服务/SaaS可以解放您的业务，使其专注于其优势，让您的团队专注于他们的主要任务和未来战略。
• 安全监控基础设施至关重要。我们都想防止服务中断。SaaS可以提供帮助，特别是如果您的团队很小，甚至还不存在的话。

结论

综上所述，以下是我们所取得的成就:

• 增加容量-我们获得了基础设施的稳定性和弹性，更容易的部署过程，排除故障的过程。更少的人需要掌舵=更多的时间做IR。(下一个谜题，即自动化，将在下一篇文章中讨论)
• 改进了每个工程师的时间投入-拥有可靠的监控解决方案意味着花费更少的调查时间。消除诸如缺少日志、解析问题和缺乏数据等问题确实会对时间效率产生重大影响。
• 微调-作为一名SIEM工程师，这是我第一次可以说我不再需要生活在服务中断的恐惧中。在一个相对稳定的解决方案上运行我们的基础设施(例如Kubernetes, Docker)允许我们自修复不同组件的故障，这些故障曾经破坏了日志记录管道。

希望我们的旅程能够帮助其他团队重新思考他们的安全日志基础设施。

伸出手来，问问题，分享你的想法、担忧和想法LinkedIn．

最后但并非最不重要的是，我们正在招聘!请查看空缺职位>