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

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

osquery超级功能

一些用户的建议可以从根本上扩展osquery的角色，从一个事件检测工具，可能允许它在预防和响应方面从商业工具中窃取重要的市场份额（我们在第一篇博客文章中列出了一些）。这将是一件大事。一个免费的开源工具，让安全团队能够访问通常仅限于昂贵付费服务客户的事件响应能力，对社区来说将是一笔意外之财。它可以民主化车队安全，并增强整个社区对攻击者的防御能力。以下是可能将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

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

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

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

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

用户想要的其他功能

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

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

列表不断增长

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

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

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

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

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

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