Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
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?
PingBack from http://blog.a-foton.ru/index.php/2009/03/19/why-the-new-sdl-threat-modeling-approach-works/
Adam here again.   I wanted to expand on that last post a little.  One of the core elements