CEOs Will be Responsible for IoT Security – Where Do They Start? #NCSAM

Gartner has started to postulate that in a few years’ time, laws could be made and enforced where CEOs are held liable for the (mis)operation of IoT systems that a specific company produces.

This is an interesting statement. Parallels can potentially be drawn to the impact on CEOs and Chief Financial Officers further to the Sarbanes-Oxley Act of 2002 that established financial regulations and auditing of public companies, a part of which requires those company leaders to certify the appropriateness of their financial statements and disclosures.

In the case of IIoT networks, the consequence of a platform’s functionality being compromised can result in the loss of human life. While many people’s brains will immediately leap to the (infamous) self-driving vehicles, the reality is that humans are increasingly in close proximity and sometimes actively collaborating with connected systems deployed in warehouses, factories, hospitals, drones and aircraft.

What the Mirai attack taught us was that it wasn’t simply that connected system that was at risk. I originally dismissed the need for security on a toaster, but Mirai showed that devices like this (okay, in actuality, it was CCTV cameras and DVRs) could be repurposed and turned against other connected platforms across the world.

While the Gartner statement is easy to say, the challenge is that IIoT systems are extremely complex. They consist of multiple subsystems often delivered by a myriad of companies, often at different times. In short, cybersecurity is a team sport. No single throat to choke. What does need to happen is to digitally audit these systems and know that a platform has been updated with the latest patches.

Europe drove recommendations a few years ago which gave countries rights to audit and deliver punitive fines if critical infrastructure was found to be lagging behind on security updates. The UK (okay, yes, not now under the jurisdiction of Europe, but I digress) has created sector security resiliency plans that cover their recommendations for thirteen sectors that include health, water, transport, energy and food. It is good to have specifications and guidelines and for the industry to know that they will be enforced.

The reality though is that industry needs to police itself. Governments will never be able to keep pace with the progress in technology. There are pieces coming together and I believe that the auditing of IIoT needs to be done digitally using technology like distributed ledgers (no one uses the word “Blockchain” anymore). Digital twins that connect to the real world and which can be connected securely into the rest of the IIoT components that, together, form a mission critical connected system has to be the way to go in the long term.

Nearer term, across a number of vertical markets, we are seeing OEMs and cloud companies investing in hardware and low-level software building blocks:

  • Tesla is creating its own hardware chips and many others in the automotive industry are defining down the specific chip requirements to a much greater level of detail than they have done previously
  • As part of the Azure Sphere program, Microsoft is specifying chip blueprints that offer secure connectivity to their cloud. Over time, I expect clouds to delineate the functionality that it offers to connected platforms based on how the cloud evaluates the security (and ultimately how strongly it trusts the data coming from) the device. Potentially a Microsoft Sphere based device will be granted more functions than a different (relatively untrusted) architecture. Ultimately the data ingested from that device will be valued more
  • The DARPA Automatic Implementation of Secure Silicon (AISS) program, involving companies like Synopsys and Arm, is exciting as it may hope to bring down the walls of certain silos and create true standards that work to further the realization of more secure connected platforms as opposed to furthering the business objectives of one specific company

In Lynx’s area of focus, companies are collapsing down functionality that previously executed on multiple systems and processors onto a single multicore processor. There are great footprint, power and cost reasons to do this. This approach does cause additional headaches for system architects as it is potentially easier for a rogue process to cause issues to a significantly wider set of functionality than was previously the case.

When Microsoft announced Azure Sphere, one of the speakers gave the analogy of someone leaving their house and locking the front door. What he argued, was that with IoT, the person needed to lock all the rooms of the house prior to exiting, so if someone broke in, they would be contained in one area. Of course, a sensor would be triggered to alert someone that the room had been entered.

What’s truly worrying is the average time to identify a breach (energy market is “winning” with 150 days) and how long it takes the industry to respond with a patch (53 days at the lower end).

In a nutshell, the locking of all the rooms in the house and providing the sensors in each of the rooms is what LynxSecure offers as a foundational secure hypervisor in these types of platforms. We don’t solve every security problem and so we are building out an ecosystem of partners that can deliver advanced analytics, advanced software delivery mechanisms for patches etc.

Finally, if I repurpose a familiar phrase, “Deploy in haste, repent at leisure”. Don’t deploy systems to meet a deadline, ensure they are robust from a security point of view first, before they are issued. The government is not fining CEOs yet, but there are significantly bigger issues at stake for taking the wrong path.

What’s Hot on Infosecurity Magazine?