Why do we call them trust boundaries?
Why do we call them trust boundaries, anyway?
This blog post is more questions and musings than answers.
Back in September, there was a fascinating Propublica article, Microsoft Chose Profit Over Security. It includes a link to Microsoft Security Servicing Criteria for Windows, which uses the term “security boundary” where I’d normally say “trust boundary.” I’m somewhat certain that I inherited the phrase without giving it a lot of thought. But when I train, some people find the phrase mystifying.
So is there a meaningful difference where the terms “trust” and “security” differ? Part of an answer comes from Crispin Cowan, who writes:
“A security boundary is defined by Mark Russinovich as a special form of trust boundary that is “a wall through which code and data can’t pass without the authorization of a security policy” and “In practice, ‘security boundary’ for Microsoft has come to mean a trust boundary that Microsoft has robustly defended over a long period of time.”
I do not love the idea that a boundary only exists when a company commits to defending it, and that trust boundaries grow into committed security boundaries. I’d prefer to think that a company that defines a trust boundary ought to commit to it, and ought to publicly abandon it when it’s no good. (Microsoft, somewhat famously, abandoned UAC as a boundary before it even shipped, because Andrew Roths and others on the internal Secure Windows Initiative team demonstrated it was indefensible, but it still added value in getting apps away from running as Administrator.) Clearly, companies would prefer not to do that, which could focus attention on the question of “did we do a good job at defining and defending this boundary?”
Another part of an answer comes from Kim Wuyts who made the point that ’trust’ nicely encompasses privacy, while ‘security’ either ignores or excludes it. Trust also calls back to the concept of a ‘trusted computing base,’ the set of system functionality on which everything else depends. (“We trust that it works right.”)
Some digging into the history on my bookshelf:
- Howard and LeBlanc’s Writing Secure Code (2002) doesn’t mention trust boundaries, and the sample threat models shown don’t include any.
- The second edition of Writing Secure Code (2003) does mention trust boundaries (page 345), with a well-formed definition, and even a closed box example with shading to draw attention to the boundary and ‘chokepoint.’
- Swiderski and Snyder’s Threat Modeling (2004) has an extensive discussion of “trust levels.” (15 index sub-entries), and the main discussion discusses the idea of boundaries, but without the word boundary. There is extensive use of a ‘walls of a building’ metaphor, and “privilege boundaries.” (“Privilege boundaries, represented with a dashed line, separate two processing nodes.. that have different trust levels associated with them, or that perform actions requiring different trust levels.”
All that said, I’m interested in understanding if there are reasons for the word trust being in the phrase. Could we just talk about boundaries? What would we lose?
Update: Good discussions at Threat Modeling Connect, OWASP Slack, Linkedin.
Update 2, Nov 13 Google uses the term “full security boundary” as they discuss V8 Sandbox Rewards.