Posted by Dan Lyon on March 1, 2016
Product security is an increasing concern as the Internet of Things (IoT) emerges from what have traditionally been isolated systems. Recent breaches into commercial HVAC systems, thermostats, and even children’s toys have brought about the recognized need to ensure that hackers can’t access sensitive information from these devices.
Everyone says that to do security properly, you need to build it in. But, what does that mean exactly? What can manufacturers change and improve to make sure that they are building systems securely with a continuously advancing threat? We must also consider IoT embedded systems that could, when breached, be potentially life threatening. Let’s look at the auto industry as an example of how companies need to evolve and adapt to stay ahead of continuously advancing security threats.
The first aspect is to understand and acknowledge that today’s world is a hostile environment. For a variety of motivations, people are looking at connected products and seeing what they can and cannot do—not just what the manufacturers intend for them to do. Through acceptance of this fundamental change in use cases comes an understanding of the problem. To understand what ‘building security in’ means, let’s look at something that car manufacturers are well-versed in already: safety risk management.
Cars have been improving on safety for decades. Cars are safer now than at any time in the past, as evidenced by the increasing test standards. Because manufacturers have had years to work through the increasing standards, they are experts at identifying ‘what if’ scenarios for when things go wrong, and then designing systems that somehow mitigate those bad scenarios.
To build security in, manufacturers need to take the same risk-based approach to security issues. By establishing a security risk management process that is parallel to their safety risk management processes, manufacturers can effectively build security in at every stage in their development life cycle. Those same safety gates that require analysis of all the ‘what ifs’ can be mirrored to apply analysis around ‘what if someone hacks your car’? Once the questions have been asked, the analysis process can begin which will yield understanding followed by solutions.
The key here is to drive understanding through risk identification. Because security is a different subject domain, different expertise is required to ensure risks are identified. However, manufacturers that build safety-critical products already do this for all sorts of other domains—electrical, chemical, and mechanical are all good examples where you need specific expertise to understand failure modes. Security is no different and ensuring security risks have been identified requires security engineers be involved. A thorough understanding of attackers, motivations, techniques, and tools is required when driving a risk-based approach to security.
With a risk-based approach, manufacturers can replicate processes already in place to drive understanding and appropriate action. The Nissan Leaf is a great example to learn from, because it had no safety impact and was quickly mitigated by Nissan.
But what happens if next time it is a safety critical component that isn’t easily mitigated in the field?
Get the latest AppSec news and trends sent directly to you.