Information Security

Defending the digital infrastructure


Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Enterprise digital rights management best practices

EDRM brings users into security more than any other tool. Are you ready?

Enterprise digital rights management is one of the most powerful data security tools in our arsenal, but it's also one of the most complex and difficult to integrate into workflows. Also called enterprise rights management and information rights management, it allows an organization to set granular, highly secure policies around who is able to read, change or share sensitive documents. Unlike many of our other data security tools, EDRM is embedded in our documents, and thus protects the data no matter where it moves.

But this power comes with a cost—and not merely the pricetag. Such granularity can be difficult to configure, and such portability difficult to integrate into your environment. EDRM today also relies heavily on user interaction, which means workflow changes; and anytime you change the way a user performs their job you face serious adoption friction.

As a result we often see enterprise digital rights management deployed at the workgroup level, where it is highly effective at protecting the most sensitive of documents. By following these best practices collected from dozens of EDRM users, you can ease deployment friction and increase the success of your project.

How enterprise digital rights management technology works

Although EDRM shares the same fundamental technology base as consumer DRM, in practice it's a very different tool that's far more effective at protecting your data.At the core, all DRM is based on a simple principle--you encrypt the data and then wrap it in policies to assign usage rights.Only applications that will enforce the rights are given access to the key and are able to decrypt the data. The rights (e.g. who can read a document or cut and paste from it) are embedded as encrypted metadata and enforced by the application, or, more commonly, plugins.

When most people hear DRM they instantly think of the consumer systems that impede our ability to access and use music, movies, and other digital media. At least until the system is broken by some enterprising young hacker, as has happened to every single consumer DRM system ever created. But although enterprise DRM shares the same basic technology, its implementation in practice is very different.

Consumer DRM never seems to last long due to the mathematics involved. You take highly popular content, protect it with an encryption key, and then send the entire package out to millions or billions of consumers. Eventually someone figures out how to extract the key, breaking the security, and often extracts the root key used to protect the DRM system itself out there on millions of devices. It's then impossible to fix the system since doing so will break every device already sold, and only protect new content.

EDRM is different since the math is simpler. You are protecting your data for your users, which means the potential audience (even accounting for every competitor out there) is far smaller. EDRM systems also use different keys for different organizations, and can fix breaks (if there are any) with software updates that don't break a few million consumer devices. Basically, there are fewer users, fewer potential attackers, and more options for managing, distributing, and rotating keys. Thus EDRM is much more effective at protecting content.

EDRM systems consist of five main components:

1. A policy management server.

2. Key manager (which can be part of the policy management server).

3. Directory server integration (to understand users and groups).

4. Endpoint client.

5. Application plugins.

We’ll focus on internal EDRM deployments--if you need to exchange documents with other organizations, the architecture changes a bit.

Functionally, the process works like this (This example simplifies the key exchanges and background processes to focus on the workflow):

1. The user is granted access to the EDRM system and client software and plugins are installed.

2. The server issues digital certificates to identify the user and support local encryption/decryption and use of documents.

3. The user attempts to open a protected file. The client checks the license embedded in the document to see if it has the rights to open the document based on the user and machine. This may require an online connection depending on how the rights were assigned.

4. If the rights match, the document is decrypted (in memory) for local use. The client and application plugins enforce additional rights, such as disabling copy and paste.

5. If the user creates a document, they assign who can access the document and the usage rights. The usage policy is created, added to the document, and it is encrypted with the appropriate keys.

Even this simplified overview is a somewhat complex process involving a mixture of public and private key cryptography, chains of trust, multiple digital certificates, application plugins and endpoint clients. But to be honest all of those are straightforward technology problems, many of which are embedded in the various products. The real inhibiting factors tend to be users--muddy directory servers, employee workflows, and changing habits.

But by setting the right expectations, using EDRM in the right circumstances, and properly preparing your infrastructure you can improve the scope of your project and its chances for success.

Define requirements and set expectations

EDRM is an extremely effective security control, but can be difficult to manage since it requires users to change how they work with, and create, documents. The majority of successful EDRM projects happen at the workgroup level; typically with users (such as engineers) who understand the value of the documents they work with.

Thus it's important to determine your requirements and set the right expectations. Asking the following questions will help you define your requirements and determine which user populations are ripe for EDRM:

1. What information do we need to protect? You can't apply EDRM to all your documents, so you need to define what specific information is your target.

2. Which business units create the content? These are the users who will have to apply the rights.

3. Which business units consume the content? What rights do they need?

4. Which backend systems consume the content? If there is any automation (e.g. consumption of spreadsheets) these systems will also need access and client/application support.

5. What file types and applications create and consume the content?

These set your baseline requirements:who needs to apply rights, access the content, and the file types applications and platforms involved. Then ask yourself if your goals are realistic. Can you train the content creators to properly apply rights? Are there shortcuts you can take (like assigning rights to everything in a shared directory by default)? Will usage rights break essential business processes? Can we support all the applications and file formats we need to? These are most definitely not the sorts of things you want to figure out after buying the software.

Clean, organize directory servers

One of the biggest technical obstacles to EDRM is dirty directory servers, the kind where users and groups don't neatly map to physical users, business units, and job roles. You can't allow engineering to edit and email documents and marketing to only view them if you previously mixed engineering and marketing users in your directory.

Before even installing your EDRM tool, clean up your directory servers. If this isn't realistic for the entire organization, focus on those teams/units that you identified as needing EDRM when you developed your requirements.

Map workflows, and mind the gaps

The next step is to map the specific workflows already using the sensitive information to ensure that your tool is even capable of supporting your needs. Will it support all the applications and file types involved? Can you define a rights scheme consistent with your existing process? Are there any coverage gaps

This time you most definitely won't want to start with more than a single business unit. Go back to your initial requirements and pick the one that offers the best mix of priority and likelihood of success. That usually translates to sensitive data used within a small, technology-savvy user population.

It's okay if you need to change how users interact with content, but remember that you increase friction and resistance with every alteration to existing workflow. EDRM projects succeed when the tool is smoothly integrated into existing workflows, or introduce changes that don't interfere with someone getting their job done. If the EDRM impedes their ability to do what they're paid for, they will find a way around it (or complain enough to get it turned off).

Build effective policies and templates

One of the best ways to ease the process for your users is to provide them a convenient set of pre-defined policies they can easily pick from, as opposed to having to figure out all the usage rights themselves. Different EDRM products handle these differently, so some of our general guidance might not exactly fit your tool's capabilities:

1. Match the policies to workflow and security needs- if the policy is too restrictive, employees will try to circumvent it (or pick a less-secure option). If it's too loose, it won't help with security.

2. Group policies by business unit/function. Users shouldn't have a massive list of every policy within the organization--group them so workers can quickly find what they need.

3. Don't write too many. Realistically employees will only use a small set of policies, even if you provide a large, confusing list. Focus on the most important information categories and use cases.

4. Use plain-language names. A policy named, "Confidential- Red Zone 3" is much less likely to be used than, "Engineering Plans".

5. Include group/role information in policies. Some organizations ask users to select the policy and then the target recipient group (e.g. "accounting"). These should both be defined in the template to save the worker from an extra step.

If your product supports it (and most do), you can build template sets that apply to different user groups. Simple, clear, easy to find, and relevant to their job are the names of the game to achieving user acceptance.

User education needs to be relevant; create documentation

At this point you should have everything aligned to start engaging the users. Rather than throwing it at them and having them sign a new data classification policy, go with a serious education program. Your employees need to understand the importance of protecting the information and how to easily integrate it into their workflow. Walk them through specific examples relevant to their job (which means different training for different workgroups), and include no shortage of documentation with screenshots and videos.

Education shouldn't be a one-shot deal. Establish a training plan which includes short review and Q&A sessions after the initial training, plus periodic reviews and inclusion in new employee onboarding (if they are in a supported business unit).

And again,the simpler the better.

Automate as many EDRM processes as possible

Depending on your tool you may also be able to automate part of the process. For example, many tools support automatically assigning rights to files saved in specific directories (local or shared). This means the user never has to think about applying the policies manually.

One bleeding-edge feature that's starting to appear is the combination of EDRM with data loss prevention (DLP). The DLP tool performs content analysis on the file, and then automatically applies rights depending on what data it finds inside (e.g. healthcare or financial data). While this is available on the market, it's still very early with few customer references.

The most important best practice is to take things slowly. Enterprise digital rights management is an extremely powerful technology, but one with the potential to materially disrupt how employees get their jobs done. You should start your rollout by focusing on easy to define content used by a more-technical user population that's more likely to understand the importance of the tool, and how to adopt it into their day to day workflows.

Most of the successful programs we've seen treat the rollout as a series of smaller projects tailored for individual workgroups. This eases user friction, reduces disruptions on business activities, and allows you to secure your most important information while eventually training the entire organization over time.

Rich Mogull has nearly 20 years experience in information security, physical security, and risk management. Prior to founding independent information security consulting firm Securosis, Rich spent seven years at Gartner Inc., most recently as a vice president, where he advised thousands of clients, authored dozens of reports and was consistently rated as one of Gartner's top international speakers. He is one of the world's premier authorities on data security technologies, including DLP, and has covered issues ranging from vulnerabilities and threats, to risk management frameworks, to major application security. Send comments on this article to


Article 3 of 7

Dig Deeper on Data security strategies and governance

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Information Security

Access to all of our back issues View All