@@ -519,10 +519,25 @@ Data minimisation is achieved with understanding what data is collected [REQ-MET
High availability starts from the running process.
In a modern cluster runtime environment used in large system deployments, the process rarely can control the loss of underlying resources.
Administrative actions can shutdown the node without preseeding announcement unexpectedly.
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.
Administrative actions can shutdown unexpectedly the node without a preseeding announcement.
It is up to the software design whether or not such interruptions can be tolerated.
Modern design is often distributed, but depending on the implementation and runtime context, a singular process can also provide the targeted service availability, if the process was implemented correctly, and a self-healing system can launch a replacement within a given time window.
Following general risks apply if the NMS can be reached by a DDoS attack: For an NMS in large deployment scenarios, e.g. telecom or enterprise use cases, a DDoS is not practical due to the physical separation of payload network and management network.
An attacker would need to physically access a high number of the managed devices, manipulate them, build a bridge to the management network, and be able to orchestrate then DDoS on the NMS.
As this is considered not practical in real scenarios, such an NMS itself will not be affected by DDoS.
Of course, such NMS are able to detect DDoS scenarios on its managed devices.
NMS in these large scenarios are usually also part of the DDoS defense means: The NMS gets input from defense systems and executes then mitigating configurations on the managed devices affected by the DDoS attack.
In these scenarios and for the CRA conformity, the NMS manufacturer can argue: a DDoS is not applicable.
For other scenarios, where the NMS itself can be affected by DDoS, the NMS may cease services for a configurable timeframe, apply predefined mitigation means, such as a reset, and return then to normal operation.
Most DDoS scenarios last less than 10 minutes.
However, such event needs to be notified, reported and logged.
Of course, for forensic analysis of this event, i.e. to identify the source of DDoS orchestration, sources of the flooding etc., a logging of all available data about this event is required.
Generally, DDoS attack vary greatly in duration, but following some online statistics, 60-80% last less than one hour, the most thereof less than 10 minutes.
Nevertheless, single publicly known campaigns can last 12 hours, the longest known 2025/12 lasted more than 7 days, but those are usually rare.
These are example data for which public statistics are available [i.17].
