Where to seek for vulnerability?
The main concentration in threat modeling is inputs and data flow in the system. A code auditor should identify all the inputs and the paths originating from them. Sometimes a vulnerable method cannot be reached by the normal path the developer assumed but through an interface or an indirect input which developer thought the attacker does not have access. While identifying paths never overlook paths that originate from an error or an exception. Sometimes causing an exception or an error is all an attack about.
In addition to the inputs, pay attention to the algorithms and the logic behind them. Remember, the difference between you and a source code analyzer is in this area. Sometimes a vulnerability is logical and there is no way to identify it except understanding the algorithm and reasoning about it. The vulnerability could be because of a wrong order of If-Else structures or a problem to the data structure. By reasoning you may find a series of actions that may lead to a successful attack or sometimes you may find a data structure condition which causes the worst case performance of the algorithm. A good example of such attack is the DOS attack against SNORT.
While you perform a code auditing always consider the AAA principal. See if the access management – if any – of the application is reliable. If data is communicated through a channel, check for the confidentiality and integrity of the data which normally is achieved through some means of encryption.
All of this data may seem overwhelming and the first question that pops in your mind is where should I start? Is there some sort of security assessment methodology or security assessment process that I can rely on? Fortunately there is one. The software security assessment plan that security experts use is threat modeling.
By now you should have got an overview of code auditing process. Plunging in code and see what happens is the philosophy of many developers but I believe without a plan it is not wise to start your work in any areas of computer science and code auditing is not an exception. There are rare professionals that do not need a security assessment methodology for their work. Some professionals have even their own security assessment methodologies. Whatsoever I suggest you follow a standard security assessment process before you get that professional to develop yours. In this article I am going to introduce Threat Modeling which is a methodology that helps you plan your work and prepare yourself for the code auditing process.
Threat Modeling has 5 steps:
- Information collection
- Application architecture modeling
- Threat identification
- Documentation of findings
- Prioritizing the implementation review
I explain each step in the following sections. There is a tool which can assist you in threat modeling but it is more concentrated on DFD and does not support all forms of data and documents we mention for threat modeling. If you’re more comfortable learning the concept by getting your hands dirty, start create your first threat model using Microsoft Threat Modeling software
Information collection is the first step, you should try to get as much as information you can. This information can come from a number of sources: documents, developers, codes and finally the application itself. To get the info from the the running version of the application, last tools from sysinternals can be very helpful. What you should try to get is pretty much everything that can help you in your final code review (refer to my vulnerability analysis and buffer overflow example articles) but as a rule of thumb have in mind that this info is going to help you to identify the threats and prioritize your works.
Which module or file has priority for the vulnerability analysis?
If you haven’t read my article about the principals in software design go now and have a look at it because it can give you a perspective to the software design principals needed for this article. A component’s weak design normally can be easily spotted by an interview with the developers, checking the changelogs and finding discrepancy between codes and the design documents. If you have access to the developers ask them:
Where were concentrated their works?
Where do they have the greatest number of bugs?
Where have they felt that the design is either not detailed enough or need some changes?
The answer to these questions can help you identify modules with greatest number of bugs. As vulnerabilities are some sort of bugs, the chances are more to find vulnerabilities there.
If you do not have access to the developers check the changelogs; wherever the changelogs are more, the chances to find vulnerability are more too.
If you have access to the design docs, look for any discrepancy in documentation and the implementation. This discrepancy suggest a weakness in design and following that a probable vulnerability.
This info is the input for the next step so notice that you want to use this info to model the application and its architecture.
Application architecture modeling
Every UML diagram that can help you better understand the application and find the threats can be helpful. Data flow diagram (DFD) is one the UML diagrams that can be extremely helpful for Threat Identification since it can visually show you inputs, flow of data, access levels and the algorithm which are pretty much what we want for threat identification. There are five elements you usually see in a DFD: Processes, Data stores, External Entity, Data flow and Trust Boundary. Below is the figure 2-5 taken from “The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities” book.
Figure 1 - Architecture modeling of an application by DFD for threat modeling
In this step you have all the data you need to begin spotting the threats. Normally the result of this step is attack trees. Below is the figure 2-8 from the referenced book.
Figure 2 - Threat modeling /threat identification, attack tree
Documentation of findings
After you analyzed the application and you identified the threats you should document your findings in a proper format. Normally a result document of your work should contain threats with such details for each threat:
Threat: Name of the attack and vulnerability
Affected component: the component of the application which is vulnerable
Description: an explanation of the attack
Result: result of the attack in case of success exploitation.
Mitigation Strategies: A solution or remedy to debug the software
Risk: Normally the DREAD model is used to give a score (on a 1 to 10 scale) to the threat.
Prioritizing the implementation review
The final step of threat modeling is using the detailed summary from the last step to calculate the score for each component and prioritize your work based on the score and the cost to remove a threat.
After you build your threat model you can start the vulnerability analysis phase.