@@ -176,18 +176,6 @@ This standard does not cover products in use in contexts other than those identi
## 2.1 Normative references
> **In Harmonised Standards these references shall be specific** (identified by date of publication and/or edition number or version number) **publicly available and in English, except in exceptional circumstances making sure that impacts have been evaluated and explanations have been given on how any negative implications should be avoided** . See clauses 2.10.1 and 8.4 of the [EDRs](EDRs) and the communiqué on "[References in ETSI Deliverables](https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/News_from_editHelp/References_in_ETSI_deliverables.pdf)".
>
> Guidance for selecting normative references in harmonised standards is given in clause 2.8.3 of the Vademecum on European standardisation. Please **systematically consult with your Technical Officer** for the latest guidance on normative references other than to ENs, ISO/IEC standards, notably to prevent the risk of non-acceptance.
>
> **Legal acts can never be used as normative references.**
>
> It is recommended that the number of references be limited to the minimum needed for the implementation/application of the ETSI Deliverables. References not directly concerned with the implementation/application/understanding of the ETSI Deliverable shall be listed in the Bibliography annex.
>
> References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
>
> Referenced documents which are not found to be publicly available in the expected location might be found in the [ETSI docbox](https://docbox.etsi.org/Reference/).
> NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long-term validity.
The following referenced documents are necessary for the application of the present document.
@@ -692,24 +680,14 @@ Manfacturer shall implement logging system features listed in the table below.
| [LOG-0] | All system clocks are synchronized to a NTP server or similar. |
| [LOG-1] | From the running process, it is impossible to overwrite the stored log output. |
| [LOG-2] | Technical documentation specifies how to integrate into an external logging system. |
| [LOG-3] | Detailed information of all emitted events is available. |
| [LOG-4] | National MSAs are able to validate the system design comformity without a deployment. |
| [LOG-5a] | All system clocks, including the managed elements, are being tracked. |
| [LOG-5b] | System clock deviation is available as a metric. |
| [LOG-6a] | SIEM event for anomalities in clock accuracy is included in the technical documentation. |
| [LOG-6b] | SIEM event is emitted when clock anomalies occur. |
### 5.3.x Monitoring
Reasoning for monitoring requirements is often justified by data integrity protection. Faults can not be detected, if an attacker can hide it's existense.
General:
-**[MON-0]** Collected and stored metrics data can not be altered from the target.
-**[MON-1]** Historical metrics data imports are handled outside of the normal flow.
-**[MON-1]** Historical metrics data import overwriting an existing data point is noticed.
-**[MON-2]** Metric name, purpose, value interpretation are described in the technical documentation.
-**[MON-3]** Metrics cadence, accuracy and storage time is defined in the technical documentation.
-**[MON-4]** System does not collect metrics that are not directly used in operative purposes.
@@ -751,24 +729,56 @@ Manfacturer shall implement monitoring system features as listed in the table be
**[MON-0]** Collected and stored metrics data can not be altered from the target.
> This section should not add requirements that are not already specified in 5. Requirements Specifications.
> Section shall define how the requirements in section 5 can be assessed objectively and repeatedly.
> There shall be at least one assessment per requirement, there can be more than one per requirement.
> Initially proposed format to define the assessment, to be further finetuned
> 1. **Assessment Reference**: Identifies the link to the exact requirement ID(s). (the requirement)
> 1. **Assessment Objective**: Defines the security property or capability that shall be verified, ensuring that the assessment remains focused on the intent of the requirement.
> 1. **Assessment Preparation**: Describes the environment, setup, and preconditions required before executing the test. (tool, guidance)
> 1. **Assessment Activities**: Provides execution steps to be performed. Activities are designed to cover the necessary rigor depending on whether the requirement is Basic, Elevated, or Advanced. (test, result)
> 1. **Assignment of Verdict**: Defines the pass/fail criteria. The assessment is considered successful if the requirement’s protection goals are demonstrably met; it fails if unauthorized access, modification, or bypass is possible, or if required security capabilities are unsupported. (treshold)
> 1. **Supporting Evidence**: Lists the artefacts to be collected and documented, such as logs, configuration files, screenshots, vendor documentation, and test results. Evidence ensures traceability and allows independent review. (test or assesment output)
Test: Review the documentation of all of the interfaces between the target and the collected and stored metrics data looking for any interface that may allow alteration of the metrics data after it has left the target.
Result: No interface allows the alteration of collected metrics data after it has left the target.
## 6.2 Technical security requirement tests and assesments
**[MON-1]** Historical metrics data imports are handled outside of the normal flow.
## 6.3 Risk mitigations tests
Test: Set up the product to provide output that distinguishes the method of handling both normal metrics data collection and historical data imports. Set up the product to collect metrics data in the normal manner from a client and begin collection. Collect output showing the whether the current metrics data is being handled by the normal flow. Now begin a historical data metrics import. Collect output showing the whether the current metrics data is being handled by the normal flow.
### 6.3.x Logging tests
Result: Output shows that the historical data metrics import is being handled by a different flow from the current metrics data collection.
| [LOG-0] | All system clocks are synchronized to a NTP server or similar. |
| [LOG-1] | From the running process, it is impossible to overwrite the stored log output. |
| [LOG-2] | Technical documentation specifies how to integrate into an external logging system. |
| [LOG-3] | Detailed information of all emitted events is available. |
| [LOG-4] | National MSAs are able to validate the system design comformity without a deployment. |
| [LOG-5a] | All system clocks, including the managed elements, are being tracked. |
| [LOG-5b] | System clock deviation is available as a metric. |
| [LOG-6a] | SIEM event for anomalities in clock accuracy is included in the technical documentation. |
| [LOG-6b] | SIEM event is emitted when clock anomalies occur. |
#### 6.3.x Monitoring tests
**[MON-0]** Collected and stored metrics data can not be altered.
**Test**: Review the documentation of all components between the target and the collected and stored metrics data looking for any step that may allow alteration of the metrics data after it has left the target.
**Result**: No process step allows the alteration of collected metrics data after it has left the target.
Output: Output showing which flow is being used to handle each of current metrics collection and historical metrics data import.
**[MON-1]** Historical metrics data re-imports and rewrites are noticed.
TBD:
**Test**: Set up the product to collect timeseries data in the normal manner from a client and begin collection. Collect output showing the whether the current metrics data is being handled by the normal flow. Re-import or resend the same set of data, but with modified values.
**Result**: System output shows that the re-import of the timeseries was overwriting an existing set of values and if the new value was accepted or discarded.
| [MON-2] | National MSAs are able to validate the system design comformity without a deployment. |
| [MON-3] | National MSAs are able to validate the system design comformity without a deployment. |
| [MON-4] | <mark>How to define business continuity metrics? A new chapter?</mark> |
@@ -780,11 +790,7 @@ TBD:
| [MON-10] | Relevant metrics are documented and presented to the user in the GUI. |
| [MON-11] | Relevant metrics are documented and presented to the user in the GUI. |
# 6 Security Profiles
## 6.1 General
# Annex A (informative): Mapping between the present document and CRA requirements
# Annex A (informative): Mapping with essential requirements of the CRA
> Table mapping technical security 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 security requirements.
@@ -796,7 +802,7 @@ TBD:
| Secure updates | |
| Authentication and access control mechanisms | [5.3.1] |
| Confidentiality protection | [5.3.2] |
| Integrity protection for data and configuration | [5.3.2], [5.3.3] |
| Integrity protection for data and configuration | [5.3.2], [5.3.3], [5.3.x Monitoring](#53x-monitoring) |
| Data minimization | |
| Availability protection | |
| Minimize impact on other devices or services | [5.3.x High Availability](#53x-high-availability) |
