Adam here again. I wanted to expand on that last post a little. One of the core elements of the SDL is to bring together security experts and developers.
To get those communities to mix, we need to look for all the insights we can find about what works.
There is tremendous power in bringing together communities and their ways of thinking. The reason I mentioned “ethnomethodology” is partially because it’s shiny and new (for me), but far more to share the place from which I’m drawing lessons. I’m hopeful that some of you will dig in, draw your own lessons, and experimentally apply them in new places.
It occurs to me that when people ask us for help in selling the SDL to management, they’re really trying to draw a third community into conversation.
Microsoft has been fortunate—we have highly technical executives and customers who regularly express their desire for us to continue investing in security.
And we have leaders who have been part of Microsoft for a long time, who have credibility built over long working relationships.
ROI, cost benefit and best practices are all attempts to speak in ways that executives will get. It’s really tempting to say “executives need to learn to understand security.” There are a dozen other departments forlornly looking for love and understanding and budget. Security needs to learn to speak executive, because security needs more from executives than execs need from a bunch of geeks talking about “phishing” and “cross site scripting” and “heap spraying.”
There’s also a move for security metrics in development and in operations which is built around the idea that numbers and measurements will give executives something they can focus on and they already have tools for.
While numbers aren’t a bad boundary object, the secrecy imperative often holds us (as an industry) back from gathering and analyzing data well.
There’s some progress, but we’re not sharing enough with each other about how we effectively communicate with ‘suits.’ There are other boundary objects we might look at. For example, there’s the case study, made famous at business schools. There are comparatives. (“The top 50 software firms all have a career ladder for testers..why don’t we?”) There are industry analyst reports, which frame things in a way executives are used to.
What are the ways that we can make that conversation work better? We’d love to hear your feedback on what’s worked for you.