You would probably imagine that a company that writes and sells software would make the protection of that software paramount. That's why it's hard to believe that my company has implemented no comprehensive efforts to prevent its bread-and-butter software falling into the wrong hands.
Fortunately, upper management is finally getting a clue and has asked that we look into the technologies currently available for protecting our source code.
The need to do something is more pressing than ever. It's become trivial to find a place to store a gigabyte of source code (a good portion of our current software inventory), what with the availability of low-cost USB tokens, external hard drives and increased disk space on public e-mail repositories such as Yahoo and Google. Left unprotected, our source code could be moved offsite in less than 10 minutes.
And if clever programmers took the code, they could rebrand, reverse-engineer or replicate it and sell it for profit within a matter of days. If you think I'm exaggerating, recall that more than 800MB of source code from Cisco Systems' Internetworking Operating System was posted to a Russian Web site a year ago.
Our programmers use the open-source Concurrent Versions System to save and retrieve various versions of source code. CVS also lets teams of developers share control of different versions of files (source code) in a common repository. The problem is that once a developer checks out source code from the repository, there are no controls to prevent him from copying, moving or transferring the code to a storage device or an FTP site. As much as we'd like to trust our programmers, it's always possible that money or coercion could get someone to take advantage of the lack of controls. And regardless of such an event, a worm or other type of malicious code could be introduced to our internal network, compromise a user's desktop and give an outsider access to locally stored source code. I could go on for hours discussing the methods and motivations for stealing source code.
Fortunately, there are some fairly significant developments in the source-code protection market. One is software that gets installed on the developer's desktop and then inserts itself into the operating system in such a way that it prevents defined data from being copied, printed or transferred anywhere other than the source-code repository or a dedicated build server. What's nice about this type of technology is its ability to define which directories and files this protection should be applied to. That means that when developers checked out source code, they would be forced to maintain that code in a certain directory, from which they would be barred from copying, printing or transferring. However, they would be free to copy, print or otherwise manipulate other business-related data such as e-mail or other documents, which would be available in a different, non restricted directory. Some of the software in this market will also encrypt the defined data.
Looking at products
Microsoft and Adobe Systems both have robust offerings in this sector, but they seem to be product-centric. We need something that is product-agnostic, which can be used with data that originates from any company's product. One vendor that seems to have really good potential is Vormetric. Its CoreGuard product seems to address all our needs. It allows encryption, access control, integrity protection, alerting and reporting, and most important, it can be configured to be transparent to the user, letting the developers conduct business as usual.
Another interesting technology monitors network traffic for source code in the data stream. An example of this is a product from Tablus that crawls through your source-code repositories and uses special technology to analyze the data. Then, in way that's similar to how intrusion-detection software works, it monitors the network and watches the data stream for the "fingerprint" of the source code it has inspected.
No matter what approach we end up usingone of the main considerations will be the user experience. We'll have to do a considerable amount of testing to ensure that we don't impact a developer's ability to do his job. In our company, developers are treated like kings, since they write the software that brings in the big bucks. If a developer's ability to work is impeded, it could affect the product life cycle, which could hurt our ability to generate revenue.
Because developer workflow is such a high priority, the more passive option -- the network approach -- has merit. However, it won't prevent users from copying data to a local storage medium such as a CD-ROM or USB thumb drive. Perhaps the best way to secure our data would be a two-pronged approach in which we both protect the desktop and monitor the network. But that activity would have to be managed, and we're short-staffed as it is.
We'll probably start asking some of these vendors to come in and demonstrate their products, and then we'll start testing the products. At the end of the day, we hope to come up with an approach that satisfies our information security needs while still leaving our developers free to do their jobs. And if it works out well, we should be able to extend the technology we select to other departments such as legal, human resources and strategic planning.
"Mathias Thurman" IS a real security manager whose name and employer have been disguised for obvious reasons.