V1 - cleanup from implementation requirements

[elarlang]

TLDR from #1063:

• We have changed the scope and removed requirements that are not clear about the application, such as software lifecycle, code beauty, etc.
• We collect documentation requirements into V1 that are preconditions for implementing or testing the application security

Only requirements that need to be moved away from V1 are listed here.

---

V1.1

• 1.1.4 - 1.1.4 and 1.1.5 are just threat modeling  #1541
  • Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.
• 1.1.5
  • 1.1.4 and 1.1.5 are just threat modeling  #1541
  • discussion/new requirement: inventory/documentation for "allow listed" sources and communications #993
  • Verify definition and security analysis of the application's high-level architecture and all connected remote services.
• 1.1.6 - About 1.1.6  #1434
  • Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls.

---

V1.2 - only documentation requirements

---

V1.3 - nothing yet

---

V1.4

• 1.4.4 - implementation requirement, or code beauty? Feels a bit duplicated discussion to V1.1.6 (About 1.1.6  #1434) Opened Is 1.4.4 a useful and verifiable requirement. #2147 to discuss as doesn't feel like a requirement.
  • Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths.
• 1.4.5 - 1.4.5 #1183
  • Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature or data item rather than just their role. Permissions should still be allocated using roles.

---

V1.5

V1.5.1 can be more clear towards documentation

---

V1.6

None of those is a documentation requirement, all are implementation requirements and must belong to V6.

• 1.6.1
  • Verify that there is an explicit policy for management of cryptographic keys and that a cryptographic key lifecycle follows a key management standard such as NIST SP 800-57.
• 1.6.2
  • Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.
• 1.6.3 - Expand 1.6.3 #1544
  • Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.
• 1.6.4
  • Verify that the architecture treats client-side secrets (such as symmetric keys, passwords, or API tokens) as insecure and never uses them to protect or access sensitive data.

---

V1.7 - ok, only documentation requirements

---

V1.8 - ok, only documentation requirements

---

V1.9 - ok, nothing there

---

V1.10 - ok, nothing there

---

V1.11

• 1.11.2 - merge 1.11.2 and 11.1.1 (edit: handle 1.11.2) #1303
  • Verify that all application flows including authentication, session management and access control, maintain a consistent application and user state to prevent race conditions and business logic flaws.
• 1.11.3 - V1.11.3 and V11.1.6 - merge tactou requirements #2138
  • Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions.

---

V1.12 - ok, nothing there

---

V1.13 - ok, nothing there

---

V1.14

• 1.14.5 - 1.14.5 needs to be rewritten #1531
  • Verify that application deployments adequately sandbox or isolate at the network level to delay and deter attackers from attacking other applications, especially when they are performing sensitive or dangerous actions such as deserialization.
• 1.14.7 - Clear separate requirement for making sure that application gets actual user IP (move V1.14.7 away from V1) #1389
  • Verify that the application is able to discern and utilizes the user's true IP address to provide for sensitive functions, including rate limiting and logging.

[tghosth]

Comments:

• I think that 1.6.1 is a classic documentation requirement but might need rewording.
• The rest of 1.6 will need to be merged into V6 when we have the draft from Daniel.

All the rest I think I have commented on the actual issues