Call to action and resources (threat modeling for drivers)

  • Article

This article contains call to action recommendations and resources for threat modeling for drivers.

Call to action

For driver developers:

  • Consider making threat modeling part of driver design.
  • Take steps to efficiently Mitigate threats
  • Become familiar with the security and reliability issues that apply to your driver and device type. For more information, see the device-specific sections of the Windows Device Driver Kit (WDK).
  • Understand which checks the operating system, I/O manager, and any higher-level drivers perform before user requests reach your driver—and which checks they do not perform.
  • Use tools from the WDK to test and verify your driver.
  • Review public databases of known threats and software vulnerabilities

Mitigate threats

Determining how and where a driver might be attacked is not enough. You must then assess these potential threats, determine their relative priorities, and devise a mitigation strategy.

The DREAD approach

DREAD is an acronym that describes five criteria for assessing threats to software. DREAD stands for:

  • Damage
  • Reproducibility
  • Exploitability
  • Affected users
  • Discoverability

To prioritize the threats to your driver, rank each threat from 1 to 10 on all 5 of the DREAD assessment criteria, and then add the scores and divide by 5 (the number of criteria). The result is a numeric score between 1 and 10 for each threat. High scores indicate serious threats.

  • Damage. Assessing the damage that could result from a security attack is obviously a critical part of threat modeling. Damage can include data loss, hardware or media failure, substandard performance, or any similar measure that applies to your device and its operating environment.

  • Reproducibility is a measure of how often a specified type of attack will succeed. An easily reproducible threat is more likely to be exploited than a vulnerability that occurs rarely or unpredictable. For example, threats to features that are installed by default, or are used in every potential code path, are highly reproducible.

  • Exploitability assesses the effort and expertise that are required to mount an attack. A threat that can be attacked by a relatively inexperienced college student is highly exploitable. An attack that requires highly skilled personnel and is expensive to carry out is less exploitable.

    In assessing exploitability, consider also the number of potential attackers. A threat that can be exploited by any remote, anonymous user is more exploitable than one that requires an onsite, highly authorized user.

  • Affected Users. The number of users that could be affected by an attack is another important factor in assessing a threat. An attack that could affect at most one or two users would rate relatively low on this measure. Conversely, a denial-of-service attack that crashes a network server could affect thousands of users and therefore would rate much higher.

  • Discoverability is the likelihood that a threat will be exploited. Discoverability is difficult to estimate accurately. The safest approach is to assume that any vulnerability will eventually be taken advantage of and, consequently, to rely on the other measures to establish the relative ranking of the threat.

Sample: Assessing Threats

Continuing with the example discussed in Create threat models for drivers, the following table shows how a designer might assess the hypothetical denial-of-service attack:

DREAD Criterion Score Comments
Damage 8 Disrupts work temporarily, but causes no permanent damage or data loss.
Reproducibility 10 Causes the device to fail every time.
Exploitability 7 Requires a focused effort to determine the command sequence.
Affected users 10 Affects every model of this device on the market.
Discoverability 10 Assumes that every potential threat will be discovered.
Total: 9.0 Mitigating this problem is high priority.

 

If possible, your driver design should mitigate against all the threats that your model exposes. However, in some cases, mitigation might not be practical. For example, consider an attack that potentially affects very few users and is unlikely to result in loss of data or system usability. If mitigating such a threat requires several months of additional effort, you might reasonably choose to spend additional time testing the driver instead. Nevertheless, remember that eventually a malicious user is likely to find the vulnerability and mount an attack, and then the driver will require a patch for the problem.

Resources

Books

Writing Secure Code, Second Edition by Michael Howard and David LeBlanc

24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them, First Edition by Michael Howard, David LeBlanc and John Viega

The art of software security assessment : identifying and preventing software vulnerabilities, by Mark Dowd, John McDonald and Justin Schuh

Microsoft Hardware and Driver Developer Information

Common Driver Reliability Problems white paper

Cancel Logic in Windows Drivers white paper

Windows security model: what every driver writer needs to know

Microsoft Windows Driver Development Kit (DDK)

See Driver Programming Techniques in Kernel-Mode Driver Architecture

Test Tools

See Windows Hardware Lab Kit in Test for performance and compatibility

Review public databases of known threats and software vulnerabilities

To expand your knowledge of software threats, review the available public databases of known threats and software vulnerabilities.

 

 

Send comments about this topic to Microsoft