One of the most significant problems facing the tech industry today is that of securing the so-called 'Internet of Things' - the vast mishmash of network-enabled gizmos and tchotchkes that seem to be the primary focus of development efforts today. When there are APIs available for toothbrushes, the likelihood of other random gadgets being equipped with network access looks to become a certainty - as is the likelihood those gadgets will be exploited in some fashion by criminals.
Much has been made of the dangers of implanting network connections into 'things' that have traditionally been standalone devices without any network capability, subject only to local control. The 'smart house' type gadgets, especially, have been the focus of much security research - from failures in so-called 'smart' refrigerators to physical security systems that turn out to be less than secure.
Part of the reason there is so much in the way of low-hanging fruit in the 'internet of things' security-wise is that the companies that manufacture these devices have no real expertise in software design and implementation - refrigerators of generations past were mostly mechanical devices; the more recent ones may have systems to run somewhat more sophisticated sensors, but all this development was geared towards a very simple set of operations carried out entirely within the device - certainly nothing that would have an attack surface outside of the house in which it was installed.
Therefore, when attaching network access to these devices, the companies in question tend to use commodity solutions - whatever's the cheapest way to get the thing "connected" to the "cloud" so that they can use that "feature" as a selling point.
Unfortunately, this means that the devices end up exposed to the internet without due attention being paid to the fact that this exposure changes the potential attack surface from "someone inside the house wrecking the device" to "someone connected to the internet somewhere in the world wrecking the device."
This problem, at least, can be solved with education - high-profile people getting attention in the various newspapers and trade sheets to tell manufacturers about the best practices for securing devices is one potential step; organizations like I Am The Cavalry providing necessary education and information to manufacturers is another.
Unfortunately, there is another factor at play here that makes even these measures less effective than they could be - that of asymmetrical resources between the 'things' and the potential attackers.
'Things' tend to be constrained in both power available to perform processing activities and in space available for processing resources. The consequence of this is the use of low-power, compact, and - importantly - slow and low-RAM SOC (systems-on-chip) microcontrollers, many of which have become available on the market in the past few years due to the trend of putting them in devices having such constraints.
While it is possible to write high-performance, high-efficiency code for such devices, such projects are very expensive and require significant expertise and development - so the usual result is that the companies manufacturing these 'Things' will grab whatever small-resource Linux distribution that can be installed on the thing easily and throw an application or two on top of it.
This will get the project out the door quickly, but it will not make the device operate efficiently - in most cases, standard libraries, including those for cryptography, will be used.
Further consequences arise from this use of standard libraries on low-power equipment - and this is where the asymmetric resources problem comes to a head.
Many security measures require very complex math to be performed in order to properly encipher communications. The more complex the math, the longer the time it takes to perform - and on very low power SOCs, this may noticeably slow down the device's operation.
If the device's operation slows noticeably, it ends up with signficiant problems in functionality - lag between control signals being sent and their functions executed, for instance, which would lead to a distinct lag between, say, telling a lightbulb to turn on and seeing it turn on.
This kind of user experience is very, very noticeable and ends up being criticized vocally - so if there's a way to mitigate it (by, for instance, using a less complex cipher scheme or just sending the commands in the clear) then manufacturers will be pressured to mitigate it in that fashion.
So there ends up existing a class devices with purposely crippled security due to resource constraints, sitting on globally available networks.
Also sitting on those globally available networks are much less constrained computing resources - everything from desktop machines with extra video cards to crypto-optimized ASICs to rent-a-supercomputer "cloud" resources - all of which are available to any attacker who has the budget to throw those solutions at whatever traffic they can capture and analyze.
The 'Things' don't stand a chance in this ecosystem.
This problem is much, much harder to solve, and unlike the previously mentioned one, cannot be solved only by educating vendors as to their responsibilities.
That's not to say there's not possible fixes - but these fixes are likely to be time consuming and expensive.
First, abandon the "Linux-on-SOC" notion - you do not need a full OS for a crock pot. These 'things' are generally single-functionality items with very few threads needed to handle their internal logic; the use of a small RTOS (real-time operating system - the kind that's used for things like engine monitoring, say, rather than the kind of OS used for a workstation) makes far more effective use of resources available.
Second, write your firmware as close to the metal as you possibly can. This is a resource-constrained system that you're developing for; the typical just-import-the-library philosophy that webapps and other consumer-facing nonsense has been chasing for years now (resulting in webpage sizes that compare unfavorably with the install image for Doom) is not the right way to go about it. Teach your developers how to build small, efficient binaries.
Third - hire a cryptographer and have them work in close concert with your developers. You need custom cryptographic functions, but having your line developers write them is a path towards disaster. Instead, it's best to work with those who are specifically trained in the cryptographic field - even on a part-time or contract basis - and have them assist your developers who are intimately familiar with your architecture and your hardware in building a similarly efficient and effective security system.
Fourth, avoid connecting your endpoints directly to the internet - yes, even to your 'cloud'. Your endpoint sensors and devices should never transit networks directly; they do not have the capability to do so safely. Have an on-site device relay to and from your sensor nodes (or, better, build an API so that someone else can build such a control panel to operate with your devices!) and configure it very conservatively - it is, essentially, the gateway to a horrifically vulnerable network, and should treat any incoming traffic with immense suspicion. Your consumers will interface with this device, NOT with the various lightbulbs or toothbrushes or showerheads that you've sprinkled about their house. If you're smart, this 'control panel' will be a great way for you to sell add-on services, too - it is, after all, a point of presence ultimately controlled by your organization in a consumer's house.
Finally, ensure that you have a very secure and very well-documented upgrade procedure for every single device that you sell, and be extremely proactive both in notifying consumers that you are updating the devices for security purposes and even more proactive when telling them that you are withdrawing support for a device. Leaving orphaned devices on the internet hurts security for everyone, and harms your professional reputation.
These steps are not simple, nor are they cheap, but they are a necessary set of actions to take in order to avoid bringing harm to your customers.
If you are unable to, or unwilling to, take these actions, then consider Adama's Rule - and do not connect your devices to a network.