May 25, 2004 (11:05 AM EDT)
GAO Warns Of Risks In Foreign-Developed Software
Read the Original Article at InformationWeek
The potential exists that software developers from nations hostile to the United States could write code for American military weapon systems, and the Defense Department should do more to prevent that possibility, according to a report made public Tuesday by the General Accounting Office, the investigative arm of Congress.
The Defense Department is increasingly reliant on software and information systems for its weapon capabilities, and prime contractors are subcontracting more of their software development. "The increased reliance on software and a greater number of suppliers results in more opportunities to exploit vulnerabilities in defense software," Katherine Schinasi, GAO's managing director for acquisition and sourcing management, wrote in the 33-page report sent to the chairmen of two House Government Reform Committee subcommittees that have oversight on emerging threats and government IT. "In addition, DOD has reported that countries hostile to the United States are focusing resources on information warfare strategies. Therefore, software security, including the need for protection of software code from malicious activity, is an area of concern for many DOD programs."
To address software vulnerabilities and threats, GAO recommends that the Defense Department better define software-security requirements and compel program managers to lessen associated risks accordingly. In a written response to GAO, the Defense Department agreed with the findings--but only partially concurred with the recommendations over concerns that it places too much responsibility for risk mitigation with program managers.
GAO concludes that the Defense Department's acquisition and software-security policies don't fully address the risk of using foreign suppliers to develop weapon-systems software. The current acquisition guidance gives program officials discretion in managing foreign involvement in software development--without requiring them to identify and mitigate such risks. GAO says other policies intended to diminish IS vulnerabilities focus mostly on operational software-security threats, such as external hacking and unauthorized access to information systems, but not on insider threats, such as the insertion of malicious code by software developers. "Recent DOD initiatives may provide greater focus on these risks," Schinasi says in the report, "but to date have not been adopted as practice within DOD."
GAO says the Defense Department has begun to recognize potential risks from foreign software content, but this isn't always the case within the weapons programs where software is developed or acquired. Program officials for the systems in this review didn't make foreign involvement in software development a specific element of their risk-identification and -mitigation efforts, GAO says. As a result, the congressional investigators say, program officials' knowledge of the foreign-developed software included in their weapons systems varied.
Risk-mitigation efforts emphasized program-level risks, such as meeting program cost and schedule goals, instead of software-security risks, GAO says. Program officials often delegated risk mitigation and source selection to contractors that are primarily concerned with software functionality and quality assurance, rather than specifically addressing software security for development risks associated with foreign suppliers. "Unless program officials provide specific guidance," Schinasi says, "contractors may favor business considerations over potential software development security risks associated with using foreign suppliers."
As the amount of software on weapons systems increases, it becomes more difficult and costly to test every line of code, GAO says. The Defense Department can't afford to monitor all worldwide software-development facilities or provide clearances for all potential software developers. "The program manager must know more about who is developing software and where early in the software acquisition process," Schinasi says, "so that it can be included as part of software source selection and risk-mitigation decisions."