Be sure to classify and be careful with your fix!
When you conduct an application security assessment, whether it’s a static analysis scan, dynamic analysis scan, penetration test, or code review, you are going to be presented with a set of vulnerabilities to fix. Often times, there are more vulnerabilities to be fixed than time to fix them, so how do you determine which you should address?
The answer is a vulnerability classification and a prioritization framework. A classification framework should take into consideration key factors such as exploitability, likeliness of exploit, criticality, threats, risk of fixing. The risk of the vulnerability can be classified based on the type of data and application to which the vulnerability applies. The risk of fixing the vulnerability is harder to quantify and is often overlooked.
Once you have these in place, you will have good framework for classifying and responding to discovered vulnerabilities. Keep in mind that any bugs you fix, security or otherwise, have a chance of causing new bugs. For that reason you are always trading a known risk for an unknown and so you should consider a minimum threshold below which you are willing to live with a known problem. A known issue of low-impact is more desirable than a high-impact unknown bug.
There are three approaches that I use and that work well individually, and more effectively, collectively:
- DREAD
- Data Asset Classification
- Criticality Definitions
DREAD is part of a system for classifying security threats used at Microsoft, and that I co-created while serving as a security lead at Microsoft. It provides a risk rating of security threats using five categories.
- Damage - how bad would an attack be?
- Reproducibility - how easy it is to reproduce the attack?
- Exploitability - how much work is it to launch the attack?
- Affected users - how many people will be impacted?
- Discoverability - how easy it is to discover the threat?
Data Asset Classification is about understanding the sensitivity of the data that is exposed by your application and the level of protection that is required based on internal policies and compliance mandates.
Criticality definitions can be created from your development team, penetration test / vulnerability assessment group, or information security staff. This is particularly useful for enterprise IT organizations that understand how the application will be accessed and deployed. Below is a sample of what that might look like.
- Critical: Server or client side error that allows remote code execution from an anonymous user.
- High: Information disclosure that allows an attacker to read highly sensitive data.
- Medium: Local denial of service that allows an attacker to stop higher privileged users from using the service or application.
- Low: Information disclosure of implementation details that allows attacker to create or execute reverse engineering attacks.
A combination of DREAD, for impact analysis, Data Asset Classification to refine the analysis and then Criticality Definitions so that everyone agrees on the importance of different types of bugs will help you build a predictable and consistent response to vulnerabilities discovered during your audits and security assessments.
