Documentation and Analysis

After the hard work is over, you need to document your findings. This phase is essentially the same as the final phase of the threat model from Chapter 2, and you can use the same basic documentation process. Table 4-2 is an example of the findings from Chapter 2 updated with the vulnerability's implementation details.

Table 4-2. Finding Summary

Threat	Brute-force login
Affected component	Human resources management login component
Module details	login.php (lines 4963)
Vulnerability class	Authentication bypass
Description	Different errors are returned for invalid usernames and passwords, making usernames easier to identify. This error makes a successful brute-force attack much more likely against users with weak or easily guessed passwords.
Result	Untrusted clients can gain access to user accounts and, therefore, read or modify sensitive information.
Prerequisites	The application is located on the corporate intranet, limiting its exposure.
Business impact	A malicious third party can access a user's personal data, which could be a violation of federal privacy regulations.
Proposed remediation	Make error messages ambiguous so an attacker doesn't know whether the username or password is invalid. Lock the user account after repeated failed login attempts. (Three or five attempts would be appropriate.)
Risk	Damage potential: 6 Reproducibility: 8 Exploitability: 4 Affected users: 5 Discoverability: 8 Overall: 6.2

This sample is certainly functional; however, it's not the only approach. Your level of detail can vary depending on your reasons for the audit and who the report is for. The following list is considered useful information to support a security finding:

• Location of the vulnerability This information (in Table 4-2's Module details row) should be fairly specific. You should usually include the filename, function name, and line number in the code. Sometimes a vulnerability spans many lines of code (and possibly several functions); in this case, you could omit a line number or give a range of line numbers. Also, you might choose to have one finding that represents a pervasive vulnerability, in which case this information would contain a large list of locations or refer to an external list generated by a tool or search.

• Vulnerability class A classification of sorts about the nature of the bug, whether it's buffer overflow, integer overflow, unchecked copy, dangerous API use, or one of the other vulnerability classes discussed in this book.

• Vulnerability description This summary of the vulnerability should describe why the code you're drawing attention to isn't secure. In some cases (such as a generic buffer overflow), you need to write very little, but more complex or unique vulnerabilities might require expanding the description to include more specifics.

• Prerequisites This is a list of prerequisite conditions that need to be true for the vulnerability to be triggered. The list might include configuration options or technical factors that need to exist before the vulnerability is a problem.

• Business impact Most reviews need to put technical risks in the context of business risks. Specifying the business impact can be tricky, as it changes depending on who's expected to deploy the application and how it will be used. However, business factors are what motivate the review, so your findings need to address these concerns.

• Remediation It is possible that this information might not be required in some cases, or it might only be a simple line or two explaining how the developers might want to fix the vulnerability. When working closely with a development team, however, the remediation section might be quite detailed and provide several options for addressing the vulnerability.

• Risk This rating is the risk determined from the vulnerability's severity combined with the probability of exploit. The DREAD rating system from Chapter 2 encapsulates this information as the overall risk rating.

• Severity This information is the amount of damage that can be incurred if the vulnerability is exploited successfully. The DREAD rating system from Chapter 2 encapsulates severity in the damage potential and affected users risk factors.

• Probability This information is the likelihood of the vulnerability being exploited successfully. The DREAD rating system from Chapter 2 encapsulates probability in the reproducibility, discoverability, and exploitability risk factors.

Generally, you need to include an overall summary of how the application measured up. Was it extremely secure, making exploitable bugs difficult to find? Or did it seem as though the developers weren't aware of security considerations? Assigning an overall "grade" can be subjective, so make sure you don't come across as judgmental or condescending. Instead, you should rely on your results to convey the application's quality, and try to express the trends you see and the potential for future problems. After you have some experience, the summary component will seem easier, as you should be able to get a feel for how securely an application is developed.