Featured Quote

In 1913, Henry Ford wrote the following as the directors had been reaping the rewards of profits - "The wages we pay are too small in comparison with our profits. I think we should raise our minimum pay rate".

Thursday, October 31, 2013

Oracle has made Java Enterprise Friendly!

I can securely manage multiple Java versions across an entire enterprise with minimal initial 'pain points.'


Finally!!

From Java 7 Update 10 forward, Oracle has instituted some intense security.  This has totally screwed with enterprise java deployments.  Many organizations have not bothered to update to Java 7 at all.  Which is a problem, because in April, 2013, Oracle stopped issuing updates for version 6, leaving open vulnerabilities to be exploited.

Oracle introduced the Security Baseline JRE version.  Before running any app, java will attempt to verify that the version of java on the computer is at or above the baseline version.  If it is not, security dialogs will pop up and the app may be blocked!

From Java 7 Update 10 forward, every version has a hard-coded expiration date.  When that date passes and Java has not been updated, Pop-ups attack!!

The default security level is “High”:
·         Very High - Only apps signed with a valid certificate are allowed to run. Everything is prompted to approve.  If java is outdated, you can’t run any app.
·         High - Signed apps can be run, self-signed can be run in the sandbox as long as the JRE is up to date.  Unsigned are allowed in the sandbox with multiple verification prompts.
·         Medium - Allows running of apps even if JRE is out of date, but has prompts to inform and verify.

Oracle has finally given some relief to Enterprises as of Java 7 Update 40 - and I just found out about it!

“A new feature in Java 7 Update 40 is aimed at ameliorating this predicament. It's a change to the local security policy that allows large customers to specify a limited number of apps that will run on older versions of Java. Now known as a deployment rule set, the new instructions use a digitally signed certificate to whitelist specific apps, often referred to as JARs or java archive files. Those not on the list will be dropped, or possibly run on the latest Java version.”

To take advantage of the Deployment Rule Set, We need to know every website or java applet that we need to Whitelist for our end users in order to create the ruleset.xml, a Java Developer’s Kit installed, a Code Signing Certificate and to distribute the “DeploymentRuleSet.Jar” file to all endpoints. 

The initial pain comes from doing a blanket block of all unknown java applets and vetting the ones that users call in to request access to.  Of course, you want to find out as many of the internal URLs that run java apps and as many of the business-need URLs that users have to have as possible, but you will miss some.  Users will call in, the .xml will have to be updated and the .jar will have to be rebuilt and re-sent.
 
Within the ruleset.xml, we can whitelist a java applet to run without prompts (unless the certificate has been revoked), block it or just use the default settings.  We can also set which version of the JRE to use, so we can identify apps that require older versions and set those to use those versions.  This means that we do not need to uninstall older versions – we can force any unlisted app to use JRE 7 or simply be blocked, while sending only those applications that require older versions to their specific version.

I find this very exciting!
Online Documentation Resources: