@@ -702,6 +702,16 @@ Such measures are typically subject for an enterprise use case.
## 4.4 Distribution of Security Functions
The NMS provides the reliable availability of a network's operation, keeps control of its managed NEs, provides traffic meta data and metrics for the monitoring and verification of the correct network operation.
The NMS can also act in cooperation with other defense systems in mitigating or repelling attacks and incidents on its managed NEs.
An inconclusive example would be a managed NE that reports to the monitoring system the current performance of network traffic throughput with related information about time, source, destination, and signalizes an alert in cases of overload or failure.
In best cases, continuous monitoring data can allow intelligent analysis systems to forecast network issues and take action to resolve or at least mitigate those before those come to reality.
Therefore, what security functions are considered to be ancillary functions, and what are considered to be part of the core product, and what 3rd. party products depend on how the product is defined.
A distributed service can in theory always be replaced, when the API design is stable, documented, and the authorisation of external components is done adequately.
Therefore, the security functions listed below, do not necessarily fit under a single categorisation.
An NMS can be formed by a compilation or collaboration of different subsystems in a local distance but within the same management network and within the equal operational environment.
The security functions may be implemented inside one or more of the subsystems that form the NMS.
The product software packages can be installed, updated, and managed using an OS package manager or other similar mechanism outside of the control of the product.
@@ -1146,6 +1156,22 @@ The assessment criteria clause shall be structured by requirement defined in cla
<mark>Editor’s Note: Elements of the assessment clause should map one-to-one to elements of the technical requirements clause, ensuring there is a direct correspondence both ways. This means there shall be no summary assessment criteria.</mark>
The assessment has the purpose to verify that the requirements of the present standard are met in consideration of the use case and the thereout resulting risks.
The requirements need to counter these risks with an appropriate level of security.
Consequently, those need to be fulfilled by product functions and mechanisms, and, where there is none, the related risk assessment needs to prove that non-product means, such as obligations for the operational environment and user information, even obligation, mitigate the risks left open by the product.
The assessment focuses on the product functions, mechanisms and its user documentation.
The latter assessment ensures that the user can apply and operate the product in concrete practical, secure and safe ways.
The assessment needs thereby to be functional complete and sufficient:
* Functional completeness:
Verify that all claimed interfaces, functions and mechanisms meet the selected requirements of the present document according to the actual product use case.
In this functional assessment, the assessor’s evidence aims to confirm not only the product’s functioning and completeness, but also the implementation correctness.
* Functional sufficiency:
Verify that the product implementation is adequate to meet the desired purpose and the requirements of the present document in the according use case.
The assessment needs to consider the appropriateness of the evaluation efforts.
This is typically applied in relation with the architecture documentation, when concrete measurements and quantitative testing would break the principle of appropriateness.
## 6.1 Introduction to the assessment and compliance criteria
This clause provides objective and reproducible assessment criteria to determine whether a product complies with the technical security requirements of clause 5.
@@ -2768,11 +2794,11 @@ Early versions of this document had a section about SBOM requirements.
Removed requirements:
These requirements are generally binding, and there is no low-medium-high tiering available.
The requirements in 5.2.5 apply to all NMS products and are not subject to low-, medium-, or high-tier differentiation, because the SBOM is a baseline transparency and dependency-management artifact needed to support vulnerability handling, update management, and product assessment across all deployment contexts.
-**[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-1b]:** The SBOM shall use unique, unambiguous, and machine-readable component identifiers based on recognized public formats that support correlation with vulnerability information sources.
-**[REQ-SBOM-2]:** The SBOM shall be consistent with [5.3.4 Secure updates] practices.
