Reply to post: Known knowns, known unknowns, and unknown unknowns

Known knowns, known unknowns, and unknown unknowns

One of the code review comments I've written: "Please use computer science to solve this problem." The developer had put in a sleep() to solve a resource problem. (He also didn't know the different between a function and a header macro.)

The problem with security is how hard is it to bypass it, and get to the target. Everybody wants something cheap, they want it now, and they want to plug it in and start using it.

We are faced with a paraphrase of what Donald Rumsfeld said, but in software security. There's always some weird crap happening, that some clever monkey has been able to figure out how to break the lock on the cage. ASLR has been broken by some clever JavaScript code. Who saw that one coming? And how about malicious code escaping from virtual machines?

There's a limit to what can be done. If you're one level above the end-user, then you can't do anything about the hardware in the CPU, or the code in the hypervisor. You can put down rules to keep a device from being accessed, but you can't do anything about the actual problem itself.

The manufacturer can do a certain number of things to "secure" the device, but even if they do their job, they still have to use code from someone else. How many IoT manufacturers write their own kernel?

The rules that should be in place are simple things, like requiring a good password the first time the device is used, and only offering additional services by manual configuration, not by default. For instance, if the device has a web UI, then require the consumer to log in via HTTPS, put in a good password, and then manually enable SNMP and SSH.