Threat Pattern Evolution and Testing

A threat pattern is not set in stone and a pattern that works effectively today may become obsolete over time. Types of threats, tools used, tactics and procedures evolve over time, as do a bank's business requirements and risk tolerance levels.

Because of the changes it is important to review each pattern periodically. Define criteria for periodic evaluation to target a broad spectrum of potential threats and ensure the results continue to align with business and risk objectives.

It is generally useful to retain design records during threat pattern development. This may include: records of the pattern’s original purpose, documentation of the specific threat/risk scenarios it was designed to detect and documentation of the specific exploitation vectors and targets it was designed to mitigate. 

During your evaluation the following questions need to be answered:

  • Is a new threat pattern required or can the existing one be enhanced?
  • Are changes designed to address the evolving requirements adequately?
  • How should measurements of residual risk be updated?

After evaluating the requirements, i.e. asset and threats, designing a general and reusable model for the threat pattern and implementing the model in the security monitoring platform, a person cannot assume that mistakes were not made. 

Specifically, that is why a well-structured and accurate testing process is important to validate design implementation and confirm that the bank has addressed the attack scenario effectively.

In conclusion, testing typically includes one or both methodologies a white-box and a black-box approach. 

  • White-box testing looks at the software code from the inside out. It verifies the threat pattern logic and ensures that design and development align with requirements. For each component, a list of inputs and outputs that trigger each part of a release should be completed.
  • Black-box testing takes an outside-in approach, examining the functionality of the threat pattern without dissecting its logic. For black-box testing, the best practice is to start from the attack scenarios originally defined during the analysis phase and determine the possible means an attacker can use to exploit the identified situations.