Elastic 利用 Tines 实现 SIEM 调查自动化
Elastic 的信息安全团队最近详细介绍了他们使用 Tines 实现的工作流程自动化，旨在提高他们识别和应对网络安全威胁的能力。该系统会自动对来自其安全信息和事件管理 (SIEM) 系统的警报进行分类，从而增强了识别和优先处理真实威胁的能力。 亚伦·杰维特Elastic 首席信息安全分析师 II 详细阐述了实施 在博客文章中. 通过这种简化的工作流程，该团队在一个月内调查并解决了超过 50,000 条警报，每条警报在触发后几秒钟内即可得到处理。这种方法使团队能够专注于调查复杂的威胁，从而改善整体安全态势。 此前，Elastic InfoSec 团队创建了规则包，用于检测 用户和实体行为分析（UEBA）. 用户和实体行为分析（UEBA）分析来自用户和设备的活动数据，以建立正常行为标准。 安全团队意识到，如果 UEBA 警报来自受信任的设备，则可能会被忽略。他们的调查通常涉及根据 Elasticsearch 数据库检查警报的详细信息。如果发现匹配的活动，则警报可能是误报。 处理大量误报会导致分析师疲劳并错过威胁。因此，该团队考虑自动进行初始警报调查，排除误报并升级真正的威胁。 目前，Elastic 的系统将安全警报传输到 SOAR（安全编排、自动化和响应) 系统。然后，该 SOAR 系统使用查询自动对每个警报进行调查。根据结果，它会解决警报或将其上报给安全分析师进行进一步审查。 Jewitt 进一步解释了 叉齿 构建自动化分类工作流程。Elastic 的安全团队利用 Elastic Security 中的 Alert Actions 将警报数据传输到他们的 SOAR 解决方案。这是通过内置的 Tines 连接器或 webhook 实现的，该连接器或 webhook 以 ndjson 格式单独或批量发送警报。 自动分类标签（例如 Triage:All、Triage:Asset、Triage: Workstation）用于将规则路由到适当的分类路径。使用 […]
使 Postgres 查询速度提高 1,000 倍
Mattermost 在大型部署中使用 Elasticsearch 来减少数据库在运行搜索查询时承受的压力，同时返回更好的、经过微调的结果。为了实现这一点，Elasticsearch 需要索引我们要搜索的所有数据，以便在请求时可以快速检索数据。一旦数据被索引，一切都会按预期运行，我们的用户会很高兴，我们的开发人员也会很高兴，生活会很美好。 但是，我最近测试了很久没尝试过的事情：从头开始索引一个相当大的数据库（包含 1 亿条帖子）。当数据库已经建立索引后，后续对新帖子和文件的索引速度会非常快，因此 Elasticsearch 的正常使用是没有问题的，但从头开始索引速度很慢： 这张截图是我们的作业系统，它告诉我们 Elasticsearch 索引作业已经运行了大约 18 个小时，但还未完成一半的任务 🙁 并且进度不是线性的，越往后进度越慢！这里显然出了问题。 让我们先来调查一下这里到底是什么地方速度慢，因为有很多活动部件：可能是数据库、Mattermost 服务器、Elasticsearch 服务器、网络或资源不足的机器。 看看我们的 Mattermost 性能监控 Grafana 仪表板 当索引作业正在运行时，问题一目了然： 上图按持续时间显示了前 10 个数据库调用，这些调用可归结为（稍微简化）以下 Prometheus 查询： topk(10, sum(increase(mattermost_db_store_time_sum[5m])) by (method) / sum(increase(mattermost_db_store_time_count[5m])) by (method) ) 我们测量每个数据库方法完成所需的时间，取过去 5 分钟的平均值，并按秒绘制图表，仅显示前 10 种方法。 从图表上看，有一个明显的异常值： PostStore.GetPostsBatchForIndexing随着索引作业的进行，它花费的时间越来越多，最终达到 30 秒，然后超时。 查看代码，我们看到了导致所有这些问题的确切查询： SELECT Posts.*, Channels.TeamId FROM Posts […]