Goal-oriented security threat modeling approaches

Posted by Jim DelGrosso on Tuesday, 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.

Creating actionable goals with your security threat modeling results.

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:

Influence code review activities.
Influence downstream testing.
Highlight areas where more training will be helpful.
Highlight areas where better guidance can be provided to avoid defects.
Know which controls are used for which components.
Avoid flaws in the future.

Improving the effectiveness of your code reviews.

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:

Parts of the system providing access to restricted data (higher valued assets).
Parts of the system allowing the privileged access (really focus on the authorization control to see if it can be bypassed).
Tests that trigger special monitoring that the operations team can use to identify an attempted attack.
Tests that initiate from the threat agent’s perspective (e.g., not all attacks start as an unauthorized or authorized user in the Internet).

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.

Identifying helpful training topics.

In one Web application threat model, business logic (in this case a security control) is in JavaScript that is running on the client’s system. In another Web application threat model, data validation exists. However, the data validation only exists on the client’s system prior to form submission. In this case, we can surmise that the developer, or team of developers, can benefit from basic web application security testing. Introductory software security courses often cover basic topics including client-side data validation and server-side data validation. Although client-side data validation provides benefits such as a nice user experience, it is generally easy to bypass. As such, it is a poor security control. A software security course covers the more general idea that anything on the client can be manipulated (data or code). Thus, having business logic run on the client is another example of a weak security control.

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.

Knowing the security controls used by various components.

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:

Which assets are protected by that control?
What threat agents pose the greatest risk to defeat that control?
What part of my attack surface is affected by the weakness of that control?

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.

Avoiding flaws in the future.

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 bottom line.

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.