Commit 56e5d79e authored by Santeri Toikka's avatar Santeri Toikka
Browse files

Merge branch 'workingmeeting1' into 'main' 

Changes from the working meeting

Closes #404, #188, #354, #21, #353, #171, #119, #22, #20, #19, #120, #355, #356, #447, and #395

See merge request cyber/stan4cr2/en-304-621!60
parents d8b1baa6 db6911ad

.gitignore

+1 −0
Original line number Diff line number Diff line
@@ -4,3 +4,4 @@ media/*.dtmp 
file_comments

en-304-625_*.pdf

HAAS_*.md

notes/

EN-304-621.md

+33 −22
Original line number Diff line number Diff line
@@ -726,7 +726,7 @@ For medium risk: 
- **[REQ-TECH-5]** All system components shall be synchronised to the same time.



For high risk:

- **[REQ-TECH-6]** All system clock drifts shall be monitored.

- **[REQ-TECH-6]** All system time drifts shall be monitored.

- **[REQ-TECH-7]** The product shall be designed in a way, that all cryptographic keys can be replaced with user controlled keys.



The listed requirement shall be implemented, if the risk of the given factor is defined as follows.
@@ -1010,7 +1010,7 @@ The following requirements apply where the corresponding function exists: 
- **[REQ-LOG-1i]:** The product shall generate auditable events for policy changes.

- **[REQ-LOG-1j]:** The product shall generate auditable events for credential changes.

- **[REQ-LOG-2a]:** The product shall log boot or initialisation events including timestamped boot stage progression.

- **[REQ-LOG-2b]:** The product shall log boot or initialisation events including component verification and initialisation actions.

- **[REQ-LOG-2b]:** The product shall log boot or initialisation events including software component verification and initialisation actions.

- **[REQ-LOG-2c]:** The product shall log boot or initialisation events including recovery mode activations if in use.

- **[REQ-LOG-3c]:** The product shall log events described by [5.3.4 Secure updates].

- **[REQ-LOG-3d]:** The product shall log installation successes and failures in the managed devices and the product itself if that information can be extracted from the targets.
@@ -1032,7 +1032,9 @@ For high risk: 


### 5.3.6 Metrics



Reasoning for metrics requirements is often justified by data integrity protection. Faults can not be detected, if an attacker can hide it's existense.

The metrics requirements in this subclause support security monitoring, operational visibility, fault detection, and verification of system behaviour.

Fulfilment of these metrics is essential for all products in all use cases and all risk levels.

Breaches can not be detected, if an attacker can hide it's existense.



These requirements are generally binding, and there is no low-medium-high tiering available.
@@ -1043,32 +1045,38 @@ General requirements: 
-   **[REQ-METRICS-2]** Metrics name, purpose, and value interpretation shall be described for the user.

-   **[REQ-METRICS-3]** Metrics cadence, accuracy and storage time shall be described for the user.



> NOTE: [REQ-MON-1], [REQ-MON-2] and [REQ-MON-3] requirements apply to all collected metrics.

> NOTE: [REQ-METRICS-1], [REQ-METRICS-2] and [REQ-METRICS-3] requirements apply to all collected metrics.



Availability and uptime requirements:



-   **[REQ-METRICS-4]** Relevant system and connected element metrics like CPU, memory, disk utilisation shall be tracked and reported.

-   **[REQ-METRICS-5a]** System process and service crashes and restarts shall be tracked and reported.

-   **[REQ-METRICS-5b]** Managed element process and service crashes and restarts shall be tracked and reported.

-   **[REQ-METRICS-6]** Managed elements and system nodes and provided services availabilities and statuses shall be tracked and reported.

-   **[REQ-METRICS-7a]** Relevant system database and storage health metrics like queries per second, latency and throughput shall be tracked and reported.

-   **[REQ-METRICS-5a]** System incidents, such as process and service crashes and restarts, shall be tracked and reported.

-   **[REQ-METRICS-5b]** Managed element incidents, such as process and service crashes and restarts shall be tracked and reported.

-   **[REQ-METRICS-6a]** Managed elements availabilities and statuses shall be tracked and reported.

-   **[REQ-METRICS-6b]** System and provided service availabilities and statuses shall be tracked and reported.

-   **[REQ-METRICS-7a]** Relevant databases in the product and storage health metrics like queries per second, latency and throughput shall be tracked and reported.

-   **[REQ-METRICS-7b]** Relevant managed element database and storage health metrics like queries per second, latency and throughput shall be tracked and reported.

-   **[REQ-METRICS-8]** Relevant networking metrics like throughput and protocol errors shall be tracked and reported.



The **[REQ-METRICS-5]** is vague by design.

The product can host an ecosystem that exposes managed elements capacity for 3rd. party applications.

The product then operates as a runtime for the workload, and needs to inherit operating system responsibilies.



The **[REQ-METRICS-7\*]** is defined expecting that the product hosts these services.

When RDPS is used for these functions, the relevant metrics are different and "like queris per second" equivivalent can be used.



The **[REQ-METRICS-8]** and **[REQ-METRICS-9]** below can refer either the product or the connected devices. Relevancy of the metric depends on the protocols and the product usage scenario.



Application metrics requirements:



-   **[REQ-METRICS-9]** GUI and API latencies and error rates shall be tracked and reported.

-   **[REQ-METRICS-9]** Relevant application metrics, like GUI and API latencies and error rates, shall be tracked and reported.



Matching tests for these requirements are listed in [6.3.6 Metrics tests].



[6.3.6 Metrics tests].: #636-metrics-tests



### 5.3.7 Data minimisation



These requirements are generally binding, and there is no low-medium-high tiering available.

Data minimisation is achieved with understanding what data is collected [REQ-METRICS-2], and how long it is reasonably stored [REQ-METRICS-3].



-   **[REQ-MINIMI-0]** Metrics name, purpose, and value interpretation shall be described for the user.

-   **[REQ-MINIMI-1]** Metrics cadence, accuracy and storage time shall be described for the user.



### 5.3.8 High Availability
@@ -1377,8 +1385,8 @@ There are three different types of assessments used in this document. 


#### 6.2.0.6 REQ-TECH-6



**Requirement:** All system clock drifts shall be monitored.<br/>

**Objective:** Where multiple monitoring sources all operate they shall have consistent clocks where any drift or lack of synchronization shall be accurately documented and notification provided to administrator.<br/>

**Requirement:** All system time drifts shall be monitored.<br/>

**Objective:** Where multiple monitoring sources all operate they shall have consistent system time where any drift or lack of synchronization shall be accurately documented and notification provided to administrator.<br/>

**Preparation:**



1.  Have the product initialised and available with the default configuration and required credentials.
@@ -1386,6 +1394,7 @@ There are three different types of assessments used in this document. 
**Activities:**



1.  Set a node or a system to a wrong time that is off by at leat an hour.

2.  Set a managed device or connected service to a wrong time that deviates from real time by at least one hour.



**Verdict:**
@@ -1630,8 +1639,8 @@ There are three different types of assessments used in this document. 


#### 6.3.6.5 REQ-METRICS-5



**Requirement a:** System process and service crashes and restarts shall be tracked and reported.<br/>

**Requirement b:** Managed element process and service crashes and restarts shall be tracked and reported.<br/>

**Requirement a:** System incidents, such as process and service crashes and restarts, shall be tracked and reported.<br/>

**Requirement b:** Managed element incidents, such as process and service crashes and restarts shall be tracked and reported.<br/>

**Objective:** Crashes are used to modify the program state. Abnormal crashes can be an indication of upcoming compromise.<br/>



**Preparation:**
@@ -1641,8 +1650,9 @@ There are three different types of assessments used in this document. 


**Activities:**



1. Purposefully crash a process or restart a connected element.

1. Study the metrics output.

1. Purposefully crash a process within the product.

2. Purposefully crash a managed element hosted process if funcitonality is available in the product.

3. Study the metrics output.



**Verdict:**
@@ -1653,7 +1663,8 @@ There are three different types of assessments used in this document. 


#### 6.3.6.6 REQ-METRICS-6



**Requirement:** Managed elements and system nodes and provided services availabilities and statuses shall be tracked and reported.<br/>

**Requirement a:** Managed elements availabilities and statuses shall be tracked and reported.<br/>

**Requirement b:** System and provided service availabilities and statuses shall be tracked and reported.<br/>

**Objective:** Bad availability can be a indication of compromise.<br/>

**Preparation:**
@@ -1677,7 +1688,7 @@ There are three different types of assessments used in this document. 


#### 6.3.6.7 REQ-METRICS-7



**Requirement a:** Relevant system database and storage health metrics like queries per second, latency and throughput shall be tracked and reported.<br/>

**Requirement a:** Relevant databases in the product and storage health metrics like queries per second, latency and throughput shall be tracked and reported.<br/>

**Requirement b:** Relevant managed element database and storage health metrics like queries per second, latency and throughput shall be tracked and reported.<br/>

**Objective:** Bad service quality can be a indication of compromise.<br/>

**Preparation:**