Secure outsourcing: An impossibility or a necessity?

This political season has seen the term offshore outsourcing create as much controversy as WMD.

Concerns over the outflow of U.S. jobs to countries such as India, China, Malaysia, Israel and Ireland have made news in both the business and general press. Underlying the threat to U.S. jobs has been an increasing drumbeat of concern about the outflow of sensitive data and business process information that has followed those jobs.

Outsourcing engenders more than just labor implications. It has security implications as well. We are just beginning to understand the ways in which any company involved in outsourcing must act to manage the associated risk. Our industry has the responsibility to prevent secure outsourcing from being thought of as an impossibility. It must instead be one of the baseline requirements before moving any business function -- or any development -- overseas.

Outsourcing development: Not as cheap as it looks

Take the example of outsourcing application development. Between now and 2007, Gartner Inc. expects enterprise application outsourcing to grow 7.3% annually. Chief financial officers favor this trend, but many of the CIOs and chief information security officers I have spoken with aren't as enthusiastic, since the projected cost savings rarely take into account the extra due diligence that must be performed to validate the security of the delivered applications.

There is growing pressure to build security review and assurance into these projects, and companies need ways to sensibly, consistently and cost-effectively tackle this issue. Here are some ways security is being addressed:

Legislative pressure: California State Sen. Liz Figueroa, prompted by the case of a Pakistani outsourcer employee who threatened to reveal personal data unless she got paid, proposed legislation that would require all outsourced providers to comply with California's privacy and confidentiality laws, the strongest in the nation.

Regulatory pressure: Implementing the Gramm-Leach-Bliley Act, the Federal Financial Institutions Examination Council's IT Examination Handbook InfoBase specifies that a financial institution's vendor management program must establish "security requirements, acceptance criterion and test plans," and should include "reviewing and testing code for security vulnerabilities." The Health Insurance Portability and Accountability Act codifies a "chain of trust," requiring that there be partner agreements to ensure that the same level of security will be maintained at all links in the chain of information moving from one organization to another.

Legal pressure: Risk managers and corporate counsel are increasingly looking for ways to include security requirements in contracts for outsourced application development. Based on requests from our customers, we have worked with a multinational law firm to develop a new generation of security-focused contract language to be included in the same way that language concerning functional requirements and delivery timelines are included today. It's the new frontier of service-level agreement (SLA) language, and one you will want to be familiar with as you negotiate or renegotiate outsourcing agreements.

Secure code required here

We can't, as vendors or as consumers of outsourced IT, wait for legislation and regulation to catch up to our fiduciary responsibility to protect our organizations from risks. We must clearly articulate the expectations for security from outsourcing providers and provide specific, measurable criteria for judging that these standards have been met.

Take outsourced development as the example once again. The most efficient and lowest-cost method to outsourcing is to set clear requirements upfront and have a repeatable, verifiable process for confirming that those requirements have been met. This should apply to security expectations for the work as well.

Therefore, there needs to be specific contractual language in the SLA stating the security expectations for the software including:

  • The proper implementation of specified security technologies, such as encryption and access control
  • Testing for and confirmation of the absence of specified security flaws, called out in a separate schedule
  • Attainment of mutually acceptable levels of security, as measured and validated by mutually acceptable third-party audit and testing tools, as well as an internal audit.

In an increasingly dangerous and fast-paced world, it isn't acceptable to sacrifice security at the altar of cost savings, nor is there any need for that sacrifice. SLAs must include expectations of security in the acceptance requirements. With the advent of a range of application-security testing and audit tools, there is no longer any reason to claim ignorance of the security state of an outsourced application. There only remains the very human, but potentially very damaging, desire simply not to know. Ignorance of vulnerability is no longer an excuse.

Manage risk, not fear

Testing and management of security in deliverables shouldn't be proposed because of some fear of offshore organizations, but rather as a standard process applied to all inbound custom development, foreign or domestic. The process is fatally flawed if we begin with a supposition of malicious intent and try to develop methods to root out every possible cause. Rather, our approach must be consistent, our metrics stable and our purpose the protection of our assets. This holds true for work with outsourced vendors, as well as for applications that are built within the so-called four walls of your business but which in reality are actually distributed to your teams around the world.

I have no doubt that those outsourced vendors that don't approach security seriously will feel the heat as the drive to codify security expectations gains momentum. They will resist being held to a standard, claiming that there aren't valid testing paradigms by which security can be fairly judged. I disagree. They may not have existed five or even two years ago, but the testing and validation technologies do exist today and are becoming more robust every day. And rising to match them is a growing consensus on best practices and testing criteria that partners can use to arrive at mutually agreeable standards of security.

Take a stand with your vendors and across your own organization: Insist that the chain of trust remain unbroken and that they have the capacity to prove it to your satisfaction before payment changes hands. On time, on budget, to specifications and secure -- is that too much to ask? I think not.

P.S. If you would like to see the boilerplate language we are developing, drop me an e-mail at jdanahy@ouncelabs.com. I'd be happy to share it with you and would love your comments.

Jack Danahy is president and CEO of Ounce Labs, and a frequent speaker and writer on Internet security topics. Ounce Labs, based in Waltham, Mass., is a provider of automated source-code vulnerability analysis and management solutions.

Copyright © 2004 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon