Describe the bug

A threat is something that can go wrong with the current solution. It is something that in case of happening it would have an impact on the system. However, seeing the current interpretation of the Threat concept in these templates, one can see they are a little confusing since are treated as security controls. Below, I provide more details.

Naming and Describing Threats as Security Controls

Some custom threats included in these templates are redacted in a way of describing the security control that needs to be placed, instead of describing the threat.

Example

1. Take a custom threat like: "3f96bbf2-1d6e-4b20-9bca-8a413008595f" and see their title and description.
2. The title for that Threat is "Ensure that multi-factor authentication is enabled for all privileged users" plus their description is "Enable multi-factor authentication for all user credentials who have write access to Azure resources."
3. The title and description are referring specifically to implementing multi-factor authentication. A multi-factor authentication is a security mechanism which aims to prevents spoofing.

Expected behavior

Instead of describing directly what mechanism needs to be implemented in the Title and Description, describe what is the threat. The threat would be that someone is able to log in due to the application only relies on password authentication. The recommendations to handle that threat would be implementing an MFA.

Information Security and Privacy regulation as Threat properties

Information Security and Privacy regulations mandate to include specific controls across different processes at organization-level. Despite the controls required for regulations, a Threat not necessary impact them.

Example

1. Take as an example the Threat identified as: "TH100", its description says: "An adversary can execute remote code on the server through XSLT scripting".
2. This threat suggest that one need to include some kind of security control to prevent remote code execution through XSLT scripting. However, including a property in the threat like "HIPPA - Does this comply with HIPAA, the US legislation that sets standards for protecting the confidentiality and security of individually identifiable health information?" can be understood like preventing this threat would help us to comply HIPPA, which ultimately can be false. HIPPA does not refer precisely to any of the technologies to store information, it only specifies high-level requirements to protect privacy and security regarding health information.
3. Finally, I consider putting so many regulations as threats properties can deviate the attention from the real purpose of threat modelling: finding and handling threats.

Expected behavior

I think Information Security and Privacy Compliance analysis is different from making threat models. I would not merge both worlds, as it could extend so many the Threat Modelling process and wouldn't be useful as a Compliance Assessment at the end.