The Desktop Files Data Loss Prevention with Enterprise Rights Management
At my day job, I work for a company that makes a whitelisting application, which fundamentally reverses the typical security approach that protects your computer. There's another approach to security, perhaps also atypical, that I'd like to discuss this month—Enterprise Rights Management and why it's the only way to truly protect confidential information.
At this year's RSA Conference in San Francisco, I was walking the show floor, comparing the wares being offered by each of the vendors, and I have to say I was confounded. With very few exceptions, the vendors on the show floor were selling reactive—not proactive—security solutions. Let me explain. When you construct a building, you secure it by including locks on the doors and windows. If you want more security, you get an alarm system. Want even more? Add a fence. What you don't do to secure a building is leave out the locks, the alarm, and the fence, and just hire a guard or two to walk around. By itself, that won't protect anything.
Information Rights Management in the 2007 Microsoft Office system
Information Rights Management in Windows SharePoint Services
Windows Rights Management Services
Windows Server 2003 Rights Management Services
RMS: Protecting Your Assets
Windows Rights Management Services Partners
Thinking about Data Loss Prevention
Here's a more realistic example. I've had many customers ask about blocking USB ports to keep information from leaking out of their company (after we have eliminated concerns about inbound threats). But the reality is that trying to stop data flow at the port itself doesn't protect you at all. In fact, it's just like leaving a building completely unsecured, then hiring that guard. Sure, he's a nice guy—but he simply can't realistically cover all of the entrances and exits. At the end of the day, in both scenarios, it's the wrong tool for the job.
The problem with blocking access to the port—and with all of the other solutions that attempt to help you scan or secure your UNC shares, or do stateful packet inspection, or do other kinds of inspection—is that they all are reactive. They all try to catch the data as it leaves your organization. But by then, it's usually too late.
This reminds me of a scenario that used to occur at Microsoft (and I'm sure will sound familiar to you, as well). In the era before Information Rights Management (IRM) in Microsoft Office and Rights Management Services (RMS) in Windows, any interesting e-mail, even if clearly marked confidential, would be forwarded to the press by the end of the business day. Unfortunately, policies, strong words, packet inspection, share security, and even the threat of termination can only go so far. Something more is needed—and that something may just be the rights management technologies from Microsoft, which can help you protect your Office content. I've become a fan of IRM and RMS primarily, as I've grown to respect them as security solutions instead of merely auditing, monitoring, or compliance technologies.
What are the advantages of IRM/RMS in protecting Office content over ordinary password protection of that content?
- There are brute-force mechanisms that can compromise the password protection that is used by Office documents.
- Ordinary password-protected content is not encrypted in the same way that IRM/RMS-protected documents are.
- IRM and RMS work together to protect content at the lowest levels within Windows.
- IRM/RMS lets you protect content using very granular access controls, which are assigned to Active Directory accounts.
But what exactly are IRM and RMS? These technologies, first shipped with Microsoft Office 2003, allow you to protect intellectual property that is stored in Office documents, including e-mail read through Microsoft Outlook, Outlook Mobile Access, and Outlook Web Access through Internet Explorer, by encrypting the documents and controlling access to the content itself.
Most Office document types, including the new XML-based documents, as well as e-mail, can be encrypted, though .msg files (e-mail messages often attached to other e-mail messages) can't. (Visit office.microsoft.com/en-us/help/HA101029181033.aspx for a complete list of the file types you can manage with IRM.) The document is not decrypted until it is opened by a user who has been authorized by the originator of the document.
IRM is essentially the rights management front end, exposed through an RMS-enabled app, while RMS is the back end. An RMS server holds the information used to identify the rights that have been granted to users and verifies the credentials of those users. The IRM component in the RMS-enabled app lets you set and manage those rights. Together IRM and RMS allow authorized users to read, change, or exert full edit control over a document (depending on the assigned rights).
When an authorized user opens IRM-protected content through an Office application, the content is decrypted and made readable or editable within that application. Keep in mind that although IRM and RMS work to keep information secure, there is always the potential for a user who is truly dedicated to compromising it to do so. If a user elects to use the "analog hole" (a digital camera or other screen-capture software, or even to retype crucial information by hand), there is little that IRM can do to protect the information. For most scenarios, however, this is pretty strong security.
Building Blocks of Rights Management
The Microsoft rights management solution consists of four components that I'll cover in detail. I'll also briefly describe the RMS SDK and the useful RMS Toolkit. The first component is built-in; the others can be downloaded from microsoft.com/windowsserver2003/technologies/rightsmgmt.
Information Rights Management A component built into Microsoft Office 2003 and the 2007 Office system (as well as the mobile versions of Outlook, Excel, Word, and PowerPoint through Windows Mobile 6x), it lets users assign permissions to Word documents, Excel workbooks, PowerPoint presentations, InfoPath forms, Outlook e-mail messages, and XML Paper Specification (.xps) files, thus allowing or preventing recipients of those files from forwarding, copying, modifying, printing, faxing, cutting and pasting, and using the Print Screen key. You can set the permissions on a per-user and per-document basis.
In an Active Directory environment, you can also set permissions for groups, and if your organization uses Microsoft Office SharePoint Server 2007, you can set permissions on libraries (note that technically, content is decrypted when stored on SharePoint, then re-encrypted when served to users). Unless set to expire, IRM permissions remain with a document no matter when or where it is sent.
IRM is not available for Office versions for the Apple Macintosh, but there are ways for Mac users to utilize RMS-protected content. Stay tuned for next month's column for details.
Rights Management Services (Server) This is available for Windows Server 2003 and is an available role in Windows Server 2008. RMS server is the heart of the Microsoft Enterprise Rights Management. It takes care of certifying trusted entities (users, client computers, and servers), defining and publishing usage rights and conditions, enrolling servers and users, authorizing access to protected information, and providing the necessary administrative functions that allow authorized users to access rights-protected information.
Figure 1 shows the Server Manager screen that lets you install the RMS role on a Windows Server 2008 system. Though RMS has quite a few dependencies, the wizard will walk you through the entire process, installing all dependencies for you.
Figure 1 Selecting the Rights Management Services server role (Click the image for a larger view)
The RMS server role (on either Windows Server 2003 or Windows Server 2008) requires a server system with:
- Microsoft Message Queue Server (MSMQ)
- IIS with ASP.NET enabled
- Active Directory
- Either SQL Server Enterprise Edition (for a production environment), the Microsoft SQL Desktop Engine (MSDE), or SQL Server Express (fine for a testing environment)
As noted, even if you do not have any of these components installed, they will be configured for you during installation on Windows Server 2008. For a production implementation, you will want a valid SSL digital certificate for your server(s) so that RMS can properly maintain security between clients and servers. However, for testing, RMS can provide a test certificate installed as a part of the role installation. Figure 2 shows what the RMS console looks like running under Windows Server 2008.
Figure 2 The RMS console (Click the image for a larger view)
Rights Management Services (Client) This allows RMS-enabled applications to work with the RMS server to enable publishing and consuming of rights-protected content. The client is built into Windows Vista and Windows Server 2008; for earlier versions of Windows, it can be downloaded and installed to give those operating systems RMS capability.
If you're building out your own enterprise deployment, you will more than likely want to deploy the RMS client through new systems, Group Policy, or System Center Configuration Manager (SCCM) instead of having users deploy it manually.
Rights Management Add-on for Internet Explorer For Internet Explorer 6.0 and later, it allows you to view rights-protected content from inside Internet Explorer.
RMS SDK Allows developers to build their own applications that can protect their own custom content by using the SOAP-based Rights Management Services API.
RMS Toolkit You will probably find, as I have, that the RMS Toolkit is immensely useful in deploying and troubleshooting your own RMS infrastructure. The Toolkit contains a number of handy programs that can help you make sure your RMS system is working as it should. Note that the RMS Toolkit is not actually part of RMS and, as such, is not officially supported by Microsoft.
How Does It Work?
When you protect a document using RMS by clicking Protect Document under the Review tab in Word 2007 or Protect Workbook in Excel 2007, you must specify the account that you want to use as the author of the document—the account with ownership privileges on the document. This should ideally be an Active Directory account, though RMS does allow you to use a trial Windows Live account—which you may not want to use for an actual production system.
Once you've authenticated with an account (see Figure 3), you can specify that account or add accounts as the owner. Then, you can quickly specify high-level rights (see Figure 4) or more granular rights for users you want to have permissions to read or change the document you are protecting.
Figure 3 Specifying the account to use (Click the image for a larger view)
Figure 4 Setting permissions (Click the image for a larger view)
You have now protected the document. As a result, any users who attempt to open the document will have to provide credentials before it can be opened. Furthermore, the privileges defined by the owner of the document will be enforced.
RMS uses IIS and ASP.NET to authenticate any user who opens the document, to verify his identity and access rights, and to convey this information back to the RMS client and the IRM infrastructure in Office. Based upon Active Directory and the rights defined by the RMS server, the end user will either be allowed complete or limited access to the document, or none at all.
RMS uses an infrastructure that relies on XrML (extensible rights Management Language) to describe the rights held by end users of IRM-protected content. In effect, these rights are contained in an XrML license that can be attached to the digital content and thus persist. Because XrML is a standard, this language can also be used by other applications looking to protect content in a similar manner. You'll find more information at xrml.org.
Where Are the Holes?
As I mentioned earlier, RMS and IRM aren't bulletproof; if a malicious "authorized" user is dedicated to compromising IRM-protected content, it'll take some work, but he can do so.
Moreover, the content is potentially susceptible to interception by subversive malware and by screen-capture software working in non-standard ways. While RMS works hard to prevent screen captures and unauthorized cut-and-paste activity, it can only go so far. I have seen some solutions that attempt to go a bit further than IRM and RMS and protect additional content types. For other ISVs building solutions around RMS, see microsoft.com/windowsserver2003/partners/rmspartners.mspx.
Enterprise Rights Management is, I believe, the only rational way to truly secure content "not at rest" on systems today. If you examine the types of content compromised today—e-mail, Office documents, and so forth—most of them could be easily protected with IRM and RMS, but they aren't. While full-volume encryption technologies such as BitLocker in Windows Vista allow you to secure content at rest and to generally keep it secure in the event of a system compromise, they don't protect content that is on shares, on e-mail servers, or on SharePoint servers.
Because content generally can't be protected "in the wild," solutions have evolved that try to track content down and eliminate it. IRM and RMS were well designed to plug into Active Directory, Exchange, Office, and Windows—and as a result, don't take much of a training curve, especially for the end users actually consuming content—and the protection they can provide is immense. Please see the "Additional Resources" sidebar for more information.
Are You Protecting Your Assets?
Are you using RMS and IRM in your organization today? Send me your thoughts on RMS and IRM—I'd love to hear from some readers as to how and why you have (or have not) deployed RMS and IRM, or if you believe that your organization is secured from data loss through another mechanism.
Wes Miller is a Senior Technical Product Manager at CoreTrace (CoreTrace.com) in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager at Microsoft. Wes can be reached at firstname.lastname@example.org.