Verified Commit 56867892 authored by Marvin Petzolt's avatar Marvin Petzolt Committed by Aki Braun
Browse files

This is a combination of 26 commits.

DNS routing is not a primary use-case for mesh. Mesh networks focus on connecting endpoints together, but do not nessecary tunnel internet traffic, but rather create a vLAN

updated table

updated table

Apply logging to remote serever requirements to enterprise

with distinctive requirement for logging to RDPS or not

Removed that personal data can not be logged

Updated numbering

Added and updated assessment criteria

More cleary differentiate as-yet-unnumbered requirements

Hard to review things that are numbered wrong, sorry about that.

That means list items too

And you 🤦🏻‍♀️



sorry, for the noise. the caffiene hasn't kicked in yet

Updates based on discussion with legal

Revert change

Apply 1 suggestion(s) to 1 file(s)

Co-authored-by: default avatarAki Braun <a@expertzebra.com>

Added note on logging free text inputs

Specified injection attack

removed unnessecary 'internal'

Removed internal from 5.

Spelling fixes

Spelling fix

Addressed comments on MR

Apply 1 suggestion(s) to 1 file(s)

Co-authored-by: default avatarAki Braun <a@expertzebra.com>

ESR 14 Language tweaks for consistency and clarity

Edit Annex R for application to EN 304 620

Move no data persistence to Data Minimisation clause

Clearer langauge for DNS query "monitoring"

Annex B.1: Expand with explanation, more assets, impact/value

closes #342

Clause 5.1: explain relationship of assets, risk factors, requirements

closes #344

Annex C.2.8 predictable -> reliable

close #346

Annex C.2.8: Make DNC-1 and DNC-2 exclusive

closes #347

Annex C.2.10: explain rationale for increased risk

closes #351

Annex C.2.1: Add link from risk factors to risk factors level definition

closes #356

Annex C.2.6: Improve rationale for admin risk factor

closes #366

Annex C.2.7: Improve rationale for RDPS factor

closes #368

Annex C.2.10: Add guidance to COM risk factor

closes #348

Remove rogue merge artifact from Clause 5.13.4

Clause 5/6 Update requirements for risk transfer to operational environment

Explcitly exempt enterprise VPNs from requirements using transfer of
risk to the operational environment via the "REQ-1 or REQ-2"
construct. Limit this exemption to mitigations for threats that the
operational environment can mitigate, like denial of service attacks
but not credential cloning. Remove accidental inclusion of "no traffic
routing through node by default" requirement for UC-6. Remove
documentation of risk transfer for denial of service from the
remaining use cases.

closes #483

Annex B (was C): remove rogue "must"

Annex C.3: Explain role of assumptions and remove identifiers

Clause 5.5: Remove redundant and not allowed secure update documentation reqs

We can't require documentation and these are redundant with update via
operational environment (coming soon as an expansion of the
administrator options).

Remove 5.10.6 REQ-AP-06 (MI-DOST-3) as redundant to Annex R
parent 46abdf71
Loading
Loading
Loading
Loading
+83 −41
Original line number Diff line number Diff line
@@ -356,7 +356,7 @@ A **VPN gateway** specifically fulfills the gateway role, acting as the secure b

#### 4.2.4.2 Server & gateway remote data processing

When VPNs are reliant on servers, gateways, or “exit nodes” operated by the manufacturer, those operations make up an important part of the product architecture. They typically serve the same functions as any other server or gateway, but remain entirely under the control of the manufacturer instead of being deployed on their customers’ infrastructure. Due to the fact that a VPN is unable to function without this manner of data processing, it is held to the same requirements as any other VPN server or gateway, in addition to the requirements laid out in Annex R.
When VPNs are reliant on servers, gateways, or “exit nodes” operated by the manufacturer, those operations make up an important part of the product architecture. They typically serve the same functions as any other server or gateway, but remain entirely under the control of the manufacturer instead of being deployed on their customers’ infrastructure. Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, such reliance introduces a product-facing RDPS boundary between the local product side and the RDPS side. RDPS-side VPN servers and gateways are held to the same requirements as any other VPN server or gateway, in addition to the requirements laid out in Annex R.

### 4.2.5 Management server

@@ -606,26 +606,35 @@ _Use technical language and focus what is relevant from a product perspective_

This annex applies state-of-the-art methodology to identify threats and identify & evaluate risks based on product use cases.

The security analysis in this Annex represents a risk assessment done by the standardisers solely for the purpose of informing the applicability of technical requirements.

A list of product assets are used to identify potential threats to the product. The assumptions are used to define the scope of potential threats that are addressed by this security analysis.

Risk factor levels for each use case are determined by using the operational coenvironment of each use case to choose a risk factor level that most accurately represents the highest risk for that use case. The use case is determined by the intended purpose and reasonably foreseeable use specified by the manufacturer.

For each threat, a formula based on the risk factor levels is used to calculate the likelihood and impact of the threat. This security analysis uses the likelihood and impact of each threat to identify specific technical requirements that treat that risk.

## B.1 Assets

(previously ## B.1)
(previously ## C.1)

The purpose of cybersecurity is to protect the product assets, which include product data, product functions, digital assets, human-related assets, and hardware. The compromise of each type of asset will have a different impact on the cybersecurity and the functionality of the product. Each asset has a corresponding value to the cybersecurity of the asset.

### B.1.1 Data
### B.1.1 Data assets

(previously ### C.1.1)

- Data transmitted over the VPN network
- Management and configuration data
  - Configuration data
  - Management application certificates
  - CA information, certificates & keys (public, private, PSK)
  - End-point details including authentication, location, and potential Personal Data
- Statistics and telemetry data
  - Network configuration audit logs
  - Network flow logs and other statistics about data transferred over the network
  - Debugging logs from end-points and VPN gateways
- Software applications
  - Device-native applications for connecting to the network (Client or Node software)
| Asset                                 | Compromise impacts                    | Value  |
|---------------------------------------|---------------------------------------|--------|
| Data transmitted over the VPN network | Confidentiality, integrity, functions | High   |
| Product configuration                 | Confidentiality, functions            | High   |
| CA information, certificates & keys   | Authorization/access control          | High   |
| Management application certificates   | Authorization/access control          | Medium |
| Logs with identifying information     | Confidentiality, monitoring           | Medium |
| Configuration audit logs              | Monitoring                            | Low    |
| Network statistics                    | Monitoring                            | Low    |
| Debugging logs                        | Monitoring                            | Low    |
| Telemetry                             | Monitoring                            | Low    |

### B.1.2 Product functions

@@ -633,12 +642,34 @@ This annex applies state-of-the-art methodology to identify threats and identify

A basic overview of VPN functions follows. See [clause 4.2](#42-product-architecture) for a detailed overview of the essential functions of a VPN product.

* Edge: uses a public network to communicate with the restricted use network
* Gateway: provides link between public network and restricted
* Router: forward traffic between nodes in the restricted use network
* Filter: select which traffic may transit this node
* Relays: assist nodes in connecting to the restricted use network
* Auth: grant nodes access to the restricted network
| Asset                                           | Compromise impacts            | Value  |
|-------------------------------------------------|-------------------------------|--------|
| Authentication/access control of VPN end-points | Authentication/access control | High   |
| Authentication/access control of VPN servers    | Authentication/access control | High   |
| Encryption of network traffic                   | Confidentiality               | High   |
| Privacy protection                              | Confidentiality               | High   |
| Network traffic routing/filtering/forwarding    | Access control, functions     | Medium |

### B.1.3 Digital assets

| Asset                      | Compromise impacts                            | Value        |
|----------------------------|-----------------------------------------------|--------------|
| VPN server applications    | Everything                                    | Astronomical |
| VPN end-point applications | All end-point assets, some VPN network assets | High         |

### B.1.4 Human-associated assets

| Asset          | Compromise impacts           | Value  |
|----------------|------------------------------|--------|
| Credentials    | Authorization/access control | High   |
| Identity       | Confidentiality              | High   |
| Location       | Confidentiality              | Medium |
| Personal data  | Confidentiality              | Medium |
| VPN usage data | Confidentiality              | Low    |

### B.1.4 Hardware assets

None for the products in the scope of this document.

## B.2 Risk factors

@@ -646,12 +677,16 @@ A basic overview of VPN functions follows. See [clause 4.2](#42-product-archite

### C.2.1 General

Risk factors determine which mitigation(s) satisfy each of the cybersecurity requirements in clause 5.2. The assessor of a product determines the level of each risk factor via the development of a threat model and risk profile based on the intended and foreseeable use and misuse of the VPN.
Risk factors influence the likelihood or impact of a threat to a product asset. Thus, risk factors determine which mitigation(s) satisfy each of the cybersecurity requirements in clause 5.

The creator of a product risk assessment determines the level of each risk factor via the development of a threat model and risk profile based on the intended purpose and foreseeable use of the VPN.

Risk factors may increase the likelihood of an incident, increase the impact of an incident, or both. As a result, different mitigation strategies may be more or less relevant to different risk factors.
Risk factors may increase one or both of the likelihood and impact of a compromise. As a result, different mitigation strategies may be more or less relevant to different risk factors.

The overall risk related to each use case should be considered as a result of combining risk factors affecting both likelihood and impact of an incident.

See Annex [C.4.2](#c42-security-analysis-methodology) for the definition of risk factor levels.

### C.2.2 RF-CFG: End-point configuration

Description: Affects likelihood of threats involving misconfiguration.
@@ -686,7 +721,7 @@ Rationale: Loss of product functions' availability can have a major impact on th

Description: What the availability and skill of administration is for the product.

Rationale: Skilled, fully resourced administration allows more risk transfer and can reduce the impact of incidents.
Rationale: Skilled, fully resourced administration allows proactive risk assessment and mitigation and can reduce the impact of incidents.

* **[ADM-0]** Skilled administration, fully resourced
* **[ADM-1]** Skilled administration, partially resourced
@@ -696,10 +731,10 @@ Rationale: Skilled, fully resourced administration allows more risk transfer and

Description: Exposure of manufacturer infrastructure responsible for essential functions of the product

Rationale: More users with physical access to manufacturer infrastructure increases likelihood of an attack via hardware interfaces.
Rationale: Rationale: More users accessing manufacturer infrastructure increases likelihood of an attack via hardware interfaces.

* **[RDP-0]** Manufacturer does not provide any remote data processing
* **[RDP-1]** Manufacturer provides RDPS via self-hosted infrastructure.
* **[RDP-1]** Manufacturer provides RDPS via self-hosted infrastructure
* **[RDP-2]** Manufacturer infrastructure located in a multi-tenant SaaS system

### C.2.8 RF-DNC: Difficulty of network configuration
@@ -709,7 +744,7 @@ Description: Difficulty of configuring, controlling, and monitoring the configur
Rationale: The more difficult it is to configure the network connection, maintain control over that configuration, and learn about changes to the configuration, the more likely it is that the configuration will become insecure.

* **[DNC-0]** Product has complete control over the network configuration
* **[DNC-1]** Product is using a well-defined, predictable platform service to configure the network connection
* **[DNC-1]** Product is using a well-defined, reliable platform service to configure the network connection but does not have total control of the configuration
* **[DNC-2]** Other software can change network configuration without notification or permission from the product

### C.2.9 RF-COM: Complexity of feature set
@@ -722,11 +757,13 @@ Rationale: More features mean more code and more interfaces mean attack surface.
* **[COM-1]** Usage requires a few additional features related to tunnelling encrypted traffic
* **[COM-2]** Usage requires many additional features

Guidance: At present, the complexity of the implementation and the exposed interfaces are accounted for in a single risk factor. This is sufficienty for the security analysis in the present document but may need to separated into two risk factors for future versions.

### C.2.10 RF-CON: Connectivity offered

Description: Whether the VPN connects different endpoints to each other via a private network or simply provides a tunnel from a single endpoint to a public network

Rationale: Different connectivity requirements create different risks and mitigations.
Rationale: More endpoints able to connect to each other within the private network means more risk of compromise via the shared private network connectivity and greater privileges often granted to endpoints sharing the private network.

* **[CON-0]** Usage is a single endpoint connecting only to a public network
* **[CON-1]** Usage is one or more endpoints connecting to other endpoints or hosts via a private network
@@ -744,21 +781,25 @@ Rationale: Different consequences change the impact of compromise of Protected D

## C.3 Assumptions

### C.3.1 Overview

Assumptions limit the scope of threats considered by this security analysis. A manufacturer's cybersecurity risk assessment may have a different scope.

### C.3.1 Platform

**[AS-PP]:** The platform the product is running on is trustworthy.
The platform the product is running on is trustworthy.

### C.3.2 Proper administrator

**[AS-PA]:** The product administrator is not intentionally hostile and is engaging in good faith efforts to administer the product properly.
The product administrator is not intentionally hostile and is engaging in good faith efforts to administer the product properly.

### C.3.3 Attacker has limited physical access to product

**[AS-LP]:** An attacker will have only temporary physical access to the platform running the product.
An attacker will have only temporary physical access to the platform running the product.

### C.3.4 Attacker has limited resources

**[AS-LR]:** An attacker will use limited resources in proportion to the value of the assets of the product in each use case.
An attacker will use limited resources in proportion to the value of the assets of the product in each use case.

## C.4 Threats and security analysis

@@ -778,7 +819,7 @@ Risk factor levels are determined by reading the descriptions for each risk fact

For each threat, a formula based on the risk factor levels is used to calculate the Likelihood and Impact of the threat, on a scale of Low, Medium, and High.

For each threat, both likelihood and impact must be Low before the risk is considered sufficiently mitigated. If the calculated levels are not already Low, then mitigations must be applied until both likelihood and impact are Low. The mitigation sets that will accomplish this are listed in each threat description.
For each threat, both likelihood and impact should be Low before the risk is considered sufficiently mitigated. If the calculated levels are not already Low, then mitigations should be applied until both likelihood and impact are Low. The mitigation sets that will accomplish this are listed in each threat description.

### C.4.3 TH-UEVU: Unknown exploitable vulnerabilities

@@ -1405,6 +1446,7 @@ _Editor's note: this table must be updated before the draft can be considered Fi
|    REQ-SSD-05 (MI-IMSL) |      |      |  x¹  |  x¹  |  x¹  |  x¹  |  x¹  |
|    REQ-SSD-06 (MI-SCFS) |  x   |  x   |  x   |  x   |  x   |  x   |  x   |
|    REQ-KEV-02 (MI-KEVT) |  x   |  x   |  x   |  x   |  x   |  x   |  x   |
|              REQ-SSD-07 |  x   |  x   |  x   |  x   |  x   |      |  x   |
|  REQ-SBD-02 (MI-CONF-5) |  x   |  x   |  x   |  x   |  x   |      |  x   |
|     REQ-SU-02 (MI-KEVD) |  x²  |  x   |  x   |  x   |  x   |      |  x   |
|     REQ-SU-03 (MI-KEVA) |  x²  |  x   |  x   |      |      |      |  x   |
@@ -1434,12 +1476,12 @@ _Editor's note: this table must be updated before the draft can be considered Fi
|  REQ-CON-03 (MI-ROUT-2) |      |  x   |  x   |  x   |  x   |  x   |  x   |
|  REQ-CON-04 (MI-ROUT-3) |  x   |  x   |  x   |      |      |      |      |
|  REQ-CON-05 (MI-ROUT-4) |      |      |      |      |      |      |  x   |
|  REQ-CON-06 (MI-DNSL-1) |      |  x   |  x   |  x   |  x   |      |  x   |
|  REQ-CON-07 (MI-DNSL-2) |      |  x   |  x   |  x   |  x   |      |  x   |
|  REQ-CON-08 (MI-DNSL-3) |      |      |  x   |  x   |  x   |      |  x   |
|  REQ-CON-09 (MI-DNSL-5) |      |      |  x   |  x   |  x   |      |  x   |
|  REQ-CON-06 (MI-DNSL-1) |      |  x   |  x   |  x   |  x   |      |      |
|  REQ-CON-07 (MI-DNSL-2) |      |  x   |  x   |  x   |  x   |      |      |
|  REQ-CON-08 (MI-DNSL-3) |      |      |  x   |  x   |  x   |      |      |
|  REQ-CON-09 (MI-DNSL-5) |      |      |  x   |  x   |  x   |      |      |
|  REQ-CON-10 (MI-DNSL-6) |      |      |  x   |  x   |  x   |      |      |
|  REQ-CON-11 (MI-DNSL-7) |      |  x   |  x   |  x   |  x   |  x   |  x   |
|  REQ-CON-11 (MI-DNSL-7) |      |  x   |  x   |  x   |  x   |  x   |      |
|  REQ-CON-12 (MI-IPV6-1) |  x   |  x   |  x   |  x   |  x   |  x   |  x   |
|  REQ-CON-13 (MI-IPV6-2) |  x   |  x   |  x   |  x   |  x   |  x   |  x   |
| REQ-CON-14 (MI-CRYPT-1) |  x   |  x   |  x   |  x   |  x   |  x   |  x   |
@@ -1452,19 +1494,19 @@ _Editor's note: this table must be updated before the draft can be considered Fi
|   REQ-DM-03 (MI-NPER-2) |      |      |  x   |      |      |      |      |
|   REQ-DM-04 (MI-NPER-3) |      |      |  x   |      |      |      |      |
|   REQ-DM-05 (MI-NPER-4) |      |      |  x   |      |      |      |      |
|   REQ-DM-06 (MI-LOGG-X) |      |  x   |  x   |      |      |      |      |
|     REQ-AP-02 (MI-FDRP) |  x   |  x   |  x   |  x   |  x   |      |      |
|     REQ-AP-03 (MI-LMEM) |      |  x   |  x   |  x   |  x   |      |      |
|   REQ-AP-04 (MI-DOST-1) |      |  x   |  x   |  x   |  x   |      |  x   |
|   REQ-AP-05 (MI-DOST-2) |  x   |  x   |  x   |  x   |  x   |      |  x   |
|   REQ-AP-06 (MI-DOST-3) |      |  x   |  x   |  x   |  x   |      |  x   |
|     REQ-IM-02 (MI-EISO) |  x   |      |  x   |      |      |      |  x   |
|  REQ-MAS-02 (MI-CONF-4) |      |  x   |  x   |  x   |  x   |  x   |  x   |
|  REQ-EMM-02 (MI-NUTI-1) |      |      |      |  x⁵  |  x   |      |      |
|  REQ-EMM-03 (MI-TRAF-2) |      |  x   |      |  x⁵  |      |  x   |  x   |
|  REQ-EMM-04 (MI-TRAF-3) |      |  x   |      |  x⁵  |      |      |  x   |
|  REQ-EMM-05 (MI-TRAF-4) |      |  x   |      |  x⁵  |      |  x   |  x   |
|  REQ-EMM-06 (MI-LOGG-X) |      |  x   |  x   |      |      |      |      |
|  REQ-LOG-02 (MI-LOGG-1) |  x   |  x   |  x   |  x   |  x   |  x   |  x   |
|  REQ-LOG-TK (MI-LOGG-1) |  x   |  x   |  x   |  x   |  x   |      |  x   |
|  REQ-LOG-02 (MI-LOGG-1) |      |      |      |      |      |  x   |      |
|  REQ-LOG-03 (MI-LOGG-2) |      |      |      |  x   |  x   |      |      |
|  REQ-LOG-04 (MI-LOGG-3) |      |  x   |  x   |      |      |      |      |
|    REQ-DRT-02 (MI-RSET) |  x   |  x   |  x   |  x   |  x   |  x   |  x   |
+119 −144

File changed.

Preview size limit exceeded, changes collapsed.

+77 −67
Original line number Diff line number Diff line
@@ -222,6 +222,10 @@ Otherwise FAIL
* Output of binary analysis tools demonstrating the presence of exploit mitigations
* Documentation of exceptions

### 6.2.7 REQ-SSD-07 Applicability of Annex R

See annex R.5 for full assessment criteria.

## 6.3 No known exploitable vulnerabilities

### 6.3.1 Overview
@@ -1694,6 +1698,39 @@ Otherwise FAIL
* Samples of stored data
* Documentation of why the samples don't contain Personal Data

### 6.9.6 REQ-DM-06 (MI-LOGG-X) No data persistence or storage enabled on exit nodes (MI-LOGG-X)

#### 6.9.6.1 Objective

Minimization of data compromise due to equipment compromise, Confidentiality of data.

#### 6.9.6.2 Preparation

1. Obtain the technical documentation detailing the server provisioning architecture for the remote data processing solutions.
2. Obtain administrative access to a test instance of the VPN exit node configured identically to the production environment.

#### 6.9.6.3 Activities

Perform steps in sequence:

1. Examine the server's operating system configuration (e.g., filesystem table/fstab, boot parameters) to verify that all system directories (including /var/log and temporary storage) are mounted exclusively on volatile memory (RAM disks).
2. Verify that unencrypted non-volatile swap partitions are disabled.
3. Generate network traffic through the test node, then power cycle (reboot) the server and inspect the storage.

#### 6.9.6.4 Verdict

PASS if **any** of the following are fulfilled:

* The server utilizes volatile disk-based storage for system logs, swap, or temporary processing, or
* data does not persist across a power cycle.

Otherwise FAIL

#### 6.9.6.5 Evidence

* Copies of the relevant server configuration files demonstrating the use of RAM disks
* The output of the storage inspection after the power cycle

## 6.10 Availability protection

### 6.10.1 Overview
@@ -1826,36 +1863,6 @@ Otherwise FAIL
* Network package capture
* Log messages

### 6.10.6 REQ-AP-06 (MI-DOST-3) Automatic traffic handling during denial-of-service attack

#### 6.10.6.1 Objective

Maintain service availability during denial-of-service attacks.

#### 6.10.6.2 Preparation

None

#### 6.10.6.3 Activities

1. Capture traffic on all interfaces,
2. start the VPN connection,
3. shutdown or disable traffic to the currently connected VPN server, and
4. observe automatic reconnection or traffic rerouting to the next available VPN server.

#### 6.10.6.4 Verdict

PASS if **all** of the following are fulfilled:

* Connection is automatically restored.

Otherwise FAIL

#### 6.10.6.5 Evidence

* Network package capture
* Log messages

## 6.11 Non-interference

### 6.11.1 Overview
@@ -2046,46 +2053,49 @@ Otherwise FAIL

* Documentation of services

### 6.13.6 REQ-EMM-06 (MI-LOGG-X) No data persistence or storage enabled on exit nodes (MI-LOGG-X)
## 6.14 Monitoring

#### 6.13.6.1 Objective
### 6.14.1 Overview

Minimization of data compromise due to equipment compromise, Confidentiality of data.
This clause provides assessment for the requirements in 5.14 relating to CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (l).

#### 6.13.6.2 Preparation
### 6.14.2 REQ-LOG-TK (MI-LOGG-1) Local event logging

1. Obtain the technical documentation detailing the server provisioning architecture for the remote data processing solutions.
2. Obtain administrative access to a test instance of the VPN exit node configured identically to the production environment.
#### 6.14.TK.1 Objective

#### 6.13.6.3 Activities
Monitoring and recording cybersecurity-relevant events.

Perform steps in sequence:
#### 6.14.TK.2 Preparation

1. Examine the server's operating system configuration (e.g., filesystem table/fstab, boot parameters) to verify that all system directories (including /var/log and temporary storage) are mounted exclusively on volatile memory (RAM disks).
2. Verify that unencrypted non-volatile swap partitions are disabled.
3. Generate network traffic through the test node, then power cycle (reboot) the server and inspect the storage.
Review the technical documentation to confirm the scope of cybersecurity-relevant events implemented in the logging mechanism.

#### 6.13.6.4 Verdict
#### 6.14.TK.3 Activities

PASS if **any** of the following are fulfilled:
For each type of cybersecurity-relevant event mentioned in 5.14.1.2:

* The server utilizes volatile disk-based storage for system logs, swap, or temporary processing, or
* data does not persist across a power cycle.
1. trigger the event on the endpoint, and
2. collect any locally generated log messages recording the event, and
3. capture any packets being transmitted to the manufacturer.

Otherwise FAIL
#### 6.14.TK.4 Verdict

#### 6.13.6.5 Evidence
PASS if **all** of the following are fulfilled:

* Copies of the relevant server configuration files demonstrating the use of RAM disks
* The output of the storage inspection after the power cycle
* at least one log message correlates to a cybersecurity-relevant event as listed in 5.14.1.2, and
* for each triggered event:
    * the collected log message reflects the cybersecurity-relevant event,
    * the log message indicating the event does not include any secrets, credentials, network traffic content or connection metadata as defined in 5.14.1.3, and
    * the log message indicating the event is not transmitted to the manufacturer without explicit user authorization, or the technical documentation provides a clear justification as to how such a transmission is required to fulfill the intended purpose of the product.

## 6.14 Monitoring
Otherwise FAIL

### 6.14.1 Overview
#### 6.14.TK.5 Evidence

This clause provides assessment for the requirements in 5.14 relating to CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (l).
* Method of triggering events
* Log messages with annotations
* Packet captures demonstrating no unauthorized transmission of logs

### 6.14.2 REQ-LOG-02 (MI-LOGG-1) Logging
### 6.14.2 REQ-LOG-02 (MI-LOGG-1) Internal event logging

#### 6.14.2.1 Objective

@@ -2093,24 +2103,23 @@ Monitoring and recording cybersecurity-relevant events.

#### 6.14.2.2 Preparation

Review the technical documentation to confirm the scope of cybersecurity-relevant internal events implemented in the logging mechanism.
Review the manufacturer's documentation to confirm the scope of cybersecurity-relevant events implemented in the logging mechanism.

#### 6.14.2.3 Activities

For each type of cybersecurity-relevant internal event (authentication, connection state change, configuration modification, etc.):
For each type of cybersecurity-relevant event mentioned in 5.14.1.2:

1. trigger the event on the endpoint, and
2. attempt to locate any automated transmission of these logs to the manufacturer without explicit user consent.
2. collect any locally generated log messages recording the event.

#### 6.14.2.4 Verdict

PASS if **all** of the following are fulfilled:

For each triggered event:

* the local log contains a message indicating the event,
* log message does not include any information likely to be confidential, and
* logs are not transmitted to the manufacturer without explicit user authorization.
* at least one log message correlates to a cybersecurity-relevant event as listed in 5.14.1.2, and
* for each triggered event:
    * the collected log message reflects the cybersecurity-relevant event, and
    * the log message indicating the event does not include any confidential information such as secrets or credentials.

Otherwise FAIL

@@ -2128,13 +2137,14 @@ Transfer log messages regarding cybersecurity-relevant events to mitigate local

#### 6.14.3.2 Preparation

List all types of cybersecurity-relevant internal events.
List all types of cybersecurity-relevant events.

#### 6.14.3.3 Activities

For each type of cybersecurity-relevant internal event,
For each type of cybersecurity-relevant event,

1. trigger the event.
1. trigger the event on the endpoint, and
2. collect any locally generated log messages recording the event.

#### 6.14.3.4 Verdict

@@ -2142,8 +2152,8 @@ PASS if **all** of the following are fulfilled:

For each triggered event:

* the log contains a message indicating the event, and
* log message does not include any information likely to be confidential.
* the collected log message reflects the cybersecurity-relevant event, and
* the log message indicating the event does not include any confidential information such as secrets or credentials.

Otherwise FAIL

@@ -2179,7 +2189,7 @@ Otherwise FAIL

#### 6.14.4.5 Evidence

* Evidence Copies of the relevant server configuration files demonstrating that logging is disabled
* Copies of the relevant server configuration files demonstrating that logging is disabled
* A description of the test traffic generated
* The output of the server storage/log inspection confirming the absence of the specified data

+212 −1669

File changed.

Preview size limit exceeded, changes collapsed.