The security operations center (SOC) has reached the same tipping point that software development faced many years ago: It’s dealing with too much data (big data and log management), struggling to innovate and update monolithic software (detection and incident response processes), and lacking ownership beyond initial deployment (content management).
When the software world reached this point, it pivoted from building monolithic software based on a waterfall methodology to microservices and agile. The SOC can take advantage of these same lessons and apply them to detection and response engineering, the engineering-focused capability responsible for building new detections and response automation workflows.
Detection and response engineering follows three core principles:
- Follow a development lifecycle.
- Leverage agile.
- Embrace detection-as-code.
In this blog, we get into one of the most critical principles: following a development lifecycle, specifically the detection and response development lifecycle (DR-DLC).
This is a topic that I have been passionate about for a long time. I was a software developer in a previous life, and I’ve seen our clients leverage a development lifecycle in their detection engineering practice to build, test, update detections, and improve analyst experience. Below, we break down the basics of the DR-DLC.
Apply The Principles Of Software Development To Detection And Response Engineering
Software development frameworks such as the software development lifecycle (SDLC) provide a foundation for development improvement and differentiation, with a central focus on business value. These models can be applied to detection and response engineering through the DR-DLC to speed the creation, tuning, and deprecation of rules and analytics.
The DR-DLC helps your team establish a consistent and timely build process for detections that incorporates ideation, design, build, test, release, and continuous monitoring.
Below, each step of the DR-DLC is laid out. It turns the traditional content management model on its head by prioritizing metrics and analyst feedback through detection building and testing.
When used in conjunction with agile (for Agile + SecOps [security operations]), the detection engineering process becomes iterative, continuous, and collaborative. This is in sharp contrast to previous models, which relied on outside development teams for content creation and had little room for analyst feedback.
Importantly, this framework does not require software development skills or detection-as-code. While Forrester highly recommends leveraging detection-as-code with the DR-DLC, ultimately the DR-DLC is a process to follow that will provide better-quality detections regardless of the use of code. It’s about establishing an analyst-led framework in conjunction with agile principles of constant evaluation and improvement of net-new and existing detections.
There’s a lot more to this topic, including the other two principles, which you can find in this complimentary version of the full report, How To Build A Leading Detection And Response Engineering Practice. Feel free to reach out to me or if you’re a Forrester client set up an inquiry or guidance session to talk this through further. This is a controversial topic with a lot of implications and moving parts — I want to hear from you!