-
-
Notifications
You must be signed in to change notification settings - Fork 662
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
move configuration related requirements from V1 to V14.6 #2072
Comments
I think that 1.2.2 and 1.14.7 make sense in V14. I think that 1.14.1 is explicitly talking about components that are no in scope for ASVS so I would support removing this requirement. @meghanjacquot @jmanico what do you think? |
I think that 1.2.2 is more of a session management requirement (v3) that a configuration requirement (v14). 1.2.2 is about session management (and not authentication) architecture. So I suggest move 1.2.2 to v3 and change it so say:
|
I agree. For severals reasons I think 1.14.1 can go. |
I think 1.14.7 should be moved to v14, it's definitely a configuration requirement. |
How is the requirement to ask individual user accounts for application components related to application session management? |
Session Context: The verification emphasizes ensuring that authenticated communications use individual user accounts, implying that there is a mechanism in place for managing user-specific sessions or credentials. This aligns with session management, where individual user identities and their associated permissions are tracked and used to authenticate actions across various components. Authentication and Identity: The focus is on authenticating communications and ensuring that individual user accounts are used. Authentication is a core aspect of session management, as it directly impacts how user sessions are created, maintained, and validated across distributed systems. Dynamic Authentication: In a microservices or distributed architecture, authenticated communication often relies on session tokens, OAuth tokens, or similar mechanisms tied to a user's session. The requirement to use individual user accounts in these back-end communications points to a session-driven model, where session tokens (rather than static configuration settings) dictate access and communication rules. While configuration plays a role in setting up the security mechanisms, such as defining authentication protocols or ensuring encryption between components, the active authentication and management of individual sessions is what places this more in the session management domain than in static configuration. |
You can tell to AI that the context is to have a bit of separation to "application logic session" for end users and authentication between underlying application components. :) |
My AI overload then says to you : "Then you need to do a better job in this requirement with a more clear distinction between the application logic session for end users and the authentication between underlying application components" It's the "use individual user accounts" that makes me think of session management. If you talking intra-service security (with things like mTLS and similar) then these would not be user accounts, they would be service accounts. :) |
Moving 1.14.7 to be in 14.7 makes sense as well due to the verification part with servers. With Jim's modified language, in this comment, I can see where 1.2.2 would be best placed into V3. If the emphasis is on "active" than maybe V3.3 would be best?
If 1.14.1 is out of scope removal makes sense to me.
|
Oeh. There is no session context. It was Jim's AI confusion. The requirement is at the moment in 1.2 which is "V1.2 Authentication Architecture" Current 1.2.2 will get modification and will be moved to V14.7
|
A bit of rough and tumble in this thread but I think Jim correctly pointed out that this requirement was a little confusingly worded as I agree with Elar's interpretation of the requirement and so for that reason I think this should be in V14. I think we all agree once we all understand each other so I will open a draft PR but will request approval from all 3 of you before it gets merged :) |
However, based on another discussion we had related to V4, I have made the following modification to the new 14.6.4:
|
This topic is way more than service accounts and has nothing to do with users sessions. Setting up authentication for intra-service security is not at all easy. Sometimes you just use mTLS. Sometimes you use tokens and OAuth tech. You might need integration with key managers. You need to set up least privilege access. You need to handle token rotation. I can see this topic in v14 (Configuration), Crypto (v6), Authentication(v2), Session Management (v3) and more. I do admit if you are using a modern service like Istio, it's more in v14. But intra-service authN is way more complex that just configuration and requires quite a few steps to set up right. I lean to putting this in V2 - Authentication or V3 - Session Management. PS: This post was approved by my AI overlord. |
As a side note I think the users session (typically a JWT) should still be propagated server-to-service regardless of how you do intra-service security. (ie the "Pass the Jot" session pattern) |
So this is the kind of complication I would prefer to abstract away for service to service issues :)
I have alluded to this in the updated requirement that I copied above. |
Then I suggest we drop the service account part and aim for something like:
|
@jmanico in your proposal do we not lose this element?
|
Or if you want a manicode-beefy(tm) version I would actually suggest:
|
I think the idea of "passing the session all the way down the pipe of various services" should be an independent v3 requirement and it's a super important one. |
And regarding pass the JWT I suggest a V3 requirement along these lines: 3.5.8 | [ADDED] Verify that user session tokens, such as JWTs, are securely propagated between services as part of service-to-service communication, ensuring that session tokens are validated at each service layer. | | ✓ | ✓ | |
I see it as 2 layers: service-to-service and user-to-service. I think you mix them and/or miss the service-to-service layer. Example: the database user for the application is unique for the application and not shared with n+1 other applications. |
I agree @elarlang so I suggest 14.6.4 stick to service-to-service auth, and a new 3.5.8 that discusses "pass the JWT".
|
Update - as there is a lot of discussion on topic and off-topic, I make an update. Proposed to move requirements:
So the focus for this issue is only the wording and the section choice for 1.2.2 |
So my suggestion was:
At this point, I wonder if we have missed the obvious option which is to merge this into 2.10.1:
There is a long unresolved discussion on 2.10.1 here: At this point I would suggest we reference 1.2.2 in that discussion and don't try and and deal with it here. @jmanico @elarlang @meghanjacquot what do you think? |
I do wonder though whether for communication between services that is outside our standard authentication/session management mechanism we should move it all to configuration as that we have less control over the specifics but rather it becomes a config question |
... which was my exact reason to propose this move. |
@set-reminder tomorrow @tghosth to come up with a proposal to merge 1.2.2 and 2.10.1. The decision to move to V14 should then move to #1032 |
⏰ Reminder
|
I can see why this is a configuration item but as started below I think the term “service account” is too specific.
|
These are the suggested contents of 1.2.2 and the actual contents of 2.10.1. I would suggest merging these as follows and then dealing with the update to 2.10.1 in issue #1032
|
I'm not really fan of this merge, and also not a fan to say, that password for database connection for a level 2 application is not acceptable. |
Password-only controls for production database access are fairly low security and pose a significant security risk. I typically suggest network controls and network segmentation for all production databases, even for level 1 applications, given the historical vulnerabilities and misconfigurations in database software.
I also strongly recommend discouraging password-only authentication for any production database systems.
|
The requirement says:
So I think this is inline with what you are saying, no? |
Politely, no. Other options like short term tokens or certificates are just as valid as service accounts. I think the term "service accounts" is way too specific. |
Ok so as an alternative:
@jmanico what do you think? |
I like it 👍🏼
|
@set-reminder in 2 days @tghosth to open PR |
⏰ Reminder
|
For updated situation, jump here: #2072 (comment)
For V1 cleanup from implementation requirements (#1063) I propose to move those requirements to V14.7 Web or Application Server Configuration
The text was updated successfully, but these errors were encountered: