WARNING! Gitlab maintenance operation scheduled for Thursday, 18 June between 19:00 and 20:00 (CET). During this time window, short service interruptions (less than 5 minutes) may occur. Thank you in advance for your understanding.
> Should you need a step-by-step guide for drafting an ETSI deliverable, please consult the "_ [Principles for Drafting ETSI Deliverables](https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/Principles_for_drafting_ETSI_deliverables.pdf)_" document. Otherwise you may contact us at_ [edithelp@etsi.org ](mailto:edithelp@etsi.org).
> Should you need a step-by-step guide for drafting an ETSI deliverable, please consult the "_ [Principles for Drafting ETSI Deliverables](https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/Principles_for_drafting_ETSI_deliverables.pdf)_" document. Otherwise you may contact us at\_ [edithelp@etsi.org ](mailto:edithelp@etsi.org).
Association à but non lucratif enregistrée à la<br/>
@@ -92,8 +82,6 @@ No representation or warranty is made that this deliverable is technically accur
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.
Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use of or inability to use the software.
<br/>
@@ -102,8 +90,6 @@ Any software contained in this deliverable is provided "AS IS" with no warrantie
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media.
@@ -124,14 +108,12 @@ IPRs essential or potentially essential to normative deliverables may have been
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.
## Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
**DECT™** , **PLUGTESTS™** , **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™** , **LTE™** and **5G ™** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM**® and the GSM logo are trademarks registered and owned by the GSM Association.
# Foreword
> DRAFT FOREWORD - DO NOT CONSIDER THE CONTENT Should be written as a last item.
@@ -150,60 +132,45 @@ The Harmonised Standard shall have appropriate transposition periods specified.
The Technical Body may propose different dates to the default ones (3, 6, 18). Technical Bodies who wish to propose different dates are advised to indicate this clearly in the approved committee draft.
<mark> Table with colspans converted to grid table. Please check and adjust manually if necessary. </mark>
The Technical Body should advise the ETSI Secretariat if the above default national transposition dates are inappropriate for the particular standard.
# Modal verbs terminology
In the present document "**should** ", "**should not** ", "**may** ", "**need not** ", "**will** ", "**will not** ", "**can** " and "**cannot** " are to be interpreted as described in clause 3.2 of the [ETSI Drafting Rules](https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules)(Verbal forms for the expression of provisions).
"**must** " and "**must not** " are **NOT** allowed in ETSI deliverables except when used in direct citation.
# Executive summary
# Introduction
The present document is a European harmonised standard that defines cybersecurity requirements for products whose primary purpose is network management system. Demonstrating compliance with this standard is not necessary, but doing so provides a presumption of conformity with Regulation (EU) 2024/2847, the Cyber Resilience Act.
<br/>
# 1 Scope
# 1.1 General
The present document describes how to demonstrate compliance with requirements in the EU Regulation 2024/2847 under the conditions identified in Annex <III> of network management systems, within the context described in section 4, Product Context.
# 1.2 Products in scope
This standard applies to Network Management Systems that manage connected network elements, such as servers, routers, switches, workstations, printers or mobile devices, by tracking them and controlling their network configuration. This category includes but is not limited to end-to-end management systems and dedicated configuration management systems, such as controllers for software-defined networking.
<mark>FIXME: Link to technical definitions doc</mark>
# 1.3 Products not in scope
> Detailed list of things whose scope might be confusing, including parts of a system which are often included when the terms in the "in scope" section are used in general conversation. Reference the "Product Context" section again to remind the reader what operational environments are in scope.
# 2 References
## 2.1 Normative references
@@ -229,6 +196,7 @@ The following referenced documents are necessary for the application of the pres
<mark>FIXME more normative references</mark>
## 2.2 Informative references
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.
@@ -240,7 +208,6 @@ The following referenced documents may be useful in implementing an ETSI deliver
-<aname="_ref_i.1">[i.1]</a> Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)
# 3 Definition of terms, symbols and abbreviations
## 3.1 Terms
@@ -256,7 +223,6 @@ For the purposes of the present document, the [following] terms [given in ... an
<mark>FIXME add any other terms we need to define</mark>
## 3.2 Abbreviations
For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:
@@ -303,23 +269,61 @@ The following types of products have reduced or varied requirements under Regula
> Create a list of representative use cases, each one representing a different threat profile. If the threat profile is the same, it's basically the same use case for the purposes of this document. Later the use cases will be mapped to security levels. Use cases should include both intended and reasonably foreseeable use/misuse.
<mark>FIXME Define more use cases</mark>
Manufacturer shall delcare what risk profile it's product is meant to be evaluated at.
### 4.3.1 Low risk deployment
- Distributed element design
- Lesser importance with the device functionality and role in the deployment context
- Highly isolated management system design
Examples:
- IoT network with monitoring data collection
- Home network deployment
### 4.3.2 Medium risk deployment
- Converged network design
- More than one installation site
Examples:
- Office network
### 4.3.3 High risk deployment
- High number of elements
- Significant number of affected user base
Examples:
- Telecom network
- Large enterprice network
## 4.4 Security levels
> List the security levels and the use cases that correspond to them._
<mark>FIXME Define the levels</mark>
The security level requirements reflects the intented deployment of the NMS.
The functionality requirements are cumulative.
High risk deployment shall implement the lower risk functionalities.
> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level._
> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.\_
>Example technical security requirements can be found in related standards, such as:_
>Example technical security requirements can be found in related standards, such as:\_
> * Protection profiles for similar categories of product
> - Other vertical standards drafts in [ETSI GitLab](https://forge.etsi.org/rep/cyber/stan4cr2)
> - Other vertical standards drafts as [contributions to verticals meetings on the ETSI Portal](https://portal.etsi.org/Meetings.aspx#/)
> - PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)
> Why do we need security levels? Isn't the base operation the same, but the applicaton usage context different? Stricter security expectes more imlemented features.
@@ -376,7 +379,6 @@ The technical requirements of the present document apply under the environmental
# Annex A (informative): Relationship between the present document and any related ETSI standards (if any)
> List any related ETSI standards and how they interact with this document.
@@ -388,7 +390,7 @@ The technical requirements of the present document apply under the environmental
> Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements.
@@ -424,6 +426,7 @@ The technical requirements of the present document apply under the environmental
## C.2 Threats
> Based on the assets, what are the threats during:
>
> - Use for intended purpose or reasonably foreseeable use
> - When integrated into another product
@@ -492,35 +495,25 @@ The annex shall have a table for a clear indication of correspondence between no
**It should be evaluated - on the basis of the legal requirements supported and other information given in a harmonised standard - how detailed correspondence can be indicated between the normative elements of the harmonised standard and the legal requirements aimed to be covered. However, where this correspondence is expressed in too general terms, it could lead to a situation where the Commission cannot assess whether the Harmonised Standard satisfies the requirements, which it aims to cover, and subsequently publication of its references in the OJEU according to Article 10(6) of the Regulation is significantly delayed or is not possible at all.**
> **EXAMPLE for a table:**
**Table A.1: Relationship between the present document and<br />the requirements of EU Regulation 2024/2847**<aname="table_A.1"></a>
<mark> Table with colspans converted to grid table. Please check and adjust manually if necessary.</mark>
**No** A unique identifier for one row of the table which may be used to identify a requirement.
**Description** A textual reference to the requirement.
@@ -531,7 +524,6 @@ The annex shall have a table for a clear indication of correspondence between no
**Requirement Conditionality:**
**U/C** Indicates whether the requirement is unconditionally applicable (U) or is conditional upon the manufacturer's claimed functionality of the equipment (C).
**Condition** Explains the conditions when the requirement is or is not applicable for a requirement which is classified "conditional".
@@ -544,7 +536,7 @@ The annex shall have a table for a clear indication of correspondence between no
The annex shall have at least the following two warnings.
A warning stating that presumption of conformity is effective only as long as the reference is maintained in the OJEU by the Commission. The following URL-address [https://ec.europa.eu/growth/single-market/european-standards/harmonised-standards\_en](https://ec.europa.eu/growth/single-market/european-standards/harmonised-standards\_en) to consult the latest list of Harmonised Standards published in the OJEU should be provided.
A warning stating that presumption of conformity is effective only as long as the reference is maintained in the OJEU by the Commission. The following URL-address [https://ec.europa.eu/growth/single-market/european-standards/harmonised-standards_en](https://ec.europa.eu/growth/single-market/european-standards/harmonised-standards_en) to consult the latest list of Harmonised Standards published in the OJEU should be provided.
Presumption of conformity stays valid only as long as a reference to the present document is maintained in the list published in the Official Journal of the European Union. Users of the present document should consult frequently the latest list published in the Official Journal of the European Union.
@@ -554,19 +546,16 @@ Other Union legislation may be applicable to the product(s) falling within the s
<br/>
# Annex: Bibliography
<br/>
# Annex <L+4> (informative): Change history
The "Change history/Change request (history)" annex shall be included in every revised or amended harmonised standard and shall contain information concerning significant changes that have been introduced by it. It shall be presented as a table.
The "Change history/Change request (history)" annex shall be included in every revised or amended harmonised standard and shall contain information concerning significant changes that have been introduced by it. It shall be presented as a table.
