安全团队依靠高质量的日志来进行大多数预防性安全工作。为了防止事件发生，需要观察到潜在的故障来源，而日志是此类洞察的重要来源。 当事件发生时，组织必须能够尽快响应并控制它们。 日志不仅对于查找问题的根源至关重要，而且还有助于确定适当的对策。
但是，如果组织没有正确的日志数据会发生什么？ 当发生未知或无法预见的事件时，我们如何了解为什么没有预见到它？
考虑以下情况：您在周一早上上班，作为安全事件响应工程师。 您一走进办公室，就被告知人力资源部突然无法访问其共享网络驱动器上的内容，其中包括一些高度敏感的数据。 进一步检查显示，驱动器上的所有文件和目录都已重命名为 .exe。 此时，您几乎可以肯定这是某种恶意软件的结果，您面临着安全事件。
作为一名经验丰富的专业人士，您知道从哪里开始调查：您检查您的安全监控解决方案以查看防火墙日志，您发现您的监控解决方案已经超过一周没有收集这些日志了。 查看您的防火墙，您注意到它被配置为仅保留最近 48 小时的日志。 您尽可能地追溯它们，但很明显，您需要比这更旧的日志才能获得任何有意义的信息。 接下来会发生什么？
在最佳情况下，您最终可以通过从所有网络设备收集日志以查找其他相关事件来消除可能的事件来源。 这是一个耗时的过程，但可能有助于解决难题。
最坏的情况是，您发现您的安全监控解决方案很长时间以来一直没有收到大量网络设备的日志，并且故障排除意味着您必须等到您的访问请求获得批准，然后手动登录到每个相关设备并手动跟踪您可以找到的所有相关信息。 没有任何简单的方法可以围绕任何这些信息进行透视，也没有可以观察的趋势信息。 在这种情况下，明智的做法是记住我们无法改变过去——而我们的过去通常会成为序言。
您和您的团队能够以多快的速度响应上述情况？ 如果您的日志流突然停止，您的团队需要多长时间才能意识到？ 他们能否快速识别故障并在几分钟或几小时内修复它？ 您将如何检测到它，以及是什么让您客观地相信这一点？ 如果您检测到中断，您知道如何恢复系统吗？ 谁将负责这样做？ 您首先如何构建一个强大的日志管道？
在本文中，我将尝试回答这些问题。
DFIR（数字取证与事件响应）中自动化面临的挑战
如今，几乎每个安全组织都在拥抱自动化，尽管其程度因行业和业务规模而异。 大多数科技公司都在云托管基础设施和物理数据中心空间上运行。 诸如 Google G Suite 或 Microsoft Office 365、第三方 HR 应用程序、内部或云托管版本的 GitHub 或 Bitbucket、防火墙、路由器、交换机和防病毒工具是一些常用基础设施的示例。 通常需要这些组件才能在当今的数字经济中运营一家小型或中型企业； 大型企业需要更大的技术栈。
对于安全事件响应团队来说，这至少有十几个不同的系统需要从中收集日志，并且这些系统中的每一个都以不同的方式处理日志处理和传输。 在极少数情况下，收集数据就像指定日志应发送到的中央日志服务器/存储桶一样简单。 但更多情况下，它需要在日志源和日志目标之间引入一系列代理，编写脚本以从源获取日志，找到安排它的方法，创建一个代理将其传输到目标等等。 正如 Lisanne Bainbridge 在 35 年前的研究论文中提出的那样，自动化的经典 讽刺之一是，尝试自动化最终会使系统比其手动对应物复杂得多。 此外，系统自动化的程度完全取决于自动化人员的创造力和想象力。
通过安全混沌工程获得新见解
有很多不同的方法来应对这一挑战。 一个可靠的起点是开始监控和警报日志趋势。 在昂贵的 SIEM（安全信息和事件管理）工具时代，相对容易地为日志流中不寻常的峰值和下降设置警报。 这可以针对 SIEM 接收日志的每个管道完成。 拥有一个集中式日志数据湖，并不断监控其访问和活动，被认为是最佳实践。
为了主动了解日志管道的运行状况，至少每年安排一次测试警报触发器的功能非常重要。 但是，根据我们的经验，管道在实施时会进行测试； 在此之后，团队完全依靠 SIEM 警报的质量来让他们知道管道是否已损坏。
考虑到此用例，我提出了一种替代方法：混沌工程。 混沌工程在站点可靠性工程 (SRE) 领域迅速普及，它是一种基于经验的系统方法，旨在解决大规模分布式系统中的混沌，并建立对其承受真实条件能力的信心。 团队通过在受控实验期间观察分布式系统来了解其行为。 用外行的话来说，混沌工程是有目的地破坏您自己的系统，以便观察和从结果中得出新的见解，包括它对系统产生的连锁反应。
一些读者可能认为这种做法类似于传统的红队或渗透测试，但实际上，它在目的和方法上都与两者不同。 红队的最终目标是通过欺骗性的对抗方法获得对敏感资源的访问权限，而不会对实时系统造成中断，从而确定安全预防控制的有效性。 然而，安全混沌工程的最终目标是通过仔细和有条不紊的系统实验来学习。 我们的方法侧重于将故障注入特定组件，以揭示系统中的未知和无法预见的问题，然后这些问题才会影响核心业务产品和服务的运营完整性。
作为智人，我们必须面对这样的事实：系统的发展速度快于我们的认知推理能力所能解释的速度。 尽管我们拥有先前的知识，但我们选择只看到我们想看到的东西，只听到我们想听到的东西。 我们的理解和信念反映了我们所相信的。 混沌工程的目的不是破坏事物，而是学习关于我们的复杂自适应系统如何真正工作的新信息，而不是我们认为我们知道的。
回到上面描述的事件日志记录示例，作为一个工程团队，我们假设系统运行正常。 这种错误每小时都会使公司损失数百万美元。 以 2018 年 7 月的亚马逊 Prime Day 中断为例，当时亚马逊每小时损失高达 3300 万美元，而工程师们则争先恐后地诊断和分类问题。 通过使用弹性技术（例如混沌工程），可以主动识别出这三个小时的中断。
在寻找意想不到的东西时，合乎逻辑的方法是客观地使其成为预期。 我们的系统发展如此迅速，变得如此复杂，以至于我们必须寻求新的方法（例如混沌工程）来更好地了解它们的工作方式，改进它们并预测其不可预测结果的非线性性质。
评论已关闭。