Virtual interfaces: all the same issues as device drivers: bad pointer, buffer overflow, memory management errors, bad logic, etc.
This will be copied from OS - do not bother now
Physical interfaces:
* Copying data beyond end of packet and putting it on the network (overflow attack?)
* Incoming packets that trigger bad behaviour
* Bug that processing incoming packets stops packet processing
* 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: stress testing with just a lot of packets of different types?
* TR: general secure design stuff PT1 that we can only do if testable on product
* Bugs in chipset allowing unauthorized/malformed access to interface
* 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
* Bluetooth is exposed to the world and very common
* development/debug commands on wireless things
> FIXME lookup CVEs - anything from host-generated packets?
* 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?
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 this standard
