Monday, November 15, 2010

The Anti-Piracy Fiscal Maelstrom

There are recent reports of Microsoft spending upwards of $200M (yes, million!) a year on anti-piracy technology. See the New York Times feature article:

http://www.nytimes.com/2010/11/07/technology/07piracy.html?scp=4&sq=microsoft&st=cse

This is an astounding figure, particularly given that in general, Microsoft software is available at vastly reduced costs from the pirates.

While it may be tempting to conclude from this that software piracy is unstoppable, I thought I would share my perspective based on my company, Arxan’s, experience. Frankly, we've seen time and again that our technology (for instance), properly applied on top of a thoughtful design from a security perspective can and does stop piracy. We've had major successes in a wide variety of market segments, from low end extremely high volume gaming software, to very low volume but extremely high value geophysical software, and all kinds of interesting applications between those two extremes.

We are also familiar with failure. That's right, I'm not here to claim our solution is a panacea. It doesn't work that way. It's a continuous arms race in general, and on a software title by software title basis, it sometimes feels like hand to hand combat.

What we have learned is that a solid design in the security dimension is critical. A weak security design can't be easily "protected" later! A design that seriously considers the threats to the software in general, how those threats are directly mitigated by the design, and then on top of that, how the design and implementation itself is protected from undermining through reverse engineering and code tampering, is required.

Secondly, we've learned that you have to stay right on top of latest technique used by the cracking community. As an example, we are now to "anti-anti-anti-debug" techniques. That's right, we deploy anti-debug techniques...and the crackers have deployed anti-anti-debug techniques...and we are deploying techniques to detect those, hence "anti-anti-anti-debug".

It's a brave new world indeed!

Microsoft's piracy problems are complicated by the fact that they have such a broad array of products, from multiple disparate design and development teams, with different licensing schemes, different distribution models and a wide diversity of distribution channels. As anyone who attempts to run their business on Microsoft software knows, Microsoft does NOT look like "one company" when viewed through the lens of purchasing and licensing their software!

Few companies have the financial wherewithal for this level of security investment, both in absolute terms and even in 'relative to revenues" terms. For these companies, it's critical that application security be integrated into their product lifecycle, as a "must" design attribute. Letting a team rip on a major product development program, then starting to think about "how do we address this piracy problem?" after the product has been shipping for a few days, weeks or months is to take a step in the direction of Microsoft levels of relative spend. Don't do that! Just as reliability, usability, and supportability are, these days, critical requirements that are considered through the software product lifecycle, so must software security be considered and addressed.

The end result can be a secure, un-pirated product. We know this for a fact, we've succeeded with many customers in achieving this result. So don't end up staring down the tunnel of extravagant anti-piracy costs: think application security early, and often.