您希望osquery能实现什么？

欢迎阅读我们osquery系列的第三篇文章。在前两篇中，我们介绍了五家企业安全团队如何使用osquery以及他们遇到的问题。在本文中，我们将聚焦osquery的未来发展。我们询问用户：“您希望osquery能实现什么？“收到的回答从小型需求到可能颠覆事件响应工具市场的重大进步应有尽有。让我们首先深入探讨这些"超级功能”。

osquery超级功能

部分用户的建议可能从根本上扩展osquery的角色，从事件检测工具转变为能够从商用工具手中夺取预防和响应市场份额的平台（我们在首篇博客中已列举部分案例）。这将意义重大——一款免费开源工具让安全团队获得通常只有昂贵付费服务客户才能拥有的事件响应能力，对整个社区将是巨大福音。它可能实现终端安全民主化，并增强整个社区对攻击者的防御能力。以下是能让osquery更上一层楼的功能：

终端写权限支持

功能说明：目前osquery仅限于对终端进行只读访问。这种访问权限使程序能够检测和报告其监控的操作系统变化。通过osquery扩展实现写权限将使其能够编辑操作系统注册表并改变终端运行方式，从而在整个终端群中强制执行安全策略。

重大意义：写权限将使osquery从检测工具升级为预防工具。您将能直接通过SQL接口强化系统，而不仅仅是观察系统问题。应用白名单与强制执行、许可证管理、防火墙设置分区等功能都将成为可能。

实现方案：如果实施不当，写权限可能弊大于利。该功能超出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并有其他要添加的请求，请告知我们。

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