Open zqu4rtz opened 8 months ago
I have to say that I agree with you. I was trying to model controls as threats, and you have laid out very clearly why they are different. In most instances I have used the remediation as the threat. Thank you for the time that you took to explain this clearly. I will tag you when I have come up with a more applicable model and would welcome your feedback. Thanks @zqu4rtz
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
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
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.