View source for 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).  [http://www.cyber.st.dhs.gov/docs/Defense%20Science%20Board%20Task%20Force%20-%20Report%20on%20Mission%20Impact%20of%20Foreign%20Influence%20on%20DoD%20Software%20(2007).pdf  ''Web'']

[http://cyber.law.harvard.edu/cybersecurity/Special:Bibliography?f=wikibiblio.bib&title=Special:Bibliography&view=detailed&action=&keyword=DoD:2007 ''BibTeX'']
[http://books.google.com/books?id=1uC1SgAACAAJ&dq=Mission+Impact+of+Foreign+Influence+on+DOD+Software&ei=AiJTTLOJH5DsygSzssnMDg&cd=1 ''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== 

[[Keyword_Index_and_Glossary_of_Core_Ideas#Computer_Network_Attack | Computer Network Attack]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#COTS_Software | COTS Software]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Cyber_Warfare | Cyber Warfare]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Department_of_Homeland_Security | Department of Homeland Security]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#DDoS_Attack | Denial of Service Attacks]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Hacker | Hackers]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Intelligence_Infrastructure.2FInformation_Infrastructure | Intelligence Community]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Malware | Malicious Code (Malware)]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#National_Security | National Security]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Outreach_and_Collaboration | Outreach and Collaboration]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Risk_Modeling | Risk Modeling]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Research_&_Development | Research & Development]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Software_Vulnerability | Software Vulnerability]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Sponsored_Attacks | Sponsored Attacks]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#State_Affiliation | State Affiliation]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Worm | Worm]],
[[Keyword_Index_and_Glossary_of_Core_Ideas#Zero-Day_Exploit | 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