4.3.1 and 4.3.3
EnigmaRosa opened this issue · comments
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 |
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 #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.
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?
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
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...
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 (#1352 (comment)):
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
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.
I agree with what @jmanico proposed
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