https://odef.wiki/odef/phases/index.htmlIntro 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 ODEF pioneers the concept of a detection lifecycle, comprehensively encapsulating the journey of a detection mechanism from creation to retirement. It's structured into three distinct phases: Sunrise, Midday and Sunset. This tri-phase approach ensures thorough coverage for each stage of a detection's active life. Corresponding to each phase are specific functions, goals, and guidelines that lay the groundwork for effective and efficient detection engineering.Hugoen-USMon, 01 Jan 0001 00:00:00 +0000https://odef.wiki/odef/phases/sunrise/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://odef.wiki/odef/phases/sunrise/index.htmlPhase 1️⃣ Sunrise 🌅 Sunrise is the first phase of the detection lifecycle. It marks the inception, development and deployment of the detection. During that phase there are 6 core functions that should be addressed: Research Prepare (Logging) Build (Detection Content) Validate Automate Share (Knowledge) High level goals for the Sunrise phase Build high fidelity detection Ensure detection validation Create documentation Integrate and automate in the environment Socialize the detection with the security organization Functions Goal Description Guidelines Research Opportunity Identification It can be triggered from analyzing threat intelligence reports, or OSINT, or internal knowledge for a particular security gap. Document the use case and the goals of the detection as part of the opportunity identification process. Document the use case that you’re building and set goals. Is the TTP already covered by an existing alert or detection? Is there sufficient knowledge to start building or additional research would be required? What are sources of information that will assist the research? Prioritize Detection engineering work has to be prioritized and tracked. Work prioritization can be based on urgency and priority. Backlog of detections and security posture activities is desirable and recommended. Prioritization criteria: Criticality of the systemhttps://odef.wiki/odef/phases/midday/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://odef.wiki/odef/phases/midday/index.htmlPhase 2️⃣ Midday ☀️ The “Midday” phase is normally the longest phase from the detection lifecycle, during which the detection has been engineered and commissioned to production. The phase monitors the detection during its operation and aims to improve it if needed. High level goals for the Midday phase: Operate and monitor the detection for FP or TP Improve the detection logic in case of influx of FP Perform systematic reviews to ensure relevancy Functions Goal Description Guidelines Monitor Run as per defined schedule Detection is configured to run on pre-defined schedule or real time if applicable Detections will run based on the schedule set during the sunrise phase. Confirm unittest passing Monitoring is configured to notify the responsible team in case the automation for the detection is not running properly Suggested approach: github actions - before deployment ensuring proper syntax Work detections Once detection is running it should be monitored for any TP or potential influx of FP TP events should be triaged, investigated and responded on by following an agreed IR process. FP events should be investigated, proved as FP and documented as part of the baseline. Once the baseline is changed in the documentation the query can be updated and improved. Measure Measure detection efficacy Enable metrics for the detection based on which areas for improvement can be identified. Mitre Attack weakness Success/failure of automating detections Services covered Each detection that covers particular TTP can be marked in the Mitre ATT&CK Navigator. Looking at percentage of covered tactics and techniques can be a metric. Success or Failure in detection automation or influx of FP metric can be used to identify detections that require improvement. Detection runtime length is a metric which can identify poorly written queries. For example, query too open that collects way too many events and chunks too much data only to spend even more time to filter by using custom logic. Improve (optional) Improve detection fidelity Once improvement opportunities have been identified during the operations or periodic review an improvement is triggered The goal of this function is to improve any detections which are with poor health (slow runtime, causing errors) and improve them by revisiting the detection logic. Review Perform periodic review Review detections to identify improvement opportunities or decommission requirements Detection can become irrelevant and thus decommissioned when: The risk that it is compensating is far smaller than the cost of running the detection The technology used for the detection is no longer present in the company Midday phase Process Flow graph TD; Monitor1(Run per schedule) -->Monitor2(Receive and respond to alerts); Monitor2 --> Monitor3{False Positives?} ; Monitor3 --> |no| Measure[Document TP]; Measure --> Review(Perform periodic review) Monitor3 --> |yes| Improve(Improve); Improve --> Monitor1;https://odef.wiki/odef/phases/sunset/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://odef.wiki/odef/phases/sunset/index.htmlPhase 3️⃣ Sunset 🌆 During the “Sunset” phase the detection is taken out of commission. The phase wants to ensure that resources are not spent for outdated detections that are no longer applicable and at the same time leave sufficient trace of the existence of the detection. High level goals for the Sunset phase: Decommission the detection and leave it in a state that it can be resumed anytime Preserve knowledge Functions Goal Description Guidelines Decommission Decommission the detection The goal is to decommission the detection by following process that provides visibility In order to decommission a detection simply change the status field to "Sunset" in the .yml file. Assuming your devops pipeline is configured correctly, this should effectively disable the detections and prevent it from running. Note: Do not remove anything from the repository as detections can be reused in future. Knowledge base update Create an adequate indication in the KB document that the detection is no longer active and socialize the change with your security teams. Update Mitre coverage map by removing the coverage that the detection was providing Sunset Process Flow graph TD; Review1[Review completed] --> Review2; Review2{detection ready to decom} -->|no| End[end]; Review2{detection ready to decom} -->|yes| Preserve(Preserve knowledge); Preserve --> Decommission(Decommission the detection);