Discussion: to keep "Trusted service layer" requirements separately or combine them to one abstract

[elarlang]

"Trusted service layer" requirements

We have quite many "Verify that is done on trusted service layer."

Examples:

• V3.1.2 [ADDED] Verify that the application performs all session tokens verification using a trusted, back-end service.
• V4.1.1 Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.
• V5.1.6 [MOVED FROM 1.5.3, LEVEL L2 > L1] Verify that input validation is enforced on a trusted service layer.

We can add logging, business logic rules, or whatever here.

The question is - can/should we create one and more abstract requirement to cover them all?

From check-list point of view it may help someone if they are done separately.

[tghosth]

I think we need to be specific because this is frequently done wrong. However, we could also have an extra abstract which specifies that all security controls should be enforced at a trusted service layer

[elarlang]

It's a bit style question as well. Another example - should we have separate logging requirement for authentication, authorization, input validation, business logic, anti-automation etc, or we list them to one requirement (like we have direction at the moment). We should use the same style through the document.

[tghosth]

access control at an untrusted layer is a very common and well established issue which is why I think it deserves a specific call out. Something like logging can be more general

[mgargiullo]

So "Trusted Service Layer" is the updated term for "server-side". Would we, should we, have a dedicated section listing all things that should be assessed on the server-side?

I understand why the language was changed, but the root issues are still very similar. (data received from the client-side should be treated as dirty until proven otherwise)

I don't think splitting it into its own section makes sense, but highlighting where a requirement should be assessed may make sense.

(i.e., Access Control validation must occur on the trusted service layer (TSL) prior to interacting with services on the TSL)

We stress to our clients that client-side validation is only good for ease-of-use or UI helpfulness. All security control validation must occur on the Transport Service Layer.

[tghosth]

I think I would err on simple but clear requirements that stand alone. I would be open to an example where we mention the TSL as part of another requirement on the same topic but in the interests of simplicity I would be more inclined to not change too many requirements unnecessarily.