Align v1 Architecture with Threat Modeling Process and General Architecture and Drop All Duplicates

[jmanico]

In relation to:

https://github.com/OWASP/ASVS/issues/877 and https://github.com/OWASP/ASVS/issues/1031

I think all of v1 needs to stick with threat modeling and general architecture requirements and drop the technical duplicates and move them into a different section.

V1.1 looks ok, but I would like to split v1.1 into SDLC and Threat modeling as separate sections

I think all of v1.2 Architecture should move into v2 I think all of v1.4 Should move into the correct access control vx and that goes for the rest

This is a big change, need leads to comment here. cc @elarlang @vanderaj @tghosth @danielcuthbert

[elarlang]

I copy-paste my opinion (2021-05-06) from ASVS slack channel

Picking some phrases from https://github.com/OWASP/ASVS/blob/master/4.0/en/0x10-V1-Architecture.md

"Architecture is not an implementation, but a way of thinking about a problem"

From this point of view, I interpret:

• it is NOT something what you can check from actual implementation - with HTTP request, with watching program code or configuration
• it IS all about principles, working/implementation processes and documentation Now there are some things which can be both, like:
• 1.4.3 Verify enforcement of the principle of least privilege in functions, data files, URLs, controllers, services, and other resources. This implies protection against spoofing and elevation of privilege.
• 4.1.3 Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.

What could be the argumentation to have 2 too similar requirements? What is the use-case for 1.4.3?

Previously we made move from 1.5.3 "architecture" to 5.1.6 "implementation":

Verify that input validation is enforced on a trusted service layer.

Arguments: even it's in big picture architecture question, you can and need to check it from implementation. Another problem is that V1 category is "Level 2" category, but many requirements should be Level 1.

The question here is - do we need to have duplicates for "architecture" and "implementation" requirements?

Like requirement 1.5.4:

Verify that output encoding occurs close to or by the interpreter for which it is intended.

I can understand, it's principle and architecture question, but you can and need to check it from implementation.

For my taste there are quite many requirements in V1 category, which should not be there.

I propose that there should stay requirements like: Verify that

• some development, implementation etc processes and/or requirements are described
• something is identified and documented (like what is sensitive data for the application)
• some principles are described - but here it must be clear and different from "check the implementation" requirement

[elarlang]

V1 category should contain "inventory" requirements, which must give "pre-condition" data for testing "implementation requirements".

Examples:

• "sensitive data" - sensitive data must be defined, otherwise you can not test any requirement related with sensitive data
• "logs inventory" - you must have list of logs you expect, otherwise you can not test, do they exist and also, that there are no others logs
• "list of required connections to outside" - if an application needs whatever communication to external party, then it must be documented. only documented connections should be allowed
• etc...

[maizuka]

Suggestion about 1.1.6.

Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls. (C10)

It is included in architecture V1.1 but says "verify implementation." In addition, I can't find the origin in C10 and don't have an idea about what is the good way to meet or what is the anti-pattern of this requirement.

If there is no clear guidance on the architecture, how about removing this?

[tghosth]

@jmanico

I think the opposite. V1 currently contains SSDLC processes like threat modelling which I think should not be there. They belong in SAMM. To me V1 should have the basic principles underlying each individual section and if we cannot find enough content we should rethink it entirely.

[jmanico]

1. I am more than happy to drop all threat modeling, I am with you. It's a "soft" requirement that I will be glad to see go.

2. I want to see access control requirements ONLY in the access control section. The idea of putting an access control requirement in both section 1 and the access control section is, IMO, a very bad idea.

We are not completely in oposition Josh, we're getting close to agreement.

[tghosth]

ok so I think we need to think carefully about what if anything should be in V1 or whether we need to abolish it completely. I think maybe we need community input on this decision

[jmanico]

I vote to totally drop v1. It's not concise enough for us. They got SAMM to evaluate process.

[elarlang]

We still need some documentation requirements, without those you can not develop or security test another requirements.

[tghosth]

So our proposal is to keep V1 as some sort of basis but strip out all the process level requirements? @elarlang

[tghosth]

@elarlang do you remember if we wrote something somewhere about our philosophy for what should be in V1 or was it just the following?

So our proposal is to keep V1 as some sort of basis but strip out all the process level requirements? @elarlang

[elarlang]

Basically the philosophy at the moment are in comments: https://github.com/OWASP/ASVS/issues/1063#issuecomment-932719779 and https://github.com/OWASP/ASVS/issues/1063#issuecomment-939336985

[danielcuthbert]

For v1, yeah remove threat modeling for v2, removing it will be the hill I'm happy to die on, I think it really adds a lot of value and the tooling around threat modeling has changed so much since the awful days of stride/dread and clunky tools.

[tghosth]

I agree with the concept that V1 should contain documentation requirements.

As regards architectural requirements, I still think that having these in V1 makes sense from a building perspective because you need the architectural foundations to implement the actual requirements. I guess from the validation perspective it makes more sense to have them in the specific sections where they belong.

Do we have anything to say about V1 other than documentation requirements? I am not sure we should have process here at all...

@elarlang ?

[elarlang]

I prefer to keep implementation requirements away from documentation/security decisions requirements.

If to to give them more hilight, we can use *.1 subcategory for architecture requirements. But can you give an example, what is the problem or situation to solve here?

[tghosth]

My concept for V1 architecture requirements is things that are foundational to the application and will either have to be developed before the more specific controls are implemented or will require significant effort to retrofit. For example, having a consistent input validation architecture will be necessary before individual input validation controls can be implemented.

[elarlang]

Just documenting one idea / option to discuss: after V1 cleanup from implementation requirements, we probably have too few requirements for each sections and some sections are empty which may cause confusion.

So one option is: for each category, there are:

• VX.1 documentation requirements
• VX.2 architecture, principle and general requirements for the category

[tghosth]

Are you advocating to eliminate V1 entirely?

[elarlang]

For me, the trend is toward the idea written in the last comment. But let's see how many requirements we have in the V1 if we have cleaned it up.