Conducting effective Threat Modeling meetings
How to conduct threat modeling meetings effectively?
Prepare:
- Make sure that the participants have had enough context about the feature/component.
- Have about 3 reviewers who are NOT part of the component/feature team, to get an outsider’s perspective.
- Have an education session at least 3 days prior to the threat modeling meeting, to ensure that the reviewers who are not part of the feature team can be educated about the feature.
During the meeting:
- The driver should act as a scribe to capture comments.
- It is advisable to have a shorthand notation to take quick notes.
About the threat model itself:
- Although there is a lot of background information, it is good to focus on the entrypoints and assets.
- Ensure that every asset has at least one threat associated with it.
- Ensure that every entry point is associated to a threat.
- In the background information section, focus on external security notes and internal security notes.
- Typically the Internal security notes section is notoriously empty in a lot of threat models. To fill it, probe the feature team with questions like: “Have you found yourself getting the same security questions repetitively?”
Asset (Definition): An asset is anything that an attacker can perceive to have some value and tries to attack it. For most of the features, consider Execution Context as an asset. Don’t sweat too much on Entry points.
Mitigation: During the threat modeling meeting or after?
It is good to spend a limited amount of time in discussing the mitigation, right after identifying the threat.
Do not confuse threats with vulnerabilities. All threats must be described as: The attacker does the following…Draw a clear distinction among the threats that are mitigated, not mitigated or partially mitigated.
Do not list imaginary threats in the threat models. An example of an imaginary threat would be: If there is a bug in the code, then following is our course of action.
Buffer overrun: It can never be completely mitigated.
Always describe the mitigations planned by the test and dev team, for buffer overruns.
These points are based on my conversations with Al Comeau, Michael Howard, Maithili Dandige, RobAnn Mateja and Subu Subramanian.
