Posted by Sanford Bingham on Fri, Apr 30, 2010 @ 03:53 PM
We'd like to thank Elisabeth Horwitt for her mention of FileOpen Systems in a recent Computerworld article, "Enterprise rights management and keeping data in-house," and also to thank Paul Chow of BCA Research for his comments about his company is using FileOpen software in the same piece.
The article describes some of the challenges around Enterprise Rights Management from an IT perspective. It also illuminates one of the important trends now emerging, the interplay between Digital Loss Prevention (DLP) and ERM/DRM. FileOpen has just made available a whitepaper on that subject, "FileOpen and Data Loss Prevention," which explores how the two approaches can complement each other.
Computerworld approached FileOpen customer Paul Chow at BCA Research, who explained why they chose FileOpen's DRM over alternative solutions;
BCA, for example, stopped using LockLizard's IRM product because it required installing a proprietary PDF reader that was not Adobe's, Chow says. "For our client base, that just wouldn't work." In contrast, FileOpen supplies a plug-in to users' existing Adobe readers that can be installed in 30 seconds, he adds.
The article underscores the importance of choosing DRM software which provides tools for managing users and permissions policies, a feature FileOpen has long provided and is soon to release in a web-based interface.
Posted by Diana Holm on Thu, Apr 08, 2010 @ 01:54 PM
We are not big on generating a lot of press releases here at FileOpen, preferring to
stick to our knitting so to speak, but every so often a customer will take it upon themselves to evangelize FileOpen software, and we'd be ungrateful not to share their enthusiasm (if a little belatedly).
The British Library, one of the world's largest document repositories, issued a press release in November 2009 entitled "The British Library Improves Electronic Access with New DRM Platform from leading provider, FileOpen Systems." Their announcement emphasized the greater flexibility FileOpen DRM would provide to end-users, with the library's head of sales and marketing quoted as saying, "The decision to add FileOpen to our Document Supply delivery options was driven by customer demand, they wanted a choice of electronic delivery options....Customer feedback from the testing phase was very positive, and we are pleased to announce that we are now recommending FileOpen as our preferred electronic delivery option to all customers."
We were also pleased to see the British Library's official response to "An open letter to the British Library" posted by Richard Mitchell of the University of York on the British Library's Facebook page. Mr. Mitchell had written to the library to express his "disappointment at the British Library's decision to use proprietary, DRM-encumbered software to distribute journal articles, whilst other institutions and publishers happily distribute their articles in the much more accessible PDF format." He also bemoans the lack of support for Linux.
It turns out, Mr. Mitchell was referring to the British Library's prior use of Adobe's Digital Editions DRM platform, which necessitates the download of a separate viewer and does not support the standard Adobe Reader. Nor does the Digital Editions viewer run on Linux. The British Library's Barry Smith thanks Mr. Mitchell for his comments and informs him the British Library will be launching "an additional DRM facility in early 2009 that will be compatible with Linux (and most other open source platforms) called FileOpen." Mr. Smith goes on to say that "From April, we will be encouraging our academic users to switch to FileOpen, as it will offer more flexibility for many of our customers."
FileOpen's relationship with The British Library goes back to 2000, and after many damp and chilly train trips from London to Boston Spa to meet with their information services management and understand their complex requirements, it is especially gratifying to have the support of both the Library and their end-users.
Posted by Sanford Bingham on Thu, Apr 01, 2010 @ 07:28 PM
Our 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.
Posted by Sanford Bingham on Thu, Mar 11, 2010 @ 11:04 AM
A few more words on Acrobat and JavaScript, triggered by a recent report in The Register that Adobe Reader is now the most popular application for targeted malware attacks. At one level this is old news, referring as it does to research done last year by antivirus maker F-Secure, and also somewhat obsolete, as the data, linked below and in the article, pre-date the Adobe 9.13 update referred to in the first post of this blog.
But it is interesting, at least, to learn that the Adobe Reader is now more targeted than Microsoft Word. I believe this status to be a consequence of the trust people put in PDF and Adobe Reader; nobody in their right mind has opened a .doc file from an unknown source in years (and anyone who has used the beta of MSOffice 2010 can tell you that Microsoft is taking that problem seriously). But the key point about this malware issue, from FileOpen's perspective, is that the attacks all target the JavaScript layer in PDF, which is normally suppressed by security handler encryption. In other words, encryption of the type FileOpen offers should be considered a solution to this problem, for several reasons:
- Files encrypted by PDF security handlers do not rely on any JavaScript methods, so disabling the execution of JavaScript via the preferences settings shown in the F-Secure article, http://www.f-secure.com/weblog/archives/00001671.html
, will have no impact on the opening or use of files encrypted using the security handler.
- Even if JavaScript is enabled, files encrypted by security handlers (at least those employed for DRM) are normally not vulnerable simply because the permissions required by the JavaScript - i.e. the ability to change the Document - are the very ones that publishers normally use DRM to restrict.
That said, it is probably possible to create a PDF that, after encryption with FileOpen, still executes one of the vulnerable JavaScript functions (getAnnots() and spell.customDictionaryOpen(), see http://www.kb.cert.org/vuls/id/970180
), but for the exploit to work the publisher would need explicitly to enable modification of the document (a setting that defaults to off in FileOpen software).
Here's a more detailed explanation of what is happening inside the Adobe viewer, for which I'm indebted to Patrick Leckey. The JavaScript boundary-condition error is setup when the arguments are processed by the code internal to the getAnnots() method. But the permissions check, by which the Security Handler opens the file and specifies what actions are to be permitted, happens at the JavaScript engine layer - before the getAnnots method is processed internally.
That basically means that when you call getAnnots() in JavaScript, Acrobat passes this request to its JavaScript interpreter. The interpreter then sees a request for getAnnots() and checks the document permission to see if this method is allowed to be called. If it is not, it returns a NotAllowedError and halts execution.
The result is that unless the Security Handler, i.e. the publisher, has granted permission to edit the document (specifically, pdPermEditNotes) the vulnerability cannot execute. For nearly every licensee of the FileOpen software, then, the issue of JavaScript vulnerability in Adobe Acrobat/Reader is a non-issue.
Posted by Sanford Bingham on Thu, Feb 04, 2010 @ 01:27 PM
We sometimes get inquiries from IT departments on behalf of users trying to open documents encrypted with the FileOpen software. Sometimes the question concerns the general design of the system, sometimes it is specific to a particular error condition. From time to time as these questions arrive we will post answers to this blog. Here's one such message.
"We have a few FileOpen plug-in users that are unable to open PDFs. When attempting to do so, they get error "There was an error contacting the server or the server's response could not be decoded. Please check your internet connection. If the error persists please contact the publisher and present the text of this message".
I have downloaded the latest version of FileOpen from the website, and attempted to open a PDF from <publisher>, but I still get the same error.
In order to help troubleshoot this, I am hoping that you can provide:
* A generic test PDF from FileOpen that we can use to determine whether this is an issue with using FileOpen itself, or an issue with the publisher of the PDF.
* A host that we can telnet to, and the necessary ports, to determine whether firewall rules are not set properly on our end.
* Any other suggestions that you might have."
Somewhat parenthetically, I'd like to point out the extremely professional structure of this question: the exact text of the error is presented, the questioner seems to have already determined the cause of the problem (firewall blocking access) so asks for data to verify that assumption. For a tech-support person, interactions like this one are a real pleasure.
In response, we can say:
There is a FileOpen test-server at http://www.rightserver.com/fowp that can be used to validate the behavior of the FileOpen client. This server is part of our Toolkit evaluation package, and implements a very simple PermissionServer script, without SSL, and contains document examples that don't require any authentication. At the top of the page there's an anchor link for MachineID, and the four documents in that section will open for any user at any time provided the user has the FileOpen client and an active internet connection. The page also contains links to files that demonstrate some of the other authentication methods, so can be used to validate other behaviors as well.
However, the fact that a document opens from the above site does not necessarily mean that the same machine will be able to open documents from any given publisher using the FileOpen software. Because of the design of our system (publishers are not required to use our server software, and their own implementations can use any port), the specifics of the ports needed for any given document can't be known ahead of time. Nearly all PermisisonServers running the FileOpen software use either port 80 or 443, but this is not a requirement.
The important things to consider if a document doesn't open are:
- Is the FileOpen client installed (check Help>About 3rd Party Plug-ins>FileOpen WebPublisher)?
o If not, install from http://plugin.fileopen.com/ or http://plugin.fileopen.com/all.html
- Does the error message contain text that suggests that the Publisher's server could not be reached (the one above, or a message with text like "Unable to get server data [FO error #2114, OS error #0].")
o If so, attempt to open a file from the test site above. If that also fails, check that the machine is connected to the internet and that the local proxy or firewall permits Adobe Acrobat/Reader to communicate over port 80.
- Does the error contain a message that is specific to this document or user, e.g. something like "Document Access Denied: This machine is not registered for access to this document."?
o If so the technical underpinnings are working properly - the client was able to contact the server and got a response - but there is a business issue between the user and the publisher, i.e. that publisher does not recognize the user or user's machine as having access to the document.
For more on the inner workings of the FileOpen plug-in for PDF, please see the FAQ.
Posted by Sanford Bingham on Wed, Feb 03, 2010 @ 02:24 PM
Last time we talked about how the "Aurora" attack on Google's servers illustrated the dangers of storing valuable data in the cloud, even in encrypted form. Owners of valuable data should not use centralized, big-name hosting services because those are servers most likely to come under attack from hackers.
So, how does FileOpen Systems approach this problem?
It was partly to avoid multi-user data breach that the FileOpen software was designed around a distributed architecture, with no single point of failure or co-location of publisher data. Each licensee of our Toolkit or PermissionServer operates a separate, private, wholly-owned implementation of the software: neither FileOpen Systems nor any other entity can monitor or remotely access that implementation without the licensee's permission.
However, some implementations of the framework - including our own FileOpen Hosted offering - operate as multi-publisher systems, so do centralize the data of multiple licensees. The FileOpen Hosted system has some structural features designed to minimize risk of data loss. Among these are:
- Distributed Document Storage: FileOpen's software operates only as a document permissioning service, not as a portal for the encrypted documents themselves. There is no single location containing all of the documents managed by the system.
- Local encryption: all documents encrypted into the FileOpen Hosted system are processed locally, on the desktops of the licensees. The unencrypted originals are never transmitted to any remote location.
- Database segregation: each licensee of the FileOpen Hosted system is provisioned as a separate instance of the PermissionServer code and a discrete database. This ensures that licensees' data is never comingled, each publisher has unique login credentials that resolve to a private database instance, and also enables migration of the database from the Hosted platform onto a private server upon request.
Using "cloud-based" hosted services is faster and easier than building-out dedicated servers, and in many cases can actually provide more security at lower cost than the same functionality implemented in-house. The safe deposit box at the bank is more secure than the safe in your basement. But at the same time, the crook is more likely to break into the bank vault than to raid hundreds of basements.
FileOpen's different products give you the flexibility to manage your entire secure publishing operation in-house, or outsource the database and authentication processes to us. But either way, your data remains with you and your authorized users--not in a centralized repository vulnerable to attack.
Sanford Bingham | President | FileOpen Systems
Posted by Sanford Bingham on Wed, Jan 20, 2010 @ 09:36 AM
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.
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