Protection Poker

Overview

Protection Poker is an activity inspired by Planning Poker and Wideband Delphi. The activity has three purposes:

• Data. Give a quantitative risk assessment of a given requirement or fix.
• Tracing. Provide a tracing of functionality to system assets.
• Discussion. Surfacing assumptions and disagreements

Let's model the hypothetical system Prescribe Me!, a system for doctors and patients to manage their prescriptions digitally. The system is a web application optimized for mobile devices. Doctors can use the site to enter in prescriptions for a given patient. Patients can look up their prescriptions, and show a barcode to the pharmacists to get a prescription fulfilled. The pharmacist then looks up the prescription on the website, fulfills it, then notifies the doctor by email that a prescription has been fulfilled. A prescription includes the following data fields: patient name, drug code, and dosage information, and a prescription expiration date.

The code for the prescription from the National Drug Code (NDC) database, which is a standard data set downloaded daily by the system and imported into the database. Furthermore, a doctor can find a patient's address information via Health Me!, an external medical records application that stores a given patient's medical history, including diagnoses, test results, and confidential doctor's notes. The doctor does not, however, have to use a patient from Health Me! to write a prescription. Doctors, patients, and pharmacists are all authenticated users in the system.

Prescribe Me! is already in production and being used by doctors and patients. Below is a list of user stories and bug fixes for the upcoming sprint.

• New feature. The doctor enters additional instructions with the prescription, including instructions that only the pharmacist sees, and instructions that only the patient sees.
• New feature. The doctor is notified of a potentially dangerous interaction with a patient's previous prescription.
• New feature. The patient can select a list of NDC codes that they are allergic to. The doctor is notified immediately when trying to create a prescription for a patient when the patient is allergic.
• Bug fix. Sometimes the overnight loading script fails to update the NDC codes to the latest version.
• Bug fix. Pharmacists are unable to reset their passwords if they forgot.

Note: you may make reasonable assumptions and speculations about this system's design and implementation. Your instructor can answer any questions you might have about the product.

Activity

This activity is for groups of 4-6.

1. Go to the Example Protection Poker document. Make a copy for your team (go to File > Make a Copy...). Share the document with each team member, and the instructor.
2. Notice that we have three sheets: Items, Assets, and Risk. Go to the Assets sheet. The Assets table is populated with the following default assets and descriptions.
   • Availability of doctor interface. The ability to keep the system available to doctors.
   • Availability of patient interface. The ability to keep the system available to patients.
   • Availability of pharmacist interface. The ability to keep the system available to pharmacists.
   • NDC codes. The database table that stores the NDC coding standard.
3. Notice that we have the initial sheet "Items", with the following columns:
   • Name
   • Description
   • Ease of Attack
   • Assets
   Populate the table with the user stories and bugs from the overview above. You come up with the name. Leave the last three columns blank for now.
4. Your instructor will give you a deck of cards, with numbers labeled on them. Make sure everyone gets a hand of cards with the following numbers: 1,2,3,5,8,13,20,40
5. List the system assets. As a group, discuss what the other assets are in the system. Come up with at least three more assets, and give the names and a one-sentence description. Don't worry about that value column just yet.
6. Agree on the assets. As a class, we will discuss the list of assets. Everyone in the class will agree on the same list of assets, so please modify the name to be consistent with everyone else when we discuss this as a class.
7. Calibrate the asset values. Of all the assets listed, which one is the most important, if it were compromised? Give this asset the maximum value of 40. Discuss as a group which asset would have the most detrimental effect if it were compromised. Remember to consider confidentiality, integrity, and availability.
8. Calibrate the ease of attack . Of all the features and bugs listed, which one is the easiest to attack? Give this one a 40 as well. For these, consider what would happen if a developer made a mistake in implementing the story or fixing the bug (or failing to fix the bug entirely). Note that this has nothing to do with what assets are affected, purely the item itself. Factors that affect the ease of attack include:
   • Complexity and amount of the change to the system make attacks easier
   • More user inputs added to the system makes attacks easier
   • Changes to the architecture or system design can make attacks easier
   • Story involves a feature with many users leads to more exposure
9. Trace one item to its assets. Pick an item at random. In the Assets column, list each the assets that affected by this item. You must agree as a group on this. If anyone comes up with a new asset at this stage, add it to the Assets sheet.
10. Vote on each traced asset for the item. For each asset affected by this one item, vote on its relative value. Each person must place a card, face-down. When everyone has placed their card face down, everyone reveals their vote. The highest and lowest person provide reasoning for their vote. After that, other people can join the conversation. The group must come to a consensus. Re-vote if you need to.
11. Vote on ease of attack for the item in the same manner as the previous step.
12. Repeat this process for each item. Use past precedents in the discussion in your reasoning. Note that not every asset may be affected by your items... that's okay. Sometimes an asset is not affected during a given sprint.
13. Compute & rank risk. Compute two additional risk columns: Max(Risk) and Sum(Risk).
    • Max(Risk) = Ease of Attack * Max(Asset Values)
    • Sum(Risk) = Ease of Attack * Sum(Asset Values)
    This might be a manual process, depending on how you set up your spreadsheet. Feel free to edit any formulas in the cells, if the lookups don't work for you.
14. Show the rankings of your items according each risk. Any surprises? Any large discrepancies between Max(Risk) and Sum(Risk)? Discuss. Be ready to discuss your results with the class.

Submission & Grading

This activity is worth 10 points, and your grade is based on in-class participation. Nothing is due beyond class today, as long as you are participating and are reasonably close to completion. Your instructor will check your GoogleDoc before the end of class.