Review updates on MON_ topic

#### 6.14.1.1 MON_LOG-1

**Objective:** Protect the logs from alteration.

**Objective:** The logs are protected from disclosure and alteration.

**Preparation:**

#### 6.14.1.2 MON_LOG-2

**Objective:** Protect the logs from alteration.

**Objective:** The logs are protected from alteration including their deletion.

**Preparation:**

**Activities:**

1. Access the collected logs the expected way.

2. Access the collected logs the expected way with valid authorisation and make an alteration.

1. Access the collected logs the expected way;

2. Access the collected logs the expected way with valid authorisation, make an alteration to one and try to delete another log entry.

**Verdict:**

1. Pass, if the product detects the alteration of logs.

1. Pass, if the product detects the alteration of logs and prevents the deletion.

2. Fail otherwise.

**Supporting Evidence:**

**Verdict:**

1. Pass if the logging system protects the access to the log data in transit and in rest.

1. Pass, if the logging system protects the reading access to the log data in transit and at rest.

2. Fail if the data stored in local disk is accessible by all locally authenticated users without restrictions.

3. Fail otherwise.

#### 6.14.1.4 MON_LOG-4

**Objective:** Protect the logs from alteration.

**Objective:** Each log entry contains a minimum set of information enabling for an analysis of the logged event.

**Preparation:**

#### 6.14.1.5 MON_LOG-5

**Objective:** Make it possible to systemically analyse managed element behavior.

**Objective:** All defined event notifications received from the managed elements are recorded in a machine-readable format and enable for machine-based analysis.

**Preparation:**

#### 6.14.1.6 MON_LOG-6

**Objective:** Make it possible to systemically analyse whole system behavior.

**Objective:** The product’s logging records enable for the analysis of the product behaviour.

**Preparation:**

#### 6.14.1.7 MON_LOG-7

**Objective:** Make it possible to systemically analyse system boot behavior.

**Objective:** The log records allow to analyse whether the product has achieved the operational status or whether an error occurred in dependency of the achieved booting stage.

**Preparation:**

#### 6.14.1.8 MON_LOG-8

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

**Objective:** Even attackers who managed to gain access to the logging records cannot alter or eliminate the history as the logging has a scheduled external backup.

**Preparation:**

**Activities:**

1. Initiate a backup of the system logs if available.

2. Verify the scheduling of the backups.

1. Check whether the product provides a product user-set scheduled backup of the log records.

2. Verify that the scheduling of the backups is indeed applied.

**Verdict:**

#### 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.

**Objective:** Even attackers who managed to gain access to the logging records cannot alter or eliminate the history.

**Preparation:**

**Activities:**

1. Identify how the logging mechanism works;

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

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

**Verdict:**

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

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

3. Have a MOC SIEM system available and configured to receive events.

3. Have an external logging SIEM system available and configured to receive events.

**Activities:**

1. Make an action that is expected to generate an auditable event.

2. Study the event and cross reference the content to the technical documentation.

1. Make an action that is expected to generate an auditable event;

2. Study the event notification and cross reference the content to the technical documentation;

3. Check whether the event is externally made available in the logging or SIEM system.

**Verdict:**

1. Pass if there are no unknown fields.

1. Pass, if the event notification is product-external available.

2. Fail otherwise.

**Supporting Evidence:**

#### 6.14.1.11 MON_LOG-11

**Objective:** Reduces vendor lock-in and supports incident response and evidence portability.

**Objective:** Logging records, product-internal and on external systems, are machine readable and can be analysed in automated ways.

**Preparation:** None

**Verdict:**

1. Pass if export is available, documented, and preserves essential fields.

2. Fail if evidence cannot be exported or loses critical context.

1. Pass, if the logging records are available product-external and are in a machine-readable format.

2. Fail, if evidence cannot be exported or loses critical context.

3. Fail otherwise.

**Supporting Evidence:**

1. Pointers to the documentation.

2. Screenshot of machine-readable logging records.

3. References to the belonging documentation of record contents and formats.

#### 6.14.1.12 MON_LOG-12

**Objective:** Ensure operations visibility in the third party connected system.

**Objective:** The exported logging records provide a minimum set of information about the basic data of the event as defined to enable the product user for event analysis.

**Preparation:**

**Verdict:**

1. Pass if all required information is available in the log systemically in a machine readable manner.

1. Pass if all required information is available in in each logging record.

2. Fail otherwise.

**Supporting Evidence:**

* Screenshot or console ouput of the logging records with identification of the minimum information parameters;

* References to the belonging documentation of record contents and formats;

* Metrics output relevant for the activities, if available;

* 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.13 MON_LOG-13

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

**Objective:** References to the belonging documentation of record contents and formats.

**Preparation:** None

**Preparation:**

**Activities:** None

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

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

**Activities:**

1. Make an action that is expected to generate an auditable event;

2. Study the log output.

**Verdict:**

1. Pass if each configuration change can be attributed to actor and context with retrievable references.

1. Pass, if the action applied can be attributed to actor and context with retrievable references.

2. Fail if changes cannot be deterministically attributed.

3. Fail otherwise.

**Supporting Evidence:**

1. Pointers to the documentation.

1. References to the belonging documentation of record contents and formats.

2. Screenshot or console output of the logging records with identification of the minimum information parameters.

### 6.14.2 Metrics tests

#### 6.14.2.1 MON_METRICS-1

**Objective:** Verifies the ingestion pipeline design upholds integrity and confidentiality requirements.

**Objective:** The ingestion pipeline design protects the metric data integrity.

**Preparation:** None

**Verdict:**

1. Pass if no unauthorised process before ingestion of collected metrics data can alter the metrics before storage

2. and if the storage can not be altered outside of regular cleaning cycles.

2. and if the storage can not be altered outside of desired storage handling.

3. Fail otherwise.

**Supporting Evidence:**