The problems of building systems that meet the requirements of security and corporate compliance are difficult enough when designing and building an application in-house. The complexity of meeting these requirements increases exponentially when IT departments outsource the projects to personnel who are no longer onsite. It is possible that an outsourcer could deliver a product that does not meet the security requirements of the organization, opening up potential compliance problems that go unaddressed by IT.

Project managers and application designers for outsourced development applications are experiencing security challenges of a magnitude they have not seen before. Is that self-inflicted through corporate paranoia, or is it an absolute necessity?

Simplistically, the problems caused by the management of such projects can be compared with the challenges parents have with their teenagers. Most parental coaching manuals stress the importance of trusting your children and granting them some freedom. Therefore, parents give their offspring some freedom to make decisions for themselves, and the parents pronounce that they trust them. But how far do they trust them? Are these the same parents installing software to control PC and instant messaging access? Do the parents check out their children's MySpace pages? Are they reading their children's journals and tidying bedrooms with eagle eyes?

In the same way, an IT organization would not normally engage in an outsourcing project with a provider it doesn't trust. That would be foolish. But will the organization be stricter than with its in-house staff? Will it define strong rules and audit, audit, audit? You bet it will.

One overriding point throughout this article is that the scale of the project has a massive impact on the security requirement. As more and more SMBs consider some aspect of development outsourcing, a lot can be learned from the large projects that have gone before.

Wikipedia describes outsourcing this way: "Outsourcing (or contracting out) is often defined as the delegation of non-core operations or jobs from internal production within a business to an external entity (such as a subcontractor) that specializes in that operation. Outsourcing is a business decision that is often made to lower costs or focus on core competences."

But that definition can cover many different scenarios. Introducing consultants and contractors for IT development projects is nothing new. Projects with outside resources always present more management and security challenges than wholly in-house projects. However, each project within this broad range will have different security needs, especially if we consider the project types:

• Contracting with an ex-employee who is now independent but has the right skills and knowledge to be a consultant on legacy applications
• Contracting resources from a cheaper part of the same country—for example, "farmsourcing"
• Outsourcing to major players such as IBM Global Services, EDS, etc.
• Outsourcing to software providers with some development teams overseas
• Outsourcing to software providers with only a sales presence locally and all developers overseas
• Creating shared companies with overseas development organizations
• Creating a development resource company in a foreign country, often called "captive subsidiaries"

Each of these presents its own challenges and levels of risk. Obviously, as risk increases, the need for stronger security mechanisms increases, too. The most risky outsourcing project is the situation in which development resources are located in another country and provided by a totally separate organization. It is this type of scenario that raises the most security concerns; however, many apply to local outsourcing projects, too.

It is easy to slip into the mindset that "we" are good and the outsourcers are bad, but that is far from the truth. Speak to many of outsourcing providers, and their verbal commitment to IT security is blatantly obvious. Organizations should look for a provider with a such a mindset. This highlights another important aspect when choosing a partner: Organizations should look for an outsourcer with a similar level of project organizational maturity. To quantify this, organizations have in the past utilized standards that grew out of ISO 9001 to cover "quality" in development project management. One that has been used regularly over the last 20 years or so is the Capability Maturity Model (CMM). Many organizations have already evaluated their own level of process organization and should look for a developer with a similar level of maturity. CMM, which was developed out of the Software Engineering Institute at Carnegie Mellon, has since been sunsetted with the introduction of a newer model called Capability Maturity Model Integration (CMMI).

To analyze the security requirements for an outsourcing project, we can split the project into discrete sections. Some security issues span, or affect, more than one of these categories and may be mentioned multiple times:

• Project definition
• Design
• Technology infrastructure
• Skills/knowledge transfer
• Development
• Testing and QA
• Audit

Project Definition

A manager I worked for once told me that contracts were only written in case one of the signatories passed away! He believed that business relationships were directed by the personal relationships of the people involved and that any issues that arose would be addressed without recourse to the contract paperwork.

I am sure everyone can think of at least one situation in which that was blatantly not the case. Outsourced projects need good, strong, detailed contracts between the parties involved. Failure to take every precaution at this stage would be a disaster waiting to happen. Stop and think of the reason outsourcing projects take place. In the majority of cases, the answer is money. The client organization is looking for a cost-effective way to produce applications.

So what is the tradeoff organizations have to accept in order to get these savings? One reason for the cost-savings is that the outsourcer is in a region that has different standards and expectations for privacy and data protection. This is not to say they are more insecure, just that there may not be a culture of security and their legal system may not provide the same protection. This is similar to employing a building contractor who does not know, or adhere to, local building codes. It may be cheaper, but it could cause problems later.

In addition to the general items, the contract must address these security issues:

• Intellectual property rights
• Federal and industry regulations
• Privacy
• Country/state of jurisdiction
• Non-compete clauses
• Exit options—Discrete points along the way where it might be useful to end the relationship if security issues arise
• Results of failure to deliver by either side
• Arbitration—Whether this can be used, rather than the more expensive and slower legal systems
• Personnel expectations—For example, whether developers are allowed to work on other companies' projects or whether third-party contractors are allowed

Design

In some development departments, personnel have been working for the same business on the same applications for so long that the designer intentionally omits some design details. It is a great luxury not to have to explain the business, demonstrate the tools, and discuss the users' expectations in order to get a quality result.

However, in an outsourcing environment, the documentation must be complete. If the developers working for the outsourcing company are located in a different region of the world, they may have no understanding of what the application will do for the end user. Hence, a detailed specification document is required. However, the organization must maintain control of that document. Whether the company is a software developer or an organization needing an in-house application to run its business, loss of design documents can lead to loss of business advantage.

The type of design documentation, its expected flow, and its rules for use must be defined up front. In large outsourcing contracts, the development resources often never get to see a printed copy of the design specifications they are working from. The PC could be locked down so that the developer cannot transmit the document somewhere else, plug in a flash drive, etc. These severe and draconian measures are important to ensure that both parties are comfortable in the business relationship.

Technology Infrastructure

As mentioned, many companies insist on a high level of security for the hardware the outsource developers are using. This extends not only to the individual PCs but also to the infrastructure between the two organizations. Some outsourcers connect to their client's systems through shared lines to save expense. Companies must determine whether the possibility exists that another partner or client of the outsourcer could connect to their production systems or even just scan and steal documentation and coding that is being transferred. How should an organization react to such a risk? One option is to insist on a separate line for the organization's project and resources (which will erode some of the cost savings the client was hoping for) or to impose security restrictions/technologies on the shared lines (which will also erode the cost savings).

Some large outsourcing projects specify that the client has the right to build the PCs and servers that the developers are to use during the project to ensure that the correct security procedures are in place. Other organizations use technology to enforce the environment they need. For example, virtualization software provider VMware markets a product called ACE (Assured Computing Environment) that can encapsulate a total environment for the developer to work on. It can be configured so that developers can still access their emails, other clients' development environments, the Internet, etc. without compromising the security of the development model.

Other technology solutions may be required to enforce the right standards for the developers' PCs when they connect to an organization's own systems. As an example, it is important that virus definitions and OS patches are at the right level before allowing access to the network.

Skills/Knowledge Transfer

With any project, transferring business and application knowledge to the developers is an important aspect of the process. Similarly, transferring technical skills cannot be underplayed. When choosing an outsourcing provider, an organization should always try to find a good match within the developer base, but it is unlikely to be a perfect match, especially with legacy environments, such as some of the older iSeries technologies. It is critical during the partner search phase of the project that the outsourcing provider makes commitments regarding the skills available within its developer team, including specific details as to which person has those skills.

However, such commitments will be of no use if the developer assigned to the project resigns or is reassigned to a new project. Monitoring developer personnel is a critical ongoing task, especially if the developer has IDs permitting him to access the client's own systems. Because of these concerns, companies often decide to employ third-party organizations to verify that the personnel commitments made by the outsourcer are being met.

The type of application development project chosen to be outsourced can be vary greatly, but all have their own types of challenges. For example, one view is that maintenance of an old legacy system is a good choice for outsourcing so that internal development can focus on newer technologies. However, the skills transfer on the old application can lead to the type of privacy exposure documented above. Another view is that a completely new application is the right type of project, partly because there would be less skills transfer concerning the old processes; however, there would be more knowledge transfer related to the business. Whichever type of project an organization has available for outsourcing, it is guaranteed that considerable skills transfer will be necessary.

Development

Maintaining control of an outsourced project has the same basic requirements as traditional in-house development, just taken to the next degree. Even the least paranoid project manager has at some time wondered whether his own developers have inserted some rogue coding into applications. The worry is that, at some point in the future, a disgruntled person could activate that coding and cause all sorts of havoc. For example, the application could transfer the rounding errors to rogue bank accounts or the application could ignore the security restrictions if the user name is JHACKER.

Now hold that thought, and apply it to an outsourcing project, where the developers are in a poorer region of the world or a country with potential political instability. Could these factors influence a developer to introduce some sort of rogue coding into the application? An organization could try to review the coding details of every part of every application, but that will likely negate the cost benefits of outsourcing. More sensible is an organized, though random, audit of selected elements of the application.

Testing and Quality Assurance

One challenge for the organization is to ensure that the quality-testing phase does not become the most onerous part of the project. Despite good design documentation, skills transfer, and such, will the developer really understand the requirements and will the discussions between designer and developer work well across geographical and social boundaries? At least in the early stages of the project, it is critical to regularly check that the developers are interpreting the designs correctly. It is not sensible to wait too long to start the QA process.

One aspect of security that is often overlooked, even during in-house development, is the privacy of the available test data. Of course, outsourcing companies require good test data to prove their applications, but what does that test data contain? Of course, the current live corporate data is the best source of application information; however, it is critical that all useful and identifiable data is replaced before handing it over for use in testing. For example, a customer file with real customer names and real prices may be of value to competitors; therefore, it should be used as test data only if some of the data contents are changed.

Audit

Most of the elements highlighted above need to be strictly audited on a regular basis. Sadly, figures show that less than a quarter of clients audit the security of their outsourcing partners. Given the difficulties in doing this, it is not surprising. For example, will a client send a consultant to check the outsourcer's premises for physical security and proper use of design documentation every quarter—or even every year?

If the outsourcing developers have access to their clients' production systems for implementation issues and ongoing support, are the IDs being checked for appropriateness of access? Is that a part of the client's internal audit processes?

In many global outsourcing centers of the world, the outsourcers have matured to a security standard that is comparable to those of the client. This can still cause challenges as the outsourcer may have set those standards to meet one particular client, maybe their first large contract, but these may not meet all clients' standards. It is difficult for the outsourcer to make all clients happy at the same time.

Successful Outsourcing

A number of themes run through this article. First, the risk (or at least the perceived risk) is greater with outsourced development projects. Second, there is a delicate balance between trust and compliance; organizations must audit to the level they are comfortable with. Finally, as more and more SMBs take their first steps in remote development, a lot can be learned from the way the big boys have run their projects. However, trying to emulate all of the processes, tools, and methodologies that the larger companies have used will very quickly erode the cost savings associated with an outsourced development project.

Martin Norman is Senior Systems Engineer for SafeStone Technologies, an IBM BP specializing in compliance and identity management. As one of the original developers of SafeStone's security portfolio, Martin has performed security audits and advised on installations for clients throughout the United States and Europe. Martin can be contacted at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

Data Privacy Rules Around the World

Data Security: 8 Privacy Principles Every IT Pro Should Know

Why the IBM i Community Needs to Pay Attention to GDPR