[ISN] Defense board sounds louder alarm about foreign software development

From: InfoSec News (alerts@private)
Date: Sun Dec 02 2007 - 22:24:47 PST


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 [1], 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" [2] 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 [3] 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 
source code.

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.

[1] http://www.acq.osd.mil/dsb/reports/2007-09-Mission_Impact_of_Foreign_Influence_on_DoD_Software.pdf 
[2] http://www.acq.osd.mil/dsb/reports/globalization.pdf
[3] http://www.csis.org/media/csis/pubs/070323_lewisforeigninflubook.pdf

Visit InfoSec News

This archive was generated by hypermail 2.1.3 : Sun Dec 02 2007 - 22:33:59 PST