Refinements of requirements from meeting

The product shall operate in a secure configuration by default.

#### 5.2.X.x **MI-ADEF**: Authorization required by default to access security-relevant assets

What are things that can be configured to be insecure? - hardware, software?

The product shall require authorization by default to access security-relevant assets, such as product firmware, security-relevant configuration, sensitive data, and sensitive functions.

Debug interfaces

  * Reference: TR-SDEF

 * usable from the host (over the system bus) - not important, the host must protect this - but we do need to specify that this is transferred to the host

 * usable from the attached network - these do need to be specified as disabled or protected for end users

 * debug interface requires external device (JTAG)

Remember the integrator - debug enabled is okay there as long as documented

#### 5.2.X.x **MI-SDEH**: Host controls access to interface

  * Objective: Find any unauthorized access to security relevant assets in default configuration

All interfaces for the product whose access is controlled solely by the host system shall have documentation describing the level of security necessary for the host system to protect them from unauthorized access.

  * Preparation: List all interfaces allowing access to security-relevant assets

FIXME make clear the host system can implement this however

  * Activities: For each interface, attempt to access security-relevant assets without authorization and record whether access was allowed or not

FIXME what are the different security requirements for interfaces, how to define them as lo/me/hi

  * Verdict: If every interface does not allow access without authorization => PASS, otherwise => FAIL

FIXME FIXME supply chain info about low/medium/high security is completely unclear and doesn't make sense FIXME

Example: encryption keys - don't want any unpriviliged user on the host to be able to read these

packet buffers - same

version of firmware - could be fine for anybody

  * Applicability: Physical interface

  * Reference: TR-SDEF

  * Objective: Secure by default

  * Preparation: Define a method that can be used to find all interfaces on the device accessible from the host

  * Activities: For each interface, review the documentation to see if it is listed

  * Verdict: If every interface discovered is listed in the documentation => PASS, otherwise => FAIL

  * Evidence: List of interfaces allowing access to security-relevant assets, record of activities used to attempt unauthorized access to security-relevant assets, log of results of attempts

#### 5.2.X.x **MI-SDEE-1**: Physical access to debug interface

For use case of selling to an integrator

All debug interfaces accessible to someone with physical access to the device shall be documented as to how to protect or disable them.

  * Applicability: Physical interface

  * Reference: TR-SDEF

  * Objective: Secure by default

  * Preparation: Physically examine the device for interfaces

  * Activities: Compare the physical interfaces of the device with the documentation

  * Verdict: All physical interfaces are documented as to how to disable or protect them => PASS, otherwise => FAIL

  * Evidence: Pictures of the device, list of discovered interfaces, comparison with documentation, notes as to which are documented how to disable/protect

#### 5.2.X.x **MI-SDEE-2**: Physical access to debug interface

For use case of end user

All debug interfaces accessible to someone with physical access to the device shall be protected or disabled.

FIXME need a requirement that all interfaces are documented

  * Applicability: Physical interface

  * Reference: TR-SDEF

  * Objective: Secure by default

  * Preparation for the person testing the product, not the manufacturer: Physically examine the device for interfaces, read documentation

  * Activities: Attempt to use the interfaces without enabling the interface or otherwise removing protection

  * Verdict: No interface can be used => PASS, otherwise => FAIL

  * Evidence: List of interfaces, log of attempts to access

#### 5.2.X.x **MI-SDEE-3**: Network access to interfaces

For use case of end user

All debug/remote management interfaces accessible via the network shall be protected or disabled.

  * Applicability: Physical interface

  * Reference: TR-SDEF

  * Objective: Secure by default

  * Preparation:

  * Activities:

  * Verdict: No interface can be used => PASS, otherwise => FAIL

  * Evidence: List of interfaces, log of attempts to access

#### 5.2.X.x **MI-SDEE**: Generic version

Manufacturer documents all interfaces with sensitivity of function/data

If pre-integration, then documented how to protect and disable

If post-integration, then protected or disabled based on ??? sensitivity/use

Necessary for functions?

Interface to host is always necessary

Interface to do normal network stuff over the network is always necessary

Debug is temporarily disabled for post-integration

FIXME: define disabled in definitions as temporarily/reversibly disabled - leave some room for manufacturer to permanently disable if necessary for security

How to say disable interfaces accessible from the network that provide access to something more than tx/rx stuff?

Remote management?

Depending on the risk factor of who has access to the network => require authorization by default for remote management or debug over the network or disabled

#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

| Risk factors        | Requires mitigations |

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

| any                 | ADEF                 |

| FIXME risk factor   | SDEE-1               |

| FIXME risk factor   | SDEE-2               |

| Security Profile    | Requires mitigations |

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

| all                 | ADEF                 |

| FIXME integrator    | SDEE-1               |

| all others          | SDEE-2               |

### 5.2.X **TR-CONF**: Confidentiality of assets

FIXME split this up into types of data, which may require different mitigations

NOTE this is about once you have it configured securely, does it actually protect the data

The product shall protect confidential data stored on the product from unauthorized access.

  * Reference: TR-CONF

  * Evidence: Logs of attempts to read confidential data with indication of success or failure

FIXME split into two things

What types of data are there on a network interface, split up by how they should be protected?

Readable only by privileged user:

* Security keys for validation of access to itself (firmware, management access)

* Security keys for packet encryption or network access

* All accessible host data and functions

Okay to read by anyone:

* Firmware ?

* Device identity (MAC address etc.)

* Device configuration (transmit power/channel configuration/options)

* Statistics

* Device driver stored on device, if any

#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

| Risk factors        | Requires mitigations |

#### 5.2.X.x **MI-TCNF**: Confidentiality of data transmitted by product

FIXME split this up into types of data transmitted, which may require different mitigations

The product shall protect data transmitted by the product from unauthorized access.

FIXME require documentation of the level of security in transmitting data provided by the product to other parts of the system.

  * Reference: TR-CONF

  * Objective: Confidentiality of data

  * Preparation: List all methods of transmitting confidential data, all methods of accessing that data available to an attacker based on the risk assessment, and what the allowable authorization methods are for that access method

  * Activities: For each method of data transmission and each access mechanism, attempt to read the transmitted data without authorization

  * Verdict: If all the attempts to read confidential data fail => PASS, otherwise => FAIL

  * Evidence: Logs of attempts to read data transmitted with indication of success or failure

  * Applicability: (for requirements that depend on a feature)

  * Reference: TR-

  * Objective: 

  * Preparation: 

  * Activities: 

  * Verdict: 

  * Evidence: 

#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

* Security keys for packet encryption or network access

* Device driver stored on device, if any

* All accessible host data and functions

* Packet data

#### C.1.1.2 Virtual network interfaces or device drivers