Drm

The Rights Management Dilemma

By Rich

Over the past few months I've seen a major uptick in the number of user inquiries I'm taking on enterprise digital rights management (or enterprise rights management, but I hate that term). Having covered EDRM for something like 8 years or so now, I'm only slightly surprised.

I wouldn't say there's a new massive groundswell of sudden desperate motivation to protect corporate intellectual assets. Rather, it seems like a string of knee-jerk reactions related to specific events. What concerns me is that I've noticed two consistent trends throughout these discussions:

1. EDRM is being mandated from someplace in management. Not, "protect our data", but EDRM specifically.
2. There is no interest in discussing how to best protect the content in question, especially other technologies or process changes.

People are being told to get EDRM, get it now, and nothing else matters.

This is problematic on multiple levels. While rights management is one of the most powerful technologies to protect information assets, it's also one of the most difficult to manage and implement once you hit a certain scale. It's also far from a panacea, and in many of these organizations it either needs to be combined with other technologies and processes, or should be considered after other more basic steps are taken. For example, most of these clients haven't performed any content discovery (manual or with DLP) to find out where the information they want to protect is located in the first place.

Rights management is typically most effective when:

1. It's deployed on a workgroup level.
2. The users involved are willing and able to adjust their workflow to incorporate EDRM.
3. There is minimal need for information exchange of the working files with external organizations.
4. The content to protect is easy to identify, and centrally concentrated at the start of the project.

Where EDRM tends to fail is with enterprise-wide deployments, or when the culture of the user population doesn't prioritize the value of their content sufficiently to justify the necessary process changes.

I do think that EDRM will play a very large role in the future of information-centric security, but only as its inevitable merging with data loss prevention is complete. The dilemma of rights management is that its very power and flexibility is also its greatest liability (sort of like some epic comic book thing). It's just too much to ask users to keep track of which user populations map to which rights on which documents. This is changing, especially with the emerging DRM/DLP partnerships, but it's been the primary reason EDRM deployments have been so self-limiting.

Thus I find myself frequently cautioning EDRM prospects to carefully scope and manage their projects, or look at other technologies first, at the same time I'm telling them it's the future of information centric security.

Anyone seen my lithium?

–Rich

Sorry, Data Labeling is *Not* the Same as DRM/ERM

By Rich

First, a bit of a caveat. Andrew Jaquith of Forrester is an excellent analyst and someone I know and respect. This is a criticism of a single piece of his research, and nothing more.

Over at the Forrester Security Blog today, Andrew posted a change of policy on their use of two important data security terms. In short, they will now be using the term Data Labeling instead of Enterprise Rights Management:

So, here's what Forrester will do in our future coverage. The ERM (enterprise rights management) acronym will vanish, except as a "bridge" term to jog memories. In the future, we will practice "truth in labeling" and call this ERM thing data labeling.

Unfortunately, this is a factually incorrect change since data labeling already exists.

I agree with Andrew that ERM is a terrible term -- in large part because I've covered Enterprise Risk Management, and know there are about a dozen different uses for that acronym. Personally, I refuse to use ERM in this context, and use the term Enterprise DRM (Digital Rights Management). Enterprise Rights Management is a term created to distinguish consumer DRM from enterprise DRM, in no small part because nearly everyone hates consumer DRM.

The problem is that data labeling is also a specific technology with an established definition. One we've actively criticized in the past. Andrew refers back to the Orange book:

Here's what the Orange Book says about data labeling: "Access control labels must be associated with objects. In order to control access to information stored in a computer, according to the rules of a mandatory security policy, it must be possible to mark every object with a label that reliably identifies the object's sensitivity level (e.g., classification), and/or the modes of access accorded those subjects who may potentially access the object." Sounds just like what what ERM is doing, no?

No -- the difference is under the covers. Data labeling refers to tags or metadata attached to structured or unstructured data to define a classification level. Labels don't normally include specific handling controls, since those are handled at a layer above the label itself (depends on the implementation).

DRM is the process of encrypting data, then applying usage rights that are embedded in the encrypted object. For example, you encrypt a file and define who can view it, print it, email it, or whatever. Any application with access to decrypt the file is designed to respect and enforce those policies... as opposed to regular encryption, which includes no usage rights, and where anyone with the key can read the file.

This shows the problem with consumer DRM and why it always breaks -- in an enterprise we have more control over locking down the operating environment. In the consumer world, the protected file is always in a hostile environment. Since you have to have the key to decrypt the file, the key and the data are both potentially exposed.

Labeling and DRM may work together, but are distinct technologies. You can label an individual record/row in a database, but you can't apply DRM rights to it (I suppose you could, but it's completely impractical and there isn't a single tool on the market for it). You can apply DRM rights to a file without ever applying a classification level.

I asked Andrew about this over Twitter, and our conversation went like this (Andrew's post is first):

@rmogull Really? Do you think "ERM" is actually a useful name for that category? Want to discuss alternatives?

@arj I use "Enterprise DRM" I also hate ERM and refuse to use it.

@rmogull Makes sense. Want to send me an e-mail (or do a blog post) critiquing the post? I'm a pretty good sport.

I think we are on the same page now, and thank Andrew for bringing this up, and being willing to take some gentle lumps.

–Rich

Kindle and DRM Content

By Adrian Lane

Rich forwarded me this article on Boing Boing regarding "Kindle Books having download caps" on content. That just shattered my enthusiasm.

A kind word of caution to Amazon: If you allow embedded Digital Rights Management content into Kindle media, your product will die. You are selling to early technology adopters, and history has confirmed they don't tolerate DRM. It's an anti-buyer technology, and the implementation requires (wrong) assumptions be made as to how a user want to use the device. History has also demonstrated that if you do push DRM with the content, the scheme will be broken, and people will do it just because they can.

If you are worried about getting content, and feel you need DRM to appease content owners of major publishing houses, don't. This is a very cool device, and content will come from thousands of sources, and people will find ways to use it you never thought possible.

–Adrian Lane

The State of Web Application and Data Security—Mid 2009

By Rich

One of the more difficult aspects of the analyst gig is sorting through all the information you get, and isolating out any inherent biases. The kinds of inquiries we get from clients can all too easily skew our perceptions of the industry, since people tend to come to us for specific reasons, and those reasons don't necessarily represent the mean of the industry. Aside from all the vendor updates (and customer references), our end user conversations usually involve helping someone with a specific problem -- ranging from vendor selection, to basic technology education, to strategy development/problem solving. People call us when they need help, not when things are running well, so it's all too easy to assume a particular technology is being used more widely than it really is, or a problem is bigger or smaller than it really is, because everyone calling us is asking about it. Countering this takes a lot of outreach to find out what people are really doing even when they aren't calling us.

Over the past few weeks I've had a series of opportunities to work with end users outside the context of normal inbound inquiries, and it's been fairly enlightening. These included direct client calls, executive roundtables such as one I participated in recently with IANS (with a mix from Fortune 50 to mid-size enterprises), and some outreach on our part. They reinforced some of what we've been thinking, while breaking other assumptions. I thought it would be good to compile these together into a "state of the industry" summary. Since I spend most of my time focused on web application and data security, I'll only cover those areas:

When it comes to web application and data security, if there isn't a compliance requirement, there isn't budget -- Nearly all of the security professionals we've spoken with recognize the importance of web application and data security, but they consistently tell us that unless there is a compliance requirement it's very difficult for them to get budget. That's not to say it's impossible, but non-compliance projects (however important) are way down the priority list in most organizations. In a room of a dozen high-level security managers of (mostly) large enterprises, they all reinforced that compliance drove nearly all of their new projects, and there was little support for non-compliance-related web application or data security initiatives. I doubt this surprises any of you.

"Compliance" may mean more than compliance -- Activities that are positioned as helping with compliance, even if they aren't a direct requirement, are more likely to gain funding. This is especially true for projects that could reduce compliance costs. They will have a longer approval cycle, often 9 months or so, compared to the 3-6 months for directly-required compliance activities. Initiatives directly tied to limiting potential data breach notifications are the most cited driver. Two technology examples are full disk encryption and portable device control.

PCI is the single biggest compliance driver for web application and data security -- I may not be thrilled with PCI, but it's driving more web application and data security improvements than anything else.

The term Data Loss Prevention has lost meaning -- I discussed this in a post last week. Even those who have gone through a DLP tool selection process often use the term to encompass more than the narrow definition we prefer.

It's easier to get resources to do some things manually than to buy a tool -- Although tools would be much more efficient and effective for some projects, in terms of costs and results, manual projects using existing resources are easier to get approval for. As one manager put it, "I already have the bodies, and I won't get any more money for new tools." The most common example cited was content discovery (we'll talk more about this a few points down).

Most people use DLP for network (primarily email) monitoring, not content discovery or endpoint protection -- Even though we tend to think discovery offers equal or greater value, most organizations with DLP use it for network monitoring.

Interest in content discovery, especially DLP-based, is high, but resources are hard to get for discovery projects -- Most security managers I talk with are very interested in content discovery, but they are less educated on the options and don't have the resources. They tell me that finding the data is the easy part -- getting resources to do anything about it is the limiting factor.

The Web Application Firewall (WAF) market and Security Source Code Tools markets are nearly equal in size, with more clients on WAFs, and more money spent on source code tools per client -- While it's hard to fully quantify, we think the source code tools cost more per implementation, but WAFs are in slightly wider use.

WAFs are a quicker hit for PCI compliance -- Most organizations deploying WAFs do so for PCI compliance, and they're seen as a quicker fix than secure source code projects.

Most WAF deployments are out of band, and false positives are a major problem for default deployments -- Customers are installing WAFs for compliance, but are generally unable to deploy them inline (initially) due to the tuning requirements.

Full drive encryption is mature, and well deployed in the early mainstream -- Full drive encryption, while not perfect, is deployable in even large enterprises. It's now considered a level-setting best practice in financial services, and usage is growing in healthcare and insurance. Other asset recovery options, such as remote data destruction and phone home applications, are now seen as little more than snake oil. As one CISO told us, "I don't care about the laptop, we just encrypt it and don't worry about it when it goes missing".

File and folder encryption is not in wide use -- Very few organizations are performing any wide scale file/folder encryption, outside of some targeted encryption of PII for compliance requirements.

Database encryption is hard, and not widely used -- Most organizations are dissatisfied with database encryption options, and do not deploy it widely. Within a large organization there is likely some DB encryption, with preference given to file/folder/media protection over column level encryption, but most organizations prefer to avoid it. Performance and key management are cited as the primary obstacles, even when using native tools. Current versions of database encryption (primarily native encryption) do perform better than older versions, but key management is still unsatisfactory. Large encryption projects, when initiated, take an average of 12-18 months.

Large enterprises prefer application-level encryption of credit card numbers, and tokenization -- When it comes to credit card numbers, security managers prefer to encrypt it at the application level, or consolidate numbers into a central source, using representative "tokens" throughout the rest of the application stack. These projects take a minimum of 12-18 months, similar to database encryption projects (the two are often tied together, with encryption used in the source database).

Email encryption and DRM tend to be workgroup-specific deployments -- Email encryption and DRM use is scattered throughout the industry, but is still generally limited to workgroup-level projects due to the complexity of management, or lack of demand/compliance from users.

Database Activity Monitoring usage continues to grow slowly, mostly for compliance, but not quickly enough to save lagging vendors -- Many DAM deployments are still tied to SOX auditing, and it's not as widely used for other data security initiatives. Performance is reasonable when you can use endpoint agents, which some DBAs still resist. Network monitoring is not seen as effective, but may still be used when local monitoring isn't an option. Network requirements, depending on the tool, may also inhibit deployments.

My main takeaway is that security managers know what they need to do to protect information assets, but they lack the time, resources, and management support for many initiatives. There is also broad dissatisfaction with security tools and vendors in general, in large part due to poor expectation setting during the sales process, and deliberately confusing marketing. It's not that the tools don't work, but that they're never quite as easy as promised.

It's an interesting dilemma, since there is clear and broad recognition that data security (and by extension, web application security) is likely our most pressing overall issue in terms of security, but due to a variety of factors (many of which we covered in our Business Justification for Data Security paper), the resources just aren't there to really tackle it head-on.

–Rich

DRM In The Cloud

By Adrian Lane

I have a well-publicized love-hate opinion of Digital Rights Management. DRM can solve some security problems but will fail outright if applied in other areas, most notably consumer media protection. I remain an advocate and believe that an Information Centric approach to data security has a future, and I am continually looking for new uses for this model. Still, few things get me started on a rant like someone who says that DRM is going to secure consumer media, and DRM in the Cloud is predicting just that.

New box, same old smelly fish. Be it audio or video, DRM secured content can be quite secure at rest. But when someone actually wants to watch that video is when things get interesting. At some point in the process the video content must leave its protective shell of encryption, and then digital must become analog. Since this data is meaningless to someone unless they can view it or use it, at some point this transition must take place! It is at this transition point from raw data to consumable media when the content is most vulnerable- the delivery point. DRM & Information Centric Security are fantastic for keeping information secret when the people who have access to it want to keep it a secret. They are not as effective when there is a recipient who wants to violate that trust, and fail outright when that recipient has control of the software and hardware used for presentation.

I freely admit that if the vendor controls the hardware, the software, and distribution, it can be made economically unfeasible for the average person to steal. And I can hypothesize about how DRM and media distribution can be coupled with cloud computing, but most of these examples involve using vendor approved software, in a vendor approved way, over a reliable high speed connection, using a 'virtual' copy that never resides in its entirety on the device that plays it. And a vendor approved device helps a whole lot with making piracy more difficult, but DRM in the Cloud claims universal device support, so that is probably out of the question. But at the end of the day, someone with the time and inclination to pirate the data will do so. Whether they solder connections onto the system bus or reverse engineer the decoder chips, they can and will get unfettered access- quite possibly just for the fun of doing it!

The business justification for this effort is odd as well. If the goal is to re-create the success of DVD as stated in the article, then do what DVD did: twice the audio & video quality, far more convenience at a lower cost. Simple. Those success factors gave DVDs one of the fastest adoption curves in history. So why should an "Internet eco-system that re-creates the user experience and commercial success of the DVD" actually recreate the success of DVD? The vendors are not talking about lower price, higher quality, and convenience, so what is the recipe for success? They are talking about putting their content online and addressing how confused people are about buying and downloading! This tells me that the media owners think that they will be successful if they move their stuff onto the Internet and make DRM invisible. If you think just moving content onto the Internet alone makes a successful business model, tell me how much fun it would be to use Google Maps without search, directions and or aerial photos- it's just maps taken online, right? Further, I don't know anyone who is confused about downloading; in fact I would say most people have that pretty much down cold. I do know lots of people who are pissed off about DRM being an invasive impediment to normal use; or the fact they cannot buy the music they want; or things like Sony's rootkit and various underhanded and quasi-criminal tactics used by the industry; and the rising cost of, well, just about everything. Not to get all Friedrich Hayek here, but letting spontaneous market forces determine what is efficient, useful, and desirable based upon perceived value of the offering is a far better way to go about this. This corporate desire to synthetically recreate the success of DVDs is missing several critical elements, most notably, anything to make customers happy.

The "Cloud Based DRM" technology approach may be interesting and new, but it will fail in exactly the same way, for exactly the same reasons previous DRM attempts have. If they want to succeed, they need to abandon DRM and provide basic value to the customer. Otherwise, DRM, along with the rest of the flawed business assumptions, looks like a spectacular way to waste time and money.

–Adrian Lane