Tech & Sourcing @ Morgan Lewis


The Business Software Alliance (BSA) recently endorsed principles for building trust in the Internet of Things (IoT), highlighting the need for a risk-based approach that (1) accounts for the various components, capabilities, users, environments, life cycles, and complexities of the IoT ecosystem, and (2) engages the corresponding stakeholders. Given the near boundless opportunities—and risks—deriving from its connectivity, a connected device should not be designed and managed in isolation.

The following key themes emerged throughout the BSA policy principles:

  • A one-size-fits-all approach would be inadequate, at best. Although treating all connected devices the same might seem simple and fair, fundamental characteristics of devices and systems (and their users, use cases, and risks) vastly differ. For example, some environments (often in consumer settings) are essentially unmanaged, have low user sophistication, and incorporate many obsolete devices. But, partly due to lower levels of integration, the consequences of a security failure in those environments may be relatively minor. Some other environments (often in enterprise or industrial settings), where a security failure may be ruinous, are carefully managed, highly complex, and have sophisticated users and network defenses. In fact, device-centric security policies could undermine transformative network-based solutions, such as (1) cloud environments where customized security rules can mitigate vulnerabilities without updating the device itself (e.g., virtual patches), or (2) protocols for communicating critical device information to routers to aid anomaly detection (e.g., manufacturer usage descriptions).
  • Policies and strategies should address the entire life cycle. Just as security risks, capabilities, and priorities differ across environments and as device-focused measures miss the bigger picture, security must be tailored to, and integrated throughout, every stage of the life cycle. Although manufacturers, distributors, and other relevant stakeholders may have strong incentives and reasonably adequate (though varying) controls to protect devices and systems during the development, manufacturing, integration, deployment, and usage stages, the evolution of IoT, as we previously discussed, may depend on whether such stakeholders also comprehensively tackle the late-life and end-of-life stages. Security flaws during these late stages are an externality that, like pollution, may require extensive voluntary and not-so-voluntary intervention.
  • Engage all relevant stakeholders. A multi-stakeholder process that is “open, transparent, and consensus-based” should be employed. Many interested parties, including governmental authorities, industry groups, standards-setting organizations, platform integrators, and privacy/security experts, should be in the room where it happens, collaborating to understand evolving threats and to develop policies and best practices. But stakeholder involvement should not stop at high-level policy discussions. Development, procurement, sales, and support teams, for example, should be well versed in the nature and mitigation of these risks. Procurement professionals may develop diligence procedures and contractual provisions that become standard practice, like supplier diversity programs. And, though admittedly a daunting challenge, devices, systems, and protocols could be designed to make updating, reporting, and decommissioning procedures easy. When combined with compelling consumer education (think, e.g., recycling), millions of users could become part of the solution rather than cracks in the levee.
  • Be prepared. As with any privacy or security policies, there is no magic bullet and incentives may not perfectly align. So incident response planning and testing should account for the reasonable likelihood that vulnerabilities in these systems will eventually be exploited. And remember that cybersecurity is only one piece of the protective framework—privacy practices that appropriately reflect the sensitivity and purposes of collected data can limit risk and inform procedures.

To bring these principles to life, some of the practical considerations we explored in the autonomous vehicle context (like vertical integration, partner diligence, private networks, industry standards, and reporting requirements) are instructive. But also just as (if not more) true in the more general IoT context, the demand (from customers, collaborators, and investors alike) for open, rapidly growing systems of connected devices will only accelerate.

No device is an island—it is a piece of the network, a part of our ecosystem. If a cog is neglected, the clouds dissipate (or storm), as if the data center or brand leader had met the same fate.