As a leader, you need to be able to see the forest and chart a path through it. That means abstracting problems and being disciplined in the way you do so. It means organizing your thoughts in ways that help you solve problems, and help shape the thinking of those around you. Threat modeling is a means to the end goal of better thinking about security problems.
Leaders know that rolling out any new set of tasks or skills can be tough. This paper will walk you through an essential approach you should use, namely, growing circles of influence. We'll start by selling you, then selling a small team, and then using their success to influence others in various ways.
In "Threat Modeling: What, Why, and How," you learned what threat modeling is and the steps involved in doing it. In this follow-on paper, you'll learn why you should make it central to your security programs overall, how to roll out threat modeling, and how to manage a threat modeling program.
This paper is written for leaders of security programs at large organizations.
Modeling Is Central to Strategic Security Programs
Too many security programs are responsive. To news. To marketing campaigns. To breaches. Executives want to know that you've got appropriate strategies, that is, an ability to define a program that allocates resources well to be prepared for tomorrow's problems.
The key advantage of threat modeling in the four-question framework is that it helps you see the forest. (The four-question framework is: "What are we working on? What can go wrong? What are we going to do about it? Did we do a good job?")
Over many years of securing products and organizations, I've seen narrow conceptions of "the problem" lead to defenses that were predictably bypassable. And I've seen threat modeling lead to uncomfortable questions. Sometimes entire sets of attacks were being ignored. How could we have let that happen? Maybe we missed it. Maybe we got focused on the shiny widgets from Acme. Maybe there are decent reasons: it's hard to defend against an attack. For example, there's no simple defense, and we need to re-architect, and that will take time. Better to know, to make a decision, than to be surprised.
Here's a concrete example of how defenses go wrong: many organizations get focused on "password recovery" for "backup authentication" for their customers. When they do, they set up the sorts of "secret answer" systems with which we are all familiar. To reduce the chances that we change the spelling of our answer, they provide drop down answers, and in doing so get a whopping 3 or 4 bits of entropy per answer. (A bad password will have at least 10-15 bits, a good password 50-80 or more.) Attackers, of course, see these for what they are: easily attacked primary authentication. Being overly focused on seeing it as backup obscures opportunities to make it safer, such as requiring time to elapse between a successful authentication and use of a backup; use of email as a backup channel; use of trustees who can authorize access to the account.
Also, if you're paying attention, only attackers ever want password recovery—they know that people's memories are limited, and we often re-use passwords across many sites. Thus, learning the password that your customer set is a win for them. The right fix for that is to use password managers, and you should stop breaking things like pasting passwords. I'm personally fond of 1Password. What you and your customers want is account recovery, access back into their account.
Good threat modeling helps you think through these things, and to recognize that spoofing of an account is only one of the threats you need to be thinking about.
You may or may not find this example compelling. Different organizations focus on different threats in different ways, and so in the next section I'm going to talk about finding the examples that are compelling for you.
Driving Organizational Change
Getting a large organization to make any change is difficult. There are many proposed changes, and the staff can only learn so many new skills in a year while continuing to deliver against the many demands for their productivity. Therefore, there is competition over what new projects will be prioritized, and rolling out threat modeling will require that it rise above those other projects.
To rise above other projects, you need to show first feasibility, then value, then more value than competing alternatives. You need to do this both at the individual contributor and the executive level.
Piloting Threat Modeling
The first step is to show that you can threat model. Threat modeling has transformed over the last ten years. Active listening, careful prototyping, and post-mortems on failing projects have allowed us to dramatically improve success rates, and with them, adoption. This has been the case at companies of all sizes, in many sectors. But you still need to show that you have the skills and ability to threat model as part of a project, and that you get worthwhile results when you do so. Some of the useful measurable results you may see include better penetration test results, fewer security bugs, or higher confidence. You will also see fewer architectural misunderstandings and concomitant faster delivery.
As you, your project managers, your architects, and your security leads learn these new skills, the road will be smooth like glass. No, wait, who am I kidding? Nothing new is ever easy! It will take time to develop the muscles you need to threat model. The first time you do it may not go smoothly. That's expected with a pilot program. Don't panic.
Once you've tried and succeeded with a project, you can iterate within a small team, or grow the practice to more teams. The benefit to iteration is your proof points are stronger, but you risk learning lessons that are tied to that small team. The sooner you can grow to more teams, the sooner you'll learn what works for your organization as a whole.
Selling Threat Modeling
Most organizations have both formal and informal leaders. There are people whose influence comes from their role, and there are people whose influence comes from their competency, their wisdom, and their mentoring of others. Different organizations call the second group different things, and whatever you call them, you're going to need one or more of them onboard, because a technical leader who speaks up in a meeting to ask, "didn't you threat model that" is going to do a great deal of good for getting threat modeling suffused through the organization.
Crafting a Successful Pilot
The ideal threat modeling pilot will deliver security value as part of a successful delivery of an important project. Of course, successful projects usually take controlled sets of risks, and you don't know which projects will succeed and which will fail. (How much risk a project takes on, and how partial successes are seen are deeply tied to organizational culture. Similarly, organizations have very different levels of project management discipline.) You want an important project, but not a "bet the company" project. "Bet the company" projects are going to take on as few unknowns as possible.
Some of the characteristics you want to look for include security risk, awareness of those risks amongst project leaders, and security awareness or skills on the part of the participants. You want some security risk because if the project has none, the threat modeling is going to be pretty boring. You want leadership to be aware of the project because if they're not, implementing fixes will be tricky. This also relates to avoiding the "bet the company" projects. Those projects almost certainly need to ship quickly.
You want to start fixes right away because that's the key value proposition: that threat modeling allows you to find and fix problems early.
Lastly, security awareness amongst participants makes it easier to stay focused on the high value work.
Now you've identified a project that seems like a good fit. Next you need to go do. You're going to want to ask for about a day of time from several participants. That's going to break out as a few meetings:
- A bit of goal setting
- 1-2 hours of meeting on, "what are you working on," that is, architectural analysis to get a diagram. (Deliverable: a diagram that represents the planned outcome of the project.)
- 1-2 hours of meeting to ask, "what could go wrong," using the Elevation of Privilege game. (I usually introduce it by asking people to give me 15 minutes without skepticism; to suspend their disbelief and give something a little different a try. Deliverables: a list of issues, tracked as bugs. A list of security requirements. A list of assumptions you found along the way and need to check.)
- 1-2 hours of meeting to triage security bugs, and possibly discuss fixes.
- 1 hour meeting to assess how you did.
Pre-requisites:
- At least one copy of the Elevation of Privilege game.
- Optionally, a copy of Threat Modeling: Designing for Security as a reference.
Overall outcomes:
You want anecdote and data. The anecdote should be about a security issue that you wouldn't have otherwise found, what could have happened, and why that's important. The best outcome is being able to say something like, "because we threat modeled, we caught a set of test interfaces that allowed full extraction of our customer database. If this had rolled to production, it could have been a major breach." If you can follow that up with data about how many people were involved, how long it took them, and the number of issues they found, then you can start comparing it to other security efforts, and you're well on your way from a pilot to a program.
