Commit 05462345 authored by Santeri Toikka's avatar Santeri Toikka
Browse files

Added overload protection to the HA requirements

Closes #6
parent 7e3cdcea
Loading
Loading
Loading
Loading
+42 −4
Original line number Diff line number Diff line
@@ -534,18 +534,23 @@ When evaluating the applicability of these requirements, the highest of followin

For low risk:

-   **[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.
* **[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.

For medium risk:

-   **[REQ-HA-2]** System shall tolerate loss of resources within the limits of the defined availability.
-   **[REQ-HA-3]** Recovery capabilities shall be sufficiently implemented to match the expected availability targets.
* **[REQ-HA-2]** System shall tolerate loss of resources within the limits of the defined availability.
* **[REQ-HA-3]** Recovery capabilities shall be sufficiently implemented to match the expected availability targets.

<mark>REQ-HA-3 needs documentation trick for: "made available in the technical documentation"</mark>

<mark>How to include protections against DDoS or similar?</mark>

For high risk:

* **[REQ-HA-4]** The prodct shall implement coordinated brute‑force and overload protection mechanisms that not only detect excessive authentication attempts or inbound traffic surges but also enforce active mitigation actions including, but not limited to connection throttling, temporary IP blocking, message buffering, QoS parameterisation.
* **[REQ-HA-5]** The product shall implement recovery or failover to mitigate overload attempts.

# 6 Conformity assessments and tests

## 6.1 General requirements assessments
@@ -1263,6 +1268,39 @@ For medium risk:

1. Pointers to the documentation.

#### 6.3.8.4 REQ-HA-4

**Preparation:**

1. Ensure brute force protection is enabled and configured as per manufacturers instructions <br/>

**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

**Verdict:**

1. Pass if the offending IP is blocked for the configured duration and legitimate connections are still served.
1. Fail otherwise.

#### 6.3.8.5 REQ-HA-5

**Preparation:**

1. Identify queues/handlers that can buffer incoming work (Eg: task queues, batch operations)

**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

**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. Fail otherwise.

# Annex A (informative): Mapping with essential requirements of the CRA

> Table mapping technical cybersecurity requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical cybersecurity requirements.