1.1.2 Threat modeling should be rephrased to cover different levels

[suvikaartinen]

[1.1.2][Verify the use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appropriate risk responses, and guide security testing.] (https://github.com/OWASP/ASVS/blob/master/5.0/en/0x10-V1-Architecture.md#v11-secure-software-development-lifecycle)

Threat modeling is a corner of SDL and it should happen on some level on all levels. For example: Verify that threats have been identified for external attack surface (L1)/whole design architecture (L2)/whole design architecture including external dependencies and all design changes (L3)

[suvikaartinen]

Also on L3 threat modelling should utilize some formal method such as STRIDE

[tghosth]

@set-reminder 3 weeks @tghosth to look at this

[octo-reminder[bot]]

⏰ Reminder Wednesday, December 28, 2022 12:00 AM (GMT+01:00)

@tghosth to look at this

[tghosth]

I think this requirement should be dropped entirely as not being in line with the standard as a whole.

There seems to be support for this based on #1460 and #1461 and @jmanico's often repeated opinion seems to be:

I think all of these non-technical requirements should go away. Too abstract.

@elarlang what do you think? Should I open a PR :)

[danielcuthbert]

I agree that the wording isn't right but I'm loathed to drop TM'ing from the standard given the numerous benefits so many get when performing it. What is probably needed more is clarification on how and what and why one should be adopting threat modelling.

[octo-reminder[bot]]

🔔 @tghosth

@tghosth to look at this

[tghosth]

I think this got dropped in the end because it is a process rather than a security mechanism/control

[tghosth]

Ok this item didn't get deleted, I must have been mistaken.

I reiterate that this is a security process rather than a security requirement of an application and therefore I think it is out of scope for ASVS and should therefore be deleted.

@elarlang what do you think?

[elarlang]

This requirement or threat modelling requirement in general is on @danielcuthbert

[tghosth]

@danielcuthbert I think we need to remove this, threat modeling is an activity whereas ASVS should be practical requirements for an application

[elarlang]

Threat modeling can exist in format: "Verify that you have TM documented" + "Verify that you have TM implemented".

Most likely it can be part of other requirements like

#	Description	L1	L2	L3	CWE
1.1.5	Verify definition and security analysis of the application's high-level architecture and all connected remote services. (C1)		✓	✓	1059
1.11.1	Verify the definition and documentation of all application components in terms of the business or security functions they provide.		✓	✓	1059
1.14.1	Verify the segregation of components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms.		✓	✓	923

[jmanico]

I would suggest if you really want Threat Modeling ASVS, then at least keep 1.1.2 but drop 1.1.4, 1.1.5 and other requirements that tell me how to do threat modeling per: https://github.com/OWASP/ASVS/issues/1541

[elarlang]

Revising the issue.

Threat Modeling is certainly useful and must have for analyzing risks, but it is outside of the ASVS scope.

What we will have in the scope of ASVS, is some outcome from threat modeling - but those are precise questions like "Verify that there is an allow-list defined for validating Y functionality."

We can not have a requirement like "Verify that you have Threat Modeling." It is not actionable and it is not part of the application (as a product).

So, if @danielcuthbert will not come up with really good arguments to keep it (aligned with ASVS scope), we will delete the requirement as "out of scope".

[elarlang]

If there is no feedback, I'll make PR on the 12th of December (2023)

[danielcuthbert]

This gets my support. It was put in during a different time and I 100% agree that it isn't actionable anymore.