Commit b73c7e30 authored by August Bournique's avatar August Bournique
Browse files 

HAS Comments 34-36
Issues #75 #74 & #73

Deleted much of 5.1 including all discussion of sweeps, and usefulness of documenting tests to allow replication by MSAs, and noting MSA authority to perform sweeps etc. I did not move this information to the annex. Rewrote sentences around documentation requirements to emphasize replicability of testing without "check box" discussion that comments suggested deletion of.

Also revised the discussion of risk transfer to be in line with the new EC guidance (no risk transfer to users) by focusing on system dependencies rather then transfer of risk.
parent c714fe14

EN-304-625.md

+5 −18
Original line number Diff line number Diff line
@@ -571,29 +571,16 @@ The examples given in each use case are for a finished product that includes the 


## 5.1 Notes on the structure of cybersecurity requirements



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



**See Annex C for more information.**



The ideal quality of a cybersecurity requirement is that it should be technical, meaning it is objectively testable on an instance of the product. If it cannot be tested on the product itself, it is a cybersecurity documentation requirement, in which the manufacturer documents the steps they took to implement the cybersecurity  requirement (such as configuration files or written policies used by employees).



The alternative is “check-box” cybersecurity requirements, which only require that the vendor says that they did a thing (“Did you have every commit code-reviewed by a second person? [x] Yes [ ] No”). These are not acceptable and should be converted into testable cybersecurity requirements if possible and documentation based cybersecurity requirements otherwise.

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.



The CRA requires the manufacturer to keep all the documentation necessary to show that the tests were conducted. In addition, the CRA explicitly grants the MSA the following rights in Article 13 Recommendation 22:

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.



> \"Manufacturers shall, upon a reasoned request from a market surveillance authority, provide that authority, in a language which can be easily understood by that authority, with all the information and documentation, in paper or electronic form, necessary to demonstrate the conformity of the product with digital elements and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Annex I. Manufacturers shall cooperate with that authority, at its request, on any measures taken to eliminate the cybersecurity risks posed by the product with digital elements which they have placed on the market.\"

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.



The goal is that when the MSA does a “sweep” or otherwise decides to verify a product’s conformance with the CRA, it has enough information that it can do its own independent testing without unnecessary barriers that could be solved by vendor documentation (e.g., does not have to reverse-engineer how to attach a serial console and read logs). Note that it is easer for an MSA to evaluate conformance via transparency - reviewing the test output and documentation to evaluate whether a mitigation is implemented - over actually testing the product themselves.



A few assumptions that we are making:



* Manufacturers are already required to provide the ability to enable testing and collect output on the product as placed on the market, and will supply instructions for enabling and collecting test data.



* The MSA can and will request source code if desired.

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



Mitigations are how a technical cybersecurity requirement can be satisfied. Mitigations should be tailored to the use case and take into account the user’s sophistication and the operational environment.

**See Annex C for more information.**



Some risks may be transferred partially or fully to other components of the system or the user of the product. When that is the case, mitigations that transfer the risk will be included as an option to fulfill a technical cybersecurity requirement, depending on the use case and risk factors.



## 5.2 Technical cybersecurity requirements specifications