Introduction

Purpose

ODEF enables organizations to establish and apply fundamental principles and best practices in detection engineering. Adopting ODEF accelerates service enhancement, refines processes, and advances cybersecurity maturity.

The framework strategically aligns cybersecurity efforts with business objectives (e.g., risk reduction and operational resilience). It enables the creation of robust detection systems, provides assurance, reduces reliance on vendors, and, most importantly, strengthens an organization’s overall security stance. ODEF defines core principles for effective detection engineering and introduces a three-tiered maturity model to evaluate organizational performance.

Each phase within the framework’s core is meticulously crafted to map out the detection lifecycle, guiding detection engineers with focused functions and outcomes expectations that steer them through the entire process. The maturity levels act as strategic benchmarks, providing organizations with a high-level perspective on their detection engineering strategy and highlighting areas for potential improvement.

High-Level Goals

The overarching ambitions of the framework are to:

• Establish a methodical, replicable, and predictable approach for developing hunts and detections.
• Achieve extensive organizational visibility.
• Transform insights into sustainable, actionable knowledge while fostering a culture of information sharing.
• Promote persistent vigilance in detection practices.
• Validate detections rigorously through systematic testing.
• Cultivate an environment where knowledge and knowledge sharing is the main driver of security initiatives.

Framework Mindmap

Framework Core

Framework Core

The Framework Core is a suite of activities aimed at achieving specific cybersecurity objectives, supplemented by illustrative examples to guide their implementation. The Core is structured around three lifecycle phases: Sunrise, Midday, and Sunset which holistically cover the detection lifecycle from inception to completion, with dedicated functions, guidelines, and goals for each phase. Together, these components provide detection engineers with a “north star” focus, enabling them to deliver high-quality detections with precision.

Functions, Goals, Guidelines

Each phase of the detection lifecycle is defined by specific functions, goals, and guidelines. These elements work together to guide detection engineers in producing robust, reliable detections

Functions

Inspired by the single-responsibility principle from software engineering, each function in ODEF represents a discrete step with a singular focus and outcome within the detection lifecycle. These single-goal activities are designed to drive a specific activity, ensuring clarity and precision at every stage.

Goals

Each function is crafted to achieve a specific, well-defined result that aligns with the overarching objectives of the detection lifecycle. While goals may sometimes be high-level or abstract, it is strongly recommended to maintain a direct correlation between functions and goals. This alignment ensures that each function contributes meaningfully toward the end goal, enhancing both focus and quality in detection engineering.

Guideline

Guidelines act as reference materials that support the achievement of goals within each function. They provide detection engineers with context-specific insights and best practices, helping to standardize processes while allowing adaptability. For example, a document detailing a company’s unique Change Management process would serve as a valuable guideline

Phases in detail

The Core encompasses three primary lifecycle phases:

• Sunrise
• Midday
• Sunset

These phases collectively chronicle the lifespan of a detection mechanism, from its conception to its eventual retirement/decommissioning.

Phases

Intro

In the rhythm of each day lies the strength of progress; every sunrise brings new potential, midday illuminates our purpose, and sunset reminds us to refine and renew.

Phases

Maturity Model

Introduction

Maturity is a self-evaluation process conducted by the team. ODEF provides guidance and structure and assures that all the relevant areas are covered. The goal of the review process is to give a baseline that helps achieving a common understanding about the organization security posture.

Dimensions

• Threat Detection Content
• Assurance
• Knowledge sharing

flowchart RL
    Assurance(Assurance) <--->Threat[Threat Detection Content]
    Knowledge[Knowledge sharing] <---> Assurance(Assurance)
    Knowledge[Knowledge sharing] <---> Threat(Threat Detection Content)

Maturity levels

Level 1 - Partial

• Threat Detection Content
  • Organizational threat identification practices rely solely on external vendors to provide security content.
  • Assurance and context around alerts and detections is not provided or sufficient.
  • Risk is managed in an ad hoc and often reactive manner by relying on third parties.
• Assurance
  • There is some limited awareness of cybersecurity threat detection capabilities at the organizational level.
  • The organization implements threat validation and verification on an irregular, case-by-case basis due to varied experience or information gained from outside sources.
  • Assurance through continuous validation is not present.
• Knowledge sharing
  • The organization may not have processes to enable cybersecurity information sharing.
  • Documentation is rarely written and shared only on ad-hoc basis and it is scattered across teams.

Level 2 - Adequate

• Threat Detection Content
  • Organizational threat identification practices rely on internal teams and external vendors to provide security content.
  • Context around alerts and detections is provided. Specialized teams are able to introduce new detections and security content.
  • Some security teams have a better understanding of security posture than others.

• Assurance
  • There is some awareness of cybersecurity threat detection capabilities as the organization is now building custom detections to compensate for gaps.
  • The custom detections are use case driven and validated during the detection development process.
  • Continuous validation is not enabled and the organization still relies on suppliers for most of the detection capabilities.

• Knowledge sharing
  • The organization is starting to enable knowledge sharing and promotes documentation efforts.
  • There is a central detection information repository.

Level 3 - Enabled (Proactive)

• Threat Detection Content
  • Organization maintains continuous practices that provide excellent internal insights and knowledge. Context around alerts and detections is provided.
  • Any team is encouraged and capable to introduce new detection components and thus improve the security posture.
  • The security posture of the environment is well understood across the security teams.

• Assurance
  • The organization possesses a detection coverage map and covers a big percentage with in-house built detections. The organization does not rely on vendors to provide security content.
  • Automation is provided to continuously validate and run the detection use cases.
  • Additional assurance is achieved by running red team exercises and automation frameworks.

• Knowledge sharing
  • Organizations possess practices to create and maintain high quality records and appropriately control and manage the access to the information.
  • Processes for socializing detections are automated and teams are informed of the development of new detections.

Operational Maturity

Maturity Review Process (MRP)

The process of evaluating the maturity:

• Collect - Collect information about your processes, people and tools. Identify changes to any. The goal is to gain a holistic understanding of the organization's security teams, tools and processes. Based on that information various posture improvements can be identified.
• Analyze - Based on the data that you have collected and find the corresponding maturity level. Finding where in the maturity level the organization is important for understanding the impact and importance of each identified security improvement initiative and thus prioritize accordingly.
• Prioritize - Prioritize and decide which is the next low hanging fruit that can be improved. Not all security issues are equally important, prioritization should focus on those initiatives that influence and change the security posture and introduce the most maturity.
• Improve - Create an initiative or a project for improving the identified gap.

Security Improvement Initiative

Security improvement initiatives are likely outcomes of the MRP process. The goal of the security improvement initiative is to address identified visibility gaps in the organization's security posture. For example, during the review process or detection engineering we may identify that our application is not providing sufficient logging in order to detect particular behavior or ttp of interest. That is a good candidate for a security improvement initiative. The goal of the initiative would be to deliver the visibility needed and notify back the Detection Engineer so that they can proceed with the detection creation. Depending on the size of the organization and internal processes, this process might be driven by the Detection Engineer or completely separate team.

DEMM Cadence

Evaluating the maturity of the organization and striving to improve it is no one time effort or activity. For that best results can be achieved by:

• Set a regular schedule for reevaluating and revisiting the DEMM.
• Ensure that the security improvement initiatives are targeted with a timeline and aligned with the overall organizational security strategy.

Templates

Template Purpose

ODEF provides two templates for documenting detections — yaml and markdown. Each for different purpose:

• Yaml is used due to its data serialization and wide programming language compatibility. It is used for automation and integrations with other systems. It stores components like the queries, baseline, schedule and others. It is a stepping stone for Detection-as-Code capability.

• Markdown is used for detection documentation due to its readability and simplicity. Especially helpful for knowledge sharing when used in conjunction with platforms like GitHub. The purpose of the file is to house all details related to the detection. Check the Knowledge Management section for additional information.

The yaml file

Yaml file purpose

status: "{{ status }}"
created_date: "{{ created_date }}"
last_updated_date: 
name: "{{ detection_name }}"
query: "{{ query }}"
author: "{{ detection_author }}"
schedule: "{{ schedule }}"
baseline: "{{ baseline }}"
visualization: "{{ visualization }}"
event_limit: 0
data_source: "{{ data_source }}"
data_location: "{{ data_location }}"
tactic: "{{ tactic }}"
mitre_id: "{{ mitre_id }}"
mitre_url: "{{ mitre_url }}"
incident:
  severity: "numeric, 0-unknown, 0.5 - informational, 1-low,2-medium,3-high,4-critical"
  type: 'Security Incident'
  name: 'string, name of the incident' 
  description: 'inc descr: This detection is monitoring for changes in any of X'
  sla: 'integer - number of minutes added to incident create time(incident sla). example sla: 1440 this means 24h sla'

Documentation Template

Template should be used to standardize the detection content and create a knowledge base

Detection Summary