Shifting from Detection 1.0 to 2.0 | by Haider Dost | Snowflake Builders Blog: Data Engineers, App Developers, AI/ML, & Data Science | Medium

As the threat landscape continues to evolve, Threat Detection teams are doing their very best to ensure their organization has enough detection coverage and depth while balancing the noise and overall alert volume generated from these detections. The backlog of detections that need to be built continues to grow and alert fatigue continues to be a problem. Reviewing our internal situation, we found that one of the primary reasons for alert fatigue was that all our detections were atomic: they were surfacing an alert every time they triggered, and they lacked context on the asset and identity tied to the alert. And while certain detections will have to always remain atomic, that should not be the default. To add, many organizations are still operating in the traditional Security Information and Event Management (SIEM) model, where security data is segregated from business data, and lack a detection development process. How can teams start to break away from this and overcome these challe

As the threat landscape continues to evolve, Threat Detection teams are doing their very best to ensure their organization has enough detection coverage and depth while balancing the noise and overall alert volume generated from these detections. The backlog of detections that need to be built continues to grow and alert fatigue continues to be a problem. Reviewing our internal situation, we found that one of the primary reasons for alert fatigue was that all our detections were atomic: they were surfacing an alert every time they triggered, and they lacked context on the asset and identity ti