Tag Archives: Outsourcing

Using DLP to protect your source code

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

  1. 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.
  2. 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
  3. 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

  1. 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.
  2. Get your VP Technologies to agree and budget money.
  3. 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.
  4. 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.
  5. 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
  6. Allocate one day for a hands-on evaluation and have the vendor in a week later to discuss results.
  7. 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

Tell your friends and colleagues about us. Thanks!
Share this

Network surveillance

Most companies have reasonable  perimeter security – i.e. a firewall and IDS (intrusion detection system) or IPS (intrusion prevention system).   Although  security people often view an IPS as the next generation of IDS; it’s important to distinguish between the roles of detection and prevention. Detection helps you understand what kind of attacks are being mounted (or potentially COULD be mounted on the network, and prevention (an IPS) is an access control security countermeasure – a way of keeping the bad guys off your network.

However, in my experience,  the same companies with well-managed firewall/IPS don’t have the foggiest notion of what’s leaving their network or what’s happening inside the network.

There is nothing like collecting data and validating the effectiveness of your security countermeasures.

This is why we need network surveillance.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this

Seven software development mistakes not to make in 2009

One thing that is burnt into my personal flash memory from 7 years at Intel is working in Plan 2009 in September/October. This time of year, I start thinking about how we can survive and grow the business.

We all like to think we learn from mistakes, however, recent experiences reminded me that the software development environment of 10 years ago is radically different today. Development tools are free, hardware is almost free (think about those $100k Sun Enterprise 450 boxes and $300 Sun Ethernet NICS) and programming talent is a global resource. Its  much easier to develop software today but that is insufficient. A development team can write lots of code but there is no replacement for a development lead that manages the team; keeping things simple, hiring the best people and keeping them challenged.

7. Don’t KISS

If my experience is any indication – the software industry billions of dollars a year by not Keeping It Simple. Complex 3 tier technologies with Java J2EE are probably not warranted for the majority of Web applications. While not fashionable,PHP is far simpler to program and maintain, and provides excellent scalability at lower cost than Java – witness the millions of Yahoo pages are served by PHP each day. Lack of KISS is the main reason for high-costs, late schedules, failed projects and unsecure software that no one can maintain.

6. Mismanage software development

The classic book,The Mythical Man-Month, written 20 years ago revealed that projects based on per-unit man-months usually don’t work due to the unique nature of software development. The difference in productivity between the best programmer and an average one is 100x. This means that 5 new college grads will be less effective than 1 talented programmer who knows what she’s doing. You are always better off with a few strong programmers than a large cast of cheap developers, a) because of individual productivity differentials and b) because smaller groups are always more effective.

5. Take a wrong turn with outsourcing

Don’t outsource something just because it’s too hard to understand or because your CFO reckons he can save money by selling your IT staff to IGS or contracting offshore. A U.S client we know went to India for software development. The Indian market was booming and job loyalty was low, like Israel and Silicon Valley in the 90’s. Due to transportation and cultural issues the work day was 8 hours not the 18 that most of us still remember. The client also needed direct involvement with the offshore team that required frequent travel to India. The client got marginal savings of less than 20%, longer delivery times and cryptic documentation.

4. Promote or hire the wrong people

I could write a book about this one. A common case is the excellent technologist who is promoted (desiring the job) into a managerial spot. He doesn’t have the people skills, won’t admit failure and can’t visualize going back to his old programmer slot. Another common case is hiring an ex-military guy to run a young engineering team. Six months later after the team has disintegrated, the board realizes that you can’t hand orders to programmers like soldiers and you can’t flirt with the lady engineers and ask them to fetch the boss coffee.

3. Decide based on religious beliefs

A client decided on Open Source and Linux, going with a leading commercial distribution, PHP and a large systems integrator believing that the combination of Open Source and reliable leading vendors would guarantee success. The integrator’s skill set was primarily Windows, the distro vendor could care less about the fundamental flaws in the client’s design, and the client was weak on Linux and PHP and couldn’t audit the integrator’s work. After a 12 month overrun, the project was scrapped and $300,000 was written off. Cool technology is not a substitute for know-how and good program management.

2. Ignore internal security threats

IT managers that focus on intruders get into a sense of false security. According to the FBI, 70 percent of security incidents that cause financial loss are inside jobs, making the insider threat arguably the most critical one facing the enterprise. In many cases,weak policies and human error can create a threat to the I.T operation, for example in the case of the computer operator who saved a file called server_passwords.xls in the MyDocuments folder of his PC in the computer room. For more examples read The Story of Insider Theft

1. Permit weak passwords

Threats such as worms get top PR but dont miss a basic IT mistake: weak authentication or bad passwords. Common password vulnerabilities include weak passwords (birthdays),publicly displayed passwords on Post-its, and Intranet and server administrator passwords that the whole firm knows. We recommend using long passphrases (like “Meeting attractive women with open source“), that resist dictionary attacks and are much easier to remember than traditional strong passwords (like “Xh67RC41“)

Tell your friends and colleagues about us. Thanks!
Share this