[Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps) specifies supplementary requirements for the product-facing RDPS boundary and does not replace the requirements applicable to the product function as such.
### 5.2.1 Network segmentation
The best practise is to use dedicated network segment for network management and control traffic.
Management traffic can be configuration updates, encryption keys, software updates, and others alike.
With segmentation, protection of management traffic is dependent on:
* capabilities the product
* deployment assumptions
* the operational environment capabilities
This is often implemented with:
* supporting more than one interface for the workload
* dedicated RFC1918 subnets for the traffic
* protecting the subnet from rogue actors
* deployment guidance
* product architecture
Many of the items above are operational environment requirements, and often product user's responsibility to implement correctly.
Using segmentation makes it easier to detect undesried traffic in the management network.
It limits the attack surface from other connected networks, but it does not remove integrity, confidentiality and authentication requirements.
Management traffic in this context refers to command and control instructions, that changes the system operation or the managed network element operation.
Low:
***CYB-NETWORK-1a** Network segmentation shall be used where applicable.
Medium:
***CYB_NETWORK-1b** Available interfaces shall accept traffic only from reasonably limited known sources.
High:
***CYB_NETWORK-1c** Available interfaces shall accept traffic only from a dedicated virtually or physically connected subnet.
## 5.3 No known exploitable vulnerabilities
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (a).
@@ -1147,8 +1109,6 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
<mark>[REQ-TECH-0] assesment: Needs the documentation trick.</mark>
For low risk:
***SBD_TECH-1** The product shall be shipped without unknown interfaces.
***SBD_TECH-2** The product shall not connect to unknown RDPS services.
***SBD_TECH-3** The product shall implement **CON_CRYPTO-1** in all interfaces, expect the ones that are available and reachable only in localhost by the local processes.
***SBD_TECH-4** When privileged information is transferred or accessed, a [5.7.2 Secure channel](#572-secure-channel) shall be used in transport.
@@ -1429,6 +1389,11 @@ This intervention enables the administrator to transfer the seed of trust.
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (g).
***DM_RETENTION-1** The product shall define what is logged, and how long that record is kept.
***DM_RETENTION-2** The product shall define what metrics are gathered, and how long that record is kept.
***DM_RETENTION-3** Metrics cadence, accuracy and storage time shall be described for the user.
***DM_RETENTION-4** The product shall not collect data unrelated to the purpose of the product operation.
## 5.10 Availability protection
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (h).
@@ -1483,22 +1448,61 @@ DDoS mitigations:
## 5.11 Non-interference
<mark>_Proposed ESR code: IM_</mark>
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (i).
## 5.12 Attack surface minimisation
### 5.11.1 Network segmentation
The best practise is to use dedicated network segment for network management and control traffic.
Management traffic can be configuration updates, encryption keys, software updates, and others alike.
With segmentation, protection of management traffic is dependent on:
* capabilities the product
* deployment assumptions
* the operational environment capabilities
This is often implemented with:
* supporting more than one interface for the workload
* dedicated RFC1918 subnets for the traffic
* protecting the subnet from rogue actors
* deployment guidance
* product architecture
Many of the items above are operational environment requirements, and often product user's responsibility to implement correctly.
Using segmentation makes it easier to detect undesried traffic in the management network.
It limits the attack surface from other connected networks, but it does not remove integrity, confidentiality and authentication requirements.
Management traffic in this context refers to command and control instructions, that changes the system operation or the managed network element operation.
<mark>_Proposed ESR code: MAS_</mark>
**Low**:
***IM_SEGMENT-1** Network segmentation shall be used where applicable.
**Medium**:
***IM_SEGMENT-2** Available interfaces shall accept traffic only from reasonably limited known sources.
**High**:
***IM_SEGMENT-3** Available interfaces shall accept traffic only from a dedicated virtually or physically connected subnet.
## 5.12 Attack surface minimisation
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (j).
***MAS_TECH-1** The product shall be shipped without unknown interfaces.
***MAS_TECH-2** The product shall not connect to unknown RDPS services.
## 5.13 Exploit mitigation
<mark>_Proposed ESR code: EMM_</mark>
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (k).
<mark>Stuff from VPN about memory safety.</mark>
## 5.14 Monitoring
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (l).
@@ -1512,88 +1516,94 @@ The logging requirements in this subclause define baseline event recording and a
For **low** risk:
***MON_LOG-0a** The log file of events shall be protected from unauthorised access.
***MON_LOG-0b** The log data of events shall be protected from modification including their deletion.
***MON_LOG-0c** The log data of events shall be confidentiality protected.
***MON_LOG-0d** The log shall include event time, actor identity, action type, and affected non-sensitive scope and object identifiers.
***MON_LOG-0e** The product shall monitor and log all received relevant events from its managed elements, including, not conclusive, incidents, alarms, time and clock shift alarms.
***MON_LOG-0f** The product shall define what is logged, and how long that record is kept.
***MON_LOG-1** The log data of events shall be protected from unauthorised access.
***MON_LOG-2** The log data of events shall be protected from modification including their deletion.
***MON_LOG-3** The log data of events shall be confidentiality protected.
***MON_LOG-4** The log information shall include the following fields including, but not limited to, event time, actor identity, action type, and affected non-sensitive scope and object identifiers.
***MON_LOG-5** The product shall log all received relevant events from its managed elements including, but not limited to, incidents, alarms, time shift alarms.
The following requirements apply where the corresponding function exists:
***MON_LOG-1a** The product shall generate auditable events for successful and failed authentication events.
***MON_LOG-1b** The product shall generate auditable events for session establishment attempts with source details.
***MON_LOG-1c** The product shall generate auditable events for session termination events with reason.
***MON_LOG-1d** The product shall generate auditable events for session validation checks like number of concurrent sessions.
***MON_LOG-1e** The product shall generate auditable events for privilege and role changes.
***MON_LOG-1f** The product shall generate auditable events for configuration changes.
***MON_LOG-1g** The product shall generate auditable events for device enrollment and unenrollment.
***MON_LOG-1h** The product shall generate auditable events for trust-anchor changes.
***MON_LOG-1i** The product shall generate auditable events for policy changes.
***MON_LOG-1j** The product shall generate auditable events for credential changes.
***MON_LOG-2a** The product shall log boot or initialisation events including timestamped boot stage progression.
***MON_LOG-2b** The product shall log boot or initialisation events including software component verification and initialisation actions.
***MON_LOG-2c** The product shall log boot or initialisation events including recovery mode activations if in use.
***MON_LOG-3c** The product shall log events described by [5.3.4 Secure updates].
***MON_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.
***MON_LOG-6** The product shall generate auditable events including, but not limited to:
* successful and failed authentication events
* session establishment attempts with source details
* session termination events with a reason
* session validation checks like number of concurrent sessions
* privilege and role changes
* configuration changes
* device enrollment and unenrollment
* trust-anchor changes
* policy changes
* credential changes
* events described by [5.5 Security updates](#55-security-updates)
* installation successes and failures in the managed devices, if that information can be extracted from the targets
* installation successes and failures in the product itself
***MON_LOG-7** The product shall log boot or initialisation events including but not limited to:
* timestamped boot stage progression
* software component verification and initialisation actions
* recovery mode activations if in use
For **medium** risk:
***MON_LOG-4:** The log information shall have an active backup scheduled.
***MON_LOG-5:** Administrative log records, traces and events shall be forwarded to or stored in a service that prevents unauthorized modification or deletion of recorded entries.
***MON_LOG-8:** The log information shall have an active backup scheduled.
> Clarification: write only service can be append only or even idempotent upsert system that does not let the received message to be altered later.
> The aim is to prevent a possible attacker to clear its traces by deleting the actions done in the system by distorting the history.
> NOTE: The purpose of **MON_LOG-8** is to prevent a possible attacker to clear its traces by deleting the actions done in the system by distorting the history.
For **high** risk:
***MON_LOG-6** The product shall support forwarding of relevant administrative events to an external logging or SIEM system.
***MON_LOG-7** SIEM transfer format, field attributes and event descriptions shall made available in a machine readable format.
***MON_LOG-8** Exported artifacts shall preserve essential fields at least, but not limited to: time, actor, action type, affected scope, result.
***MON_LOG-9** The product shall record provenance sufficient to attribute the change to an actor and context information related to at least, but not limited to: user, automated workflow, policy or rule identifier, and triggering event reference.
***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:
* 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:
* authorative subject
* automated workflow if relevant for the event context
* policy or rule identifier
* and triggering event reference.
> NOTE: **MON_LOG-12** describes privlege escalations that are done in computation. A common tactic to infiltrate a system is to trick it to escalate attacker privileges.
### 5.14.2 Metrics
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.
Fulfilment of these requirements 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.
General requirements:
***MON_METRICS-0** The product shall be designed in a way that collected and stored metrics data can not be altered.
***MON_METRICS-1** Historical metrics data import overwriting an existing data point shall be noticed.
***MON_METRICS-2** Metrics name, purpose, and value interpretation shall be described for the user.
***MON_METRICS-3** Metrics cadence, accuracy and storage time shall be described for the user.
***MON_METRICS-9** The product shall not collect data unrelated to the purpose of the product operation.
***MON_METRICS-1** The product shall be designed in a way that collected and stored metrics data can not be altered.
***MON_METRICS-2** Historical metrics data import overwriting an existing data point shall be noticed.
***MON_METRICS-3** Metrics name, purpose, and value interpretation shall be described for the user.
> NOTE: **MON_METRICS-1**, **MON_METRICS-2** and **MON_METRICS-3** requirements apply to all collected metrics.
Availability, uptime, and application metrics requirements:
Availability and uptime requirements:
***MON_METRICS-4** The product shall collect, track and store metrics on, including, but not limited to:
* availability and status changes, like process and service crashes and restarts
* incidents
* relevant operative information like CPU, memory, disk utilisation
* relevant networking metrics like throughput and protocol errors
* relevant databases and storage health metrics like queries per second, latency and throughput
* GUI and API latencies, where available
***MON_METRICS-4** Relevant system and connected element metrics like CPU, memory, disk utilisation shall be tracked and reported.
***MON_METRICS-5a** System incidents, such as process and service crashes and restarts, shall be tracked and reported.
***MON_METRICS-5b** Managed element incidents, such as process and service crashes and restarts shall be tracked and reported.
***MON_METRICS-6a** Managed elements availabilities and statuses shall be tracked and reported.
***MON_METRICS-6b** System and provided service availabilities and statuses shall be tracked and reported.
***MON_METRICS-7a** Relevant databases in the product and storage health metrics like queries per second, latency and throughput shall be tracked and reported.
***MON_METRICS-7b** Relevant managed element database and storage health metrics like queries per second, latency and throughput shall be tracked and reported.
***MON_METRICS-8** Relevant networking metrics like throughput and protocol errors shall be tracked and reported.
from the following targets:
The **MON_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 **MON_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.
* managed elements, where such metrics are available or can be reasonably synthetised
* provided services
* the system itself.
The **MON_METRICS-8** and **MON_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.
The product can be a host to an ecosystem that exposes managed elements capacity for 3rd. party applications.
The product can operates as a runtime for the workload, and effectively inherits operating system like responsibilies and funcionalities.
Application metrics requirements:
The **MON_METRICS-4** 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.
***MON_METRICS-9** Relevant application metrics, like GUI and API latencies and error rates, shall be tracked and reported.
> NOTE: Relevancy of the metric depends on the protocols in use, the product design and the operative environment makes available.
Matching tests for these requirements are listed in [6.3.6 Metrics tests].
What metrics and logs can be collected is defined in more detail in [5.9 Data minimisation](#59-data-minimisation).
## 5.15 Factory reset and data portability
@@ -1827,29 +1837,6 @@ Verify that:
## 6.4 Secure by default configuration
### 6.4.1 SBD_TECH-1
**Objective:** How the product communicates is understood and documented.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the technical documentation.
1. Study the listed documented communication endpoints.
1. List all the interfaces the product is listening.
1. Cross-reference the open interfaces to the documentation.
**Verdict:**
1. Pass, if all interfaces used for communication are documented.
2. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
### 6.4.4 SBD_TECH-4
**Objective:** Protect the integrity of the data.<br/>
@@ -2155,13 +2142,36 @@ Verify that:
## 6.12 Attack surface minimisation
### 6.12.1 MAS_TECH-1
**Objective:** How the product communicates is understood and documented.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the technical documentation.
1. Study the listed documented communication endpoints.
1. List all the interfaces the product is listening.
1. Cross-reference the open interfaces to the documentation.
**Verdict:**
1. Pass, if all interfaces used for communication are documented.
2. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
## 6.13 Exploit mitigation
## 6.14 Monitoring
### 6.14.1 Logging tests
#### 6.14.1.8 REQ-LOG-8
#### 6.14.1.10 MON_LOG-10
**Objective:** Reduces vendor lock-in and supports incident response and CRA evidence portability.
**Preparation:** None<br/>
@@ -2175,7 +2185,7 @@ Verify that:
1. Pointers to the documentation.
### 6.14.1.9 REQ-LOG-9
#### 6.14.1.12 REQ-LOG-12
**Objective:** Enables audit replay and accountability for automated control planes. Reduces ambiguity in incident investigations.
