Posted by Jim DelGrosso on August 30, 2016
When it comes to security, the vast majority of firms take measures to discover and remediate implementation-level software defects (i.e., bugs) in code. While this is a great start to securing software and data, it’s just that—a start. Bugs are only half the problem. It’s a necessary practice to look beyond squashing bugs, and into the design-level flaws (i.e., architectural defects) within software.
A threat model is the best way to identify these flaws. This security analysis documents threat agents, motivations, attack surfaces, attack vectors, probability, impact, and mitigation information for a system to facilitate risk analysis of a piece of software. The risks identified through threat modeling are used to improve downstream security activities to strengthen your firm’s stance. In other words, it’s the foundation on which you can build secure software goals.
You’ve gone through the exercise of creating a threat model to identify flaws. Now what can you hope to do with that output? There are several options of where to go from here:
Your threat model identifies assets in your system, the controls protecting those assets, and threat agents with potential to defeat or circumvent those controls. Use this information during code reviews to verify that code corresponding to (or implementing) these controls doesn’t contain defects.
If you have time limitations regarding a code review, use the threat model to establish the highest priority code for the review. For example, code implementing a control that protects a valuable asset and is potentially accessible by an unauthorized attacker is a high priority.
Establishing a testing strategy.
In a moderate to large application, it’s likely that not all parts of the system operate at the same level of sensitivity. There might be administrative functions allowing privileged users access to data that others users cannot access.
Perhaps report data containing sensitive information is generated and stored somewhere. Perhaps, under certain conditions, information is exchanged with business partners. Whatever the case, the phrase “all things are not created equal” likely holds true. Therefore, it seems reasonable that not all parts of the system should be treated as equal from a testing perspective.
Some examples where more targeted tests could be applied include:
Understand the importance of assets, and the fact that some controls are “hard to get right.” This allows you to re-focus tests to cover those elements that are more valuable to the threat agents of your system.
Let’s take a look at a second example. In another threat model, someone is using an encryption algorithm to secure data in transit. The encryption logic is very good and correctly encrypts the data following the company’s best practices for using encryption APIs. The problem is that the requirement calls for unaltered data. However, the current design is using a confidentiality control, not an integrity control. Cryptography training explains basic differences like confidentiality in comparison to integrity. It’s also critical to note that any use of cryptographic APIs must be vetted by your software security group.
Keeping track of the security controls used by components in an application allows you to understand the potential risk to that application when the effectiveness of a security control changes. For example, assume a component uses a cryptographic primitive and a weakness is found in that primitive. Knowing the component that makes use of that security control allows you to better assess how the weakness in the security control affects the overall risk to your application. This allows you to answer questions like:
Know the answers to these types of questions. This allows you to determine the best course of action to mitigate the risk for that application.
Let’s say that you review a threat model and notice two components communicating with a database that connects with the same credentials. However, their access requirements are very different (e.g., one component requires read-only access, the other requires update access). Then you see it again in another application. And then again…
Restricting access based on what you need to access (principle of least privilege) is a technique to limit the potential damage should a vulnerability exist that allows a threat agent to access some asset. Having guidance on this topic may also improve the security posture of future applications with a similar design.
The primary reason for threat modeling is to create a more secure design or identify weaknesses in an existing design. However, it can also improve aspects of your overall software security program.
Get the latest AppSec news and trends sent directly to you.