@@ -864,6 +864,8 @@ The product shall operate in a secure configuration by default.
#### 5.2.5.2 **MI-ADEF**: Authorization required by default to access security-relevant assets
TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.
The product shall require appropriate authorization by default to access security-relevant assets, such as product firmware, security-relevant configuration, sensitive data, and sensitive functions.
Guidance: Appropriate authorization depends on the use case and the asset. For example, if the product's intended purpose is for integration into another product, then authorization is generally not necessary to access assets since the integrator will implement appropriate authorization. Another example would be encryption keys; these should not be readable without authorization such as password-based or pre-shared credentials/secrets from either hte host or the network.
@@ -958,6 +960,8 @@ See Section 5.3 for which mitigations are necessary for which security profiles
The product shall be securely updateable by the user.
> TODO: Specification of how secure updates can be done securely is in progress.
#### 5.2.6.2 **MI-SUDC**: Documentation of secure update
The product shall be accompanied by documentation of the secure update methods for any firmware or software in the product.
@@ -1031,6 +1035,8 @@ The product shall protect data stored on the product from unauthorized access.
#### 5.2.7.2 **MI-CDST**: Protect confidentiality of data stored on the product
> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.
The product shall protect data stored on the product from unauthorized access.
Guidance: This may include keys, firmware, configuration, packets, credentials, and data stored in volatile or non-volatile memory or storage.
@@ -1061,6 +1067,8 @@ The product shall protect data transmitted by the product from unauthorized acce
#### 5.2.8.2 **MI-CDTX**: Protect confidentiality of data transmitted by product
> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.
The product shall protect data transmitted by the product from unauthorized access on the local network.
Guidance: Protecting confidentiality of data transmitted across indirectly attached networks is not the responsibility of the network interface.
@@ -1107,6 +1115,8 @@ Guidance: Integrity may be protected by the environment, permissions, duplicatio
#### 5.2.10.2 **MI-IDST**: Protect integrity of data stored on the product
> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.
The product shall protect the integrity of data stored on the product from unauthorized modification.
* Reference: TR-IDST
@@ -1123,6 +1133,8 @@ The product shall protect the integrity of data stored on the product from unaut
#### 5.2.10.3 **MI-DCST**: Detect corruption of data stored
> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.
The product shall detect corruption of the data stored on the product.
* Reference: TR-IDST
@@ -1151,6 +1163,8 @@ Guidance: Integrity may be protected by the environment, permissions, duplicatio
#### 5.2.11.2 **MI-DCTX**: Detect corruption of data transmitted by the product
> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.
The product shall detect corruption of the data transmitted by the product.
* Reference: TR-IDTX
@@ -1225,19 +1239,19 @@ The product shall implement a mechanism to notify the host system when it detect
#### 5.2.13.4 MI-FDRP: Fast packet drop
TODO: Write mitigation requiring the interface to do validity checks on packets from both the network and the host in order of cheapest to most expensive so it can drop invalid packets with as little resource usage as possible.
> TODO: Write mitigation requiring the interface to do validity checks on packets from both the network and the host in order of cheapest to most expensive so it can drop invalid packets with as little resource usage as possible.
#### 5.2.13.5 MI-LMEM: Limit memory usage
TODO: Write mitigation requiring the interface limit memory usage triggered by user input via network or host.
> TODO: Write mitigation requiring the interface limit memory usage triggered by user input via network or host.
#### 5.2.13.6 MI-FAIR: Fair resource usage and prioritization
TODO: Write mitigation requiring the interface implement some form of ensuring fair resource usage by multiple sources of input, including the ability to prioritize some sources of input
> TODO: Write mitigation requiring the interface implement some form of ensuring fair resource usage by multiple sources of input, including the ability to prioritize some sources of input
#### 5.2.13.7 MI-DOST: Document risk transfer to operational environment for denial of service
TODO: Write mitigation documenting that the operational environment must provide denial of service protection, such as an external or internal firewall, fair queueing or filtering be the OS, a proxy, etc.
> TODO: Write mitigation documenting that the operational environment must provide denial of service protection, such as an external or internal firewall, fair queueing or filtering be the OS, a proxy, etc.
