**Objective:** Events by changes of the product itself that impact the product availability do not render the product behaviour into the unpredicatable. The product keeps the availability time definitions.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the metrics for availability information provided in the technical documentation
2. Check in the system whether the features are available as described in the technical documentation
1.Intensionally terminate randomly an NMS-internal process, a processing node or simulate a loss of a datacenter.
2.Repeat the previous step 1 enough often with varying scopes to demonstrate conformance.
**Verdict:**
1. Pass, if all relevant features are available as defined and tracked.
1. Pass, if the effect of the loss of a chosen resource or process termination matches the availability and service description, and that the NMS meets the availability time period definitions.
1. Fail otherwise.
**Supporting Evidence:**
1. Relevant metrics described in the technical documentation.
1. Screen shots of metrics being visualised in the dashboards.
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
### 6.10.1 REQ-HA-1
### 6.10.2 AP_HA-2
**Objective:**Events by changes of the product itself that impact the product availability do not render the product behaviour into the unpredicatable. The product keeps the availability time definitions.<br/>
**Objective:**The changes in the system availability are noticed.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation
**Activities:**
1.Intensionally terminate randomly an NMS-internal process, a processing node or simulate a loss of a datacenter.
2.Repeat the previous step 1 enough often with varying scopes to demonstrate conformance.
1.Study the technical documentation;
2.Disconnect or make unavailable a service, a compute node, a rack, or a datacenter based on the tolerable disturbances provided in the technical documentation.
**Verdict:**
1. Pass, if the effect of the loss of a chosen resource or process termination matches the availability and service description, and that the NMS meets the availability time period definitions.
1. Fail otherwise.
1. Pass, if an event is emited as a result to the test activity.
2. Fail otherwise.
**Supporting Evidence:**
1. Structured log output or other documentation that shows made actions and perceived operative response.
**Objective:** System updates and changes are included in the availability definition.<br/>
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
### 6.10.2 REQ-HA-2
### 6.10.3 AP_HA-3
**Objective:** The user understands how the sytem behaves under different conditions and can make a disaster recovery plan for the operation.<br/>
**Preparation:**
@@ -2143,14 +2147,16 @@ Verify that:
4. and the defined high availability is hold.
5. Fail otherwise.
> NOTE: The selection of the resource to be removed should meet the principal of the most needed or having the highest priority resource for the normal NMS operations.
> NOTE: The selection of the resource to be removed should meet the principal of the most needed or having the highest priority resource for the expected NMS operations.
**Supporting Evidence:**
1. Pointers to the documentation.
2. Description of the test procedure and relevant bits of log showing the phases.
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
### 6.10.3 REQ-HA-3
### 6.10.4 AP_HA-4
**Objective:** The technical documentation provides explanations on how the sytem behaves under different conditions, enabling the user to develop a disaster recovery plan for the operation.<br/>
**Preparation:** None <br/>
@@ -2163,46 +2169,102 @@ Verify that:
**Verdict:**
1. Pass if recovery expectations are clearly defined
1. and the distribution of the system operations is within reasonable scope in regards to the production computational resources.
1. Fail otherwise.
2. and the system design is reasonably capable to operate in abnormal conditions
3. and the distribution of the system operations is within reasonable scope in regards to the production computational resources.
4. Fail otherwise.
**Supporting Evidence:**
1. Pointers to the documentation.
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
#### 6.10.5 AP_HA-5
#### 6.10.4 REQ-HA-4
**Objective:** The system tolerates missuse of the protocols and connection surges outside of the expected behavior.<br/>
**Preparation:**
1. Ensure brute force protection is enabled and configured as per manufacturers instructions <br/>
1. Have the product initialised and available with the default configuration and required credentials;
2. Ensure brute force and overload protections available are enabled and configured as per manufacturers instructions.
**Activities:**
1. From a test host, generate repeated failed SSH / HTTP (as applicable) logins to exceed the configured threshold.
2. Observe the scheduler‑based detection and automatic IP block of the attacking host
1. From a test host, generate repeated login attempts without valid credentials exceeding the expected threshold.
2. Observe detection and expected reaction to the generated traffic.
**Verdict:**
1. Pass if the offending IP is blocked for the configured duration and legitimate connections are still served.
1. Fail otherwise.
1. Pass if the expected reaction is made by the system.
2. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
#### 6.10.6 AP_HA-6
**Objective:** The system tolerates missuse of the protocols and connection surges outside of the expected behavior.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Identify queues/handlers that can buffer incoming work (Eg: task queues, batch operations);
3. Identify the failover mechanisms in place.
**Activities:**
#### 6.10.5 REQ-HA-5
1. Feed the system with large volume of batch jobs or messages;
2. Execute concurrent operations in accordance;
3. Confirm the operations are batched and system is still serving requests and is not unresponsive;
4. Repeat the task flooding and kill a process, node or a datacenter that withing the toleration of the availability and time the disturbance to the moment processing is onging;
5. Verify the successfull completion of the test jobs.
**Verdict:**
1. Pass if buffering and task queuing is performed within the queue depth or metrics as per the manufactured defined limits
2. and the system load reduces as the tasks complete
3. and the failover mechnisms function without intervention.
4. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
### 6.10.7 AP_HA-7
**Objective:** Protect the prodcut and the product user from rogue actors.<br/>
**Preparation:**
1. Identify queues/handlers that can buffer incoming work (Eg: task queues, batch operations)
1. Have the product initialised and available with the default configuration and required credentials.
2. Ensure DDoS protections available are enabled and configured as per manufacturers instructions.
**Activities:**
1.Feed they system with large volume of batch jobs or messages
1.Execute concurrent operations in accordance
1. Confirm the operations are batched and system is still serving requests and is not unresponsive
1.Tricker defined DDoS protection mechnisms;
2.Observe how the mechanism works;
3. Confirm the system is still serving requests and is not unresponsive.
**Verdict:**
1. Pass if buffering and task queuing is performed within the queue depth or metrics as per the manufactured defined limits. The system load reduces as the tasks complete.
1. Pass, if all relevant features are available as defined and mitigates DDoS attack as expected.
1. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
## 6.11 Non-interference
### 6.11.1 Network segmentation
@@ -2306,7 +2368,38 @@ Verify that:
**Supporting Evidence:**
1. References to to documentation sections.
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
### 6.12.2 MAS_TECH-2
**Objective:** How the product communicates is understood and documented.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the technical documentation.
2. Study the listed dependencies to RDPS systems.
3. Capture all network traffic metadata that is communicating outside of the product deployment boundaries.
4. Tricker all possible actions, that might result to a communication with RDPS services, like update, licensing verifications, etc.
5. Identify all systems with the help of the tehcnical documentation.
**Verdict:**
1. Pass, if the product does not intiate a connection with an undefined target.
2. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
