While I realize that the reason DREAD has withstood the test of time is due to it's simplicity and clarity, I think that accuracy and a clear "you need to do something now" is essential.

By limiting the categories to three (High, Medium, Low) any software application that has more than 10 vulnerabilities will not allow adequate granularity for prioritization of severity due to the Pigeon Hole Principle. For example, in a test where 20 vulnerabilities are identified and 7 of them are high: yes all 7 should be fixed (and ideally soon), but what if there are 1 or 2 that are really really bad? Wouldn't you want to convey that immediacy? I sure would.

As the world becomes more dependent on IoT, our focus will include more and more public safety and health related applications. If a software vulnerability could lead to a loss of life, how can you not deem that "Critical?" For example, an authentication bypass vulnerability in a Bluetooth-enabled insulin pump may allow an attacker to read patient data. That alone, depending on the data it stores, can be a pretty high severity vulnerability. But if the same vulnerability allows the attacker to change the amount of insulin the pump delivers? Someone can get killed.

As for Reproducibility, I like the idea of removing it for simplicity sake but I've seen it be quite useful in the past. Although in web applications this is not a commonly useful factor, the IoT risk rears its head again. IoT devices are likely to be programmed in a compiled language, which means that timing and memory corruption issues are more common. Plus, the once problematic buffer overflow that .NET and JRE mitigate for web applications is back in play. BO’s can lead to immediate system ownage. An example of Reproducibility being relevant is the Drammer attack that exploits a memory hardware vulnerability in Android device that is dependent on the type of memory chip used. Therefore it may not be reproducible on two devices that are the same model and run the same OS version.

If you want more simplicity in DREAD but don't want to give up the Critical rating, consider removing a factor or two from Likelihood and Impact. I also think there's a case to leave Minimal out of the severity rating as I have only seen it used as an excuse to ignore issues and not fix vulnerabilities.

Software Threat Classification

Want to hear about the other side? Read DREAD 2.0: An Argument AGAINST Critical Ratings

Get a monthly digest of our blog posts