Boundary Objects and Threat Modeling
Ethonomethodologists talk a lot about communities of practice. Groups of people who share some set of work that they do similarly, and where they’ll co-evolve ways of working and communicating.
When everyone is part of a given community, this works really well. 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.)
One of the tools which different communities of practice can use to communicate is a boundary object. Boundary objects include things like ISBNs. Books have ISBNs in large part to track payments. They differ from 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.
In STRIDE/Element threat modeling [link to http://msdn.microsoft.com/msdnmag/issues/06/11/ThreatModeling/default.aspx no longer works], there are two accidental boundary objects. (I learned about the theory after developing the approach.) They are data flow diagrams (DFDs) and bugs. The picture is a DFD, showing the process of threat modeling, along with boundaries. The boundaries are doing double duty as trust boundaries, and bi-secting the boundary objects.
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 be that communicative — look to see if you can find boundary objects which they can use to help organize conversation.
Dear Adam,
Since I know of no other way to contact you, I am taking the liberty of using this vehicle to write to you to urge you to make a very strong statement correcting the way that people are mis-stating your blog about the cost of breaches presented in the Maine breach report.
Nowhere in that post can I find the $450 per record cost that I have seen several times in the computer press, or that I just heard during a podcast dated 1/27/2009, called “The Network Security Podcast, Episode 136” from Rich Mogull and Martin McKeay.
Here is the quote from your blog:
“It also includes (pdf 24, printed 18) an interesting cost summary, with 243,000 accounts impacted by Hannaford having an estimated cost of $1.6MM, or about $6.50 per customer. The highest cost per person/card/account is the TJX incident at roughly $9 per card. Which is a stark contrast to the generally used $187 number from Ponnemon surveys.”
I have just assumed that someone missed a decimal point somewhere – please correct me if I am wrong.
Kind regards,
Patrick Florer
You might also want to look for work on boundary objects by Prof Reinhard Riedl of the Berner Fachhochschule.
Robin, do you have a pointer? I found this page, http://e-government.bfh.ch/index.php?id=1172&no_cache=1&tx_bfhpersonalpages_p=rer2&tx_bfhpersonalpages_screen=publications&cHash=9c801397b2 and was then stymied