Threat modeling enhanced with misuse cases

We have heard how important it is to include security in the software development life cycle (SDLC). We have also seen approaches such as threat modeling, which captures the threat profile of a system. Threat modeling documents are very useful for architects, as well as for testers to a certain extent, as they help provide a more accurate sense of security.

Threat modeling documents have one major challenge, however: If we make them too granular by capturing all the details, they get too big and later get buried under the pile of other documents. If we don't capture all the details, then we leave out most of the details pertaining to the developers.

This is where use cases that focus on the misuse of software are a perfect fit. Where threat modeling works more on the architecture level, misuse cases target individual functionalities and detail the individual threats to that functionality. Threat modeling documents capture possible threats, while misuse cases explore those threats and bind them to specific functionalities of the application. Misuse cases are created by architects, and developers and testers rely on them heavily.

Misuse cases can be approached two ways:

1. Identify a malicious user (mis-actor) and capture all the threats he can pose to the system, such as denial of service (DoS), SQL injection, brute force, and escalation of privileges. This is more like a threat modeling approach where all the possible attacks are identified and attack trees are defined to capture the attack profile of the system.
2. Identify a misuse case scenario from your use cases, where you capture all the information related to possible threats to the functionality along with mitigation steps. For example, if you have a forgot password use case, a misuse case identified for this use case will capture the type of attacks that can happen to this use case, such as denial of service, SQL injection and brute force attacks.

As you see in the second case, instead of identifying mis-actors from an overall architecture perspective, you identify scenarios in the normal flow of an application that can be exploited by a malicious user.

Application security in the SDLC Secure SDLC: Integrating security into your software development life cycle  The most effective time to do security testing  Best practices for building software security into the SDLC

With that approach, you may have more than one misuse case with similar types of attacks, but it will help developers and testers focus their approach toward integrating and testing security in an application at individual functionalities.

Moreover, a properly constructed misuse case, which captures all the possible attacks on the system along with mitigation steps, can help architects identify architectural changes in the design phase, help developers understand the malicious user's approach to write more secure code, and help testers (who may or may not have as good an understanding of the possible attacks) identify test cases for those attack scenarios.

Secure coding guidelines serve a purpose, but only to a certain extent. Developers need to understand different attack scenarios and how to write code to avoid those attacks.

A misuse case is a use case from the point of view of an actor hostile to the system. Just like use cases, which concentrate on what the system should do, misuse cases concentrate on what the system should not do. Its purpose is to capture the security requirements of the system. It is helpful in identifying the following:

• The type of hostile agents
• Threats to the system
• Mitigating steps pertaining to those threats
• Conflicts in design based on the security requirements

Software security is a process that is tied to all the phases of SDLC, and misuse cases provide a mechanism to achieve that. It is created by architects in the requirements gathering/design phase by identifying the attacks to a use case and capturing the mitigating steps to those attacks in the misuse case document. It is used by developers in the development phase to write code that is not susceptible to the type of attacks identified in the misuse case. It is also used by testers in the testing phase to test against those attacks identified in the misuse case.

Here's a sample misuse case for the "Forgot Password" use case. Please note that this misuse case focuses mainly on how a misuse case should look like and should not be used as is. Architects should modify this misuse case based on their system design.

Name: Attack on "forgot password" functionality
Summary: A malicious user tries to attack the "forgot password" functionality in order to gain access to the Web application or guess a valid e-mail address
Author: Anurag Agarwal
Date: April 15, 2006

Possible Attacks:

1. SQL injection attack
2. Brute force attack to guess a valid user
3. Sniffing attack on e-mail sent with password on an insecure transmission channel

Trigger Point: Can happen anytime

Preconditions: None

Assumptions:

1. The attacker can perform this attack remotely over the Internet
2. The attacker can be an anonymous user

Worst case threat (post condition) :

1. Attacker gains entry into the company database and steals sensitive information
2. Attacker is able to modify an existing e-mail address to its own e-mail address and mails the password to himself to gain unauthorized entry into the system

Related business rule: The system should e-mail the password to a valid e-mail address entered

Capture guarantee (post condition) :

1. Attacker cannot gain access to the database to steal or modify information
2. Attacker cannot identify the e-mail address of a valid user
3. Attacker cannot view the password sent in an e-mail to an e-mail address of a valid user

Note: Please do not mention "Hacker cannot compromise the system." This is too broad a criterion. You need to be specific.

Potential misuser profile:

1. Script kiddie
2. Skilled attacker

Threat level: High

Mitigation steps:

1. SQL injection attack
   • List all the mitigation steps to avoid a SQL injection attack. (For details, please read my article, "SQL injection: Developers fight back.")
   • Brute force attack
     • Accept first name, last name along with e-mail address
     • Have proper error handling so as not to reveal information to the attacker
     • Delay 3 to 5 seconds before re-entering the e-mail address
     • Lock out page for that IP address after 10 attempts

   • Sniffing attack
     • Send password e-mail on a secure transmission channel with strong encryption

Misuse cases address security throughout the development life cycle and help architects identify possible threats, as well as list mitigation steps that are later used by developers to make sure they are following more then just secure coding guidelines. Testers use them to create test cases to make sure the mitigation steps are implemented properly. Penetration testers can also use them.

As you can see, misuse cases present a valuable tool for security engineering and should be considered as a part of SDLC. After all, every step, however small, is a step forward in securing your application.

-------------------------------
About the author: Anurag Agarwal, CISSP, works for a leading software solutions provider where he addresses different aspects of application security. You may e-mail him at anurag.agarwal@yahoo.com.