TM Chapter 1 Drive In and Threat Model

What are the four key questions to threat modeling?

1. What are you building (Can use diagrams to show data flow through components, boundaries)? 2. What can go wrong (STRIDE)? 3. What should you do about those things that can go wrong? (Mitigate it, eliminate it by removing features, transfer it operating system or firewall or customer, or accept it) 4. Did you do a decent job of analysis? Addressing a threat involves mitigation strategy and a mitigation technique.

"What are you building" is the first of the four key questions of threat modeling. What's it about?

- Diagrams are useful here, specifically data flow diagrams. - Your system might be comprised of a web browser, web server, business logic and a database. Think about can go wrong in these application and their communication. For example, how do you know that the web browser is being used by the person you expect? What happens if someone modifies data in the database? Is it OK for information to move from one box to the next without being encrypted? You might want to take a minute to think about some things that could go wrong here because these sorts of questions may lead you to ask "is that allowed?" You can create an even better model of what you're building if you think about "who controls what" a little. Is this a website for the whole Internet, or is it an intranet site? Is the database on site, or at a web provider?

Why should you do threat modeling?

- Find security bugs early - Understand your security requirements. Good threat models can help you ask "Is that really a requirement?" - Engineer and deliver better products. By considering your requirements and design early in the process, you can dramatically lower the odds that you'll be re-designing, re-factoring, or facing a constant stream of security bugs. - Address issues other techniques won't. Threat modeling will lead you to catego- ries of issues that other tools won't find. Some of these issues will be errors of omission, such as a failure to authenticate a connection. That's not something that a code analysis tool will find. Other issues will be unique to your design.

What is Threat Modeling?

In this context, a threat is a potential or actual adverse event that may be malicious (such as a denial-of-service attack) or incidental (such as the failure of a storage device), and that can compromise the assets of an enterprise. The key to threat modeling is to determine where the most effort should be applied to keep a system secure. This is a variable that changes as new factors develop and become known, applications are added, removed, or upgraded, and user requirements evolve. Threat modeling is an iterative process that consists of defining enterprise assets, identifying what each application does with respect to these assets, creating a security profile for each application, identifying potential threats, prioritizing potential threats, and documenting adverse events and the actions taken in each case.

What is Stride?

It stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege: ■ Spoofing is pretending to be something or someone you're not. ■ Tampering is modifying something you're not supposed to modify. It can include packets on the wire (or wireless), bits on disk, or the bits in memory. ■ Repudiation means claiming you didn't do something (regardless of whether you did or not). ■ Denial of Service are attacks designed to prevent a system from provid- ing service, including by crashing it, making it unusably slow, or filling all its storage. ■ Information Disclosure is about exposing information to people who are not authorized to see it. ■ Elevation of Privilege is when a program or user is technically able to do things that they're not supposed to do.

"What can go wrong?" is the second of the four key questions to threat modeling. Explain!

Now that you have a diagram, you can really start looking for what can go wrong with its security. STRIDE is a good place to start. Recall the three example threats mentioned in the preceding section: ■ How do you know that the web browser is being used by the person you expect? ■ What happens if someone modifies data in the database? ■ Is it ok for information to go from one box to the next without being encrypted? These are examples of spoofing, tampering, and information disclosure. Using STRIDE as a mnemonic can help you walk through a diagram and select example threats. Pair that with a little knowledge of security and the right techniques, and you'll find the important threats faster and more reliably. For each of these, imagine how STRIDE can be used to threaten your security.

In a data flow diagram, what is a trust boundary?

Trust boundary is a term in computer science and security used to describe a boundary where program data or execution changes its level of "trust". The term refers to any distinct boundary within which a system trusts all sub-systems (including data). An example of an execution trust boundary would be where an application attains an increased privilege level (such as root). A data trust boundary is a point where data comes from an untrusted source. For example, user input or a network socket. A "trust boundary violation" refers to a vulnerability where computer software trusts data that has not been validated before crossing a boundary. A web server and business logic might exist within the same realm, and the trust boundary might be drawn there as a box. You can give every connection between a component a number, to referer to that relationship as its own trust boundary.

"Checking your work" is the fourth question to threat modeling. Explain what it's about!

Validation of your threat model is the last thing you do as part of threat model- ing. There are a few tasks to be done here, and it is best to keep them aligned with the order in which you did the previous work. Therefore, the validation tasks include checking the model, checking that you've looked for each threat, and checking your tests. You probably also want to validate the model a second time as you get close to shipping or deploying. - Check your model. Have you found the relevant threats? - Update your model (diagram). Have you left out any key data? - Check each threat. There are two main types of validation activities you should do. The first is checking that you did the right thing with each threat you found. The other is asking if you found all the threats you should find. - Check the tests you've build to handle the threat.

"Addressing each threat" is the third question of doing threat modeling. Explain!

You should now have a decent-sized list or lists of threats. The next step in the threat modeling process is to go through the lists and address each threat. There are four types of action you can take against each threat: ■ Mitigating threats: is about doing things to make it harder to take advan- tage of a threat. Requiring passwords to control who can log in mitigates the threat of spoofing. Adding password controls that enforce complexity or expiration makes it less likely that a password will be guessed or usable if stolen. ■ Eliminating threats is almost always achieved by eliminating features. ■ Transferring threats is about letting someone or something else handle the risk. ■ Accepting the risk is the final approach to addressing threats. For most organizations most of the time, searching everyone on the way in and out of the building is not worth the expense or the cost to the dignity and job satisfaction of those workers. Foe each of these, consider STRIDE and how you would address the threats you previously listed.

With threat modeling (question 2), how do you identify threats?

■ Start with external entities: If you're not sure where to start, start with the external entities or events which drive activity. There are many other valid approaches though: You might start with the web browser, look- ing for spoofing, then tampering, and so on. ■ Never ignore a threat because it's not what you're looking for right now. ■ Focus on feasible threat: There are real possibilities but not very likely com- pared to using an exploit to attack a vulnerability for which you haven't applied the patch, or tricking someone into installing software.