Threat Modeling
This guide is to help you run a security-focused discovery session. The goal is to get the team thinking about security upfront, not as an afterthought. At the end of a session, the team will add security-specific stories to the project backlog.
Preparation
If this is the first time you're running a security session, you'll want to allocate around 90 minutes. You want to give everyone enough time to get comfortable with the process. After a few sessions, the process should speed up considerably.
When running a security session, try to keep the scope of the discussion contained. For example:
- The next sprint or iteration, scope the conversation around the upcoming stories.
- A forthcoming security-sensitive feature.
- Re-evaluating an existing security-sensitive feature.
- Reviewing the continuous delivery pipeline.
Try to include more than just the technical team in these discovery sessions. Involving non-technical participants brings varied perspectives to the discussion and a shared understanding of the risks.
Explain & Explore
Ask, what are you building?
Draw a "lo-fi" technical diagram
To get started, draw out the components, actors, data flows, boundaries, & data stores involved with the feature or story you are assessing.
- Show the relevant components
- Place the users on the diagram
- Draw arrows to show data-flow
- Label networks and mark physical & logical boundaries
- Highlight important information & data stores
If gathering in-person, make sure to use a room large enough to host everyone comfortably. You'll need a large whiteboard, dry-erase markers, sticky notes, & pens.
When gathering online, you'll need an online whiteboarding tool that can mimic the in-person experience. DevFacto currently uses Mural for this purpose.
Brainstorm Threats
Ask, what can go wrong?
Capture threats on stickies
Use the diagram you just created to brainstorm possible threats. Post all ideas that you can think of around the diagram. Place your ideas as close to the relevant components as possible.
To help get the ideas flowing:
- Follow the data-flow lines on the diagram
- Use the STRIDE mnemonic
- Consider security risks from the business perspective, not just technical concerns
STRIDE
- Spoofed Identity: Can someone pretend to be someone with authority in the system?
- Tampering with Input: Can someone intercept & alter submitted information?
- Repudiation of Action: Can someone perform an action that the system cannot trace back to them?
- Information Discolsure: Can someone view information that they are unauthorised to see?
- Denial of Service: Can someone break the system with the intent of denying that system to valid users?
- Elevation of Privilege: Can someone grant themselves more access to the system than they should have?
Prioritise & Fix
Ask, what are you going to do about it?
Before the team starts to prioritise, review the ideas as a group. This process is not to debate or disqualify ideas, but to share useful knowledge and gain a shared understanding.
Next, it's time to prioritise.
- Each person has three (3) votes that they are free to distribute. You can place all your votes on a single item or spread them out as you see fit.
- Once all the votes have been cast, sort the threats by votes, and discuss the results.
- Write a set of the most critical threats, or all the threats, as stories and add them to your projects backlog. Use the votes to determine the priority.
Finally, aim to pull in one or several of these stories into your next projects iteration.
Continuous Improvement
Ask, how can we do even better next time?
Make sure to schedule a dedicated retrospective on the security session before too much time has passed.
- How useful was the security session?
- How can we improve the process the next time around?
Resources
This guide was based on the content outlined in A Guide to Threat Modelling for Developers.