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:
| 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 detention logic. |
| Review | Perform periodic review | Review detections to identify improvement opportunities or decommission requirements | Detection can become irrelevant and thus decommissioned whe: 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 |