From time to time, a technically astute person challenges me around some area of secure design. Not too long ago, a distinguished engineer opined that “Threat modeling doesn’t do anything.” A CTO asked why there was any need for security architects, arguing, “We pay for static analysis. That should fix our secure development problems.”
I’m not making these comments up. The people who made them are not clueless idiots, but rather, very bright individuals. These are worthy questions. If we, security architects (that is, those of us trying to create designs that embody and enact security principles), cannot articulate what it is that we do and why it’s important, then we’re literally “out of business”; harried execs aren’t going to pay for something whose value cannot be explained, let alone quantified.
The essential problem with security architecture is that success will result in resiliency, in longevity, in plasticity in the face of change (particularly, a changing threat landscape). These are hard things to measure, and they have a time element. It can take a rather long time to demonstrate effectiveness and realize the benefits of investment. It’s what my friend, Srikanth Narasimhan (one of Cisco’s Distinguished Engineers) terms, “the long tail of architecture.” There may be no Immediate results from secure design efforts.
Every once in while, we see a good example of the art in practice. Chrome’s recent release of “Site Isolation” provides an interesting example of the application of secure design. https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html
“Site Isolation is a large change to Chrome’s architecture that limits each renderer process to documents from a single site.” Charlie Reis, Google Security Blog, July 11, 2018, https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html. The highlight is mine.
The so-called “Spectre” technique, if you recall, is a new set of techniques that misuse speculative execution (the CPU pipeline that executes multiple potential branches of code in parallel) cache to bypass operating system and firmware restrictions. Spectre has been used by real-world attackers. Operating system and CPU vendors have been scrambling to close these avenues since January 2018. At the same time, security researchers have been finding ever more ingenious methods to expand upon the techniques. Meltdown and Spectre continue to be important security issues1.
I’m not going to dig into the technical details of site isolation here. Instead, let’s focus on the secure design improvement to Chrome.
Of course, Chrome Site Isolation is ultimately coded, which means that it may suffer from any of the security horrors that code might contain. That is, what are commonly called, “vulnerabilities.” Presumably, the Chrome team did their best to find and fix any secure coding errors (on a side note, I spent some time studying Chrome’s secure development processes and commitment to security in a past role, and I’ve no doubt that if they’ve followed their stated processes, they’ve done their utmost to write secure code and to test it well).
Secure coding aside, the Chrome team faces a significant problem: It is demonstrable that JavaScript (and potentially other web-loaded, client-side browser code) can be used to exploit Spectre2. Spectre protection cannot rely solely on coding. Because Spectre does not exploit a coding error, it cannot be “fixed” in code. Hence, in response to that CTO I quoted earlier, static analysis cannot solve this problem. Protection against Spectre in a browser must be designed. That is precisely my point.
All the vulnerability scanning tools in the world will not provide a mitigation nor fix Spectre browser exploitation. It has to be designed. That is the art of security architecture.
The threat model for attacking Chrome via Spectre exploitation is mercifully simple, in that we know the attack and its method; we have example code against which to test3.
In order to conceive of Site Isolation, its designers had to understand Spectre thoroughly, especially JavaScript/client-side code exploitation. Then, they had to weigh that knowledge against potential defenses that would be possible to build. At some point, they chose Site Isolation as the best solution from the pool of potentials, and from that point, they had to build and test Site Isolation.
Site Isolation at a very high level, confines communications and data from each website to a strictly controlled sandbox process dedicated to that site. You can read more here.
We won’t know the effectiveness of Site Isolation until it faces attacks. How long a real-world challenge will take to emerge depends upon a number of factors: adoption amongst Chrome users, metrics on defended attacks, perceived value of exploitation by real-world attackers, etc.
In the meantime, I suspect that the security research community will examine Site Isolation in great detail against its promised protection. That examination, in and of itself, must be part of a robust secure design process: independent review and the resulting dialog around the design, as threat modeling author, Adam Shostack, so wisely opines, (my response).
In any event, as events unfold for Site Isolation, we can immediately note that this is a potential success for security architecture and secure design practices. I doff my hat to the prudent Chrome folks who’ve tried to defend against Spectre directly, thus, protecting us all and perhaps offering a ray of hope (and codable technique!) to other browser makers.