Review requirementes 14.2.6 and 14.2.8, potential move to V10

[elarlang]

Spin-off from #2088 / the discussion over 14.2.6 and/or 14.2.8 comes from #1425.

Current requirements:

#	Description	L1	L2	L3	CWE
14.2.6	[MODIFIED, SPLIT TO 14.2.8, LEVEL L2 > L3] Verify that risky third party libraries or those with a history of vulnerabilities are encapsulated such that only required behaviour is available to the application, to reduce attack surface.			✓	1061
14.2.8	[ADDED, SPLIT FROM 14.2.6] Verify that risky third party libraries or those with a history of vulnerabilities are sandboxed away from the most sensitive system modules/services so that even if a vulnerability in the library was successfully exploited, the sensitive system modules/services would not be compromised.			✓	1061

The need for those requirements are questioned for example in comments:

• Are parts of 14.2.x section out of scope for ASVS? #2088 (comment)
• Item number 14.2.6 needs to be revised  #1425 (comment)

For me the "main error" is, if we talk about L3 requirement, then those application can not use any "too risky" and not trustful component anyway.

By content, both are more "software architecture" requirements, not a clear configuration requirements. Most likely we need a chapter for V10 for that, something to say "Software Architecture" or "Sandboxing".

[jmanico]

These are great requirements. Well done. ** Revised Oct 23: I think we should just not use risky libraries instead

[elarlang]

Those are current requirements that are questioned by 2 persons...

[jmanico]

With a little wordsmithing, I personally like them. That's all.

[tghosth]

@set-reminder @tghosth in 1 day to double check the reasoning behind this split but strongly consider re-connecting them and simplifying the requirement.

[octo-reminder]

⏰ Reminder
Wednesday, October 23, 2024 12:00 AM (GMT+02:00)

@tghosth in to double check the reasoning behind this split but strongly consider re-connecting them and simplifying the requirement.

[tghosth]

By nature, these requirements are probably better put into the proposed "architecture" section for V10 (discussed in #2173)

[octo-reminder]

🔔 @tghosth

@tghosth in to double check the reasoning behind this split but strongly consider re-connecting them and simplifying the requirement.

[tghosth]

Ok @elarlang so my proposal:

#	Description	L1	L2	L3	CWE
14.2.6	[MOVED TO 10.5.2]
10.5.2	[MODIFIED, MOVED FROM 14.2.6, LEVEL L2 > L3] Verify that risky third party libraries or those with a history of vulnerabilities are sandboxed away from the most sensitive system modules/services so that even if a vulnerability in the library was successfully exploited, the sensitive system modules/services would not be compromised. Alternatively, the libraries should be encapsulated such that only required behavior is available to the application.			✓	1061

I think this remains something worth thinking about for the most sensitive applications.

[elarlang]

/ vs "or"

But if is so risky and so sensitive, why not to have it as default setup for everything?

[jmanico]

Yea. Fair point Elar.

Why not just have a requirement around "don't use risky libraries" instead?

[elarlang]

Just for information, 14.2.6 in v4.0.3 release was:

V14.2.6 Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application.

[jmanico]

14.2.6 is just a good principle for libraries you choose to use.

I suggest 10.5.2 be modified to state that we should just not use risky third party libraries at all.

[elarlang]

I'm a bit confused...

In the issue description I stated:

For me the "main error" is, if we talk about L3 requirement, then those application can not use any "too risky" and not trustful component anyway.

Response from Jim:

These are great requirements. Well done.

[jmanico]

Sorry I was too fast above. Go with my latest comment in general.

Why not just have a requirement around "don't use risky libraries" instead?

[tghosth]

So I prefer that security is not the "Department of No", but rather the "Department of Yes, and...." or at least the "Department of Yes, but....".

Hence, saying if you must do risky things, at least take precautions

[elarlang]

Getting a bit philosophical, but I'm from the department "everything is risky by default" and have a question - how do you decide, what is risky and what is not?

[jmanico]

The “yes” is to use libraries with a good security history.

[tghosth]

So should we change "risky" to "perform potentially dangerous operations" or "perform security sensitive operations"?

[elarlang]

I think the style of old version is good.

Verify that

• risky third party libraries
  • comment: no one undestands, what is risky. My risky is not your risky.
• or those with a history of vulnerabilities
  • comment: every component has vulnerabilities. If it does not, no one tested it or they just don't publish it. I would say a new component without vulnerability history is more dangerous choice than "publicaly beaten" component, because the old one is tested and got fixes

... are sandboxed away from

• the most sensitive system modules/services
  • comment: what is sensitive? If we talk about Level 3 requirement, everything must be considered as senstive

so that even if a vulnerability in the library was successfully exploited, the sensitive system modules/services would not be compromised. Alternatively, the libraries should be encapsulated such that only required behavior is available to the application.

[jmanico]

Getting a bit philosophical, but I'm from the department "everything is risky by default" and have a question - how do you decide, what is risky and what is not?

1. How critical is this library? - Is it handling access control, encryption or authentication?
2. What is the security history of the library - How long were serious vulns exposed in this library and its dependencies?
3. What is the attack surface of this library? - Does this library have complex functions or broad functionality?

Admittedly this is not easy to quantify, but there are some of the things I look for as a developer before using a library.

[tghosth]

@elarlang

I accept your point about risky which is why I suggested different potential wording above. Jim also makes good points about how to quantify. We could include Jim's point in section text or use "perform potentially dangerous operations" or "perform security sensitive operations" instead of "Risky". What do you think?

Regarding the history of vulnerabilities, I think this is more easily quantifiable as there are clearly certain libraries which have had a long string of nasty vulnerabilities in.

the most sensitive system modules/services

I take your point, take a look at my change below.

#	Description	L1	L2	L3	CWE
14.2.6	[MOVED TO 10.5.2]
10.5.2	[MODIFIED, MOVED FROM 14.2.6, LEVEL L2 > L3] Verify that risky third party libraries or those with a history of vulnerabilities are sandboxed away from the rest of the application so that even if a vulnerability in the library was successfully exploited, the other parts of the application would not be compromised. Alternatively, the libraries should be encapsulated such that only required behavior is available to the application.			✓	1061

[elarlang]

I have described n+1 times my concerns on the "risky" and "history of vulnerabilities" here and before that in the #1425. I still have them and this wording does not make any sense for me, it's not reasonable limitation. The requirement got in because I did not care enough and was already annoyed of this discussion in the last issue, but this did not make it valid.

[tghosth]

From your perspective, you would prefer to delete this requirement?

[elarlang]

I think it has the point and it should be in, but close to the previous version (in v4.0.3) without unclear limiting wording such as risky and "history of vulnerabilities". For level 3 application everything should be considered as risky.

[tghosth]

Ok so let me have one more try, I think doing this for every library is unrealistic as it means every library being separated from every other library. @elarlang

#	Description	L1	L2	L3	CWE
1.10.2	[MODIFIED, SPLIT FROM 14.2.6, LEVEL L2 > L3] Verify that application documentation highlights "risky" third party libraries which should include: libraries which perform operations which are dangerous from a security perspective, libraries which are poorly maintained, unsupported, or end of life, libraries which have historically had several significant vulnerabilities, etc.			✓	1061
10.5.2	[MODIFIED, SPLIT FROM 14.2.6, LEVEL L2 > L3] Verify that third party libraries which have been documented as "risky" are sandboxed away from the rest of the application so that even if a vulnerability in the library was successfully exploited, the other parts of the application would not be compromised. Alternatively, the libraries should be encapsulated such that only required behavior is available to the application.			✓	1061
14.2.6	[SPLIT TO 1.10.2, 10.5.2]

[elarlang]

Let's distance from the wording and reset to the beginning: what is the application security problem to solve or address with this requirement?

[jmanico]

1. Initially choosing libraries that are secure.
2. Initially choosing libraries that are likely to remain secure, with active maintenance and a track record of timely vulnerability patches.
3. Choosing libraries with minimal complexity, making them easier to update and manage in case of security problems.
4. Ensuring libraries are sourced from trusted repositories to prevent attackers from substituting them with compromised versions.
5. Regularly reviewing libraries for newly discovered vulnerabilities and deprecated dependencies.
6. Validating library integrity by using hashes or digital signatures to verify that libraries are authentic and untampered.

[elarlang]

Keeping in mind that it should not duplicate requirements:

• V1.10.2 Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all third-party libraries in use, including verifying that components come from pre-defined, trusted, and continually maintained repositories.
• V10.3.2 Verify that the application only loads or executes code, modules, content or plugins from sources not under the application's direct control or protection if it employs integrity protections, such as code signing.
• V10.5.1 Verify that the application architecture uses techniques such as sandboxing, containerization or network level isolation to delay and deter attackers from attacking other parts of the application, especially when the application is performing sensitive or dangerous actions such as deserialization.
• V10.6.1 Verify that all components are up to date.
• V10.6.2 Verify that third party components are being included from the expected repository, whether that is internally owned or an external source, and that there is no risk of a dependency confusion attack.