Using DLP to Protect Your Source Code

Monday, January 17, 2011

Danny Lieberman

959779642e6e758563e80b5d83150a9f

Dec 10, 2010.

Sergey Aleynikov, a 40-year-old former Goldman Sachs programmer, was found guilty on Friday by a federal jury in Manhattan of stealing proprietary source code from the bank’s high-frequency trading platform. He was convicted on two counts — theft of trade secrets and transportation of stolen property — and faces up to 10 years in prison.

Mr. Aleynikov’s arrest in 2009 drew attention to a business that had been little known outside Wall Street — high-frequency trading, which uses complex computer algorithms to make lightning-fast trades to exploit tiny discrepancies in price. Such trading has become an increasingly important source of revenue for Wall Street firms and hedge funds, and those companies fiercely protect the code underpinning their trading strategies.

See full story on the Goldman Sachs source code theft incident

If you have proprietary algorithms, it can and may be happening to you. Consider three threat scenarios for software assets:

1. Source code  theft by employees

Source code theft by employees can be a major ethical issue that requires good management but also good detection. Designing, developing and deploying successful software is complex business, but unfortunately, most companies don’t know whether or not their source code is leaving their network with some proprietary algorithms. See the story about Chinese source code theft.

The stories of losing source code and having it posted on the Net are fairly common – remember  Windows NT source code and Mainsoft?.  We’ve found, from work with software developers, that many source code leaks are never reported. Frightengly, companies usually have no idea how the source code got out in the first place and call in consultants after the event to detect the origin of the leak .

In order to respond quickly to a suspected disclosure of company IP/source code, it’s crucial to be doing real time detection which is far more important than trying to prevent unauthorized disclosure altogether.

2. Source code leakage from outsourcing

In many cases,  source code leaks from a network run by an outsourcing service provider or from a team of outsourcing contractors connected via a VPN. However, if companies cannot detect problems in their own networks, they are unlikely to find them in others. The result is an outsourcing relationship built on a shaky foundation with no independent monitoring capability to enforce non-disclosure agreements.

This points at a wider problem for software developers everywhere. Whether you collaborate with a partner on development or outsource an entire project, you expose sensitive software and intellectual assets to people people with limited allegiance to your firm.

3. Misuse of Open Source software

This is probably worth an entire article in it’s own right but most developers today incorporate Free Open Source software into their projects. The Open Source license, if it’s GPL for example, may be infectious in the sense that if the GPL requires disclosure of sources, then incorporating GPL-licensed code into your project may require you to do the same (read about copy-left licenses).  In that case – you should start by establishing a policy for using Open Source licenses and monitor usage of Open Source code.

How can DLP (data loss prevention) help you protect your source code?

Data loss prevention (or in this case data loss detection) of software source code is based on three key concepts

  • A direct approach – prevent valuable software assets from getting out, unlike indirect methods that focus on preventing unwanted users from getting in. Conventional IT security takes an indirect approach by focusing on controlling user and system  behavior through access control and authentication. This indirect method places a heavy burden on your security staff and does not scale well. It won’t get the job done.
  • Real-time flow monitoring – of software assets over all channels. Since almost everything tunnels over http today, you have to worry about back-channels and not just email
  • Network audit – DLP should be used in a detection capacity to detect upticks in unusual activity; for example unusually large FTP or SCP file transfers may be a pre-cursor of an employee getting ready to leave the company with large quantities of your source code and proprietary algorithms

When deploying DLP for source code protection, consider technical and  business requirements.

Technical requirements. Commercial DLP products include pre-built fingerprints for identifying C/C++C# source code.  A more substantial requirement  is that the DLP solution you choose should use network DLP technology that is bi-directional on all channels – two possible candidates are Websense DLP and Fidelis Security Systems XPS.

Business requirements start with management commitment to the project, and policy for use of Open Source code and use of code and non-disclosure by contractors.

And finally, a post like this would not be complete without the requisite 7 step checklist:

A 7 Step check list for source code protection for the information security team

  • Acknowledge that black holes exist (for example: no policy for Open Source licensed code, unclear policy for use of company IP in contractor software development). Fix it by writing the appropriate policies and implementing them.
  • Get your VP Technologies to agree and budget money.
  • Identify your company’s business needs for source code protection. Some senior executives don’t care what you do – they only care about sleeping well at night. The more you know about their issues the easier it is to sell them. Don’t improvise.
  • If you’re not using bi-directional network DLP today, call a DLP vendor on Wednesday and ask them to come into the office on Monday with a box.
  • Give them one hour to set up on a production network segment. Try a few of your favorite cases; trap a webmail with some top-secret project keywords, fingerprint a SQL query from your data model, steal some C# source code from your own system and upload to github.com
  • Allocate one day for a hands-on evaluation and have the vendor in a week later to discuss results.
  • Be patient. Be prepared to refine the rules.

Using DLP technology to monitor movement of source code can be a rewarding exercise in terms of protecting company IP and reputation, however it is not a trivial task. Just remember:

It’s kinda fun to do the impossible -Walt Disney

Cross-posted from Israeli Software

Possibly Related Articles:
27037
Enterprise Security
Insider Threats Software Intellectual Property DLP Source Code
Post Rating I Like this!
Default-avatar
moin khan The only way to do this is either your code is so big that not a single programmer can write it, I am talking about million of LOC's eventually they can be written as well within the passage of time.

b) you pay your developers so much money like MSFT that they never want to go into another organization, if they do then we have the case of IRON PYTHON, and there is nothing any one did or can do legally about it.
1343444425
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.