move configuration related requirements from V1 to V14.6

[elarlang]

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

#	Description	L1	L2	L3	CWE
1.2.2	[MODIFIED] Verify that communications between back-end application components, including APIs, middleware and data layers, are authenticated and use individual user accounts.		✓	✓	306
1.14.1	[MODIFIED] Verify the segregation of back-end components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms.		✓	✓	923
1.14.7	[MODIFIED, MOVED FROM 1.2.1] Verify the use of unique or special low-privilege operating system accounts for all back-end application components, services, and servers.		✓	✓	250

[tghosth]

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?

[jmanico]

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:

1.2.2	[MODIFIED] Verify that communications between back-end application components, including APIs, middleware and data layers, use active sessions of individual user accounts.		✓	✓	306

[jmanico]

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.

I agree. For severals reasons I think 1.14.1 can go.

[jmanico]

I think 1.14.7 should be moved to v14, it's definitely a configuration requirement.

[elarlang]

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.

How is the requirement to ask individual user accounts for application components related to application session management?

[jmanico]

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.

[elarlang]

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. :)

[jmanico]

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.

:)

[meghanjacquot]

I think that 1.2.2 and 1.14.7 make sense in V14.

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?

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.

If 1.14.1 is out of scope removal makes sense to me.

@meghanjacquot @jmanico what do you think?

[elarlang]

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

Verify that communications between back-end application components, including APIs, middleware, and data layers, are authenticated and use individual service accounts.

[tghosth]

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 :)

[tghosth]

However, based on another discussion we had related to V4, I have made the following modification to the new 14.6.4:

#	Description	L1	L2	L3	CWE
14.6.4	[MODIFIED, MOVED FROM 1.2.2] Verify that communications between back-end application components, including APIs, middleware and data layers, are authenticated and use either the original user's session or individual service accounts.		✓	✓	306

[jmanico]

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.

[jmanico]

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)

[tghosth]

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.

So this is the kind of complication I would prefer to abstract away for service to service issues :)

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)

I have alluded to this in the updated requirement that I copied above.

[jmanico]

Then I suggest we drop the service account part and aim for something like:

14.6.4	[MODIFIED, MOVED FROM 1.2.2] Verify that communications between back-end application components, including APIs, middleware and data layers, are authenticated using some form of intra-service authentication that is independent of individual user sessions.		✓	✓	306

[tghosth]

@jmanico in your proposal do we not lose this element?

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)

[jmanico]

Or if you want a manicode-beefy(tm) version I would actually suggest:

14.6.4	[MODIFIED, MOVED FROM 1.2.2] Verify that communications between back-end application components, including APIs, middleware, and data layers, are authenticated using strong intra-service authentication mechanisms, such as mutual TLS, OAuth tokens, or signed JWTs, which are independent of individual user sessions. Ensure that these mechanisms include secure key management, regular credential rotation, and audit logging to detect unauthorized access, and are implemented following the principle of least privilege to minimize attack surface.		✓	✓	306

[jmanico]

@jmanico in your proposal do we not lose this element?

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)

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.

[jmanico]

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. | | ✓ | ✓ |
-- | -- | -- | -- | -- | --

[elarlang]

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.

[jmanico]

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".

14.6.4	[MODIFIED, MOVED FROM 1.2.2] Verify that communications between back-end application components, including APIs, middleware, and data layers, are authenticated using strong intra-service authentication mechanisms, such as mutual TLS, OAuth tokens, or signed JWTs, which are independent of individual user sessions. Ensure that these mechanisms include secure key management, regular credential rotation, and audit logging to detect unauthorized access, and are implemented following the principle of least privilege to minimize attack surface.		✓	✓	306

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.		✓	✓	306

[elarlang]

Also, stay in topic. If the discussion here was about 3 requirement, please open separate issues for separate topic or proposals.

[jmanico]

I'll propose 3.5.8 in a new issue and drop it from this conversation. I'm with you Elar. See #2079

[jmanico]

So there are two suggestions for clarifying 1.2.2

(beefy)

14.6.4	[MODIFIED, MOVED FROM 1.2.2] Verify that communications between back-end application components, including APIs, middleware, and data layers, are authenticated using strong intra-service authentication mechanisms, such as mutual TLS, OAuth tokens, or signed JWTs, which are independent of individual user sessions. Ensure that these mechanisms include secure key management, regular credential rotation, and audit logging to detect unauthorized access, and are implemented following the principle of least privilege to minimize attack surface.		✓	✓	306

or

(less beef)

14.6.4	[MODIFIED, MOVED FROM 1.2.2] Verify that communications between back-end application components, including APIs, middleware and data layers, are authenticated using some form of intra-service authentication that is independent of individual user sessions.		✓	✓	306

[jmanico]

... and since this is setting up service authentication, which is complex, I'd rather see this as 2.10.4 under the "V2.10 Service Authentication" section. So my final proposal here is:

2.10.4	[MODIFIED, MOVED FROM 1.2.2] Verify that communications between back-end application components, including APIs, middleware, and data layers, are authenticated using strong intra-service authentication mechanisms, such as mutual TLS, OAuth tokens, or signed JWTs, which are independent of individual user sessions. Ensure that these mechanisms include secure key management, regular credential rotation, and audit logging to detect unauthorized access, and are implemented following the principle of least privilege to minimize attack surface.		✓	✓	306

[tghosth]

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.

I agree that we are mixing them and that it becomes confusing.

I'd rather see this as 2.10.4 under the "V2.10 Service Authentication" section.

I also agree with this as I think it is the original intention of the requirement to focus on components that we did not specifically build and therefore do not support our user session mechanism.

I think the "beefy" requirement is too large so I would suggest the following:

#	Description	L1	L2	L3	CWE
14.6.4	[MODIFIED, MOVED FROM 1.2.2] Verify that communications between back-end application components which don't support the applications standard user session mechanism, including APIs, middleware and data layers, are authenticated and use individual service accounts.		✓	✓	306

[elarlang]

If current 1.2.2 should to go 2.10 service authentication, then it makes sense to create also "4.4 service authorization" and move 1.14.7 (v4.0.3-1.2.1) and 14.6.2 (... potential duplicate to 1.14.7 - #2082).

... or we will move those under current "Configuration" (the title can be widened) sections as "V14.X service authentication" and "V14.Y service authorization". Why I would like this - those sections are different from the application end-user authentication and authorization (It is not a clear proposal, it is described as one option)

[jmanico]

I would just suggest we drop the service account term because it’s only one of a few types of intra-service authentication.

[elarlang]

Update - as there is a lot of discussion on topic and off-topic, I make an update.

Proposed to move requirements:

• 1.2.2 - requirement text is under discussion (last proposal move configuration related requirements from V1 to V14.6 #2072 (comment)))
  • the question is, to move to V2.10 or to V14.6
• 1.14.1 - removed as out of scope (remove 1.14.1 as out of scope #2083)
• 1.14.7 - agreed to move to V14.6, but if authentication requirements end up in V2.10 "service authentication", it could be aligned to have such section for authrozation as well (move configuration related requirements from V1 to V14.6 #2072 (comment))
  • Let's handle the 1.14.7 requirement and it's location in the other issue, as the requirement itself may be duplicate of 14.6.2 (see deduplicate or merge 14.6.2 and 1.14.7 #2082)

So the focus for this issue is only the wording and the section choice for 1.2.2

[tghosth]

So my suggestion was:

#	Description	L1	L2	L3	CWE
1.2.2	[MODIFIED] Verify that communications between back-end application components which don't support the applications standard user session mechanism, including APIs, middleware and data layers, are authenticated and use individual service accounts.		✓	✓	306

At this point, I wonder if we have missed the obvious option which is to merge this into 2.10.1:

#	Description	L1	L2	L3	CWE	NIST §
2.10.1	Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.		✓	✓	287

There is a long unresolved discussion on 2.10.1 here:
#1032

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?

[tghosth]

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

[elarlang]

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.

[tghosth]

@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

[octo-reminder]

⏰ Reminder
Thursday, September 19, 2024 12:00 AM (GMT+02:00)

@tghosth to come up with a proposal to merge 1.2.2 and 2.10.1.

[jmanico]

I can see why this is a configuration item but as started below I think the term “service account” is too specific.

[octo-reminder]

🔔 @tghosth

@tghosth to come up with a proposal to merge 1.2.2 and 2.10.1.