Commit 8e768124 authored by Santeri Toikka's avatar Santeri Toikka
Browse files

Added 5.7 Confidentiality protection assessments

parent 73c22b48

EN-304-621_revised_structure.md

+154 −19
Original line number Diff line number Diff line
@@ -1307,9 +1307,11 @@ How the retake of the authority is implemented is between the product and the de 
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (e).



* **CON_INGEST-1** The collected network element monitoring data shall be integrity and confidentiality protected.

* **CON_INGEST-2** The product shall protect data at rest.

* **CON_INGEST-3** The product shall protect data in transit.

* **CON_INGEST-4** When data relevant to monitoring, control, or security functions is transferred over connections not controlled by the product, the product shall provide measures appropriate to the intended and reasonably foreseeable use to protect the integrity and, where required, the confidentiality of that data.

* **CON_INGEST-2** The product shall cryptographically protect relevant data at rest and in transit, including but not limited to:

  * secrets

  * confidential configuration data

  * metrics that can expose confidential data

* **CON_INGEST-3** When data relevant to monitoring, control, or security functions is transferred over connections not controlled by the product, the product shall provide measures appropriate to the intended and reasonably foreseeable use to protect the integrity and, where required, the confidentiality of that data.



Products are delivered without known exploitable vulnerabilities and that comprises also implemented cryptography.

However, certain use cases or the product installation into a present user infrastructure may require the use of legacy protocols and cryptography.
@@ -1330,6 +1332,9 @@ As the product is delivered without known exploitable vulnerabilities, those leg 
          6. the cryptographic mechanism is required for a specific set of product functions;

          7. <mark>[any additional criteria specified by the vertical standard, where applicable]</mark>.

    3. Interoperability-based: the cryptographic mechanism is listed in clause K.4.2 as an interoperability-based cryptographic mechanism for specific product function(s) and external specification(s) or external requirement(s).

* **CON_CRYPTO-2** To prevent rollback or downgrade [i.10] the product shall:

  * enforce a monotonic policy/configuration version (or equivalent mechanism);

  * prevent re-enabling deprecated algorithms or disabled security checks via rollback without an explicit logged administrative override.



> NOTE 1: The reference to the product’s default configuration is intended to define a clear and assessable baseline, corresponding to the configuration in which the product is placed on the market. The product can provide several configurations that fulfil the requirement.
@@ -1351,16 +1356,8 @@ A **secure channel** used in transportation is a cryptographically protected com 
When privileged information is transferred or accessed, the transport channel provides confidentiality, integrity protection, endpoint authentication, and protection against downgrade to less secure configurations.

TLS may be used for this purpose, but other mechanisms may also be used where they provide an equivalent level of protection and are implemented as defined in Annex K.



* **CON_CRYPTO-2** To prevent rollback or downgrade:

  * the product shall enforce a monotonic policy/configuration version (or equivalent mechanism);

  * the product shall record changes in tamper-evident audit logs;

  * the product shall prevent re-enabling deprecated algorithms or disabled security checks via rollback without an explicit logged administrative override.



* **CON_CHANNEL-1** The product shall ensure that the channel uses cryptographic functions and configuration according to the **CON_CRYPTO-1**.

* **CON_CHANNEL-2** All endpoints in a secure channel shall cryptographically verify others through mutual auhentication.

* **CON_CHANNEL-3** The product shall ensure that the channel can not be impaired by downgrading it [i.10].

* **CON_CHANNEL-4** The product shall implement secure channel as per Annex K.

* **CON_CHANNEL-5** The product shall protect the data transfer, the confidentiality and the integrity of the data according to the requirements of the foreseeable use.



![Figure 5.7.2-1: Secure channel example with TLS originated by managed device](./media/52_secure_channel_example.drawio.png)
@@ -1577,18 +1574,19 @@ The following requirements apply where the corresponding function exists: 
For **medium** risk:



* **MON_LOG-8:** The log information shall have an active backup scheduled.

* **MON_LOG-9:** The audit logs shall be tamper-evident.



For **high** risk:



* **MON_LOG-9** The product shall support forwarding of relevant administrative events to an external logging or SIEM system.

* **MON_LOG-10** Logging or SIEM event data transfer format, field attributes and event descriptions shall made available in a machine readable format.

* **MON_LOG-11** Exported log data artifacts shall preserve essential fields at least, but not limited to:

* **MON_LOG-10** The product shall support forwarding of relevant administrative events to an external logging or SIEM system.

* **MON_LOG-11** Logging or SIEM event data transfer format, field attributes and event descriptions shall made available in a machine readable format.

* **MON_LOG-12** Exported log data artifacts shall preserve essential fields at least, but not limited to:

  * timestamp when the event occured

  * actor

  * action type

  * affected scope

  * result.

* **MON_LOG-12** The product shall record provenance sufficient to attribute the change to an actor and context information related to at least, but not limited to:

* **MON_LOG-13** The product shall record provenance sufficient to attribute the change to an actor and context information related to at least, but not limited to:

  * authorative subject

  * automated workflow if relevant for the event context

  * policy or rule identifier
@@ -1900,6 +1898,117 @@ Verify that: 


## 6.7 Confidentiality protection



### 6.7.1 CON_INGEST-1



**Objective:** Protect the ingested data confidentiality.<br/>

**Preparation:**



1. Have the product initialised and available with the default configuration and required credentials;

2. Study the technical documentation.



**Activities:**



1. Study the monitoring data ingestion:

   1. The receeption and/or querying mechanism

   2. The ingestion workflow steps

   3. Intermediate storages used in the processing

   4. The enrichment and filtering of data ingestion

   5. The communciation between the systems involved in the processing

2. The storage systems used to serve the data for later use.



**Verdict:**



1. Pass, confidentiality is uphold in the data ingestion.

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.7.2 CON_INGEST-2



**Objective:** Protect the ingested data confidentiality.<br/>

**Preparation:**



1. Extending the assessment defined in [6.7.1 CON_INGEST-1](#671-con_ingest-1)



**Activities:**



1. Study the listed relevant data handling



**Verdict:**



1. Pass, if the data in rest and in transit follows Annex K guidance with the default configuration.

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.7.3 CON_INGEST-3



**Objective:** Protect the ingested data confidentiality.<br/>

**Preparation:**



1. Extending the assessment defined in [6.7.1 CON_INGEST-1](#671-con_ingest-1)



**Activities:**



1. Study the access methods, where the connection to query the data is initiated outside of the product;

2. Initiate such query targeting relevant data.

3. Investigate the system response.



**Verdict:**



1. Pass, if the data in transit follows Annex K guidance with the default configuration

2. and the response is reasonably protecting the data in rest.

3. 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.7.1 State-of-the-art cryptographic libraries



#### 6.7.1.1 CON_CRYPTO-1



Assesments are defined in [Annex K](#annex-k-normative-generic-cryptographic-requirements-and-assessment)



#### 6.7.1.2 CON_CRYPTO-2



**Objective:** Prevent attackers to modify the connectivity to more favorable chipher suite.<br/>

**Preparation:**



1. Have the product initialised and available with the default configuration and required credentials;

2. Study the technical documentation.



**Activities:**



1. Study the product operation.



**Verdict:**



1. Pass, if the listed requirements are implemented.

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.7.2.1 CON_CHANNEL-1



**Objective:** The implementation and operation follows the Agreed Cryptographic Mechanisms specification and the Annex K.<br/>
@@ -2738,7 +2847,33 @@ Verify that: 
* 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.14.1.8 MON_LOG-9

#### 6.14.1.9 MON_LOG-9



**Objective:** Prevent a possible attacker to clear its traces by deleting the actions done in the system by distorting the history.<br/>

**Preparation:**



1. Have the product initialised and available with the default configuration and required credentials;

2. Study the technical documentation how to interact with the system.



**Activities:**



1. Identify how the logging mechanism works;

2. Change the logging storage outside of the system control while maintaining the schema.



**Verdict:**



1. Pass if modification was noticed.

2. Fail otherwise.



**Supporting Evidence:**



* Metrics output showing detected system or managed element crash or restart with the reported cause;

* 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.14.1.10 MON_LOG-10



**Objective:** Prevent a possible attacker to clear its traces by deleting the actions done in the system by distorting the history.<br/>

**Preparation:**
@@ -2765,7 +2900,7 @@ Verify that: 
* 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.14.1.10 MON_LOG-10

#### 6.14.1.11 MON_LOG-11



**Objective:** Reduces vendor lock-in and supports incident response and evidence portability.<br/>

**Preparation:** None<br/>
@@ -2779,7 +2914,7 @@ Verify that: 


1. Pointers to the documentation.



#### 6.14.1.11 MON_LOG-11

#### 6.14.1.12 MON_LOG-12



**Objective:** Ensure operations visibility in the third party connected system.<br/>

**Preparation:**
@@ -2805,7 +2940,7 @@ Verify that: 
* 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.14.1.12 MON_LOG-12

#### 6.14.1.13 MON_LOG-13



**Objective:** Enables audit replay and accountability for automated control planes. Reduces ambiguity in incident investigations.<br/>

**Preparation:** None<br/>