Engineering The Design Of A Threat Pattern

In our journey of developing and maintaining threat patterns, we have now arrived at a critical phase: the design. While the need of an implementation phase is immediate as well as the evaluation of the background analysis in order to build something meaningful (as explained by my colleague, Demetrio Milea) – the intermediate design phase is the most underestimated component of the process.

Content engineers in a SOC love to move from abstract ideas into coding and development right away. They believe speed can save time, and that quick design production may result in immediate, working solutions. This is likely a key reason why many current detection strategies are so ineffective against motivated attackers. If there is something worse than being exposed to risks, this is a wrong way to counter it. Implementing a threat pattern we believe will be able to detect a specific scenario, but won’t due to improper design and evaluation, is equally bad.

The outcome of proper analysis can provide us with great insights on the challenges that we are really trying to solve, and the residual risk that we should consider. In the design phase, we can start addressing the problems by evaluating the use and abuse cases that we have previously identified. Additionally, having a good coverage in this phase is absolutely key if we want to be aligned with the risk analysis.

Similar to the process for designing a piece of software, during the threat pattern design phase – we need to identify the critical data to input into our model, as opposed to doing the reverse  – shaping the model solely based on the data available. By doing this, we are also able to ask a set of challenging question about what particular output would be beneficial for the entire process, because we are able to think through what valuable data sources or platforms we were not considering previously.

After thinking through the data components, we need to link the different pieces of our design model together.  When designing the logical flow and building blocks of the threat pattern, it’s critical to not make any quick assumptions. You shouldn’t assume that there is only one platform for implementing a given pattern because this would dramatically limit the efficacy of the detection. A very common mistake at this stage is to design something with only SIEM technology in mind. SIEMs are valuable in a SOC for gaining a comprehensive understanding of what security controls are detecting but SIEM technology shouldn’t be considered in a silo, because the pattern would have inherent limitations.

At this stage, we need to consider a threat pattern in the same way as we would when creating a software design pattern: our objective should be to develop a general and reusable solution to a commonly occurring problem. As a sorting algorithm would achieve the same result regardless of the programming language that it is implemented in,  a well-designed threat pattern needs to be implemented in a technological set up that would best address the inherent residual risk we are considering.

Since we are talking about detection patterns, we should consider the development of the logic built to identify a specific situation and understand how the patterns should work in conjunction with our alerting strategy, so to let our security team know about it. Not all the patterns are necessarily bad, but they can be if the situation is particularly ugly. It’s important to build the quantification of a given scenario into the design phase to ensure that the pattern is flexible enough to adapt to this ever-changing threat landscape. In this phase, you need to think how you could derive a value out of the pattern, in order to define a threshold level above which a particular event becomes significant.

As design patterns can speed up the software development process, it’s important for teams to spend an adequate amount of time in the design phase when they create threat patterns.  Allocating the necessary time and check points throughout your design work can help  anticipate issues that may not become visible until implementation, provide a proven and re-usable paradigm that can be used with other indicators, and ensure consideration of a  platform-independent architecture that can be more effective against a specific attack vector.

No Comments