Via Chad Loder.
Via Chad Loder.
The response to my first Threat Model Thursday was almost uniformly positive. Thank you!
I’m going to continue with the series, and have a second one ready. But as I think about how to maximize the value of the series, I want to try something. I want you to read the threat model without me, and analyze it.
This week’s model is the ARM Network Camera TMSA. (It’s behind a regwall, but you can opt-out of marketing.)
As you read it, I want you to ask yourself two sets of questions. First, how does it align with the 4-question frame (“what are we working on,” “What can go wrong,” “what are we going to do about it,” and “did we do a good job?”) Second, ask yourself who, what, why, and how. (You can ask yourself when if you want to be complete about it.)
I’ll be back next week with my answers.
Eric Ries wrote the excellent book Lean Startup. In a recent interview with Firstround, he talks about how to integrate gatekeeping functions into a lean business.
There is a tremendous amount of wisdom in there, and almost all of it applies to security. The core is that the gatekeeper has compassion for the work and ambiguity of engineering, and that compassion comes from being embedded into the work.
Engineering involves starting with problem statements that are incomplete or inaccurate, and dialog about those problems leading to refinement of the understanding of both the problem and the solution. It’s hard to do that from a remote place in the organization.
This is an argument for what Ries calls embedding, which is appropriate for some gatekeeping functions. What’s more important for security is “a seat at the table.” They’re importantly different. Embedding is a matter of availability when a problem comes up where we need the voice of legal or finance. A seat at the table is that the person is invited to the meetings where the problems and solutions are being refined. That happens naturally when the person invited is a productive contributor. Many functions, from program management to test to usability have won a seat at the table, and sometimes lost it as well.
The first hurdle to a seat at the table, and the only one which is non-negotiable, is productive engagement. “We get more done because we invite Alice to our meetings.” That more might be shipping faster, it might be less rework, it might be higher quality. It is always things which matter to the organization.
The more productive the engagement, the more willing people will be to overlook soft skills issues. The famed BOFH doesn’t get a seat at the table, because as much as IT might want one, he’s abusive. Similarly, security people will often show up and say things like “one breach could sink the company,” or “your design is crap.” Hyperbole, insults, anger, all of the crassly negative emotions will cost not just Angry Bob but the whole security team their seat. These are behaviors that get drawn to the attention of management or even HR. They limit careers, and they also make it hard to give feedback. Who wants to get insulted when you’re trying to help someone? They limit teams. Who wants to work with people like that?
There are other, less crass behaviors with similar effect: not listening, not delivering on time, not taking on work that needs taking on. These soft skills will not get you to the table, but they’ll ease the journey, and most importantly, get you the feedback you may need to get there. But if you are in a gatekeeper role today, or if your security team aspires to rise to the point where you have a rope you can pull to stop the production line, the new article on gatekeepers by Mr. Ries is well worth your time.
Larry Greenblat is releasing a series of videos titled “Passing the CISSP Exam with the help of Spock & Kirk.” I, of course, love this, because using stories to help people learn and remember is awesome, and it reminds me of my own “The Security Principles of Saltzer and Schroeder, illustrated with Star Wars.” Also, my thoughts on Star Wars vs Star Trek for these sorts of things.
There’s an increasing — and valuable — trend to publish sample threat models. These might be level sets for customers: “we care about these things.” They might be reassurance for customers: “we care about these things.” They might be marketing, they might serve some other purpose. All are fine motives, and whatever the motive, publishing them gives us an opportunity to look and compare the myriad ways models are created, recorded and used. And so I’m kicking off a series I’m calling “threat modeling Thursdays” to do exactly that.
Up front, let me be clear that I’m looking at these to learn and to illustrate. It’s a dangerous trap to think that “the way to threat model is.” There’s more than one way to do it, as the Perl mavens say. Nothing here is intended to say “this is better or worse.” Rather, I want to say things like “if you’re a consultant, starting with scope is more important than when you’re a developer.”
So today’s model, kicking off the series, comes to us from Synopsys, in a blog post titled “The 5 pillars of a successful threat model.” And again, what’s there is great, and what’s there is very grounded in their consulting practice.
Thus, step 1 includes “define the scope and depth. Once a reasonable scope is determined with stakeholders, it needs to be broken down in terms of individual development teams…” Well, sure! That’s one way to do it. If your threat models are going to be executed by consultants, then it’s essential. And if your threat models are going to be done as an integral part of development, scoping is often implicit. But it’s a fine way to start answering the question of “what are we working on?”
Step 2 is “Gain an understanding of what is being threat modeled.” This is also aligned with my question 1, “what are we working on.”
The diagram is great, and I initially wanted the internet trust boundary to be more pronounced, but leaving it the same as the other boundaries is a nice way to express “threats come from everywhere.”
The other thing I want to say about the diagram is that it looks like a nice consulting deliverable. “We analyzed the system, discovered these components, and if there’s stuff we missed, you should flag it.” And again, that’s a reasonable choice. In fact, any other choice would be unreasonable from consultants. And there are other models. For example, a much less formal whiteboard model might be a reasonable way for a team starting to threat model to document and align around an understanding of “what we’re building.” The diagrams Synopsys present take more time than the less formal ones. They also act as better, more formal records. There are scenarios where those more formal records are important. For example, if you expect to have to justify your choices to a regulator, a photo of a whiteboard does not “convey seriousness.”
Their step 3 is to model the attack possibilities. Their approach here is a crisp version of the “asset/entry point” that Frank Swiderski and Window Snyder present in their book. “Is there any path where a threat agent can reach an asset without going through a control?”
They draw in assets, threat agents and controls here, and while I’m not a advocate of including them in diagrams (it makes for a lot of complexity), using two diagrams lets you study the system, then look at a more in depth version, which works nicely. Also, their definitions of threat agents is pretty interesting, for example, “unauthorized internal user.” It says nothing of their motivation or capabilities, just their starting position and privileges. Compare and contrast that with a threat persona like “Sean “Keech” Purcell – Defacer.” (Keech is one of the personas created by Aucsmith, Dixon, and Martin-Emerson.)
Synopsys’s step 3, along with their step 4, “interpret the threat model,” answer the question “what can go wrong?” Here I do want to mildly critique their use of the word “the.” There are at least four models in play in the threat modeling activity (System, assets, agents, and controls are all modeled.) There’s strength in thinking of threat modeling as a collection of activities. Calling a particular something ‘the threat model’ is both very common and needlessly restrictive.
Their step 5 is to “create a traceability matrix to record missing or weak controls.” This is a fine input to the question that the readers of that matrix will ask, “what are we going to do about it?” Which happens to be my question 3. They have a somewhat complex analytic frame of a threat agent targets an asset via an attack over a surface… Also interesting in the traceability matrix is the presentation of “user credentials” as an attack goal. I treat those as ‘stepping stones,’ rather than goals. Also, in their discussion of the traceability matrix, we see handoffs: “it takes time and repetition to become proficient at [threat modeling],” and “With experience, you’ll be able to develop a simplified traceability matrix.” These are very important points — how we threat model is not simply a function of our job function, it’s also a function of experience, and the ways in which we work through issues changes as we gain experience. There’s another trap in thinking the ways that work for an experienced expert will work for a novice, and the support tools that someone new to threat modeling may use will hinder the expert.
Lastly, they have no explicit analog to my step 4, “did we do a good job?” I believe that has nothing to do with different interests in quality, but rather that the threat model deliverable with their logo on it will go through stages of document preparation, review and critique, and so that quality check is an implicit one in their worlds.
To close, threat modeling shares the property, common in security, that secrecy makes it harder to learn. I have a small list of threat models to look at, and if you know of some that we can look at together, I would love to hear that, or other feedback you might have on what we can learn from this model.
I really enjoyed being part of this panel. I felt we had a good mix of experience and some really interesting conversations.
There’s a long and important blog post from Matt Miller, “Mitigating speculative execution side channel hardware vulnerabilities.”
What makes it important is that it’s a model of these flaws, and helps us understand their context and how else they might appear. It’s also nicely organized along threat modeling lines.
What can go wrong? There’s a set of primitives (conditional branch misprediction, indirect branch misprediction, and exception delivery or deferral). These are built into gadgets for windowing and disclosure gadgets.
There’s also models for mitigations including classes of ways to prevent speculative execution, removing sensitive content from memory and removing observation channels.
Last week, in “Threat Modeling: Citizens Versus Systems,” I wrote:
I think that was a right call for the first project, because the secondary data flows are a can of worms, and drawing them would, frankly, look like a can of worms.
Many organizations don’t disclose them beyond saying “we share your data to deliver and improve the service,” those that do go farther disclose little about the specifics of what data is transferred to who.
Today, via Bruce Schneier, we see that Paypal has disclosed the list of over 600 companies they might share your data with. He rightly asks if that’s unusual. We don’t know. My instinct is that it’s not unusual for a financial multi-national.
I’m standing by the questions I asked; the first level of categories in the Paypal list may act as a good third level for our analysis. It will be interesting to see if others use the same categories. If they don’t, the analysis process is magnified.
Their categories are:
It’s unclear to me how 6 (“Commercial partnerships”) differs from 10 (“Commercial partners”). I say this because I’m curious, not to point and laugh. We should cut Paypal some slack and appreciate that this is a new process to handle a new legal requirement. I’m also curious if 12 (“agencies”) means “law enforcement agencies” or something else.
Visualization from How PayPal Shares Your Data.
Recently, we shared a privacy threat model which was centered on the people of Seattle, rather than on the technologies they use.
Because of that, we had different scoping decisions than I’ve made previously. I’m working through what those scoping decisions mean.
First, we cataloged how data is being gathered. We didn’t get to “what can go wrong?” We didn’t ask about secondary uses or transfers — yet. I think that was a right call for the first project, because the secondary data flows are a can of worms, and drawing them would, frankly, look like a can of worms. We know that most of the data gathered by most of these systems is weakly protected from government agencies. Understanding what secondary data flows can happen will be quite challenging. Many organizations don’t disclose them beyond saying “we share your data to deliver and improve the service,” those that do go farther disclose little about the specifics of what data is transferred to who. So I’d like advice: how would you tackle secondary data flows?
Second, we didn’t systematically look at the question of what could go wrong. Each of those examinations could be roughly the size and effort of a product threat model. Each requires an understanding of a person’s risk profile: victims of intimate partner violence are at risk differently than immigrants. We suspect there’s models there, and working on them is a collaborative task. I’d like advice here. Are there good models of different groups and their concerns on which we could draw?
I have a new Perspectives article at ISACA, Reasonable Software Security Engineering. It talks about the how, why and where you need to ground a software security engineering program.