V10.2 requirements - cleanup

[elarlang]

parent/related issue: #1383

"V10.2 Malicious Code Search" requirements.

#	Description	L1	L2	L3	CWE
10.2.1	Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data.		✓	✓	359
10.2.2	Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location.		✓	✓	272
10.2.3	Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered.			✓	507
10.2.4	Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions.			✓	511
10.2.5	Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs.			✓	511
10.2.6	Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.			✓	507

All the "third party libraries" points should be covered by requirements:

• V14.2.4 Verify that third party components come from pre-defined, trusted and continually maintained repositories.
• V14.2.5 Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use.
• V14.2.7 [ADDED] Verify that third party components are sourced separately from internally owned and developed applications.

Or is the message here, that with Level 3 you need to test and code review all used frameworks and components?

Other comments:

• V10.2.1 - phone home is in a way covered that outgoing connections should be limited
  • V1.1.5 Verify definition and security analysis of the application's high-level architecture and all connected remote services.
  • V12.6.1 Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from.
• V10.2.2 is good candidate to be some way in V8.3 Sensitive Private Data
  • edit: seems that this idea was not first time in my mind (Consider making 10.2.2 Level-1 > modify and move 10.2.2 to 8.3 #1201, 1.8.X new requirements #1005)
• V10.2.3 - undocumented and hardcoded accounts are related/covered
  • V2.5.4 Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").
• V10.2.3 - debugging features are related/covered
  • V14.3.2 Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.
• V10.2.4, V10.2.5, V10.2.6 - just many different ways to say "malicious code"

There are some points to keep, but a some abstraction and cleanup is needed.

[danielcuthbert]

10.2.1 & 10.2.2 are a bit vague. I get the reasoning but without us either adding some examples, this is very handwavy. I agree with the comment that 10.2.2 level 1

[tghosth]

This feels like big rework.

[tghosth]

I think that the "third party library" part should stay as I think these are L3 requirement with specific and difficult scope.

• 10.2.1 I think this is ok as a L3 requirement
• 10.2.2 is gone to V8.
• I think that 10.2.3 is a lot more comprehensive and wide ranging than 2.5.4. I think it can stay separate
• I would support merging 10.2.4, 10.2.5 and 10.2.6.

[ImanSharaf]

@tghosth I believe we can close this based on #2145

[tghosth]

Yeah this section has basically disappeared so closing this issue