Refactored requirement IDs (c2615b09) · Commits · STAN4CRA / EN 304 621 Network Management Systems

EN-304-621.md

+23 −23

Original line number	Diff line number	Diff line
		@@ -501,13 +501,13 @@ The metrics can be for example the last time when the managed element has been s

		The following are non-technical requirements, that shall be implemented by all products with digital elements evaluated with this standard.

		- [REQ-GEN-1]: Manufacturer shall declare in the technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.
		- [REQ-GEN-2]: Manufacturer shall provide in the technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.
		- [REQ-GEN-0]: Manufacturer shall declare in the technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.
		- [REQ-GEN-1]: Manufacturer shall provide in the technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.

		\| Requirement \| Assesment \|
		\| --------------- \| ------------------------------------------------------------------------------------------------------------- \|
		\| [REQ-GEN-1] \| Technical documentation exists, is available for national MSAs and has product related risk factors declared. \|
		\| [REQ-GEN-2] \| National MSAs are able to validate the system design comformity without a deployment. \|
		\| [REQ-GEN-0] \| Technical documentation exists, is available for national MSAs and has product related risk factors declared. \|
		\| [REQ-GEN-1] \| National MSAs are able to validate the system design comformity without a deployment. \|

		## 5.2 Technical security requirements specifications

		@@ -519,28 +519,28 @@ Later [Section 5.3 Risk Mitigations](#53-risk-mitigations) combines these genera

		General requirements:

		- [REQ-TECH-1] An network management system shall implement appropriate cryptographic libraries to allow the protection to the requirements of the forseeable use.
		- [REQ-TECH-2] The product is shipped without undocumented interfaces.
		- [REQ-TECH-3] Administrative actions shall be traced.
		- [REQ-TECH-4] A secure channel is used in transport.
		- [REQ-TECH-5] Cryptographic keys can be changed.
		- [REQ-TECH-0] An network management system shall implement appropriate cryptographic libraries to allow the protection to the requirements of the forseeable use.
		- [REQ-TECH-1] The product is shipped without undocumented interfaces.
		- [REQ-TECH-2] Administrative actions shall be traced.
		- [REQ-TECH-3] A secure channel is used in transport.
		- [REQ-TECH-4] Cryptographic keys can be changed.

		\| Requirement \| Assesment \|
		\| ---------------- \| ------------------------------------------------------------------------------------------------------------ \|
		\| [REQ-TECH-1] \| See [5.2.3 Appropriate cryptographic libraries](#523-appropriate-cryptographic-libraries) \|
		\| [REQ-TECH-2] \| Deployment of a production distribution exposes only documented interfaces. \|
		\| [REQ-TECH-3] \| Actions are recorded and can not be modified later. \|
		\| [REQ-TECH-4] \| See [5.2.1 Secure channel definition](#521-secure-channel-definition). \|
		\| [REQ-TECH-5] \| See [5.2.2 Cryptographic key intialization and rotation](#522-cryptographic-key-intialization-and-rotation). \|
		\| [REQ-TECH-0] \| See [5.2.3 Appropriate cryptographic libraries](#523-appropriate-cryptographic-libraries) \|
		\| [REQ-TECH-1] \| Deployment of a production distribution exposes only documented interfaces. \|
		\| [REQ-TECH-2] \| Actions are recorded and can not be modified later. \|
		\| [REQ-TECH-3] \| See [5.2.1 Secure channel definition](#521-secure-channel-definition). \|
		\| [REQ-TECH-4] \| See [5.2.2 Cryptographic key intialization and rotation](#522-cryptographic-key-intialization-and-rotation). \|

		### 5.2.1 Secure channel definition

		A secure channel referred in [REQ-TECH-4] and used in transportation is a cryptographically protected communication channel, that may be implemented with TLS. When TLS is used, manufacturer shall ensure that the channel uses appropriate cryptographic functions and configuration according to the requirements of the forseeable use. Manufacturer shall ensure that the channel can not be impaired by downgrading it [i.10].
		A secure channel referred in [REQ-TECH-3] and used in transportation is a cryptographically protected communication channel, that may be implemented with TLS. When TLS is used, manufacturer shall ensure that the channel uses appropriate cryptographic functions and configuration according to the requirements of the forseeable use. Manufacturer shall ensure that the channel can not be impaired by downgrading it [i.10].

		When TLS is not used to encrypt the traffic in the secure channel, manufacturer shall provide detailed description how the channel is secured in the technical documentation.
		The chosen method shall follow the intent in the CRA by protecting the data transfer, and protect the confidentiality and integrity of the data according to the requirements of the forseeable use.

		\| [REQ-TECH-4] Assesment \| Details \|
		\| [REQ-TECH-3] Assesment \| Details \|
		\| -------------------------------------------- \| ------------------------------------------------------------------------------------------ \|
		\| Appropriate cryptographic libraries are used \| See [5.2.4 Appropriate cryptographic libraries](#524-appropriate-cryptographic-libraries) \|
		\| Mutual trust \| All endpoints in a secure channel can cryptographically verify others. \|
		@@ -598,7 +598,7 @@ This section can include topic specific requirements.
		> - How the system users identities should be maintained
		> - How the least amount of privileges principles are enforced to user groups

		- [REQ-ID-1] An network management system shall implement and document appropriate safeguards to ensure the validity of users identity according to the requirements of the forseeable use.
		- [REQ-ID-0] An network management system shall implement and document appropriate safeguards to ensure the validity of users identity according to the requirements of the forseeable use.

		### 5.3.2 Mitigations for ingested data integrity and confidentiality

		@@ -607,8 +607,8 @@ This section can include topic specific requirements.
		> - How the NMS shall verify the authensity and integrity of the incoming data
		> - What is expected to happen, if discrepencies are found

		- [REQ-INGEST-1] The manufacturer shall protect the system against data poisoning or other adversial attacks.
		- [REQ-INGEST-2] The collected network element monitoring and metrics data shall be verifiable.
		- [REQ-INGEST-0] The manufacturer shall protect the system against data poisoning or other adversial attacks.
		- [REQ-INGEST-1] The collected network element monitoring and metrics data shall be verifiable.

		Every time a data is transported through an undefined connection, manufacturer shall take great care, that integrity and confidentiality of the data is not compromised.

		@@ -618,13 +618,13 @@ Reflecting to [List of Risk Factors](#451-list-of-risk-factors) defined in this
		\| Name \| ACC-L-0 \| ACC-L-1 \| ACC-L-2 \| ACC-L-3 \|
		\| -------------- \| --------------- \| ---------------------- \| ------------------------ \| -------------------------------------- \|
		\| Network \| Air gapped \| Single public endoint \| Multiple endpoints \| Everything else \|
		\| [REQ-TECH-0] \| Required \| Required \| Required \| Required \|
		\| [REQ-TECH-1] \| Required \| Required \| Required \| Required \|
		\| [REQ-TECH-2] \| Required \| Required \| Required \| Required \|
		\| [REQ-TECH-3] \| Required \| Required \| Required \| Required \|
		\| [REQ-TECH-4] \| Self-signed TLS \| TLS in the endpoint \| TLS in exposed endpoints \| Technical documentation responsibility \|
		\| [REQ-TECH-5] \| Required \| Required \| Required \| Required \|
		\| [REQ-TECH-3] \| Self-signed TLS \| TLS in the endpoint \| TLS in exposed endpoints \| Technical documentation responsibility \|
		\| [REQ-TECH-4] \| Required \| Required \| Required \| Required \|
		\| [REQ-INGEST-0] \| Data signing \| Data signing \| Data signing \| Data signing \|
		\| [REQ-INGEST-1] \| Data signing \| Data signing \| Data signing \| Data signing \|
		\| [REQ-INGEST-2] \| Data signing \| Data signing \| Data signing \| Data signing \|

		Note that in a closed system, where the confindentiality doesn't require transport encryption, the data integrity does require at least signing of the data set with cryptographically good enough keying.

Original line number	Diff line number	Diff line
		@@ -501,13 +501,13 @@ The metrics can be for example the last time when the managed element has been s

		The following are non-technical requirements, that shall be implemented by all products with digital elements evaluated with this standard.

		- [REQ-GEN-1]: Manufacturer shall declare in the technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.
		- [REQ-GEN-2]: Manufacturer shall provide in the technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.
		- [REQ-GEN-0]: Manufacturer shall declare in the technical documentation with what [Risk factors](#45-risk-factors) the product with digital elements shall be evaluated.
		- [REQ-GEN-1]: Manufacturer shall provide in the technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.

		\| Requirement \| Assesment \|
		\| --------------- \| ------------------------------------------------------------------------------------------------------------- \|
		\| [REQ-GEN-1] \| Technical documentation exists, is available for national MSAs and has product related risk factors declared. \|
		\| [REQ-GEN-2] \| National MSAs are able to validate the system design comformity without a deployment. \|
		\| [REQ-GEN-0] \| Technical documentation exists, is available for national MSAs and has product related risk factors declared. \|
		\| [REQ-GEN-1] \| National MSAs are able to validate the system design comformity without a deployment. \|

		## 5.2 Technical security requirements specifications

		@@ -519,28 +519,28 @@ Later [Section 5.3 Risk Mitigations](#53-risk-mitigations) combines these genera

		General requirements:

		- [REQ-TECH-1] An network management system shall implement appropriate cryptographic libraries to allow the protection to the requirements of the forseeable use.
		- [REQ-TECH-2] The product is shipped without undocumented interfaces.
		- [REQ-TECH-3] Administrative actions shall be traced.
		- [REQ-TECH-4] A secure channel is used in transport.
		- [REQ-TECH-5] Cryptographic keys can be changed.
		- [REQ-TECH-0] An network management system shall implement appropriate cryptographic libraries to allow the protection to the requirements of the forseeable use.
		- [REQ-TECH-1] The product is shipped without undocumented interfaces.
		- [REQ-TECH-2] Administrative actions shall be traced.
		- [REQ-TECH-3] A secure channel is used in transport.
		- [REQ-TECH-4] Cryptographic keys can be changed.

		\| Requirement \| Assesment \|
		\| ---------------- \| ------------------------------------------------------------------------------------------------------------ \|
		\| [REQ-TECH-1] \| See [5.2.3 Appropriate cryptographic libraries](#523-appropriate-cryptographic-libraries) \|
		\| [REQ-TECH-2] \| Deployment of a production distribution exposes only documented interfaces. \|
		\| [REQ-TECH-3] \| Actions are recorded and can not be modified later. \|
		\| [REQ-TECH-4] \| See [5.2.1 Secure channel definition](#521-secure-channel-definition). \|
		\| [REQ-TECH-5] \| See [5.2.2 Cryptographic key intialization and rotation](#522-cryptographic-key-intialization-and-rotation). \|
		\| [REQ-TECH-0] \| See [5.2.3 Appropriate cryptographic libraries](#523-appropriate-cryptographic-libraries) \|
		\| [REQ-TECH-1] \| Deployment of a production distribution exposes only documented interfaces. \|
		\| [REQ-TECH-2] \| Actions are recorded and can not be modified later. \|
		\| [REQ-TECH-3] \| See [5.2.1 Secure channel definition](#521-secure-channel-definition). \|
		\| [REQ-TECH-4] \| See [5.2.2 Cryptographic key intialization and rotation](#522-cryptographic-key-intialization-and-rotation). \|

		### 5.2.1 Secure channel definition

		A secure channel referred in [REQ-TECH-4] and used in transportation is a cryptographically protected communication channel, that may be implemented with TLS. When TLS is used, manufacturer shall ensure that the channel uses appropriate cryptographic functions and configuration according to the requirements of the forseeable use. Manufacturer shall ensure that the channel can not be impaired by downgrading it [i.10].
		A secure channel referred in [REQ-TECH-3] and used in transportation is a cryptographically protected communication channel, that may be implemented with TLS. When TLS is used, manufacturer shall ensure that the channel uses appropriate cryptographic functions and configuration according to the requirements of the forseeable use. Manufacturer shall ensure that the channel can not be impaired by downgrading it [i.10].

		When TLS is not used to encrypt the traffic in the secure channel, manufacturer shall provide detailed description how the channel is secured in the technical documentation.
		The chosen method shall follow the intent in the CRA by protecting the data transfer, and protect the confidentiality and integrity of the data according to the requirements of the forseeable use.

		\| [REQ-TECH-4] Assesment \| Details \|
		\| [REQ-TECH-3] Assesment \| Details \|
		\| -------------------------------------------- \| ------------------------------------------------------------------------------------------ \|
		\| Appropriate cryptographic libraries are used \| See [5.2.4 Appropriate cryptographic libraries](#524-appropriate-cryptographic-libraries) \|
		\| Mutual trust \| All endpoints in a secure channel can cryptographically verify others. \|
		@@ -598,7 +598,7 @@ This section can include topic specific requirements.
		> - How the system users identities should be maintained
		> - How the least amount of privileges principles are enforced to user groups

		- [REQ-ID-1] An network management system shall implement and document appropriate safeguards to ensure the validity of users identity according to the requirements of the forseeable use.
		- [REQ-ID-0] An network management system shall implement and document appropriate safeguards to ensure the validity of users identity according to the requirements of the forseeable use.

		### 5.3.2 Mitigations for ingested data integrity and confidentiality

		@@ -607,8 +607,8 @@ This section can include topic specific requirements.
		> - How the NMS shall verify the authensity and integrity of the incoming data
		> - What is expected to happen, if discrepencies are found

		- [REQ-INGEST-1] The manufacturer shall protect the system against data poisoning or other adversial attacks.
		- [REQ-INGEST-2] The collected network element monitoring and metrics data shall be verifiable.
		- [REQ-INGEST-0] The manufacturer shall protect the system against data poisoning or other adversial attacks.
		- [REQ-INGEST-1] The collected network element monitoring and metrics data shall be verifiable.

		Every time a data is transported through an undefined connection, manufacturer shall take great care, that integrity and confidentiality of the data is not compromised.

		@@ -618,13 +618,13 @@ Reflecting to [List of Risk Factors](#451-list-of-risk-factors) defined in this
		\| Name \| ACC-L-0 \| ACC-L-1 \| ACC-L-2 \| ACC-L-3 \|
		\| -------------- \| --------------- \| ---------------------- \| ------------------------ \| -------------------------------------- \|
		\| Network \| Air gapped \| Single public endoint \| Multiple endpoints \| Everything else \|
		\| [REQ-TECH-0] \| Required \| Required \| Required \| Required \|
		\| [REQ-TECH-1] \| Required \| Required \| Required \| Required \|
		\| [REQ-TECH-2] \| Required \| Required \| Required \| Required \|
		\| [REQ-TECH-3] \| Required \| Required \| Required \| Required \|
		\| [REQ-TECH-4] \| Self-signed TLS \| TLS in the endpoint \| TLS in exposed endpoints \| Technical documentation responsibility \|
		\| [REQ-TECH-5] \| Required \| Required \| Required \| Required \|
		\| [REQ-TECH-3] \| Self-signed TLS \| TLS in the endpoint \| TLS in exposed endpoints \| Technical documentation responsibility \|
		\| [REQ-TECH-4] \| Required \| Required \| Required \| Required \|
		\| [REQ-INGEST-0] \| Data signing \| Data signing \| Data signing \| Data signing \|
		\| [REQ-INGEST-1] \| Data signing \| Data signing \| Data signing \| Data signing \|
		\| [REQ-INGEST-2] \| Data signing \| Data signing \| Data signing \| Data signing \|

		Note that in a closed system, where the confindentiality doesn't require transport encryption, the data integrity does require at least signing of the data set with cryptographically good enough keying.