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

Review updates on AP_ topic

Closes #578, #579, #580, #581, #582, #583
parent 00263a5f
Loading
Loading
Loading
Loading
+17 −17
Original line number Diff line number Diff line
@@ -3192,7 +3192,7 @@ Assessments are defined in [Annex K](#annex-k-normative-generic-cryptographic-re

### 6.10.2 AP_HA-2

**Objective:** The changes in the system availability are noticed.
**Objective:** A product and product-services outage, or a performance decrease trigger a security event.

**Preparation:**

@@ -3218,7 +3218,7 @@ Assessments are defined in [Annex K](#annex-k-normative-generic-cryptographic-re

### 6.10.3 AP_HA-3

**Objective:** The user understands how the system behaves under different conditions and can make a disaster recovery plan for the operation.
**Objective:** Even during the specified tolerable loss of essential external resources, the product remains operational.

**Preparation:**

@@ -3240,7 +3240,7 @@ Assessments are defined in [Annex K](#annex-k-normative-generic-cryptographic-re
4. and the defined high availability is held.
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 expected 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 product operations.

**Supporting Evidence:**

@@ -3251,21 +3251,20 @@ Assessments are defined in [Annex K](#annex-k-normative-generic-cryptographic-re

### 6.10.4 AP_HA-4

**Objective:** The technical documentation provides explanations on how the system behaves under different conditions, enabling the user to develop a disaster recovery plan for the operation.
**Objective:** In case of product anomalies the product limits its impact on the managed elements.

**Preparation:** None

**Activities:**

1.  Cross-reference the recovery capabilities with the distribution description.
2.  Cross-reference the recovery capabilities with the deployment plan and system architecture.
1.  Terminate arbitrarily one or more processes operated on the product;
2.  Check whether such disruption impacts the managed element operation or other dependent systems operation.

**Verdict:**

1. Pass if recovery expectations are clearly defined
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.
1. Pass, if the affected product disruptions do not impact the managed element or other dependent systems operation
2. and the product resumes services after the disruptions have been removed.
3. Fail otherwise.

**Supporting Evidence:**

@@ -3276,7 +3275,7 @@ Assessments are defined in [Annex K](#annex-k-normative-generic-cryptographic-re

#### 6.10.5 AP_HA-5

**Objective:** The system tolerates misuse of the protocols and connection surges outside of the expected behavior.
**Objective:** The product defences itself against brute-force and overload attacks, and enforces countermeasures.

**Preparation:**

@@ -3302,7 +3301,7 @@ Assessments are defined in [Annex K](#annex-k-normative-generic-cryptographic-re

#### 6.10.6 AP_HA-6

**Objective:** The system tolerates misuse of the protocols and connection surges outside of the expected behavior.
**Objective:** The product recovers in total or in parts from crashes or achieves a secure failover state in case the failure persists.

**Preparation:**

@@ -3334,7 +3333,7 @@ Assessments are defined in [Annex K](#annex-k-normative-generic-cryptographic-re

### 6.10.7 AP_HA-7

**Objective:** Protect the product and the product user from rogue actors.
**Objective:** The product protects itself form denial of service attacks with present countermeasures.

**Preparation:**

@@ -3343,13 +3342,14 @@ Assessments are defined in [Annex K](#annex-k-normative-generic-cryptographic-re

**Activities:**

1. Tricker defined DDoS protection mechanisms;
2. Observe how the mechanism works;
3. Confirm the system is still serving requests and is not unresponsive.
1. Flood the product with data packages from a simulator;
2. Check that the defined DDoS protection mechanisms get triggered;
3. Observe the mechanism operation and the resulting effects;
4. Confirm the system is still serving requests and is not unresponsive.

**Verdict:**

1. Pass, if all relevant features are available as defined and mitigates DDoS attack as expected.
1. Pass, if all relevant features are available as defined and mitigates DDoS attack is mitigated.
1. Fail otherwise.

**Supporting Evidence:**