Section 5.3. update (40095ce9) · Commits · STAN4CRA / EN 304 621 Network Management Systems

EN-304-621.md

+74 −117

Original line number	Diff line number	Diff line
		@@ -722,9 +722,10 @@ For backwards compatibility, use of other combinations of options other what is

		These requirements are generally binding, and there is no low-medium-high tiering available.

		- [REQ-SBOM-0]: Operating system dependencies and application dependencies are clearly separated in the provided SBOM.
		- [REQ-SBOM-1a]: Unique, unambiguous, and machine-readable identification of all components and dependencies are provided in the SBOM.
		- [REQ-SBOM-1b]: The SBOM identifier format is consistent with common vulnerability handling standards.
		- [REQ-SBOM-0]: Operating system dependencies and application dependencies shall be clearly separated in the provided SBOM.
		- [REQ-SBOM-1a]: Unique, unambiguous, and machine-readable identification of all components and dependencies shall be provided in the SBOM.
		- [REQ-SBOM-1b]: The SBOM identifier format shall be consistent with common vulnerability handling standards.
		- [REQ-SBOM-2]: The SBOM shall be consistent with [5.3.4 Secure updates] practices.

		### 5.2.6 Role based authorisation

		@@ -776,26 +777,18 @@ See [5.2.6 Role based authorisation]

		### 5.3.2 Mitigations for ingested data integrity and confidentiality

		> This section shall have:
		>
		> - How the system shall verify the authensity and integrity of the incoming data
		> - What is expected to happen, if discrepencies are found
		When evaluating the applicability of these requirements, the highest of following risk factors define the category to follow: [SRU], [Complexity], [Segment], [NIS2]

		For medium risk:

		- [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.
		- [REQ-INGEST-1] The collected network element monitoring 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.

		Confidentiality can be achieved different ways in different scenarios.
		Reflecting to [List of Risk Factors](#451-list-of-risk-factors) defined in this document, the following requirements shall be implemented.

		Table 5.3.2-1: Requirement applicability

		\| Name \| [SRU] \| [Complexity] \| [Segment] \| [NIS2] \|
		\| :------------- \| :----- \| ------------ \| --------- \| ------ \|
		\| [REQ-INGEST-0] \| medium \| medium \| medium \| medium \|
		\| [REQ-INGEST-1] \| high \| medium \| medium \| high \|

		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.

		### 5.3.3 Mitigations for managed device configuration integrity and confidentiality
		@@ -872,46 +865,46 @@ For high risk:
		- [REQ-LOG-7]: The system reports relevant administrative operations shall be forwarded to an external SIEM system.
		- [REQ-LOG-8]: SIEM transfer format, field attributes and event descriptions shall made available as part of the technical documentation.

		### 5.3.6 Monitoring
		### 5.3.6 Metrics

		Reasoning for metrics requirements is often justified by data integrity protection. Faults can not be detected, if an attacker can hide it's existense.

		Reasoning for monitoring requirements is often justified by data integrity protection. Faults can not be detected, if an attacker can hide it's existense.
		These requirements are generally binding, and there is no low-medium-high tiering available.

		General requirements:

		- [REQ-MON-0] Collected and stored metrics data can not be altered.
		- [REQ-MON-1] Historical metrics data import overwriting an existing data point is noticed.
		- [REQ-MON-2] Metrics name, purpose, and value interpretation are described for the user.
		- [REQ-MON-3] Metrics cadence, accuracy and storage time are described for the user.
		- [REQ-MON-4] System does not collect metrics that are not directly used in operative purposes.
		- [REQ-METRICS-0] The product shall be designed in a way that collected and stored metrics data can not be altered.
		- [REQ-METRICS-1] Historical metrics data import overwriting an existing data point shall be noticed.
		- [REQ-METRICS-2] Metrics name, purpose, and value interpretation shall be described for the user.
		- [REQ-METRICS-3] Metrics cadence, accuracy and storage time shall be described for the user.

		> NOTE: [REQ-MON-2], [REQ-MON-3] and [REQ-MON-4] requirements apply to all collected metrics.

		Availability and uptime requirements:

		- [REQ-MON-5] Relevant system and connected element metrics like CPU, memory, disk utilisation are tracked and reported.
		- [REQ-MON-6a] System process and service crashes and restarts are tracked and reported.
		- [REQ-MON-6b] Managed element process and service crashes and restarts are tracked and reported.
		- [REQ-MON-7] Managed elements and system nodes and provided services availabilities and statuses are tracked and reported.
		- [REQ-MON-8a] Relevant system database and storage health metrics like queries per second, latency and throughput are tracked and reported.
		- [REQ-MON-8b] Relevant managed element database and storage health metrics like queries per second, latency and throughput are tracked and reported.
		- [REQ-MON-9] Relevant networking metrics like throughput and protocol errros are tracked and reported.
		- [REQ-METRICS-5] Relevant system and connected element metrics like CPU, memory, disk utilisation shall be tracked and reported.
		- [REQ-METRICS-6a] System process and service crashes and restarts shall be tracked and reported.
		- [REQ-METRICS-6b] Managed element process and service crashes and restarts shall be tracked and reported.
		- [REQ-METRICS-7] Managed elements and system nodes and provided services availabilities and statuses shall be tracked and reported.
		- [REQ-METRICS-8a] Relevant system database and storage health metrics like queries per second, latency and throughput shall be tracked and reported.
		- [REQ-METRICS-8b] Relevant managed element database and storage health metrics like queries per second, latency and throughput shall be tracked and reported.
		- [REQ-METRICS-9] Relevant networking metrics like throughput and protocol errros shall be tracked and reported.

		Application monitoring requirements:
		Application metrics requirements:

		- [REQ-MON-10] GUI and API latencies are tracked and reported.
		- [REQ-MON-11] GUI and API error rates are tracked and reported.
		- [REQ-METRICS-10] GUI and API latencies shall be tracked and reported.
		- [REQ-METRICS-11] GUI and API error rates shall be tracked and reported.

		These requirements are generally binding, and there is no low-medium-high tiering available.
		Matching tests for these requirements are listed in [6.3.6 Metrics tests].

		Matching tests for these requirements are listed in [6.3.6 Monitoring tests].

		[6.3.6 Monitoring tests]: #636-monitoring-tests
		[6.3.6 Metrics tests].: #636-metrics-tests

		### 5.3.7 Data minimization

		- [REQ-MON-2] Metrics name, purpose, and value interpretation are described for the user.
		- [REQ-MON-3] Metrics cadence, accuracy and storage time are described for the user.
		- [REQ-MON-4] System does not collect metrics that are not directly used in operative purposes.
		These requirements are generally binding, and there is no low-medium-high tiering available.

		- [REQ-MINIMI-0] Metrics name, purpose, and value interpretation shall be described for the user.
		- [REQ-MINIMI-1] Metrics cadence, accuracy and storage time shall be described for the user.

		### 5.3.8 High Availability

		@@ -922,56 +915,19 @@ It is up to the software design to tolerate these interruptions.

		Modern design is often distributed, but depending on the implementation and runtime context, a singular process can also provide the targetted service availability if implemented correctly and self healing system can launch a replacement within the given time window.

		The high availability requirements are:

		- [REQ-HA-0] Expected availability is defined for each relevant system component.
		- [REQ-HA-1] System tolerates loss of resources.
		- [REQ-HA-2] Disaster recovery plan is available.
		- [REQ-HA-3] System updates and changes are included in the availability definition.
		- <mark>How to include protections against DDoS or similar?</mark>
		- Unwanted traffic in the interfaces can cause a denial of service from the managed elements.

		Manfacturer shall implement requirements as listed in the table below.

		Table 5.3.8-1: High availability requirements - 1

		\| Name \| ACC-L-0 \| ACC-L-1 \| ACC-L-2 \| ACC-L-3 \|
		\| :--------- \| :--------- \| :-------------------- \| :----------------- \| :-------------- \|
		\| Network \| Air gapped \| Single public endoint \| Multiple endpoints \| Everything else \|
		\| [REQ-HA-0] \| Required \| Required \| Required \| Required \|
		\| [REQ-HA-1] \| Required \| Required \| Required \| Required \|
		\| [REQ-HA-2] \| Required \| Required \| Required \| Required \|
		\| [REQ-HA-3] \| Required \| Required \| Required \| Required \|
		When evaluating the applicability of these requirements, the highest of following risk factors define the category to follow: [SRU], [Complexity], [Segment], [NIS2]

		<br />

		Table 5.3.8-2: Mitigation requirements - 2

		\| Name \| SRU-L-0 \| SRU-L-1 \| SRU-L-2 \|
		\| :-------------------------------- \| :----------- \| :------------------------- \| :------- \|
		\| Affected Service Requesting Users \| Household \| Medium or large enterprise \| CSP \|
		\| [REQ-HA-0] \| Required \| Required \| Required \|
		\| [REQ-HA-1] \| Not required \| Required \| Required \|
		\| [REQ-HA-2] \| Not required \| Required \| Required \|
		\| [REQ-HA-3] \| Not required \| Required \| Required \|

		<br />

		Table 5.3.8-3: Mitigation requirements - 3
		For low risk:

		\| Name \| [EXP-L-0] \| [EXP-L-1] \| [6.3.8 High availability tests] \|
		\| :-------------------- \| :----------- \| :---------- \| :------------------------------ \|
		\| Entity classification \| Undefined \| NIS2 entity \| \|
		\| [REQ-HA-0] \| Not required \| Required \| [6.3.8.0](#6380-req-ha-0) \|
		\| [REQ-HA-1] \| Not required \| Required \| [6.3.8.1](#6380-req-ha-1) \|
		\| [REQ-HA-2] \| Not required \| Required \| [6.3.8.2](#6380-req-ha-2) \|
		\| [REQ-HA-3] \| Not required \| Required \| [6.3.8.3](#6380-req-ha-3) \|
		- [REQ-HA-0] Expected availability shall be defined for each relevant system component.
		- [REQ-HA-1] System updates and changes shall be included in the availability time definition.

		<br />
		For medium risk:

		[6.3.8 High availability tests]: #638-high-availability-tests
		- [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.

		Matching tests for these requirements are listed in [6.3.8 High availability tests].
		<mark>How to include protections against DDoS or similar?</mark>

		# 6 Conformity assesments and tests

		@@ -1156,7 +1112,7 @@ Functional sufficiency assessment, “not necessary of a pure applicability requ

		### 6.3.5 Logging tests

		### 6.3.6 Monitoring tests
		### 6.3.6 Metrics tests

		#### 6.3.6.0 REQ-MON-0

		@@ -1517,23 +1473,21 @@ Functional sufficiency assessment, “not necessary of a pure applicability requ

		\| CRA requirement \| Technical cybersecurity requirements \|
		\| :---------------------------------------------- \| :-------------------------------------------------------------------------------------- \|
		\| No known exploitable vulnerabilities \| [5.1.1 No known exploitable vulnerabilities] \|
		\| No known exploitable vulnerabilities \| [5.1.1 No known exploited vulnerabilities] \|
		\| Secure design, development, production \| [5.1.2 Secure design, development and production], [5.1.3 Product lifecycle management] \|
		\| Secure by default configuration \| [5.2.4 State-of-the-art cryptographic libraries] \|
		\| Secure updates \| [5.3.4 Secure updates] \|
		\| Authentication and access control mechanisms \| [5.3.1 Mitigations for user identity integrity] \|
		\| Authentication and access control mechanisms \| [5.2.6 Role based authorisation] \|
		\| Confidentiality protection \| [5.3.2 Mitigations for ingested data integrity and confidentiality] \|
		\| Integrity protection for data and configuration \| [5.3.2], [5.3.3], [5.3.6 Monitoring] \|
		\| Integrity protection for data and configuration \| [5.3.2], [5.3.3], [5.3.6 Metrics] \|
		\| Data minimization \| [5.3.7 Data minimization] \|
		\| Availability protection \| [5.3.8 High Availability] \|
		\| Minimize impact on other devices or services \| [5.3.8 High Availability] \|
		\| Limit attack surface \| [5.1.4 Product vulneravility management process] \|
		\| Exploit mitigation by limiting incident impact \| \|
		\| Logging and monitoring mechanisms \| [5.3.5 Logging], [5.3.6 Monitoring] \|
		\| Logging and monitoring mechanisms \| [5.3.5 Logging], [5.3.6 Metrics] \|
		\| Secure deletion and data transfer \| \|

		<br />

		[5.1 General]: #51-general
		[5.1.1 No known exploited vulnerabilities]: #511-no-known-exploited-vulnerabilities
		[5.1.2 Secure design, development and production]: #512-secure-design-development-and-production
		@@ -1545,16 +1499,18 @@ Functional sufficiency assessment, “not necessary of a pure applicability requ
		[5.2.3 Network segmentation]: #523-network-segmentation
		[5.2.4 State-of-the-art cryptographic libraries]: #524-state-of-the-art-cryptographic-libraries
		[5.2.5 Software Bill of Materials]: #525-software-bill-of-materials
		[5.2.6 Remote Data Processing Systems]: #526-remote-data-processing-system
		[5.2.6 Role based authorisation]: #526-role-based-authorisation
		[5.2.7 Remote Data Processing Systems]: #527-remote-data-processing-system
		[5.3.1 Mitigations for user identity integrity]: #531-mitigations-for-user-identity-integrity
		[5.3.1]: #531-mitigations-for-user-identity-integrity
		[5.3.2 Mitigations for ingested data integrity and confidentiality]: #532-mitigations-for-ingested-data-integrity-and-confidentiality
		[5.3.2]: #532-mitigations-for-ingested-data-integrity-and-confidentiality
		[5.3.3 Mitigations for managed device configuration integrity and confidentiality]: #533-mitigations-for-managed-device-configuration-integrity-and-confidentiality
		[5.3.3]: #533-mitigations-for-managed-device-configuration-integrity-and-confidentiality
		[5.3.3]: #533-mitigations-for-managed-device-configuration-integrity-and-confidentiality
		[5.3.4 Secure updates]: #534-secure-updates
		[5.3.5 Logging]: #535-logging
		[5.3.6 Monitoring]: #536-monitoring
		[5.3.6 Metrics]: #536-metrics
		[5.3.7 Data minimization]: #537-data-minimization
		[5.3.8 High Availability]: #538-high-availability

		@@ -1563,29 +1519,30 @@ Functional sufficiency assessment, “not necessary of a pure applicability requ
		Table A-2: Cybersecurity requirements mapping to sections

		\| Section \| Content status \| Tests status \|
		\| :--------------------------------------------------------------------------------- \| :-------------------------------- \| :------------------------------ \|
		\| [5.1 General] \| will be ammended with new content \| todo \|
		\| [5.1.1 No known exploited vulnerabilities] \| ready for review \| ready for review \|
		\| [5.1.2 Secure design, development and production] \| todo \| todo \|
		\| [5.1.3 Product lifecycle management] \| todo \| todo \|
		\| [5.1.4 Product vulneravility management process] \| todo \| todo \|
		\| [5.2 Technical cybersecurity requirements specifications] \| almost there \| todo \|
		\| [5.2.1 Secure channel definition] \| idea would need refinement \| todo \|
		\| [5.2.2 Cryptographic key intialization and rotation] \| format needs to be changed \| todo \|
		\| [5.2.3 Network segmentation] \| idea would need refinement \| todo \|
		\| [5.2.4 State-of-the-art cryptographic libraries] \| todo \|
		\| [5.2.5 Software Bill of Materials] \| waits for AMS input \| todo \|
		\| [5.2.6 Remote Data Processing Systems] \| waits for AMS input \| todo \|
		\| [5.3.1 Mitigations for user identity integrity] \| waits for AMS input \| todo \|
		\| [5.3.2 Mitigations for ingested data integrity and confidentiality] \| ready for review \| todo \|
		\| [5.3.3 Mitigations for managed device configuration integrity and confidentiality] \| ready for review \| todo \|
		\| [5.3.4 Secure updates] \| waits for content from Jon \| todo \|
		\| [5.3.5 Logging] \| waits for AMS input \| todo \|
		\| [5.3.6 Monitoring] \| ready for review \| [6.3.6 Monitoring tests] \|
		\| [5.3.7 Data minimization] \| todo, coupled with monitoring \| todo \|
		\| [5.3.8 High Availability] \| ready for review \| [6.3.8 High availability tests] \|
		\| :-------------------------------------------------------- \| :------------------------- \| :----------- \|
		\| [5.1 General] \| done \| \|
		\| [5.1.1 No known exploited vulnerabilities] \| done \| done \|
		\| [5.1.2 Secure design, development and production] \| \| \|
		\| [5.1.3 Product lifecycle management] \| \| \|
		\| [5.1.4 Product vulneravility management process] \| \| \|
		\| [5.2 Technical cybersecurity requirements specifications] \| done \| \|
		\| [5.2.1 Secure channel definition] \| done \| \|
		\| [5.2.2 Cryptographic key intialization and rotation] \| done \| \|
		\| [5.2.3 Network segmentation] \| idea would need refinement \| \|
		\| [5.2.4 State-of-the-art cryptographic libraries] \| done \| \|
		\| [5.2.5 Software Bill of Materials] \| done \| \|
		\| [5.2.6 Role based authorisation] \| done \| \|
		\| [5.2.7 Remote Data Processing Systems] \| waits for AMS input \| \|
		\| [5.3.1 Mitigations for user identity integrity] \| done \| \|
		\| [5.3.2] \| done \| \|
		\| [5.3.3] \| done \| \|
		\| [5.3.4 Secure updates] \| done \| \|
		\| [5.3.5 Logging] \| done \| \|
		\| [5.3.6 Metrics] \| done \| \|
		\| [5.3.7 Data minimization] \| done \| \|
		\| [5.3.8 High Availability] \| done \| \|


		<br />

		# Annex B (informative): Relationship between the present document and any related ETSI standards (if any)