|
|
|
|
|
by tzs
3803 days ago
|
|
"Exploits are always changing" is not really a meaningful objection, because it applies to every way that one might try to ensure security short of only deploying software and systems that have been mathematically proven to be secure. The vast majority of exploits against IoT devices do not involve new exploits. They involve ridiculously ancient exploits, like finding plaintext passwords embedded in the firmware, or adding something like "&admin=1" to the end of a URL. If we could get to the point where breaking an IoT device requires something like finding a hole in, say, the TLS protocol (or in a widespread TLS library), rather than just looking because the damn thing doesn't use encryption at all, we'd be vastly better off than we are now. This is what I meant when I said, "I'd be happy for now just having some rules to try to make it so IoT device breaches are mostly due to bugs in the implementation of a good design, rather than due to the producers not having a clue about security". Right now far too many devices are vulnerable even if they are 100% bug free. |
|
For IOT, the bigger problem is that most of this stuff is getting deployed on BOM constrained designs, so they can't take advantage of safe programming environments, but instead pretty much have to link random C libraries together.