@@ -1564,120 +1564,6 @@ Threat: Attacker may degrade or stop the functions of the device driver.
Threat: Attacker may use unauthorized access to the device driver to harm other devices, including the host system.
Unsorted notes
Physical interfaces:
* Malicious/corrupted firmware updates - do this securely
* TR: the firmware update method must verify firmware in some way
* note that update can be done OS or other stuff
* IoT things updated over wifi
* development/debug commands accessible externally from host
* TR: debug interfaces disabled by default
* TR: debug interface is only used by authorized users via SoTA
* extended feature sets not generally used by default
* TR: disabled by default
* automatically connecting to an open network where a closed/encrypted one was remembered
* buffer overflow (in network interface)
* TR: bounds check on packet buffer descriptors
* TR: bounds check on any kind of length field
* TR: contains only data host wants sent
* TR: compiler-based checks
* DoS by external packets
* TR: do validity checks as soon as possible before doing lots of processing
* switching to less secure state without user realiziing it
* TR: test that it doesn't do this
* TR: reset of firmware does not lose security configuration
* stack smashing (overwrite return address or value on stack)
* TR: general stack stuff
* encryption failures in on-interface implementations WPA2, MACSEC
* TR:
* bugs in various offload features
* segmentation offload - recommend specific tests?
* programmable FPGA
* as long as not doing something by default, this is sophisticated user
* remote management interface
* TR: disabled by default
* TR: no default auth by default
* TR: auth should be done
* remote boot
* TR: disabled by default
* remote firmware update
* TR: disabled by default
* TR: tests on source code provided to the MSA (not necessarily public)
* TR: DAST dynamic applications security testing
* TR: open source your code and use open source tools?
Done
* TR: watchdog timeout that resets card if packets aren't coming out right?
* TR: fuzz testing of network input packets (directed maybe, specify numbers and test?)
* TR: general secure design stuff PT1 that we can only do if testable on product
FIXME: reference or use IEC 62443 certification? industrial use case, mostly for B2B relationships, suppliers, sophisticated, we are more consumer-related, probably can't base it on but we can find some overlap and inspire the present document
Potential sources of threats:
A generic CVE for many NICs that copied data beyond the end of the packet in memory and sent it on the network.
Where is the manufacturer the best place to mitigate the risks? Those should be the ones the manufacturer treats, otherwise they are documented for the integrator.
Don't ship with undocumented interfaces!!!
Problems with protocols working as designed are not in scope.
Problems with the implementation of the protocols by the interface are in scope.
Is there a use case where we care about glitching of the network interface itself? think about it
----
* Disable all interfaces that intercept incoming packets above data link layer and do not pass them to the to the host
* Check that outgoing packets only contain the data requested to be copied from host
* Don't auto-connect to an network that is not really the same network
## C.3 Assumptions
> List assumptions that are relevant to the risk analysis for these threats. Everything is hackable if you try hard enough. What kinds of threats are in and out of scope? What are you assuming is the sophistication of attack? Relate to use cases.
* Malicious/corrupted firmware updates - do this securely
* TR: the firmware update method must verify firmware in some way
* note that update can be done OS or other stuff
* IoT things updated over wifi
* development/debug commands accessible externally from host
* TR: debug interfaces disabled by default
* TR: debug interface is only used by authorized users via SoTA
* extended feature sets not generally used by default
* TR: disabled by default
* automatically connecting to an open network where a closed/encrypted one was remembered
* buffer overflow (in network interface)
* TR: bounds check on packet buffer descriptors
* TR: bounds check on any kind of length field
* TR: contains only data host wants sent
* TR: compiler-based checks
* DoS by external packets
* TR: do validity checks as soon as possible before doing lots of processing
* switching to less secure state without user realiziing it
* TR: test that it doesn't do this
* TR: reset of firmware does not lose security configuration
* stack smashing (overwrite return address or value on stack)
* TR: general stack stuff
* encryption failures in on-interface implementations WPA2, MACSEC
* TR:
* bugs in various offload features
* segmentation offload - recommend specific tests?
* programmable FPGA
* as long as not doing something by default, this is sophisticated user
* remote management interface
* TR: disabled by default
* TR: no default auth by default
* TR: auth should be done
* remote boot
* TR: disabled by default
* remote firmware update
* TR: disabled by default
* TR: tests on source code provided to the MSA (not necessarily public)
* TR: DAST dynamic applications security testing
* TR: open source your code and use open source tools?
Done
* TR: watchdog timeout that resets card if packets aren't coming out right?
* TR: fuzz testing of network input packets (directed maybe, specify numbers and test?)
* TR: general secure design stuff PT1 that we can only do if testable on product
FIXME: reference or use IEC 62443 certification? industrial use case, mostly for B2B relationships, suppliers, sophisticated, we are more consumer-related, probably can't base it on but we can find some overlap and inspire the present document
Potential sources of threats:
A generic CVE for many NICs that copied data beyond the end of the packet in memory and sent it on the network.
Where is the manufacturer the best place to mitigate the risks? Those should be the ones the manufacturer treats, otherwise they are documented for the integrator.
Don't ship with undocumented interfaces!!!
Problems with protocols working as designed are not in scope.
Problems with the implementation of the protocols by the interface are in scope.
