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% 的规则持续进行测试和验证；基于实时反馈和情报的主动改进机制。

第二层：中级

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

标准

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

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

• 定性行为 - 规则集状态
  • 初始：调整活动最少。
  • 可重复：根据警报和临时分析师反馈进行被动调整。
  • 已定义：主动和系统的调整，并记录 FP 率的降低以及已记录/已知的数据库，用于降低 FP。
  • 已管理：持续调整活动，并附有详细的文档记录和定期的利益相关者沟通；实施系统审查和更新。
  • 已优化：与高级分析和机器学习集成的自动化和动态调整流程，以持续降低 FP 并适应新模式。
• 定量测量 - 维持状态的活动
  • 初始：根据误报警报减少的总体数量，没有降低误报率（必要时）。
  • 可重复：过去一个季度误报率降低 10%-25%。
  • 已定义：过去一个季度误报率降低超过 25%，指标有所不同（速率由规则集功能所有者确定），基于威胁环境在 SIEM 和端点规则之间有所不同。
  • 已管理：在多个季度内持续降低误报率超过 50%，并详细跟踪和报告指标。
  • 已优化：利用自动反馈循环和持续改进实现近实时降低误报率，误报率降低超过 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/对手，这些 TTP/对手基于第一方威胁情报和内部研究；50-70% 的规则涵盖高级 TTP；至少 70% 的高级威胁检测具有全面的遥测和灵活的数据摄取；根据新的威胁情报定期更新高级 TTP 覆盖率。
  • 已管理阶段：检测和响应超过五个高级 TTP/对手，并提供持续更新和积极主动的措施；70-90% 的规则涵盖高级 TTP，并集成了遥测和数据摄取；与威胁情报团队定期更新和反馈循环。
  • 已优化阶段：实时检测和响应高级 TTP，并提供自动更新和积极主动的覆盖；100% 的规则涵盖高级 TTP，并提供持续的遥测集成；根据不断变化的威胁环境进行动态更新和实时反馈。

第四级：专家

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

标准

在遥测/内部数据中进行狩猎

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

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

持续改进和潜在增强

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

• 定性行为 - 规则集状态
  • 初始阶段：没有自动化。
  • 可重复阶段：用于规则管理流程的基本自动化，例如 ETL（提取、转换和加载）数据管道，以实现可操作的见解。
  • 已定义阶段：初步使用生成式 AI 来协助规则创建和评估。例如，AI 可以根据预定义的标准评估规则的质量。
  • 已管理阶段：高级使用 AI/LLM 检测规则重复和重叠，建议增强而不是创建冗余规则。
  • 已优化阶段：在整个检测工程生命周期中全面集成生成式 AI/LLM。这包括使用 AI 持续改进规则准确性、减少误报以及提供有关规则有效性的见解。
• 定量测量 - 维持状态的活动
  • 初始阶段：未实施任何自动化流程。
  • 可重复阶段：实施用于规则管理和集成的基本自动化流程；不到 30% 的规则管理任务是自动化的；自动化部署和版本控制的初始设置。
  • 已定义阶段：使用 AI 评估规则质量，至少 80% 的新规则在部署前进行自动化的质量检查；40-60% 的规则管理任务是自动化的；AI 驱动的初步见解用于增强规则有效性并减少误报。

  • **托管：**基于 AI 的重复检测，目标是在实施后的第一年内将规则重复率降低 50%；70-80% 的规则管理任务自动化；AI 驱动的建议导致 FP 减少 30-50%；持续集成管道捕获和部署规则更新。
  • **优化：**全面集成 AI，其中超过 90% 的规则更新和优化由 AI 建议，从而显著减少了警报的手动分类，并将 FP 减少了 40%；完全自动化的规则管理和部署流程；实时 AI 驱动的遥测过滤以及与其他高级工具的集成。

应用 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 自行决定。任何当前不可用的功能或功能可能无法按时或根本无法交付。