@@ -916,47 +916,6 @@ The product shall zero-initialize all heap memory before use.
| WD-1 | None |
| all others | IMSL or (MSAF-\*, MZRO-\*) |
### 5.2.X.x **TR-AVAI**: Availability
#### 5.2.X.x Requirement
The product shall protect the availability of essential and core functions.
#### 5.2.X.x MI-WDOG: Watchdog and self-initiated reset
The network interface shall implement a mechanism to trigger an automatic reset when it detects that it is no longer able to perform its functions.
* Applicability: physical network interfaces that have a remote management feature
* Preparation: document the conditions that indicate the device cannot perform its functions
* Test: cause each of the conditions to occur
* Result: for each condition, the network interface resets itself
* Output: error, log message, statistics update, or other information from card indicating reset of network interface
#### 5.2.X.x MI-NTFY: Watchdog and notification of host
The network interface shall implement a mechanism to notify the host system when it detects that it is no longer able to perform its functions.
* Preparation: document the conditions that indicate the device cannot perform its functions
* Test: cause each of the conditions to occur
* Result: for each condition, the notification is received by the host
* Output: error, log message, statistics update, or other information from card indicating error notification was received
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
FIXME update mitigation mapping below for MI-NTFY
FIXME define a security profile for interfaces that are the primary interface
| Risk factors | Requires mitigations |
|--------------|----------------------|
| FUN < 2 | NTFY or WDOG |
| all others | WDOG |
| Security Profile | Requires mitigations |
|------------------|----------------------|
| FIXME | NTFY or WDOG |
| all others | WDOG |
### 5.2.X **TR-SDEF**: Secure by default configuration
#### 5.2.X.x Requirement
@@ -1065,6 +1024,97 @@ Guidance: For use case of end user for backwards compatibility with insecure pro
| FIXME integrator | ADEF, DPAH, SDEE-1 |
| all others | ADEF, DPAH, SDEE-2 |
### 5.2.X **TR-SCUD**: Secure updates
#### 5.2.X.x Requirement
The product shall be securely updateable by the user.
> FIXME add versions for device driver and virtual network interface.
#### 5.2.X.x **MI-SCFM**: Secure update of firmware
The product shall provide a method of updating its firmware from the host system.
* Applicability: Product is a physical network interface
* Reference: TR-SCUD
* Objective: Secure updates
* Preparation: Prepare a new firmware image with a different version number from the currently installed firmware
* Activities: Check the firmware version, install the new firmware, and check the firmware version
* Verdict: The second version number is that of the new firmware => PASS, otherwise FAIL
* Evidence: Log of querying the firmware version, installing the new firmware, and querying the firmware version again
#### 5.2.X.x **MI-SCDC**: Documentation of secure update of firmware
The product shall be accompanied by documentation of the secure update methods for the physical network interface.
* Reference: TR-SCUD
* Objective: Secure updates
* Activities: Assess the documentation for completeness
* Verdict: Documentation describes secure update methods sufficiently for a third party to implement them => PASS, otherwise FAIL
* Evidence: Documentation and analysis of completeness
#### 5.2.X.x **MI-SCDD**: Secure update of firmware via device driver
The device driver shall provide a method of updating the firmware on the device.
* Applicability: Device driver supplied with physical network interface
* Reference: TR-SCUD
* Preparation: Prepare a new firmware image with a different version number from the currently installed firmware
* Activities: Check the firmware version, install the new firmware, and check the firmware version
* Verdict: The second version number is that of the new firmware => PASS, otherwise FAIL
* Evidence: Log of querying the firmware version, installing the new firmware, and querying the firmware version again
#### 5.2.X.x **MI-SCHL**: Low security updates provided by operational environment
The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "Low" security level for the product supplying it.
* Reference: TR-SCUD
* Objective: Secure updates
* Activities: Assess the documentation provided with the product
* Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL
* Evidence: Documentation and analysis of completeness
#### 5.2.X.x **MI-SCHM**: Medium secure updates provided by operational environment
The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "Medium" security level for the product supplying it.
* Reference: TR-SCUD
* Objective: Secure updates
* Activities: Assess the documentation provided with the product
* Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL
* Evidence: Documentation and analysis of completeness
#### 5.2.X.x **MI-SCHH**: High secure updates provided by operational environment
The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "High" security level for the product supplying it.
* Reference: TR-SCUD
* Objective: Secure updates
* Activities: Assess the documentation provided with the product
* Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL
* Evidence: Documentation and analysis of completeness
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
| Risk factors | Requires mitigations |
|---------------------|----------------------|
| any | SCFM, SCDD, SCDC |
| RSKL | SCDL |
| RSKM | SCDM |
| RSKH | SCDH |
FIXME define RSKL/M/H as a function of other risk factors
| Security Profile | Requires mitigations |
|---------------------|---------------------- |
| VI-1 | SCDL |
| VI-2 | SCDM |
| WD-1 | SCFM, SCDD, SCDC, SCDL |
| WD-2 | SCFM, SCDD, SCDC, SCDM |
| WL-1 | SCFM, SCDD, SCDC, SCDL |
| WL-1 | SCFM, SCDD, SCDC, SCDM |
### 5.2.X **TR-CDST**: Confidentiality of data stored on the product
#### 5.2.X.x Requirement
@@ -1225,6 +1275,79 @@ The product shall detect corruption of the data transmitted by the product.
All mitigations are required for all products.
### 5.2.X **TR-DMIN**:
#### 5.2.X.x Requirement
The product shall minimize the data processed.
#### 5.2.X.x **MI-DJST**: Document and justify processed data
All sources of data processed by the product in its secure-by-default configuration shall be documented. All sources of data processed shall have a documented rationale for why its processing is necessary for the functioning of the product in its secure-by-default configuration.
* Reference: TR-DMIN
* Objective: Minimize data processed
* Preparation: List all potential sources of data for the product. For each source of data, identify a method to detect whether the product is processing data from that source.
* Activities: Using the list of sources of data, and the method to detect whether the product is processing data from that source, list all sources of data processed. Compare to the documented list.
* Verdict: All sources of processed data are documented, including rationale => PASS, otherwise => FAIL
* Evidence: List of sources of data, documentation of each source of data, list of sources of data processed, connection between each discovered source of processed data to its documentation
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
| Risk factors | Requires mitigations |
|---------------------|----------------------|
| any | DJST |
| Security Profile | Requires mitigations |
|---------------------|----------------------|
| any | DJST |
### 5.2.X.x **TR-AVAI**: Availability
#### 5.2.X.x Requirement
The product shall protect the availability of essential and core functions.
#### 5.2.X.x MI-WDOG: Watchdog and self-initiated reset
The network interface shall implement a mechanism to trigger an automatic reset when it detects that it is no longer able to perform its functions.
* Applicability: physical network interfaces that have a remote management feature
* Preparation: document the conditions that indicate the device cannot perform its functions
* Test: cause each of the conditions to occur
* Result: for each condition, the network interface resets itself
* Output: error, log message, statistics update, or other information from card indicating reset of network interface
#### 5.2.X.x MI-NTFY: Watchdog and notification of host
The network interface shall implement a mechanism to notify the host system when it detects that it is no longer able to perform its functions.
* Preparation: document the conditions that indicate the device cannot perform its functions
* Test: cause each of the conditions to occur
* Result: for each condition, the notification is received by the host
* Output: error, log message, statistics update, or other information from card indicating error notification was received
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
FIXME update mitigation mapping below for MI-NTFY
FIXME define a security profile for interfaces that are the primary interface
@@ -1257,6 +1380,37 @@ All exposed interfaces on the product in any state that is part of its reasonabl
|---------------------|----------------------|
| any | JSTY |
### 5.2.X **TR-LOGG**: Logging and monitoring
#### 5.2.X.x Requirement
The product shall record security-relevant internal events, including but not limited to changes to configuration and access or modification of data and functions. The product shall provide an opt-out mechanism.
#### 5.2.X.x **MI-LOGG**: Logging
The product shall record log messages indicating security-relevant internal events in an internal or external log. The log messages shall not include any confidential information such as PII, secrets, or credentials, or any information which might reasonably be expected to include such items.
* Reference: TR-LOGG
* Objective: Monitoring and recording security-relevant events
* Preparation: List all types of security-relevant internal events
* Activities: For each type of security-relevant internal event, trigger the event
* Verdict: For each triggered event, the log contains a message indicating the event, log message does not include any information likely to be confidential => PASS, otherwise FAIL
* Evidence: Method of triggering events, log messages with annotations
Guidance: One type of event whose log message must take care to not accidentally include a secret is failed password authentication attempts. Since people often type their password into the username field, including the username field in the log message may result in including a secret in the log message.
| LOC < 1 & SDS < 1 & FUN < 1 & SYS < 1 & NET < 1 | none |
| all others | LOGG |
| Security Profile | Requires mitigations |
|------------------|----------------------|
| FIXME | none |
| all others | LOGG |
> FIXME: Update when risk factors are updated
### 5.2.X **TR-SCDL**: Secure deletion
#### 5.2.X.x Requirement
@@ -1385,160 +1539,6 @@ The product shall provide a method by which an authorized user can securely tran
> FIXME: Update when risk factors are fully filled out
### 5.2.X **TR-DMIN**:
#### 5.2.X.x Requirement
The product shall minimize the data processed.
#### 5.2.X.x **MI-DJST**: Document and justify processed data
All sources of data processed by the product in its secure-by-default configuration shall be documented. All sources of data processed shall have a documented rationale for why its processing is necessary for the functioning of the product in its secure-by-default configuration.
* Reference: TR-DMIN
* Objective: Minimize data processed
* Preparation: List all potential sources of data for the product. For each source of data, identify a method to detect whether the product is processing data from that source.
* Activities: Using the list of sources of data, and the method to detect whether the product is processing data from that source, list all sources of data processed. Compare to the documented list.
* Verdict: All sources of processed data are documented, including rationale => PASS, otherwise => FAIL
* Evidence: List of sources of data, documentation of each source of data, list of sources of data processed, connection between each discovered source of processed data to its documentation
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
| Risk factors | Requires mitigations |
|---------------------|----------------------|
| any | DJST |
| Security Profile | Requires mitigations |
|---------------------|----------------------|
| any | DJST |
### 5.2.X **TR-SCUD**: Secure updates
#### 5.2.X.x Requirement
The product shall be securely updateable by the user.
> FIXME add versions for device driver and virtual network interface.
#### 5.2.X.x **MI-SCFM**: Secure update of firmware
The product shall provide a method of updating its firmware from the host system.
* Applicability: Product is a physical network interface
* Reference: TR-SCUD
* Objective: Secure updates
* Preparation: Prepare a new firmware image with a different version number from the currently installed firmware
* Activities: Check the firmware version, install the new firmware, and check the firmware version
* Verdict: The second version number is that of the new firmware => PASS, otherwise FAIL
* Evidence: Log of querying the firmware version, installing the new firmware, and querying the firmware version again
#### 5.2.X.x **MI-SCDC**: Documentation of secure update of firmware
The product shall be accompanied by documentation of the secure update methods for the physical network interface.
* Reference: TR-SCUD
* Objective: Secure updates
* Activities: Assess the documentation for completeness
* Verdict: Documentation describes secure update methods sufficiently for a third party to implement them => PASS, otherwise FAIL
* Evidence: Documentation and analysis of completeness
#### 5.2.X.x **MI-SCDD**: Secure update of firmware via device driver
The device driver shall provide a method of updating the firmware on the device.
* Applicability: Device driver supplied with physical network interface
* Reference: TR-SCUD
* Preparation: Prepare a new firmware image with a different version number from the currently installed firmware
* Activities: Check the firmware version, install the new firmware, and check the firmware version
* Verdict: The second version number is that of the new firmware => PASS, otherwise FAIL
* Evidence: Log of querying the firmware version, installing the new firmware, and querying the firmware version again
#### 5.2.X.x **MI-SCHL**: Low security updates provided by operational environment
The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "Low" security level for the product supplying it.
* Reference: TR-SCUD
* Objective: Secure updates
* Activities: Assess the documentation provided with the product
* Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL
* Evidence: Documentation and analysis of completeness
#### 5.2.X.x **MI-SCHM**: Medium secure updates provided by operational environment
The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "Medium" security level for the product supplying it.
* Reference: TR-SCUD
* Objective: Secure updates
* Activities: Assess the documentation provided with the product
* Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL
* Evidence: Documentation and analysis of completeness
#### 5.2.X.x **MI-SCHH**: High secure updates provided by operational environment
The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "High" security level for the product supplying it.
* Reference: TR-SCUD
* Objective: Secure updates
* Activities: Assess the documentation provided with the product
* Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL
* Evidence: Documentation and analysis of completeness
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
| Risk factors | Requires mitigations |
|---------------------|----------------------|
| any | SCFM, SCDD, SCDC |
| RSKL | SCDL |
| RSKM | SCDM |
| RSKH | SCDH |
FIXME define RSKL/M/H as a function of other risk factors
| Security Profile | Requires mitigations |
|---------------------|---------------------- |
| VI-1 | SCDL |
| VI-2 | SCDM |
| WD-1 | SCFM, SCDD, SCDC, SCDL |
| WD-2 | SCFM, SCDD, SCDC, SCDM |
| WL-1 | SCFM, SCDD, SCDC, SCDL |
| WL-1 | SCFM, SCDD, SCDC, SCDM |
### 5.2.X **TR-LOGG**: Logging and monitoring
#### 5.2.X.x Requirement
The product shall record security-relevant internal events, including but not limited to changes to configuration and access or modification of data and functions. The product shall provide an opt-out mechanism.
#### 5.2.X.x **MI-LOGG**: Logging
The product shall record log messages indicating security-relevant internal events in an internal or external log. The log messages shall not include any confidential information such as PII, secrets, or credentials, or any information which might reasonably be expected to include such items.
* Reference: TR-LOGG
* Objective: Monitoring and recording security-relevant events
* Preparation: List all types of security-relevant internal events
* Activities: For each type of security-relevant internal event, trigger the event
* Verdict: For each triggered event, the log contains a message indicating the event, log message does not include any information likely to be confidential => PASS, otherwise FAIL
* Evidence: Method of triggering events, log messages with annotations
Guidance: One type of event whose log message must take care to not accidentally include a secret is failed password authentication attempts. Since people often type their password into the username field, including the username field in the log message may result in including a secret in the log message.
