Java vulnerabilities are clearly on the rise, and currently consist of more than 10 percent of all reported vulnerabilities this year and are reported to be the root cause of the Facebook and Apple hacks.
(See graph on number of java software flaws by year: http://web.nvd.nist.gov/view/vuln/statistics-results?cves=on&query=java&cwe_id=&pub_date_start_month=-1&pub_date_start_year=-1&pub_date_end_month=-1&pub_date_end_year=-1&mod_date_start_month=-1&mod_date_start_year=-1&mod_date_end_month=-1&mod_date_end_year=-1&cvss_sev_base=&cvss_av=&cvss_ac=&cvss_au=&cvss_c=&cvss_i=&cvss_a= )
If it was possible, we would have advised administrators to disable java on all browsers, but generally speaking, having IT administratively disable ANY software component on “all user machines” is nearly impossible, especially on today’s Bring You Own Device (BYOD) IT environment. The current case of disabling Java components is no different.
The lesson the world should have already learned from incidents such as the Stuxnet attacks is that protection should be around data rather than around devices. Closely monitoring and controlling data at the source is one part of the solution. Looking for abusive access patterns to data or patterns that reflect the behavior of an outsider within our perimeter is the answer. Coupled with data encapsulation, organizations can achieve true mitigation of such risks.
Additionally, individual users should turn off Java 7 browser plug-ins and only enable them specifically to trusted site (such as the mentioned “Java-powered line of business applications”). See the following link for instruction on how to do so in Google’s Chrome browser: http://support.google.com/chrome/bin/answer.py?hl=en&answer=1247383 .