Instructor Notes

This is a placeholder file. Please add content here.

Introduction

Agile Security Game

Instructor Notes - Prep

Preparation in Advance - Face-to-Face

  1. Calculate how many players you’ll have, and so how many teams of 3-6 players you’ll need.
  2. Print the two side GamePlayerInstructionsPrinted.pdf sheet, one per player, preferably 2-sided.
  3. Print from CardsFourToPage.pdf a set of task cards for each team, on A4 paper, one sided and ideally on light card (black and white is fine, colour better). Then cut them out, preferably with a guillotine (or see below).
  4. Sort out cards in advance into individual mini-packs of a set of each (A, B, C, or D), according to the letters in the top right corner. Each pack has an additional ‘cover’ card. A packs have 8 cards; B, C, and D have 4 cards.
  5. Optionally, you might like to get large flipchart sheets of paper for the teams to use as Kanban boards on the table, or arrange for a whiteboard for each team with blu- tack to stick the cards there.

Setup on the Day

  1. Arrange the room with separate tables with 2-6 chairs around each table. Make there’s a piece of blank paper and pen for each team.
  2. Set up a projector/display visible to all the players, showing the DeveloperSecurityEssentials.pptx presentation. Note that if no projector/display screen is available, you could use the option of reading out the content of the slides instead.
  3. Sort out cards in advance into individual mini-packs of a set of each (A, B, C, or D), with cover. A packs have 8 cards; B, C, and D have 4 cards.

Running the Workshop

The workshop has an introduction, up to four rounds, or ‘sprints’, and a wrap-up session. Timings are approximate. Adjust them according to how the teams are getting on in each step.

TABLE 1: WHEN TO GIVE OUT CARDS

Tell the participants that they are taking the role of agile product managers for the MoneyZoom product; their role is to decide on the stories for the development team to tackle each sprint. In the first couple of sprints each team will be able to complete 11 story points, using the Kanban board on their shared board. Stories chosen from previous sprints will remain part of the product and available to mitigate attacks. Stories not chosen in a given sprint will remain on the backlog as candidates to be chosen in later sprints. Optionally you might use the first PowerPoint slide.

Face-to-face: Organise the players into teams of 2-6 people, each team sitting at chairs around a table, as shown in Figure 1. Give each player a set of Player Instructions.

The workshop then proceeds in ‘sprints’.


Instructor Notes - Sprints

Instructor Notes - Wrap Up

Wrap-Up (10 min)

Ask the teams to discuss what they feel they learned from the game. Then either get a representative to report back for each, or (larger group) use an ‘open ended’ question on Menti.com to gather and share feedback (this can work even face-to-face). You may like to explain some less obvious learning points (with the appropriate slide): - The password tasks (EP – Complex Passwords, and CC – Credential Changes) conflict with recent UK National Cyber Security Centre guidance, and have no benefit. - Detecting Jailbroken devices (DJ) doesn’t really help with app security – few apps do it nowadays. Similarly Review of Server Code (RS) is rarely used.

Some Notes about the Game

In a real world situation obviously one wouldn’t get feedback and lists of attacks before the start of the next agile sprint. If this worries you or the players, say that the ‘security enhancement’ sprints we’re doing here would actually be interspersed with a number of functionality sprints, allowing plenty of time for feedback before the next sprint. Observe in the attack descriptions that in some cases the mitigations are alternatives: the first attack could be mitigated by either BS or PT. But in other cases the teams must have completed all of a collection of tasks to mitigate the attack.


Threat Assessment

Instructor Notes - Prep

Instructor Notes - Running the Workshop

The timings are approximate. Adjust them according to how the teams are getting on in each step.

Step 1: Ideation (30 min)

Display the slide with: Who might do what bad thing to whom? Person – Thing – Reason

Ask the groups to think about their project, and ‘ideate’ answers, writing down the person-thing-reason combinations on the post-its on their board. Encourage everyone to write independently (duplicates will be combined in the next step). Remind them that not every bad thing is malicious; sometimes security or privacy issues happen due to accident or misunderstandings. Encourage them to discuss the issues, and to gather as many completed post-its (‘threats’) as they reasonably can.

Step 2: Organisation (15 min)

Have the participants in each room cluster the ‘post-its’ into ‘topics’, posting related ones close together and duplicates on top of each other.

Step 3: Evaluation (15 min)

This step identifies the most important threats. Copy the ‘dot voting sets’ to the appropriate boards for each breakout room. Ask each participant to pick the threats (post-its) that are (a) most likely, and (b) most damaging. And to place a black dot next to the each of the three they consider most likely; and a red dot next to the three they think most damaging. When they’re done, take a photo of each of the resulting boards, for reference.

Step 4: Summary (10 min)

Get the Technical Leads or a responsible couple of people from each project to use the dots next to each post-it to position a selection of the threats on the grid. A dozen or so is a good number to aim for. Figure 4 shows an example (online); Figure 5, an example face-to-face. The threats towards the top right are the most important ones to consider in the corresponding projects.


Instructor Notes

Benefit Analysis

Instructor Note

If you would like to add a post-workshop survey, I recommend adding a QR Code (if in person) or a link here (if online).