Download PDF Fall Issue of The Bridge on Cybersecurity September 19, 2019 Volume 49 Issue 3 This issue features selected papers intended to provide a basis for understanding the evolving nature of cyber-security threats, for learning from past incidents and best practices, and for anticipating the engineering challenges in an increasingly connected world. Policy Dimensions of Cybersecurity Engineering Challenges Thursday, September 19, 2019 Author: Fred B. Schneider and Lynette I. Millett Computing systems are increasingly subject to attack in support of criminal activities as well as nation-state espionage, sabotage, and now information-influence campaigns. New technical developments are providing ingredients for better defenses, but there is still much work to be done. However, a focus only on the technical aspects of cybersecurity will produce solutions that are unlikely to be effective in practice. Organizational, social, economic, and policy issues must be considered in concert with any technical developments. Case studies are one way to understand the critical role of nontechnical issues in what, at first, appear to be technical matters. Three are discussed in this paper: quantum-resistant encryption (NASEM 2017), managing data breaches (NASEM 2016), and microarchitectural vulnerabilities in processors (NASEM 2019a). Each was the subject of a workshop organized by the National Academies’ Forum on Cyber Resilience (www.cyber-forum.org). A Goal: Trustworthy Systems For a system to be considered trustworthy, stakeholders require a basis to believe that a system will do what is expected and not do the unexpected. Cybersecurity is the dimension of trustworthiness concerned with resisting attacks. Expected and unexpected behaviors here are often characterized broadly in terms of three classes of properties: Confidentiality. Which principals are allowed to learn what information or, equivalently, what must be kept secret? Integrity. What changes to information and uses of resources are allowed? Availability. When must inputs be read and outputs produced? Whether a system satisfies these properties depends on the soundness of assumptions made by designers, developers, and users. Moreover, by making additional assumptions about the deployment environment, it generally becomes easier to build a system, although assumptions can have cybersecurity consequences. For example, if a component behaves as expected only while an assumption holds, then an attacker can cause disruption by falsifying the assumption. Other cybersecurity consequences of assumptions are more subtle. For instance, to express expectations about system behaviors in terms of operations and interfaces (as is common) is to make an implicit assumption that an attacker’s actions are limited to certain restricted modes of access for controlling the system or for learning its state. In summary, assumptions create room for vulnerabilities. The design of a secure system can be viewed as an exercise in identifying assumptions and assessing -whether they reflect reality and whether they can be violated by motivated adversaries with certain capabilities. Security mechanisms can create environments where stronger assumptions hold (e.g., because a -broader range of behaviors are precluded or handled appropriately) and, therefore, some component runs in a more benign setting than it would have absent those mechanisms. The improved environment -created by such security mechanisms does come at some cost, though—the mechanisms themselves need to be secure and additional assumptions might have to hold to ensure their correct operation. With this approach, design choices can be justified, as befitting an engineering discipline. As in other fields of engineering, design will be an iterative process, deemed finished only when the remaining assumptions are (believed) difficult or unlikely to be violated. Quantum-Proof Encryption and Cryptoagility Nearly all computing systems in use today rely on crypto-systems to protect confidentiality and integrity of information, whether that information is “at rest” (i.e., in some form of storage) or “in motion” (i.e., in transit on a network). A few public key cryptosystems are prevalent, and the security they provide depends on an assumption that specific mathematical computations, such as factoring or computing discrete logarithms on sufficiently large numbers, are computationally infeasible given the processing power that may be available to an adversary. Based on current mathematical understanding, this is a safe assumption for digital computers that can be built today and are expected in the future. Even though digital computers are likely to get ever more powerful, they will not have the capacity to factor the large numbers used in public key cryptosystems. The Threat of Quantum Computers A sufficiently large general-purpose quantum computer, if it could be built, would invalidate assumptions about the difficulty of performing the mathematical operations that underpin today’s widely used public key algorithms. For example, if a powerful quantum computer could be built (NASEM 2019b), any actor could use it to execute Shor’s algorithm (Shor 1994) to factor large integers. This would be detrimental to both network communications and the protection of long-term data encrypted and stored using algorithms that depend on the difficulty of factoring large integers. The possibility of breakthroughs in quantum computing is thus cause for concern. Cryptography researchers are developing new public key algorithms that are resistant to cryptoanalysis by adversaries using any combination of classical or quantum computers. The good news is that it appears that such encryption algorithms can be built and with acceptable performance on modern computers. The bad news is that simply having quantum-resistant encryption algorithms available is not enough. Installed software must use them, requiring upgrades to an enormous amount of software. And those upgrades will not be straight-forward. For one thing, cryptographic keys and encrypted messages will undoubtedly be different sizes with these new cryptosystems, potentially requiring changes to any software that stores keys or manipulates encrypted messages. Protocols to set up encrypted connections or do other provisioning also have to be upgraded. In short, transitioning the internet ecosystem to -quantum-resistant cryptosystems will not simply be a matter of replacing the few routines that perform encryption and decryption; the upgrade likely will require making and distributing changes to all software that uses these routines, too. Most software systems now in use were designed to allow upgrades after deployment. But few were designed to readily support cryptoagility, wherein encryption and decryption routines (and perhaps a small amount of other code) are all that must be updated to replace a cryptosystem. Previous Cryptosystem Challenges History offers insight into the costs and challenges of replacing a cryptosystem widely used by the internet ecosystem. The TLS (Transport Layer Security) proto-col was standardized in 1999 (and version 1.3 was recently finalized) as a revision of the early SSL (Secure Sockets Layer) protocol; TLS encrypts all types of internet traffic. Yet there are still systems in place that support SSL 2.0. So, even after two decades, some systems have not been fully transitioned. The general consensus among experts is that it takes about a decade to substantially roll out a new cryptosuite and retire the old one. The experience with TLS suggests that, if usable quantum computers may be achieved within a decade, now is the time to start upgrading to quantum--resistant cryptosystems. The most sensible course would be to upgrade systems to improve cryptoagility, because even if quantum computers never become available, cryptosystems might need to be changed to defend against attacks developed based on new insights in the underlying mathematics or on bugs in the software implementation. National Security Concerns Efforts to update the protocols and software under-pinning the internet ecosystem bring many technical and operational challenges to software producers and their customers. And if the upgrades are connected to a competitive or national security advantage, then important nontechnical factors come into play, too. Global platform companies—even those based in the United States—respond to the needs and requirements of their customers around the world. Some of these customers may be governments, which may not want to use the same cryptographic tools as others. Other customers may be subject to foreign government regulations aimed at either improving security (e.g., by prohibiting risky practices) or undermining it (e.g., by mandating backdoors or other sorts of access). In the interests of its national security, a country may wish to regulate surveillance-resistant cryptosystems or insist on its own locally created cryptosuites—for example, to facilitate law enforcement access to encrypted content or to enable government surveillance of network communications. A platform provider could be caught in one of the following binds if the cryptosystem it uses to protect its software upgrades is not compliant with a nationally mandated cryptosuite: For consistency, scale, and to avoid having to trust a customer’s government, a company would want to distribute software upgrades using its own -cryptography and keep those keys secret. The company would find it unacceptable to use a cryptosystem it did not trust or to provide a government with keys used by its -customers’ systems, because that would risk losing control of both the integrity of its installed systems and the confidentiality of its intellectual property. A software upgrade capability would have to be able to change locally installed cryptosuites. Governments, fearing supply chain attacks, would find that unacceptable, since a (potentially foreign) company would then have control over what cryptography the platform uses and would have the capability to either install backdoors for exfiltrating content or remove government-provided backdoors. There are thus at least two parties—a company and a government—neither comfortable with the other having needed control. Yet one of them must have that control. In addition, end users and companies that provide networking capabilities may have interests that conflict with each other, with software companies, and/or with governments. A technical solution might satisfy all these constraints, but none is currently known. Most likely, addressing these and other policy and international complications will require not just new forms of cryptoagility but also new thinking about what entities should have jurisdiction over encryption policies and what should be the goals of those policies. New policies and norms formulated by international standards -bodies as well as other regulatory and political entities are likely to be part of a solution. Managing Data Breaches Two Approaches: Prevention, Recovery Prevention, which takes the conservative stance of prohibiting actions that could violate some security policy, is one approach to managing the risk of cyberattacks. With the other, recovery, the risk is made tolerable by having the means to mitigate the effects of an attack. Recovery typically involves both technical mechanisms to detect attacks and to return a computing system to a preattack state, and nontechnical means to reverse effects of the attack on the system’s environment. Prevention receives the lion’s share of attention in the cybersecurity research community, but the inevitable failure of any defense implies that even prevention-based defenses benefit from implementations of recovery measures.[1] Data breaches and identity theft commonly inspire discussions about recovery, with incident reports like the following now a regular front page feature: In early 2019, Marriott International revealed that several million of its customers’ unencrypted passport numbers were stolen in a data breach that exposed personal information of nearly 500 million indi-viduals (Gressin 2018). Breaches of credit card information at major retailers are now so common that the process for issuing new cards has become routine, often completed even before a consumer is aware of a compromise. In these examples, recovery would superficially appear to be straightforward to implement. Marriott said that it will cover the cost of new passports when fraud can be shown. Banks incorporate the cost of frequent card replacement into their business model. However, passport replacement does not remedy the harm if the theft was undertaken to track movements of certain passport holders. And there remain unaddressed costs to consumers for credit card disclosures, given the time it takes to correct and update accounts. The Need for Other Approaches Identity theft sometimes goes well beyond the disclosure of a single identifying number, and with not just financial but all manner of other harms to individuals and institutions, as illustrated in the following examples: The breach of sensitive security clearance information at the Office of Personnel Management (OPM) in 2015[2] caused harm to national security, not least in that it revealed the names and personal networks of individuals with clearance to the attacker. Exposure of user identities and profiles in the Ashley Madison data breach in 2015 (Krebs 2015) caused people to suffer humiliation and reputational harm (but not identity theft). An Equifax data breach in 2017 revealed the social security numbers and birthdates of nearly 150 million users of the credit bureau, undermining confidence in the company itself and in the entire credit management infrastructure.[3] A national database in Singapore containing the names and addresses of more than 14,000 people who had tested positive for HIV was breached in early 2019 and the data were made public (Ives 2019). In each example, approaches such as replacing credit cards, freezing credit accounts, or even remedying significant identity theft are not sufficient to resolve the harms caused. The OPM example is especially problematic because security clearance applications hold vast amounts of personal and sensitive details, including information about family and social networks. People who provided this information were assured that the government would keep it confidential. Some individual or entity now has a vast trove of information on people in positions of trust with the US government. To remedy that national security harm in any meaningful way may not be possible. The straightforward, and now reflexive, responses after a data breach—replacing identifier numbers, harden-ing systems, freezing certain credit accounts, notifying users—are based on an assumption about possible harms. But as should now be clear, that assumption is unsound: The toolbox of easy responses is insufficient to cope with the scale, scope, nature, and duration of potential harms from many major data breaches. Furthermore, new kinds of data manipulation and information distortion are now being deployed on social platforms, the effects of which may often be individually intangible but globally intractable and socially toxic. The credibility and/or targeting of these postings is enhanced by attacker access to information gleaned from data breaches—data stolen in one breach may be used in another. Policy, legal, and regulatory approaches are needed to address the myriad ways in which data breaches can cause harm well beyond an individual’s credit rating. Vulnerabilities in Computer Architectures The recent discovery of the security vulnerability Spectre (Kocher et al. 2018) and others (Canella et al. 2018) showed that software engineers and compiler designers have, for the past two decades, been making unsound assumptions about what computers do—and don’t do—when executing programs. Spectre exploits speculative execution, a micro-architectural processor performance optimization through which instructions are executed for -predicted execution paths before it is known with -certainty -whether the corresponding instructions will be -executed. The speculation allows processors to accomplish useful work rather than idling, and this allows for -parallel work. Results that are not needed because the program follows a path other than the predicted one are simply discarded. Unfortunately, instructions that are erroneously executed during speculative execution exhibit side effects by affecting resource availability or changing the state of the processor’s cache. Spectre and a related vulnerability named Meltdown (Lipp et al. 2018), both discovered in 2017 and revealed publicly in early 2018, exploit these side effects to deduce private memory contents. Since then, numerous other attacks have been described that take advantage of differences between the architectural properties that programmers assume, the architectural specifications, and the actual micro-architectures of modern processors. Although some limited mitigations have been deployed, satisfactory comprehensive technical solutions for these kinds of vulnerabilities do not exist; research is ongoing. Moreover, there is some urgency in finding mitigations, because speculative execution is an important performance feature of all modern processors, and solutions are likely to require hardware changes that take a long time to deploy. Nearly all modern computing systems are vulnerable to these kinds of hardware-focused attacks, although software bugs are widespread and often easier to exploit, so for the time being, easier-to-exploit avenues for attack are plentiful. Policy and Practical Challenges Independent of technical mitigations for existing processors, vulnerability and the orchestration of any associated upgrades pose some formidable policy dilemmas. Disclosure of a vulnerability is itself a vexing issue. Who should be notified during the initial -embargo -(confidentiality) period, and, more -controversially, who should not be informed? The -processor -manufacturer? Users? Wholesale customers of the manu-facturer? Operating system vendors? Software developers? Cloud computing vendors whose products depend on effective isolation? Disclosing to everyone who may have a reasonable need to know can be -dangerous because notifying too many people during an -embargo period can result in attackers finding out about a vulnerability while defenders are in the dark. Who is responsible for the repairs? For vulnerabilities discovered by those working on offense (e.g., intelligence agencies and companies that supply them with zero-day exploits[4]), the “embargo” objectives are inverted. The goal is to maximize the power of the exploit, which includes keeping the bug from being patched. Because military and government computers use modern processors, vulnerabilities constitute -national security risks from a defense perspective as well as opportunities to attack vulnerable systems used by rivals. When should governments be notified? Which governments? There are additional -policy challenges when vendors are expected or required to inform a government about vulnerabilities. A recent workshop on this topic (NASEM 2019a) covered the technical dimensions and explored how researchers, manufacturers, and vendors managed the disclosure for Spectre. The workshop included discussion of the challenge of creating effective vulnerability disclosure processes, especially for vulnerabilities whose mitigations affect multiple layers of the computing stack (e.g., hardware, operating system software, applications, and cloud service implementations) and could therefore require assistance from stakeholders ranging from small software companies to multinational corporations to national governments. Spectre and its ilk result from the success of computer engineering itself—processor innovations driven by performance needs have quietly and inadvertently undermined basic software engineering assumptions about how data are handled. Those now incorrect assumptions can be exploited, leading to the possibility of an attack that strikes at the heart of the interface between software and hardware. What Next? Engineering any artifact involves decisions about trade-offs, and these decisions are made relative to expectations about the environment in which the artifact will be deployed. Changes to the environment make it -crucially important to revisit and change a design. Computing systems and the internet ecosystem are a case in point. In the early days of computing, the environment in which computer systems were deployed was assumed to be relatively benign. Performance, time to market, and features were paramount; security was a concern in only a very small number of cases. But as dependence on computing systems—by nations, communities, and individuals—has grown, so have the threats. Assumptions about the environment that once were acceptable are no longer sound, and can have -dangerous consequences. Insofar as assumptions beget vulnerabilities, old designs need to be rethought. An added challenge is the increasing sophistication and capabilities of adversaries. New assumptions need to be robust against not only today’s but also tomorrow’s adversaries, because components built today will remain fielded for a long time and will become increasingly difficult to replace. Security trade-offs are not just technical choices; they have important policy implications, too. Efforts to address underrecognized and multidisciplinary aspects of evolving cybersecurity challenges will require theoretical perspectives (e.g., taxonomies of harm and remedies for data breaches, analyses of what system parameters affect what sorts of recoverability and update capabilities) as well as practical and organizational approaches (e.g., how does the anticipated lifecycle affect the organizational structure that maintains the system; what mechanisms are in place to ensure an orderly path to update cryptography suites when needed). Moreover, absent a continuing dialogue across these disciplines, attempts at solving cybersecurity problems are likely to fail. What’s needed are people who are not only expert in specific technical or policy matters but also comfortable in discussions concerning the entire spectrum of technical and policy issues and solutions. The National -Academies’ Forum on Cyber Resilience is one such effort, but there is much ground to cover, so more efforts are needed. Acknowledgments Much of this paper is based on discussions in the -National Academies’ Forum on Cyber Resilience; the authors are grateful to forum members for their thoughtful contributions at those meetings. Addi-tional thanks are due to Paul Kocher, Jon Eisenberg, and Emily -Grumbling for their comments on a draft version of this paper. The forum is supported by the National Science Foundation (award number CNS-14194917), the Office of the Director of National Intelligence (award number 10004154), and the National Institute of Standards and Technology (award number -60NANB16D311). We are grateful for their participation and vote of confidence in the work and activities of the forum. References Canella C, Van Bulck J, Schwarz M, Lipp M, von Berg B, -Ortner P, Piessens F, Evtyushkin D, Gruss D. 2018. A systematic evaluation of transient execution attacks and defenses. arXiv:1811.05441v1. Gressin S. 2018. The Marriott data breach. Consumer Information blog, Dec 4. Washington: Federal Trade -Commission. Ives M. 2019. Singapore says records for 14,200 HIV patients, held by an American, were leaked. New York Times, Jan 28. Kocher P, Genkin D, Gruss D, Haas W, Hamburg M, Lipp M, Mangard S, Prescher T, Schwarz M, Yarom Y. 2018. Spectre attacks: Exploiting speculative execution. -arXiv:1801.01203. Krebs B. 2015. Extortionists target Ashley Madison users. Krebs on Security, Aug 21. Lipp M, Schwarz M, Gruss D, Prescher T, Haas W, Fogh A, Horn J, Mangard S, Kocher P, Genkin D, and 2 others. 2018. Meltdown: Reading kernel memory from user space. Proceedings, 27th USENIX Security Symposium, Aug 15–17, Baltimore. NASEM [National Academies of Sciences, Engineering, and Medicine]. 2016. Data Breach Aftermath and Recovery for Individuals and Institutions: Proceedings of a Workshop. Washington: National Academies Press. NASEM. 2017. Cryptographic Agility and Inter-operability: Proceedings of a Workshop. Washington: National -Academies Press. NASEM. 2018. Recoverability as a First-Class Security Objective: Proceedings of a Workshop. Washington: National Academies Press. NASEM. 2019a. Beyond Spectre – Confronting New Technical and Policy Challenges: Proceedings of a Workshop. Washington: National Academies Press. NASEM. 2019b. Quantum Computing: Progress and Prospects. Washington: National Academies Press. Shor PW. 1994. Algorithms for quantum computation: Discrete logarithms and factoring. Proceedings, 35th Annual Symposium on Foundations of Computer Science, Nov 20–22, Santa Fe. [1] The challenges associated with supporting recovery were surveyed in a recent workshop (NASEM 2018). [2] OPM Cybersecurity Resource Center, Cybersecurity Incidents: What Happened (https://www.opm.gov/cybersecurity/-cybersecurity-incidents/ ). [3] The US Federal Trade Commission provided guidance for consumers and business owners in a series of blogs, September 2017–June 2018 (https://www.ftc.gov/equifax-data-breach). [4] A zero-day exploit is a cyberattack that occurs before a software weakness becomes known to the software provider who would be responsible for providing a mitigation. About the Author:Fred Schneider (NAE) is the Samuel B. Eckert Professor of Computer Science in the Department of Computer Science at Cornell University and chair of the Forum on Cyber Resilience, Computer Science and Telecommunications Board, National Academies of Sciences, Engineering, and Medicine. Lynette Millett is director of the forum.