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.
Adam Shostack here. I recently posted an article on my non-MS blog talking about some of the thinking which went into our threat modeling re-design. (It made sense as part of a series of posts there.) I wanted to tie the ideas in it to the SDL a little more strongly. The SDL is all about bringing together two sets of people who haven’t talked very much. Those communities are software developers and security engineers. Their failure to talk has hurt both communities.
Communities naturally evolve shorthand and jargon as they communicate. Within a given community, this works. When we talk about "think like an attacker" within a community of security practice, it works well. When we tell developers to do that, they look like a deer in the headlights. (Sorry, couldn't resist.)
If we think about communities that are defined by practices (in contrast to say, geographic communities), then we can look at how they communicate both within and across communities. Some people who study how communities interact have a concept of a boundary object. A boundary object is something both communities can point to facilitate communication. You might think that simple things, like books, would be uniquely identifiable in one way in all contexts. In fact, each book has several unique identifiers, and some, like title, that may or may not be unique. Books have ISBNs in large part to track payments. They also have Library of Congress catalog numbers. 0321502787, HD30.2.S563 and "The New School of Information Security" all refer to the same book in different contexts. So when referring to a book that they want to buy, a library might look to the ISBN, and then look at the Library of Congress number to shelve it.
In computer security, “Proof of Concept” code is a useful way to get developers and security researchers to talk about the same thing, and in working between the communities, acts as a boundary object.
In STRIDE/Element threat modeling, there are two accidental boundary objects. (I learned about the theory after developing the approach.) They are data flow diagrams (DFDs) and bugs.
The DFD acts as a boundary object because it's simple. It takes about 30 seconds to learn (except for trust boundaries). It looks a lot like most whiteboard diagrams. Developers can draw the diagram, and security experts can analyze it.
The second boundary object is the bug database. Everyone in software development understands bug databases. And though the practices which surround them differ pretty markedly, almost no one would ship a product without reviewing their bugs, which is why security people like putting the output of a threat modeling session into the database.
There are other possible boundaries, such as the interface between the business and the software. This is where assets come into some threat modeling approaches.
So what's the takeaway here? If you're watching groups of people frustratedly talk past each other — or wishing they'd bother to get in a room and try to communicate — look to see if you can find boundary objects which they can use to help organize conversation.
(This blog post draws on an academic practice called ethnomethodology. If you’d like to learn more, the Wikipedia article is currently a reasonable introduction.)
Have you used boundary objects to help security communicate with other communities?
Steve Lipner here.
Last fall, I spent a half-day discussing the SDL with Gary McGraw and Sammy Migues of Cigital, and Brian Chess of Fortify. The three of them were on a whirlwind tour of software security teams across the IT industry with the objective of building an industry picture of best practices in secure development. In our meeting, we went through details of what we do and don’t require as part of the SDL, and why we’ve made the decisions we have. We went into a fair degree of depth and, because these are really good security folks, the meeting was a lot of fun.
The payoff from Gary’s, Sammy’s, and Brian’s work is the Building Security In Maturity Model (BSIMM) that was released to the web late last week. The model enumerates best practices in building software that’s resistant to attack, as applied by nine real-world software development organizations.
I’ve historically not been a fan of “maturity models” because many of them are so abstract and paper-oriented that you can rate “high” on the maturity model and still fail at whatever attribute of your products and processes (quality, timeliness, security) the model purports to measure. In contrast, I like the BSIMM because
· It’s specific. The measures in the BSIMM are things that an development organization actually does to produce secure software.
· It’s real-world. Gary, Sammy, and Brian made a rule that no activity would be included in the BSIMM unless at least one of the organizations they interviewed actually performed that activity.
On reviewing the BSIMM as finally released, I was also gratified to see that Microsoft fares extremely well as measured against the BSIMM – we conduct virtually all of the activities defined by the BSIMM. Approximately three quarters of the BSIMM activities are covered by the SDL, and most of the rest are covered by other internal Microsoft security and privacy policies that are not parts of a software vendor’s development process.
One question we’ve discussed in reviewing the BSIMM is how it relates to the SDL Optimization Model. We think of it this way: the BSIMM tells you that the SDL is an industry-leading process for developing secure software. The Optimization Model provides your organization with specific guidance on getting started in secure development – telling you how to make progress in improving your organization’s development practices and getting to a point of high maturity as measured by the BSIMM.
Adam Shostack here. Forrester Research just released a report on threat modeling and the SDL. We're really excited to see this report affirming a critical component of the SDL, our approach to threat modeling and supporting tools. Forrester characterizes the Threat Modeling Tool as a unique tool that allows developers to identify and mitigate security risks to make applications more secure from the onset. Their recommendation to security and application development professionals is clear: catch vulnerabilities early in the development stage by implementing Microsoft's SDL Threat Modeling Tool. If you're already a Forrester customer, you should go check out the report and whether you're a current Forrester customer or not, you should download and evaluate the threat modeling tool.
Hi all – Dave here…
This past month marked the five year anniversary of the implementation of the SDL here at Microsoft. To mark that occasion, we had a recent series of posts from security veterans from those days as well as a couple of SDL War Story videos, featuring two SDL blog regulars and security thought leaders - Michael Howard and Steve Lipner.
It’s been interesting (and kind of surreal) to look back at the early days and the hard lessons learned from the likes of Nimda and Code Red – but it’s also been encouraging to see how far we’ve come as a company.
One other side effect of these retrospective musings – is that it has made us all the more aware that there’s a ton of work left to do. Microsoft can share a lot with the developer community as a result from "learning the hard way." That’s where my team comes in.
This past year, we launched the SDL Pro Network, the SDL Optimization Model and the SDL Threat Modeling Tool. In the months to come, we plan to publish refreshed SDL guidance; we’ll also have new tools and information that will assist with implementation of the Microsoft SDL within an organization.
So, while it’s great to look back and realize how far we’ve come, we’re acutely focused on where we need to go.
As always, we welcome your comments...
Hi everyone, Bryan here. RSA Conference is hosting a series of “encore” webcasts of popular presentations from past years, and I’m happy to announce that my 2008 session on Ajax Security (originally presented with Billy Hoffman of HP) was chosen for the series. I’ll be presenting an updated version of the original session via Live Meeting next Wednesday, March 11 at 1:00 PM EST. If you’d like to attend, please register here.
From the session abstract: People talk in the abstract about Ajax security issues like an “increased attack surface” or “code transparency issues.” But how secure is your average Ajax application? In this session, a sample Ajax application will be built using design patterns, advice, and code samples from respected resources in the Ajax community; then the glaring security defects will be exposed.