Commit 8f522b18 authored by August Bournique's avatar August Bournique Committed by Santeri Toikka
Browse files

HAS 63 Issue #102 Section 5.3 Intro

parent 14ea2d68
Loading
Loading
Loading
Loading
+19 −5
Original line number Diff line number Diff line
@@ -567,13 +567,13 @@ The examples given in each use case are for a finished product that includes the

A Cybersecurity requirement is a security or other functional element that a product must have to comply with this standard. An ideal cybersecurity requirement is technical, meaning it is objectively testable on an instance of the product. If a cybersecurity requirement cannot be tested on the product itself, it is a cybersecurity documentation requirement, where the manufacturer documents the steps they have taken to implement it. Any documentation required to meet the cybersecurity requiremetns of this standard must be detailed (including materials such as configuration files or written policies used by employees), and will ideally be sufficent replicate the manufacturer's tests. Limited documentation, such as that indicating only that a test was completed, do not meet the cybersecurity requirements of this standard.

Mitigations are how a technical cybersecurity requirement can be satisfied. Mitigations provided in this standard are tailored to the use case and take into account the user’s sophistication and the operational environment.
Each technical requirement provided in clause 5.2 consists of various mitigations, security features or elements that a product shall include. Mitigations are how a technical cybersecurity requirement can be satisfied. Mitigations provided in this standard are tailored to the use case of the product and take into account the user’s sophistication and the operational environment. However, mitigations may vary considerably based on a product's use case and the risk factors associated with it. The list of appropriate mitigations for a use case is captured a security profile listing all necessary technical requirements. Secuirty profiles are listed below in clause 5.3.

While risks may not be transffered to the user, some risks may be treated partially or fully by other, connected elements of the system. When that is the case, mitigations that allow a risk to be treated externally are included as an option to fulfill a technical cybersecurity requirement, depending on the use case and risk factors.

**IMPORTANT:** Not all cyberseecurity requirements are necessary for all products. The mapping tables at the end of each cybersecurity requirement shows which risk factors and use cases determine which cybersecurity requirements are necessary for the product.
**IMPORTANT:** Not all cyberseecurity requirements or mitigations are necessary for all products. The mapping tables at the end of each cybersecurity requirement shows which risk factors and use cases determine which cybersecurity requirements are necessary for the product.

**See Annex C for more information.**
**See Annexes C and D for more information.**


## 5.2 Technical cybersecurity requirements specifications
@@ -1446,11 +1446,25 @@ The product shall have vulnerability handling processes compliant with prEN 4000
  * Verdict: Vulnerability handling documentation is compliant with prEN 40000-1-3 [\[3\]].(#_ref_3) => PASS, otherwise FAIL
  * Evidence: Vulnerability handling documentation, comparison with  prEN 40000-1-3 [\[3\]](#_ref_3).

## 5.3 Risk Mitigation Sets
## 5.3 Security Profiles

This clause lists all the mitigations necessary to meet cybersecurity requirements for each security profile. 

### 5.3.1 Introduction

This clause lists all the mitigations necessary to meet cybersecurity requirements for each security profile.
Security profiles in the context of this document are an intermediary tool that connects specific cybersecurity technical requirement and thier associated mitigations with product use cases. 
Each security profile below applies to one or more use case and includes a list of technical requirements and mitigations that are necessary to secure the products described by the use case.
It is worth noting that neither security profiles or use cases constitute exhuastive lists and that they do not include mitigations intended to provide guidance on due diligence for components or product functions performed by non-RDPS remote services.

To apply a security profile to a specific product the manufacturer shall implement the technical requirements and mitigations it containes per clause 5.2 of this document and need not implement technical requirements or mitigations unlisted in the security profile.
For some security profiles products are given the option to apply one or more from a list of related technical requirments and mitigations based on the functions, implementation, security constraints, and what is most secure and practicable for the specific product.
This option is noted by the use of "or" between technical requirements and mitigations listed in the security profile, or in cases where there are technical requirements with multiple mitigations, this is noted by the same alphabetic abbreviation followed by a "-\*" to indicate that any for the mitigations may be utilized to satisfy the technical requirement.

Security profiles are abbreviated with a set of letters and numbers denoting their general characteristics.
This abbreviation begins with "SP" to indicate that the abbreviation describes a security profile and is followed by another two letters indicating if the profile is for a wired interface ("WD"), wireless interface ("WL"), or virtual interface ("VI").
Finally, the abbreviation includes a number to indicate it with greater specificity, with higher numbers generally indicating security profiles of greater complexity.  

Use cases, as described in clause 4.7 above, are mapped to appropriate security profile by reference to the table in Annex C.5.2 

### 5.3.1 Wired network interface risk mitigation sets