Protection Poker Tutorial
Laurie Williams

Protection Poker Paper

 

Requirements

Considerations for “ease points”

Database tables

Tables to complete

Tutorial slides [Contact Laurie Williams at williams ~ at ~ csc dot ncsu dot edu for the Power Point slides]

 

In this exercise, we will be using a variant of Planning Poker – called Protection Poker – to do a security risk assessment of the new capabilities provided by the team project.   Ultimately, we come out with a ranking of the security risk of each of the new requirements for the iteration.  Requirements with higher security risk should get more attention when it comes of “building security in” to your product and to verifying that security protection mechanisms are in place and working.  Protection Poker is done during an iteration planning meeting.   

 

We use the following computation for security risk:  security risk = (ease of attack)(value of asset being protected)

The following chart can help to clarify this thinking:

 

 

Both Planning Poker and Protection Poker work when members feel free to express their opinion, diversity of opinion is encouraged, and everyone is open to learning from the others.

 

 

Background

The tutorial is based on a hypothetical system called iTrust[1].  iTrust is a role-based heath care web application.  Through the system, patients can see an manage their own medical records.  Medical personnel can manage the medical records of their patients including those provided by other medical personnel, be alerted of patients with warning signs of chronic illness or missing immunizations, and perform biosurveillance such as epidemic detection.       

 

Prerequisite

Knowledge of the Planning Poker practice for effort estimation.

 

Tutorial steps

 

1.       Calibrate value of database tables.  Look at the database tables (provided in Table 1). 

a.       As a team, think about which table could be considered “the” least valuable table to an attacker.    Circle the name of the database and give that table a value of 1 in Table 1.   

b.      As a team, think about which table could be considered the “most” valuable table to an attacker.  Use your “poker” cards to come to consensus about how much more valuable that table is to an attacker than the previous table.   Circle the name of the database and record the value in Table 1.  

These are your two endpoints for the rest of the Protection Poker exercise, though you can certainly update these values if you change your opinion or learn new information.     

2.       Calibrate ease of attack for new requirements.  Look at the new requirements and try  to come to a consensus on the requirement that will make an attack easiest and the requirement that will make the attack hardest for an attacker to exploit the new functionality.   Here is a partial list of things to consider.  Use your “poker” cards to assign ease points to the hardest and easiest to attack.  Record these ease points in Table 3 for the appropriate requirement.   These are your two endpoints for the rest of the Protection Poker exercise, though you can certainly update these values if you change your opinion or learn new information.  

3.       Compute security risk.  For each requirement, perform the following steps:

a.       Identify each database table used by the new capabilities provided by that requirement.   Document the names of these tables in Table 2.  If a new table will need to be created for this requirement, name it and write this name in Table 2.  

b.      For each table identified in step 2a, look in Table 1 to see if the table has been assigned a value.

·   If yes, copy the value into Table 2. 

·   If no, use your poker cards to assign that database table a value, considering the relative values assigned in Step 1.  Record that value in Table 1 and Table 2.

c.       Put the sum of the values of all the database tables in Table 2 in the “value” points for the requirement in Table 3 .

d.      Consider ease points for the remaining five requirements – how easy does the new capability make an attack for someone with malicious intent?     Use your “poker” cards to assign a value for ease points for each requirement.  Record the value in Table 3.

e.      Compute security risk by multiplying the value points (step 3c) by ease points (step 3d).  Record the value for security risk in Table 3.

4.       Rank security risk.  Once you have computed the value for security risk for each requirement, provide a ranking number for each requirement in the last column of Table 3 where the requirement with the highest security risk is given a 1 and the lowest security risk a 4.  As you develop your project, use these rankings to consider how much security attention to pay to each of these requirements.   Looking at your risk rankings, is any rank surprising to you? Discuss as a group any surprises in your prioritization, and how well you are satisfied with both the values and the ranks. 

 

 

 



[1] This description is a simplified version of the actual iTrust project which can be seen at http://agile.csc.ncsu.edu/iTrust/.  iTrust provides a testbed for software engineering courses, particularly those that deal with privacy and security issues.