Threat Modeling Activity

Overview

The purpose of this activity is to help you enumerate and model the security of your system architecture by looking at it from the point of view of threats. According to the Microsoft Threat Modeling methodology, we treat the word “threat” as a class of exploits. They fall into the following categories (S.T.R.I.D.E.):

  • Spoofing
  • Tampering
  • Repudiation
  • Information Disclosure
  • Denial of Service
  • Elevation of Privilege

Today, let’s model Dropbox. Dropbox is a cloud-based storage system for your desktop and mobile devices. Store a file in a folder on your desktop, and it gets immediately uploaded to the server, and synchronized across all of your registered devices. Users can share folders in their Dropbox, allowing other users or the public view the files. Also, each change to a file is kept in a version history, so that users can revert to old copies of their files. All of this can be managed via a desktop client, a mobile client, and a webapp.

One feature you may not know about Dropbox is their de-duplication engine. The clients maintain a local list of hashes of the files in your folder. When a file is changed, Dropbox re-computes the hash, and sends all of the hashes to the server. The server then uses this logic on each hash:

  • New change. If the server doesn’t have the hash, upload the file.
  • No change. If the server has the hash associated with the user’s account already, no files are uploaded.
  • De-duplicate. If the server has the hash already, but another user owns it, then make a record that a user is storing a copy of the file associated with that hash (i.e. no files are uploaded, just some bookkeeping).

De-duplication can provide a huge speedup in upload times and a gives big savings in storage for Dropbox. It also may have some security risks that may become apparent once we do some threat modeling.

Addtionally, Dropbox servers are spread across multiple physical sites, and data is replicated across those sites for reliability and performance. This replication is handled by a single database management system. Mobile and desktop clients (even the webapp) all interact with a common API.

Note: you may make reasonable assumptions about the features of the system for the sake of this exercise. This link may be helpful for understanding how Dropbox works.

Setup

This activity is for groups of 2-3.

Fire up the Microsoft Threat Modeling tool. Before going further, save your file, calling it Dropbox.tm4. The tool should be installed in the lab. If you are working from your own machine, the tool can be found at MS Threat Modeling 2014 or at MS Threat Modeling 2016. If you don’t have access to a Windows machine, you can create a VM in RLES by following the instructions in the Web Application Activity.

Activity

  1. Discuss as a group briefly what the architecture of the system will look like.
  2. Start your model by creating processes, interactors and stores.
  3. Next, add data flow relationships. Be sure to name every relationship with a noun describing a type of data. For example, “Authentication Data” or “Passwords” are types of data that would flow from one primitive to another. Note: you can have multiple dataflows from one primitive to another. Don’t go too crazy with it - try to name your data in the most useful way possible.
  4. Next, add trust boundaries.
  5. For each primitive in the diagram, update the Properties to be as realistic as possible.
  6. Now go to Analyze model (View->Analysis View)
  7. Expand a few of the items. Notice the vast number of potential threats that can arise.
  8. Let’s eliminate some threats to be generated with some assumptions. Discuss as a group which threat categories you believe are not possible in Dropbox. Change those to “Not Applicable”. Be ready to discuss your choice with the class.
  9. Now let’s revise a threat, getting our inspiration from the diagram. Start with DenialOfService on a data store. Fill in the potential mitigiations you might take.
  10. Now let’s also test your model. Try to think of a security concern in your system. This can be a design concern or domain-specific vulnerability. Where does it fit in your model? If it doesn’t, revise the model a bit.
  11. Pick three more elements, and come up with a threat for each of those (just pick one category of threat).
  12. At this point, check the report by going to Generate Reports in the lower-left. Note anything you believe is missing.
  13. Continue adding threats to the system. Be ready to discuss your results with the class.

Submission

Nothing is due beyond your participation in this activity. If you would like feedback on your threat model, please show it to the TA or to the instructor (you can submit to the myCourses assignment folder for easy viewing). Getting feedback on your threat model is a great way to study this material!