In an era of agile development and digital transformation, any application is subject to ongoing enhancement and improvement. Indeed, software engineering is a complex process with many interdependent tasks where multiple functions share responsibilities to strike a balance between software quality and business objectives, regardless of the specialized nature of the teams within the organizational structure.

A similar analogy can be applied to a threat pattern, as Davide Veneziano and I outlined in this series of articles where we explored the initial phases of the lifecycle: Analysis, Design, Implementation, and Testing.

Once a threat pattern is developed and deployed into a production environment, it must be subject to ongoing review. We refer to this as “Evolution,” the fifth and final phase of the lifecycle. Threat patterns need to be monitored to ensure that they remain relevant and continue to deliver value relative to the workload of the analysts. This is a continuous process of evaluation and enhancement, required to keep up with newly discovered attack vectors and changes in the IT operating ecosystem.

Once again, we can borrow from software engineering. The “maintenance” of a threat pattern includes:

• Changes in the implementation technique (e.g. the way in which the model is engineered);
• Changes in the event source or external context data;
• Changes in threshold values.

Best practices in the software maintenance process can be brought to bear, more specifically ISO/IEC 14764, “Software Engineering – Software LifeCycle Processes – Maintenance,” which identifies four main types of maintenance: corrective, adaptive, perfective and preventive.

Corrective maintenance addresses bug repair or failures that should never have occurred. This is mainly due to design, coding, or logic errors. The testing phase of our model should, ideally, have prevented most of them. However, some errors only reveal as the model is deployed in a production environment while processing live data. In this category, it is also possible to include threat patterns whose defined thresholds are not met, such as:

• Degradation of system performance of the technologies;
• High number of alerts being triggered;
• Unacceptable levels of false positives / false negatives.

Adaptive maintenance addresses the need for the threat pattern to adapt to changes in the IT environment. As we know, “content is king, but context is queen” and even a minimal change can influence the effectiveness, efficiency and efficacy (the three “E”s) of a threat pattern. Close collaboration with the IT department, in this specific case, is key. For example, the on-boarding of a new application/platform provides the security team with a new event source, which can then participate in the overall program for threat detection.

Perfective maintenance addresses the need to accommodate functional enhancements, tweaks and minor improvements to the way the model is working. In this case, three primary elements need to be considered:

• Operational threat intelligence – Many security operations centers (SOCs) have the capability to proactively monitor for targeted attacks. Threat patterns can be enhanced by supporting the ingestion of internal and external context produced by the attackers’ activities.
• The “Lessons Learned” phase of the incident response lifecycle – The overall objective is to leverage the knowledge gained across incident responses as an input to enhance the current logic of specific threat patterns.
• Threat hunting activities – Proactive threat hunting enables the security team to better understand the IT operations environment and, consequently, improve and tune existing threat patterns with more insights about the organization’s network and application infrastructure. 

Preventive (or proactive) maintenance, consists of periodic efforts to reduce the complexity of the threat pattern itself and maintaining relevance by keeping it current.

It’s important to note in this last stage of the lifecycle the ability to identify which elements need to be modified does not rely on a single set of actions. Ideally, all enhancement requests should be managed in a centralized repository with change-tracking capabilities along with a determination of the benefits and impact of any proposed changes to the threat patterns.

During the review of a specific threat pattern, the security operation team might consider it no longer useful (for example, due to a different technology that can accomplish the same objective in a quicker or better way). In those cases, a formalized end-of-life (EOL) process must be activated by assessing the impact and involving all relevant stakeholders.

With this post the journey which brought us through the creation of meaningful threat patterns by leveraging a holistic engineering model comes to an end. By combining this approach with a focus on the quality, rather than the quantity, of threat patterns, organizations can develop threat management capabilities to better protect from IT security risks, mitigate existing threat, and leverage the limited resources available in the SOC in an efficient manner.