Oil Change or Culture Change?

I have worked on security and privacy initiatives at Microsoft for a number of years, but it wasn’t until I came to the Security Engineering group to work on the Security Development Lifecycle that I realized I don’t actually work on security.  To be clear, I do many of the tasks that one might associate with security – look at bugs, evaluate tools, provide guidance and the like – but it’s more accurate to say that I (along with everyone else in Security Engineering and Communications) am in the culture change business.

At its heart, the SDL is a series of common sense processes and technologies woven into a lightweight, coherent framework that has produced real results for Microsoft. While it may pain some of my colleagues to read this, the SDL is not Unified Field Theory – much of what makes up the SDL has been in existence for years (although I would be remiss if I didn’t note that there is a big difference between a process that has been applied to millions of lines of production code and those that have not).  Furthermore, many of the processes used by SDL (and other methodologies) are generally acknowledged as effective in identifying and mitigating security threats.  Pondering this notion is what lead me to my realization about culture change, and prompted a question: If this stuff has been around for awhile in some shape or form, why aren’t more people doing it?

Being a naturally curious type, I wanted to learn more about this apparent discontinuity.  More often than not, when talking to our customers an interesting social phenomenon is presented – as I talk with technical employees (developers, project managers, testers and the like) the desire to implement secure development practices extends all the way up the technical food chain, including the CSO – then it stops…cold.

I haven’t done any empirical study of this behavior, nor do I plan to – however, in the process of conducting my informal probes for causality, more often than not I find that it hinges on two points:

1. lack of understanding at the CxO level about how security, privacy and reliability are contributors to corporate risk, and;
2. discomfort with the notion of redirecting resources to trustworthiness in the short term, in exchange for longer term gains in product quality and customer satisfaction.

Microsoft has two things going for it in this regard; strong executive support and the unfortunate experience gained by living through “tectonic” security events – which have snapped trustworthiness issues into razor-sharp focus and continue to provide motivation by the truckload.  This clarity of thought at the executive level has allowed us to create, implement, and refine the SDL – providing resources and support at critical junctures has proven to be absolutely vital in driving culture change at Microsoft. Have we won the culture war?  Absolutely not.  Microsoft is constantly evolving; people come and go and the lessons of the past must be taught to future generations. Bottom line: our executives understand that we are in this for the long haul and that by addressing trustworthiness on a continuing basis, we will see tangible gains in both product quality and customer satisfaction.

As one might expect, we get a lot of requests from customers asking for help in “selling the concept to their execs” – and that’s okay because as we have learned, executive support for trustworthiness can be cultivated.  It’s our intent to try to help illustrate the value of adopting secure development practices – watch this space over the next few months as we start to roll out some of this work.

A final note to help illustrate my point – for those of you that are old enough to remember, there was an old TV commercial for Fram Oil Filters that showed a mechanic working on the tear down of some old beater. At the end of the commercial, the mechanic turns to the camera and says, “You can pay me now, or you can pay me later…”

Seems to be oddly prophetic advice.

About the Author
Dave Ladd

Principal Security Group Program Manager

Join the conversation

  1. asteingruebl


    Great entry.  I’ve been thinking about this in my own job and how the vast majority of what I’m doing in building my own program in this area is affecting culture change.

    On the root causes of the problem I think I’ll throw in a third and its the general culture of software development vs. software engineering.  I wrote a little more about it on my blog:


  2. mattmurphy531

    Not only does security awareness stop "cold" at the exec level, it’s often like hitting a brick wall.  To say it stops doesn’t do justice to the problem, because when it *does* stop, it can completely derail an otherwise very effective process.  If your priority and the CEO’s priority conflict, your priority is functionally non-existent.

Comments are closed.