If you do not fully know the asset, how can you protect it? This is the first challenge security practitioners face during any activity, whether it is a penetration test, code review, risk assessment, or design of a threat pattern.
In a previous post, author Davide Veneziano provided an overview of the building-block required to design a consistent threat pattern, highlighting the importance of scoping the asset in order to develop and maintain meaningful threat indicators.
To prepare for the successful identification of threat patterns, it is then beneficial to invest effort in the first phase, the "threat risk analysis," where the threat modeling assessment is blended with a risk analysis of the asset. The objective is to have a deep understanding of the characteristics and peculiarities of the ecosystem and protect it accordingly.
A lot has been written around the various risk analysis and threat modeling techniques. Considering that they complement each other, combining to provide the greatest visibility and understanding of the targeted asset and to define a realistic business and risk context in which operates. Adopting this approach can help the security team to evaluate:
- Which components of the asset ecosystem might be attacked?
- What are the attack vectors that might be used?
- Who might exploit a certain vulnerability (whether an external or an internal user actor)?
- Which are the threats that can impact the business, the confidentiality and integrity of the asset?
- What are the most likely risk scenarios and the associated degree of damage an attack could cause?
- Which security solutions can be applied to mitigate the risks which have been identified?
Once the analysis is completed and the complete picture is defined, an understanding of the native security features of the asset also plays a key role.
Let's consider for example a brute-force attack use case on the authentication process of an asset. The detection of this attack could be done by implementing the following logic: "detect certain number of events X, followed by event Y." If the approach above does not leverage knowledge of the assets native security capabilities, it might lead to the deployment of unneeded detection controls. For example, if the asset already had a CAPTCHA or comparable security mechanism that can mitigate the threat, we would realize that scarce resources could be applied towards the implementation of other use cases.
It is also important to highlight, that one of the possible outcome of the "threat risk analysis" is that the threats cannot always be fully mitigated by applying further security controls. Sometimes it is just not possible, unrealistic or even not effective and here it is where security monitoring solutions fit even better. Such "residual risks" defined as those that remain after security countermeasures have been applied, can be monitored by developing and shaping threat patterns in relation with security controls which have been implemented to protect the asset, the data flows and the potential attack vectors. This is why a threat pattern should always be developed to detect events based on residual risk and the monitoring of the attack scenarios which can circumvent any existing defense mechanisms.
By leveraging this approach, a security team is enabled to work and focus on those threats that can be exploited, rather than more obvious but less relevant threats. In organizations with a tight budget and small teams, this methodology can help save time and money and reduce the implementation of unnecessary security controls. The identification and remediation of residual risks can result in a more efficient allocation of resources. It helps to monitor and identify the real threats we care about and avoid the potential for elaborate and complex countermeasures that do not enhance the security posture of the organization.