About 1.1.6

[teavanist]

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

I have two questions regarding 1.1.6:

Section: V1 Architecture, Design and Threat Modeling

https://github.com/OWASP/ASVS/blob/master/5.0/en/0x10-V1-Architecture.md

q1) This basically means that the organization has to make a list of security controls that developers can then follow. What are some common security controls thats referred to in this? I am assuming it could mean things like approved libraries, the approach developers must follow for authentication, authorization, etc. Is this correct?

q2) Are there other examples or guidance for someone looking to implement this? esp the part around centralized security controls?

[elarlang]

Requirement 1.1.6:	#	Description	L1	L2	L3	CWE
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)		✓	✓	637

CWE 637 points to "Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism')"

For me it basically means - for the same action, in different places in code base, different solution are used for the same thing or the same solution is copy-pasted everywhere.

First thing comes to my mind is curl calls in PHP application, I have seen them duplicated many times. Another one is authentication and authorization decisions, but for those we have separate requreiments (current V1.2.3, V1.4.4)

#	Description	L1	L2	L3	CWE
1.2.3	Verify that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches.		✓	✓	306
1.4.4	Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths. (C7)		✓	✓	284

Please let me know it helped, or there is some problem to solve or proposal to improve.

[teavanist]

Thanks! What caused the confusion I think was that the control text is quite different from CWE 637. When I read the control it looks to me that "simplicity" (as explained in CEW637) is just one of the items that we need to verify. Since the scenario you mention is very specific, wouldnt it be better to rephrase the recommendation to: Verify during code review that for the same action, in different places in code base, different solution are not used or the same code is not copy-pasted. All such actions should call a common code. or something similar?

[tghosth]

I am going to mark this for the major rework of V1 as I don't think it can be considered in isolation

[elarlang]

In case the category V10 is "widened", I propose to move this requirement as an "architecture" requirement there.

[tghosth]

Elar's perspective is that 1.1.6 requires code access to really verify it which is why it fits in well with V10 which is becoming more about code level considerations.

My perspective is that 1.1.6 is absolutely foundational to everything in ASVS to the extent that I am not sure if it should actually be a requirement but rather a mindset/condition for you implement/verify security requirements.

On the other hand, as Elar says you can't verify this without code access. Maybe we need levels of verification in terms of what is actually being checked for each requirement...

[jmanico]

I appreciate the efforts of penetration testers in identifying potential security risks.

However, I believe their expertise is more effectively utilized in highlighting actual vulnerabilities rather than critiquing code design choices, such as the use of multiple libraries for similar functions. In many cases, these design decisions are made with specific considerations in mind.

I suggest we concentrate on directly verifiable security issues. While code design is undoubtedly important, it's essential to distinguish between pure design preferences and actual security vulnerabilities. This approach will allow us to focus more on strengthening ASVS in a way that's both efficient and effective instead of straying into design issues that may or may not be security issues.

[elarlang]

I share Jim's point of view here.

From a developing perspective - it is fundamental, it is a mindset question, it is common sense, etc.

But from a security verification perspective - if you have crappy code, with awful style, but without security holes - what do you report? :)

Although it's a fundamental from development perspective, it is a bit coding style question from application security perspective.

In other words, @tghosth - for me it's actually easy move to V10 as architecture requirement.

[csfreak92]

Yeah, this is hard to verify without code access and I agree with Elar and Jim's points on this as well. Moving it to V10 works as well since that chapter deals with code, but cannot think of the best fit for the subsection yet, maybe we need to create a subsection about high-level architecture requirement to fit this in?