Detection Engineering Maturity

While "WTF" might seem like an unusual acronym, WTF" in this context is a slightly irreverent and informal way to refer to Detection Engineering Maturity. The "WTF" version is more likely to be encountered in casual conversations, blog posts, or social media discussions among security professionals. It's a bit of industry jargon that reflects the sometimes humorous and unconventional nature of the cybersecurity field.

it's gaining traction in the cybersecurity world to represent Detection Engineering Maturity. It's a way to assess and improve an organization's ability to detect and respond to threats. There isn't one definitive but here's a breakdown of the key concepts and common elements:

While Security Automation is going in the direction of low-code/no-code, Detection Engineering is heading toward a much more code-centric model. This is where Detection as Code (DaC) comes into play—a methodology where detection logic is managed like software code.

The rise of DaC can be traced to the increasing complexity of cybersecurity threats. Traditional signature-based or rule-based detection methods became inadequate in the face of modern, sophisticated attacks. Security teams needed detection systems that were not only highly customizable but also scalable and version-controlled—hence the move toward treating detection rules as code.

What is Detection Engineering

Detection-as-Code is a new way of finding threats. Instead of using old-fashioned rules or special languages, it uses code that is easy to change, understand, and grow. This code is often written in popular languages like Python. This means security teams can create custom solutions for their unique needs, making them better prepared for any challenge.

It's a critical function within a Security Operations Center (SOC), enabling analysts to detect malicious activity that bypasses traditional security controls. By applying engineering principles and leveraging threat intelligence, detection engineers create and refine detection rules, automate analysis, and improve the overall efficiency of threat detection.

Detection engineering fosters collaboration with other security teams, such as incident response, red teams, and purple teams. It provides valuable insights to incident responders by delivering high-fidelity alerts with actionable context, enabling faster and more effective response to security incidents. Collaboration with red and purple teams helps validate and improve detection rules through simulated attacks and adversarial testing. Furthermore, detection engineering helps the business understand its security challenges by providing metrics and reporting on detection coverage, effectiveness, and areas of improvement. This data-driven approach enables informed decision-making and helps justify budget allocation for security investments.

Detection engineering maturity refers to the level of sophistication and effectiveness of an organisations threat detection program. A mature program goes beyond simply relying on out-of-the-box security tools and alerts. It involves a proactive and continuous process of developing, testing, and refining detection rules and processes to identify and respond to increasingly sophisticated attacks.  

The core pillars are

a)     Detection-as-code,

b)     Incident Response

c)     Detection logic and infrastructure itself.

Detection-as-Code:

Traditional approaches to threat detection often involve manually creating and managing detection rules within security tools like SIEMs and EDRs. This can be time-consuming, error-prone, and difficult to scale. Detection-as-code DaC) offers a more modern and efficient approach by applying software engineering principles to threat detection.

Detection-as-Code, which applies software engineering principles to the creation and management of threat detection logic. It highlights two key aspects:

1. Agile Processes:

• Methodology: Apply agile methodologies like Scrum or Kanban to manage detection engineering tasks.
• Benefits: Improved Collaboration: Enable better teamwork and communication. Efficient Workflow: Facilitate efficient prioritization, tracking, and sizing of detection engineering work. Flexibility: Allow for flexibility and adaptation to changing requirements and priorities.

2. Code Reuse:

• Modularity: Break down complex detection logic into smaller, reusable components or "functions."
• Benefits: Efficiency: Avoid redundant effort by reusing code across multiple detection rules. Maintainability: Simplify maintenance and updates by making changes in a single, reusable component. Consistency: Promote consistency and standardization in detection logic.

Industry guidelines on Engineering Process and Principles for implementing Detection-as-Code

Detection-as-Code:

• Core Idea: Apply software engineering principles to the creation and management of threat detection logic (e.g., SIEM rules, Yara rules).

Key Practices:

1. Version Control: Track changes to detection logic using tools like Git. Benefits: Enables collaboration, review, rollback, and integration with CI/CD pipelines.
2. CI/CD (Continuous Integration/Continuous Delivery): Automate the deployment and testing of detection logic. Benefits: Enforces testing, ensures consistency, and streamlines updates.
3. Static & Dynamic Testing: Validate detection logic before deployment. Static Testing: Analyze code for errors and potential issues. Dynamic Testing: Test the logic against real-world data or simulated attacks. Benefits: Improves accuracy, reduces errors, and increases confidence in detection capabilities.

The Core Idea:

DaC treats detection logic (e.g., SIEM queries, EDR rules, Yara rules) as code, allowing you to manage, test, and deploy them using the same rigor and discipline as software development. This means leveraging version control, automated testing, and continuous integration/continuous delivery (CI/CD) pipelines to ensure the quality and reliability of your detection rules.logic definition and maturity' is one more practice and benefit that needs to be accounted With multiple team's collaboration, there will different ideas and the logic would differ based on scenario, industry, geo-politics, etc.

Benefits of Detection-as-Code:

• Improved Collaboration: Multiple team members can collaborate on detection logic, review changes, and provide feedback, much like in software development.
• Version Control: Track changes to detection rules, revert to previous versions if needed, and understand the history of modifications.
• Automated Testing: Implement automated testing to ensure that detection rules are accurate, reliable, and effective before deployment.
• CI/CD Integration: Integrate detection rules into CI/CD pipelines, enabling automated deployment and updates to security tools.
• Consistency and Standardization: Promote consistency and standardisation in detection logic across the organization.
• Reduced Errors: Minimize human error and improve the quality of detection rules.
• Increased Efficiency: Streamline the process of creating, managing, and deploying detection rules.
• Scalability: Easily scale detection capabilities as your organization grows and your security needs evolve.

Practical Implementation:

1. Choose a Version Control System: Use a version control system like Git to store and manage your detection logic.
2. Define a Workflow: Establish a clear workflow for creating, testing, reviewing, and deploying detection rules.
3. Automate Testing: Develop automated tests to validate the accuracy and effectiveness of your detection rules.
4. Implement CI/CD: Integrate your detection rules into a CI/CD pipeline to automate deployment and updates.
5. Store Metadata: Store metadata alongside your detection logic, such as the MITRE ATT&CK techniques it detects, test cases, and performance metrics.

Example:

Imagine you have a detection rule for identifying suspicious login attempts. With DaC, you would:

• Store the rule's code in a Git repository.
• Write automated tests to ensure it accurately identifies malicious logins.
• Use a CI/CD pipeline to automatically deploy the rule to your SIEM.
• Track changes to the rule over time and document any modifications.

Detection-as-code is a powerful approach that can significantly improve the efficiency, accuracy, and scalability of your threat detection program. By applying software engineering principles, you can create a more robust and resilient security posture.

Incident Response Optimisation

Effective threat detection should always consider the impact on incident responders (IR). By focusing on the IR experience, organisations can ensure that detection logic is relevant, actionable, and contributes to efficient incident response. The importance of considering the Incident Response (IR) team's experience when developing and managing security alerts.

It highlights two key areas:

1. Alert Documentation & Context:

• Ensure that alerts are well-documented and provide sufficient context for the IR team to understand the situation and take appropriate action.
• This includes clear descriptions of the alert's purpose, the potential impact, and any relevant background information.

2. Alert Fidelity, Monitoring & Maintenance:

• Alert Fidelity: Refers to the accuracy and relevance of alerts. High-fidelity alerts accurately identify real threats, while low-fidelity alerts may trigger false positives or require significant investigation.
• Monitoring & Maintenance: Establish processes for monitoring alert fidelity and maintaining detection rules over time.
• Dedicating resources to assist with low-fidelity alerts or empowering the IR team to self-serve in managing them.
• Automation to improve the efficiency of alert monitoring and maintenance.

There needs to be a collaboration between detection engineers and incident responders to ensure that alerts are valuable, actionable, and contribute to a successful security program. The emphasis should be on robust detection logic and infrastructure for effective threat detection. It highlights two key areas:

3.Log Visibility & Timeliness:

• Comprehensive Data Sources: Ensure you collect log data from a wide range of sources, including operating systems, endpoint detection and response (EDR) tools, network devices, cloud platforms, and applications. This ensures comprehensive visibility into potential threats.
• Real-time Data: Log data should reach your detection logic in near real-time to enable rapid response to security incidents.
• Data Optimization: Remove unnecessary log data from your Security Information and Event Management (SIEM) system to optimize performance and reduce storage costs.

 4.MITRE ATT&CK:

• Integration: Integrate the MITRE ATT&CK framework into your detection processes and documentation. This helps you understand attacker tactics and techniques, prioritize threats, and develop more effective detection rules.

Having comprehensive log visibility, timely data, and a threat-informed approach to detection logic to ensure a strong security posture. The team needs to optimize the relationship between detection engineering (creating alerts) and incident response (handling those alerts) for a more effective security process.

Here's how: -

Detection & Incident Response Relationship:

• Collaboration is Key: Constant communication and feedback between the teams who create alerts and the teams who respond to them is crucial. This helps improve low-quality alerts and ensures new alerts are high-quality and actionable.
• IR-Focused Design: When creating new alerts, consider the needs of the incident response team. Ask: Is this alert worth their time? Can the response be automated? Are there clear and actionable steps the IR team can take?

Automated Resolution by the User:

• Self-Service Options: Explore secure ways to allow users to resolve certain types of alerts themselves, without needing to involve the incident response team.

Example: A Slackbot could be used to guide users through simple remediation steps or to gather more information about an alert.

A strong partnership between detection and response teams to ensure that alerts are meaningful, actionable, and contribute to a more efficient and effective security operation.

The next steps build on IR  focusing on validating and refining detection logic to ensure it effectively identifies and responds to threats. It emphasizes two key areas:

Purple Teaming:

• Purpose: Purple teaming involves simulating real-world attacks to test and validate the effectiveness of your detection mechanisms.

Benefits:

• Identify Gaps: Uncover weaknesses in your detection logic, such as missed events or false negatives.
• Continuous Improvement: Provide feedback to improve detection rules, processes, and overall security posture.
• Recommendation: Conduct regular purple team exercises to ensure your detection capabilities remain effective against evolving threats.

Threat Intelligence:

• Focus on Probable Threats: Prioritize detection development based on your organization's threat model, focusing on the most likely and impactful threats.
• Incorporating Frameworks like such as MITRE ATT&CK ,TIBER, iCAST, TLPT which leverage TI as central component to conduct activity. This helps map your detection coverage, and identify areas for improvement.
• Test and Build: Develop and test detection rules for the most used ATT&CK techniques. 

Purple teaming directly addresses the need to validate that alerts are actionable and provide sufficient context for the incident response team. Purple teaming helps ensure that your log visibility and data sources are adequate for detecting real-world attacks. It also reinforces the importance of integrating threat intelligence into your detection strategy.

Overall, the importance of continuous testing and refinement of detection logic to maintain an effective security posture. By combining purple teaming with threat intelligence, organizations can proactively identify weaknesses and improve their ability to detect and respond to evolving threats.

Key Principles:

1. Prioritize Alert Value: Every detection rule should be evaluated based on its value to the IR team. Ask the critical question: "Is this alert worth someone's time?" This requires a clear understanding of what constitutes a valuable alert, which may vary depending on the organisations risk profile, threat landscape, and IR team capabilities.
2. Begin with the End in Mind: Detection engineers should consider the incident response process from the outset. Before developing a new detection rule, they should collaborate with the IR team to determine: Actionability: What actions will the IR team take if the alert fires? Context: Does the alert provide sufficient context for effective triage and investigation.Automation: Can the alert resolution be automated, or can it be routed to the end-user for self-service remediation?
3. Continuous Feedback Loop: Maintain close collaboration between detection engineers and incident responders throughout the detection lifecycle. This includes: Regularly reviewing existing detection rules: Ensure that alerts remain relevant and valuable as the environment and threat landscape evolve. Soliciting feedback from IR: Gather input on alert quality, actionability, and areas for improvement. Developing frameworks for managing low-fidelity alerts: Establish processes for handling alerts that require significant time and effort to investigate.
4. Empower Incident Responders: Incorporate incident responders into the detection development process. This can include: Granting approval authority: Allowing IR leaders or senior responders to approve or deny new detection logic before it's deployed. Leveraging detection-as-code: Implementing version control and CI/CD pipelines to enable seamless review and collaboration on detection logic.

Benefits of Focusing on the IR Experience:

• Reduced Alert Fatigue: Minimize the number of irrelevant or low-value alerts, allowing IR teams to focus on critical threats.
• Improved Efficiency: Streamline incident response processes by providing actionable alerts with sufficient context.
• Faster Response Times: Enable quicker triage, investigation, and remediation of security incidents.
• Enhanced Collaboration: Foster better communication and collaboration between detection engineers and incident responders.
• Stronger Security Posture: Improve the overall effectiveness of the organization's threat detection and response capabilities.

By prioritizing the incident response experience, organizations can optimize their detection efforts, reduce alert fatigue, and empower their IR teams to respond to threats more effectively.

Detection Logic and Infrastructure

Effective threat detection relies on a robust infrastructure and well-defined detection logic. To achieve this, organisations need to strategically align their data sources, prioritize detection development, and continuously validate their capabilities.

Key Considerations:

1. Data Visibility and Timeliness: Critical Data Sources: Identify the data sources crucial for detecting and responding to threats. This might include logs from firewalls, intrusion detection systems, endpoint detection and response (EDR) solutions, cloud platforms, and identity providers. Data Quality: Ensure data quality and timeliness. Data must be accurate, complete, and readily available for analysis. SIEM Ingestion: Even with "unlimited" SIEM licenses, organizations face limitations on data ingestion. Prioritize ingesting data from critical sources and consider trimming or dropping fewer valuable data to optimize resources.
2. Skills and Platform Capabilities: Ensure your team possesses the necessary skills to develop and implement effective detection logic. This includes expertise in security analysis, threat hunting, and data science.Baselining or acceptable limits can be achieved using experience gained from previous engagements Platform Capabilities: Evaluate your security platform's ability to support the required detection logic. This includes the ability to process and analyze data from various sources, create complex rules, and integrate with other security tools.
3. Detection Prioritisation: Collaborative Approach: Establish a collaborative process for prioritizing detection development. Involve threat intelligence teams, incident responders, and security engineers to gain diverse perspectives and ensure alignment with organizational needs. Threat-Informed Approach: Prioritize detection development based on the organization's threat model, focusing on the most likely and impactful threats.
4.  Continuous Validation: Purple Teaming: Conduct regular purple team exercises to test and validate detection capabilities. This involves simulating real-world attacks to evaluate how effectively your detection logic identifies and responds to them. Identify Gaps: Use purple teaming to uncover gaps in your detection pipeline, such as missing data sources, ineffective rules, or integration issues. Data-Driven Improvement: Leverage the insights from purple teaming to improve detection rules, refine processes, and enhance your overall security posture.

Benefits of Optimization:

• Improved Threat Detection: Enhance your ability to detect a wider range of threats, including advanced and targeted attacks.
• Reduced False Positives: Fine-tune detection rules to minimize false positives and reduce alert fatigue.

 By strategically managing data sources, prioritising detection development, and continuously validating capabilities, organisations can build a robust and effective threat detection program.

Key Components of a Mature Detection Engineering Program at a high level

People:

a)     Dedicated Detection Engineering Team: A dedicated team with specialised skills in threat hunting, security analysis, and data science.

b)    Collaboration: Strong collaboration between security teams, IT operations, and threat intelligence providers.  

The Human Element

Specialised Skillsets: A mature detection engineering team needs a blend of skills:

a)     Threat Hunters: Proactively search for threats that evade existing security controls. They need strong analytical skills, knowledge of attacker tactics, and the ability to think like an adversary.

b)    Security Analysts: Investigate alerts and incidents, perform root cause analysis, and develop detection rules. They need deep technical knowledge of security tools, operating systems, and network protocols.

c)     Data Scientists: Apply data science techniques to analyze security data, identify patterns, and develop advanced detection models. They need expertise in machine learning, statistical analysis, and data visualization.

Collaboration is Key: Detection engineering isn't a solo endeavor. Effective teams foster collaboration with:

a)     IT Operations: Share knowledge about the IT environment, system configurations, and normal network behavior.

b)    Threat Intelligence Providers: Obtain up-to-date information about emerging threats, attacker tactics, and indicators of compromise (IOCs).

c)     Incident Response Teams: Share information about incidents and attacks to improve detection rules and prevent future occurrences.

 Process:

a)     Defined Detection Strategy: A clear strategy aligned with the organization's risk profile and threat model.

b)    Formalised Workflow: A structured process for developing, testing, deploying, and maintaining detection rules.  

c)     Continuous Improvement: Regular review and tuning of detection rules based on threat intelligence, incident response feedback, and performance metrics.

 Structure and Continuous Improvement

 Defining a Detection Strategy:

1. Threat Modeling: Understand the organization's attack surface, identify potential threats, and prioritize assets.
2. Data Sources: Determine which security data sources are most relevant for detection (e.g., logs from firewalls, EDR, cloud platforms).
3. Detection Rules: Define the types of detection rules to be developed (e.g., signature-based, anomaly-based, behavioral).

Formalised Workflow:

1. Rule Creation: A standardized process for developing and documenting detection rules, including clear criteria and testing procedures.
2. Version Control: Use version control systems (like Git) to track changes to detection rules and ensure consistency.
3. Deployment: A controlled process for deploying new or updated detection rules to production environments.

Continuous Improvement:

1. Metrics: Track key performance indicators (KPIs) like the number of true positives, false positives, and dwell time.
2. Feedback Loops: Gather feedback from security analysts, threat hunters, and incident responders to refine detection rules and processes.
3. Threat Hunting: Regularly conduct threat hunts to identify gaps in existing detection capabilities and proactively uncover hidden threats.
4. Technology: Advanced Security Tools: Utilizing a variety of security tools, including SIEM, EDR, NTA, and threat intelligence platforms. Automation: Automating tasks like data collection, analysis, and alert triage.   Detection-as-Code: Treating detection rules as code, using version control and automated testing.  

Maturity Levels:

Many frameworks define maturity levels, often ranging from ad-hoc and reactive to proactive and optimized. Here's a common example:  

• Level 0 - Initial: Reliance on basic security tools with limited customization.
• Level 1 - Basic: Some customization of detection rules, but still largely reactive.
• Level 2 - Intermediate: Proactive threat hunting and development of custom detection rules.
• Level 3 - Advanced: Automated analysis and response, with continuous improvement of detection capabilities.
• Level 4 - Expert: Threat prediction and proactive mitigation based on advanced analytics and threat intelligence.

 Benefits of a Mature Detection Engineering Program:

• Improved Threat Detection: Identify and respond to a wider range of threats, including advanced and targeted attacks.
• Reduced Dwell Time: Minimize the time attackers spend in your environment.  
• Faster Incident Response: Respond to security incidents more quickly and effectively.  
• Reduced Risk: Lower the overall risk of successful cyberattacks.
• Improved Security Posture: Strengthen your organization's overall security posture.

 Assessing Your Detection Engineering Maturity:

To assess your organisations detection engineering maturity, consider the following questions:

• Do you have a dedicated detection engineering team?
• Do you have a defined detection strategy and workflow?
• How do you prioritize and respond to security alerts?
• Do you leverage threat intelligence to inform your detection efforts?
• Do you use automation to improve efficiency?
• How do you measure the effectiveness of your detection program?

Tool stack to measure include but not limited to

a)     Security Information and Event Management (SIEM): Collects and analyzes security logs from various sources, providing a centralized platform for threat detection and monitoring.

b)    Endpoint Detection and Response (EDR): Monitors endpoint activity to detect and respond to malicious behavior.

c)     Network Traffic Analysis (NTA): Analyzes network traffic to identify suspicious patterns and anomalies.

d)    Threat Intelligence Platforms (TIPs): Provide access to curated threat intelligence feeds, IOCs, and vulnerability information.

e)    Security Orchestration, Automation, and Response (SOAR): Automates security tasks, such as alert triage, incident response, and threat intelligence enrichment.

f)      User and Entity Behavior Analytics (UEBA): Detects anomalies in user and entity behavior to identify insider threats and compromised accounts.

Detection Engineering Maturity is a critical concept, and understanding its nuances is essential for CISOs. Here's a deeper dive with more specific examples and considerations:

Detecting a Ransomware Attack

Let's say your organization wants to improve its detection of ransomware attacks. Here's how a mature detection engineering approach might look:

• Threat Modeling: Identify critical assets and data that are most vulnerable to ransomware.
• Data Sources: Collect logs from EDR, file integrity monitoring, and network traffic analysis tools.
• Detection Rules: Develop rules that detect suspicious file activity, network connections to known ransomware command-and-control servers, and unusual encryption activity.
• Automation: Use SOAR to automate the response to ransomware alerts, such as isolating infected systems and blocking malicious traffic.
• Continuous Improvement: Analyze past ransomware incidents to identify patterns and improve detection rules.

Key Takeaway: Detection engineering maturity is an ongoing journey, not a destination. By continuously investing in people, processes, and technology, organizations can build a robust detection program that effectively protects against today's sophisticated cyber threats.

Metrics are crucial for assessing and improving Detection Engineering Maturity.

These are a set of metrics to measure the effectiveness of a detection engineering program, specifically focusing on detection performance and the maturity of detection-as-code practices.

Detection Performance Metrics:

• % False positives: Measures the percentage of alerts that are not actual threats. A high rate of false positives can lead to alert fatigue and wasted effort.
• % "Expected behavior": Tracks the percentage of alerts that represent expected or benign activity. This helps identify areas where detection logic can be refined.
• % of alerts resolved by an end user: Measures the percentage of alerts that can be resolved by the end-user without involving the security team. This indicates the level of automation and self-service capabilities.
• Mean time to detect (MTTD): Measures the average time it takes to detect a threat. Lower MTTD indicates faster detection and response.
• % of "probable" ATT&CK TTPs covered by detection logic: Measures the percentage of probable attacker tactics and techniques covered by your detection rules. This indicates the breadth of your threat detection coverage.
• % of detection catalogue tested by a purple team exercise: Measures the percentage of your detection rules that have been tested through purple team exercises. This indicates the level of validation and confidence in your detection capabilities.

 Detection-as-code Metrics:

• % of detection logic in version control: Measures the percentage of detection rules that are managed using version control systems. This indicates the level of maturity in applying software engineering principles to detection development.
• % of logic with test coverage: Measures the percentage of detection logic that has automated tests. This indicates the level of quality assurance in your detection development process.
• % of deployments with errors: Tracks the percentage of detection rule deployments that result in errors. This helps identify areas for improvement in your deployment process.[ST5] 

 These metrics are crucial for several reasons:

• Measure Effectiveness: They provide a quantitative way to measure the effectiveness of your detection engineering program.
• Identify Areas for Improvement: They highlight areas where you can improve your detection logic, infrastructure, and processes.
• Track Progress: They allow you to track progress over time and demonstrate the value of your detection engineering efforts.
• Drive Continuous Improvement: They support a data-driven approach to continuous improvement in your threat detection capabilities.

Here's a sample breakdown of key metrics, categorized by area, with some basic examples:

 1. Detection Coverage:

• Metric: Percentage of Tactics, Techniques, and Procedures (TTPs) covered by detection rules. Example: "We have detection rules in place for 80% of the TTPs associated with ransomware attacks."
• Metric: Number of data sources integrated into the detection pipeline. Example: "We collect and analyse security logs from agreed log  sources, including firewalls, EDR, and cloud platforms."
• Metric: Mean Time to Detect (MTTD) for known threats. Example: "Our average time to detect a known phishing attack is 10 minutes."

 2. Detection Accuracy:

Metric: True Positive Rate (TPR) - the percentage of actual threats that are correctly identified. Example: "Our detection rules have a true positive rate of 95% for malware infections."

Metric: False Positive Rate (FPR) - the percentage of benign events that are incorrectly flagged as threats.Example: "Our false positive rate for account lockout alerts is 2%."

Metric: Alert Triage Efficiency - the time it takes to triage and investigate security alerts.Example: "Security analysts can triage 90% of alerts within 30 minutes."

 3. Detection Efficiency:

Metric: Mean Time to Respond (MTTR) - the time it takes to respond to and remediate a detected threat.Example: "Our average time to respond to a critical vulnerability is 2 hours."

Metric: Automation Coverage - the percentage of detection and response tasks that are automated.Example: "70% of our alert triage process is automated through SOAR playbooks."

Metric: Number of detection rules created per analyst per month.Example: "Each detection engineer creates an average of 5 new detection rules per month."

4. Threat Hunting Effectiveness:

Metric: Number of proactive threat hunts conducted per month.Example: "The threat hunting team conducts 4 proactive threat hunts per month."

Metric: Number of new threats or vulnerabilities discovered through threat hunting.Example: "Threat hunting activities identified 2 previously unknown malware variants in the past quarter."

Metric: Time spent on threat hunting activities.Example: "Security analysts dedicate 20% of their time to proactive threat hunting."

5. Continuous Improvement:

Metric: Number of detection rules updated or improved per month.Example: "We update or improve an average of 10 detection rules per month based on new threat intelligence and incident response feedback."

Metric: Frequency of detection rule reviews and tuning.Example: "All detection rules are reviewed and tuned at least quarterly."

Metric: Number of lessons learned documented and implemented from security incidents.Example: "We documented 5 key lessons learned from a recent phishing campaign and implemented changes to our detection rules and user awareness training."

Important Considerations:

• Context is Key: Metrics should be interpreted in the context of your organisations specific environment, risk profile, and security goals.
• Focus on Trends: Track metrics over time to identify trends and measure progress.  
• Qualitative Metrics: Don't just focus on quantitative metrics. Qualitative factors like team expertise, collaboration, and process maturity are also important.
• Continuous Improvement: Use metrics to identify areas for improvement and drive continuous enhancement of your detection engineering program.   

By honestly assessing your current maturity level, you can identify areas for improvement and develop a roadmap for building a more robust and effective detection engineering program.

 References

A big thanks to Sujit T. for contributing to the above article.

Thanks to Krishna Balakrishnan (BKP) for conceptualising and giving practical inputs to make this a success.

A detailed version of the detection-engineering-maturity-matrix can be found at - https://detectionengineering.io/

Other references

 https://github.com/k-bailey/detection-engineering-maturity-matrix

 https://kyle-bailey.medium.com/detection-engineering-maturity-matrix-f4f3181a5cc7