There's more than one way to threat model

Today, most presentations on threat modeling talk about each phase of the process. They talk about how to model what you’re building, what can go wrong, and what to do about it. Those tightly coupled processes can be great if you’ve never heard of an approach to threat modeling. But they can add to the challenge for those trying to execute the process. What knowledge and skills can they re-use, and what do they need to replace?

Two of the big ideas in Threat Modeling: Designing for Security are that there’s more than one way to threat model, and that we can and should compose them. We can move beyond every talk covering how to model, how to find problems, and how to fix them. And when we do that, we improve our ability to agilely engage with new approaches, because the cost of experimentation falls.

One such new approach is DIAL: Discovery, Incorrectness, Authorization/Authentication, Limits/Latency. It’s a set of ‘threats’ to reliability, being explored by my colleagues in Microsoft Trustworthy Computing’s Reliability team. DIAL is an interesting complement to security threat modeling, because it starts with a D which (of course) stands for Denial of Service in STRIDE. And that’s sort of neat.

Anyway, the blog posts are worth checking out:

  1. Reliability vs. resilience
  2. Categorizing reliability threats to your service
  3. Reliability-enhancing techniques (Part 1)
  4. Reliability-enhancing techniques (Part 2)

[Update: inserted “D” in the “starts with a ..” sentence. Thanks Mike for pointing out the error!]

Threat modeling the Dread Pirate Roberts way

It has to be said that no one in the Princess Bride is great at threat modeling. But one scene in particular stands out. It’s while they’re planning to attack the castle and rescue Buttercup:

if only we had a wheelbarrow

Westley: I mean, if we only had a wheelbarrow, that would be something.
Inigo: Where we did we put that wheelbarrow the albino had?
Fezzik: Over the albino, I think.
Westley: Well, why didn’t you list that among our assets in the first place?

The trouble here is that Inigo and Fezzik don’t see a wheelbarrow as an asset worth listing. They know about it, but don’t bring it up. This is a predictable and even desirable state. When you model, you discard details that seem irrelevant. If you list absolutely everything, you end up sounding like the rain man, not an engineer.

Knowing what’s important enough to list is challenging. There’s no prescriptive guidance to what assets are worth including. (Because it’s challenging to know what’s a good list, there’s also no clear exit criteria or “gate.”)

Security experts love to complain that others have left things out. If you want to complain, you need to start with a clear definition of what’s an asset, what assets are important enough to list (A $10 wheelbarrow?), and what constitutes a good list. That’s simply easier with the technology that you’re threat modeling, rather worrying about assets.

Virtual assistant services?

I’m getting ready to announce an East coast book tour. In planning my Silicon Valley tour, I learned that between scheduling, getting the details needed out, making sure I knew where I was sleeping, there was a large amount of administrative work involved. So I’d like to hire someone to take care of all that for me next time.

I think the tasks will include:

  • Engage with companies/venues interested in having me speak to work through scheduling & logistics, including ordering books
  • Scheduling (including travel time, setup, speaking, signing)
  • Travel coordination including hotels & trains

Do you have recommendations for a virtual assistant service that you’ve used for something at this level of complexity?

Alternately, convince me that I want a specialized book tour operator? My experience in Silicon Valley was that most venues were companies, and many were good enough to buy the books for their employees. So I don’t think I need someone specialized.

Should I Start Threat Modeling from Assets?

A couple of reviewers have commented that they have different perspective on assets. For example, in a review I very much appreciated, Gunnar Peterson says:

I have slightly a different perspective on Shostack’s view on assets. The book goes into different views that launch the threat model, the approach advocated for in the book is very software-centric. I have no quibble on that, especially if you work for a software company. But for a financial institution, a supply chain, a healthcare company, I think it works less well to assume a software first view of the world. Its simpler in those companies to get traction by looking at the assets in play – accounts, confidential data, supplier access, and so on. for one thing, you can engage a wider portion of the organization. For another you have an easier time linking the resultant threats to a business impact.

The TL;DR response is consultants may like asset-centered approaches more than others, and the closer you are to the code, the less helpful they are. Previously, I wrote (page 39):

Focusing on assets appears to be a common-sense approach to threat modeling, to the point where it seems hard to argue with. Unfortunately, much of the time, a discussion of assets does not improve threat modeling. However, the misconception is so common that it’s important to examine why it doesn’t help.

There’s no direct line from assets to threats, and no prescriptive set of steps… That discussion, at best, results in a list of things to look for in your software or operational model, so why not start by creating such a model? Once you have a list of assets, that list is not (ahem) a stepping stone to finding threats; you still need to apply some methodology or approach. Finally, assets may help you prioritize threats, but if that’s your goal, it doesn’t mean you should start with or focus on assets. [Note that this sentence could be more clear as “assets may help you prioritize threats, but that doesn’t mean you should start with, or focus on, assets.’]

Let me say a bit more, since this perspective keeps coming up in both reviews and private conversations. Financial institutions are a great example, because, after all, they hold money as an asset which attackers want and that they want to defend, so we can avoid definitional issues. We can over-simplify and say that money is THE asset that the bank has. Also, I’ve done a fair amount of work threat modeling for financial institutions, so I have a basis for discussing how those systems are really built.

So, let’s take a retail bank as an example. (In contrast to an investment bank, a retail bank does most of its business with consumers and businesses, providing things like loans and money management.) The bank has a general ledger (GL) system. It’s often still on a mainframe, and it is the only place where money really moves from one account to another. So we should start threat modeling there, right? Maybe.

Let’s look at the rest of the business. It turns out that there are pretty much two types of systems at the bank: those that touch the GL as a matter of course, and the desktops and laptops that people use to do their day jobs. In other words, pretty much everything that the bank has deployed, from the web front ends that show you your balance through to the inter-bank transfer systems like ACH and credit cards through the systems that calculate taxes have access to the GL. That access is often mediated through several layers of control, protocol translation and the like, but the access is there. Worse, even the systems that you’d hope are read-only (the tax calculators) can often move money around (manage deductions, enforce IRS mandatory withholding, etc). Now, I’m modeling, that is to say simplifying. But in this instance, I don’t think I’m dramatically over-simplifying.

If you go and enumerate everywhere the money is, or everywhere that there’s access to the GL, what you eventually get to (in essence) is a model of the software. It’s more expensive than a software-mainly model because you need to draw in additional people who can explain the business processes, and add a layer of model that covers how money moves.

Now, it may be that if you come in consulting at the senior management level (and I think Gunnar often does), that you start from the money because the senior management folks have no idea how their systems are actually plugged together, and figuring it out requires following the business processes, and reporting will require going back along that path of following the money. So here, I think the difference is one of intended audience: the book is primarily for people building or operating software, not consultants. If we make it accessible, those folks can and should learn to threat model. It’s easier than git.

People building software or systems at a financial institution, a supply chain, or a healthcare company should start from the software they’re building because it’s what they know best. Another way to say this is that they are surrounded by layers of business analysts, architects, project managers, and other folks who translate between the business requirements (including assets) and software and system requirements.

Gunnar and I agree that assets are a great tool to link “the resultant threats to a business impact.” It’s my experience (as a consultant and at my current employer) that the assets come out in risk discussion after you’ve identified a software issue.

So to answer the question: it depends who you are. If you know the software, you should start there.

L'Academie Gawker

Via Poynter, we learn that the word “massive” has been banned on Gawker.

We want to sound like regular adult human beings, not Buzzfeed writers or Reddit commenters,” new Gawker Editor Max Read says in a memo to the publication’s writers. Words like “epic,” “pwn” and “derp” are no longer welcome on the site. Read also says the word “massive” is “never to appear on the website Gawker dot com.”

The desire to sound like regular human beings is admirable, and Mr. Read is correct when he says that jokes made using strikethrough are generally not worth saving.

However, he seems to fall into a trap of believing that there is an hierarchy of language goodness which is removed from our social hierarchies. We’re not the French, with L’Acadamie française to define correct language, and to be ignored by Le Frenchmen dans on le weekends.

The observable reality is that language evolves as a result of a variety of pressures or opportunities. That is, language is emergent, not decreed. There is no authority who gets to declare what words a community uses (outside of NewSpeak, and even in Orwell’s world, normal people don’t use NewSpeak daily, because the words decreed by Big Brother didn’t serve their needs. Real language is inevitably chaotic and messy.

This is a massive pile of derp, and an epic mistake on Gawker’s part.

[Updated to add a strikethrough joke.]