In-Depth
Outsourcing: Securing Software Development
As application development outsourcing pushes into high-risk foreign locations, new techniques are needed to protect intellectual property resident within software applications.
by Victor DeMarines
The alarming spike in software piracy, coupled with offshore outsourcing to areas with weak intellectual property (IP) enforcement laws make it all the more critical for organizations to step up protection of intellectual property. There are essentially three ways organizations attempt to protect software: legal agreements, code segregation, and source code review.
Legal Agreements: Before any code or API is allowed to be shared, organizations normally insist on a Non-disclosure Agreement (NDA). This agreement outlines what is confidential and provides terms for sharing sensitive IP. However, this will do little good in countries were IP enforcement laws have been weak. If the partnering scenario involves outsourcing of application development, then legal agreements will include provisions for auditing a vendor’s site and mandating of hiring requirements.
Code Segregation: This broad term includes technologies and approaches used to control access to sensitive software. Examples are secure file transfer, network segregation, and password access to source-code repositories. Code segregation is most important if you are dealing with third-party development firms that may be working with competitors in your market. However, even these controls cannot protect your code from a disgruntled employee with access to the source-code repository.
Source Code Review: As organizations increase their application development outsourcing offshore, it is necessary to review the resulting source code. Not only should the code be reviewed for legal use of open-source software and GNU General Public License (GPL) it should also be examined for malware and back doors that may have been injected during development.
These three approaches are necessary, but few focus on the direct threats to the code itself. Organizations have a unique opportunity to leverage software protection technology to enable safe sharing of software applications for collaborative development environments.
Software protection technology is a general category for technologies designed to deter reverse engineering (RE) of applications. Normally these solutions are deployed to prevent piracy, protect sensitive algorithms from competitors, and prevent tampering of software. Although code-protecting software within un-trusted computing environments is far from absolute security, its goal of making reverse engineering both expensive and time-consuming is a valuable measure.
In general, software protection solutions can add their countermeasures to applications either by modifying the source code or via injecting into the binary themselves (i.e., embedded code within the compiled object code). Countermeasures employed by anti-RE features include:
Code Obfuscation: Obfuscation techniques make deployed software difficult to decipher by removing symbols, encrypting strings, or altering code control flow. It is a passive technology in the sense that it does not attempt to actively stop a reverse engineer. Although it can applied to source code, it has been most often used in Java and Microsoft .NET computing environments because of the greater threat to accessing source code when using these frameworks.
Encryption: Software encryption can defeat static analysis of sensitive functions. Encryption applied at the function level and at run-time is decrypted and then re-encrypted after the function is called. This can be an effective way to prevent hackers from simply dumping the decrypted code in memory. While it is a useful defense, it is difficult to apply in intermediate language environments, so must be combined with other run-time countermeasures that verify the environment is safe to execute code.
Anti-tampering: Anti-tampering features are critical to ensure safe execution of software. Software protection technology normally deploys their own cryptographic-based means to detect and prevent tampering of software modules. These features are normally superior to existing code signing (or in the Microsoft .NET world Strong Name), which can be easily stripped out by manipulating the intermediate language. Anti-tampering is a pivotal defense because is can prevent a cracker from creating a binary patch that manipulates machine code to bypass licensing routines.
Anti-debugging: Because tools such as Microsoft Windbg, SoftIce, and dissemblers such as DataRescue‘s IDA Pro are so effective in analyzing deployed application code, software protection solutions normally deploy multiple anti-debugging tricks and techniques to prevent these tools from attaching to an application. There is no absolute way to prevent these tools from being used to reverse engineer an application, but it can make the process more difficult by combining multiple anti-debugging countermeasures. Usually these techniques are kept at the user (“Ring 3”) level, but some solutions have attempted to monitor and block threats at the kernel (“Ring 0”) level and introduced even greater security vulnerabilities.
Execution Monitoring: Additional monitoring of the execution environment can be deployed to further deter reverse engineering. For example, anti-debugging alone would offer little protection if the protected application could run within a virtual machine (i.e., ReactOS, Bochs, Xen, etc.) where the user would have complete control of memory.
More Features Equals Greater Protection
If these features could be applied to software shared in risky development environments, they would offer a more direct approach to securing code. The value of software protection is proportional to number of defenses against reverse engineering offered. Therefore, when looking for a solution, make sure it combines the features mentioned above and offers a “Defense in Depth” strategy versus reliance on any one approach (which creates a single point of failure for the protection itself). However, one critical requirement that must be addressed in software protection solutions in a collaborative software development process is the ability to differentiate and allow development tools to be used with protected software.
Many of the features mentioned above would also break many of the development processes needed. This is because applying software protection systems is normally a binary proposition. If the code needs to be protected, then once the protection technology is applied, its purpose is to prevent all debuggers and development aids from attaching the protected application.
To the resolve this security dilemma, software protection solutions need to relax some of their anti-RE features to allow authorized partners, firms, and users to develop around protected software. However, if not controlled, this approach would reduce the value of applying software protection in the first place. Therefore, organizations wishing to leverage this technology should look for capabilities in the technology that would enable authorized end users to develop and debug their extensions around the application code without exposing sensitive code within the primary protected application.
Summary
As application development outsourcing pushes into high-risk foreign locations, new techniques are needed to protect intellectual property resident within software applications. Existing indirect approaches, although necessary for outsourced development, are only successful in environments where IP laws are enforced. Therefore, by layering software protection solutions with your development partners, you can directly govern access to their software IP . Prior to applying software protection, organizations need to evaluate and ensure protection can be applied in concert with development processes.
Software protection solution must offer extensions to allow controlled access to code, it can be transformed from a strict anti-reverse-engineering technology to an approach that can encourage and develop avenues for distributed software development.
Victor DeMarines is vice president of products at V.i. Laboratories. You can reach the author at vdemarines@vilabs.com.