Archive for May, 2009

“Sign here…” Getting started with electronic signatures in Adobe products

This is the latest entry in our “What is an Electronic Signature, Anyway?” series.  You can find previous entries here.

Recently, I’ve received a number of emails from our users asking questions about electronic signatures, so I thought it would be useful to briefly answer some of these frequently asked questions and also direct you, dear reader, to a variety of resources here at Adobe that can help.

First, I recommend you read the other blog entries in our “What is an Electronic Signature, Anyway? “ series to better understand the terminology and issues surrounding electronic signatures.

Now onto the questions…

I want to electronically sign a PDF—what do I need to do?

There are lots of different ways to electronically ‘sign’ documents, but they vary in terms of reliability, longer-term validity, and application.

Continue reading…

“Click on this…” Adobe’s eSubmissions Solution Accelerator Shows Off Click-thru Approvals & Signatures

Electronic signatures come in many shapes and sizes, and for a long time, Adobe has been primarily associated with three of those sub-types—digital signatures, certification signatures, and handwritten eSignatures based on solutions from our Security Partner Community—due to our comprehensive coverage of, and capability for, those technologies.  However, customers and partners do not often associate us with click-thru approvals and electronic signatures, where a user authenticates to a website, reviews a document, and then is allowed to approve or reject said document with a simple click of a button.

Actually, Adobe has supported this capability for some time within our LiveCycle ES product line, but the capability was spread across components that can prepare documents for review (PDF Generator, Output, Reader Extensions, Forms), move documents along a workflow (Process Management), present documents for review, comment, and approval (Workspace), and then sign (Digital Signatures) and archive (Content Services) or further process those documents for storage, submission, etc. 

The challenge of piecing together these components was not lost on Adobe, and last year we started working on Solution Accelerators–sample code and tooling that brings together task-oriented building blocks composed of LiveCycle components.  More than a proof-of-concept, but less than complete production code, Solution Accelerators can be used by a customer or systems integrator to bring projects to fruition in a much shorter timeframe, while providing for flexibility in the final implementation. 

The eSubmissions Solution Accelerator, released this Spring, shows how LiveCycle can be used to present documents for review, commenting, & approval in parallel or serial workflows, and incorporates the capability to not only sign with traditional digital signatures or handwritten electronic signatures, but also via authenticated click-thru approvals and server-side signing and certification functions.  Download the demonstration video here.  Unlike other click-thru solutions on the market, this Solution Accelerator shows the breadth and depth of Adobe’s offering, providing for compliance with electronic signature regulations around the world.


While this Solution Accelerator was designed for the biopharmaceutical market, it can easily be repurposed for contract approvals, financial services transactions, and the like—this is one of the benefits of the Solution Accelerator approach. Moreover, eSubmissions demonstrates Adobe’s intent to provide users with a best-in-class experience when it comes to electronic documents and workflows.  There’s no longer any reason to print an electronic document just for review and signature…Adobe provides a one-stop shop for a full range of electronic signature and approval capabilities.


Primer on configuring offline lease and synchronization

Today, I hope to answer some of the questions surrounding “offline lease” and “offline synchronization” settings within the LiveCycle Rights Management ES server configuration. Here is a screenshot showing several settings within our Admin UI:


and within our end-user-facing policy-edit UI:


What are these settings for? The “offline lease period” and “offline synchronization period” are interrelated settings that dictate how and when clients can be trusted to access (view, modify, print, etc) “offline”. There are varied casual definitions of “offline” depending on the scenario: when an executive needs to view confidential documents on an airplane without network access; when a field service technician is on-site at a customer location repairing a device but not entitled to “network guest access” due to security concerns. Both are supported with our solution and in fact are exceedingly transparent to the end user because they “just work” when the client is unable to “phone home” to the LiveCycle Rights Management ES server to authorize access in real time.


Customers appreciate that this offline access mechanism works transparently for users when they need it to most – but only when the author (and administrator) want it enabled. Not all organizations are willing to enable offline features for their most sensitive documents because while they retain complete access to revoke content or change authorization rules at any time, they are not guaranteed that these changes will go into effect immediately for all users world-wide. This is because the users and clients who are physically unable to “phone home” to the server will not receive an updated set of authorization rules while they remain disconnected.


In other words, by introducing offline access, authors retain complete control over protected intellectual property, however they introduce some latency before authorization rules are implemented.


This latency is the period of time before the clients can “phone home” to get the latest set of authorization rules. So we offer customers the ability to set a “ceiling” on the amount of latency they are willing to tolerate between an authorization rule being changed and when it will go into effect worldwide.


The maximum tolerated latency can be configured by document author/owners on a per-policy basis. This offers our customers the greatest flexibility because an internally-targeted policy covering executive “Insiders” may be very different from information classified for external use by customers. So how does this work? Each policy can set the "auto-offline lease period" – refer back to the second screnshot. This is how an author sets the maximum latency associated with one policy (and all documents associated with it). Since not all authors will want to set the latency, we give the administrator the ability to establish a default global latency: see screenshot one, where the administrator can set the default maximum latency – which is the value that is copied into each policy when it is created.


When discussing the feature, customers ask what happens if a disconnected user has access to two different documents with different policies, and different latency thresholds (that offline lease period). An example may help – say we have document A which allows three days of offline access, and document B which allows 15 days, and the client last phoned home to the server on March 1. Through March 3, the client will be authorized to view document A and document B, and from March 4-15 will be able to view document B only. If on March 8 the client phones home again, the clock is reset so document A and B will be viewable until March 11, and B will continue to be accessible until March 23.


Back to the March 1 example. What if somebody gives the offline client document C with 10 days of maximum latency on March 6? Because our system tries to be transparent to the user, and we do not require offline documents to be opened first online, he will be able to open document C from March 6 through March 10.


So…how does “Default Offline Synchronization Period” (screenshot one) relate? It’s a global server setting regulated by the administrator that dictates how long offline accessible documents should remain available offline. We accomplish the feature of not requiring offline documents to be opened first online by having the server give the client enough information to open “all” documents the user should be entitled to use while offline.


Our engineers decided to allow customers to tune whether “all” is really “all documents ever protected in the system” or whether in most customer uses it may mean for example “all documents protected in the last 365 days”, because many customers may not need to grant access to documents offline forever. By tuning this from an infinite (true “all”) period to a rolling-window of XX (e.g., 365) days, it simplifies the amount of information that needs to be sent to the client, and the amount of information that the client must store. The user benefit of this is that if you hire a new employee in the future and want to enable his machine to access documents offline, it’s unlikely he would need to access documents from 1982 while offline.


There are clearly tradeoffs here; the key takeaway is that this value should be set to the amount of time the client should allow protected documents to be viewed offline from the date they are initially protected.  Tuning this value to accommodate your scenario may be somewhat complex, so if you have any questions about your setup, do not hesitate to contact your local Adobe support representative.


Some general advice: administrators should set the offline synchronization period to be the total amount you would like documents to be viewable offline. It’s very easy to set this value large at initial deployment and then decide to tune it down later. Increasing this value is possible, but we recommend you contact Adobe support first to understand the implications and interactions in the system.


In conclusion, the “offline synchronization period” is an administrator-tunable setting that makes sure the end-user experience is always straightforward and that people can view confidential intellectual property when on an airplane, at a disconnected customer site, etc. Simply set this as the maximum time any document can be used offline from when it is initially protected.


End users who want to control access to content need only set how long they want their content to be viewable offline—and remember that it will stop being viewable offline once the “offline synchronization period” has been exhausted.

Need more information on how your organization can effectively manage and protect your intellectual property? Further information can be obtained at or by contacting Adobe

Adobe Reader and Acrobat Security Initiative

Brad Arkin here. In my role as the Director of Product Security and Privacy I’m responsible for the security of all Adobe products and services. In practice this means that I manage both the proactive work the Adobe Secure Software Engineering Team (ASSET) does as well as the reactive Product Security Incident Response Team (PSIRT) activities.
Back in December, Peleus Uhley kicked off this blog with the post, “We Care.” In that first post, he discussed how Adobe’s commitment to the security of our customers shows up in our process, our schedules, resourcing, and more. Since then we’ve talked publicly about Adobe’s overall approach to software security, our incident response process, and our support for more security tools for Adobe technologies. Today’s post shares some details about the software security activities underway with two of our best known and widely used products, Adobe Reader and Acrobat.
The recent JBIG2 vulnerability (CVE-2009-0658), the associated exploits, and Adobe’s response (APSB09-04) were the subject of much discussion in the security community in February and March. The JBIG2 issue also sparked a lot of conversation internally at Adobe from executives to testers and developers. What started out as a routine incident response expanded to a broader effort by Adobe Reader and Acrobat engineers, culminating in permanent changes to our software security approach for those products.
Since February, Adobe Reader and Acrobat engineers have been executing a major project focused on software security. Everything from our security team’s communications during an incident to our security update process to the code itself has been carefully reviewed. Security is an ongoing process, so while we believe our plan will eliminate or mitigate many potential security risks, we are also working to enhance our ability to respond to externally found vulnerabilities in Adobe Reader and Acrobat in the future.
In particular, we have focused this security effort in three major areas:

  1. Code Hardening – For the past several years all new code and features for Adobe Reader and Acrobat have been subject to our modern Secure Product Lifecycle (SPLC). The Adobe SPLC is similar to Microsoft’s Security Development Lifecycle (SDL). The Adobe SPLC integrates standard secure software activities such as threat modeling, automated and manual security code reviews, and fuzzing into the standard Adobe Product Lifecycle we follow for all projects.
    The SPLC activities have been successful in mitigating threats in new code development, but did not fully address problems in the existing code base. Therefore, an initiative in the current security effort has been focused on hardening at-risk areas of the legacy code. We’ve applied the latest SPLC techniques against these prioritized sections of each application. Even in cases where no immediate vulnerability was identified, we have been strengthening input validation on a best-practice basis. (Experience shows such validation is a powerful tool in preventing as-yet unidentified security holes.)
  2. Incident Response Process Improvements – We’ve targeted several specific areas where we are improving our incident response process. We expect folks outside Adobe will see more timely communications regarding incidents, quicker turn-around times on patch releases, and simultaneous patches for more affected versions as we move forward.
    This approach was tested sooner than we would have liked with CVE-2009-1492/1493. Although this incident fell in the middle of our security effort, we were encouraged by the progress our response demonstrated. We worked to communicate early and often via our PSIRT blog and two weeks later, on May 12, 2009, we simultaneously shipped 29 binaries to update 17 different versions of Adobe Reader and Acrobat covering 32 languages for the Windows, Mac, and UNIX platforms.
  3. Regular Security Updates – Starting this summer with the initial output of our security code hardening effort, we plan to release security updates for all major supported versions and platforms of Adobe Reader and Acrobat on a quarterly basis. Based on feedback from our customers, who have processes and resources geared toward Microsoft’s “Patch Tuesday” security updates, we will make Adobe’s quarterly patches available on the same days. (Although our March 10, 2009 and May 12, 2009 security patches landed on Patch Tuesday, the timing was coincidental. In both cases, we shipped the patches as soon as we finished testing them.)

Software security is a rapidly evolving field and we are always on the lookout for ways to best adapt to the changing threat landscape. In developing this new approach to product security for Adobe Reader and Acrobat we’ve leveraged lessons learned by our friends and partners in the community. We look forward to continuing the conversation in person at some upcoming security conferences.
Watch this blog for more details as work progresses.

Seven Technology Habits of Highly Effective CFOs

Recently, Adobe executive vice president and Chief Financial Officer Mark Garrett presented a keynote at the CFO Rising conference, sponsored by CFO Magazine. Speaking to a ballroom full of senior finance executives, Mark outlined the “Seven Technology Habits of Highly Effective CFOs” and utilized several case study examples to illustrate his points.

Continue reading…