Security is every developer’s business, but not for the reasons you may think
Things working together are bringing us the next tsunami of innovation. For example, if I have a connected car and the dynamics of the road or cityscape change around me because of a burst water main, that will automatically impact the car’s suggested route. The car being smart on its own doesn’t help much. It is understanding the context of how these systems are going to work together which will really drive innovation.
However, there’s a downside to this tsunami of IoT connected devices, which, as Re-searchAndMarkets notes, will hit 25.1 billion in 2025, compared to 2017’s 7.5 billion. There are the threats, which come in many forms, and the ability to accidentally or purposely poison data, to re-route cars, or to impact organizations’ performance. There have been ransomware examples with PCs, and this is expected to continue within the IoT; a recent OT system example is the cyberattack on the Norsk Hydro aluminum plant, estimated to cost them more than 50 million dollars.
The cloning and counterfeiting of OECD numbers is already a 500-billion-dollar-a-year industry with a high proportion of that in electronics and electronic equipment—which amounts to the GDP of Ireland and the Netherlands combined.
And these threats will take place at a time when the rise of edge computing is broadening the attack surface. Edge computing allows engineers to complete analysis and other tasks outside the cloud, but it also expands vulnerability, giving hackers more ways to get into a system. Every edge computing point is a system in its own right and must be protected.
And then there are the events that remind us that in this connected world, you want to talk to your specific device instead of all your devices. Philips had an identity issue to resolve when re-searchers found that the company’s Hue light bulbs were alarmingly hack-able. Because all the Hue light bulbs used the same key, once a hacker had broken one key, he had broken them all. Philips acted, and now every Hue light bulb has its own unique identity.
The Differentiation Engine Hiding in Plain Sight
Yet for all the awareness of issues like those just cited, and despite the spotlight often being on security, its role is not fully understood, and especially its function as the bedrock upon which in-novation in the IoT era depends.
To understand security in this era is to understand that security is the strongest differentiation en-gine at your enterprise. This engine is hiding in plain sight, mistakenly seen as a “cost.”
Consider just some of the reasons to move security to the value column on the spreadsheet ra-ther than the cost category:
• Security protects IP. The first value of security is not in stopping something from getting hacked; it’s in protecting the investment put into your software design and engineering. Increasingly, IP software is in the shape of a car, a washing machine, etc., gaining more and more value whereas the value of the actual hardware is decreasing. IP aggregates a lot a company’s knowhow and contains typically several man years of development efforts. The last thing you want to see is this IP stolen, put on GitHub or ending up on the black market.
• Security is a bedrock enabler for next generation services. One of the most important best practices covered in the IoTSF recommendations is the capability to update the software of an IoT de-vice. This update capability goes beyond adding greatly to the security and life of the device; it also enables the service provider to add new services over the product’s lifespan. As tech-nology moves quickly, services that were unthinkable during initial development can simply be added later. New security services have the potential to generate revenue over the entire life cycle of a product. For example, smart city lighting may initially start out as the simple selling of bulbs. This may be the initial design criteria for the smart bulbs. However, later the provider may change the landscape and add a new service to sell you lighting as a service. The value point changes quite substantially from simply the cost of bulbs and the in-house resource to fit and maintain them, to an annual fee where the bulbs and in-house resources are no longer consid-ered.
• Security leverages your application’s capabilities. For example, taking the security step of as-signing connected devices a unique identity upfront makes it possible to tailor applications to leverage the identity properly. That’s becoming easier and less time-consuming to do with the arrival of new tools on the market. For example, it’s now possible to leverage a security devel-opment environment which can capitalize on the secure hardware that the latest microcontrol-lers have. The elements of this security development environment include integrated identity and certificate management; scalable secure boot management; secure deployment with in-tegrated manufacturing mastering; and release management with versioning and update in-frastructure.
• Security fosters ongoing customer relationships. It’s the rails upon which continued communica-tion with your customers runs. There’s also a more generous amount of time over which cus-tomer relationships can develop than in the past. Traditionally, 10-, 15-, 20-year life cycles have been found only in military or aerospace domains. Now however, sectors leveraging the IoT, smart cities, and smart homes are also demanding these longer life cycles from embedded sys-tems. Throughout those cycles security will be paramount. And security will be your opportunity to differentiate in how your devices, for example, securely and seamlessly onboard to Azure, to AWS, to Google Cloud, etc.
Beginning the Security Journey
Security is a journey. It won’t be an instant leap from “Security is not core to the application; I will try to fit that in at the end of the project, or perhaps in version 2 or 3 or 4,” to the understanding that leveraging security effectively means bringing security to bear at the start of the design process.
One of the current challenges to this journey is the dauntingly greater number of cybersecurity job postings than individuals available to fill them. Frost & Sullivan expects 1.5 million cybersecurity job postings by 2020. But these statistics also serve to point out that in everything we do, whether it is Information Technology, Operating Technology or IoT, security has become central.
On the positive side, embedded systems OEMs today are in a better position than ever to begin this journey. For one, the other two parties present at the design inception—the chip vendors and the tools vendors—have continued to strengthen their security solutions. Mainstream widely available chips can be leveraged. For example, Arm’s TrustZone-M makes it possible to create a virtual secondary processor to handle some of the security domain.
On the tools front, it’s important to use a set of tools which can scale as migration between ar-chitectures takes place. Also helpful is working with a tools vendor who can support different platforms and support mainstream devices as well as newer, security-orientated chipsets. Con-sider a vendor who can offer tools specifically designed to help in following all 13 of the IoT Se-curity Foundation (IoTSF) best practices for the gateways, actuators, and sensors used for con-sumer IoT devices.
The tools and the availability of security as a service are there to make bringing security to the front of the development cycle a reality and to help even where clean sheet design is not possi-ble. One example, the IAR Embedded Workbench ®, is a toolchain with a complete IDE, includ-ing Embedded Trust from Secure Thingz.
To get started, begin with basic design hygiene, which alone probably inhibits 90 to 95 percent of the attacks that we see today. One hygiene measure is instead of having fixed passwords, move to a standard identification platform which utilizes a Public Key Infrastructure (PKI).
PKI has been around for a long time in the IT domain, but not been brought to bear in the em-bedded domain. But it is a best practice. We know it works. We know the cryptography works. What is needed is to ensure developers can leverage PKI to create a set of proper identities with a proper certificate authority, so it is known and trustworthy. The use of PKI would enable the creation of intermediate certificates, which may be OEM-specific certificates, and then device certificates, which means that every single device is uniquely identifiable and uniquely addressable.
Design hygiene measures also include:
i) switching off debug; making sure that when the device is booting up it is set into a secure space before the bad guy can start coming in and rooting around inside the code base; ensuring that identity can be fused into those devices in an immutable way.
ii) memory protection; making sure that the user application is isolated from the immu-table bootloader memory and that the bad guys cannot inject any malware that could tamper with the bootloader code.
iii) software update; making sure there is a mechanism to securely update the user ap-plication in order to quickly fix any vulnerabilities that are discovered and ensure se-curity over the life of the product.
Of course, the bad guys will then step up the network attacks moving forward. Nevertheless, if we can take out the random attacks, then it is a pretty easy win for the industry. It also shows to legislative organizations, to governments, to whomever that the OEMs are taking security serious-ly and at least putting in the minimal hygiene.
On the Legislative Front
Even though noted above that security’s role is not yet fully understood, progress is being made within industry and within governments. One of the first legislative efforts will be the state law that goes into effect this January in California. It will require that when something goes wrong with a connected/IoT device there is an absolute requirement to be able to fix, patch, and recover it if hacked. Legislation such as this indicates that the industry needs to move in the direction of hav-ing a standard solution as opposed to something which is unique for every device, which means custom updating for every light bulb, every car, every refrigerator.
While this cybersecurity legislation may be first out of the gate, expect more to follow. Industry groups, such as the IoTSF, and governmental agencies in Europe, the UK, the U.S., and Asia have begun building legislative frameworks based on best practices for cybersecurity in consumer, medical, and other sectors. The frameworks will support legal requirements to ship devices which are secure. And these laws will also speak to the manufacturers’ obligation to ensure that when things go wrong—and they will, because developers have to be right 100 percent of the time while hackers only need to get lucky once—that devices and networks can be remediated and that people and businesses can be protected over the long term.
Conclusion and Recommendations
The complexity of software that we have on PCs, servers, and the cloud means it is difficult to protect it, and that is why we typically see so many compromises and the need for running very deep layers of anti-virus software and anti-malware. But difficult is not impossible, and as an in-dustry we can do better than less than four percent of new devices having embedded security. Broader proliferation and adoption of IoT devices can take place as security is designed in from inception.
As an industry we have to back legislation; we also have to drive it at the global level. In the U.S., in the EU, by setting the market rules for what can be sold, we are going to improve design hygiene and take out the easy targets.
Secure Thingz, together with IAR Systems, is helping to assure that the devices talking to one an-other are inherently trustworthy. Yes, there still has to be an on-boarding process; they still need to get used to each other, but fundamentally if you use our tools those things will be inherently more secure and more trustworthy. Ultimately it will mean that it is harder and harder for the bad guys to find a way into the system.
As the mathematician George Polya advised in his First Principle, “Understand the problem.” Be-coming aware of the best security practices out there, via the plentiful free advice at iotsecuri-tyfoundation.org and other sites is a step in the right direction.