@@ -93,9 +93,9 @@ The Technical Body should advise the ETSI Secretariat if the above default natio
The following non-technical requirements shall be implemented by all products with digital elements evaluated with the present document.
-**[REQ-GEN-2]:** The product dependencies to Operating System essential security capabilities are documented.
-**[REQ-GEN-3]:** The products technical documentation shall describe the external services and systems that are required for the product operation like mentioned in [4.10.1 External security functions, not in scope of the present document].
-**[REQ-GEN-4]:** Traffic related to the product operation, including but not limited to configuration, metrics and API access, is addressed as Application level traffic as per RFC 1122 in the technical documentation.
-**[REQ-GEN-2]:** The product shall describe the dependencies to Operating System essential security capabilities.
-**[REQ-GEN-3]:** The products shall describe the external services and systems that are required for the product operation.
-**[REQ-GEN-4]:** The product shall describe the traffic related to the product operation, including but not limited to configuration, metrics and API access, is addressed as Application level traffic as per RFC 1122.
-**[REQ-GEN-5]:** The product shall describe the core requirements and expectations for the operational environment (OE).
System operation is always an interplay of multiple components. Modern software design can rarely ignore impact of the changes to other components.
@@ -137,8 +137,11 @@ Later [Section 5.3 Risk Mitigations](#53-risk-mitigations) combines these genera
When evaluating the applicability of these requirements, the highest of following risk factors define the category to follow: [SRU], [Complexity], [Segment], and [CENT] defines the below risk category low, medium or high to follow. The requirements covering high risks comprise all requirements of the medium and low risk, and, analogously, the requirements from the medium risk comprise also those from the low risk.
<mark>[REQ-TECH-0] assesment: Needs the documentation trick.</mark>
For low risk:
-**[REQ-TECH-0]** The product shall be shipped without undocumented interfaces.
-**[REQ-TECH-0]** The product shall be shipped without unknown interfaces.
-**[REQ-TECH-0]** The product shall not connect to unknown RDPS services.
-**[REQ-TECH-1]** The product shall implement [5.2.4 State-of-the-art cryptographic libraries] to allow the protection of the requirements of the foreseeable use.
-**[REQ-TECH-2]** When privileged information is transferred or accessed, a secure channel shall be used in transport [5.2.1 Secure channel].
-**[REQ-TECH-3]** All endpoints in a secure channel shall cryptographically verify others.
@@ -157,7 +160,7 @@ A **secure channel** referred in [REQ-TECH-2] and used in transportation is a cr
-**[REQ-CRYPTO-0]** The product shall ensure that the channel uses appropriate cryptographic functions and configuration according to the requirements of the foreseeable use.
-**[REQ-CRYPTO-1]** The product shall ensure that the channel can not be impaired by downgrading it [i.10].
-**[REQ-CRYPTO-2]** The product shall provide detailed description how the channel is secured in the technical documentation.
-**[REQ-CRYPTO-2]** The product shall implement secure channel as per Annex K.
-**[REQ-CRYPTO-3]** The product shall protect the data transfer, the confidentiality and the integrity of the data according to the requirements of the foreseeable use.
Mutual trust is in plural form not exluding IP Multicast or Anycast usage if implemented.
@@ -292,7 +295,7 @@ This is the reason for the requirement [REQ-AUTH-3], but as the evaluating the f
-**[REQ-AUTH-3]:** When a subject has been authenticated, the product shall apply authorisation controls based on assigned roles or equivalent access-control attributes.
-**[REQ-AUTH-4]:** The authorisation model shall enforce separation of privileges appropriate to the intended and reasonably foreseeable use of the product.
-**[REQ-AUTH-5]:** The product technical documentation shall describe the identity and authorisation model implemented by the product.
-**[REQ-AUTH-5]:** The product shall implement the identity and authorisation model that is considered to be secure.
-**[REQ-AUTH-6]:** All access to privileged interfaces, control functions, and sensitive operations shall be subject to strong authentication of subjects, services, or integrated components.
-**[REQ-AUTH-7]:** Privileged interfaces shall be protected with [5.2.4 State-of-the-art cryptographic libraries].
-**[REQ-AUTH-8]:** The product shall report all relevant events related to authorisation including, but not limited to, successful and unsuccessful use of identity, object access, policy change, privileged function use, data access and deletions, data changes and permission changes.
@@ -453,8 +456,8 @@ For medium risk:
For high risk:
-**[REQ-LOG-6]:** The product shall support forwarding of relevant administrative events to an external logging or SIEM system and shall document the transfer format and field definitions.
-**[REQ-LOG-7]:** SIEM transfer format, field attributes and event descriptions shall made available as part of the technical documentation.
-**[REQ-LOG-6]:** The product shall support forwarding of relevant administrative events to an external logging or SIEM system.
-**[REQ-LOG-7]:** SIEM transfer format, field attributes and event descriptions shall made available in a machine readable format.
-**[REQ-LOG-8]:** Exported artifacts shall preserve essential fields at least, but not limited to: time, actor, action type, affected scope, result.
-**[REQ-LOG-9]:** The product shall record provenance sufficient to attribute the change to an actor and context information related to at least, but not limited to: user, automated workflow, policy or rule identifier, and triggering event reference.
@@ -526,7 +529,9 @@ For low risk:
For medium risk:
-**[REQ-HA-2]** System shall tolerate loss of resources within the limits of the defined availability.
-**[REQ-HA-3]** Recovery capabilities shall be made available in the technical documentation and are sufficient to implement the expected availability.
-**[REQ-HA-3]** Recovery capabilities shall be sufficiently implemented to match the expected availability targets.
<mark>REQ-HA-3 needs documentation trick for: "made available in the technical documentation"</mark>
<mark>How to include protections against DDoS or similar?</mark>
