Make notes on what needs to be done, move some vuln text

## 2.1 Normative references

> TODO-HAS: Add reference to PT3 for vulnerability handling (see VULH and normative referenecs in the Network Interfaces draft).

**_Editor's Note_: _This Section Needs To Be Updated_**

> **In Harmonised Standards these references shall be specific** (identified by date of publication and/or edition number or version number) **publicly available and in English, except in exceptional circumstances making sure that impacts have been evaluated and explanations have been given on how any negative implications should be avoided** . See clauses 2.10.1 and 8.4 of the [EDRs](EDRs) and the communiqué on "[References in ETSI Deliverables](https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/News_from_editHelp/References_in_ETSI_deliverables.pdf)".

## 2.2 Informative references

> TODO-HAS: check if we need to add/remove anything here

**_Editor's Note_: _This Section Needs To Be Updated_**

References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

> NOTE: Users may have multiple user accounts and user accounts may have multiple users.

> FIXME: Better distinction of the agent acting through a user account and the user account.

**threat actor:** entity that can adversely affect the system through malicious or unauthorized activities

**application:** software that runs on a platform and performs tasks on behalf of the user or owner of the platform, as well as its supporting documentation

## 4.2 Essential functions

An operating system shall provide essential functionality based on the foreseeable risks specific to the product context. The essential functions may depend on available hardware or network resources, intended and foreseeable use, user configuration, and other environmental factors. 

The essential functions may include functions such as: process isolation, memory isolation, I/O abstraction, device driver management, user authentication and access control, event logging, software management, device firmware management, secure updates, and more.

The essential functions of an operating system shall be documented.

The essential functions of the product may include functions such as: process isolation, memory isolation, I/O abstraction, device driver management, user authentication and access control, event logging, software management, device firmware management, secure updates, and more.

## 4.3 Product architecture

* Resource limits

* Performance considerations

### 4.3.7 Vulnerability Handling

#### 4.3.7.1 General Vulnerability Handling

Operating Systems often provide the essential functionality of securely updating the underlying hardware and the installed software products which rely on the operating system.

Given this essential role of the operating system in maintaining the security of products which rely on operating systems, it is important that vulnerabilities in operating systems are remediated expediently and in coordination with manufacturers of products that rely upon them.

**_Editor's Note_: _This Section Needs To Be Moved To Section 5_**

For operating systems that rely on third-party open source software components, the manufacturer's vulnerability handling process shall include:

1. recording of all third-party open source components by name, version, source location, and hash-based identifier;

1. proactive monitoring of external sources for vulnerability disclosure regarding the third-party open source components;

This should be accomplished by implementing additional vulnerability handling steps according to common industry standards such as << INFORMATIVE REFERENCE TO FIRST GUIDANCE HERE >>, and by relying on accepted standards for precise software identification, such as << INFORMATIVE REFERENCE TO PURL and SWHID HERE >>.

#### 4.3.7.2 Enabling Vulnerability Handling in Integrated Products

**_Editor's Note_: _This Section Needs To Be Moved To Section 5_**

When Operating Systems are integrated into subsequent products in a supply chain, vulnerabilities in the operating system may have a particularly high impact on the security characteristics of the final product. Therefore, manufacturers of Operating Systems intended for integration in subsequent products have a responsibility to enable the vulnerability handling processes of manufacturers which depend upon them.

If an operating system's use cases support integration into subsequent products, then the manufacturer of the operating system shall provide:

1. clear documentation of all essential security capabilities which the operating system provides to the integrator, and

1. unique, unambiguous, and machine-readable identification of all components of the operating system, including third party components, in a format consistent with common vulnerability handling standards.

Providing this information enables the manufacturer which integrates the operating system to:

1. verify that the forseeable use of the final product can rely on appropriate security protections from the operating system, and

1. verify that the product, including components integrated in the operating system, is free of known vulnerabilities at the time it is placed on the market, and

1. proactively monitor for the disclosure of new vulnerabilities, including in the operating system and its components, which might affect the security of the final product.

## 4.4 Operational Environment

The technical requirements of the present document apply under the environmental profile for operation of the equipment, which shall be in accordance with its intended use. The equipment shall comply with all the technical requirements of the present document at all times when operating within the boundary limits of the operational environmental profile defined by its intended use.

The manufacturer shall document and communicate the expected environmental profile for the product to the consumer.

The operational environment of an operating system is highly varied. In general it includes at least a platform (virtual or physical), and may also include applications, separately shipped device drivers, device firmware, peripherals, and many other components. Operating systems may be a standalone software product on a single processor, or it may be part of suite of software products running on multiple processors. Many systems have multiple operating systems all managing different parts of the system at the same time.

## 4.5 Distribution of security functions

This section is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following section will define which mitigations will be required, depending on risk factors and/or a use case. See Annex C for more information.

> TODO-HAS: Renumber the requirements

### 5.2.1 TR-NKEV: No known exploitable vulnerabilities at first use

#### 5.2.1.1: Requirement

  * Verdict: Vulnerability handling documentation is compliant with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling" => PASS, otherwise FAIL

  * Evidence: Vulnerability handling documentation, comparison with <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling"

> TODO-HAS: Make the below text into a mitigation for the vulnerability handling requirement above, or delete if no longer necessary.

General Vulnerability Handling

Operating Systems often provide the essential functionality of securely updating the underlying hardware and the installed software products which rely on the operating system.

Given this essential role of the operating system in maintaining the security of products which rely on operating systems, it is important that vulnerabilities in operating systems are remediated expediently and in coordination with manufacturers of products that rely upon them.

For operating systems that rely on third-party open source software components, the manufacturer's vulnerability handling process shall include:

1. recording of all third-party open source components by name, version, source location, and hash-based identifier;

1. proactive monitoring of external sources for vulnerability disclosure regarding the third-party open source components;

This should be accomplished by implementing additional vulnerability handling steps according to common industry standards such as << INFORMATIVE REFERENCE TO FIRST GUIDANCE HERE >>, and by relying on accepted standards for precise software identification, such as << INFORMATIVE REFERENCE TO PURL and SWHID HERE >>.

Enabling Vulnerability Handling in Integrated Products

When Operating Systems are integrated into subsequent products in a supply chain, vulnerabilities in the operating system may have a particularly high impact on the security characteristics of the final product. Therefore, manufacturers of Operating Systems intended for integration in subsequent products have a responsibility to enable the vulnerability handling processes of manufacturers which depend upon them.

If an operating system's use cases support integration into subsequent products, then the manufacturer of the operating system shall provide:

1. clear documentation of all essential security capabilities which the operating system provides to the integrator, and

1. unique, unambiguous, and machine-readable identification of all components of the operating system, including third party components, in a format consistent with common vulnerability handling standards.

Providing this information enables the manufacturer which integrates the operating system to:

1. verify that the forseeable use of the final product can rely on appropriate security protections from the operating system, and

1. verify that the product, including components integrated in the operating system, is free of known vulnerabilities at the time it is placed on the market, and

1. proactively monitor for the disclosure of new vulnerabilities, including in the operating system and its components, which might affect the security of the final product.

## 5.3 Risk Mitigation Sets

> TODO: Connect the technical security requirements in clause 5.2 to specific Risk Factors, and define these as sets of Risk Mitigations that will be referenced in clause 6.

> TODO-HAS: For each security profile, list all the mitigations required by the threat assessments in C.4.

SP-LR

SP-IoT-1

SP-IoT-2

SP-IoT-3

SP-RO-1

SP-OT-1

SP-MOB-1

SP-WE-1

SP-PC-1

SP-PC-2

SP-LA-1

SP-LA-2

SP-PS-1

SP-SE-1

SP-SE-2

SP-SE-3

# 6 Conformity Assessment

# Annex B (informative): Relationship between the present document and any related ETSI standards (if any)

> TODO-HAS: Put any ETSI standards from the normative/informative section here and make some general statement describing the relationship. See Network Interfaces draft for an example.

> List any related ETSI standards and how they interact with the present document.

# Annex C (informative): Risk identification and assessment methodology

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.

> FIXME: reference guidance on risk assessment when it exists.

#### C.2.1.x Number of User Accounts

**[RF-NUSR]:** The number of user accounts of end-users expected on the system, excluding administrator accounts.

## D.2 Mapping of risks to requirements

> TODO: Update below

> TODO-HAS: Update below

| Threat | Requirements                             |

|--------|------------------------------------------|

For each risk untreated by the product itself, a corresponding mitigation has been created to explicitly permit the risk to be transferred to the user or operational environment. These are:

> TODO: update below

  * MI-KEVD

  * MI-KEVM

  * MI-MDOC

  * MI-SUDC

  * MI-SUOE

  * MI-SUAO

  * MI-SCHL

  * MI-SCHM

  * MI-SCHH

  * MI-DOCC

  * MI-DOST