Palantir的IR团队开发了ADS，分享了使用的流程框架以及在早期ADS开发中所遇到的陷阱，并在GitHub存储库上发布了示例ADS。

告警和检测策略（Alerting and Detection Strategies ，ADS) 是有效的事件响应（Incident Response，IR）和检测团队的关键要求之一。

良好运作的IR团队会投入时间和精力开发ADS。如果做得好，ADS策略可以提供非常强的检测信号，揭示异常和潜在的恶意活动。

如果做得不好，IR团队可能会淹没在大量的低效率告警中，导致告警疲劳、工作情绪问题，最终对检测和消除恶意活动的安全运营工作任务产生负面影响。

问题

ADS框架是一组关于告警和检测策略的设计、实现和落地的文档模板、流程或约定。

在同意这样的框架之前，Palantir在告警策略的实施方面面临着重大挑战。缺乏严谨性、文档、同行评审和总体质量标准，导致低质量告警检测部署到了生产系统。

这经常导致忽略告警和额外的工程时间、资源去修复和更新告警.....

一些可能会遇到临时的或不成熟的告警开发问题包括：

• 值班工程师可能不熟悉软件或目标操作系统

• 告警缺乏明确的指导，说明什么可能构成误报

• 告警没有对于误报结果的响应计划

• 告警未经过长期验证

• 告警可能基于狭隘的标准，这会产生大量的漏报结果

• 告警可能基于宽泛的标准，从而产生大量的误报结果

• 告警可能依赖于不正确的假设、不一致的数据来源或技术

• 告警在生产系统上线之前未经过审核

• 告警可能根本不需要人工干预

• 告警的优先级不一致或定义不清

• 告警在实施过程中没有真正的（足够的黑白数据验证）准确性测试

ADS Framework

ADS框架包括以下几个部分：

Goal

全局描述提供了ADS应该检测到的行为类型的简短明文描述。

Categorization

提供了将ADS映射到MITRE ATT＆CK框架中的相关条目，ATT＆CK为对手可能使用的各种后渗透技术和策略提供了一种通用描述语言。

将ATT＆CK框架映射到技术上，可以进一步调查技术，提供对ADS将被使用的killchain领域的参考，并可以进一步推动对告警间隙的洞察和指标。

比如在我们的环境中，我们有一个知识库，将我们所有的ADS映射到MITRE ATT＆CK框架的各个组件。当为新告警生成假设时，工程师可以简单地查看我们在个别ATT＆CK技术方面的最强或最弱之处。

Strategy Abstract

战略摘要是ADS功能的高级概述。

其中描述了告警寻找什么，使用了哪些技术数据源，进行了哪些富化，以及任何减少误报的步骤。

Technical Context

技术上下文提供了响应者理解告警所有组件所需的详细信息和背景。

这应该适当地链接到任何平台或工具知识，并应包括有关告警相关的垂直领域信息。

技术上下文部分的目标是为响应者提供一个默认包含的参考，使其能够对任何告警的潜在问题做出判断，即使他们没有关于ADS本身的垂直领域知识。

Blind Spots and Assumptions 

盲点和假设是已知的问题、假设和范围。

任何的自动化系统都不是完美的，系统可能因为各种问题无法运转，认识假设和盲点可以帮助其他工程师了解系统会无法启动或被对手击败的情况。

False Positives

由于错误配置、环境特异性或其他非恶意情况导致ADS失效的已知实例。

这些误报告警应在安全信息和事件管理工具（SIEM）中被抑制，以防止在发生已知误报的情况重复生成告警。

Validation

验证列出了生成触发此告警的准确性场景所需的步骤。

这类似于单元测试，并描述了工程师如何引起ADS的触发，这可以是生成告警的步骤的演示，触发ADS的脚本（例如红队模拟测试），或在告警测试和编排平台中使用的场景。

Priority

优先级描述了ADS可能被标记的各种告警级别。

虽然告警本身应该反映它被配置在SIEM中触发时的优先级（例如高、中、低），但在本节内容中应该详细介绍了特定优先级的标准。

Response

响应是在触发此告警时的一般响应步骤。这些步骤指导下一个响应者对警报进行分类和调查的过程。

Additional Resources 

附加资源是任何其他内部、外部或技术参考资料，可能有助于理解ADS

注意事项

在部署ADS之前，必须完成并审核该框架的每个组成部分。这可以确保任何给定的告警都有足够的文档，经过验证以确保长期稳定运营，并在生产部署之前进行审核。

​比如我们所有的生产或草稿告警都按照此模板进行记录，并将文档存储在稳定性、版本控制和集中化的位置（例如Wiki、GitHub条目等）。ADS后续更改，例如修改白名单、更改策略或记录其他盲点，应在修改时纳入ADS文档中。

在内部，Palantir使用类似于GitHub的系统对ADS进行维护，其中任何功能请求或错误都会作为ADS相应的问题进行发布，值班工程师将对相应的错误或功能请求进行分类、更改、然后在关闭问题之前更新ADS文档，此过程确保ADS文档保持最新状态，同时跟踪审计留下更改的记录。