5: Research and Capability Development Scoping (RCDS)

Fig. 18 RCDS

A particular challenge when scoping and planning for security content, artifacts, rules, or anything not necessarily a direct product feature, is that it can be less obvious what to focus on and how to partition work. It also tends to be very time sensitive and is exacerbated by the fast pace nature of emerging threats and an always changing environment that is being protected. This is intended to be leveraged throughout planning, while accounting for the unpredictable threat landscape to revalidate scope and priority as needed.

If development is in support of external customers, detection engineers must consider the implications of the diverse environments and multiple competing requests about what to focus on and deliver. This is a means to optimize resources and time, ensuring the best outcomes for the investment. Lastly, this is specifically tailored to help with scoping and prioritizing threat centric development of rules and similar capabilities.

Diving into the steps of the RCDS

Each of these categories make use of specific examples, which should be customized depending on your specific use case. Consideration of the target environment is imperative to influence this process, so as previously mentioned, product teams building for users across a diverse set of environments, may need to adopt a conceptual environment, which should be the same environment from previous steps.

The pseudo-environment should be an amalgamation of the perception of standard environments based on reference architectures, awareness of our internal environment, and observations from customer telemetry.