Mission Impact of Foreign Influence on DoD Software

Full Title of Reference

Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software

Full Citation

Def. Science Board Task Force, Dep't of Def., Mission Impact of Foreign Influence on DOD Software (2007). Web

BibTeX Google Books

Categorization

• Resource by Type: US Government Reports and Documents
• Threats and Actors: Government Networks (.gov); Military Networks (.mil); States; Terrorists
• Issues: Attribution; Cyberwar; Government to Government; Public-Private Cooperation; Risk Management and Investment; Supply Chain Issues
• Approaches: Government Organizations

Key Words

Computer Network Attack, COTS Software, Cyber Warfare, Department of Homeland Security, Denial of Service Attacks, Hackers, Intelligence Community, Malicious Code (Malware), National Security, Outreach and Collaboration, Risk Modeling, Research & Development, Software Vulnerability, Sponsored Attacks, State Affiliation, Worm, Zero-Day Exploit

Synopsis

Software has become the central ingredient of the information age, increasing productivity, facilitating the storage and transfer of information, and enabling functionality in almost every realm of human endeavor. However, as it improves the Department of Defense's (DoD) capability, it increases DoDs dependency. Each year the Department of Defense depends more on software for its administration and for the planning and execution of its missions. This growing dependency is a source of weakness exacerbated by the mounting size, complexity and interconnectedness of its software programs. It is only a matter of time before an adversary exploits this weakness at a critical moment in history.

The software industry has become increasingly and irrevocably global. Much of the code is now written outside the United States (U.S.), some in countries that may have interests inimical to those of the United States. The combination of DoDs profound and growing dependence upon software and the expanding opportunity for .adversaries to introduce malicious code into this software has led to a growing risk to the Nation's defense.

A previous report of the Defense Science Board, "High Performance Microchip Supply", discussed a parallel evolution of the microchip industry and its potential impact on U.S. defense capabilities. The parallel is not exact because the microchip fabrication business requires increasingly large capital formation - a considerable barrier to entry by a lesser nation-state. Software development and production, by contrast, has a low investment threshold. It requires only talented people, who increasingly are found outside the United States.

The task force on microchip supply identified two areas of risk in the off-shoring of fabrication facilities - that the U.S. could be denied access to the supply of chips and that there could be malicious modifications in these chips. Because software is so easily reproduced, the former risk is small. The latter risk of "malware," however, is serious. It is this risk that is discussed at length in this report.

Software that the Defense Department acquires has been loosely categorized as:

• Commodity products - referred to as "commercial-off-the-shelf" (COTS) software;
• General software developed by or for the U.S. Government - referred to as "Government-off-the-shelf" (GOTS) software; and
• Custom software - generally created for unique defense applications.

The U.S. Government is obviously attracted by the first, COTS. It is produced for and sold in a highly competitive marketplace, and its development costs are amortized across a large base of consumers. Its functionality continually expands in response to competitive market demands. It is, in a word, a bargain, but it is also most likely to be produced offshore, and so presents the greater threat of malicious modification.

There are two distinct kinds of vulnerabilities in software. The first is the common "bug", an unintentional defect or weakness in the code that opens the door to opportunistic exploitation. The Department of Defense shares these vulnerabilities with all users. However, certain users are "high value targets", such as the financial sector and the Department of Defense. These high-value targets attract the "high-end" attackers. Moreover, the DoD also may be presumed to attract the most skilled and best financed attackers-a nation-state adversary or its proxy. These high-end attackers will not be content to exploit opportunistic vulnerabilities, which might be fixed and therefore unavailable at a critical juncture. Furthermore, they may seek to implant vulnerability for later exploitation. It is bad enough that this can be done remotely in the inter-networked world, but worse when the malefactors are in DoDs supply chain and are loyal to and working for an adversary nation-state -- especially a nation-state that is producing the software that the U.S. Government needs. The problem is serious, indeed. Such exploitable vulnerabilities may lie undetected until it is too late.

Unlike previous critical defense technologies which gave the U.S. an edge in the past, such as stealth, the strategic defense initiative, or nuclear weaponry, the U.S. is protected neither by technological secrets nor a high barrier of economic cost. Moreover, the consequences to U.S. defense capabilities could be even more severe than realized. Because of the high degree of interconnectedness of defense systems, penetration of one application could compromise many others.

In a perfect world there would be some automated means for detecting malicious code. Unfortunately, no such capability exists, and the trend is moving inexorably further from it as software becomes ever more complex and adversaries more skilled. Even if malicious code were discovered in advance, attributing it to a specific actor and/or knowing the intent of the actor may be problematic. Malicious code can resemble ordinary coding mistakes arid malicious intent may be plausibly denied. The inability to hold an individual accountable weakens deterrence mechanisms, such as the threat of criminal charges, or even separation of the individual or entity from the supply chain.

Task Force Conclusion

The Department of Defense faces a difficult quandary in its software purchases in applying intelligent risk management, trading off the attractive economics of COTS and of custom code written off-shore against the risks of encountering malware that could seriously jeopardize future defense missions. The current systems designs, assurance methodologies, acquisition procedures, and knowledge of adversarial capabilities and intentions are inadequate to the magnitude of the threat.

Task Force Recommendations

Acquisition of COTS and Foreign Software

DoD should continue to procure from, encourage and leverage the largest possible global competitive marketplace consistent with national security. The DoD must intelligently manage economics and risk. For many applications the inexpensive functionality and ubiquitous compatibility of COTS software make it the right choice. In acquiring Custom software the increased risk inherent in software written offshore may sometimes be worth the considerable cost savings. The task force recominends that critical system components be developed only by cleared U.S. citizens.

Increase U.S. Insight into Capabilities and Intentions of Adversaries

The intelligence Community should be tasked to collect and disseminate intelligence regarding the intents and capabilities of adversaries, particularly nation-state adversaries, to attack and subvert DoD systems and networks through supply chain exploitations, or through other sophisticated techniques.

DoD should increase knowledge and awareness among its cyber-defense and acquisition com1llunities of the capabilities and intent of nation-state adversaries.

Offensive Strategies Can Compliment Defensive Strategies

The U.S. Government should link cyber defensive and offensive operations to its broader national deterrence strategies, Communications and operations, treating adversarial cyber operations that damage U.S. information systems and networks as events warranting a balanced, full-spectrum response.

System Engineering and Architecture for Assurance

DoD should allocate assurance resources among acquisition programs at the architecture level based upon mission impact of system failure. The task force endorses the strategy and methods to accomplish this as developed by the DoD Software Assurance Tiger Team and validated by the Committee on National Security Systems (CNSS) Global IT Working Group.

DoD cannot cost effectively achieve a uniformly high degree of assurance for all the functionality it uses across many and varied mission activities. Allocating criticality of function levies a requirement for assurance of that function, and also of those functions that defend it. Systems identified as critical must then allocate criticality at the sub-system and assembly level.

To properly allocate scarce assurance resources, DoD must allocate criticality at the system-of-systems and enterprise architecture level. This analysis should occur early within the life-cycle, and should render a prioritization decision no later than Acquisition Milestone A, to allow programs of record to appropriately respond to their criticality.

Improve the Quality of DoD Software

The DoD can effectively raise the "signal-to-noise ratio" against software attacks by raising the overall quality of the software it acquires. If there were fewer unintentional bugs in software, the visibility of deliberate malware would be increased. While general improvements in information assurance (IA) will not, per se, prevent a determined attacker from corrupting the software supply chain, there are several compelling benefits in improving the overall assurance/securityworthiness of COTS.

A sophisticated adversary would have to work harder to introduce an exploitable vulnerability instead, as is currently the case, of relying upon the plausible deniability of a common programming error to avoid attribution of malicious intent. Furthermore, a sophisticated adversary would have less confidence that its malware would remain undetected, invisible in a world containing far fewer distracting vulnerabilities. That uncertainty could be a deterrent in itself.

Improve Tools and Technology for Assurance

Improve Trusted Computing Group (TCG) Technologies

The Trusted Computing Group initiatives, centered on the Trusted Platform Module (TPM), provide a means for containing intrusions into separated information domains. Each chipset that implements the Trusted Platform Module embeds a unique identifier. Cryptologic verification of this identity is required when access to system assets is requested. TPM may help ensure that only approved and signed code is run, thus reducing the risk of unapproved code being installed.

NSA and others have identified a number of improvements and complementary practices that would strengthen TCG-compliant systems, including privacy preserving attestation, virtualization, and architectures that provide richer software assurance measurement and monitoring capabilities.

Improve Effectiveness of Common Criteria

Currently, the official DoD-wide evaluation/validation scheme is the National Information Assurance Partnership (NIAP) based upon the Common Criteria. The reality today is that it would be far easier and more effective to improve Common Criteria than to invent a new scheme specific to the DoD or to DHS.

A number of ways to strengthen Common Criteria are discussed in the Recommendations section of this report. Among these suggestions are crediting vendors for the effective use of better development processes, including the use of automated vulnerability reduction tools and automated tools for vulnerability analysis-during evaluations at levels four (EAL4) and below. Validation schemes should also reduce artificial artifact creation and rely upon artifacts that are generated by the development process.

Improve Usefulness of Assurance Metrics

There is a natural tension between the U. S. Government’s need to know the security-worthiness of what they procure and a vendor's need to avoid disclosing particular vulnerabilities. One way to satisfy both needs would be to develop a weighted index of the security-worthiness of software. A weighted score could be generated via testing based on some combination of the utility of the tools itself, the amount of code coverage of the tool, and the test results against a particular product. The entire development process should also be evaluated.

More knowledgeable Acquisition of DoD Software

DoD should implement a scalable supplier assurance process to assure that critical suppliers are trustworthy. No product evaluation regime in effect today provides insight into a vendor's real development processes and their effectiveness at producing secure and trustworthy software - so the software assurance challenge for DoD is to define an evaluation regime that is capable of reviewing vendors' actual development processes and rendering a judgment about their ability to produce assured software.

The DoD acquisition process should require that products possess assurance matching the criticality of the function delivered. Furthermore, the DoD should require that all components should be supplied by suppliers of commensurate trustworthiness, and in particular, that all custom code written for systems deemed critical be developed by cleared U.S. citizens.

The collective buying power of the U.S. Government is such that it can force change on its suppliers to a degree no other market sector can reasonably do. The DoD, working in collaboration with the Office of Management and Budget (OMB), DHS, and other Federal agencies, can help to change the market dynamic through both positive and negative incentives so that they get better quality software, and to make better risk-based and "total cost" -based acquisitions.

Research and Development in Software Assurance

DoD should establish and fund a comprehensive Science and Technology Strategy and programs to advance the state-of-the-art in vulnerability detection and mitigation within software and hardware. The goals of the classified and unclassified research and development (R&D) investments in assurance should be to develop the technology to effectively take accidental vulnerabilities out of systems development and to improve Trusted Computing Group technologies in order to bound most risks of intentionally planted software. This program should monitor what markets are delivering, identify gaps between what the market is delivering and what DoD needs, and fill this gap.

Additional Notes and Highlights

Expertise Required: Defense Policy/Procurement - Low