***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:
***MON_LOG-4** The log information shall include the following fields in a machine readable format including, but not limited to:
* event timestamp
* actor identity
* action type
* 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:
***MON_LOG-5** The product shall log all received relevant events from its managed elements in a machine readable format including, but not limited to:
* incidents
* alarms
* time shift alarms.
@@ -1561,18 +1561,16 @@ The following requirements apply where the corresponding function exists:
* 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
* 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
* recovery mode activations if in use.
For **medium** risk:
***MON_LOG-8:** The log information shall have an active backup scheduled.
> 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-9** The product shall support forwarding of relevant administrative events to an external logging or SIEM system.
@@ -1589,7 +1587,7 @@ For **high** risk:
* 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.
> 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 access rights.
### 5.14.2 Metrics
@@ -2150,9 +2148,248 @@ Verify that:
### 6.14.1 Logging tests
#### 6.14.1.1 MON_LOG-1
**Objective:** Protect the logs from alteration.<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. Access the collected logs the expected way.
2. Access the collected logs the expected way without valid authorisation.
3. Access the collected logs un-expected way without valid authorisation.
**Verdict:**
1. Pass if access is denided
2. and if the event detected and logged.
3. 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.2 MON_LOG-2
**Objective:** Protect the logs from alteration.<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. Access the collected logs the expected way.
2. Access the collected logs the expected way with valid authorisation and make an alteration.
**Verdict:**
1. Pass if the product detectecs the alteration of logs.
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.3 MON_LOG-3
**Objective:** Protect the logs leaking information.<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. Study the product and the implementation.
**Verdict:**
1. Pass if the logging system protects the acces to the log data in transit and in rest.
2. Fail if the data stored in local disk is accessible by all locally authenticated users without restrictions.
3. 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.4 MON_LOG-4
**Objective:** Protect the logs from alteration.<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. Study the log output.
**Verdict:**
1. Pass if listed information is available in the log event systemically in the same machine readable manner.
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.5 MON_LOG-5
**Objective:** Make it possible to systemically analyse managed device behavior.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Have the managed element initialised and available with the required credentials;
3. Study the technical documentation how to interact with the system.
**Activities:**
1. Emit listed events from the managed element;
2. Study the log output.
**Verdict:**
1. Pass if listed information is available in the log event systemically in the a machine readable manner.
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.6 MON_LOG-6
**Objective:** Make it possible to systemically analyse whole system behavior.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Have the managed element initialised and available with the required credentials;
3. Study the technical documentation how to interact with the system.
**Activities:**
1. Interact with the system to create all described events;
2. Study the log output.
**Verdict:**
1. Pass if all required information are available in the log systemically in a machine readable manner.
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.7 MON_LOG-7
**Objective:** Make it possible to systemically analyse system boot behavior.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials;
2. Have the managed element initialised and available with the required credentials;
3. Study the technical documentation how to interact with the system.
**Activities:**
1. Interact with the system to create described event;
2. Study the log output.
**Verdict:**
1. Pass if required information are available in the log systemically in a machine readable manner.
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.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.<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. Initiate a backup of the system logs if available.
2. Verify the scheduling of the backups.
**Verdict:**
1. Pass if backup is scheduled and working.
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.8 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.
3. Have a MOC 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.
**Verdict:**
1. Pass if there are no unknown fields.
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:** Reduces vendor lock-in and supports incident response and evidence portability.
**Objective:** Reduces vendor lock-in and supports incident response and evidence portability.<br/>
**Preparation:** None<br/>
**Activities:** None<br/>
**Verdict:**
@@ -2164,9 +2401,35 @@ Verify that:
1. Pointers to the documentation.
#### 6.14.1.11 MON_LOG-11
**Objective:** Ensure operations visibility in the third party connected system.<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. Make an action, that is expected to generate an auditable event.
2. Study the log output.
**Verdict:**
1. Pass if all required information are available in the log systemically in a machine readable manner.
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.12 MON_LOG-12
**Objective:** Enables audit replay and accountability for automated control planes. Reduces ambiguity in incident investigations.
**Objective:** Enables audit replay and accountability for automated control planes. Reduces ambiguity in incident investigations.<br/>
