Elastic 发布检测工程行为成熟度模型

检测工程行为成熟度模型

在 Elastic，我们认为安全是一个旅程，而不是终点。随着威胁的演变和攻击者变得更有效，安全团队必须不断调整和改进其流程，以保持领先地位。有效安全计划的关键组成部分之一是开发和管理威胁检测规则集。这些规则集对于识别和响应安全事件至关重要。然而，这些规则集的质量和有效性直接受到管理它们的团队的流程和行为的影响。

为了应对威胁检测工程中不断变化的挑战，并确保安全团队之间的一致改进，我们定义了检测工程行为成熟度模型 (DEBMM)。该模型与其他模型和框架相辅相成，为安全团队提供了一种结构化的方法，以持续改进其流程和行为。通过关注团队的流程和行为，该模型确保有效地开发、管理和改进检测规则集，而无论个人或具体规则集如何。这种方法促进了持续改进的文化，并提高了威胁检测能力的一致性。

检测工程行为成熟度模型概述了安全团队要实现的五个成熟度级别（基础级、基本级、中级、高级和专家级）。每个级别都建立在前一个级别之上，指导团队完成一个结构化和迭代的过程，以增强其行为和实践。虽然团队可能会在不同的级别展示行为，但不建议跳过或降低先前级别的标准优先级。始终满足每个级别的期望对于为进步奠定坚实的基础至关重要。然而，随着威胁和技术的演变，随着时间的推移衡量成熟度变得具有挑战性，使得难以以常青的方式定义成熟度。该模型强调持续改进，而不是达到固定目标，反映了安全工作的持续性。

请注意，在当前级别的行为之外，尝试更高等级的行为是可能且有时是必要的。例如，尝试增强高级 TTP 覆盖范围可能涵盖直接风险或威胁，从而进一步培养基本级别工程师的专业知识。这种灵活性确保安全团队可以优先考虑关键改进并适应不断变化的威胁，而不会感到需要达到每个级别的完美而受到约束。成熟度的双重维度确保了一种平衡的方法，培养了持续增强和适应的文化。此外，该模型旨在补充安全领域中广泛采用的框架，通过专注于支持有效检测规则集管理的团队流程和行为的成熟度，增加了独特的价值。

在表中列出的几个参考中，检测工程成熟度矩阵与目标和方法最相关。该矩阵为流程、技术和团队技能定义了精确的成熟度级别，而 DEBMM 通过强调工程行为和实践的持续改进来建立在此基础之上。它们共同为提高检测工程能力提供了一种全面的方法，确保在管理检测规则集时具有结构和行为上的卓越性，同时描述了通用的词汇。

关于观点和模型重要性的一点说明

具有不同背景的人员通常会执行检测工程。管理检测工程流程的人员必须认识并赞扬不同背景的价值；DEBMM 是关于个人、供应商和用户的团队，每个人都为流程带来了不同的观点。该模型为后续更强大的框架奠定了基础，补充了先前提到​​的现有框架，同时考虑了其他观点。

什么是威胁检测规则集？

在我们深入研究使我们的规则集成熟的行为之前，让我们首先定义这个术语。威胁检测规则集是一组规则，其中包含信息和某种形式的查询逻辑，试图匹配收集数据中的特定威胁活动。这些规则通常具有模式、有关预期目的的信息以及针对其特定查询语言格式化的查询，以匹配威胁行为。以下是一些公共威胁检测规则集的示例

• Elastic：检测规则 | Elastic Defend 规则
• Sigma：Sigma 规则
• DataDog：检测规则
• Splunk：检测
• Panther：检测规则

检测规则集通常介于简单的入侵指标 (IOC) 匹配和可编程检测（例如在 Panther 中用 Python 编写的检测）之间。它们平衡了灵活性和能力，尽管它们受到检测脚本语言的设计偏差和检测引擎功能的限制。重要的是要注意，本讨论侧重于 SIEM（安全信息和事件管理）系统中常用的基于搜索的检测规则。其他类型的检测（包括流上检测和基于机器学习的检测）可以补充 SIEM 规则，但本模型未明确涵盖这些检测。

可以根据特定标准进一步对规则集进行分类。例如，可以评估 Elastic 检测规则存储库中的 Amazon Web Services (AWS) 规则集，而不是基于所有可用数据源的规则。其他类别可能包括所有与云相关的规则集、凭证访问规则集等。

为什么规则集成熟度很重要

问题： 使用哪种规则集并不重要；它们都受益于一个促进有效性和严谨性的系统。如果使用临时或不存在的成熟度系统，以下问题会更加突出

• SOC 疲劳和低检测准确率：管理大量警报的压倒性性质，通常会导致 SOC 分析师精疲力竭，再加上低保真检测逻辑和高误报 (FP) 率，导致大量警报不是实际威胁，并且无法准确识别恶意活动。
• 缺乏上下文信息和糟糕的文档：触发警报但没有足够的上下文信息来理解事件的重要性或缺乏操作指南的检测规则，再加上检测规则的文档不足，包括其目的、逻辑和预期结果。
• 规则质量不一致：检测规则的质量和有效性存在差异。
• 过时的检测逻辑：必须更新检测规则以反映最新的威胁情报和攻击技术。
• 规则过于复杂：检测规则过于复杂，导致难以维护和理解。
• 缺乏自动化：规则更新、警报分类和响应依赖于手动流程。
• 测试和验证不足：检测规则必须在部署前进行彻底的测试和验证。
• 规则集不灵活：检测规则无法适应环境变化或新的攻击技术。
• 缺乏指标、衡量和覆盖范围洞察：需要更多指标来衡量检测规则在不同领域的有效性、性能和覆盖范围。
• 孤立的威胁情报：威胁情报必须与检测规则集成，否则会导致威胁检测的碎片化和不完整。
• 无法优先处理新规则的创建：如果没有成熟度系统，团队可能会专注于快速获胜或更令人兴奋的领域，而不是真正需要的东西。

机遇： 此模型鼓励采用结构化的方法来开发、管理、改进和维护高质量的检测规则集，帮助安全团队

• 通过优化警报数量和提高准确性来减少 SOC 的疲劳。
• 通过定期更新和经过良好测试的规则来提高检测保真度。
• 确保整个规则集中检测逻辑的一致性和高质量。
• 集成上下文信息和威胁情报以获得更明智的警报。
• 自动化日常流程以提高效率并减少人为错误。
• 持续衡量和改进检测规则的性能。
• 保持领先于威胁，维持有效的检测能力，并增强其整体安全态势。

了解 DEBMM 结构

DEBMM 被划分为与标准相关的层级，以定量和定性地传达不同级别的成熟度，每个级别都有助于清晰的进展结果。它旨在指导安全团队通过一套结构化的行为来开发、管理和维护其检测规则集。

层级

DEBMM 采用多维方法来衡量成熟度，既包括高层级的层级，也包括每个层级内细粒度的行为级别。第一个维度涉及整体成熟度层级，应逐步满足标准以反映整体成熟度。第二个维度与每个层级内的行为级别有关，强调具体的实践和改进，以体现成熟度。这种结构允许灵活性，并认识到成熟度可以通过多种方式来展示。第二个维度与 NIST 网络安全框架 (CSF) 的成熟度级别（初始、可重复、已定义、已管理和已优化）松散对齐，为安全团队提供了一个熟悉的参考点。例如，每个 DEBMM 层级内的定性行为和定量测量都反映了 NIST CSF 所倡导的迭代改进和结构化流程管理。通过与这些原则保持一致，DEBMM 确保团队在逐步提高其层级的同时，也体现了 NIST CSF 中看到的最佳实践和结构化方法。

在高层级上，DEBMM 由五个成熟度层级组成，每个层级都建立在前一个层级的基础上

1. 第 0 级：基础 - 规则开发和管理没有结构化的方法。规则是临时创建和维护的，几乎没有文档、同行评审、利益相关者沟通或人员培训。
2. 第 1 级：基本 - 建立基准规则、系统规则管理、版本控制、文档、定期审查威胁态势以及初步人员培训。
3. 第 2 级：中级 - 专注于持续调整规则以减少误报，识别和记录差距，进行彻底的内部测试和验证，以及为人员提供持续的培训和发展。
4. 第 3 级：高级 - 系统地识别并确保不会遗漏合法的威胁（漏报），参与规则的外部验证，涵盖高级 TTP，以及为分析师和安全专家提供高级培训。
5. 第 4 级：专家 - 此级别的特点是高级自动化、与其他安全工具的无缝集成、通过定期更新和外部协作进行持续改进，以及为所有级别的安全人员提供全面的培训计划。主动威胁搜寻在维持强大的安全态势方面起着至关重要的作用。它补充了规则集，通过识别可以纳入检测规则的新模式和见解来增强管理流程。此外，虽然供应商通常不这样做，但将检测开发作为事件响应的后阶段可以提供有价值的见解并提高检测策略的整体有效性。

理想情况下，应遵循最符合安全团队需求的方法（例如，按顺序、按最高风险优先级等）逐步提高这些层级。逐步提高层级会增加运营成本，在没有适当的预算和人员的情况下匆忙完成成熟度模型可能会导致倦怠并使情况恶化。跳过较低层级的基础实践会削弱较高层级中更高级活动的有效性。

始终如一地满足每个层级的期望，可确保为进入下一级别奠定坚实的基础。组织应努力迭代并持续改进，认识到成熟度是动态的。专家级别代表着成熟度的高级状态，但这并不是最终目的地。它需要持续的承诺和适应才能保持在该级别。组织可能会根据评估的频率和准确性，其成熟度级别会发生波动。这就是为什么重点应该放在交互式开发上，并认识到根据组织特定的需求和资源，层级内不同的成熟度级别可能是合适的。

标准和级别

每个层级都分解为安全团队必须满足的特定标准。这些标准涵盖了检测规则集管理的各个方面，例如规则创建、管理、遥测质量、威胁态势审查、利益相关者参与等。

在每个标准中，都有定性行为和定量测量来定义成熟度级别

• 定性行为 - 规则集状态： 这些主观评估基于规则集及其文档的质量和完整性。它们提供了一种评估规则集当前状态的方法，帮助威胁研究人员和检测工程师**以结构化的方式理解和阐明其规则集的成熟度。尽管个人观点可能会影响这些行为，并且评估者之间可能存在差异，但它们对于初始评估和提供有关规则集状态的详细见解很有帮助。
• 定量测量 - 维持状态的活动：这些活动提供了一种结构化的方式来衡量维持或改进规则集的活动和流程。它们旨在更可靠地比较不同规则集的成熟度，并帮助跟踪一段时间内的进展。虽然自动化可以帮助一致地衡量这些指标，反映最新的成熟度状态，但每个组织都需要为自己的特定环境定义理想状态。确定和计算这些指标的练习将为成熟度过程做出重大贡献，确保这些衡量标准与安全团队的独特需求和目标相关且量身定制。将此模型用作指导，但根据您的组织要求和目标建立并调整具体的计算和指标。

与层级类似，定性和定量测量中的每个级别都建立在前一个级别的基础上，表明检测规则集管理方法的成熟度和复杂性不断提高。目标是为安全团队提供明确的结果和路线图，以便系统地、持续地改进其检测规则集。

从基本级到专家级所需的努力范围

从基本级到专家级的过渡需要持续的重大努力。随着团队逐步提高层级，活动的复杂性和深度也会增加，需要更多的资源、高级技能和全面的策略。例如，从第 1 级过渡到第 2 级涉及系统的规则调整和详细的差距分析，而提升到第 3 级和第 4 级则需要强大的外部验证流程、主动威胁搜寻和复杂的自动化。这一过程需要承诺、持续学习和适应不断变化的威胁态势。

第 0 级：基础

团队必须在基础层级建立规则开发和管理的结构化方法。检测规则可能开始是临时创建和维护的，几乎没有或根本没有同行评审，并且通常需要适当的文档和利益相关者沟通。威胁建模最初很少影响检测规则的创建和管理，导致对威胁检测采取被动而非主动的方法。此外，可能很少有或根本没有记录或计划的规则开发和更新路线图，导致不一致和不协调的工作。

建立定义良好检测规则的标准对于引导团队走向更高的成熟度级别至关重要。重要的是要认识到，规则在其初期可能并不完美，并且需要随着时间的推移不断改进。如果分析师致力于持续改进和增强规则，这是可以接受的。我们根据我们的经验提供了关于良好规则的建议，但组织必须根据其可用的能力和资源定义其完美的规则。

无论规则集如何，规则都应包括特定字段，以确保其有效性和准确性。不同的成熟度级别将以不同的完整性和准确性来处理这些字段。虽然更多内容会提供更多出错的机会，但规则的质量应随着规则集成熟度的提高而提高。例如，具有更少误报的更好查询、具有详细信息的更多描述以及最新的 MITRE ATT&CK 信息是更高成熟度的指标。

通过建立并逐步改进这些标准，团队可以提高其检测规则集的质量和有效性。从根本上说，它始于开发、管理和维护单一规则。即使在最基本的层面上，为规则开发和更新制定路线图也可以提供方向，并确保系统地跟踪和传达改进情况。大多数字段应根据定义的模式进行验证，以提供一致性。有关更多详细信息，请参阅示例规则字段。

标准

规则开发和管理的结构化方法

• 定性行为 - 规则集的状态
  • 初始：没有结构化方法；规则是随机创建的，没有文档。
  • 可重复：最小的结构；一些规则是在主要文档中创建的。
  • 已定义：规则创建的标准化流程，具有详细文档，并与定义的模式保持一致。
  • 已管理：定期审查和更新规则，确保一致性并遵守文档化的标准，并有利益相关者的参与。
  • 已优化：基于反馈和不断演变的威胁进行持续改进，具有自动化规则创建和管理流程。
• 定量衡量 - 维护状态的活动
  • 初始：没有正式的规则创建活动。
  • 可重复：零星地创建规则，监督或审查最少；少于 20% 的规则具有完整文档；少于 10% 的规则与定义的模式对齐；创建的规则不经过任何正式的审批流程。
  • 已定义：定期创建和记录规则，其中 50-70% 与定义的模式和同行评审流程对齐。
  • 已管理：全面的创建和管理活动，其中 70-90% 的规则具有完整文档和正式的审批流程。
  • 已优化：完全自动化和集成的规则创建和管理流程，其中 90-100% 与定义的模式对齐，并持续更新文档。

检测规则的创建和维护

• 定性行为 - 规则集的状态
  • 初始：规则是临时创建和修改的，没有版本控制。
  • 可重复：偶尔更新规则，但仍需要系统化的流程。
  • 已定义：规则更新的系统化流程，包括版本控制和定期文档。
  • 已管理：定期的、结构化的更新，具有详细文档、版本控制和利益相关者的沟通。
  • 已优化：通过自动化更新、全面文档和积极的利益相关者参与，持续改进规则。
• 定量衡量 - 维护状态的活动
  • 初始：维护检测规则不需要正式的活动。
  • 可重复：规则是零星更新的，每年审查的规则少于 50%；超过 30% 的规则缺少或不完整描述、参考或文档；少于 20% 的规则经过同行评审；少于 20% 的规则包含升级程序或指南；少于 15% 的规则具有关联的元数据，用于跟踪规则的有效性和修改。
  • 已定义：定期更新，每年审查的规则为 50-70%；大多数规则都有详细描述、参考和文档；50% 的规则经过同行评审。
  • 已管理：全面更新，每年审查的规则为 70-90%；大多数规则都有完整的描述、参考和文档；70% 的规则经过同行评审。
  • 已优化：自动化更新，每年审查的规则为 90-100%；所有规则都有完整的描述、参考和文档；90-100% 的规则经过同行评审，并包含升级程序和指南。

已记录或计划的路线图

• 定性行为 - 规则集的状态
  • 初始：没有为规则开发和更新记录或计划路线图。
  • 可重复：一些规则存在基本路线图，偶尔更新和与利益相关者沟通。
  • 已定义：大多数规则都记录了全面的路线图，定期更新并有利益相关者的参与。
  • 已管理：详细、定期更新的路线图，涵盖所有规则，并积极与利益相关者沟通和参与。
  • 已优化：动态、持续更新的路线图，集成到组织流程中，与利益相关者充分参与，并与战略目标保持一致。
• 定量衡量 - 维护状态的活动
  • 初始：没有记录规则开发和更新的路线图。
  • 可重复：为少于 30% 的规则记录了基本路线图；每年更新路线图或举行利益相关者会议少于两次；少于 20% 的规则有计划的更新时间表；没有跟踪路线图进度的正式流程。
  • 已定义：为 50-70% 的规则记录了路线图；定期更新和利益相关者会议；50% 的规则有计划的更新时间表。
  • 已管理：为 70-90% 的规则制定了全面的路线图；频繁更新和利益相关者会议；70% 的规则有计划的更新时间表并跟踪进度。
  • 已优化：为 90-100% 的规则制定了完全集成的路线图；持续更新和积极的利益相关者参与；90-100% 的规则有计划的更新时间表并有正式的跟踪流程。

执行的威胁建模

• 定性行为 - 规则集的状态
  • 初始：没有执行威胁建模。
  • 可重复：偶尔进行临时威胁建模，对规则创建的影响最小，不考虑数据和环境的具体情况。
  • 已定义：定期进行威胁建模，使用结构化流程影响规则创建，同时考虑数据和环境的具体情况。
  • 已管理：将全面的威胁建模集成到规则创建和更新中，并提供详细文档和利益相关者的参与。
  • 已优化：使用实时数据集成进行持续的、积极的威胁建模，影响规则创建和管理的各个方面，并充分与利益相关者进行沟通。
• 定量衡量 - 维护状态的活动
  • 初始：没有正式的威胁建模活动。
  • 可重复：零星的威胁建模工作；每年进行的威胁建模演习少于一次，文档或影响分析最少；威胁模型每年审查或更新少于两次；少于 10% 的新规则是基于威胁建模的结果，并且数据和环境的具体情况没有得到一致考虑。
  • 已定义：定期进行威胁建模工作；每年进行一到两次演习，并提供详细文档和影响分析；威胁模型每季度审查或更新一次；50-70% 的新规则是基于威胁建模的结果。
  • 已管理：全面的威胁建模活动；每年进行三到四次演习，并提供详细文档和影响分析；威胁模型每双月审查或更新一次；70-90% 的新规则是基于威胁建模的结果。
  • 已优化：持续的威胁建模工作；每月进行演习，并提供实时文档和影响分析；威胁模型持续审查或更新；90-100% 的新规则是基于威胁建模的结果，同时考虑数据和环境的具体情况。

第一层：基本

基本层涉及创建覆盖基本威胁的基线规则。这包括区分核心保护的基线规则和其他支持规则。建立系统化的规则管理，包括版本控制和文档。重点是提高和维护遥测质量，并定期审查威胁态势变化。在 Elastic，我们始终遵循“检测即代码 (DAC)”方法进行规则管理，这帮助我们维护了规则集。我们最近公开了一些内部功能，并为社区记录了核心 DAC 原则，以帮助改进您的工作流程。

标准

创建基线

创建基线规则涉及开发一组基础规则以覆盖基本威胁。此过程首先要了解环境和可用数据，确保规则是根据组织的特定需求和能力量身定制的。重点应放在关键战术上，例如初始访问、执行、持久性、特权提升、命令和控制，以及由威胁建模和范围确定的关键资产。基线被定义为在这些战术或资产中检测关键威胁所需的最低规则，并认识到并非所有技术都可能被覆盖。关键战术被定义为攻击生命周期的初始阶段，攻击者在此阶段获取入口、建立据点并提升特权以执行其目标。主要威胁被定义为可能对组织造成重大损害或破坏的威胁，例如勒索软件、数据泄露和未经授权的访问。支持规则（例如 Elastic 的构建块规则 (BBR)）有助于增强整体检测能力。

考虑到 SIEM 的发展和端点检测和响应 (EDR) 解决方案的集成，对于使用 EDR 的用户来说，还有另一种替代的初始步骤。只有一些 SIEM 用户拥有 EDR，因此此步骤可能仅适用于某些用户，但组织应验证其 EDR 是否足以覆盖基本的 TTP。完成此验证后，您可以针对您环境中关注的特定威胁补充该覆盖范围。确定高价值资产，并分析其典型的主机和网络行为。开发规则以检测偏差，例如新软件安装或意外的网络连接，以确保根据您的需求量身定制全面的安全态势。

全面的文档不仅包括基本描述，还包括有关每个规则的详细解释、调查步骤和背景信息。例如，通用文档说明了规则的目的及其查询逻辑。相比之下，全面的文档提供了对规则意图的深入分析、其应用背景、详细的调查步骤、潜在的误报和相关规则。全面的文档确保安全分析师拥有有效利用和维护规则所需的所有必要信息，从而实现更准确和可操作的检测。

它将从解释规则背后技术的初始背景开始，概述风险以及用户为什么应该关注它们，并详细说明规则的作用及其工作方式。接下来是可能的调查步骤，包括分类、范围界定和详细调查步骤，以彻底分析警报。关于误报分析的部分还提供了识别和减轻误报的步骤，以确保规则的准确性和可靠性。文档还将列出相关规则，包括其名称和 ID，以提供检测情况的全面视图。最后，将概述响应和补救措施，以指导分析师根据分类结果控制、补救和升级警报，从而确保对检测到的威胁做出快速有效的响应。此外，将添加设置指南部分，以解释正确运行所需的任何先决条件设置信息，确保用户在部署规则之前拥有所有必要的配置详细信息。

• 定性行为 - 规则集的状态
  • 初始：创建一些基线规则，为规则集奠定基础。
  • 可重复：创建了一些基线规则，涵盖了记录完善的威胁的关键战术（初始访问、执行、持久性、特权提升以及命令和控制）。
  • 已定义：创建并记录了全面的基线规则，涵盖了重大威胁（例如，勒索软件、数据泄露、未经授权的访问）。
  • 已管理：在发布之前，根据与安全产品一致的已定义模式验证查询和规则。
  • 已优化：通过高级威胁建模和自动化，持续改进和微调基线规则。
• 定量衡量 - 维护状态的活动
  • 初始：每个规则集（例如，AWS S3 规则集、AWS Lambda 规则集、Azure 规则集、端点规则集）创建并记录 5-10 个基线规则。
  • 可重复：每个规则集创建并记录十多个基线规则，涵盖基于威胁建模的主要技术（例如，针对目标的可能性、数据源可用性、对关键资产的影响）；至少 10% 的规则会经历诊断阶段。
  • 已定义：每个数据源涵盖了相当大比例（例如，60-70%）的 ATT&CK 技术基线；70-80% 的规则在生产前作为诊断（测试版）规则进行测试；定期更新和验证规则。
  • 已管理：每个数据源覆盖 90% 或以上的基准 ATT&CK 技术；所有规则在投入生产前都经过诊断阶段；制定全面的文档和持续改进流程。
  • 已优化：每个数据源 100% 覆盖基准 ATT&CK 技术；所有规则均采用自动化诊断和验证流程；规则更新采用持续集成和部署 (CI/CD)。

规则集管理与维护

一种系统化的规则管理与维护方法，包括版本控制、文档和验证。

• 定性行为 - 规则集的状态
  • 初始：没有规则管理。
  • 可重复：偶尔的规则流程，带有一些文档，并具有规则的定期发布周期。
  • 已定义：定期的规则管理，具有全面的文档和版本控制。
  • 已管理：对规则管理采用“检测即代码”方法（模式验证、查询验证、版本控制、自动化等）。
  • 已优化：具有持续每周规则管理和验证的高级自动化流程；所有规则都具有完整的文档和版本控制。
• 定量衡量 - 维护状态的活动
  • 初始：没有规则管理活动。
  • 可重复：每季度进行基本的规则管理活动；少于 20% 的规则具有版本控制。
  • 已定义：每月进行定期规则更新和文档编制；50-70% 的规则具有版本控制和全面的文档。
  • 已管理：每两周进行一次规则管理和验证的自动化流程；80-90% 的规则使用“检测即代码”原则进行管理。
  • 已优化：具有持续每周规则管理和验证的高级自动化流程；100% 的规则使用“检测即代码”原则进行管理，并具有完整的文档和版本控制。

改进和维护遥测质量

开始与管理遥测数据的团队进行对话并建立关系。这对于不同的安全团队有不同的适用性：对于供应商而言，可能涉及来自所有客户的数据；对于 SOC 或信息安全团队而言，它与公司数据有关；而对于 MSSP 而言，它涵盖来自托管集群的数据。拥有良好的数据源对于所有安全团队至关重要，以确保其检测规则的有效性和准确性。这还包括整合网络威胁情报 (CTI) 工作流程，以使用相关的威胁上下文和指标丰富遥测数据，从而提高检测能力。此外，与您的供应商合作，并将您的检测工程里程碑与他们的功能里程碑对齐，以确保您使用最佳工具并充分利用您的检测规则。如果内部安全团队不适用，则可以跳过此可选标准。

• 定性行为 - 规则集的状态
  • 初始：没有对遥测进行更新或改进以改进规则集。
  • 可重复：偶尔手动更新和最少的临时协作。
  • 已定义：定期更新，具有重要的集成和正式的协作，包括与集成团队的联系人 (POC) 进行沟通以及 CTI 数据的初始集成。
  • 已管理：全面的更新和协作，并持续集成 CTI 数据，从而增强遥测数据的上下文相关性并提高检测准确性。
  • 已优化：高级集成 CTI 工作流程与遥测数据，能够实时丰富和自动响应新出现的威胁。
• 定量衡量 - 维护状态的活动
  • 初始：没有遥测更新或改进。
  • 可重复：零星发生基本手动更新和改进；少于 30% 的规则类型产生遥测/内部数据。
  • 已定义：至少每季度进行一次定期手动更新和改进，并定期集成 CTI 数据；50-70% 的遥测数据与 CTI 集成；初步记录数据质量和规则有效性的增强。
  • 已管理：半自动化更新，并持续改进、定期 CTI 数据丰富以及初步记录数据质量和规则有效性的增强；70-90% 的遥测数据与 CTI 集成。
  • 已优化：完全自动化更新和持续改进、全面的 CTI 集成以及详细记录数据质量和规则有效性的增强；100% 的遥测数据与 CTI 集成；实时丰富和自动响应新出现的威胁。

审查威胁态势变化

根据威胁态势的变化定期评估和更新规则，包括威胁建模和组织变更。

• 定性行为 - 规则集的状态
  • 初始：不审查威胁态势变化。
  • 可重复：偶尔的审查，更新最少，威胁建模有限。
  • 已定义：定期审查和更新，以确保规则的相关性和有效性，并纳入威胁建模。
  • 已管理：保持适应性地响应新出现的威胁和组织变更的能力，并进行全面的威胁建模和新情报的交叉关联。
  • 已优化：基于新出现的威胁和组织变更进行持续监控和实时更新，并进行动态威胁建模和情报的交叉关联。
• 定量衡量 - 维护状态的活动
  • 初始：未进行任何审查。
  • 可重复：每半年进行一次审查，参考网络博客站点和公司报告；根据威胁态势变化审查的规则少于 30%。
  • 已定义：进行全面的季度审查，纳入新的组织变更、记录的变更以及规则有效性的改进；根据威胁态势变化审查的规则为 50-70%。
  • 已管理：持续监控（每月、每周或每天）网络情报来源，实施可操作的知识并调整规则以适应新资产和部门；根据最新的威胁情报和组织变更审查和更新的规则为 90-100%。
  • 已优化：使用自动化情报集成进行实时监控和更新；根据动态威胁态势和组织变更持续审查和更新的规则为 100%。

与产品负责人一起推动功能

积极与产品负责人（内部或外部）互动，以确保检测需求在与检测规则生命周期或影响检测创建的产品限制相关的事项的产品路线图上。这对于供应商与内部安全团队有不同的适用性。对于内部安全团队，这可以应用于内部开发的自定义应用程序以及与供应商或第三方工具的互动。这意味着开始与供应商（例如 Elastic）建立关系，以提出有助于满足其检测需求的功能请求，尤其是在需要第三方采取行动而不是内部采取行动时。

• 定性行为 - 规则集的状态
  • 初始：不与产品负责人互动。
  • 可重复：与路线图有一些影响的临时偶尔互动。
  • 已定义：定期互动，对产品路线图产生重大影响。
  • 已管理：与产品负责人进行结构化互动，从而将检测需求持续集成到产品路线图中。
  • 已优化：与产品负责人进行持续的、积极的互动，确保检测需求完全集成到产品开发生命周期中，并具有实时反馈和更新。
• 定量衡量 - 维护状态的活动
  • 初始：不与产品负责人互动。
  • 可重复：每季度完成 1-2 次互动/请求；少于 20% 的请求导致路线图变更。
  • 已定义：每个季度完成两次以上的互动/请求，从而导致路线图变更和检测规则集的改进；50-70% 的请求导致路线图变更；定期跟踪和记录互动结果。
  • 已管理：与产品负责人频繁互动，从而导致超过 70% 的请求导致路线图变更；对所有互动和结果进行结构化跟踪和记录。
  • 已优化：与产品负责人持续互动，进行实时跟踪和调整；90-100% 的请求导致路线图变更；全面的文档和主动反馈循环。

端到端发布测试和验证

实施强大的端到端发布测试和验证流程，以确保检测规则在推送到生产环境之前的可靠性和有效性。这包括运行不同的测试以发现潜在问题并确保规则的准确性。

• 定性行为 - 规则集的状态
  • 初始：没有正式的测试或验证流程。
  • 可重复：基本测试，验证最少。
  • 已定义：全面的测试，包括内部验证流程和多个关卡。
  • 已管理：高级测试，包括自动化和外部验证流程。
  • 已优化：持续的、自动化测试和验证，并具有实时反馈和改进机制。
• 定量衡量 - 维护状态的活动
  • 初始：没有测试或验证活动。
  • 可重复：每个发布周期 1-2 次规则集更新（发布节奏应根据资源和内部授权流程在内部驱动）；少于 20% 的规则在部署前经过测试。
  • 已定义：从开发到生产环境，端到端测试和发布新规则或调整的时间少于一周；50-70% 的规则在部署前经过测试，并具有记录在案的验证。
  • 已管理：能够在 24 小时内部署新出现的威胁规则；90-100% 的规则在部署前使用自动化和外部验证流程进行测试；根据测试结果持续改进。
  • 已优化：使用自动化部署流程进行实时测试和验证；100% 的规则经过持续测试和验证；基于实时反馈和情报的主动改进机制。

第 2 层：中级

在中级层，团队会持续调整检测规则以减少误报和过时规则。他们识别并记录规则集覆盖范围中的差距，使用模拟工具和恶意软件引爆在内部测试和验证规则，以确保正确发出警报。强调系统性的差距分析以及与利益相关者的定期沟通。

标准

持续调整并减少误报 (FP)

定期审查和调整规则，以最大限度地减少误报和过时规则。必要时建立共享/可扩展的例外列表，以防止重复调整，并记录过去的 FP 分析，以避免重复出现问题。

• 定性行为 - 规则集的状态
  • 初始：调整活动最少。
  • 可重复：根据警报和临时分析师反馈进行被动调整。
  • 已定义：主动和系统化调整，记录 FP 率的降低以及记录/已知的数据源，用于减少 FP。
  • 已管理：持续调整的活动，具有详细的文档和与利益相关者的定期沟通；实施系统性审查和更新。
  • 已优化：自动化和动态调整流程与高级分析和机器学习集成，以持续减少 FP 并适应新模式。
• 定量衡量 - 维护状态的活动
  • 初始：FP 率没有降低（必要时），基于减少的 FP 警报的总体量。
  • 可重复：过去一个季度 FP 率降低 10-25%。
  • 已定义：过去一个季度 FP 率降低超过 25%，指标各不相同（费率由规则集功能负责人确定），基于威胁态势在 SIEM 和端点规则之间。
  • 已管理：多个季度 FP 率持续降低超过 50%，并跟踪和报告详细指标。
  • 已优化：通过自动化反馈循环和持续改进，几乎实时地降低 FP 率，实现 FP 率降低超过 75%。

理解和记录差距

识别规则集或产品覆盖范围中的差距对于提高数据可见性和检测能力至关重要。这包括记录缺失的字段、日志数据集以及了解数据中的异常值。与利益相关者沟通这些差距，并将其视为“阻止因素”来解决，有助于确保持续改进。通过了解异常值，团队可以识别意外模式或异常，这些异常可能表明未检测到的威胁或当前规则集存在问题。

• 定性行为 - 规则集的状态
  • 初始：没有差距分析。
  • 可重复：偶尔进行差距分析，并带有一些文档。
  • 已定义：全面且定期的差距分析，包括详细的文档和利益相关者沟通，包括识别数据中的异常值。
  • 已管理：将系统性差距分析集成到常规工作流程中，具有全面的文档和与利益相关者的主动沟通。
  • 已优化：使用高级分析和机器学习进行自动化差距分析，具有实时文档和主动利益相关者参与，以立即解决差距。
• 定量衡量 - 维护状态的活动
  • 初始：没有记录任何差距。
  • 可重复：记录并沟通了 1-3 个威胁覆盖范围内的差距（例如，反向 Shell、代码注入、暴力攻击等特定技术）。
  • 已定义：已记录并沟通了三个以上威胁覆盖或数据可见性方面的差距，包括阻碍规则创建的差距（例如，缺少代理/日志）以及数据中识别出的异常值。
  • 已管理：详细记录并沟通了所有已识别的差距，定期更新并制定解决这些差距的行动计划；已记录并定期沟通了五个以上的差距。
  • 已优化：通过自动文档和沟通进行持续的实时差距分析；采取积极措施立即解决差距；全面跟踪和报告所有已识别的差距。

测试和验证（内部）

执行诸如执行模拟工具、C2 框架、引爆恶意软件或其他可重复技术等活动，以测试规则功能并确保正确警报。

• 定性行为 - 规则集的状态
  • 初始：无测试或验证。
  • 可重复：偶尔使用模拟功能进行测试。
  • 已定义：使用恶意软件或模拟功能进行定期和全面的测试，确保生产中的所有规则都经过验证。
  • 已管理：将系统的测试和验证流程集成到常规工作流程中，并进行详细记录和持续改进。
  • 已优化：使用高级分析和机器学习进行自动化和持续的测试和验证，确保所有规则的实时验证和改进。
• 定量衡量 - 维护状态的活动
  • 初始：未进行内部测试。
  • 可重复：生产规则集 40% 的模拟覆盖率。
  • 已定义：生产规则集 80% 的自动化测试覆盖率。
  • 已管理：生产规则集 90% 以上的自动化测试覆盖率，并具有持续验证流程。
  • 已优化：100% 的自动化和持续测试覆盖率，具有实时验证和反馈循环，确保最佳的规则性能和准确性。

第三层：高级

高级成熟度包括系统地识别和解决误报，从外部验证检测规则，并覆盖高级 TTP（战术、技术和程序）。此层强调通过外部评估和对复杂威胁的覆盖进行全面和持续的改进。

标准

误报（FN）分类

误报 (FN) 分类包括系统地识别和解决检测规则未能针对实际威胁触发警报的实例，这些实例称为误报。当数据集中存在威胁但现有规则未检测到威胁时，就会发生误报，这可能会使组织容易遭受未被检测到的攻击。利用威胁态势洞察力，此过程记录并评估各自环境中的误报，旨在通过定量标准在数据集中达到真实警报的阈值。

• 定性行为 - 规则集的状态
  • 初始：未对误报进行分类。
  • 可重复：偶尔分类，并进行了一些改进。
  • 已定义：进行系统且定期的分类，记录误报的减少情况，并对不同威胁态势中的误报进行全面评估。
  • 已管理：积极的分类活动，并提供详细文档和利益相关者沟通；定期更新以解决误报。
  • 已优化：使用高级分析和机器学习对误报进行持续的自动化分类和减少；实时文档和更新。
• 定量衡量 - 维护状态的活动
  • 初始：误报率没有降低。
  • 可重复：用于触发警报的测试样本或工具的 50%；每个季度审查的误报规则少于 10%；误报评估的文档最少。
  • 已定义：70-90% 的测试样本触发警报，指标因威胁态势和检测能力而异；过去一年误报减少 30-50%；每个季度对至少 50% 的规则进行误报的全面文档和审查；与威胁情报团队建立了定期的反馈循环。
  • 已管理：90-100% 的测试样本触发警报，并跟踪一致的误报减少指标；多个季度误报减少 50% 以上；所有规则的全面文档和反馈循环。
  • 已优化：使用自动反馈和更新进行近实时的误报分类；误报减少 75% 以上；持续的文档和主动措施来解决误报。

外部验证

外部验证涉及聘请第三方通过各种方法验证检测规则，包括红队演练、第三方评估、渗透测试以及与外部威胁情报提供商的协作。通过整合不同的视角和专业知识，此过程可确保检测规则稳健、全面且有效应对真实世界的威胁。

• 定性行为 - 规则集的状态
  • 初始：无外部验证。
  • 可重复：偶尔的外部验证工作，并进行了一些改进。
  • 已定义：进行定期和全面的外部验证，并记录反馈、改进以及将发现结果集成到检测规则集中。此级别包括所有这些验证方法。
  • 已管理：结构化的外部验证活动，提供详细文档和持续改进；与多个第三方验证者积极互动。
  • 已优化：持续的外部验证，具有自动化的反馈集成、实时更新以及基于不同第三方见解的主动改进。
• 定量衡量 - 维护状态的活动
  • 初始：未进行外部验证。
  • 可重复：每年进行 1 次外部验证演练，例如红队演练或第三方评估；每年解决的已识别差距少于 20%。
  • 已定义：每年进行一次以上的外部验证演练，包括红队演练、第三方评估、渗透测试以及与外部威胁情报提供商的协作等多种方法；详细记录基于外部反馈的改进，并在一个季度内解决至少 80% 的已识别差距；将外部验证结果整合到至少 50% 的新规则中。
  • 已管理：每年进行多次外部验证演练，并全面整合反馈；在设定的时间范围内解决 90% 以上的已识别差距；根据持续的外部见解主动更新规则。
  • 已优化：持续的实时外部验证，具有自动化的反馈和更新；主动解决 100% 的已识别差距；全面跟踪和报告所有外部验证结果。

高级 TTP 覆盖

在规则集中涵盖非通用恶意软件（APT、零日漏洞等）和新兴威胁（新的恶意软件家族和被威胁参与者滥用的攻击性安全工具等）。此覆盖范围受检测这些高级威胁的能力的影响，这需要全面的遥测和灵活的数据提取。虽然在成熟度过程的早期展示这些行为可以对团队的成长产生复合的积极影响，但此标准旨在关注具有低误报的更高保真度规则集。

• 定性行为 - 规则集的状态
  • 初始：无高级 TTP 覆盖。
  • 可重复：根据第三方发布的研究对某些高级 TTP 进行响应。
  • 已定义：基于威胁情报和内部研究为高级 TTP 创建的第一方覆盖范围，具有灵活且全面的数据提取能力。
  • 已管理：使用详细的威胁情报和持续更新对高级 TTP 进行主动覆盖；与各种数据源集成以进行全面检测。
  • 已优化：使用高级分析和机器学习对高级 TTP 进行持续的自动化覆盖；针对新兴威胁的实时更新和主动措施。
• 定量衡量 - 维护状态的活动
  • 初始：无高级 TTP 覆盖。
  • 可重复：根据可用数据和第三方研究，检测和响应 1-3 个高级 TTP/对手；少于 20% 的规则涵盖高级 TTP。
  • 已定义：根据第一方威胁情报和内部研究，检测和响应三个以上独特识别和定位的高级 TTP/对手；50-70% 的规则涵盖高级 TTP；至少 70% 的高级威胁检测具有全面的遥测和灵活的数据提取；根据新的威胁情报定期更新高级 TTP 覆盖范围。
  • 已管理：检测和响应五个以上的高级 TTP/对手，并进行持续更新和主动措施；70-90% 的规则涵盖集成了遥测和数据提取的高级 TTP；与威胁情报团队进行定期更新和反馈循环。
  • 已优化：通过自动更新和主动覆盖实时检测和响应高级 TTP；100% 的规则涵盖具有持续遥测集成的高级 TTP；根据不断变化的威胁态势进行动态更新和实时反馈。

第四层：专家

专家层侧重于高级自动化、与其他安全工具的无缝集成以及通过定期更新和外部协作实现持续改进。虽然主动威胁搜寻对于维持稳固的安全态势至关重要，但它通过识别可合并到检测规则中的新模式和见解来补充规则集管理流程。团队实施复杂的规则更新自动化，确保高级检测的持续集成。在 Elastic，我们的团队通过日常分类、定期更新并在我们的公共 GitHub 存储库中共享威胁搜寻查询来不断改进我们的规则集，以帮助社区提高其检测能力。

标准

在遥测/内部数据中搜寻

设置查询和每日分类以搜寻新威胁并确保规则的有效性。这适用于在遥测中搜寻的供应商以及在其可用数据集中搜寻的其他团队。

• 定性行为 - 规则集的状态
  • 初始：没有导致规则集改进的搜寻活动。
  • 可重复：偶尔进行搜寻活动，并有一些发现。
  • 已定义：根据威胁搜寻成熟度模型进行定期和系统的搜寻，并包含来自外部验证、端到端测试和恶意软件引爆的发现。
  • 已管理：持续的搜寻活动，并提供全面的文档和发现结果的集成；搜寻和检测工程团队之间定期的反馈循环。
  • 已优化：使用高级分析和机器学习进行自动化的实时搜寻；持续的文档和主动集成发现结果以增强检测规则。
• 定量衡量 - 维护状态的活动
  • 初始：未进行导致规则集改进的搜寻活动。
  • 可重复：搜寻工作流程的每周结果（例如，发现的威胁、基于假设的新检测等）；少于 20% 的搜寻发现被记录；搜寻结果集成到检测规则中的程度最小。
  • 已定义：根据搜寻结果和外部验证数据，每周得出结果，并记录改进情况并将其集成到检测规则中；50-70% 的搜寻发现被记录并集成到检测规则中；在搜寻和检测工程团队之间建立了定期的反馈循环。
  • 已管理：每日搜寻活动，并提供全面的文档和发现结果的集成；超过 90% 的搜寻发现被记录，并导致检测规则的更新；基于搜寻结果和外部验证数据的持续改进流程；与威胁情报团队定期协作，以增强搜寻的有效性。
  • 已优化：具有自动化文档和集成的实时搜寻活动；100% 的搜寻发现被记录，并导致检测规则的立即更新；通过基于高级分析和威胁情报的主动措施进行持续改进。

持续改进和潜在增强

在专家级别，持续改进至关重要，需要利用最新的技术和方法来增强检测能力。各个级别中不同标准下的“优化”级别都强调了先进自动化和新兴技术集成的必要性。实施规则更新、遥测过滤以及与其他高级工具集成的自动化，对于现代检测工程至关重要。虽然目前的实践涉及超出基本案例管理和 SOAR（安全编排、自动化和响应）的先进自动化，但使用生成式人工智能和大型语言模型 (LLM) 等新兴技术仍有进一步增强的潜力。这再次强调了最高级别需要持续适应和创新，以保持强大而有效的安全态势。

• 定性行为 - 规则集的状态
  • 初始阶段：无自动化。
  • 可重复阶段：规则管理流程的基本自动化，例如 ETL（提取、转换和加载）数据管道，以实现可操作的见解。
  • 已定义阶段：初步使用生成式人工智能来辅助规则创建和评估。例如，人工智能可以根据预定义的标准评估规则的质量。
  • 已管理阶段：高级使用人工智能/LLM 来检测规则重复和重叠，建议增强功能而不是创建冗余规则。
  • 优化阶段：在整个检测工程生命周期中完全集成生成式人工智能/LLM。这包括使用人工智能来持续提高规则准确性、减少误报以及提供有关规则有效性的见解。
• 定量衡量 - 维护状态的活动
  • 初始阶段：未实施自动化流程。
  • 可重复阶段：实施规则管理和集成的基本自动化流程；少于 30% 的规则管理任务实现自动化；自动化部署和版本控制的初始设置。
  • 已定义阶段：使用人工智能评估规则质量，至少 80% 的新规则在部署前经过自动质量检查；40-60% 的规则管理任务实现自动化；使用初始人工智能驱动的见解来增强规则有效性并减少误报。
  • 已管理阶段：人工智能驱动的重复检测，目标是在实施的第一年内将规则重复减少 50%；70-80% 的规则管理任务实现自动化；人工智能驱动的建议可使误报减少 30-50%；持续集成管道捕获和部署规则更新。
  • 优化阶段：全面集成人工智能，超过 90% 的规则更新和优化由人工智能建议，从而显著减少手动警报分类，并使误报减少 40%；完全自动化的规则管理和部署流程；实时人工智能驱动的遥测过滤并与其他高级工具集成。

应用 DEBMM 来了解成熟度

一旦您了解 DEBMM 及其层级，就可以开始应用它来评估和增强您的检测工程成熟度。

以下步骤将指导您完成该过程

1. 审核您当前的成熟度等级：根据 DEBMM 中概述的标准评估您现有的检测规则集。确定您的规则集的优势、劣势和最显着的风险，以帮助确定您当前的成熟度等级。有关更多详细信息，请参阅示例问卷。

2. 了解工作范围：认识到从一个层级转移到下一个层级需要付出巨大的持续努力。随着团队在层级中取得进展，活动的复杂性和深度都会增加，需要更多的资源、高级技能和全面的策略。例如，从第 1 层过渡到第 2 层涉及系统化的规则调整和详细的差距分析，而晋升到第 3 层和第 4 层则需要强大的外部验证流程、主动的威胁狩猎和复杂的自动化。

3. 设定进展目标：为晋升到下一层级定义具体目标。使用定性和定量指标为每个标准设定明确的目标。

4. 制定路线图：制定详细的计划，概述实现目标所需的行动。包括时间表、资源和负责的团队成员。在您前进的过程中，确保始终应用较低层级的基础实践，同时通过首先解决最关键和风险最高的改进领域来确定快速获胜或产生重大影响的机会。

5. 实施变更：执行计划，确保所有团队成员都与目标保持一致并了解自己的角色。根据需要定期审查和调整计划。

6. 监控和衡量进展：根据 DEBMM 标准持续跟踪和衡量您的检测规则集的性能。使用指标和关键绩效指标 (KPI) 来监控您的进展并确定需要进一步改进的领域。

7. 迭代和改进：根据反馈、结果和不断变化的威胁形势定期审查和更新您的改进计划。迭代您的检测规则集以增强其有效性并保持较高的成熟度等级。

分组标准以实现有针对性的改进

为了进一步简化流程，您可以将标准分组到特定的类别中，以专注于有针对性的改进。例如

• 规则创建和管理：包括创建、管理和维护规则的标准。
• 遥测和数据质量：侧重于改进和维护遥测质量。
• 威胁形势审查：涉及根据威胁形势的变化定期审查和更新规则。
• 利益相关者参与：与产品所有者和其他利益相关者进行互动，以满足检测需求。

分组标准使您可以根据您当前的需求和目标来确定活动和改进的优先级。这种结构化且有重点的方法有助于增强您的检测规则集，并且对于多个功能所有者在不同领域为实现共同目标而工作的团队特别有益。

结论

无论您是将 DEBMM 应用于您的规则集，还是将其用作增强检测能力的指南，其目标都是帮助您系统地开发、管理和改进您的检测规则集。通过遵循此结构化模型并逐步提升成熟度等级，您可以显著增强威胁检测能力的有效性。请记住，安全是一个持续的过程；持续改进对于保持领先于新兴威胁并维持强大的安全态势至关重要。DEBMM 将支持您实现更好的安全性和更有效的威胁检测。我们重视您对改进和增强该模型的反馈和建议，以使安全社区受益。请随时分享您的想法和见解。

我们始终对听取此类用例和工作流程感兴趣，因此一如既往地，请通过 GitHub 问题与我们联系，在我们的 社区 Slack 中与我们聊天，并在我们的 讨论论坛中提出问题！

附录

示例规则元数据

以下是与 Elastic 中使用的示例元数据对齐的更新标准列表，但应根据所使用的产品进行定制

示例问卷

1. 识别威胁态势

要问的问题

• 您是否定期审查您的组织面临的前 5 大威胁？（是/否）
• 是否已针对这些威胁识别出相关的战术和技术？（是/否）
• 威胁态势是否定期审查和更新？（是 - 每月/是 - 每季度/是 - 每年/否）
• 最近是否发现了任何新兴威胁？（是/否）
• 是否有指定人员负责监控威胁态势？（是/否）
• 您是否有捕获相关威胁流量的数据源？（是/部分/否）
• 是否已识别出可能受这些威胁影响的关键资产？（是/否）
• 重要的资产及其位置是否已记录？（是/否）
• 这些位置中的端点、API、IAM、网络流量等是否已识别？（是/部分/否）
• 是否已识别出关键的业务运营并确保其维护？（是/否）
• 如果在医疗保健领域，记录是否以符合 HIPAA 的方式存储？（是/否）
• 如果使用云，是否已锁定对跨多个区域的云存储的访问？（是/否）

改进步骤

• 建立威胁态势更新的定期审查周期。
• 与外部威胁情报提供商合作，以获得更广泛的见解。

2. 定义完美的规则

要问的问题

• 是否已定义完整规则所需的必填字段？（是/否）
• 是否有记录和验证规则的流程？（是/否）
• 是否有创建新规则的清晰流程？（是/否）
• 是否基于已定义的标准对规则的创建和更新进行优先级排序？（是/否）
• 是否有可用于创建规则的模板或指南？（是/否）
• 规则是否在投入生产之前经过一段时间的验证？（是/否）

改进步骤

• 开发和标准化规则创建的模板。
• 在部署之前实施规则验证的审查流程。

3. 定义完美的规则集

要问的问题

• 您是否拥有覆盖关键威胁所需的基本规则？（是/否）
• 您的规则集是否涵盖主要的威胁技术？（是/部分/否）
• 是否衡量规则集的有效性？（是 - 全面地/是 - 部分地/否）
• 您是否有用于确定是否应将规则包含在规则集中的特定标准？（是/否）
• 规则集是否维护和更新？（是 - 程序化维护和频繁更新/是 - 程序化维护和临时更新/是 - 手动维护和频繁更新/是 - 手动维护和临时更新/否）

改进步骤

• 执行差距分析，以识别缺失的覆盖区域。
• 根据新的威胁情报和反馈定期更新规则集。

4. 维护

要问的问题

• 是否定期审查和更新规则？（是 - 每月/是 - 每季度/是 - 每年/否）
• 是否已到位版本控制系统？（是/否）
• 是否有记录的规则维护流程？（是/否）
• 如何将规则集的更改传达给利益相关者？（定期会议/电子邮件/文档/不沟通）
• 是否有用于规则更新和验证的自动化流程？（是/部分/否）

改进步骤

• 为所有规则实施版本控制。
• 建立用于规则更新和验证的自动化工作流程。

5. 测试和发布

要问的问题

• 是否在规则部署之前执行测试？（是/否）
• 是否有记录的验证流程？（是/否）
• 是否记录测试结果并用于改进规则？（是/否）
• 是否有指定人员负责测试和发布规则？（是/否）
• 是否有到位的自动化测试框架？（是/部分/否）

改进步骤

• 开发和维护用于规则验证的测试框架。
• 记录和审查测试结果，以不断提高规则质量。

6. 标准评估

要问的问题

• 在规则评估过程中是否使用了包括生成式 AI 在内的自动化工具？（是/否）
• 使用定义的标准进行自动化评估的频率是多少？（每月/每季度/每年/从不）
• 哪些类型的自动化或 AI 工具集成到规则评估过程中？（列出具体工具）
• 如何使用来自自动化（包括来自生成式 AI）的见解来优化规则？（定期更新/临时更新/不使用）
• 跟踪哪些指标来衡量自动化评估的有效性？（列出具体指标）

改进步骤

• 将包括生成式 AI 在内的自动化工具集成到规则评估和优化流程中。
• 定期审查和实施来自自动化评估的见解，以提高规则质量。

7. 迭代

要问的问题

• 多久重新审视评估流程？（每月/每季度/每年/从不）
• 从以前的评估中识别和实施了哪些改进？（列出具体改进）
• 如何将评估的反馈纳入规则集？（定期更新/临时更新/不使用）
• 谁负责根据评估反馈迭代规则集？（指定角色/无特定角色）
• 是否有指标来跟踪随着时间的推移的进展和改进？（是/否）

改进步骤

• 建立定期审查和迭代周期。
• 跟踪和记录改进及其对规则有效性的影响。

本帖子中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。任何当前不可用的特性或功能可能不会按时交付或根本不交付。