The Dangers of Global Development

Overview
Software development is now a global process. Hundreds of U.S. corporations are turning to offshore software outsourcers to maintain their core systems as well as develop new applications. India alone exported over $7.8 billion dollars of software in FY 2001, over 65 percent of this went to the United States. Software outsourcing companies have set up offshore development centers (ODC) in many other Asian countries such as Pakistan, Malaysia, China, and the Philippines. Other popular destinations include Israel, Ireland, Mexico, Russia, and Chile. These countries offer low costs, valuable trained personnel, and English language capabilities. Their facilities employee thousands of programmers who develop software applications for U.S. companies.

Good illustrations of such facilities are the technology parks that India has developed to aid software-exporting companies. Software Technology Parks of India (STPI), headquartered in New Delhi, is an umbrella organization with eleven facilities throughout the country. Each technology park provides for a software company's infrastructure needs by guaranteeing a supply of electricity, high-speed telecommunications links, and even hardware and network capabilities. STPI provides services for more than 450 companies. Software exports from these parks grew at an annual rate of 65 percent during the nineties. Each STPI houses multiple offshore development centers.

An ODC may be a dedicated facility for one client or it may produce software for multiple clients. Analysts working at the client company develop system requirements and specifications and then send them for coding by programmers at an ODC. The ODC is usually connected to the client's host system through leased lines, through a Virtual Private Network (VPN), or sometimes directly through the Internet. The link to the ODC creates several potential vulnerabilities for the client's system. Vulnerabilities include Trojans or viruses embedded in the software, unauthorized access by ODC personnel into parts of the client network, and intrusion of the client system by a hacker who has penetrated the ODC defenses.

At the same time that software development has become a global industry, there are growing incidents of cyber warfare. After the emergency landing of a U.S. surveillance plane on Hainan Island, Chinese and American hackers declared war on each other, attacking Websites in opposing countries. Such attacks increased from two or three incidents per day before the incident to 40 to 50 immediately following it. In October 2000, a wave of denial of service attacks and network penetrations has spread through the Middle East. Hackers attacked both the Israeli Defense Forces and the Foreign Ministry Websites. The Foreign Ministry site crashed and the Defense Forces shut down their website as a defensive measure. U.S. organizations that support Israel were also attacked.

US government and private security consultants warned that such attacks could spill over to other American companies. On September 11, 2001, the unthinkable happened to the physical security of our nation. Given our country's newly heightened security consciousness, there is greater attention to network security. Still, U.S. corporations are struggling to establish effective security practices within their own companies. When a company outsourced a software project in the past, it rarely examined the security practices of the offshore outsourcing company. Whether this will change in the future depends on education of the security community, consumers and producers of offshore software, and our political leaders.

There is resistance to examining the security of the outsourcing option because of the cost factor. One of the great attractions of offshore outsourcing is the comparative price advantage compared to on-site development. Improved security will add to costs and both clients and vendors may be tempted to cut corners, despite the recent upsurge in terrorism. Few analysts have examined the security implications of global software development. The topic deserves in depth research, analysis, and increased visibility.

The Dangers of Global Development
Whether engaged in global software outsourcing or not, each company must assess the threats to their computer systems. Threats include viruses, denial of service attacks, network intrusions, fraud, and sabotage by disgruntled employees. It is, of course, impossible to defend against all possible threats and therefore each company must analyze its level of risk. Risk analysis must take into account the likelihood of the threat actually compromising the company system and the costs of such a compromise. The investment in computer and network security must be commensurate with the actual risks. Appropriate counter-measures must then be developed to meet the risks.

Risk analysis and determining appropriate counter-measures is necessary for all companies. However, the picture becomes much more complicated for a company that is using an offshore software development facility. There are several complicating factors:

      Loss of control - By outsourcing, a client loses control over the conditions under which its software is developed. A link with an ODC opens a broadband communications channel directly into the client system. The company's security personnel lose the ability to regulate authentication of users at the ODC.

      Network complexity - Network configuration management in an expanding and ever-changing environment is a challenge for most security departments. Maintaining an understanding of normal traffic patterns becomes almost impossible when an ODC is thrown into the mix. If the development center produces software for multiple clients and does not isolate the networks connected to each client's system, configuration management becomes an impossible task.

      Clashing security policies and procedures - The client and the ODC may take varying approaches regarding known vulnerabilities, intrusion detection, perimeter defense, or other security issues. These discrepancies could easily create vulnerabilities for both the client and the offshore vendor.

      Threats to a company's intellectual property - Offshore development creates risks to a company's intellectual property because trade secrets, customer data, and financial information are often made available to a foreign company whose employees are not subject to U.S. laws. The offshore developer or its employees may also be doing work for a competitor. A company's worst nightmare is losing their intellectual property when they go offshore since it would require international litigation, a process that could take years of effort while the damage is immediate.

      Legal issues - As mentioned, different laws govern offshore vendors. The issue is not contract enforcement as much as data security because most vendors contracts are enforceable in U.S. courts. However, the laws applying to protection of data are often non-existent in the offshore country. Another legal complication is presented by the new U.S. data privacy laws such as Graham-Leach-Bliley that requires U.S. financial corporations to protect the data of their customers. Few measures are required to ensure that offshore development centers are abiding by these laws.

Loss of control over code
When a company has its software produced in an ODC, it defines the performance requirements but it gives control over how the software is developed to the overseas vendor. Clients spend hundreds of thousands of dollars testing software applications to ensure that they meet requirements. Rarely, however, do security departments inspect the code for designer Trojans, viruses, or embedded Easter eggs - code that performs unspecified or even illicit activities. Virus scanners identify and sanitize widely known viruses, but they will not find code specifically designed to sabotage or provide particular information. Given the sophistication with which terrorists have infiltrated the aviation industry in the United States, it is highly likely that such attacks will occur in the future. In December of 2001, there was a spike in attacks against electric utility networks and the source of the attacks were IP addresses located in the Middle East. It would be much easier to penetrate the security of an offshore development center and implant some code time bombs that would later cause chaos for a U.S. company. Therefore, embedded malware in programs is a real risk that security departments must now guard against.

Loss of perimeter control
Clients establish direct links between an ODC and their host system for a number of reasons. Some offshore teams carry beepers and provide real-time applications support. Other teams log-on to the host system during the night to code and test programs. These programmers have authorization to update data files and system libraries needed to maintain the applications they support. In either case, the ODC network has direct access to the host computer. Some companies use development centers in foreign countries for critical operations. These companies include many leading American railroads and airlines. The vast majority of offshore developers are honest IT professionals happy to have the opportunity to work for a U.S. company. However, the catastrophic events at the World Trade Center and the Pentagon, show to what lengths terrorists have gone to cause damage to U.S. interests. Companies using offshore vendors need to know exactly what the vendor's perimeter defenses are. They need to know when perimeters have been breached and should be able to monitor intrusion detection systems. Vendor security policies must be examined for issues such as connecting to the Internet at the same time they are logged on to the client host system.

Lack of authentication controls
A client company also loses control over authentication of users logging in from the ODC. Software developers normally have user IDs with broad authority. The same is true for offshore developers. However, the client company has no control over the physical security of the ODC. Could people off the street or from another office or a team working on a competitor's system walk in and start using a workstation? Company security personnel have no way of knowing if the offshore developers are sharing passwords. The primary defense against unauthorized intrusion is authentication based on passwords and authorization rules. Password cracking tools such as LophtCrack can resolve most passwords within a few minutes.

Network complexity - The challenge to configuration management
When security admin knows the configuration of a network, they can determine the normal traffic patterns and automate monitoring of routine activities. Security administrators can correct known vulnerabilities and deploy regular anti-virus updates, website blocking, intrusion detection systems, appropriate firewalls, and other defensive measures. If a network is constantly changing, then it is very difficult to determine a normal baseline, even when the changes are known. Linking the host computer network with an ODC exponentially increases the complexity of the task. The ODC can change its configuration and host security services will know nothing of the changes.

An ODC link often means that an unknown network is linked into the heart of the client computer system.An ODC connection bypasses much of the host perimeter defenses and opens multiple channels for hostile penetration of the host system. A developer in an ODC may conscientiously be doing his job. Still, while he is coding and testing he could also chatting on a website that would be off limits to an on-site programmer. An attacker could use the open http connection to the workstation to implant a Trojan in the host system or map the corporate network.

Isolation levels within the ODC
Offshore development centers are often large complexes involving 500 or more programmers. They often work for a variety of clients. ODC management often moves network resources and software technicians from one project and from one client to another as the need arises. When people move from one company to another, they carry important knowledge with them. In the United States, most companies execute legal agreements protecting the company's intellectual property when they leave the country. This is not standard practice in many of the countries, which host ODCs. In addition, it is our experience in India that there is even less awareness of intellectual property issues when a programmer moves from working for one client to another within the same outsourcing vendor.

Lack of isolation of network resources is another critical issue. Sometimes hard-drives or servers are shared between projects for different clients. Even when resources are not directly shared, there are rarely perimeters established between LANs dedicated to different clients. In addition, depending on the configuration, it is possible for someone on a host network of one ODC client can use the development center as a means to connect to the network of another ODC client.

It is essential that the client ensures that their data and resources are isolated from that of other ODC clients. There are however different levels of isolation. Development for a project can take place on LANs that are completely isolated from the Internet and the rest of the ODC's networks with fully dedicated personnel. Alternatively, some resources can be shared between projects or even clients. Sharing of resources creates economies of scale and enables the vendor to pass on cost savings to the client. Applications are not all equally as critical and isolation does create additional costs. Therefore, the level of isolation of a project must be commensurate with its security requirements.

Security policies & procedures - Security reviews
A vigorous security reviews should be required before an offshore development contract is signed. Too often, the assumption has been that the vendor has an effective security policy. Even if the vendor has a good policy on paper, potential clients must ask how rigorously it is implemented. A security review is the only valid way to answer this question. As with all security investments, the extent of the review or audit should be commensurate with the risks involved. At a minimum, the review should consist of a thorough examination of the security policies and procedures. It should assess how well the ODC actually implements the policy and procedures. The client should either send a member of their corporate security team or hire an independent security analyst who is able to conduct the review on site. Questions to the vendor sales team are, of course, completely inadequate. An important factor of such a review is an investigation into how the vendor has dealt with known vulnerabilities. In addition to a security review of the ODC, it is critical that the client company involves its own network security personnel in all technical decisions regarding connectivity between the ODC network and the client's system. In addition, a security development life cycle should be part of the methodology for offshore projects.

Policy compatibility
Clients should analyze the security policy of the ODC for compatibility with their own policies and procedures. Issues such as passwords, virus protection, and business continuity should be reviewed for compatibility. Where there are conflicts between the two policies, a common approach should be spelled out and a common policy defined. The common policy can refer to the existing policies where there are no discrepancies. This process should be part of the master contract between outsourcing vendor and the client.

Security cooperation
The common policy should include a framework for cooperation between the network security departments of the vendor and client. Policy reviews and security audits are only snapshots at a particular time. It is critical that security cooperation includes appropriate monitoring, reporting, and incident handling procedures. Where this puts undue strain on vendor and client security departments, an independent security company can be hired to provide coordination.

Security ROI
Effectively implementing and monitoring additional security procedures costs money and money must be spent wisely. Not every application or every enhancement to an application need equally secure treatment. While certain principles such as isolation of LANs by client are essential, it is important for clients to analyze the security needs of each application being developed offshore.

Authority for offshore developers
System admin normally grants developers authority to update system libraries and a variety of files related to their applications. Production run-time libraries are often common across systems, especially for emergency updates to programs. Offshore programmers are routinely treated as remote developers. Once they pass through a perimeter firewall, they have the same access as on-site developers. However, there is a much higher level of risk for developers working thousands of miles away. The client will interact with a handful of project managers or lead personnel but know nothing about dozens of programmers doing the actual work. Therefore, their security classification of offshore personnel should be stricter than on-site developers. In general, authority to update files should be based on a person's functionality. Developers who support production systems need wide-ranging authority in order to fix unforeseen problems that occur in off-hours. Project leaders and analysts need greater access to client system resources. For the majority of offshore developers, however, file authority must restricted to what they need to perform their jobs.

Legal and intellectual property issues
The protection of intellectual property is primarily the duty of a company's legal department. Still, network security must also take an active role since theft of a company's trade secrets is now likely to occur using digital media. The main security goals here are in one sense the reverse of the normal approach of protecting the host from attack. When protecting intellectual property the first task is to identify the data files that must be protected and then access must be restricted. Next, the means by which this information can be removed from either the host site or the offshore development facility must be analyzed. Such information can be uploaded to a website, transferred through a modem connection, written onto a floppy disk or a CD.

It is essential for a company to analyze the risks that offshore relationships may pose to its intellectual property. The risks vary depending on the software application under development, the character of the relationship with the offshore vendor, and the nature of the corporation's intellectual property. Competitors can quickly use certain trade secrets, such as chemical formulae or industrial processes. Such information is critical to protect. Both client and vendor must employ the strictest security measures in software development projects that involve easily replicable trade secrets. Some projects relating to critical and easily replicated intellectual property ought not to be outsourced at all. Other intellectual property is not as easily stolen. For example, a trade process such as a financial planning methodology, takes a considerable time to master. Companies can develop appropriate steps to protect these processes from competitors. Security measures for offshore projects should fit the risks to a company's intellectual property.

In addition to trade secrets, customer data, and financial information are often exposed during a software development project. Customer data can easily be used for fraudulent purposes and the incident of international Internet credit card fraud is rising rapidly. In a tightly interconnected world financial system, information on the finances of large corporations can be used for insider trading and manipulation of stock prices. The employees of a foreign company are not subject to U.S. laws. Some countries such as India are aware of cyber crime and are beginning to take a few initial steps. However, the criminal justice systems of most Third World countries, lack the technical and legal framework to investigate and prosecute system break-ins or data theft.

Developing a knowledge transfer policy
As is the case in all projects with contract employees, the client will lose experience and knowledge that the employee has gained when she or he leaves the project. Some of this knowledge, especially that which constitutes critical intellectual property of the company represents a serious security risk. This situation is more critical in global development situations by legal factors, cultural differences, and international competition. While human beings are not machines and contract employee knowledge cannot be erased, it is important to keep track of contract resources that are exposed to critical knowledge. It is also important that this knowledge is retained within access of the client, to the extent this is possible. The client company should develop a knowledge transfer policy to cover these situations.

Physical Security
Whether a data center is in Delhi or Denver, physical security is essential for network security. However, in India and other ODC host-countries, physical security takes on cultural and physical nuances not present in the U.S. For example, on December 14, 2001, five men penetrated the heavily guarded perimeter of the Indian Parliament building with a car loaded with explosives and automatic weapons. Seven people were killed including the terrorist and only the sacrifice of an unarmed bailiff prevented a massacre of India's political leaders.

The terrorists gained access through social engineering. They drove a sedan similar to that used by all Indian officials and wore the uniforms of high ranking security officials. When the guard challenged them they threatened him with the loss of his job and he let them pass. The next day CNN filmed the British Prime Minister entering the grounds of a castle where a European summit meeting was being held. The guards searched the Prime Ministers car for bombs the same as any other vehicle. There is a lesson in these two events that the IT security community must keep in mind. In cultures where there is a rigid hierarchy, those on the lower echelons are brought up to be subservient to those above them. This means that many people who work as data center guards are susceptible to intimidation and manipulation by intruders who wear the mantle of authority.

Another example is a TerraFirma employee who worked for one of India's leading technology companies. He repeatedly entered the facility by saying he had forgotten his pass. Within the ODC, he had complete access to computers and files, even on projects that he knew nothing about, including a secure project for British Gas that developed refinery software.

These two examples illustrate the weaknesses in physical security at some ODCs. While the scheduled security audits examine physical security, the real issue is how is security maintained when auditors are not on the scene.

Conclusions
The threats to America's IT infrastructure from offshore outsourcing are very real but there are means to combat them. International firms can be become secure suppliers of reliable software and services. However, the standards by which they are judged must be set by the companies buying the software and acceptable to the U.S. government agencies charged with protecting the country's infrastructure. Overseas vendors should be judged by how they compare to U.S. companies and this rating should be conducted by American security companies. The rating methodology should include the following:

      A thorough review of the vendor's security policy. The policy must be address issues such as isolation of resources by client and security cooperation with the client.

      A rigorous network vulnerability assessment of the offshore development center, including its ability to protect client intellectual property.

      Evaluation of the application security development life cycle being used by the ODC. Application security must go far beyond password authentication and network firewalls. It must be built into the software application from the beginning.

      Ongoing monitoring and reporting of the ODC's client anti-virus, intrusion detection, and perimeter protection systems.

However, the responsibility for secure outsourcing does not lie with the vendors alone. U.S. companies themselves must be ready to meet the challenges presented by global software development. In addition to holding their vendors accountable on the above issues, U.S. buyers of outsourced software (including the U.S. government) should:

      Implement an independent review of their outsourcing security policy

      Conduct security testing of newly developed systems. (This applies to systems developed in-house as well as overseas.)

      Submit their own data centers to a security rating to evaluate where they stand compared to industry standards.