Although vulnerabilities, hackers and exploits are chief components of application security, they have been overshadowed by compliance issues in the minds of corporate decision makers.
With the myriad regulations and standards imposing stricter IT security requirements, application security has reached a pinnacle of importance in the context of regulatory compliance.
Risk management is a key requirement of many of these regulations and is one of the most difficult processes to complete. The difficulty lies in the fact that although the high-level threat is generally well understood (breach of customer data, denial of service, etc.), the underlying causes and sub-threats can lead to it remaining obscured.
Threat modeling is a powerful technique that helps to characterize the higher-level threat and separate it into more manageable sub-threats that can be addressed.
Buyer Beware the Risks
In the current legislative climate the burden of IT security falls on the software users. They are responsible for ensuring the confidential customer information at the core of most legislative texts is not compromised.
But what does this mean for a company’s IT division?
The perimeter defense concept is fairly easy to grasp: keeping the “bad guys” out. Perimeter defenses have however failed numerous times as a result of constantly being weakened to allow remote users to access corporate resources and because the distinction between trusted and distrusted users is increasingly unclear.
IT divisions must remember that once a user passes perimeter defenses then the burden of security lies with the applications that process data.
Both the software vendors and the companies that use the software must understand the risk that application imposes. For companies seeking compliance this is the starting point of risk mitigation. For software vendors this is a first step towards securing their products and making them more attractive for companies.
Understanding this risk is not a trivial task. The higher-level threats are generally well-understood because they are frequently mentioned in the regulatory texts (e.g., disclosure of sensitive customer data). It is difficult, however, to address these threats without considering the underlying sub-threats that can (and often do) yield catastrophic consequences.
Threat modeling is a powerful exercise that can help in risk determination. Here we will discuss two approaches to threat modeling: Threat modeling of an existing application and threat modeling during all stages of the software development lifecycle (SDLC).
Existing Apps
For many software vendors, security is still an afterthought. In this model, the priority is software functionality, and security is bolted on in the later stages of the SDLC. This is also the relevant model for software users who wonder about potential security failures in the products they have purchased.
One approach for threat modeling in this type of context is a three step process consisting of: analyzing the application, determining threats; and ranking the threats.
The first step, analyzing the application, consists of identifying the application’s features and user/attacker entry points. During this process it is important to note feature characteristics such as its relevancy to security and access level required to perform related tasks.
The second step, determining threats, is certainly the most challenging aspect of threat modeling. This step consists of breaking down the higher level threat into sub-threats that can be more easily addressed.
Once the threats and sub-threats have been identified they can be prioritized using various ranking techniques. One such technique is feature ranking. Here we score application features according their characteristics (is it a new feature with the current release? is it a security feature? is it installed by default?, etc.).
With this technique we assign to each feature a score that is a combined measure of the likelihood it will contain a security flaw and its potential for damage. We can then rank each identified threat by averaging the scores for features that are relevant to the threat. The broken down threats listed above are much more easily addressed when it comes to risk mitigation than the higher-level threat.
A completed threat model should provide the supporting material to prioritize risk mitigation and the framework for security testing.
Modeling in the SDLC
Proactive software vendors integrate security at all stages of the SDLC. For vendors or internal development teams that do so or realize they need to start doing so, threat modeling can be used to its full potential.
In this context the threat model should evolve during the SDLC and guide decisions at all stages. The process by which threats are characterized and ranked can be similar to the one described previously, however the threat model will grow and be refined as the product progresses through its lifecycle.
At the requirements/design phase, for instance, a proposal for the addition of a feature may be rejected because of the additional attack vectors it creates. At the implementation phase, the use of recognized encryption libraries may be elected in order to mitigate stealth of sensitive information.
Just as it was the case in the previously described context, the threat model can help prioritize risk mitigation and drive the security testing effort.
Whether threat modeling is performed on an existing application or throughout the SDLC it is an essential component in the risk management arsenal because it can help quantify and visualize the otherwise intangible threats an application carries.
Threat modeling is not a trivial exercise and should be done with care so as not to miss any aspect of the attack surface applications expose.
Fabien Casteran is a senior security engineer with Security Innovation.