Content from Introduction
Last updated on 2025-07-16 | Edit this page
Overview
Questions
- What is the purpose of this workshop?
Objectives
- n/a
Purpose
In a world where software is essential for nearly every aspect of modern life, the need for secure development have never been greater. However, many software engineers enter the workforce with limited knowledge or training on how to contribute to security during development without being security experts. In this workshop, you will learn about and participate in activities that software engineers can perform to make development more secure. These activities include:
- Identifying security risks
- Evaluating the trade-offs of addressing those risks
- Effectively communicating with other stakeholders about the problem.
This workshop is intended for research software engineers. Due to the diverse backgrounds an RSE can come from, we cannot speculate on your current security knowledge or expertise. Therefore, we assume you have limited knowledge of security. The good news is that this workshop is derived largely from the Developer Security Essentials workshop by Charles Weir. Developer Security Essentials aims to instruct software engineers on threat assessment and benefit analysis, requiring little security expertise. Other information in this workshop is informed by Charles Weir’s Secure Development Handbook. This handbook is a good reference guide for the topics of this workshop and contains additional topics you may find interesting.
“As someone working with developers and concerned about software security, you want the ‘how to do it’. Not the technical detail, but how you can change your professional approach and that of your colleagues to deliver adequate software security at a minimum cost. You reach for the dummies guide, and there’s nothing like that available. This book addresses that gap.”
Source: Secure Development Handbook
To start the workshop, we will play a card game called the “Agile Security Game.” This game does not require security expertise to play and motivates developers to start considering their own projects’ security and privacy requirements. We assume participants do not have a common project they can discuss, therefore an artifical project and its connections are supplied.
The next part of the workshop focuses on threat assessment and benefit analysis. In this activity, we explore the question “Who might do what bad thing to whom?” Similarly to the card game, an artifical project is supplied. This activity results in a list of identified threats to address. The next activity focuses on benefit analysis. In this activity, participants must make a case to “product management” about why they should address a given threat.
- Threat assessment and benefit analysis are both activities that developers can perform with little security expertise.
Content from Agile Security Game
Last updated on 2025-08-11 | Edit this page
Overview
Questions
- How do you play the agile security game?
- What are the outcomes of the game?
Objectives
- For each Agile sprint, discuss and agree amongst yourselves which stories to implemnt.
- Record your chosen sotries for that sprint (write down the code letters).
Player Instructions
We’ve got a problem. The app we released last week as apart of our researhc project has gone viral. People are downloading it by the tens of thousands; they’re all using it massively, and it’s received thousands of tweets and masses of mentions on every other social network. Even the Sunday newspaper has had an article on it.
Trouble is, we’re a small team and it was only supposed to be a limited pilot. We’ve put in only rudimentary security because we believed it under the radar for any of the likely attackers. But now we’ve got everyone from celebrities to my grandmother using it. AND IT’S NOT SAFE!
As the figure to the right shows, the functionality is all there and works well enough – fantastically done, team! Your mission now, should you choose to accept it, is to prioritise and implement the security enhancements to the system in the best way to minimise the threat to us and our users. Are you up for it?
It’s an agile project, of course, with two-week sprints. So each round in this game is a two week sprint. And for each sprint you have story cards with options you can take, and the estimated cost for each in estimation units. Some are security enhancements; some are test actions (the estimates include basic fixes that result from the testing); some are research activities which may lead to further tasks.
You have an initial budget for each sprint of 11 units, building up as you build up the team to 12 units for sprints 3 onwards; you can’t go over your budget and of course unused units don’t carry over the next sprint. You decide what you’ll do and the two weeks go by in a trice. And at the end of the sprint you’ll do a release of both app and server, and maybe get some new options opened up by the research you’ve done or the actions you’ve taken in the past.
And in the next sprint, and following sprint you do the same again. But remember – we also have a released product out there and maybe attackers will be DOING NASTY THINGS. Whether they’ll be successful or not depends on what decisions you made.
The game has some simplifications in timing. It ignores the time lag for getting apps from release to deployment. It assumes a stunningly agile team who can all move easily from server to app and from coding to reviewing to pen testing. And, remarkably, each task turns out to take exactly the effort estimated! So, you’ll get feedback on what NASTY THINGS have happened at the end of the sprint when you make each release.
For each sprint, discuss and agree amongst yourselves which stories to implement; record your chosen stories for that sprint (write down the code letters). The purpose and the learning of the game is in the discussion. Once the decisions are made, the game leader will feed back what has happened: any exploits seen during that sprint (of the code in the previous sprint’s release), and any new stories suggested by the learning from that sprint.
A Little Bit about Our App - MoodRing
We created “MoodRing” to enable participant mood-tracking in mental health studies. Here’s what I as a user can do with MoodRing:
- Report moods that I have experienced
- See my mood history
- Change my name, address and contact details
- Discuss with other app users
- Use the in-app analysis to find patterns in my moods
The MoodRing app communicates with an ‘App Server’, which itself is connected to a myriad of services related to storage, processing, and analysis as shown in Figure 2.
Sprints
Sprint 1
Using 11 points, pick the stories that will be completed this sprint.
Scanning Kiddie – gets to server by accident – maliciously deletes all data.
DoSing Kiddie – gets to server by accident – uses for ddos attacks on other servers
Scanning Kiddie – gets to server by accident – maliciously deletes all data.
- Backup Server (BS): Having a backup server containing a recent backup of our data makes recovering from this event easier.
- Server patches up to date (PT): Server updates often times inlcude security patches that address identified vulnerabilities and implement countermeasures.
DoSing Kiddie – gets to server by accident – uses for ddos attacks on other servers
- Server patches up to date (PT): Server updates often times inlcude security patches that address identified vulnerabilities and implement countermeasures.
Sprint 2
Using 11 points, pick the stories that will be completed this sprint.
Hacking Kiddie – gets to server by accident – downloads and publishes what he finds.
Phishing Kiddie – sends spam email, gets subscribers to download rogue version or enter credentials in spoof website.
Detective or journalist hacker – wants account information for specific users – server hack – publishes information or causes customer complaints.
Hacking Kiddie – gets to server by accident – downloads and publishes what he finds.
- Server patches up to date (PT): Server updates often times inlcude security patches that address identified vulnerabilities and implement countermeasures.
Phishing Kiddie – sends spam email, gets subscribers to download rogue version or enter credentials in spoof website.
- Contingency Plan (CP): Establishing a publicity plan with keeps the threat in the forefront of the teams mind and allows for faster notifications and warnings to users about phishing threats.
- Two Factor Authentication (2F*): Establishing two-factor identification helps defend users from phishing attacks and our app from compromised accounts.
Detective or journalist hacker – wants account information for specific users, hacks the server, and publishes information or causes customer complaints.
- Server Pen testing (PT) AND Encrypt and Hide data on server (EH*): External penetration testing (that includes server patching as well) can identify vulnerabilities in our app and patch them accordingly. Encrypting and hiding the data on our server prevents exposure of sensitive data in the event of a security breach or data leak.
* requires penetration testing
Sprint 3
Using 12 points, pick the stories that will be completed this sprint.
MITM kiddie – Spoofs WiFi access point in airport – Gains credentials – randomly hacks accounts.
Aggrieved hacker – gains access to server – downloads or modifies server data – publicizes.
(FATAL) MITM Mafia – spoofs WiFi access point in airport – uses dodgy root certificates to validate all banking services - gains credentials – steals small amount from each.
MITM kiddie – Spoofs WiFi access point in airport – Gains credentials – randomly hacks accounts.
- HTTPS in Protocol (HP): HyperText Transfer Protocol Secure utilizes encryption for secure communications over the network, thus protecting traffic between the device and the server.
- Two Factor Authentication (2F): Establishing two-factor identification helps defend users from phishing attacks and our app from compromised accounts.
Aggrieved hacker – gains access to server – downloads or modifies server data – publicizes.
- Server Pen Testing, AND Encrypt and Hide data on Server (PT, EH*): External penetration testing (that includes server patching as well) can identify vulnerabilities in our app and patch them accordingly. Encrypting and hiding the data on our server prevents exposure of sensitive data in the event of a security breach or data leak.
MITM Mafia – spoofs WiFi access point in airport – uses dodgy root certificates to validate all external services - gains credentials – steals personal information from each.
- Forced Upgrades and SSL Pinning (FU, SS): Mandating up-to-date app versions and binding authentication certificates to specific services would protect against MITM attacks like this one.
- Two Factor Authentication (2F): Establishing two-factor identification protects user credentials.
* requires penetration testing Text Fatal
Sprint 4
Using 12 points, pick the stories that will be completed this sprint.
Mafia Team – Gain access to office, get passwords from server logs, stealing data from tens of thousands of accounts.
Mafia Advanced Programming Team – gain access to server though zero day exploit, installed hacked version, modifies mood data.
Mafia APT - Malware on device via email – sends back credentials found in logs to command and control server – used to steal and modify data.
Mafia Team – Gain access to office, get passwords from server logs, small theft from tens of thousands of accounts.
-Prevent Access to Office (PA): Physical security of servers is just as critical as virtual! -Filtered Logging for Server (FL): Ensuring that logs do not contain sensitive or protected data helps prevent data leakage. -Two Factor Authentication (2F): Establishing two-factor identification protects user credentials and defends against unauthorized logins.
Mafia Advanced Programming Team – gain access to server though zero day exploit, installed hacked version, modifies mood data.
- Network Monitoring for Server (NM): Monitoring network traffic is an excellent way find and stop on-going attacks. In this case, an unexpected server patch could indicate malicious activity.
Mafia APT - Malware on device via email – sends back credentials found in logs to command and control server – used to steal and modify data.
- Forced Upgrades AND Sanitize App Logging (FU, SA): Keeping strict requirements on app-versions can detect or defend against disguised malicious malware. In this example, sanitizing logs wold prevent secret data from being discovered and leaked.
- Two Factor Authentication (2F): Establishing two-factor identification protects user credentials and defends against unauthorized logins.
* requires penetration testing
Text Fatal
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. These king of ‘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.
Also, 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.
- Choosing how to use your limited resources to increase security is difficult.
- Assess possible threats before they happen!
Content from Threat Assessment
Last updated on 2025-08-11 | Edit this page
Overview
Questions
- What process do I follow to identify threats?
Objectives
- Your group should identify some threats and discuss their risk and impact.
Introduction
You probably know that security is important. But how do you, as a developer, impact security? That first requires a different question: not how but what?
- What should you be worried about?
- What is likely to harm you, how would it happen?
- If it involves external attackers, what do they want, how might they go about getting it and how much do we care?
Finding the answers to these questions is called “Threat assessment” or “threat modelling.” In this activity, we will do a light-weight exercise to introduce you to the concept of threat-modelling.
Step 1: Discuss & Ideate
Who might do what bad thing to whom?
Person – Thing – Reason
Begin this section by thinking about the question above. Write down any combination of Person - Thing - Reason you can come up with on your worksheet. Feel free to write independently from the rest of your group.
Remeber that not every bad thing is malicious. Sometimes security or privacy issues happen due to accidents or misunderstandings. Discuss the issues amongst your group and gather as many completed threats as you can.
Step 2: Organize
Cluster the ‘post-its’ into ‘topics’ by posting related ones close together and duplicates on top of each other.
Step 3: Evaluation
This step identifies the most important threats.
- Pick the threats (post-its) that are (a) most likely, and (b) most damaging1.
- Place a black dot next to the each of the three you consider most likely;
- Place a red dot next to the three you think are most damaging.
Step 4: Summary
Using the risk-impact grid, place a selection of the threats onto their appropriate space.
This information will be used for the Benefit Analysis section!
The risk-impact grid is an inaccurate way to assess risks; however it is easy to understand and use. More sophisticated teams may well use better approaches, but these are outside the scope of this workshop.
- Not all “bad things” are malicious, sometimes accidents happen.
- Threats should be considered by their likeliness and impact.
Content from Benefit Analysis
Last updated on 2025-08-10 | Edit this page
Overview
Questions
- How do you communicate about threats?
- How do you justify which threats to address?
Objectives
- By completing this activity, you should be more knowledgeable on how to communicate with managerment/decision makers about threats.
Introduction
By this point, your group should have a risk-impact grid populated with the threats that your group came up with.
Single group workshops: Now you are going to choose 2-3 threats that you want to discuss.
Multi-group workshops: Now you are going to choose one threat that you want to discuss.
Your new mission is to make a case to Product Management to address the threat, using the board to explain your conclusions. This requires two things:
- A way to address the threat (a ‘mitigation’, in security jargon), ideally with an idea of the effort required, or a means to discover what effort is required. This only needs to be sketchy.
- The positive benefit to the organisation of addressing the threat. This often requires some ingenuity.
Multi-group workshops: Select one person to present your findings to all of the groups.
Post-Workshop Survey
SMART:
- S: Specific
- M: Measurable
- A: Achievable
- R: Realistic
- T: Timely
Please take the remaining time to fill out the post workshop survey.
At the end of the survey, it will ask you to write a letter to your future self on what kind of changes you plan to make to your work processes in response to this workshop. When writing this letter, consider writing SMART objectives.
- Information on a threat’s likelihood, impact, and cost to address are required to make informed decisions on which threats should be addressed.