Afterword

Discussions at this workshop and among Forum on Cyber Resilience members during its planning and after the workshop make clear that software update is more complicated than it seems at first glance. This Afterword is offered to distill and share some of the insights shared during those discussions. Software update raises different sets of concerns, depending on who needs to address it. In particular, policymakers face different sorts of questions than engineering managers. Below are checklists of concerns that might arise for the two groups, based on points raised during the workshop. Additional detail can be found in the previous chapters.

First is the question of market mechanisms. This topic was not discussed at length during the workshop, but it merits careful consideration. Developers and engineers ought to plan for supporting updates to artifacts they create and respond to software update for building blocks they incorporate, because situations change and customers and/or their data may be put at risk. Questions enterprise purchasers could raise as they negotiate with vendors, especially with regard to Internet of Things (IoT) devices include the following:

• How would I know this device has failed or been compromised? What is the surprising worst that can happen if this device is successfully attacked?
• Can I afford to replace this device every few years?

• If not, what penalties ensure continued support? Is there escrow to a “software orphanage” in case support is abandoned, as discussed in Chapter 4? This device is just one piece of a network of many connected systems; how do I avoid endless finger pointing if it fails?
• Can I buy insurance, and what sorts of failures or breaches would it cover?

The rise of externalities from software that is not readily updateable, such as seems plausible now that IoT devices are surreptitiously used in denial of service attacks, makes software update not just something to leave to the market, but a public policy issue. The security of IoT is a public good.¹ What options are there to disincentivize lax maintenance by vendors, developers, and purchasers that could equitably reduce harm to innocent third parties? Below is a partial list of policy options that could lead to improvements:

• A vendor could clearly state how many years of security support come after the last sale, ensure that there is a viable economic model behind those promises, and ensure the appropriate entity is balancing risks of enabling software update versus not. Vendors could make clear to customers what, if any, updates are mandated.
• Information about installed software could help a purchaser or user have more information for assessing risk (e.g., scanning one’s own systems for instances of vulnerable libraries). Software identification (SWID) tags are one proposed approach for providing such information.
• The privacy implications of the update channel should be considered along with the security implications.
• Recognize what is reasonable to expect of a small start-up company and avoid blanket requirements. For instance, one could set a minimum number of devices or revenue before certain requirements or regulations become applicable.
• A well-managed cloud commonly makes updates easier because such an installation would likely have a large professional security staff, uniform hardware, and software control procedures already in place. The IoT and cyber-physical systems can lack these properties, and thus cannot take advantage of the security benefits that a well-managed cloud environment provides.

In addition to policy and regulatory challenges, there are numerous technical issues that engineering managers and developers need to consider with regard to software

___________________

¹ D. Mulligan and F. Schneider, 2011, Doctrine for cybersecurity, Dædalus, the Journal of the American Academy of Arts and Sciences 140(4).

update. This list is intended to serve only as a starting point for those grappling with how best to implement and deploy software update capabilities.

• Software update is more complicated than it might seem at first. Managing it appropriately during the development process and life cycle of the device or system will take resources, so it will need a budget early.
• Updates should almost always be safe or trust could be destroyed, making user acceptance much harder to obtain. Secure development life cycle, test via tooling, daily builds, and employee use all help to improve safety. However, managing update dissemination is much more difficult if the customer or end user can pick and choose which updates to deploy. Synchronized global update is a best practice that helps keep the vulnerabilities, which are inevitably disclosed by updates, from becoming live exploits used against users who have not yet received the update. Significant bandwidth would be needed in most cases.
• The client update software “agent” that accepts and performs the update needs to be exceptionally robust and metaphorically paranoid. Ideally it would be linked to the boot process so an adversary cannot bypass updates undetected by just writing over disk image. The update agent best practices include the following:
  • Ensure that a power failure or other interruption of the updating process does not brick the device or system.
  • Design with the understanding that there are often only minutes, or even seconds, from initial network connection of a device to the first probing attacks.
  • Design to expect advanced attackers, and do not assume a firewall will provide sufficient protection.
• Consider designing a fail-safe mode for the product—for example, a mode that disables all communications except for update or perhaps is triggered automatically (after a warning period) if the product has not been updated.
• Observe trial users managing the updates, and design the process in ways that would make their lives easier, including the following:
  • Involve the product marketing team in persuading customers to accept updates and ensure that the process to accept updates is straightforward.

• • Consider that bad actors will mimic your update screens to trick users into installing malware; ideally avoid the need to “pop-up” any screen at all, and instead rely on signed automatic updates.
  • Schedule updates to happen at convenient times.
  • Maintain user configuration choices and make intelligent extensions and do what you can to prevent updates from resulting in loss of user data—something that occurs occasionally today and motivates end users to disable automatic updates.
• Be sure that your own systems are getting updates from all your own suppliers, including open source. Avoid suppliers whose devices have proprietary drivers for which only limited or no future support is provided.
• Updates themselves need to be done in a trustworthy manner. The best technical practices at the moment include the following:
  • Test thoroughly but swiftly, accept feedback, and do postmortems after deployment;
  • Provide quick-rollback mechanisms to mitigate the impact of failed updates;
  • Protect against subversion of the update channel;
  • Avoid using “security update” to advance other business interests; and
  • Carefully consider whether to separate security updates from feature updates. Such separation can be helpful to enterprise and other large users who are cautious about system reliability and perceive a need to verify that security updates will not have unexpected impacts; however, some suppliers, notably the Linux kernel, do not distinguish.
• Very large proprietary firmware (such as the Unified Extensible Firmware Interface) is often problematic, even with support, because of the large attack surface unmitigated by compartmentalization.
• Updates (and all boot-time executables) need to be digitally signed.² As demonstrated by Stuxnet and other malware, those signing keys are high-value targets and deserve extraordinary protective measures. It will also be important

___________________

² See the Forum on Cyber Resilience’s recent exploration of cryptographic agility and interoperability challenges in National Academies of Sciences, Engineering, and Medicine, 2017, Cryptographic Agility and Interoperability: Proceedings of a Workshop, The National Academies Press, Washington, D.C., https://doi.org/10.17226/24636.

We offer these thoughts as an additional personal perspective inspired by conversations with workshop participants and Forum members. Our thanks to them for their insightful discussions and comments on this important topic.

Eric Grosse, Member, Forum on Cyber Resilience

Fred B. Schneider, Chair, Forum on Cyber Resilience