Security, privacy, economics and unrelated topics since 2005
Emergynt has created the Emergynt Risk Deck, a set of 51 cards, representing actors, vulnerabilities, targets, consequences and risks. It’s more a discussion tool than a game, but I have a weakness for the word “emergent,” and I’ve added it to my list of security games
Also, Lancaster University has created an Agile Security Game.
Oddly, I am unable to find this on Etsy. Perhaps the Disney Corporation, new owners of Star Wars, doesn’t like mousetraps?
So this week’s threat model Thursday is simply two requests:
“Attacks always get better, and that means your threat modeling needs to evolve. This talk looks at what’s new and important in threat modeling, organizes it into a simple conceptual framework, and makes it actionable. This includes new properties of systems being attacked, new attack techniques (like biometrics confused by LEDs) and a growing importance of threats to and/or through social media platforms and features. Take home ways to ensure your security engineering and threat modeling practices are up-to-date.”
[Update: clarified a sentence about whose privacy is touched, and where.]
I had missed the story “Big Brother on wheels: Why your car company may know more about you than your spouse.” There are surprising details, including that you might be able to shut it off, and the phrase “If a customer declines, we do not collect any data from the vehicle.” I do wonder how a customer can decline — does it involve not buying a GM car?
When we did a privacy threat model at the Seattle Privacy Coalition, we found these issues. We also were surprised that the defense, taking a car driven by someone else (a taxi, or a Lyft/Uber) makes such a big difference, leaving the owner of the car associated with the trip via license plate, toll beacons, tire pressure monitors, traffic sensors, maps, and other technologies with tracking implications. And the passenger is associated if payment is by card, or the ride is booked via an app. splits/confuses the difference. It may also be that driving for Lyft/Uber acts as a defense, by classifying a car as a carshare, but it seems pretty easy to see through that to where the car is parked (especially overnight) and to repeated trips to dis-ambiguate between paid and personal rides.
Over at the Leviathan blog, Crispin Cowan writes about “The Calculus Of Threat Modeling.” Crispin and I have collaborated and worked together over the years, and our approaches are explicitly aligned around the four question frame.
One of the places where Crispin goes deeper is definitional. He’s very precise about what a security principal is:
A principal is any active entity in system with access privileges that are in any way distinct from some other component it talks to. Corollary: a principal is defined by its domain of access (the set of things it has access to). Domains of access can, and often do, overlap, but that they are different is what makes a security principal distinct.
This also leads to the definition of attack surface (where principals interact), trust boundaries (the sum of the attack surfaces) and security boundaries (trust boundaries for which the engineers will fight). These are more well-defined than I tend to have, and I think it’s a good set of definitions, or perhaps a good step forward in the discussion if you disagree.
His approach adds much more explicit description of principals who own elements of the diagram, and several self-check steps (“Ask again if we have all the connections..”) I think of these as part of “did we do a good job?” and it’s great to integrate such checks on an ongoing basis, rather than treating it as a step at the end.
Here Crispin has assessing complexity and mitigations. Assessing complexity is an interesting approach — a great many vulnerabilities appear on the most complex interfaces, and I think it’s a useful strategy, similar to ‘easy fixes first’ for a prioritization approach.
He also has “c. Be sure to take a picture of the white board after the team is done describing the system.” “d. Go home and create a threat model diagram.” These are interesting steps, and I think deserve some discussion as to form (I think this is part of ‘what are we working on?’) and function. To function, we already have “a threat model diagram,” and a record of it, in the picture of the whiteboard. I’m nitpicking here for two very specific reasons. First, the implication that what was done isn’t a threat model diagram isn’t accurate, and second, as the agile world likes to ask “why are you doing this work?”
I also want to ask, is there a reason to go from whiteboard to Visio? Also, as Crispin says, he’s not simply transcribing, he’s doing some fairly nuanced technical editing, “Collapse together any nodes that are actually executing as the same security principal.” That means you can’t hand off the work to a graphic designer, but you need an expensive security person to re-consider the whiteboard diagram. There are times that’s important. If the diagram will be shown widely across many meetings; if the diagram will go outside the organization, say, to regulators; if the engineering process is waterfall-like.
Crispin says that tools are substitutes for expertise, and that (a? the?) best practice is for a security expert and the engineers to talk. I agree, this is a good way to do it — I also like to train the engineers to do this without security experts each time.
And that brings me to the we/you distinction. Crispin conveys the four question frame in the second person (What are you doing, what did you do about it), and I try to use the first person plural (we; what are we doing). Saying ‘we’ focuses on collaboration, on dialogue, on exploration. Saying ‘you’ frames this as a review, a discussion, and who knows, possibly a fight. Both of us used that frame at a prior employer, and today when I consult, I use it because I’m really not part of the doing team.
That said, I think this was a super-interesting post for the definitions, and for showing the diagram evolution and the steps taken from a whiteboard to a completed, colored diagram.
The image is the frontspiece of Leviathan by Thomas Hobbes, with its famous model of the state, made up of the people.
Continuum has released a video of me and Stuart Winter-Tear in conversation at the Open Security Summit:
“At the recent Open Security Summit we had the great pleasure of interviewing Adam Shostack about his keynote presentation “A seat at the table” and the challenge of getting security involved in product and application design. We covered numerous topics from the benefits brought to business by threat modeling to pooping unicorns.”
The decision in Carpenter v. United States is an unusually positive one for privacy. The Supreme Court ruled that the government generally can’t access historical cell-site location records without a warrant. (SCOTUS Blog links to court documents. The court put limits on the “third party” doctrine, and it will be fascinating to see how those limits play out.
A few interesting links:
The most important sentence in Justice Gorsuch’s opinion appears at page 20: “Nor can I fault the Court today for its implicit but unmistakable conclusion that the rationale of Smith and Miller is wrong; indeed, I agree with that.” Justice Gorsuch is going to be on the Court for a very long time and he is signaling that in a properly presented case he will reject the third-party doctrine. That’s huge. What is less certain is whether his characterization of the majority opinion is apt.
As I said previously, I am thankful to the fine folks at the Knight First Amendment Institute at Columbia University for the opportunity to help with their technologists amicus brief in this case, and I’m glad to see that the third party doctrine is under stress. That doctrine has weakened the clear aims of the fourth amendment in protecting our daily lives against warrantless searches as our lives have involved storing more of our “papers” outside our homes.
Image via the mobile pc guys, who have advice about how to check your location history on Google, which is one of many places where it may be being captured. That advice might still be useful — it’s hard to tell if the UI has changed, since I had turned off those features.
For Threat Model Thursday, I want to use current events here in Seattle as a prism through which we can look at technology architecture review. If you want to take this as an excuse to civilly discuss the political side of this, please feel free.
Seattle has a housing and homelessness crisis. The cost of a house has risen nearly 25% above the 2007 market peak, and has roughly doubled in the 6 years since April 2012. Fundamentally, demand has outstripped supply and continues to do so. As a city, we need more supply, and that means evaluating the value of things that constrain supply. This commentary from the local Libertarian party lists some of them.
The rules on what permits are needed to build a residence, what housing is acceptable, or how many unrelated people can live together (no more than eight) are expressions of values and priorities. We prefer that the developers of housing not build housing rather than build housing that doesn’t comply with the city’s Office of Planning and Community Development 32 pages of neighborhood design guidelines. We prefer to bring developers back after a building is built if the siding is not the agreed color. This is a choice that expresses the values of the city. And because I’m not a housing policy expert, I can miss some of the nuances and see the effect of the policies overall.
Let’s transition from the housing crisis here in Seattle to the architecture crisis that we face in technology.
No, actually, I’m not quite there. The city killed micro-apartments, only to replace them with … artisanal micro-houses. Note the variation in size and shape of the two houses in the foreground. Now, I know very little about construction, but I’m reasonably confident that if you read the previous piece on micro-housing, many of the concerns regulators were trying to address apply to “True Hope Village,” construction pictured above. I want you, dear reader, to read the questions about how we deliver housing in Seattle, and treat them as a mirror into how your organization delivers software. Really, please, go read “How Seattle Killed Micro-Housing” and the “Neighborhood Design Guidelines” carefully. Not because you plan to build a house, but as a mirror of your own security design guidelines.
They may be no prettier.
In some companies, security is valued, but has no authority to force decisions. In others, there are mandatory policies and review boards. We in security have fought for these mandatory policies because without them, products ignored security. And similarly, we have housing rules because of unsafe, unsanitary or overcrowded housing. To reduce the blight of slums.
Security has design review boards which want to talk about the color of the siding a developer installed on the now live product. We have design regulation which kills apodments and tenement housing, and then glorifies tiny houses. From a distance, these rules make no sense. I didn’t find it sensible, myself. I remember a meeting with the Microsoft Crypto board. I went in with some very specific questions regarding parameters and algorithms. Should we use this hash algorithm or that one? The meeting took not five whole minutes to go off the rails with suggestions about non-cryptographic architecture. I remember shipping the SDL Threat Modeling Tool, going through the roughly five policy tracking tools we had at the time, discovering at the very last minute that we had extra rules that were not documented in the documents that I found at the start. It drives a product manager nuts!
Worse, rules expand. From the executive suite, if a group isn’t growing, maybe it can shrink? From a security perspective, the rapidly changing threat landscape justifies new rules. So there’s motivation to ship new guidelines that, in passing, spend a page explaining all the changes that are taking place. And then I see “Incorporate or acknowledge the best features of existing early to mid-century buildings in new development.” What does that mean? What are the best features of those buildings? How do I acknowledge them? I just want to ship my peer to peer blockchain features! And nothing in the design review guidelines is clearly objectionable. But taken as a whole, they create a complex and unpredictable, and thus expensive path to delivery.
We express values explicitly and implicitly. In Seattle, implicit expression of values has hobbled the market’s ability to address a basic human need. One of the reasons that embedding is effective is that the embedded gatekeepers can advise, interpret in relation to real questions. Embedding expresses the value of collaboration, of dialogue over review. Does your security team express that security is more important than product delivery? Perhaps it is. When Microsoft stood down product shipping for security pushes, it was an explicit statement. Making your values explicit and debating prioritization is important.
What side effects do your security rules have? What rule is most expensive to comply with? What initiatives have you killed, accidentally or intentionally?
Today’s Threat Model Thursday is a look at “Post-Spectre Threat Model Re-Think,” from a dozen or so folks at Google. As always, I’m looking at this from a perspective of what can we learn and to encourage dialogue around what makes for a good threat model.
From the title, I’d assume Chromium, but there’s a fascinating comment in the introduction that this is wider: “any software that both (a) runs (native or interpreted) code from more than one source; and (b) attempts to create a security boundary inside a single address space, is potentially affected.” This is important, and in fact, why I decided to hightlight the model. The intro also states, “we needed to re-think our threat model and defenses for Chrome renderer processes.” In the problem statement, they mention that there are other, out of scope variants such as “a renderer reading the browser’s memory.”
It would be helpful to me, and probably others, to diagram this, both for the Chrome case (the relationship between browser and renderer) and the broader case of that other software, because the modern web browser is a complex beast. As James Mickens says:
A modern Web page is a catastrophe. It’s like a scene from one of those apocalyptic medieval paintings that depicts what would happen if Galactus arrived: people are tumbling into fiery crevasses and lamenting various lamentable things and hanging from playground equipment that would not pass OSHA safety checks. This kind of stuff is exactly what you’ll see if you look at the HTML, CSS, and JavaScript in a modern Web page. Of course, no human can truly “look” at this content, because a Web page is now like V’Ger from the first “Star Trek” movie, a piece of technology that we once understood but can no longer fathom, a thrashing leviathan of code and markup written by people so untrustworthy that they’re not even third parties, they’re fifth parties
who weren’t even INVITED to the party…
There is a detailed set of ways that confidentiality breaks current boundaries. Most surprising to me is the claim that clock jitter is not as useful as we’d expect, and even enumerating all the clocks is tricky! (Webkit seems to have a different perspective, that reducing timer precision is meaningful.)
There is also an issue of when to pass autofilled data to a renderer, and a goal of “Ensure User Intent When Sending Data To A Renderer.” This is good, but usability may depend on normal people understanding that their renderer and browser are different. That’s mitigated by taking user gestures as evidence of intent. That seems like a decent balancing of usability and security, but as I watch people using devices, I see a lot of gesturing to explore and discover the rapidly changing meanings of gestures, both within applications and across different applications and passwords.
As a non-expert in browser design, I’m not going to attempt to restate the mitigations. Each of the defensive approaches is presented with clear discussion of its limitations and the current intent. This is both great to see, and hard to follow for those not deep in browser design. That form of writing is probably appropriate, because otherwise the meaning gets lost in verbosity that’s not useful to the people most impacted. I would like to see more out-linking as an aide to those trying to follow along.
I’m very glad to see Google sharing this because we can see inside the planning of the architects, the known limits, and the demands on the supply chain (changes to compilers to reduce gadgets, changes to platforms to increase inter-process isolation), and in the end, “we now assume any active code can read any data in the same address space. The plan going forward must be to keep sensitive cross-origin data out of address spaces that run untrustworthy code.” Again, that’s more than just browsers. If your defensive approaches, mitigations or similar sections are this clear, you’re doing a good job.
I have a new essay at Dark Reading, “‘EFAIL’ Is Why We Can’t Have Golden Keys.” It starts:
There’s a newly announced set of issues labeled the “EFAIL encryption flaw” that reduces the security of PGP and S/MIME emails. Some of the issues are about HTML email parsing, others are about the use of CBC encryption. All show how hard it is to engineer secure systems, especially when those systems are composed of many components that had disparate design goals.
