Java Security Flaws: Wake-Up Call for DevOps

At the best of time, IT departments have a hard time keeping up with patches and updates necessary to fix security holes. With the emergence of the DevOps role, responsibility for maintaining a vigilant watch may have shifted onto new shoulders, but with the rise of new PaaS technologies comes a new level of automation that can ease the burden and help ensure effective compliance.

A Java Wake-Up Call

Recently, Oracle had to rush in and make urgent updates, after Homeland Security issued a warning about a Java security breach. Corporate IT departments went in to action to apply a patch to PC and Mac computers to fix a very real Java security flaw that hackers had a field day exploiting. Technorati across blogosphere went into a frenzy reporting the flaw, ensuring that everyone was made well aware of the seriousness of the security breach.

What’s the Big Deal?

The Java security flaw allowed users to run unsigned Java applets in browsers on their laptops and mobile devices, which in turn opened up an opportunity for hackers to inject Java applets with nasty bits and exploit devices on Windows, Mac and Linux operating systems alike. This flaw presented a problem with all Java installations, including client, server, and embedded. However it was most exploitable on clients.

The flaw known as “Oracle Java Runtime Environment Unspecified Remote Code Execution Vulnerability (CVE-2013-0422)” was available and distributed through the Cool Exploit pack and other similar packs. Symantec reported about 300,000 attacks per day, predominantly targeting PC users located in the United States.

In addition to releasing the Java 7 Update 11, Oracle modified Java 7 to automatically reset it to the “High” security level. At that setting, Java notifies users before they can run unsigned Java applets. While this doesn’t ‘fix’ the hole, it does ensure that the user is aware that they are allowing an unsigned applet to run if they chose to do so.

Some security gurus criticized Oracle’s response time and highlighted a perceived failure to respond to earlier warnings. While Oracle maintains a vigilant watch over Java, it is a challenge to keep up with all Java security breaches. Less than twenty-four hours after patching this Java security hole, Oracle had to deal with yet another vulnerability in Java that still remains unpatched to this day.

The “New” Normal: Hooked on Java

Java lives and breathes under the hood in just about every PC in the world, as well as hundreds of millions of mobile devices including Android. Java is also deeply embedded in enterprises’ web applications and infrastructure. We are all hooked on Java.

For most non-Homeland Security level warnings, users usually notice a pop-up JRE update message pushed up to the surface by the software they download onto their mobile devices, laptops, or embedded into an application deployed on the cloud. For these client-side updates, the onus is on users to acknowledge the warning, download the patch, and set the update install. IT is responsible for making users aware that they must take action.

These days, it is relatively easy to patch clients en masse with the right tools. Most enterprises have a variety of configuration management tools such SCCM, Absolute Manage, BigFix, Altiris, KACE, and a host of other small players. These tools provide enterprises remote control to manage patches, distribute software, handle operating system deployment, coordinate network access protection, and maintain hardware and software inventories.

What is rapidly changing is how those applications are delivered to the enterprise end-users. In today’s enterprises, the applications are no longer running on desktops. Instead, they are hosted in clouds and delivered via a SaaS-based model, which brings new challenges. It becomes difficult to update application back-ends to apply a patch, as bringing down a custom enterprise SaaS application can affect an entire organization’s workforce if not done properly.

Time to Rethink Enterprise Application Deployment Strategies

As the IT world moves to a SaaS-based approach to satisfy corporate demands for mobile-aware services and deploys more custom enterprise applications, maintaining and updating versions of the languages such as Java, frameworks, components, libraries, database and other services is a daunting compliance challenge.

These patches are not limited to client side updates. A quick look at past year’s Oracle critical patches and security alerts shows a wide range of databases, languages, and other Oracle products. This is just Oracle’s list, but when updates from all vendors, open source projects, and other critical components are considered, it becomes overwhelming.

Winning the Security Compliance Battle with Private Paas

Recently, private Platform as a Service (PaaS) greatly simplify IT’s compliance requirements for security and other updates. To fully take advantage of the benefits offered by PaaS, IT must first rethink application deployment strategies. One of the benefits of a PaaS environment is that it is easy to update components parts of the PaaS on IT’s own schedule and with no disruption to end users. Private PaaSes simplify both the deployment and management of applications, and a any well-built PaaS incorporates functionality that eases the burden of applying patches and updates.

In a multi-tenant PaaS architecture such as ActiveState’s Stackato, each application runs within its own container built at deployment time. The container is based on the application’s requirements and configuration manifest, and incorporates components available on the stager (if a buildpack is used). Depending on the patches, PaaS provides automated processes for applying updates without interrupting service to end-users.

IT can simply redeploy SaaS applications with a new buildpack that includes the updates. The PaaS will re-direct users to the new end-point as soon as it is live, allowing IT to delete the older versions of the applications without any service outage.

To future proof the entire Private PaaS cluster, all is needed is to update the PaaS with new releases. This will ensure that any future applications deployed via the staging process includes the updates.

These steps can be performed with zero downtime for the applications, as the PaaS redirects traffic to the newer worker daemons and allows the older ones to gracefully be depreciated. The IT department gains the ability to push updates without service interruption., and individual employees no longer need to update their own applications.

While the Private PaaS approach works nicely for covering the back-ends of cloud-hosted SaaS applications, IT still needs to use enterprise configuration management software to update the myriad of mobile devices and desktops that connect to SaaS applications. However, by deploying SaaS applications in a Private PaaS, IT will exponentially improve the odds in the battle to keep patches up to date and ensuring that any new application deployed will use the updated releases of languages, libraries, frameworks and other stack components.