By Bob Brewin
November 30, 2007
Software developed in foreign countries and used by the Defense
Department and other agencies puts federal information systems at
serious risk of being hacked and compromised, according to a recent
report issued by Defense's top advisory board.
The report , released last month by a Defense Science Board task
force, warns that "globalization of software development where some ...
U.S. adversaries are writing the code that ... [Defense] will depend
upon in war creates a rich opportunity to damage or destroy elements of
the warfighter's capability."
Defense relies heavily on commercial off-the-shelf and custom-built
software developed in countries such as India, China and Russia, so it
can quickly and cheaply take advantage of the latest advances designed
for global markets rather than relying solely on U.S. developers.
But the task force's report, "Mission Impact of Foreign Influence on DoD
Software," concluded that relying on software developed in other
countries "presents an opportunity for threat agents to attack the
confidentiality, integrity and availability of operating systems,
middleware and applications that are essential to operations of U.S.
government information systems and the DoD."
The report emphasized that "the most direct threat is foreign corruption
of software: insertion by the developer of malware, backdoors and other
intentional flaws that can later by exploited."
The fear that software developed in foreign countries that government
agencies use in information systems may contain backdoors or programs
that allow hackers to steal information or take down systems goes back
to the late 1990s, when federal agencies hired foreign contractors to
rewrite code to keep systems from malfunctioning when the date changed
to the year 2000. But the Defense Science Board report is the first
formal acknowledgement since 1999 at the top levels within Defense that
such a security risk exists and highlights the seriousness of that risk.
A 1999 Defense Science Board task force report titled "Globalization and
Security"  stated, "DoD's necessary, inevitable and ever increasing
reliance on commercial software -- often developed offshore by software
engineers who have little, if any allegiance to the United States -- is
likely amplifying DoD vulnerability to information operations against
all such systems incorporating such software.
The 2007 task force report echoes the 1999 warnings about the potential
of malicious code in commercial software threatening Defense systems.
The 1999 report concluded, "Malicious code, which would facilitate
system intrusion, would be all but impossible to detect through testing,
primarily because of software's extreme and ever increasing complexity.
... Increased functionality means increased vulnerability."
But the latest warnings come with hard evidence that Defense systems
already have been infiltrated. In his introductory letter for the 2007
report, Robert Lucky, the task force chairman and a former vice
president of Telcordia Technologies (formerly Bell Labs), wrote: "Low
level malicious technologies have been employed to successfully
penetrate sensitive, unclassified DoD systems despite efforts by DoD to
maintain information security and assurance."
The board also reported that Defense faces a security threat from
"foreign adversaries' corruption of the supply chain. Commercial
development processes make no guarantees about the purity (or lack of
corruption) of the supply chain, nor could they reasonably do so. The
overall opaqueness of the software development supply chain and the
complexity of software itself make corruption hard to detect."
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 offshore against the risks
of encountering malware that could seriously jeopardize future defense
missions," the board concluded in the report. "Current systems designs,
assurance methodologies, acquisition procedures and knowledge of
adversarial intentions "are inadequate to the threat."
Despite these concerns, the board task force recommended that Defense
continue to "procure from, encourage and leverage the largest possible
global competitive marketplace consistent with national security."
Marketplace realities dictate the globalization of information
technology, which provides Defense with cost saving and market
innovation, and the board pointed out that the greatest threat to
Defense systems comes from custom code written for specific projects or
programs, not COTS software packages from companies such as Microsoft.
The board's conclusion dovetails with a Center for Strategic and
International Studies report  released in March. In its forward,
Philip Bond, president and chief executive officer of the Information
Technology Association of America, wrote, "The information technology
industry is global. Corporations based at home and abroad depend on a
worldwide supply chain to deliver and develop the very best products to
the U.S. government."
Restricting Defense to software written in the United States would
provide an advantage to "our adversaries jockeying for a position on the
battlefields of cyberspace," Bond noted.
The board's task force said Defense and the intelligence community need
to develop polices and procedures to ensure the integrity of software
used in critical information systems, but warned that "the problem of
detecting vulnerabilities is deeply complex, and there is no silver
bullet on the horizon."
Ensuring the integrity of code in complex Defense systems, such as the
Army's Future Combat Systems, which will use millions of lines of code
to stitch together multiple battlefield systems, presents a particular
challenge, according to an appendix to the board report. About 27
million lines of source code used in FCS are either COTS code or open
The FCS program office has determined there is a "low-to-moderate risk
that malicious code could be inserted into the FCS Master Software
Baseline and exploited," but, the report added, The Army has decided to
handle the problem of potentially malicious code by assuming that the
"profit motive will assure clean code in 'shrink wrapped' [consumer]
The Army also has decided to accept foreign software for areas not
critical to the performance of the FCS System of Systems Common
Operating Environment, according to the report, and plans to make blind
buys of software so the vendor does not know it has been purchased for
use in FCS.
The report said the Army has no automated tools that can detect all
malicious code and line-by-line inspection in FCS is not feasible.
Philip Coyle, senior adviser with the Center for Defense Information, a
security policy research organization in Washington, said the only
reason the Army is not conducting line-by-line inspection of code is
because Boeing Co., the FCS lead systems integrator, "doesn't want to do
it, and the Army doesn't want to have to pay them to do it.
"For the Army to say it is not feasible is nonsense," said Coyle, who
served as assistant secretary of Defense and director of its operational
test and evaluation office from 1994 to 2001. "Of course it's feasible.
Tedious? Yes, but they're going to have to do it eventually when
problems develop in FCS software that was assembled from a wide variety
of sources that turn out not to work effectively together in the overall
Coyle added, "Boeing will need to examine supplier source codes from the
start. Waiting until U.S. soldiers on the battlefield can prove that a
supplier has failed will be too late."
Boeing officials declined to answer a query about inspecting FCS
software code, deferring to the Army due to the "sensitivity" of the
Paul Mehney, an Army FCS spokesman, said the program has "a robust
information assurance plan in place. Potential threats are well known
and well understood, and processes, plus leading-edge technology, will
be used to address the threats. Additionally, as consistent with Army
regulations and acquisition policy, foreign ownership, control or
influence will be taken into account prior to software development,
integration or purchase."
Ed Hammersla, chief operating officer of Trusted Computer Solutions in
Herndon, Va., which supplies software used across Defense and the
intelligence community, said automated tools can help the Army examine
its FCS software. In addition, he said, TCS writes all its code in the
U.S. and makes a profit.
The Defense Science Board recommended that Defense could better ensure
the integrity of custom software by requiring all custom code written
for its systems deemed mission critical be developed by U.S. citizens
holding security clearances. ITAA's Bond said he partially agreed with
that suggestion, but added, "We're very interested in where they draw
the line on what is critical."
The board report said the ability to examine COTS software source code
would be a big help in detection of malware, but pointed out that such
an approach would be expensive and could pose a risk a vendor's
intellectual property. Scott Charney, Microsoft corporate vice president
at Trustworthy Computing in Redmond, Wash., said his company gives all
governments worldwide, including the U.S. government, access to its
The board's task force also recommended that Defense gain insight into
the processes vendors use to develop COTS software so it has meaningful
assurance that software code isn't being tampered with. The board called
for a product evaluation regime that is capable of reviewing vendor
development processes and rendering a judgment about the ability of the
vendor to produce secure software. The report also said the department
must assess the tools vendors use to identify vulnerabilities and allow
Defense personnel to interview developers.
Charney said Microsoft has advocated since 2004 a focus on a vendor's
actual development t process and use of Security Development Lifecycle
policies and tools to reduce software vulnerability rates. Charney said
Microsoft's SDL enforces a number of technical and policy controls to
limit and monitor access to its source code. Additional processes
included in the SDL, such as automated and manual reviews and testing,
"provide other mechanisms that would make an attempt to tamper with our
source code even more difficult," he said. "The SDL embeds security and
privacy milestones at every stage of the development process."
As part of the SDL, Charney said Microsoft conducts code reviews before
the company ships software, uses independent test teams and automated
tools to test security, and conducts penetration testing by independent
third parties, in some cases.
Charney said developing using these processes underscores the fact that
software security has less to do with where it is written than how it is
written. "Both secure and less secure software can be written anywhere,"
he said. "Because the goal is to produce more secure software, it is
critically important that vendors leverage the best talent available and
that talent may be located both inside and outside the United States."
Andy Kendzie, a spokesman for SAP in Newtown Square, Pa., said the
board's report pointed out that software assurance should be judged
according to the vendor's actual development process and not merely its
location. He added that while SAP's general software packages are
developed in a global environment, "software for highly sensitive
customers is handled in U.S.-based secure environments."
ITAA's Bond agreed that Defense needs more insight into software
vendors' development processes, but not to the extent that impedes the
ability of software vendors to innovate. Chris Fountain, chief executive
officer of SecureInfo, a McLean, Va., provider of information assurance
software to Defense and other federal users, said Defense should be able
to "look over the shoulder "of software developers.
Bond said any risks inherent in offshore development need to be balanced
against global software innovations, which have "tremendously improved"
U.S. warfighting capabilities.
Visit InfoSec News