通过集中日志记录减少安全风险

集中日志并构建日志数据以进行处理可以降低与日志记录不足相关的风险。
161 位读者喜欢这篇文章。
Through the looking glass: Security and the SRE

Opensource.com

日志记录和日志分析对于保护基础设施至关重要,尤其是在我们考虑常见漏洞时。本文基于我在 FOSDEM'19 上的闪电演讲让我们使用集中日志收集来让事件响应团队满意,旨在提高人们对日志记录不足带来的安全问题的认识,提供一种避免风险的方法,并倡导更安全的实践(免责声明:我为 NXLog 工作)。

为什么需要日志收集,又为什么需要集中日志记录?

具体来说,日志记录是附加到磁盘的记录序列。在实践中,日志可以帮助您在尝试查找异常行为的原因时调查基础设施问题。当您拥有具有自身标准和格式的异构系统,并且希望能够以可靠的方式处理这些系统时,就会出现挑战。这通常以元数据为代价。集中日志记录解决方案需要通用性,而这种通用性通常会消除许多开源日志记录工具提供的丰富的元数据。

日志记录和监控不足的安全风险

开放 Web 应用程序安全项目 (OWASP) (OWASP) 是一个非营利组织,通过出色的项目(包括许多专注于软件安全的 工具)为行业做出贡献。该组织定期报告应用程序开发人员和维护人员面临的最危险的安全挑战。在其关于十大最关键 Web 应用程序安全风险的最新报告中,OWASP 将日志记录和监控不足添加到其列表中。OWASP 警告了在以下类型的场景中,由于日志记录、检测、监控和主动响应不足而导致的风险。

  • 重要的可审计事件,例如登录、登录失败和高价值交易未被记录。
  • 警告和错误不会生成日志消息,或者日志消息不足或不清楚。
  • 日志仅存储在本地。
  • 应用程序无法实时或接近实时地检测、升级或警报正在进行的攻击。

这些情况可以通过集中日志(即,不将日志存储在本地)和构建日志数据以进行处理(即,在警报仪表板和安全套件中)来缓解。

例如,想象一下 DNS 查询导致恶意站点,名为 hacked.badsite.net。通过 DNS 监控,管理员可以监控和主动分析 DNS 查询和响应。DNS 监控的效率依赖于充分的日志记录和日志收集,以便捕获潜在问题,以及构建生成的 DNS 日志以进行进一步处理。

2019-01-29
Time (GMT)  	Source            	Destination       	Protocol-Info
12:42:42.112898 SOURCE_IP         	xxx.xx.xx.x       	DNS  	Standard query 0x1de7  A hacked.badsite.net

您可以自己尝试一下,并通过 NXLog 社区版 运行其他示例和代码片段(再次声明:我为 NXLog 工作)。

重要提示:非结构化数据与结构化数据

花一点时间考虑日志数据格式很重要。例如,让我们考虑一下这条日志消息

debug1: Failed password for invalid user amy from SOURCE_IP port SOURCE_PORT ssh2

此日志包含预定义的结构,例如冒号前的元数据关键字 (debug1)。但是,日志字段的其余部分是非结构化字符串(Failed password for invalid user amy from SOURCE_IP port SOURCE_PORT ssh2)。因此,虽然该消息以人类可读的格式轻松可用,但它不是计算机可以轻松解析的格式。

非结构化事件数据带来了一些限制,包括难以解析、搜索和分析日志。重要的元数据通常以自由格式字符串的形式设置在非结构化数据字段中,如上面的示例所示。日志管理员在尝试标准化/规范化日志数据并集中其日志源时,会在某个时候遇到这个问题。

下一步去哪里

除了集中和构建日志之外,请确保您正在收集正确的日志数据——Sysmon、PowerShell、Windows EventLog、DNS 调试、NetFlow、ETW、内核监控、文件完整性监控、数据库日志、外部云日志等等。还要有正确的工具和流程来收集、聚合和帮助理解数据。

希望这为您提供了一个起点,可以跨各种来源集中日志收集;将它们发送到外部来源,如仪表板、监控软件、分析软件、专用软件,如安全信息和事件管理 (SEIM) 套件等。

您的集中日志记录策略是什么样的?在评论中分享您的想法。

User profile image.
NXLog 日志收集套件的技术传播者,之前从事安全文件传输软件 | 喜欢旅行,也是语言学习者(法语、德语),一个 🏴‍☠️ |

评论已关闭。

© . All rights reserved.