Threat  Modeling  Assignment  -­‐  CS456    Consider that you are the security team for the following software development project: Your customer is a local auction firm called MooTube Auctions. Mootube specializes in onsite farm, household, and video store (hence the "tube") auctions and they need a software system designed to handle their auction events. The company has three employees - an auctioneer (also the MooTube owner), a clerk and a flunky. Computing hardware of the company includes a mySQL database server, a web server to handle all auction transactions, and two iPads - one for the clerk and one for the flunky. All of these devices communicate by WIFI and broadband, except the two servers, which are connected on a proprietary in-house LAN and protected behind a perimeter firewall. All communication with the iPads uses unencrypted http protocols, except for credit card information, which is always transferred using https. Your company is not responsible for writing the code to handle auctions that runs as a web server applet that communicates with the iPads and dbms server. Each auction is a new event and only buyers registered on that day may bid. To register a potential buyer must show see the clerk who photographs the individual's driver's license. Your software must check this individual against your database of folks who have not paid their debts from a prior auction and against the DMV's database of criminals and/or invalid driver's licenses. Authenticated buyers are each given a uniquely numbered placard that they must wave in order to place a bid. One other piece of information that is supplied at the the time of registration is an email address for the buyer. As the auction proceeds the flunky with the second iPad enters each purchase into a purchase database. The purchase must indicate three things: an ID code for the item purchased, a dollar amount to be paid and the placard number of the buyer. Buyers can check out with the clerk at any time within two hours after the auction ends. To check out the purchaser must show his/her placard and then present a credit card to the clerk. The clerk enters the credit card info and your application uses a standard third-party system to verify that the card is legitimate and has sufficient credit to cover the purchase. The purchaser receives an invoice that is emailed by your software to the email address supplied at the time of registration. (No one worries about the validity of the address, because the buyer just doesn't get an invoice if they supply an invalid address.) At the end of the auction the database of purchase transactions and the database of buyers is archived. Also at this time all buyers with unpaid bills are added to the buyers with unpaid bills database. The auctioneer is the only person with admin privilege on the web and database servers. The auctioneer chooses when to create and destroy the customer databases, and can manually alter any field of any database record. Each of the three employees has a separate role that allows them to perform only the functions as described. Your servlet must allow the MooTube owner to create, delete and modify new users. Each user is given one of the three roles, along with a user name and password. User authentication to your system is handled through a web servlet regardless of device, and all user accounts are maintained by the web server. Your program maintains a log file on the web server of all logins and logouts.

Threat  Analysis  Your threat modeling team must produce a complete collection of threat modeling documents. (These should then by emailed to riley@cs.uwlax.edu or submitted in paper form) (1) A high-level design style dataflow diagram that shows all files and external entities. It should

include processes sufficient to cover all of the functionality described above, but need not break down behavior with any more detail. Also, this DFD should uses dashed lines to depict the trust boundaries.

(2) Using STRIDE identify threats. You need not show an entire threat scenario for each, but there

needs to be enough of an explanation to understand the nature of each threat and how it differs from others. Classify each threat under S, T, R, I , D, or E - you should have several in each category Please remember that this exercise needs to be thorough, but also cannot be so detailed that it is uselessly complex. In other words you are expected to capture significant threats, but need not include everything - particularly threats that are nearly impossible or have virtually no impact. Also, please exclude physical threats, such as theft, vandalism, fire or flood to any of the physical devices. Sometimes you may want to group threats into a single lump because they all have substantially the same probability of occurrence and potential for damage. However, you need to think carefully, because it is important to separate threats whenever they have substantially different threat trees, significantly different probability of occurrence or varying potential for damage.

(3) Every member of the team must draw a threat tree for a threat that is different than all other team

members. Your threat tree must contain at least ten nodes, three levels depth, and must include both AND and OR children. These threat trees should be emailed (or submitted in written form) to Riley separately, and they will be graded separately from the project.

(4) The team must come to an agreement of threat ranking for each threat. The ranking is to use a

LOW-MODEST-MEDIUM-HIGH ranking for probability of occurrence and the same ranking system for potential damage.

While it is expected that teams will divide the responsibilities for creating the documents for (1), (2), and (4) above, it is important that your team get together to agree on these documents so that they are correct and thorough. Threat modeling is sufficiently subjective that such peer review is an important aspect of success. You will be graded upon completeness, clarity, reasonableness and the utility of your documents.

Due  Date:  Apr.  24,  2014