Dr. No and Risk Management

Adam Shostack here… 

Not too long ago, I was talking to a friend at a large company (not Microsoft).  My friend has  been in security a long time.  He’s frustrated that he’s nicknamed Dr. No, because his co-workers expect him to say no to everything.  He’s risk averse, convinced that all security failures, viruses or a breach will be attributed to him, and cause his career to dead-end.

What he doesn’t see is that his career is dead already.  It’s not there because of a security flaw, but because of an all-too-common failing among security professionals.   He’s not managing risk in the way his execs want him to manage risk.  He’s not evaluating the benefits of a program, he just focuses on the downside.  He’s not trying to make tradeoffs.

In the SDL, we help people and teams make more informed decisions on the trade-offs and balances associated with security decisions.  There are some risks that we say are unacceptable because of their impact on customers.  On behalf of those customers, we tell teams that they can’t ship software unless they’ve taken certain steps to reduce that risk, and that there are classes of issues that they must resolve before they ship (roughly, anything that would result in an MSRC bulletin).

Knowing up front what’s allowed and not allowed, teams can build it into their schedules.  We keep the SDL on a twice-yearly change schedule, giving teams a chance to integrate the SDL recommendations and requirements into their planning.  (We’ve reserved the right to issue emergency changes.)

By setting a clear and prescriptive bar for how to control risks, we’ve made the SDL a lot more acceptable than if we simply played Dr. No when projects are trying to get out the door.

This is an example of what John Boyd called an ‘orientation.’ It’s the result of our heritage, cultural traditions, training, and previous experiences.  Orientation influences what we notice and how we act.  If you’re oriented around blocking and risk avoidance, rather than ensuring that your concerns are discussed at the table, you might end up avoided, rather than having a conversation.

We try to orient the SDL around what our customers want, both explicitly and implicitly.

It’s a risk we’re cognizant of as we evolve the SDL.