@@ -1356,7 +1356,7 @@ A **secure channel** used in transportation is a cryptographically protected com
When privileged information is transferred or accessed, the transport channel provides confidentiality, integrity protection, endpoint authentication, and protection against downgrade to less secure configurations.
TLS may be used for this purpose, but other mechanisms may also be used where they provide an equivalent level of protection and are implemented as defined in Annex K.
***CON_CHANNEL-1** The product shall ensure that the channel uses cryptographic functions and configuration according to the **CON_CRYPTO-1**.
***CON_CHANNEL-1** The product shall ensure that the secure channel uses cryptographic functions and configuration according to the **CON_CRYPTO-1**.
***CON_CHANNEL-2** All endpoints in a secure channel shall cryptographically verify others through mutual auhentication.
@@ -3992,76 +3992,51 @@ Other Union legislation may be applicable to the product(s) falling within the s
# Annex B (informative): Security analysis
<mark>Editor's Note: Even if informative, this Annex is mandatory in CRA Vertical Harmonised Standards, as it implements the risk-based approach prescribed in the CRA Regulation.</mark>
<mark>Editor’s Note: The security analysis should contain information on the risks that are associated with the use cases, as well as the risks conveyed by specific capabilities.</mark>
<mark>Editor’s Note: The security analysis represents a risk assessment done by the standardisers for the purpose of informing the applicability of technical requirements. It does not replace or interact with the risk assessment manufacturers are legally obliged to conduct pursuant to Article 13. To prevent confusion, refrain from using the term risk assessment.</mark>
This Annex applies state of the art methodology to identify assets, threats, identify and evaluate risk factors, and define security profiles applicable to the different use cases identified in the product context.
<mark> Editor's Note: The standard may implement an existing methodology, referencing the standards where it is defined. However, this methodology shall not compete with the legal obligation to draft an overall risk assessemnt.
</mark>
<mark>Use technical language and focus what is relevant from a product perspective</mark>
For each network management system placed on the market, this annex provides the grounds to develop a threat model and risk profile of the foreseeable use of the system that considers the interplay between:
- Complexity of foreseeable use
- Likelihood of an incident, given the foreseeable use
- Impact of an incident, given the foreseeable use
* Likelihood of an incident, given the foreseeable use
* Impact of an incident, given the foreseeable use
Attack vectors that are the responsibility of the network management system:
- Arbitrary commands from outside the system control boundaries
- Through APIs
- From GUI
- Context manipulation (DNS, TLS)
- Ingested data manipulation
- Unprivileged actors inside the system control boundaries
- Malicious networking node
- Malicious 3rd. party integration
- Privileged actors inside the system control boundaries
- Credential missuse
Out of scope attack vectors:
- Anything the OS is responsible for
- Direct bit twiddling of registers
Refer to normative standards:
- Device driver attack vectors
- Physical interface specific attack vectors?
<mark>Is the following relevant? Above chapter is the old Annex D Risk evaluation guidance</mark>
* Arbitrary commands from outside the system control boundaries
* Through APIs
* From GUI
* Context manipulation (DNS, TLS)
* Ingested data manipulation
* Unprivileged actors inside the system control boundaries
* Malicious networking node
* Malicious 3rd. party integration
* Privileged actors inside the system control boundaries
* Credential missuse
## B.1 Asets
* Network configuration data
* Network metrics data
* Network and device secrets
* Device inventory
* User register
* User secrets
## B.2 Risk Factors
This assessment provides a risk factors for the intended purpose and foreseeable uses of the product.
When following this standard such an assessment should consider the interplay between:
- The complexity of foreseeable uses
- The likelihood of incidents, given the foreseeable uses
- The impact of incidents, given the foreseeable uses
- The complexity of foreseeable use
- The likelihood of an incident, given the foreseeable use
- The impact of an incident, given the foreseeable use
* The likelihood of incidents, given the foreseeable uses
* The impact of incidents, given the foreseeable uses
The technical requirements in clause 5 reflect the risks and provide mitigations for the use cases provided in intended deployment of the product.
Individual risks are judged using the risk factors described here, and determine the degree and type of security needed for specific related security requirements.
Clause 5.X maps each use case to a set of requirements that reflect these risk factors and the overall risk of the product as a combination of the likelihood and potential impact of incidents.
The technical requirements in [Clause 5](#5-technical-requirements-for-the-products) reflect the risks and provide mitigations for the use cases provided in intended deployment of the product.
Individual risks can be judged using the risk factors described here, and determine the degree and type of security needed for specific related security requirements.
[Clause 5.1](#51-introduction---applicability-of-the-requirements) maps each use case to a set of requirements that reflect these risk factors and the overall risk of the product as a combination of the likelihood and potential impact of incidents.
Risk factor analysis of all appropriate risk factors can be combined to determine an overall risk of the product and label its risk as low, medium, or high.
With this approach, each risk factor provides a description of high or low risk related to a particular aspect of the product and when combined a way to judge its overall security needs.
The risk is combination of likelihood and impact.
Each risk factor is evaluated using defined criteria for likelihood and impact.
The resulting risk level is determined as low, medium, or high according to Table B.1.0-1.
The set of resulting risk levels is then used to determine the applicable requirements in clause 5.
The resulting risk level is determined as low, medium, or high according to **Table B.1.0-1**.
* Managed network is complex with sophisticated functions and supporting services
* Managed network includes multiple interconnected sites
### B.2.3 Critical entity
The expectations on security are a sum of deployment, its environment, likelihood and impact. Therefore this risk factor is evaluated directly as perceived by the market the product is made available.
**Key:**[CENT](#b13-critical-entity)</br>
**Rationale:** Critical entity's operations are governance is defined by laws and guidances like the NIS2 [i.16] in addition to nation specific regulation.
**Rationale:** Critical entity's operations are governance is defined by laws and guidances in addition to nation specific regulation.
Entities that require higher level of protection also expects more accuracy and scrunity from the product.
The deployment context may include additional mechanisms to detect and respond to security compromise.
risk level is **low** if:
- The product is intended for or foreseaably used to manage networks whose product user entity status is undefined.
- Product's intended deployment target is a household or a small business with under a thousand users.
Risk level is **low** if:
* The product is intended for or foreseaably used to manage networks whose product user entity status is undefined.
* Product's intended deployment target is a household or a small business with under a thousand users.
risk level is **medium** if:
- The product is intended for or foreseaably used to manage networks whose entity status is undefined.
- The product serves for a medium-sized enterprise.
- or the number of managed elements is a thousand or over.
Risk level is **medium** if:
* The product is intended for or foreseaably used to manage networks whose entity status is undefined.
* The product serves for a medium-sized enterprise.
* or the number of managed elements is a thousand or over.
risk level is **high** if:
- The product is targeted important or essential entities.
Risk level is **high** if:
* The product is targeted important or essential entities.
**Rationale:** The level of segementation and isolation of the managed network are a factor when determining risk.
**likelihood** is **low**, if:
- Managed network is physically isolated from public networks with strong physical access control procedures.
**likelihood** is **high**, if:
- Managed network is connected with multiple entry points to public networks filtered by firewalls.
- Managed network uses no segmentation.
Risk likelihood is **low**, if:
* Managed network is physically isolated from public networks with strong physical access control procedures.
**impact** is **low**, if:
- Managed network is segmented in a way that does not mix management traffic with payload data.
- Managed network uses single segment, but the number of connect devices in the network is low.
Risk likelihood is **high**, if:
* Managed network is connected with multiple entry points to public networks filtered by firewalls.
* Managed network uses no segmentation.
**impact** is **high**, if:
- Managed network is segmented, and the segmentation is trusted to provide additional security.
- Traffic classes including control, management and payload shares the same segment on the NMS managed network.
Risk impact is **low**, if:
* Managed network is segmented in a way that does not mix management traffic with payload data.
* Managed network uses single segment, but the number of connect devices in the network is low.
## B.3 Assumptions
Risk impact is **high**, if:
* Managed network is segmented, and the segmentation is trusted to provide additional security.
* Traffic classes including control, management and payload shares the same segment on the NMS managed network.
## B.4 Threats and connection to risk factors
## B.5 Mapping of risk factors to use cases
* Complex system design
* Requires an university degree to be able to work with the networks
* Poor documentation
* Variability in the implementations
* Old technologies Die Hard
* Once an interface is take into use, the value from the development needs to continue flowing
* High number of 3rd. party components
* Large market and a lot of players
* What the real dependency of all services is misty
* Layering problem
* Operative environment is complex and has multiple layers of responsibilities
Above threaths are adressed by [5.2.1 Architecture and design](#521-architecture-and-design).
* High number of software that is developed in-house or is tailor made
* Visibility to to production status is low
Above threaths are adressed by [5.3 No known exploitable vulnerabilities](#53-no-known-exploitable-vulnerabilities).
* Provided configuratoin is made easy to adopt and the pressure is to make results
* Interfaces implement crypto only after the software reaches maturity
* Old devices are functional, but lack cryto-agility
Above threaths are adressed by [5.4 Secure by default configuration](#54-secure-by-default-configuration).
* OS and the Applicaton are owned by separate teams
* OS can not be updated without disturbing the Application operation
* Version numbers are unique
* Recovery from failed updates results to downtime
Above threaths are adressed by [5.5 Security updates](#54-secure-by-default-configuration).
* Operative authority in systems is inherited from collegues
* Critical process execution is not guarded and auditable
Above threaths are adressed by [5.6 Authentication and access control](#56-authentication-and-access-control).
* A physical cable is trusted when the infrastructure routing is not always fully in control
* Used cryptography is old and know to be weak
* Old keys are forgotten to devices or they are hard to change
Above threaths are adressed by [5.7 Confidentiality protection](#57-confidentiality-protection)
and by [5.8 Integrity protection](#58-integrity-protection).
* Every data bit is collected without fully understanding what the dataset contains
* While the user identity can be recoverd, it is hard to tell what datasets contains PII.
Above threaths are adressed by [5.9 Data minimisation](#59-data-minimisation).
* Singularity results to interruptions when no fall back mechanisms are in place
* Available interfaces are targets for interference operations
Above threaths are adressed by [5.10 Availability protection](#510-availability-protection).
* Same network is used to serve the requesting users and to control the network
* Network control is affected when the serving routes are cognested
Above threaths are adressed by [5.11 Non-interference](#511-non-interference).
* What services are used are dependent on and available is not well known
* Systems call home and open a potential c&c channe
Above threaths are adressed by [5.12 Attack surface minimisation](#512-attack-surface-minimisation).
* Compromised device is used to access the central controller, the product
* Compromised device is used to access the network the controller is
Above threaths are adressed by [5.13 Exploit mitigation](#513-exploit-mitigation).
* Logs and metrics are modified to hide the attacker activity
* Investication of the attack is complex due to missing information
Above threaths are adressed by [5.14 Monitoring](#513-exploit-mitigation).
[5.15 Factory reset and data portability](#515-factory-reset-and-data-portability) is not really a threath for system described by this document apart from vendor locking which is done already when one decies what devices to use.
# Annex C (informative): Relationship between the present document and any related ETSI standards (if any, e.g. EN 303 645)
