Toolbox

Patching Leaky Software Read More Machine Shop Archive

CSO: The Resource for Security Executives

CSO Newsletters
CSO's free newsletter keeps you informed about the latest articles, analysis, news, reports and other developments at CSOonline.com. Sign up today.


Subscribe to CSO
Our print publication is free to qualified readers in the U.S. and Canada.


Read CSO Online
All the issues of CSO are available online.

Information Without Borders

When it comes to outsourcing, out-of-site shouldn't mean out-of-mind

BY SIMSON GARFINKEL


What do textiles, cars and software all have in common? Answer: They're all in industries that once offered high-paying jobs to large numbers of U.S. workers, but then eventually moved production offshore to lower costs. For textiles, most of those exports happened in the 1970s and 1980s; automotive jobs were exported in the '80s and '90s. The software industry has been steadily moving offshore for the past five years, and the trend is likely to accelerate in the coming years.

We live in a world in which information can freely move across international boarders. People, on the other hand, are far less mobile. And because wages in countries such as Argentina, India, Pakistan and Russia are dramatically lower than they are here in the United States, it makes good economic sense for large companies to move as many programmer jobs overseas as possible. Doesn't it?

At a recent MIT-sponsored event for young entrepreneurs, one of the superstars—a twentysomething Pakistani who had graduated from MIT a few years ago—talked about how he had set up a software company to make tools for large websites. His company's headquarters is in the United States, and sales, marketing and support are done domestically too. But all the software development takes place in Pakistan, where the company has hired 24 programmers for what it would cost in Boston to hire four.

Another company that I visited has fewer than two dozen employees in its Boston headquarters—but a team of 60 programmers in Argentina backs them up. It's in Argentina where the heavy-duty engineering happens. The Boston office handles management, consulting and sales.

Coordinating these intercontinental development projects is easier than it might seem. With instantaneous e-mail, free IP-telephony and reasonably good Internet-based videoconferencing, the only real stumbling blocks to overseas development are time zones and language differences. Having bilingual senior management can eliminate the language barrier, and monthly trips between the home office and the programming shop seem to make the time-shift matter less.

But as we have seen time and again, there is no free lunch when it comes to security. Saving money almost always means an increased risk of something. And here, the risks that come with overseas development are many.


Not Invented Here
The first risk, surprisingly enough, is not technical but regulatory: If you are selling products to the U.S. government, you may be required to disclose the amount of "foreign content" in your product, and software that is developed outside the United States can count. Especially in the case of computer security tools, certain federal customers may not wish to purchase software programs developed in countries such as Argentina, India or Pakistan—or else they may require additional certification or assurance before the products are accepted. The fear, whether justified or not, is that software developed outside our borders is more likely to have intentional security vulnerabilities, Trojan Horses or back doors than software developed inside the country. Military customers feel especially vulnerable to these sorts of information warfare attacks since it is virtually impossible to analyze a piece of code and state that it doesn't have any security vulnerabilities.

What's more, the U.S. military has reason to be concerned. We've used similar regulations in the past to put security holes in software that we've exported to other countries. Back in the 1990s, U.S. export regulations allowed software with 40-bit encryption to be freely exported, but software with 128-bit encryption was restricted because the stronger encryption couldn't be cracked by the U.S. National Security Agency. That presented a problem for Lotus: Foreign customers didn't want to use the weaker versions of its programs. So Lotus and the NSA cut a deal. Lotus was allowed to sell the 128-bit version of its product overseas, but the program was modified so that 88 of the 128 bits for every encrypted message would be leaked to the NSA. Technically, those bits were leaked by encrypting them to a special public key that only the NSA controlled, then including those leaked bits with every Lotus Notes message. The Lotus/NSA deal was publicly discussed inside the United States, but overseas customers were generally unaware of it—that is, until Sweden's government learned that it was using software that had been specially gimmicked by the NSA to allow for easier surveillance.

When you outsource work, you also outsource control. You may have a policy that work should not be sent overseas, but it's hard to make sure that that policy is enforced.

So clearly, one of the risks of outsourcing your development is that you won't be able to sell your programs (or your services) to others in the United States. But there are other risks as well—specifically, you might lose control of your intellectual property. That's what almost happened to software company SolidWorks when one of its programmers in India stole the entire source code to the CAD system SolidWorks 2001 and offered to sell it to the company's competitors (see "Big Savings, Big Bucks").

The employee, Shekhar Verma, had landed a job with Geometric Software Solutions Ltd. (GSSL), an Indian company that had been given a contract to debug SolidWorks 2001 Plus. Things didn't work out well for Verma at GSSL, and he was fired for poor performance. A short while later, he allegedly sent a series of e-mail messages to SolidWorks' U.S. competitors, offering them the entire SolidWorks 2001 Plus source code for $200,000.

When a competitor turned the e-mail message over to the FBI, a sting was set up, and Verma was arrested. The value of the source code on those CD-ROMs has been reported to be anywhere between $70 million and $90 million.

According to FBI special agent Nenette Day, who spoke about the Verma case at a conference last year, one of the problems that the Indian authorities have had in prosecuting this case is that stealing these sorts of trade secrets wasn't a crime under Indian law at the time. So Verma had to be charged with simple theft. His attorneys then claimed that SolidWorks didn't have a cause of action against Verma, since he wasn't its employee.

Another problem with outsourcing software is source-code control. One company I know hired a team in Europe to port a program from Mac to Windows. The company got back a Windows installer and source code for the completed application. But the company never bothered to see if the source code could be compiled—it couldn't. A year later, when the company wanted a new version brought out, the Europeans demanded considerably more money than the project was worth. Without working source code, the company ended up abandoning the product.

Outsourcing isn't the only risk for software development. It's a risk whenever sensitive information leaves your perimeter of control. In October, the San Francisco Chronicle reported that a woman in Pakistan who was transcribing audio tapes for the University of California at San Francisco Medical Center had threatened to release patient records unless she was paid more money. It turns out that UCSF wasn't outsourcing directly to the woman in Pakistan. It had hired a medical transcription company in Sausalito to do the work. But that company outsourced the work to a woman in Florida, who wired somebody in Texas, who sent the work to Lubna Baloch in Pakistan. The recordings were being sent to Pakistan over the Internet, and when Baloch felt that she wasn't being paid enough money, she sent an e-mail to UCSF with a copy of some patients' reports and those audio recordings.

As UCSF found out, when you outsource work, you also outsource control. You may have a policy that work should not be sent overseas, as the Florida-based transcription company apparently did, but it's hard to make sure that that policy is enforced.


So What's a CSO to Do?
The first step is to carefully review outsourcing agreements with law firms both in your home country and in the country in which the outsourcing is taking place. Make sure that the agreements cover poor security and bad employees on the part of contractors and subcontractors alike. And make sure that the country has legislation that makes your contracts enforceable.

The second thing to do is to see if you can make anonymous or obscure personal information so that a leak will be less damaging. There's no reason that the audio recordings outsourced to Pakistan should have had the names of patients or even the medical institution attached to them. Had that information been withheld, Lubna Baloch wouldn't have known where to send her threat.

Finally, if your company outsources software development, you should make sure that the code that's created is checked and verified by qualified people you trust. And make sure that the code you get back actually works.


Simson Garfinkel, CISSP, is a technology writer based in the Boston area. He is also CTO of Sandstorm Enterprises, an information warfare software company. He can be reached at machineshop@cxo.com.

> Patching Leaky Software