Skip to content

Part 2: Writing Secure Software

Mitigating Threats to Your Software

Part 2:

In my last blog post, I discussed one possible process for developing secure software. We learned about potential security threats using the S.T.R.I.D.E. acronym, creating a threat model and identifying potential threats. Next, I’ll discuss prioritizing the potential threats you have identified and discuss ways to mitigate these threats.

Prioritizing Potential Threats

In my last blog post I used a simple system as an example to create a threat model and identify potential threats. Not all of the potential security threats that we brainstormed are necessarily worth our time and effort to address – but how do we know which ones are worth tackling? One method of analyzing potential threats uses another handy acronym: D.R.E.A.D.

  • Damage – If this threat is exploited, how much damage will occur?
  • Reproducibility – Is it easy to reproduce the exploit?
  • Exploitability – What is needed to exploit this threat?
  • Affected Users – How many users will be affected?
  • Discoverability – Is the threat easy to discover?

For each potential threat, you assign a score in each of these areas, then sum these scores for each threat. The threats with the highest scores become your highest priority risks to address. Let’s look at a few examples using a simple High (3), Medium (2) Low (1) scheme.

One of the potential threats we came up with last time was:

Data sent across the wire to the WCF Service could be visible to an attacker using a packet capture tool.

Let’s assess this threat in each of the D.R.E.A.D. categories.

CategoryNotesScore
DamageSensitive data such as user passwords could be compromised, leading to further compromises in securityHigh (3)
ReproducibilityThis threat is reproducible every time.High (3)
ExploitabilityPacket capture tools are freely downloadable.High (3)
Affected UsersAll.High (3)
DiscoverabilityWithout taking appropriate steps, this is easily discoverable.High (3)
Total15

A second potential threat we identified was:

A malicious user might do a memory dump of the client process, looking for sensitive information.

CategoryNotesScore
DamageThis depends on the nature of the client application, but let’s suppose that the user types in an authentication password which is stored in memory. An attacker could use that password to gain access to the system.Medium (2)
ReproducibilityThis threat is reproducible every time.High (3)
ExploitabilityGetting a memory dump for a process is fairly easy, but parsing through it to find sensitive information could be difficult.Low (1)
Affected UsersProbably only affects this one user whose password was stored in memoryLow (1)
DiscoverabilityWithout direct access to the client machine, or installing some malicious software, this would be difficult to exploit.Low (1)
Total8

A third potential threat was:

Data in the incoming request might attempt a SQL injection attack.

CategoryNotesScore
DamageIf exploited, SQL injection attacks can be very damaging.High (3)
ReproducibilityThis threat is reproducible every time.High (3)
ExploitabilitySuccessfully exploiting this threat probably requires a skilled programmer.Medium (2)
Affected UsersIf exploited, it could potentially affect all users.High (3)
DiscoverabilityGetting the syntax correct for a successful attack can be tricky.Medium (2)
Total13

As you evaluate your potential threats, you are likely to find a wide range of threats. Some will be able to inflict a great deal of damage, but require expert knowledge in some area in order to exploit. Others may be easy to discover, but only risk leaking trivial information. Using the principles behind the D.R.E.A.D. acronym can help you to identify the high risk threats that should be discussed in the next phase – security threat mitigation.

Written by Wayne Creasey.

Leave a Reply

Your email address will not be published. Required fields are marked *