The IoT Cybersecurity Improvement Act of 2017 is well on its way to becoming law. With support of several members in both the House and Senate, plus many technology lobbying groups regularly relied on by Congress, odds are good it will be law by the end of the next session. If that happens, IoT vendors will have just 180 days to bring their products into compliance if they wish to continue selling the the federal government.
Six months isn’t a lot of time to redevelop, test and productize a device to meet the new requirements. And since the legislation will also require manufacturers to fix or replace devices already deployed, many manufacturers are at risk of losing their install bases to competitors.
Device manufacturers who don’t sell to the federal government should still be concerned. It’s quite common for CIOs in the private sector and their boards to protect their organizations by adopting federal requirements verbatim.
This article will step through each of the technical requirements developers need to meet to be compliant. The good news is, iTivity can speed the development and deployment of most of all of these requirements for both new products and devices already deployed on customer sites.
Moreover, the bill provides federal agency CIOs with the power to exempt devices if they wish. It doesn’t make them exempt from the consequences of a security breach, however, so why would they? iTivity can protect the CIO from many of the threats enumerated by the bill without requiring redevelopment of the device’s actual source code or product build. Thus, by utilizing iTivity, IoT OEMs can give CIOs a good reason to exercise their exemption powers where redeveloping and replacing working devices isn’t feasible.
In that context, let’s look at what’s required and how iTivity can help.
- Vendors must be able to certify that the “hardware, firmware and software” in a device contains no known security vulnerabilities. This simply means devices must patched when security updates are available. Patches and security updates must be applied to vendor applications as well as operating systems and firmware.
The iTivity SCP Patch Management app is designed for patching IoT devices.The iTivity iAgent provides low level access to components like firmware, while its powerful scripting capabilities let technical professionals create update routines that check version information across customer networks and selectively update devices.
- Updates must be authenticated so that unauthorized updates can be automatically detected and rejected. A common tactic among hackers is to update system software with malware that provides a backdoor into the device and its network. Vendors must be able to verify that any updates made are in fact authentic.
iTivity SCP can poll devices for a wide variety of system information. Beyond collecting version information, iTivity can be used to collect software signatures, file sizes and other meta data which can be used to authenticate updates.
- Devices must not have hard coded passwords for either user accounts or admin accounts. In the aftermath of the Mirai attack, it turned out that many of the infected devices allowed users to change the default password for accessing their devices but not the passwords used by manufacturers and vendors for services such as Telnet and SSH. In many cases it was these accounts that were exploited by hackers. The bill requires that admin accounts and the mechanisms that access them be changeable in response to security threats.
iTivity SCP allows manufacturers to mitigate the risk of hard coded passwords without the effort and expense of rewriting source code. With iTivity, remote access services like SSH, Telnet and RDP can be automatically redirected through a secure application tunnel as an outbound connection accessible only from the iTivity platform. In the process, the outbound ports used by these services are closed and the attack surfaces eliminated. Separate accounts can then be created and managed in iTivity for each administrator.
- Devices must use current industry-standard protocols for communications, encryption and interconnection with other devices. For a variety of reasons, some device manufacturers have developed their own communication protocols to facilitate communication between devices and sometimes admins.The problem has less to do with any security exposure for these devices than it does the impact on managing security for the entire network. Any non-standard protocols used to communicate outside can easily be mistaken as rogue communications, possibly to or from a hacker’s command and control system. These communications become distractions, so it’s better to ban them than constantly chase them.
Again, the simple solution is to tunnel these communications “as is” through the iTivity SCP platform. iTivity can easily redirect any communications protocol through an encrypted, secure http tunnel. To security personnel, the traffic can be treated like normal web traffic, so their are no rogue communication streams to chase. The vendor is spared the monumental task of replacing the existing protocol and rewriting both device source code and back-end systems.
- Devices with minimal computing capabilities must comply requirements developed by NIST in the future. As written, the bill requires security compliance for all connected devices, from computers to sensors. For some devices, these security requirements may be overkill. Therefore, the bill instructs the National Institute of Standards and Technology (NIST) to develop appropriate requirements for such devices in the future.NIST has already hinted at the first two requirements. The first is network segmentation. The second is multi-factor authentication.
Fortunately, iTivity SCP provides both.iTivity SCP is essentially a software-defined, segmented network, plus much more. Devices connected to the iTivity platform can be configured to connect only to each other through the platform. Their communications are automatically secured and their traffic is segmented from other traffic on the network. To communicate with these devices, other systems and users would have to authenticate first to iTivity and then to the device.iTivity supports multi-factor authentication out-of-the-box. In the above scenario, users wanting connect to these devices can be required to use a variety of 2FA mechanisms.
Jeff Greene, Senior Director of Global Government Affairs and Policy, Symantec and advisor to the bill said, “The Mirai botnet was a wake-up call, a stark demonstration of the risk created by unsecured IoT devices. It does not have to be this way – IoT devices can be secured.” In all probability, they soon will be. Though the market has been slow to demand secure IoT devices, that is about to change. Some variation of the bill will likely become law, and CIOs in the commercial sector will adopt these requirements. Security will become a new basis for competitive advantage. The only remaining question is what path will vendors take to get there.
Redevelopment is time consuming, expensive, and uncertain. In contrast, iTivity SCP can be adopted and deployed in days. Its pay-as-you-grow subscription model eliminates the long term investment and long-term payback. And the flexible, evolving platform, combined a rich developers tool set means new security capabilities can be added as quickly as new security requirements are written.