Foreign Software: Security Threat?

FOREIGN SOFTWARE: SECURITY THREAT?

The global outsourcing of software development has
raised the potential for malicious code attacks.

By Cheryl Gerber

Although the global outsourcing of software development and the expanding use of commercial software have dropped the price and often boosted the quality of software, the practices have also raised the rate of malicious code attacks. That has presented a potential national security risk that the Department of Defense and a number of companies are battling with multiple technologies.

Two reports last year corroborated the nature of the risk and made recommendations to mitigate it. In March 2007, the Center for Strategic and International Studies (CSIS) issued a report citing malicious code, cyber-attacks and espionage as top threats facing the DoD and defense industry today, resulting primarily from software developed overseas, and to a lesser extent, from the global use of commercial software. The report also contended, however, that new software security policies ought to focus more on how, rather than where, software is developed.

In September, the report of the Defense Science Board Task Force, entitled, “Mission Impact of Foreign Influence on DoD Software,” came to similar conclusions and proposed processes and strategies to reduce the risk.

Both reports recommended new policies for improving software assurance and network integrity. The CSIS report noted that the number of U.S. companies outsourcing software development overseas had grown 25 percent from 2003 to 2006.

The DSB report warned that the risk of software supply chain exploits will escalate as adversaries gain more access through global outsourcing. It distinguished between the risks in COTS and higher risks of mission-critical custom software, pointing out that “while COTS development environments are more porous to attack than those of DoD custom development environments,” subversion of the latter is more likely to achieve adversarial objectives.

“Hundreds of millions of people look at commercial code, such as Windows, whereas critical custom code does not receive the daily scrutiny, does not have as many eyeballs on it, rendering it more vulnerable,” pointed out Dr. Robert Lucky, chairman of the DSB task force that wrote the report.

Security software experts agree that when it comes to vetting software, the larger the talent pool, the better the result. “You want to make algorithms public because they can’t be trusted unless they are, and you get enormous benefit from the public attacking it,” said Dan Geer, chief scientist and vice president of Verdasys, a security software firm.

Concurrently, opponents wielding malicious code have grown more sophisticated. “This is no longer hobbyists doing it for fun and games. It’s playing for keeps. The skill level is increasing. Now it’s a job paid for out of revenue,” said Geer. “Instead of trying to put a mole in the CIA, they try to put a mole in software.”

As such, cyber-attacks are now more devious and focused. “They’re getting good enough at it that they now favor stealth over persistence. Many attacks are now targeted—not blanketed, shot-in-the-dark viruses,” said Geer.

Finding Vulnerabilities

Meanwhile, the technology industry has made progress at finding which writing patterns leave software vulnerable to inadvertent bugs. Microsoft and Sun Microsystems, for example, improved security in the companies’ .net and Java frameworks, respectively, although those improvements helped only to eliminate some, but not all, unintentional vulnerabilities.

“The computer security community has a pretty good understanding of the range of human errors that lead to security compromises in software. We don’t have nearly as good a handle on what malicious programmers introduce. It’s harder to detect an adversary who is actively trying to avoid detection,” said Brian Chess, chief scientist, Fortify Software.

The constant, low-level intrusions on internal DoD networks pose a threat to classified systems as well. The DSB report noted that penetration of sensitive-but-unclassified systems and networks can allow adversaries to steal or tamper with information, and to build up knowledge about classified systems. “They might not be able to find classified systems, but they can find things about classified systems, pointers to classified systems and documents about developments,” Lucky said.

Another finding of the DSB report states, “Software deployed across DoD continues to contain numerous vulnerabilities and weak information security design characteristics. DoD and its industry partners spend considerable resources on patch management, while gaining only limited improvement in defense posture.”

One chart in the report shows how the number of information assurance vulnerability alerts (IAVA) rose significantly from 2002 to 2006. More than 6,000 of them could cause root-level compromise, yet only 423 IAVA management notices were published in that period. The highest increase was in the most critical systems. Indeed, critical, complex classified and customized systems were cited as the most difficult to manage, partly because of the lack of eyeballs on those systems.

The report further states: “For mission-critical or complex software, programs are unlikely to be patched quickly regardless of the severity of the issue, precisely because the systems are so critical or complex. Such conditions mandate significant testing before patch deployment.”

Yet testing software reveals one of the toughest problems of software development. “We do not at present know how to write software that is completely unflawed. And we don’t have a good way yet to measure security in software. We don’t have a reasonable metric for that. For instance, how long has a flaw been present before it was known to have been exploited?” asked Geer.

Testing software code is a bit like an obstacle course in a quagmire, with intellectual property rights cropping up alongside a host of other concerns. “It’s a messy situation. The whole issue of testing code is difficult legally, economically and management-wise. If software companies let the U.S. dissemble and pry into code, you have to let others do the same. So they don’t want to open that Pandora’s Box,” Lucky said.

The DSB report also advocated improving the software acquisition process by requiring developers to inform DoD of what tools they used and how they developed the code. “It really comes down to risk management. One way around it is to have independent testing labs with ironclad agreements with software companies,” said Lucky.

Air Force Assurance

To battle malicious cyber-attacks on existing software, the Air Force in September 2007 launched the Application Software Assurance Center of Excellence (ASACoE), tasked with centralizing software assurance knowledge and best practices Air Force-wide. Initial funding for the center was awarded under the Network Centric Solutions program (NETCENTS).

Under prime contractor Telos, several subcontractors are providing security technology to the ASACoE, including Cigital, Fortify Software, IBM Watchfire and Application Security.

Cigital is acting as a subject matter expert for software assurance to assist Telos in meeting the Air Force requirements for ASACoE technical direction. “It includes defining strategic approach and software assurance methodology as well as selecting and leveraging appropriate tools and technologies,” said Sean Barnum, Cigital principal consultant.

Barnum said Cigital and the Air Force team have identified seven areas of software assurance to be tackled in the ASACoE: knowledge, technologies, process, risk management, acquisition assurance, governance and secure software operations. He added that the final area is not the same as network operations. “Going forward there will be other tools needed and additional methodologies for application risk assessment,” he said.

For the initial award, Cigital is helping to prepare the first suite of tools to meet Air Force application security requirements. The Air Force Electronic Systems Center at Hanscom AFB, Mass., had already been using Fortify Software’s Defender product to monitor and protect operational software from certain types of attacks, so it simply expanded into a broader portfolio of Fortify products, including Tracer and Source Code Analysis. Fortify has since rolled the three products into one, now called Fortify 360.

While Application Security provides dynamic analysis of software, which is observing software behavior under various conditions while it’s running, Fortify supplies static source code analysis. “It goes beyond looking at words into looking at the context that software code occupies and what the code means,” said Chess. “What we’re looking for is whether or not an attacker could take advantage of that code.”

The Air Force center also uses an IBM Watchfire tool called AppScan. IBM acquired Watchfire last year, and then integrated its security technology into IBM’s Rational product line to offer customers a way to build security into the design, build and test phases of software development.

“Application security assessment has been around for a while, but we have only begun in recent years to embed security analysis throughout the entire software development life cycle,” said Danny Allen, director of security research, IBM Watchfire.

AppScan is a Web application vulnerability assessment and compliance tool that guards against cyber-attacks and compliance breaches. It comes in auditor and enterprise versions. IBM Rational integrated AppScan into its existing ClearQuest and Build Forge software.

ClearQuest tracks existing and new defects in software and audits to provide traceability, while Build Forge automates security in the build and release process of software as it is written. “There is also an option for AppScan to analyze security each time the application is compiled,” said Allen.

“The technology performs much like a malicious individual in testing applications,” said Allen. “The two core pieces of proprietary intellectual property include an automated understanding of what software does and is supposed to do, and intelligent fuzz testing, which looks at the boundaries of what is expected and tries to step outside those boundaries intelligently,” he said. “You take a known entry point to an application and try inputs that are outside the norm to see how the software responds.”

Risk Ratings

IBM’s acquisition of Watchfire illustrates one of various security technology developments in the last two years. Founded in 2006 with financial services customers, security software provider Veracode acts as an independent third party to broker the quality of security between a producer and consumer of software.

Customers upload their software to Veracode’s secure Website. Veracode’s SecurityReview analyzes the software for unintentional and malicious security vulnerabilities, and then sends a detailed report with risk ratings to the producer and a summary report to the consumer.

“It protects the intellectual property of the producer, and since the consumer does not have the details to exploit the problems we find, it protects against insider threats by having an independent party conduct the test,” said Chris Wysopal, chief technology officer for Veracode.

Veracode specializes in back doors—discovering unknown entry points in software, and in benchmarking against human code review. “In general, the automated analysis will find the majority of issues a human can find, and some things the human missed. There are some classes of vulnerabilities that cannot be automated, at least with known techniques, and require a human to detect. There are also some classes of vulnerabilities that humans are poor at and automation is better. Then there is the overlap where both techniques can be accurate,” Wysopal said.

Veracode is currently planning a separate classified facility for an individual with the proper classified clearances to run the company’s software. “We see a need for the classified, customized software community to have this service,” he said.

Most security professionals seem to agree with the findings of the reports. “It is true that we are pumping out more software that is more vulnerable at the same time as we have more sophisticated opponents,” Barnum said.

As part of the ongoing battle to protect internal DoD systems from the risks identified in the reports and to continue building security requirements into contracts, it seems inevitable that software vendors will build vulnerability detection tools into mission-critical software development processes in the future if they want to qualify for DoD acquisition.

In the meantime, though, there is no comprehensive method of measuring how good software is.

“We talk about the metrics of measuring software assurance, but we have no way of telling how good software is. How do we know how buggy code is? We need metrics to measure it so we can improve upon it. I’d like to see more funding devoted to research on this critical software assurance problem,” said Lucky. ♦