Microsoft RMS: Standard or Stranglehold?

Posted by Sanford Bingham

 

pdf.pngSave a print-friendly version of this post (PDF)

 

“Standards allow different layers to evolve independently and therefore faster and better.”

- Sir Tim Berners-Lee, Founder and Director of the W3C

 

The World Wide Web is built upon standards, at every level. Because of Web standards, users can access information from multiple different browsers on a variety of platforms and operating systems, and organizations can choose from a diverse set of servers and databases to host content. This arrangement has worked well for more than twenty years, encouraging innovation and competition—as long as the information being served is intended to flow freely and without restriction. However if the contents’ owners want to control access to their information through encryption and authentication, the interoperability of the Web breaks down. The means of decrypting content for secure viewing has always required a separate, proprietary viewer or plug-in, because there is no Web standard for rights management at the file level.w3cSmall.png

Opinions differ on the wisdom and feasibility of implementing DRM for consumer content on the Web (although the channeling of rights-managed content into closed platforms such as Amazon Kindle and Apple iBooks has rendered opposition somewhat futile), but the absence of a security standard in the enterprise has created a vacuum into which a private corporation (namely Microsoft) could come to dominate the creation, distribution and consumption of information from end-to-end. Imagine a scenario in which the entire document workflow of the Fortune 1000 is beholden to a single vendor for its authoring applications, user identity management, decryption keys, usage data and other private and proprietary information.

Aside from wiping out entire categories of cloud storage platforms and security vendors, a private monopoly in rights management technology would prevent its customers from choosing among workflow and server technologies, and put their data at risk of a potentially catastrophic security breach if any vulnerabilities were exploited. The vast majority of encrypted documents would be secured with a single proprietary method. Further, such a monopoly would threaten the fundamental framework of the Web, which was originally designed to enable servers and clients on different platforms, from different vendors, to speak to each other in a common language. Without a published standard for handling encrypted documents on the Web, it becomes possible, even necessary, to limit usage to a single viewer or editor—the one sold by the same vendor of the productivity suite, identity framework and encryption tools.

 

The Mirage of Cloud Security

How could we be at risk of a rights-management monopoly, when the cloud era has disrupted incumbent vendors and the dominant players now encourage integration via open APIs? In his blog post from 2013 “The Rise of The Cloud Stack,” Aaron Levie of Box proclaimed “From this diversity of systems, customers will get choice, and with this choice we’ll see better applications and solutions emerge. At a lower cost, and at a higher quality.” The cloud stack was supposed to free us from single-vendor “ecosystems” so we could migrate between increasingly sophisticated platforms. But as we will see, the lack of a standard document security protocol has instead resulted in a Babel-like city of secure towers that don’t speak the same language, and therefore can’t interoperate.

cloud-platforms.png

First, let’s look at how cloud services handle user identity management, because any workable rights management scheme depends on user identity to determine whether or not to decrypt a file. One of the keys to the evolution of the cloud stack is the availability of what Gartner Group has named Identity and Access Management as a Service (IDaaS). Using an IDaaS service, a company can create a Single Sign-On (SSO) system for a variety of different, and often interconnected, cloud applications. With a single login, a user might now update a record in Salesforce, triggering an alert in Slack, updating a spreadsheet in Google Docs and a report in Box.

From the perspective of a network administrator, it is necessary that these new workflows also be auditable and their use controlled. So the “Access Management” part of IDaaS has become an important new element of the information security toolkit. In the example above, it is also critical that the administrator be able to revoke access to all the applications in that workflow all at once. In the current environment the granularity of IDaaS is normally at the application level; i.e. the IDaaS vendor controls access to the cloud provider itself, with that cloud provider managing access internally based on the identity provided.

In some cases, the cloud vendor may implement access control at the document-level, but the identification and permissioning of documents is specific to that environment. That is, there is no mechanism exposed by IDaaS vendors by which a document exported from Google Docs and imported into Box or Dropbox can be tracked or controlled as it moves from one environment to the next. Every cloud provider that offers some form of DRM is an island, and every protected document is trapped on that island.

 

RMS: Bundling Security and Identity

If there is no standard for document-level security in the cloud, what about behind the firewall, in the enterprise? There are multiple competing approaches to Enterprise Document Rights Management (EDRM), including the one developed by my company, FileOpen Systems. Each is functionally a silo; there is no standard for DRM interoperation. Among the EDRM solutions, the largest (by installed base or market share) and best-known framework is Microsoft Rights Management Services (RMS). It can certainly be argued that RMS is the de facto standard for controlled distribution of MS Office documents; the question is whether it can or should be the basis of a more formal web standard.

Microsoft RMS is a framework for DRM implemented natively in the Microsoft Office suite of products and also by third parties for some PDF viewers. The RMS software was introduced in 2003, evolving from and ultimately replacing an eBook DRM system, Microsoft Reader, which was introduced in 2000 and discontinued around 2007. Today RMS is predominantly, perhaps exclusively, focused on enterprise use-cases and workflows. The functionality was originally bundled into Windows Server 2003 and remains a part of the core Windows Server product. The RMS system is also tightly integrated with Microsoft's Active Directory product, indeed is formally named "Active Directory Rights Management Services" (AD RMS).

RMS-workflow.png

The tight integration of RMS with Windows Server has impeded adoption by entities not primarily using the Microsoft stack; RMS cannot be implemented directly in environments using Linux, or other Unix derivatives, at the server. Further, the reliance upon Active Directory has reduced the utility of the system for external document distribution, insofar as the Active Directory environment of the document creator and that of the document consumer are rarely integrated. Microsoft is now addressing this concern via the federation of Active Directory networks using Azure Active Directory (Azure AD) and the cloud version of RMS (Azure RMS). These cloud-based systems for identity management and DRM are intended, among other things, to simplify the process of distributing encrypted content outside the firewall.

Microsoft has also integrated the RMS functionality into a number of clients on desktop and mobile platforms, under the banner “Office everywhere, encryption everywhere.” This initiative addresses both document security in the MS Office suites and message security in the Microsoft mail clients, via S/MIME. Viewing of RMS-protected documents on iOS can now be done in third-party viewer applications or with Azure RMS in the Microsoft Office applications for Mac, iOS and Android.

Support for PDF files in the RMS environment is implemented via partners, including Foxit, Nitro and Nuance, and in Adobe Acrobat/Reader via a plug-in from GigaTrust. RMS-encrypted PDF cannot be opened in the Microsoft Reader application, which is the default handler for PDF on Windows 8.1 and later, nor by the embedded PDF viewer in Microsoft Edge (or any other browser).

 

Standard or Stranglehold?

The presence of the RMS client in the primary Microsoft Office applications enables workflows in which effectively any user can distribute encrypted content to any other user, without a requirement that either install new software. No other DRM system can make that claim. And while this situation is reminiscent of Microsoft’s bundling of Internet Explorer with Windows, which was ultimately sanctioned by the US courts, the integration of Microsoft’s DRM into Microsoft’s Office applications has not been the subject of any antitrust actions. So it is likely that the bundling will continue, and continue to be an advantage for Microsoft in the enterprise, as long as Office remains the primary vehicle for document creation and collaboration.

Similarly, the bundling of RMS with Windows Server and Active Directory is not optional, as the RMS functionality depends upon proprietary logic in the Microsoft Server stack. Use of RMS with any alternative webserver is not supported. We assume that Microsoft tightly integrated the RMS client and server functionality in order to increase the security and reliability of the system rather than as a competitive strategy, but the result is indistinguishable. There is no set of APIs and no licensing framework that would permit an independent vendor to create an alternative to the Microsoft implementation of RMS in Windows Server, or a cloud service that could be used as a replacement for Azure RMS.

While the original on-premises version of RMS required use of Active Directory for identity provision, the Azure RMS product offers the option of a federated identity mechanism, meaning that other IDaaS vendors can be integrated into an RMS workflow. However, by design, all DRM interactions involving the Azure RMS client/server exchange require a token from the Azure RMS server. So while an alternative identity provider may be provisioned, there is no mechanism in either RMS or Azure RMS for that identity provider to also manage the permissions on the document. In short, the RMS client and server cannot be decoupled.

openvsclosed.png

As a result of these Microsoft design choices, it is not possible for an entity that chooses not to use Microsoft Server to implement RMS inside the firewall, nor is it possible for an entity using Azure RMS to operate with full independence from Microsoft. An IDaaS vendor can provide primary identity management, but cannot independently provide access control at the document level, as this capability necessarily involves the sharing of user and client data with Microsoft.

 

An Alternative: Standards-Based DRM

Microsoft’s approach is fundamentally at odds with the core design of the World Wide Web, which is premised on the loose coupling of client and server functionality. It is, for example, inconceivable today that a browser vendor would attempt to require use of a particular, and proprietary, server in order to implement SSL. An entity publishing data on the World Wide Web today can exert complete control over the code used at the webserver, to the point of having the option to write that code anew in any language and run it on any hardware, provided that the result properly implements the required protocols, all of which are public.

It follows that any attempt to create a standard system for DRM on the World Wide Web would, at a minimum, need to support this degree of client/server independence. However, DRM systems are rarely designed around open interfaces, at least partly due to a tendency to think that the most secure system is one in which the developer has control over both ends of the client/server interaction. Moreover, DRM differs from standard cryptographic implementations because one side of the interaction, the client, is not necessarily a willing participant in the secrecy of the conversation, and indeed may be an adversary.

So a completely open source DRM system is likely to be impossible. What can work, as demonstrated by the implementation chosen for the W3C Encrypted Media Extensions (EME), is the combination of a compiled binary client library and an open interface to an arbitrary key management system. EME is now embedded in multiple applications and platforms, and allows content distributors to manage protected video files using one or a combination of key management and delivery systems (Google Widevine, Apple FairPlay, Microsoft PlayReady, Adobe Primetime, etc.)

 

The FileOpen Rights Management Layer

The original design of the FileOpen DRM software, first articulated in 1997, described the same general architecture. FileOpen rights management was explicitly designed to work with any external identity provider, and to permit the entity encrypting documents to specify all relevant metadata (e.g. document identifiers, encryption keys). In the company’s early years, the only way to implement FileOpen software was to develop a custom server to manage customer and document identities and to implement business logic governing usage. Today, commercial "PermissionServer" implementations are available in .NET and PHP, and multiple cloud services are built around the FileOpen Client and protocol, which is published.

The architecture of FileOpen rights management is such that is not tied to any particular document format or viewing application. This differs markedly from Microsoft’s approach, which developed RMS for its own Office applications and has demonstrated a clear bias toward those applications with respect to competing tools (e.g. LibreOffice) and formats (e.g. PDF). We believe that decoupling the rights management protocol from the document format and viewer vendor enables organizations to share documents securely with the broadest set of users, inside and outside the firewall. It also protects publishers and document creators from a potentially costly “lock-in” to the format vendor, who would control the keys to encrypted documents and store private data about their end-users.

FileOpenCloud.png

Moreover, because the FileOpen software does not rely upon any particular identity provider, it can be implemented natively by any IDaaS vendor. All such implementations are independent and private, in the sense that information about users/documents/permissions is fully controlled by and visible only to that vendor. Interoperation between IDaaS implementations, or between IDaaS vendors and cloud application providers, or between different cloud application providers, is likewise possible without direct involvement of FileOpen Systems, using the published interfaces of the system.

While FileOpen rights management is not yet a standard, it was designed and continues to be developed around the principles that underlie Web standards. In fact, one of the first and largest sectors to standardize on the FileOpen software is the community of Standards Developing Organizations (SDOs; e.g. ANSI, ASME, Afnor, DIN, etc.). Ultimately, the FileOpen software was designed not to be an end-to-end secure publishing system, or even a complete system for DRM, but a flexible component that can be integrated to extend the functionality of such systems--one thread in a larger, interconnected, Web.

 

Learn more about FileOpen rights management architecture and implementation options for Microsoft Office documents

Contact us for a demo of FileOpen Rights Management for Office

 

 

Topics: document control, drm, Rights Management, cloud, Microsoft RMS

How to Track Printed Documents Using FileOpen Dynamic Watermarks

Posted by Diana Holm

When Adobe announced the PDF file format as an open document standard in 1993, it was meant finally to usher in the era of the “paperless office.” Despite the success of PDF as a platform-independent document format, we are still printing to paper—a lot. According to The Paperless Project, paper usage is increasing in American businesses at a rate of 22% a year, and the average office worker uses a “staggering” 10,000 sheets of copy paper annually.watermark200.png

This poses a unique challenge to publishers, who increasingly depend on the usage data and analytics which digital documents can provide, but not printed documents. For example, if a publisher sells a subscription of valuable research reports to one employee at a company, how do they know that employee isn’t printing out hundreds more copies, depriving the publisher of that additional subscription revenue?

Encrypting those research reports so that only the original subscriber can access them makes it harder for a user to share access to the digital version. FileOpen makes it possible to disable printing entirely, but if you allow the document to be printed and want to solve the rogue printing problem, you’ll need to take advantage of FileOpen’s advanced printing restrictions and watermarking features.

In this post we’ll walk you through how to limit printing of FileOpen-protected documents, and how to impose unique watermarks on each printout with user-identifying data. Using “dynamic” watermarks, you can auto-generate watermarks at the time of encryption and delivery, to include rich data which could be used to track a printout back to the user, time and device on which a document was printed.

How to Control Printing 

In FileOpen RightsManager and RightsServer, you set printing permissions according to the access control policies you define for your different groups, or recipients. So rather than assigning printing restrictions to the actual documents, you can give different recipients different levels of printing privileges to the same document.

Your options for restricting printing are:

  • Enable/disallow any printing
  • Set a notification when a document has been printed
  • Set the maximum # of print copies allowed
  • Specify which pages or page-ranges can be printed
  • Restrict printing to only physical devices (no print-to-file), or only to specific “whitelisted” printers
  • Set a percentage of the document you will allow to be printed
  • Print documents as lower resolution images so they are a degraded version of the original
  • Simply monitor printing activity, without limiting # of prints or prohibiting any print drivers

All of the above printing permissions require that the end-user be online. RightsManager and RightsServer also have offline permission settings, which can be used to allow or disallow offline printing, and to cap the number of prints allowed while the user is offline.

Add-Permission-Policy-Crop.png

FileOpen RightsManager offers a great deal of flexibility over printing, including the ability to render printouts in a lower resolution. 

You don’t have to set printing restrictions in order to use watermarks, but they add an additional layer of control to your valuable documents. Now, let’s move on to adding watermarks.

How to Add Watermarks

Prior to the development of the current FileOpen watermarking mechanism, some implementations of the system added watermark text to a PDF prior to encryption, then encrypted that PDF uniquely for a specific user. We refer to this as Static Watermarking and Dynamic Encryption. That is, the watermark text is static (always remains the same as what was imposed originally), and the encryption is done in real-time, or dynamically.

The current system implements Dynamic watermarks, and can be used either with Dynamic or with Static Encryption. That is, the text of the watermark can change each time the document is opened, and this can be the case whether the same encrypted PDF is opened by multiple users, or a unique encrypted PDF is created for each user.

Within any particular watermark policy, there is a similar distinction between static and dynamic text, both of which can be used simultaneously on the same document:

Static Watermark Text: These contain information you define in advance when you are setting up permissions policies for your recipients. They can contain a copyright message or any text you please. This text is literal, i.e what is specified in the policy is imposed into the watermark.

Dynamic Watermark Text: Dynamic watermark text is generated “on-the-fly” when a user opens or prints a document. This text typically contains information specific to the user, e.g. name or email address. This information is retrieved from the PermissionServer database and sent to the Client as part of the document open or print control event, so can be changed even after document delivery, e.g. for example to notify an end-user that a newer version of the document is available. FileOpen SDK licensees can take advantage of a rich syntax to dynamically place watermarks using data such as the machine ID of the user, IP address, and printer name/port that they used.

For the purposes of this post, we’ll walk through the process of generating watermarks using the WebUI of FileOpen RightsManager and RightsServer.

1. Create a Watermark Layout Template

The first step is to configure a Layout Template for your watermark (Watermarks > Layout Templates > Add Layout Template). Here you can choose whether to make your watermark a “Stamp”, in which case it will be superimposed on top of the document contents, or a watermark that is imposed beneath the text of the document. You can also define the watermark’s type (header, footer, diagonal up, diagonal down, vertical left up or vertical right down), the font (also the size/fill-color RGB, stroke width, stroke color RGB) and the aligment (left/right/center).

2. Create a Text Template

Next, create a Text Template to define the content of your watermark (Watermarks > Text Template Sets > Add Text Template Set). Here you can choose whether to date and time stamp each printout, include user-identifying information, etc. User-identifying information can include their email address, username, full name, company, IP address, printer ID, and many more data points.

Together, your Watermark Layout Template and your Text Template make up a Watermark Set.

3. Apply a Watermark Set to a Policy

Navigate to Policies > Watermarks. Click on the Policy Set you want to apply your Watermark to. For example, you might have a Policy Set for a site-license subscription, and want to add the watermark to all documents associated with that policy.

Applying watermarks at the Policy level frees you from having to create multiple different versions of the same document, because the watermark floats above the document as a separate object, and can be changed or removed even after delivery. When you assign your watermark to a Policy, you can define a different watermark for digital viewing and print, or only include the watermark on the printed version.

Here is an example of what your watermarks will look like on the resulting document:

 dynamicwatermarks.png

This example shows a printed PDF with both static and dynamic user-generated watermarks, visible in the header and footer of the page.

You can make your watermarks as noticeable or unobtrusive as you like using the design controls in Watermark Layout Template dialog.

The Result: Smart Printed Documents

By leveraging FileOpen’s print controls and watermarking features, you can close the loop on unwanted printing and reproduction of your documents. Including unique user-identifying data in your watermarks will render every printed copy of your document traceable back to the original user—even copies made with a photocopier. Because the watermarks appear below the text, they cannot be “whited out” without visible degredation of the document content. Watermarks not only reinforce your permission policies on the printed page, they provide you with actionable data on how your valuable and confidential documents are being used.

FileOpen’s print control and watermarking features are bundled with our RightsManager, RightsServer and SDK products for encrypting and controlling access to documents. FileOpen watermarks can be used on native PDF files for viewing/printing in Adobe Acrobat and Adobe Reader(end-user plug-in required), and on OPN files for viewing/printing in any web browser with no plug-in required.

Contact Us for a demonstration and consultation of FileOpen's watermarking and security features. 

 

Topics: document control, watermarks, watermarking, printing control

Two Lesser-known FileOpen Features: Screen Capture Prevention & Watermarking

Posted by FileOpen DRM News

Document security is one of the most important challenges faced by businesses today.  Your documents contain your company’s proprietary, confidential or regulated data and are likely the most valuable things on your computer or network. FileOpen document security and rights management software not only allows businesses to set up strict access and usage controls to documents, it also provides additional layers of security to prevent or deter the unauthorized redistribution of the data in your documents.

Today we will take a look at two lesser-known features available in FileOpen software which go a step beyond basic document security; screen-capture prevention and user-identifying watermarking.

Screen capture prevention

For our most security conscious customers, FileOpen offers screen-capture prevention in environments where possible (currently Windows operating systems).  FileOpen has obtained a  Code Signing (Class 3) Digital ID giving permission to run services at the kernel level, including monitoring for a screen capture event.  Once an event has been identified, our app hides the content of the protected document.  The screen shots below illustrate a FileOpen-protected document with and without screen capture prevention enabled. 


FileOpen-protected-documentFileOpen-protected PDF, viewed in Adobe Acrobat/Reader DC with the FileOpen Plugin, without screen capture prevention enabled.  Image captured with the Windows Snipping tool.

FileOpen-screen-capture-preventionFileOpen-protected PDF, viewed in Adobe Acrobat/Reader DC with the FileOpen Plugin, with screen capture prevention enabled.  Image captured with the Windows Snipping tool.

To be clear, we do not claim that FileOpen guards against all methods of screen capture; it is always possible for a determined adversary to use a camera or to transcribe content manually. Nothing is 100% secure unless it is 100% unusable.  That said, FileOpen screen-capture protection adds real value by preventing screenshots in environments where it can do so without impacting the recipient’s ability to use the document as intended. 

User-identifying watermarks

In addition to screen capture prevention, FileOpen enables user-identifying watermarks. Watermarks can be applied on-screen and to printed copies of protected documents (and can be different watermarks in the two cases).  These watermarks provide a deterrent against a user redistributing a confidential or purchased document, because they are far less likely to disseminate content where they are identified as the source.

Watermarks can be configured as needed and can be edited with immediate effect. They can contain static and variable information (for example, the recipient email address, IP address, user host name, print driver and the date and time of view/print). For this reason, different users will see the same document with different watermarks.  FileOpen watermarks are supported  in PDF on Windows and Macintosh, in OPN on all supported devices, and in the FileOpen HTML5 rendition.

The screen shots below illustrate a FileOpen-protected document with user identifying watermarks.

FileOpen-user-identifying-watermarks-in-PDFFileOpen-protected PDF, viewed in Adobe Acrobat/Reader DC with the FileOpen Plugin. Both variable and static watermarks are present.

FileOpen-user-identifying-watermarks-Web-viewerFileOpen-protected PDF delivered in OPN format, viewed in Chrome without any clients or plugins.  Both variable and static watermarks are present.

Contact us today to learn more about the FileOpen document security.

 

 

Topics: document control, data protection, stop document piracy, watermarks, watermarking

What makes FileOpen document security & control different?

Posted by FileOpen DRM News

At FileOpen we understand that building out your security infrastructure can be a daunting task.  Every document security and DRM vendor claims their solution is bigger, better and faster than the others.  It is vital to evaluate these claims and potential issues before a solution is purchased.  We advise our potential customers to create a checklist encompassing their core requirements and desired results.   A checklist may start small and grow as you assess each solution.  To assist in this process we have put together a few questions based on what our customers have consistently identified as important differentiators, such as:

  • Security and encryption
  • Recipient ease-of-use
  • Day-to-day administration and permissioning
  • Flexibility and extensibility (integrations)

Security and encryption

This section covers issues pertaining to file-level security and encryption.  This encryption makes the contents of your files indecipherable to unauthorized individuals. Document encryption uses complex mathematical algorithms to convert documents into an information package that cannot be read until there is a positive client server interaction verifying user identity and permissions. So, if an unauthorized individual intercepts an encrypted document they will not be able to access and read it.

FileOpen gives you a choice of encrypting on-premise or in the cloud, so you never have to upload an unprotected file. Once the document is protected, it can be distributed safely through whatever mechanism or protocol is most appropriate.  Documents are secured at all times and can only be accessed after a positive client server interaction verifying user identity and permissions.

 
FileOpen
Other Vendor
  1. Does the solution offer local encryption so source files are never transmitted over the internet?
YES

 

  1. Are decryption keys stored within the document?
NO

 

  1. Can the permission data be stored separately from the document?
YES

 

  1. Can permission requests and data be encrypted as well as the document?
YES

 

  1. Can document controls be enforced even after being downloaded to the recipient’s device? Offline?
YES

 

 

Recipient ease-of-use

One of the biggest challenges of document DRM is making it easy for your users to share, access and work with protected files.  No organization wants to lose control of protected documents, or to place unnecessary barriers between authorized users and the information they need to do their jobs.  With FileOpen’s versatile client set you can define when, where and how users can interact with documents while still allowing users to use the productivity tools of their choice.

 

 
FileOpen
Other Vendor
  1. Does the solution provide protected files in standard file formats like Adobe® PDF, Microsoft® Word®, Excel® or PowerPoint®?
YES

 

  1. Does the solution provide a preview of protected document to authorized users without any software installation (plugins/clients)?
YES[1]

 

  1. Can protected files be accessed from mobile devices? 
YES

 

  1.  Are native applications required for mobile viewing?
NO[2]

 

 

Day-to-day administration and permissioning

This section covers issues pertaining to administering document access and usage controls.  These features allow you to securely share your files with others, while maintaining full control over who accesses them and how they can work with them. With FileOpen software, you control who can access your files by defining groups and including the users in these groups. For each group, you set specific usage policies, such as print restrictions, watermarks and offline capabilities. You then protect documents by assigning them to their respective groups, according to the permissions you want to grant. You can change a user’s or documents group membership at any time, with immediate effect.

 

 
FileOpen
Other Vendor
  1. Can the solution control printing, copying and saving of the file?
YES

 

  1. Does the solution provide user-identifying watermarks on document view and print?
YES

 

  1. Does the solution provide the ability to grant offline access? Configure how long offline access is permitted?
YES

 

  1. Does the solution provide an out of the box, easy-to-use authentication scheme?
YES

 

  1. Can the administrator of the solution remove access to specific documents, users or user’s device?
YES

 

  1.  Does the solution provide access to activity reports by user, document and failed access attempts?
YES

 


  1. Can the solution be configured to automatically apply permissions to documents? Provision users?
YES[3]

 

 

Extensibility & flexibility

This section is designed to help you find an integration-friendly solution; one that enhances and extends current investments.  At FileOpen, we work with customers evolving standalone solutions into infrastructure that protects and controls documents as they are created or on-demand. Our extensive list of services and APIs allow any person or system within an organization to protect documents and permission authorized users.

 
FileOpen
Other Vendor
  1. Can the solution be implemented on-premise? Or as a Software-as-a-service (SaaS) solution?
YES

 

  1. Can the solution be configured to protect files as they are created?  In batches?  On-demand?
YES

 

  1. Are there specialized services for eCommerce?
YES

 

  1. Does the solution integrate into cloud-based sync-and-share systems like Dropbox?
YES

 

  1. Does the solution extend current directory services? Does it support mixed-mode authentication?
YES

 

  1.  Can the solution connect to existing NAS?
YES

 

Creating a vendor checklist can be a difficult task but after reviewing your company’s polices you should be able to create a list that will help you decide which solution will conform to your company’s security requirements.  Contact us today for more information on how FileOpen solutions stack up or sign up for a free 14-day trial and see for yourself.

[1] The FileOpen Plugin/Client is required to securely collaborate within native publishing tools like Adobe® Acrobat®, Microsoft® Word® and Excel®
[2] While not required to preview a FileOpen-protected document in a browser, native iOS and Android Apps are freely available and provide a larger feature set.
[3] FileOpen offers extensive APIs to connect document and user permissioning to almost any third party system.  

 

Topics: document control

FileOpen Systems 2012: The Year in Review and a Look into the Future

Posted by FileOpen DRM News

As we start the new year we’d like to extend our sincerest thanks to our licensees, partners and vendors. We truly value your business and look forward to many more years of working with you.  We would also like to take this opportunity to review a few of our accomplishments of the year and provide a glimpse of some of the new features we plan to release in the coming months.ny2013

2012:  Year in Review

2012 was a big year at FileOpen Systems.  We saw steady growth in our licensee base, the number of documents protected, and of platforms supported. This year we added client support for new platforms including Apple iOS, Adobe Acrobat/Reader XI and Windows 8, even as we broadened the reach of our “zero install” solutions. We also saw FileOpen technology integrated into a number of 3rd party products. A few of the highlights from the year include:

    • Early in 2012, we reported solid year-over-year growth and expansion of active licensees in the publishing, financial services, manufacturing, healthcare and government sectors. At the same time we also had a significant surge in licensing to Virtual Data Room (VDR) providers, reinforcing our position as the predominant enabling technology for VDRs.  To sustain this momentum, we expanded our engineering and marketing staff.
    • In February 2012, we exhibited at the RSA Conference in San Francisco, “where the world talks security.” At the show we unveiled the zero-install FileOpen viewer, the culmination of years of development to grant the wish of our licensees who need to distribute documents securely with absolutely no client software download.
    • During the summer we released the FileOpen Viewer for iPad and iPhone.  This new app enables the secure display of FileOpen-protected documents in Apple iOS. In the PDF world we also continued to expand the list of FileOpen-compatible applications to include the most popular PDF viewers.  These include Foxit Phantom/Reader, Nuance PDF Converter Pro, Bluebeam PDF Revu, Nitro Pro 8, and Tracker PDFXChange.
    • This fall we launched the new and improved fileopen.com, with additional content organized by business need, industry segment, and solution.  The site also provides new ways to test out clients with demonstration documents in addition to requesting a full evaluation version.

FileOpen Systems in 2013

We have been working on a number of projects that will be released in the new year. To avoid pre-announcing products or features, we’ll mention only a few general themes that we see as significant for the coming year and for which we hope to provide working solutions. These include:

    • Encryption and management of content will continue to shift from
    • being a centralized publishing function toward being a responsibility of individual document creators. FileOpen will be releasing new and improved tools for local document encryption at the point of creation and/or the point of exit from the local environment.
    • FileOpen will continue to support BYOD in the enterprise through the release of viewer components for new platforms — integrated into a coherent system for enterprise document control.
    • Storage and distribution of content will continue to flow toward cloud-based systems, and FileOpen will continue to expand the functionality to support these solutions.  More specifically, we will be releasing the technology to detect user environments and display content in the most appropriate format while maintaining the highest possible degree of security. 
    • A trend toward tracking of documents, rather than control of those documents, may be accelerated by new offerings from FileOpen that provide this functionality.
    • As the amount of data generated by document control and tracking systems continues to grow, new tools will be provided for the analysis and visualization of that data.

In closing, we would like to thank all of our community for being pioneers and visionaries.  We send you our warmest wishes for the Holidays and for a happy and prosperous New Year.

 

Topics: document control, FileOpen, BYOD, document security

RIM's "PlayBook" Will Extend FileOpen's Reach on Handheld Devices

Posted by Sanford Bingham

playbookThis week Research in Motion announced a tablet device, named the “BlackBerry PlayBook”, that appears to exceed the specifications of the iPad in every respect other than screen-size. The device, which will debut in the second half of 2011, will have a dual-core processor and 1Gb of memory, a variety of input/output ports, and two cameras (i.e. the ability to videoconference).

Most important for our customers, the PlayBook will run Flash 10.1, and therefore should support both the FileOpen Viewer and our recently released BlackBerry client. This would enable distribution of the same FileOpen-encrypted document to the BlackBerry, PlayBook, and on standard Windows/Macintosh/Linux computers.

The PlayBook will work immediately with BlackBerry Enterprise servers. It runs a Unix-derived microkernel operating system (QNX) that RIM acquired along with the company of the same name earlier this year. Reports describe the OS as extremely secure and capable of true multitasking, something the iOS can’t currently provide. The seven inch screen is smaller than the iPad’s by two inches, but this may be intentional (there are rumors that the next version of the iPad will include a model with a seven-inch screen). 

Check out our press release announcing our support of the BlackBerry platform for document distribution, and stay tuned for more announcements as we extend secure document sharing to the world of smartphones and tablets.

Topics: document control, FileOpen, blackberry, pdf security, RIM, Research in Motion, PlayBook

FileOpen for Handhelds

Posted by Sanford Bingham

This week FileOpen Systems is releasing FileOpen Document Control fileopenbbfor Blackberry™, the first of several implementations of our software for handheld devices. This product release is the first example of general architecture that we expect will permit the expansion of the FileOpen footprint to include a variety of devices and systems. The key idea behind this design can be summed up as “Adapt to the incumbent viewer.”

This is not a new idea, of course: FileOpen has always adapted to the incumbent PDF viewer on the PC/Mac/Linux platform, which is Adobe Acrobat/Reader. However, there currently is no Adobe Reader for Blackberry™. Adobe has released a viewer for the Android OS, which also uses the Java language, so the possibility exists that we’ll see an Adobe Reader for Blackberry™ in the near future. At the moment there are two incumbent viewers on the BlackBerry™ platform:  BeamReader (www.slgmobile.com) and RepliGo (www.cerience.com). Neither product is free (both cost about $15 for a perpetual license), but both do a good job of rendering a PDF entirely on the local device.

Our initial intent had been to create a “FileOpen PDF Viewer” for the BlackBerry™, i.e. to display documents in our own application. However, as the development got underway we discovered that the BlackBerry OS doesn’t permit more than one application to be registered for a particular file type, so if we were to deliver a FileOpen PDF Viewer any user who installed that application would be forced to use it to display all PDFs (even those not encrypted by FileOpen). We could also have changed the file extension from PDF to something else, but doing that violates some of our core design principles (we work with native formats) and doing so for only one device would be a recipe for end-user confusion.

Even if we could, FileOpen Systems has no desire or incentive to displace the incumbent players in the BlackBerry™ PDF viewer market, or even to favor any single player over any other. So we decided on an approach that would allow our application to work with any and all viewers that support the required Java Mobile Edition (JME) functions for interapplication communication. On BlackBerry™ devices where a compliant PDF viewer is present, PDF files encrypted by FileOpen can now be authenticated and modified by our application, then opened and displayed in the incumbent viewer.

Going forward we think this approach will simplify the development of solutions for other handheld devices. Look for more announcements in this space in the coming weeks.

Find out more about FileOpen Document Control for Blackberry™

Request a 30-Day Free Trial of FileOpen Document Control for PDF and Blackberry™!

Topics: document control, FileOpen, blackberry, drm, pdf security, pdf encryption, pdf, RIM

Alternative PDF Viewers Lag Behind Adobe Reader in Security

Posted by Sanford Bingham

pdf viewersOur colleague Vivek Unune has pointed out yet another attack related to PDF files. 

This one is a bit unusual in that it exploits a PDF language feature (launch action for embedded files), rather than a specific vulnerability. This means that it impacts not only the Adobe Reader, but probably all full-featured PDF viewers (though not all PDF viewers are full featured, see below).

At least one PDF viewer, Foxit Reader, appears to be more vulnerable to this particular exploit than the Adobe Reader. This is not unusual:  most of the PDF exploits that have been uncovered so far, especially the ones related to JavaScript, affect most, if not all, other PDF viewers at least as much as they do the Adobe viewer (http://www.pcworld.com/businesscenter/article/160977/foxit_pdf_viewer_also_open_to_attack_say_researchers.html).

This particular attack requires that the user actively allow the exploit to run, though as the author points out it is quite possible to mask this in such a way as to make it likely that users will go along (and in Foxit the exploit just runs, with no user interaction required). Preventing the exploit in the Adobe viewer is relatively simple (uncheck the box at Edit>Preferences>Trust Manager: Allow opening of non-PDF file attachments with external applications).

The reason one hears so much less about other vulnerable PDF applications is presumably that they are much less widely used.  While there are a great many PDF viewers (see http://en.wikipedia.org/wiki/List_of_PDF_software), only one of them has any significant market share. I can't cite any real data for this claim (if anyone has statistics on penetration levels please send it), but my guess is that the distribution of PDF viewers is similar to that in the Office productivity market (MS Office vs. Corel and Open Office etc.), where the Microsoft share is about 80% overall (see http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html). In the PDF world I'd bet that the combined share of all non-Adobe PDF viewers is less than 10% of the total, with the Adobe viewer having the other 90%.

With this in mind I was intrigued to read a review by Duff Johnson of Appligent, http://www.appligent.com/talkingpdf-pdfreaderreview, in which he analyzes a few alternative PDF viewers and finds each of them wanting in many important respects, relative to Adobe's viewer. This functionality-gap is the result of Adobe having invented PDF and working with it longer, with more resources, than anyone else.

Just as we have seen Microsoft over the past five years, perhaps longer, make security a primary objective so too do we now see Adobe prioritizing the effort to stop vulnerabilities. Today the case can reasonably be made that Windows is the most secure OS available (see http://blogs.zdnet.com/hardware/?p=4146, http://www.oreillynet.com/windows/blog/2007/05/is_vista_more_secure_than_mac_1.html, etc.), and the same can be said about the Adobe 9.x viewers relative to all other PDF viewers. Adobe's statements around the beta of the next Acrobat release suggest that security will be an even more important part of that product, along with a variety of other features and functionality that we will discuss as soon as we are permitted to do so.

I should point out that FileOpen's encryption tools work with PDFs generated from a wide range of third-party PDF creation tools, in addition to Adobe Acrobat, as long as the PDFs are compliant with the PDF Specification, now an ISO standard. On the client-side, however, we currently support the Adobe Viewer for secure PDF viewing (in part for the security reasons mentioned above). We have also developed the FileOpen document viewer which can convert PDF content and display it securely in any Flash-enabled web browser, without any need for a client plug-in.

Topics: document control, FileOpen, pdf security, pdf encryption

Document Control Post-"Aurora": Don't keep it all in the Cloud

Posted by Sanford Bingham

Google's recent disclosure that its servers were breached, along with those of 34 other big-name companies including Adobe Systems, raises some important questions about security in general and the risks of hosted data services, or "cloud computing", in particular.Aurora: Danger

In an intriguing technical twist, the "Aurora" attacks (given that name by McAfee  from a fragment found in the executable), were initiated by taking control of the PCs of unsuspecting employees, apparently through "spear phishing" emails sent to specific users. When the users clicked links in the messages their machines were infiltrated and then remote-controlled to further penetrate the internal networks of the target companies.

PDF and Aurora: Setting the Record Straight 

Some early reports suggested that the infected links were PDF files, and that a vulnerability in Adobe Acrobat/Reader was the entry point for the attack. This theory has since been debunked, and the actual vector identified as a previously unknown JavaScript-execution flaw in Internet Explorer (Security Advisory 979352).

Adobe patched the Acrobat/Reader JavaScript flaw (APSA09-07) on January 12, 2010, in versions 8.2 and 9.3. However, the Adobe patch was released a week after the Aurora attack, so doesn't settle the break-in whodunit one way or the other. (The patch does, however, allow up-to-date Adobe Acrobat/Reader installations to re-enable Javascript execution and/or to avoid having to implement a blacklist framework for filtering malicious code.) Incidentally, disabling JavaScript has no impact on the operation of the FileOpen software, which loads into the Adobe viewer via the C/C++ interface, i.e. at a lower level of the Acrobat API. 

Risks of Comingling Data

Regardless of whose vulnerability was exploited to gain the beachhead, the fact remains that the attackers penetrated the internal networks of Google and dozens of other name-brand software and internet companies, set up encrypted channels for the extraction of data, and operated for a period of days or weeks before being expelled. The attackers may have stolen or modified source code from any of the targeted companies (Google's  announcement refers to "the theft of intellectual property from Google", though Adobe's announcement suggests that nothing of value was taken), and in doing so have probably paved the way for even more sophisticated intrusions down the road.

Despite the fact that most of the networks penetrated by the Aurora hack were private corporate environments, not public hosting providers, the event has sparked wide-ranging debate about the risks of storing critical data on servers "in the cloud". At least one commentary from a widely-respected author calls the breach so damaging that henceforth "none of our stuff on Google's servers is safe."

If indeed the attackers were able to extract or modify Google's source code - not just for GMail, presumably, but also the various applications providing hosted document authoring, management and storage, etc. - then the amount of data at risk is vast, and there may indeed be reason to think twice before storing important corporate data in that hosted environment, if not hosted environments in general.  

This is not meant to suggest that other companies can better defend themselves from attack than can Google, with all of its resources and security expertise, only that the centralized storage of any valuable good creates incentive for theft. In a physical world it is possible to scale security proportionally to the value of the goods - castles, Fort Knox, missile silos - but doing the same for data is much harder. Data security at a major enterprise like Google comes to resemble airport security, an imperfect struggle to avoid the worst outcome. In hosted computing, like air traffic, scale creates risk: because Google aggregates so much usage, a breach of Google's security (or Facebook's, etc.) is potentially an attack on the data of thousands of companies and millions of users.

In the next post, we'll discuss how FileOpen's document security software was designed from the start to avoid the aggregation of documents, user data and decryption keys all in one place.

Sanford Bingham   President   FileOpen Systems Inc.   www.fileopen.com

 

Topics: document control, FileOpen, drm, adobe, aurora, china, google, cloud