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 source.
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] software."
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 system-of-systems."
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 issue.
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.
No comments:
Post a Comment