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.
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:
No comments:
Post a Comment