White paper on Microsoft internal deployment of Active Directory Rights Management Services

Largely due to the demands exerted by many events that have occurred in the Exchange space, it's taken me some time to get around to acknowledge that Microsoft published an interesting white paper on TechNet describing their implementation of Active Directory Rights Management Services (ADRMS). The actual publication occurred in December 2011, so you can see that a lot has happened in between to stop me commenting. 

In any case, I think that this is an interesting document because it reveals some details of the templates that Microsoft has deployed to protect against the kind of information leakage that email facilitates so easily. In saying this, I realize that ADRMS and its associated components don't work as well inside companies that operate heterogeneous environments than it can when Windows is everywhere. Even so, we can learn from the observation of a deployment and put those lessons to use when it comes to answering questions about information protection in our own operations.

Companies have attempted to prevent users from doing things like forwarding confidential email outside the organization for at least twenty years. In the early 1990s, we were still in the transition from technologies like telex and fax as email became more pervasive. Although it’s possible to send a fax or telex to a wrong number, the number of incidents seemed low in comparison to the leakage that can accrue through email. In addition, the information provided in a fax or telex is relatively less usable than the data contained in an email or attachment.

Early efforts to control email focused on human behavior. Unlike today, it wasn’t usual for everyone in the company to have access to email and so it was easier to concentrate on the small pool of email users who might make an error and forward something that they shouldn’t, or, on a more sinister level, deliberately share a company secret with a journalist, competitor, or someone else who might benefit from the information. However, people are fallible and corporate directives on the correct use of email were often ignored.

Some companies attempted to implement email encryption as a way to prevent unauthorized access to information. Indeed, one of the big selling points for the first generation of Exchange in the late 1990s was its close integration with the Windows PKI infrastructure that enabled it relatively easy to distribute and manage the keys necessary to encrypt and decrypt messages. Relative is an important word here because although the deployment of encrypted email was absolutely feasible in terms of technology, it was a nightmare to manage and users didn’t comply. One major news company that I worked with attempted to deploy encrypted email and retreated after three months to a point where they simply asked senior management to protect Word and Excel attachments with a password that was “well known” within the company. The theory was that company users who received an attachment would know how to gain access to its content whereas external recipients would not. We certainly lived in a simpler world then!

Third party software vendors who offered different methods to protect email content have come and gone in the intervening period. None have been especially successful. I think this is because protected email can only be successful when:

It all seems simple enough. Select some technology to do the job, get senior management on board, and train users. In short, three simple steps to successful protection that any company can take.

So why have more not deployed information protection? And more specifically, why haven’t they taken advantage of the investment that Microsoft has made in software engineering to build a robust directory, the ability to deploy and manage templates that determine how people can use protected content, and to integrate protection into clients? I think the answer lies in two facts of corporate IT:

1. Most large corporations operate heterogeneous IT environments. Even though a lot of the infrastructure might be served by Windows, other operating systems have to be accommodated.

2. Insisting that the latest clients are deployed to facilitate information protection might be acceptable within a company that makes client software. But other companies regard desktop upgrades with all the enthusiasm reserved for molar extractions. Requiring Outlook 2010 everywhere to use a feature like Outlook Protection Rules is just a non-runner. And then there’s the slight matter of mobile clients and devices like iPhones and iPads that care less about ADRMS, yet are probably used by many of the executives that might leak the most confidential information.

Don’t get me wrong. I think that the technical implementation in ADRMS is very good and it works well with Outlook 2010 in particular. Microsoft has also done the work within Exchange 2010 to ensure that components such as Outlook Web App and transport rules support information protection. Much the same functionality appears to exist in Exchange 2013 Preview. And there’s no doubt that the implementation works well for Microsoft. On page 14, we learn that in addition to the standard “Do Not Forward” template, Microsoft uses custom templates called:

The names of the templates give you a good idea of the kind of protection that Microsoft applies to information sent to their FTE (Full Time Employees) and other communities. No data is given to indicate how much of Microsoft’s daily email traffic is protected and what template is used most often. However, there’s still a lot of very interesting and worthwhile information to be gleaned from this white paper that makes it a good resource for anyone who considers ADRMS as the basis for information protection.

Follow Tony @12Knocksinna