See what else is new...
No items found.
Late last year we saw a wave of distributed denial-of-service (DDoS) attacks on Internet infrastructure, targeting major services such as Twitter, Amazon, Spotify and Netflix. Detailed accounts of the “botnet” used to propagate these attacks can be found at major technology publications such as ArsTechnica, Krebs on Security, and from Bruce Schneier. Until recently, attackers targeted traditional computing infrastructure—consumer PCs and enterprise servers—as hosts for malware.
However, for those who develop connected digital products, it is notable that recent attacks have begun to target other types of Internet-connected devices: the “things” that make up the Internet of Things, such as connected security cameras. In doing so, the attackers have gained two advantages. First, the number of IoT devices is on pace to exceed the number of traditional computers, smartphones, and tablets within the next few years, providing an exponentially expanding attack surface. And second, these smaller devices have, to date, been designed with insufficient attention to security—they are vulnerable and difficult to fix, and so will likely remain vulnerable until the end of their functional lifespan unless they are manually decommissioned.
It is important that digital security and privacy be taken seriously throughout the process of product development from a systems engineering perspective.
The subject of security can be broken down in many ways, and the following is one guide to thinking about security and privacy during the product development process. Because today’s devices are increasingly being connected to the Internet, it is important to work with stakeholders to make sure that proper security measures are in place throughout the entire IoT system architecture, including mobile phone applications, gateways and Internet hubs, and the back-end cloud services platform.
Increasingly, today’s Internet-connected devices provide value to their users through personalization of their user experiences. As such, they need to store the user’s information, such as personally identifying details, financial information like credit card numbers, network credentials, or medically-sensitive data. Developers must take care to protect this data from unwarranted access. In addition, the embedded software (“firmware”) that powers the device may implement the manufacturer’s intellectual property or trade secrets, where access to it may be a significant business risk. Finally, protection of this sensitive data often requires storage of private cryptographic keys on a device, which in turn must be defended against exposure.
In early design phases of a product, one must consider how to protect a device from both physical tampering and from digital access to stored resources. We also work with clients to make sure that data will be protected after it has left a device and is stored in the cloud.
Sensitive data must also be protected while in transit. Recent years have seen a great amount of progress in development of secure device-to-Internet communications protocols, at different levels of a device’s network stack (SSL, DTLS, MQTT, CoAP, ZigBee, Thread, BLE, etc.). It is important to stay current in recent advancements in this space, and use that experience to inform the decision of the proper communications protocol to use. We discuss the need for field upgradability below, and any custom communications protocols must be designed to be upgradeable if they need to be adapted to new security threats.
One must also understand the tradeoffs in different approaches to establishment and maintenance of cryptographic keys for secure communications. Different situations may call for fixed private keys in lieu of forward secrecy (unique keys per-session), and may or may not require the use of negotiated key exchange algorithms (such as ECDH).
Lastly, be sure to consider the transport of data on internal communications busses, so that they can be protected from physical tampering and snooping of a device’s circuitry.
The protection of a user’s sensitive data as described above is a main consideration in maintaining their privacy, but designers should also consider whether a device’s communications with the outside world can compromise privacy in other ways. Primarily, it’s important to think about whether a device might allow a user to be identified and profiled over time, for example by tracking the radio address used in communications, and to work with stakeholders to understand the implications for their users. For example, a system architect might choose to implement Random Private Resolvable addressing for a Bluetooth Low Energy peripheral device, but should understand that this mandates a bonding process for any phones that wish to interact with it—a considerable impact on the user experience.
Security must be thought of as an ongoing process, and connected devices must be able to adapt to new attack vectors even after they are deployed; they must be designed with a mechanism for updating their firmware in the field.
Such a firmware update mechanism is comprised of a secure boot loader (the code that is run immediately upon power-up and is responsible for installing new “main” firmware when needed), and a secure over-the-air update mechanism. Engineers should understand industry-accepted best practices for encrypting and authenticating firmware images so that their intellectual property cannot be intercepted during transit, and malicious firmware images cannot be installed. They should also work with microcontroller and processor vendors to implement secure chains-of-trust that start with securely stored keys to validate trust beginning with the boot process.
Finally, consider proactive measures to design a system architecture that provides security in layers. One example is the design of an internal firewall, such that if one area of the system is compromised it does not necessarily allow access to the entire system; the system resources allocated to a task are protected from access by other tasks. Another example is the inclusion of background tasks that monitor system behavior and attempt to detect and report intrusions.
The design of digital security includes the manufacturing process and the associated supply chain, and part of introducing a product into the market is designing and deploying IT systems that protect digital assets (including cryptographic keys) in the factory, before being installed on a device. Many processor vendors support secure provisioning of encryption keys on the manufacturing line, such that the authentication of a chain of trust starting with the initial boot-up sequence can be established without the need to have those keys ever exposed in plaintext. At a minimum, working with contract manufacturers to secure server rooms and protect digital assets via firewalling is essential.
In Synapse’s experience in addressing the above concerns when developing digital products, we have found that the following principles generally hold true:
Digital security and privacy live on a spectrum, from complete openness to extremely powerful cryptographic protection of all concerns. Increased security will generally come with downsides, including:
Especially in early phases of product development, designers should work to understand these trade-offs, and work with their stakeholders from initial requirements analysis through the product development process to understand the near- and long-term implications of how these decisions will impact their product and their brand.
While a system designer should never assume that a tested software or hardware package is 100% secure, they should know that custom or recently-developed security components are much more likely to have security bugs. To the greatest extent possible, use well-tested off-the-shelf hardware and software in building a product.
Developers should have strong in-house quality assurance capabilities and a solid understanding of how to test for security, but we also think that one should try to rely on outside experts for security audit (white-box testing) and system (black-box) test whenever it is feasible. Depending on circumstances, this is generally a more effective way of establishing and maintaining product security.
We are optimistic that governmental regulatory bodies, independent testing and certification laboratories, and product companies can move forward from recent incidents to address the security issues of the IoT in a practical but effective way. For example, it is our expectation that governments will find ways to hold product companies accountable for the security of connected devices through requirements to disclose security incidents and known vulnerabilities to their shareholders, as has been mandated by the U.S. Securities and Exchange Commission since 2011. This in turn will incentivize product companies to address security through better engineering, and through cyber insurance—and the need for insurance will give rise to standards of testing and certification.
As product designers, we believe the days of “security through obscurity” for connected consumer products are decidedly over. Product designers can no longer ignore the risk that a potential security compromise poses to their brands. The good news is that recent incidents have raised awareness of the issue across the market, which levels the playing field for all manufacturers—and “design for security” can be achieved with minimal downsides if considered early in the process.
No items found.
No items found.