4.3.1 and 4.3.3

[EnigmaRosa]

Addressing #1352 Q7:

Q7 - 4.3.1, 4.3.3 - are those actually authentication requirements?

While 4.3.1 is relevant to access control - as access to the admin interface can enable changes to user permissions - I would argue that this is an authentication issue, not an access control one. Furthermore, the language surrounding "administrative interfaces" should be clarified, as I've seen users interpret it as admin interface for a single corporate instance (in a multi-tenant SaaS app).

I'm also inclined to argue that 4.3.3 doesn't belong in V4, and likely in authentication.

#	Description	L1	L2	L3	CWE
4.3.1	[MODIFIED] Verify administrative interfaces can only be logically accessed from trusted endpoints or locations. For example, restricting access to bastion or jump hosts, trusted admin workstations or endpoints (e.g., device authentication), administrative LANs, etc.	✓	✓	✓	419
4.3.3	[MODIFIED] Verify that, if the application allows changing highly sensitive configurations around passwords or connection parameters for integrations with databases and third-party systems, they are protected by extra controls such as re-authentication or multi-user approval.		✓	✓	732

[elarlang]

Q7 - 4.3.1, 4.3.3 - are those actually authentication requirements?

So the quote is from me. When I watch updated requirements, I don't think the authentication is suitable for those, as the responsibility or the goal is not identifying the user.

Some thoughts:

• 4.3.1 - as it is not under "application permission" logic and is/can be external, outside of application solution, we can watch it also as some kind of configuration
• 4.3.3 - it's authorization + logic for specific case, in a way related discussion https://github.com/OWASP/ASVS/issues/1576
  • re-authentication in the requirement is used as a tool for authorization, but the goal for the requirement is not related about procedure of identifying the user

In summary: if we don't find a clear better place, I'm ok when they stay where they are.

[EnigmaRosa]

I understand. For 4.3.1, placing in configuration might be the best option, as well as having clarifying language. Is Business Logic perhaps a more suitable location for 4.3.3?

[elarlang]

Improving the wording is always an option, but those requirements have seen some journeys already :)

As both requirement were modified after the last release, it makes sense to review the reasons how those reached to the current wording

• 4.3.1
  • https://github.com/OWASP/ASVS/issues/1591
  • https://github.com/OWASP/ASVS/issues/1086 - it was not a sprint here
• 4.3.3
  • https://github.com/OWASP/ASVS/issues/1437

Is Business Logic perhaps a more suitable location for 4.3.3?

I think we should wait for the outcome from #1576 - if it results with a separate requirement, we need to be sure those are different enough and maybe it makes sense to put them together somewhere (most likely business logic), otherwise, it may rise question why we have 2 really similar requirements in different places. But, we need to have the other requirement first...

[elarlang]

One more note, if to take direction that 4.3.1 will be moved to configuration section, then we can move 1.4.6 as well, as it is not about application authorization logic (https://github.com/OWASP/ASVS/issues/1352#issue-1352215924):

Q5 - 1.4.6 - would be nice to move this requirement to somewhere "configuration hardening" category, to keep separately access control issues for users and for internal components

[jmanico]

I agree that 4.3.1 and 4.3.3 are not access control design requirements. I suggest:

• 4.3.1 - I like the suggestion from @elarlang that this one should be moved to the architecture section (AuthN or AuthZ).
• 4.3.3 - I think this would fit nicely into the configuration section.

[EnigmaRosa]

I agree with what @jmanico proposed

[mesutgungor]

4.3.1 : More Access Control Context not Authentication : Defines the attribute based access control (location and device) 4.3.3 : We can split this into two

• Authentication Context : Where user must re-authenticate to perform senstive action if we think sole end-user,
• Configuration Context : Securing configuration changes by adding multiple layer such as multi-user approval or mult-factor authentication

[EnigmaRosa]

@tghosth @elarlang I propose that 4.3.3 be moved to 1.14 (configuration architecture). As for 4.3.1, we clarify the language in order to make the connection to access control more obvious - "Verify that access to administrative interfaces is tied to user attributes indicating access from a trusted endpoint or location. For example, restricting access to bastion or jump hosts, trusted admin workstations or endpoints (e.g., device authentication), administrative LANs, etc."

[elarlang]

I propose that 4.3.3 be moved to 1.14 (configuration architecture).

V1 seems to be some magic place where everyone want to put requirements away from their sight :) But V1 will be cleaned up. I'm going to re-use my comment: Note that V1 is for documentation requirements only and is under clean-up process for everything that are not documentation requirements. Most likely all requirements from V1 will end up as separate section into the related category. In short, moving thing to V1 is not a solution here till those are not clear documentation requirements.

After changes with 4.3.3, I would say it is quite clear V4 requirement - it is implementation requirement (not documentation, not architecture principle, not configuration). Next closest chapter is V14.6 Web or Application Server Configuration, but there I would like to see only requirements that are clear configuration on the web server or, without application logic involved. So for me, moving current 4.3.3 there is not that clear case.

As for 4.3.1, we clarify the language in order to make the connection to access control more obvious - "Verify that access to administrative interfaces is tied to user attributes indicating access from a trusted endpoint or location. For example, restricting access to bastion or jump hosts, trusted admin workstations or endpoints (e.g., device authentication), administrative LANs, etc."

Pretty much the same story as with 4.3.3.

I'm kind of back in the beginning, it is not big problem to solve and I'm ok if those requirements stay where they are.

I think it we should just rename "V4.3 Other Access Control Considerations" to be more descriptive and we don't need to move those requirements anywhere.

[EnigmaRosa]

@elarlang I can get on board with renaming V4.3. First, how do you feel about the re-word for 4.3.1?

[elarlang]

First, how do you feel about the re-word for 4.3.1?

Current 4.3.1:

Verify that access to administrative interfaces is tied to user attributes indicating access from a trusted endpoint or location. For example, restricting access to bastion or jump hosts, trusted admin workstations or endpoints (e.g., device authentication), administrative LANs, etc.

Proposed 4.3.1:

Verify administrative interfaces can only be logically accessed from trusted endpoints or locations. For example, restricting access to bastion or jump hosts, trusted admin workstations or endpoints (e.g., device authentication), administrative LANs, etc.

I would say it is just a wording change and no actual difference. So I don't mind the wording.

I'm a bit worried, how this requirement is aligned with Zero Trust mindset.

[EnigmaRosa]

What are your concerns?

[jmanico]

I share in @elarlang concern that this requirement is not very zero trust. Relying on network location or similar is very anti zero-trust. How about:

Verify that access to administrative interfaces is controlled based on continuous verification of the user's identity, device security posture, and context, irrespective of the user's location or network. For example, requiring device authentication, multifactor authentication, and contextual risk signals, rather than relying solely on access from predefined trusted endpoints.

[elarlang]

To be clear with that - I don't say that limiting access (for example) to local network is wrong thing to do, I say that you can not only rely on that. So it can be configuration hardening factor to take down the likelihood, but it can not be authorization factor.

[jmanico]

How about:

4.3.1	[MODIFIED] Verify that access to administrative interfaces incorporates multiple layers of security, including continuous user identity verification, device security posture assessment, and contextual risk analysis, ensuring that network location or trusted endpoints are not the sole factors for authorization.	✓	✓	✓	419

[elarlang]

From the authorization decision point if view, being aligned with zero trust, we should not rely on network segment for authorization decisions. This is covered with latest proposal by Jim.

What I don't want here as a side-effect - it's kind of sending a message, that limiting accessing admin interface to internal network only is a bad thing to do. It is not! It is really cost-effective and simple way to take down likelihood of the attacks from the internet. Just when you are in the internal network, you can not be automatically authorized to do some actions.

So I think we need one clear separate requirement in the V14 "configuration hardening" section to cover that and send a clear message "take down the likelihood, but do not make authorization decisions".

[jmanico]

4.3.1 was resolved here. https://github.com/OWASP/ASVS/pull/2291

We just need to address 4.3.3

[jmanico]

How about this for 4.3.3 to it only deals with high risk features:

Verify that high-risk features, such as large money transfers or contract approvals, are secured through multi-user approval processes. Ensure that these features require authorization from multiple approved users before execution, reducing the risk of unauthorized or accidental actions that could lead to significant financial or operational impact.

[ImanSharaf]

Nuclear Facility Operations: Access to certain areas within nuclear sites or initiating critical processes such as the activation of reactors or shutdown procedures should require multi-user approval to prevent unauthorized or accidental actions.

Healthcare Systems: Accessing or modifying sensitive patient health records, particularly for high-profile patients, could require multi-user verification to ensure data integrity and privacy.

Banking and Finance Systems: Approval for large monetary transfers or high-value transactions, especially across borders, should involve multiple users to ensure security against fraud.

Government or Classified Information: Accessing or sharing sensitive government data, like military operations details or classified intelligence, could be restricted to those with multi-level clearance and require multi-user confirmation.

Manufacturing Plant Safety Overrides: For high-stakes manufacturing environments (like chemical plants), bypassing safety protocols or making adjustments to critical equipment settings could need multi-user approval to prevent accidents.

[jmanico]

How about:

Verify that high-risk features such as large monetary transfers, contract approvals, access to critical nuclear facility operations, healthcare record modifications, access to classified information, or safety overrides in manufacturing—are restricted with multi-user approval to prevent unauthorized or accidental actions.

[tghosth]

4.3.3 was moved to v14.7 in #2299 and a separate new req was created in #2296 so I think we can close this now