Commit 39382cd4 authored by Santeri Toikka's avatar Santeri Toikka
Browse files

Merge branch '118-has57-write-full-sentences-5-3-5' into 'main' 

HAS 57 Full Sentences in (5.3.5)

Closes #118, #25, #26, #17, #8, #349, #350, #351, #352, #210, #211, #212, #393, and #348

See merge request cyber/stan4cr2/en-304-621!35
parents f2a39efe d25d554c

EN-304-621.md

+74 −20
Original line number Original line Diff line number Diff line
@@ -849,43 +849,69 @@ Requirements: 
- **[REQ-UPDATES-1]:** The product shall maintain a monotonic version counter or equivalent mechanism to prevent installation of updates with an older vulnerable version.

- **[REQ-UPDATES-1]:** The product shall maintain a monotonic version counter or equivalent mechanism to prevent installation of updates with an older vulnerable version.

- **[REQ-UPDATES-2]:** If the product supports intentional rollback, this action shall require explicit authorisation and shall be based on separately versioned and signed rollback metadata.

- **[REQ-UPDATES-2]:** If the product supports intentional rollback, this action shall require explicit authorisation and shall be based on separately versioned and signed rollback metadata.

- **[REQ-UPDATES-3]:** The product shall apply updates in an atomic manner such that incomplete or failed updates do not result in a partially updated state. In the event that an update cannot be completed successfully, the product shall automatically restore a previously operational software state, ensuring the product remains functional.

- **[REQ-UPDATES-3]:** The product shall apply updates in an atomic manner such that incomplete or failed updates do not result in a partially updated state. In the event that an update cannot be completed successfully, the product shall automatically restore a previously operational software state, ensuring the product remains functional.

- **[REQ-UPDATES-5]:** The product shall inform the user about update availability if applicable.

- **[REQ-UPDATES-6]:** The product shall track the relevant component versions of the product and the managed devices if applicable.

- **[REQ-UPDATES-7]:** The product shall log start and finish of the update download if applicable.

- **[REQ-UPDATES-8]:** The product shall perform an automatic upgrade of the product and the managed devices if the operative context and the application design allows this to happen within the defined availability targets.





These requirements are generally binding, and there is no low-medium-high tiering available.

These requirements are generally binding, and there is no low-medium-high tiering available.





<mark>Editor's Note: Consider making [REQ-UPDATES-3] applicable only for high tier.</mark>

The requirements REQ-UPDATES-5, REQ-UPDATES-6, REQ-UPDATES-7 and REQ-UPDATES-8 are conditional due to different operative management models.

A cellphone that is connected to a corporate inventory management often has it's own update manager, and the device does not rely on the centralised control.

Similary in a modern cluster deployment, the application can not update itself, as the control is in the cluster, which makes the provisioning, scheduling and network shaping decisions for all applications ran in the same context.



Applying automatic updates are also subject to the operative environment design.

In some occasions, the cluster design does not have the capasity to provison the extra workload needed to make a seameless trasfer of application functions.

Distributed application design and delay lines built with buffers might tolerate partial downtime of individual components and services, but as the upgrade controller designs are not fully matured, the evaluation of upgrade structures needs to be left for the assessors.





### 5.3.5 Logging

### 5.3.5 Logging





The monitoring requirements becomes more demanding, when the security expectation of the deployment context is more strict.

In many product deployments, administrators manage monitoring tasks also with the analysis of product logging records.

Especially when there are forensic demands, comprehensive and detailed logging becomes a larger challenge.



The logging requirements in this subclause define baseline event recording and additional protections for retention, integrity, backup, and external forwarding according to the applicable risk tier.



When evaluating the applicability of these requirements, the highest of following risk factors define the category to follow: [NIS2]

When evaluating the applicability of these requirements, the highest of following risk factors define the category to follow: [NIS2]





For low risk:

For low risk:





- **[REQ-LOG-0a]:** The log file of events shall be protected from unauthorised access, modification,

- **[REQ-LOG-0a]:** The log file of events shall be protected from unauthorised access.

- **[REQ-LOG-0b]:** and is confidentiality protected.

- **[REQ-LOG-0b]:** The log data of events shall be protected from modification including their deletion.

- **[REQ-LOG-1a]:** The product shall generate auditable events for: successful and failed authentication attempts,

- **[REQ-LOG-0c]:** The log data of events shall be confidentiality protected.

- **[REQ-LOG-1b]:** session establishment attempts with source details,

- **[REQ-LOG-0d]:** The log shall include event time, actor identity, action type, and affected non-sensitive scope and object identifiers.

- **[REQ-LOG-1c]:** session termination events with reason,



- **[REQ-LOG-1d]:** session validation checks like number of concurrent sessions,

The following requirements apply where the corresponding function exists:

- **[REQ-LOG-1e]:** and privilege escalation.



- **[REQ-LOG-2a]:** The product shall log boot or initialisation events: timestamped boot stage progression,

- **[REQ-LOG-1a]:** The product shall generate auditable events for successful and failed authentication events.

- **[REQ-LOG-2b]:** component verification and initialisation actions,

- **[REQ-LOG-1b]:** The product shall generate auditable events for session establishment attempts with source details.

- **[REQ-LOG-2c]:** and recovery mode activations if in use.

- **[REQ-LOG-1c]:** The product shall generate auditable events for session termination events with reason.

- **[REQ-LOG-3a]:** The product shall log: update availability,

- **[REQ-LOG-1d]:** The product shall generate auditable events for session validation checks like number of concurrent sessions.

- **[REQ-LOG-3b]:** start and finish of the update download,

- **[REQ-LOG-1e]:** The product shall generate auditable events for privilege and role changes.

- **[REQ-LOG-3c]:** events described by [5.3.4 Secure updates],

- **[REQ-LOG-1f]:** The product shall generate auditable events for configuration changes.

- **[REQ-LOG-3d]:** and installation successes and failures.

- **[REQ-LOG-1g]:** The product shall generate auditable events for device enrollment and unenrollment.

- **[REQ-LOG-1h]:** The product shall generate auditable events for trust-anchor changes.

- **[REQ-LOG-1i]:** The product shall generate auditable events for policy changes.

- **[REQ-LOG-1j]:** The product shall generate auditable events for credential changes.

- **[REQ-LOG-2a]:** The product shall log boot or initialisation events including timestamped boot stage progression.

- **[REQ-LOG-2b]:** The product shall log boot or initialisation events including component verification and initialisation actions.

- **[REQ-LOG-2c]:** The product shall log boot or initialisation events including recovery mode activations if in use.

- **[REQ-LOG-3c]:** The product shall log events described by [5.3.4 Secure updates].

- **[REQ-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.





For medium risk:

For medium risk:





- **[REQ-LOG-4]:** The log information shall have an active backup scheduled.

- **[REQ-LOG-4]:** The log information shall have an active backup scheduled.

- **[REQ-LOG-5]:** Administrative actions like logs, traces and events shall be recorded into a write only service or endpoint.

- **[REQ-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.



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





For high risk:

For high risk:





- **[REQ-LOG-6]:** The write only log or tracing storage shall be deployed outside of the system deployment context.

- **[REQ-LOG-6]:** The product shall support forwarding of relevant administrative events to an external logging or SIEM system and shall document the transfer format and field definitions.

- **[REQ-LOG-7]:** The system reports relevant administrative operations shall be forwarded to an external SIEM system.

- **[REQ-LOG-7]:** SIEM transfer format, field attributes and event descriptions shall made available as part of the technical documentation.

- **[REQ-LOG-8]:** SIEM transfer format, field attributes and event descriptions shall made available as part of the technical documentation.

- **[REQ-LOG-8]:** Exported artifacts shall preserve essential fields at least, but not limited to: time, actor, action type, affected scope, result.

- **[REQ-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.





### 5.3.6 Metrics

### 5.3.6 Metrics
@@ -1335,6 +1361,34 @@ There are three different types of assessments used in this document. 




## 6.3 Risk mitigations tests

## 6.3 Risk mitigations tests





### 6.3.5 Logging tests



### 6.3.5.8 REQ-LOG-8



**Requirement:**

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

**Preparation:** None<br/>

**Activities:**

**Verdict:**



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

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



**Supporting Evidence:**



### 6.3.5.9 REQ-LOG-9



**Requirement:**

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

**Preparation:** None<br/>

**Activities:**

**Verdict:**



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

2. Fail if changes cannot be deterministically attributed.



**Supporting Evidence:**



### 6.3.6 Metrics tests

### 6.3.6 Metrics tests





#### 6.3.6.0 REQ-METRICS-0

#### 6.3.6.0 REQ-METRICS-0