Will the Small IoT Device OEM Survive?

After decades of frustration, downstream users are about to get laws and regulations passed to force upstream IoT manufacturers to produce more secure IoT devices. This seems like a good thing, however, we are about to see an enactment of how new laws and regulations work to the advantage of big companies and to the disadvantage of small companies, eventually driving the latter out of business. As presented by Ruchir Sharma in his excellent book [1], regulations tend to favor large companies for two reasons: (1) large companies can afford the necessary resources to conform to the new laws and regulations and (2) large companies have the necessary resources to shape the new laws and regulations to favor themselves. Although these may be well-intentioned, initially, the eventual result is that smaller companies are forced out of business and only the large companies survive. Are we about to see this scenario play out for IoT device manufacturers? That is the subject of this paper.

The Problem — CVEs

To date, over 240,000 CVEs (vulnerabilities) have been reported, and the list is growing at over 30,000 per year. This amounts to more than 100 new ones each business day! Of all CVEs, 1/3 have been proven to be exploitable, but only 6% have actually been exploited “in the wild” (i.e. by hackers). The list of known exploited vulnerabilities, KEV, which is maintained by the government exceeds 15,000. This is a daunting number considering that all of them have actually been exploited by cyber criminals.

The Fix

The current approach for fixing CVEs in IoT devices is to develop a firmware patch (i.e. a code correction) to eliminate the vulnerability in the IoT firmware and to then update the firmware running on each device in the field. The typical time to develop a patch is about two weeks, but the time to install it depends upon numerous factors such as whether the device is internet-connected and who is installing the patch (i.e. the vendor, the distributor, or the user). The time to install an update can vary from minutes to months to never.

During the above patching delay, an IoT device having a CVE to patch is vulnerable to attack. This delay is important because following publication, 75% of CVEs are exploited within 19 days [2]. In many cases the hacking tools necessary to do this can be obtained on the internet – sometimes as SaaS (Software as a Service). And as cyber syndicates grow in size, researchers have found that hundreds of devices may be exploited simultaneously after a CVE is publicized [3].

This patch and put solution works fairly well for application and server software, but it is not ideal for IoT devices, most of which are classified as embedded systems. Embedded systems generally must meet tight deadlines when performing their main functions and are expected to operate 24/7, unsupervised. To install a patch, even remotely, usually requires shutting the device down and thus stopping whatever it is controlling. This can be a big problem for the user and may result in patch installations facing long delays.

A further problem with patch and put is that it does not protect against zero-days. A zero-day is a vulnerability that is exploited before it is publicized. A normal CVE is not publicized until vendors have had time to fix the problem. Not so with zero-days, for which vendors have zero time to fix the problems. In her book [4] Nicole Perlroth describes how our government and others have inventories of zero-days ready to be weaponized for large-scale attacks. One would hope there might be some form of detente here, similar to that for nuclear weapons, but this does not seem to be the case. In a recent report [5] over 50% of new, widely-exploited vulnerabilities were zero-days. These attacks are originating from state-tolerated and other large cyber syndicates. There actually is a black market in which zero days can be bought and sold.

Yet another problem with patch and put is that it does not protect against insider threats. In this case, an employee might install malware in a firmware update that is intended to fix a vulnerability in the firmware. Such malware can later be remotely activated by cyber criminals. This too is a growing problem. In a recent report [6] the average ransomware payment is now $2,000,000 and some are much more. With this kind of money in the offing, a cyber syndicate can afford to find vulnerable employees and to offer them sizeable bribes to plant malware.

Despite these problems and other shortcomings, patch and put is being baked-in to the new laws and regulations that are intended to improve the security of IoT devices. Next, we will explore why this is harmful to small and medium-size IoT device OEMs, as well as to the world-at-large.

The Harm

The general intent of new cyber laws and regulations is to make the IoT device OEMs responsible for the security of their devices and thus motivate them to make their devices secure. The problem with this is that those making the laws and regulations have settled upon a specific approach (patch and put) to accomplish this objective, and it is neither practical nor effective for IoT devices.

As noted above, over 100 new CVEs are reported every business day. According to new laws and regulations, OEMs are expected to determine if any of these CVEs are in their IoT devices and to report how they intend to fix them. This, by itself, is a massive job. Even if software or AI comes to the rescue to perform this daily chore, the next steps are equally difficult, which are to determine which of the new CVEs are exploitable, and then to fix them. The CISC KEV is of little help because the processing of CVEs is 30,000 behind – i.e. a whole year of new vulnerabilities. In addition, a private study [7] has determined that the CISC KEV appears to be listing only a small fraction of exploited vulnerabilities.

Without help, it is very difficult for small OEM teams to determine which CVEs are exploitable and which can be safely ignored. This task is burning out even large security teams. As a result, enormous time is being wasted fixing CVEs that are not exploitable [8]. Nonetheless, the OEM is expected to issue frequent reports specifying when each new CVE in its devices will be fixed and what the users should do in the meantime. (One large OEM advised users to disconnect all of its equipment from the internet!)

This is the kind of situation that benefits large companies. They can afford the enormous staffs necessary to comply with these draconian regulations. Smaller companies will simply go out of business trying to comply or paying stiff penalties and losing markets when they fail to do so. Inasmuch as small companies are the innovators, progress will suffer, and the IoT industry may become safe, yet dormant.

The Better Solution

There is a better solution to the exploding CVE problem for IoT devices and one that might save small to medium size IoT OEMs from extinction. It is called isolation. As illustrated in the figure below, firmware is split into partitions, represented by ovals, that are isolated from each other. If malware invades one partition, it cannot access data or code other partitions. The lower partitions are additionally protected from the upper partitions by what we call the pmode barrier. Both partition isolation and the pmode barrier are hardware-enforced. Thus malware cannot defeat them. Typically, mission-critical and trusted code is put below the pmode barrier and vulnerable, untrusted code is placed above the barrier, as shown.

Security is achieved through confinement, not through a never-ending battle with CVEs. Of course, OEM teams can choose to fix some CVEs but they are not forced to fix all of them. Partitioning works equally well against zero-days as against n-days (publicized vulnerabilities) and it allows development teams and maintenance teams to be divided into small groups, each of which can access only one or a few partitions. Full system access is reserved for highly-trusted individuals with sufficient skin in the game to guarantee their loyalty. This is called siloing.

We offer an RTOS, called SecureSMX, which enforces partitioning and offers many other security features. Using SecureSMX, an OEM development team can create a framework consisting of a partition for every firmware module needed by their device. Normally each partition contains at least one task and has at least one portal to communicate with other partitions. Initially, dummy code is put into each partition to emulate its expected size and processor loading. The framework is compiled and linked and actually runs before any new code is even written. Then each small team can develop and test its module within its partition in the framework, thus saving countless hours of system integration later. This approach conforms to current best software practices such as agile programming, CI/CD, and DevSecOps. When the code is done, integration is done, and security is baked in!

Additional advantages of partitioning:

• Partition-only rebooting allows exorcising malware in an infected partition while the rest of the system continues performing its main functions.
• Partition-only updates allow systems to continue operating while firmware in a vulnerable partition or partitions is updated.
• Partition-only updates avoid exposing trusted legacy firmware to more than a highly-trusted few, because it seldom needs to be updated.

References