您希望 osquery 能做什么？ - The Trail of Bits 博客

欢迎阅读我们关于 osquery 系列文章的第三篇。截至目前，我们已经描述了五家企业安全团队如何使用 osquery，并回顾了他们遇到的问题。在第三篇文章中，我们聚焦于 osquery 的未来。我们询问用户：“您希望 osquery 能做什么？”我们收到的答案范围从小请求到可能颠覆事件响应工具市场的巨大进步。让我们先深入探讨这些“超级功能”。

osquery 超级功能

一些用户的建议可能从根本上扩展 osquery 的角色，从一个事件检测工具， potentially 允许它在预防和响应方面从商业工具中夺取 significant 市场份额（我们在第一篇博客文章中列出了其中一些）。这将是一件大事。一个免费开源工具，让安全团队能够访问通常仅限于昂贵付费服务客户的事件响应能力，对社区来说将是一笔意外之财。它可以 democratize 车队安全，并增强整个社区对攻击者的防御能力。以下是可能将 osquery 提升到新水平的功能：

对端点的可写访问

是什么： 目前，osquery 仅限于对端点的只读访问。这种访问允许程序检测和报告其监控的操作系统中的变化。通过 osquery 扩展的写访问将允许它编辑操作系统中的注册表并改变端点的行为方式。它可以使用这种访问在整个车队中强制执行安全策略。

为什么这很惊人： 写访问将把 osquery 从检测工具提升到预防领域。而不是简单地用 osquery 观察系统问题，写访问将赋予您直接从 SQL 接口强化系统的能力。应用程序白名单和执行、管理许可证、分区防火墙设置等都可能可用。

我们如何构建它： 如果构建不当，osquery 中的写访问可能弊大于利。写访问超出了 osquery 核心的范围。一些当前用户仅被允许在整个车队中部署 osquery，因为它有限的只读权限。通过 osquery 核心授予写访问将带来更高的安全风险以及系统中断的潜力。实现这一点的正确方法是使其可用于在初始化期间请求功能的扩展，并最小化此功能对核心的影响。

现实证明： 事实上，我们有一个等待批准的拉取请求，将支持通过扩展进行写访问！该代码启用扩展的写权限，但阻止核心内置表的写权限。

我们构建此功能是为了支持一个客户，该客户希望阻止恶意 IP 地址、域和端口，用于预防和反应用例。一旦此代码提交，我们的客户将能够下载我们的 osquery 防火墙扩展，使用 osquery 在整个车队中分区防火墙设置。

事件触发响应

是什么： 如果 osquery 读取指示攻击的日志条目，它可以自动响应，例如隔离受影响的端点。此超级功能将为 osquery 的能力添加自动预防和事件响应。

为什么这很惊人： 这将把 osquery 的能力提升到商业漏洞检测/响应工具的水平，但它是透明和可定制的。防御团队可以评估、定制并将 osquery 的事件响应能力与公司需求匹配，作为独立解决方案或作为另一个更通用响应套件的补充。

我们如何构建它： osquery 的自动事件响应可以灵活构建，允许安全团队定义自己的事件指标和首选反应。用户可以从已知更新的数据库中选择：通过 VirusTotal 的 URL 声誉、通过 ReversingLabs 的文件声誉、通过 OpenDNS 的活动连接远程地址的 IP 声誉等。用户可以选择匹配标准类型（例如，精确、部分、特定模式等），并规定响应，如增加日志记录频率、将关联的恶意 ID 添加到防火墙阻止列表，或调用外部程序采取行动。作为附加选项，将日志发送到外部分析工具的事件触发可以在不损害端点性能的情况下提供更复杂的响应。

现实证明： 不仅多个受访者渴望此功能；一些团队已经开始构建其初步版本。正如“团队目前如何使用 osquery？”中讨论的，我们与一个团队交谈，该团队通过将日志数据管道传输到 ElasticSearch 并使用 ElastAlert 在异常检测时自动生成 Jira 票证来构建事件警报。此示例未展示完整的响应能力，但说明了 osquery 如何实现及时的业务流程事件反应。如果 osquery 可以监控事件驱动的日志（FIM、进程审计等），基于检测到特定模式触发行动，并管理保护性响应，它可以提供有效的端点保护平台。

技术债务 overhaul

是什么： 许多开源项目携带“技术债务”。也就是说，一些代码工程构建为对短期目标有效，但不适合长期程序架构。分布式开发者社区各自为 slightly 不同的需求增强技术加剧了这个问题。解决此问题需要昂贵的协调和多个社区成员的努力来重建和标准化系统。

为什么这很惊人： 减少 osquery 的技术债务将将程序升级到可被更广泛安全团队采用的标准。在我们关于 osquery 痛点的研究中，用户引用了性能影响和可靠性作为组织领导采用 osquery 的主要关注点。最终，我们采访的团队赢得了争论，但可能有许多团队未获得使用 osquery 的绿灯。

我们如何构建它： 在组织内处理技术债务已经足够困难。在分布式社区中可能更难。除非开发者有 specific 动机处理非常困难的高价值低效问题，关闭问题的自然奖励偏向于较小努力。为了对抗这一点，社区领导者可以转储和排序所有技术债务问题 along a matrix of value and time，将所有高价值/低时间问题留给 individual 开源开发者，并汇集社区资源以解决更难的问题作为完整的开发项目。

现实证明： 我们知道汇集社区资源处理技术债务是有效的。我们已经这样做了一年多。Trail of Bits 已被多家公司委托构建对开源社区来说太大的功能和修复。我们利用此模型将 osquery 移植到 Windows，增强 FIM 和进程审计，以及更多我们兴奋地在未来几个月与公众分享的内容。通常，多个客户对构建相同事物感兴趣。我们能够汇集资源，使项目对每个参与者来说更便宜，而整个社区受益。

用户想要的其他功能

osquery 显示出超越端点监控的 considerable 潜力。然而，我们采访的企业安全团队和开发者表示，开源工具有改进空间。以下是我们从用户那里听到的一些其他请求：

• 查询的防护栏和规则： 目前，格式错误的查询或实践可能妨碍用户的工作流程。受访者希望有关 targeting 正确数据、在正确间隔查询、从推荐表收集以及针对不同环境的定制建议的指导。
• 增强部署选项： 用户寻求更好的工具来在整个车队中部署并保持这些实现更新。 Beyond recommended QueryPacks，管理员希望能够定义和选择跨多平台端点的平台特定配置。自动检测和部署独特系统和软件的配置是另一个 desired 功能。
• 集成测试、调试和诊断： 除了当前的调试工具，用户希望更多资源用于测试和诊断问题。新工具应帮助提高可靠性和可预测性，避免性能问题，并使 osquery 更易于使用。
• 增强事件驱动数据收集： osquery 支持通过 FIM、进程审计和其他表进行基于事件的数据收集。然而，这些数据源遭受日志记录实现问题，并且并非在所有平台上受支持。更好的事件处理配置、发布的最佳实践和数据收集的防护栏将大有帮助。
• 增强性能功能： 用户希望 osquery 用更少资源做更多事。这将导致整体性能增强，或允许 osquery 在低资源配置文件或任务关键性能要求的端点上操作。
• 更好的配置管理： 增强功能如自定义表和 osqueryd 计划查询针对不同端点环境将使 osquery 在增长的车队上更易于部署和维护。
• 支持离线端点日志记录： 用户报告希望取证数据可用性以支持远程端点。这将要求离线端点在本地存储数据 –- 包括失败查询的存储 –- 并在重新连接时推送到服务器。
• 支持常见平台： Facebook 为其基于 macOS 和 Linux 的端点车队构建了 osquery。PC 系统管理员直到我们去年的 Windows 移植才幸运。由于开发社区的努力，对其他操作系统的支持一直在稳步增长。尽管如此，仍然有限制。将此视为一个 umbrella 功能请求：支持所有操作系统上的所有功能。

列表不断增长

对当前和潜在的 osquery 用户来说不幸的是，Facebook 无法满足所有这些请求。他们通过开源 osquery 分享了一份巨大的礼物。现在由社区来推动平台向前发展。

好消息：这些功能请求都不是不可行的。定制工程只是对 individual 组织来说投资不经济。

在本系列的最后一篇文章中，我们将提出一个 osquery 用户共享开发成本的策略。受益的公司可以汇集资源并共同 targeting 特定功能。

这将加速公司淘汰其他更昂贵、 less 灵活和 less 透明的全套工具的速度。

如果任何这些项目与您的团队需求产生共鸣，或者如果您当前使用 osquery 并有另一个请求添加到列表中，请告诉我们。

如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News