osquery 超级功能

一些用户的建议可能从根本上扩展 osquery 的角色，从事件检测工具转变为可能抢占商业工具市场份额的预防和响应工具（我们在第一篇博客中列出了其中一些）。这将是一件大事。一个免费的开源工具，让安全团队能够获得通常只有昂贵付费服务客户才能使用的事件响应能力，对社区来说将是一笔意外之财。它可以 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、进程审计等），基于检测到特定模式触发行动，并管理保护性响应，它可以提供有效的终端保护平台。

技术债务重构

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

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

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

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

用户想要的其他功能

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

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

列表不断增长

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

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

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

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

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