Sometimes when I present about secure programming practices, I emphasize education for PM's, testers, and devs, for obvious reasons. Then there's the hard part – educating management. You really have to be able to do that – you need to spend time on security and management needs to understand the value added, or they won't prioritize correctly. In Office, we've actually had security training for mid and upper management so they understand the issues.
Someone wrote in saying that DREAD and STRIDE didn't help much in terms of communicating with the pointy-haired boss (PHB). This is true, and if you're bothering management with details at this level, something's not right, though diving deep into the details can be a useful technique for making the boss' eyes roll back in their head and go away (hi Chris!) when they're bugging you and you want to be working. Here in Office, that doesn't work – all my management can follow me into as much detail as I want to go, unless I start going on about ACLs and tokens.
The point the reader made was that management wants to understand things in terms of risk. To be able to put a risk on things, we have to look at a broader perspective:
Risk = f(vulnerability, threat, value) – risk of fix
Is there an active threat that can exploit the vulnerability? What value will the attacker gain if the vulnerability is exploited? When shipping commercial software with a lot of different users, we can't judge that very well, but if it is custom software, you do have that information, and have to include this in making your call. Something else to factor into value is that the value of the loss to you may be very different than the value of the gain to the attacker, much the same way as having your convertible top ripped open and your dashboard mangled so the stereo can be stolen could cost $2500 to fix, but gains the attacker $50. Having your web site defaced causes a lot more damage to brand than gain to the attacker. There is also some risk to making the fix – you might take down the web site or something – I hate it when that happens.
So DREAD and STRIDE are meant to facilitate a technical discussion, and the results of that discussion need to be presented to management, not some score that takes an hour to explain. In the context of a specific piece of software, DREAD is a reasonable start at figuring out the vulnerability component, but doesn't include the other 2 components at all. I wouldn't try to put a score on it – this needs maybe a paragraph to explain to less technical people.