The Biden Administration’s Impending Executive Order on Software Security

The White House in Washington, D.C. (Alex Proimos, https://tinyurl.com/xrzncrw5; CC BY-NC 2.0, https://creativecommons.org/licenses/by-nc/2.0/) Last year’s revelation of the infiltration of federal agency digital supply chains—via the information technology (IT) contractor SolarWinds —revealed gaping holes in America’s cyber defenses. The White House recently attributed this intrusion to the Russian foreign intelligence service , further highlighting the sophisticated nature of malicious cyber actors targeting the United States. Following closely on this news was the announcement by Microsoft that probable Chinese government hackers had exploited previously unknown attack vectors in one of its products. The Biden administration has begun responding to these and other high-profile exploitations of vulnerabilities in commercially available software—including some used by the United States Government—through a variety of means. Although any retaliatory actions that the United States takes against the perpetrators of these digital espionage campaigns are worthy of their own analysis, preventing future such infiltrations in the first place is of vital concern. Toward this end, the White House has signaled its intent to release an executive order on software security. While the exact text of the order is not yet public, both media reporting and public statements by administration officials have highlighted what will likely be the key components. In this post I describe what the order might look like—based on information that is currently publicly available—and also comment on the merits of its various aspects. From my analysis of the publicly available information, it appears likely the order will drive action in three specific domains: improvements to internal federal department and agency operations, mandatory secure development standards for contractors selling software to the government, and requirements for these organizations to report data breaches proactively and cooperate with investigations into them. The first category is where the executive order can have the fastest impacts because establishing and refining internal government procedures is likely the simplest place to start, bureaucratic inertia and resistance notwithstanding. Generally, the steps in this area being publicly mulled are welcome. But, regarding the latter two categories—which relate to the government’s interaction with software vendors—I have some concerns. While laying out these reservations, I will suggest ways in which the executive order can help improve the security of federal networks without triggering unintended consequences. In general, the order should direct the federal government to focus on managing all relevant risks while avoiding a “box-checking” focus on compliance. With respect to federal department and agency IT operations, a Reuters article reporting on an early draft suggests that the impending order will mandate more extensive use of encryption and multifactor authentication. Although additional detailed guidance will be vital for implementing these requirements, on their face they appear appropriate. Use of the former technology still appears to be uneven throughout the government’s computers, and the latter can help stop even nation-state hackers from reusing stolen credentials to move laterally through systems. In addition to requiring the use of technical controls, however, organizational and policy changes are also needed, and the new order is an excellent vehicle to implement them. Although nothing in the public record suggests this is imminent, modifying the Obama administration-era Presidential Policy Directive (PPD) 41 would be a critical step toward improving the government’s ability to respond to malicious activity in the digital domain. Specifically, the new order should clarify the definition of a “cyber incident,” as PPD-41 currently conflates vulnerabilities—potential infiltration vectors—with imminent or actual exploitations of them. Federal IT teams likely detect potential vulnerabilities of varying severity in their systems every day . The vast majority are extremely difficult to use maliciously or are exploitable only in a limited set of situations . In my assessment, truly serious vulnerabilities might warrant rapid and broad notification, but the mere discovery of one should not necessarily trigger action at the level of the National Security Council. Exploitations , by contrast, represent the successful use by an attacker of one or more such vulnerabilities. Unless conducted by an authorized party such as an ethical hacker or penetration tester, such events necessarily indicate hostile intent and are generally cause for far greater concern than the identification of a vulnerability alone. On this note, federal departments and agencies need detailed guidance regarding damage thresholds and timelines for notification of such cyber incidents (or impending ones). For example, the order should lay out quantitative notification criteria based on the dollar value of financial loss expected or—in the worst case—actual or anticipated number of deaths or injuries. For example, a sophisticated breach of sensitive systems requiring expensive incident response and forensic measures should necessarily lead to the immediate notification of senior officials. By contrast, the prompt detection and blocking of an unskilled reconnaissance attempt can probably be reported in a weekly or monthly roll-up of malicious cyber events. Unfortunately, the existing incident classification schema established by PPD-41 uses qualitative terminology, which the information security community increasingly views as poor practice due to its openness to interpretation. A well-designed successor regime to PPD-41 would base event triggers on numeric damage estimates. Such a clear framework could also serve as a foundation for the private-sector reporting requirements being mulled. Finally, the Biden administration should use the issuance of the order as an opportunity to eliminate the accountability by committee that PPD-41 established (via the Cyber Response Group). The president should simply use the order to delegate coordination authority for cyber incident response to the newly established national cyber director position, as another Lawfare author has previously suggested . With such explicit authorization, and assuming he is confirmed, the recently nominated Chris Inglis can direct the relevant federal actors to take appropriate action. Similarly, the president should be wary of creating yet another organization, such as the proposed cybersecurity incident response board that the aforementioned Reuters article has suggested is under consideration. Establishing such an additional body would further cloud the already muddy waters of responsibility for information security in the federal government. In response to the second category of potential requirements—security mandates levied on government contractors—a coalition of industry groups have already expressed concerns via a letter to the secretaries of commerce and homeland security. I think their hesitance is appropriate, based on some statements the Biden administration has already made publicly. For example, Jeff Greene, acting senior director for cybersecurity at the National Security Council, said that “we’re at the point where the federal government simply can’t bear the risk of buying insecure software anymore.” This statement implies plans to implement a (currently undefined) standard of security for software below which the government will never consider buying it. Unfortunately, indexing only on one characteristic of a piece of software is not a good practice, either for the private sector or for the government. As I have stated before, deciding whether to accept information security risk or spend time and money mitigating it must always depend on the countervailing reward to be had by using such software. At times, keeping old and likely insecure software in operation might be the only alternative to shutting down entire systems or programs. A zero-defect mentality with respect to cybersecurity can inflict substantial costs in other domains that, upon review, leaders often decide are not justifiable or appropriate. Additionally, such a binary perspective necessarily implies a “box-checking” mentality rather than a focus on weighing risks and rewards. To give just one example, the Reuters article suggests the order will require in certain cases that vendors provide the government with software bills of material (SBOMs), identifying all of the components contained therein. Taken by itself, this seems like a sensible requirement, as third-party components (and their dependencies) can introduce serious vulnerabilities into applications. The government, however, should be careful in what it asks for and have a plan for what happens if it gets it. SBOMs can certainly highlight known vulnerabilities in products used in federal IT systems, but a surface-level analysis of a typical SBOM will likely set off unnecessary alarm bells while potentially obscuring true threats. Due to the nearly ubiquitous use of third-party libraries in enterprise sof
The Biden Administration’s Impending Executive Order on Software Security posted first on http://realempcol.tumblr.com/rss