lumension 2013apr wp takingthestingoutofjavavulnerabilities 0

10
April 2013 Taking the Sting out of Java Vulnerabilities Java vulnerabilities have dominated the security headlines. Some observers now say organizations should simply turn off the ubiquitous software platform. But what if there were a better way? WP-EN-04-10-13

Upload: andyayam

Post on 12-May-2017

222 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Lumension 2013Apr Wp TakingtheStingOutofJavaVulnerabilities 0

April 2013

Taking the Sting out of Java Vulnerabilities

Java vulnerabilities have dominated the security headlines. Some

observers now say organizations should simply turn off the

ubiquitous software platform.

But what if there were a better way?

WP-EN-04-10-13

Page 2: Lumension 2013Apr Wp TakingtheStingOutofJavaVulnerabilities 0

Taking the Sting out of Java Vulnerabilities

1

So far, 2013 hasn’t been a good year for Java security.On January 13, Oracle issued a Java update to stop

a zero-day exploit already in the wild. By the 18th,

two security holes had been found in the update.

On February 1, Oracle released patches to address

50 separate security issues, with at least one ex-

ploit in the wild. On the 19th, it pushed out another

patch for an additional five problems. Six days later,

two more vulnerabilities were uncovered. The 28th

turned up another hole, which has been exploited

by the McRat Trojan. On March 4, five more chinks

were found in the Java armor. And so on.

This history was chronicled by InfoWorld, which

counted eight new Java zero-day issues in less

than a week’s time. The news source later reported

that only 5 percent of browser installations use the

most current version of the Java plug-in.

Clearly, organizations need to address Java security.

Simply turning off Java probably isn’t an option for

most organizations, because many legitimate busi-

ness applications rely on the plug-in. And in the long

run, focusing exclusively on Java won’t significant-

ly improve your security posture, because Java is

merely a delivery mechanism for malicious attacks.

What’s needed is a more considered, holistic ap-

proach. A defense-in-depth strategy, with overlapping

layers of protections, backed up by flexible application

whitelisting, to address, not just Java vulnerabilities,

but the security profile of your entire IT infrastructure.

Ubiquitous—and UnprotectedJava is a software platform originally developed by

Sun Microsystems and now owned by Oracle. It’s

designed to operate across operating systems such

as Windows, Mac OS and Linux. Java plug-ins add

functionality to a broad range of applications, and

they’re often required to allow crucial business and

cloud-based technologies to function. The Java

Runtime Environment is found on more than 850

million PCs, according to Oracle.

Java security is built around a “sandbox” model.

The idea is that users can download a Java ap-

plet that will run in their browser in a protected

area, where malicious code can’t do harm. In

this way, Java allows for the delivery of robust

and dynamic Web content, theoretically without

a high security risk.

Partly as a consequence of this security approach,

Java browser plug-ins are commonly installed

and enabled by default. As a consequenceresult,

a vulnerability in Java typically affects virtually all

browsers running across all operating systems in

an organization. And because the vulnerability is

browser-based, all it takes is for a user to click on

a link or go to webpage to fall victim to an exploit.

Perpetrators take advantage of Java vulnerabilities

to defeat Java’s sandbox security model to run mali-

cious code or alter privileges. As of early 2013, there

were 1,342 Java-related security issues spanning 129

separate software products, according to Secunia. For

Java specifically, there were 66 security issues.

Page 3: Lumension 2013Apr Wp TakingtheStingOutofJavaVulnerabilities 0

Taking the Sting out of Java Vulnerabilities

2

From Bad to WorseOf course, all software is subject to vulnerabilities.

But some observers have questioned whether Or-

acle is investing adequate time and effort into se-

cure coding practices. What’s more, the company

appears to have focused only on patching exploits

known to be actively used. As a result, there has

been a backlog of unpatched vulnerabilities. Some

vulnerabilities discovered in 2012 remained un-

patched in the first quarter of 2013.

Notably, Apple has apparently taken the path of

least resistance by deciding to simply disable Java

in the Safari browser and blacklist older versions.

Rather than proactively working with Oracle to ad-

dress vulnerabilities, or independently addressing

Java vulnerabilities and including them in Safari

updates, Apple has evidently made a decision on

behalf of Safari users to disable Java.

The move follows an incident in March 2012 when

Apple fell out of sync with Oracle on Java patching,

leaving users exposed to vulnerabilities. As a re-

sult, some 600,000 Apple users were infected with

the Flashback Trojan. Apple fell out of sync again

in September 2012 when it issued a patch that ad-

dressed one known Java vulnerability, but over-

looked at least one other. Since that time, Apple

seems to have ceased including Java patches in

its own security updates, instead advising users to

obtain Java patches directly from Oracle.

Rejecting Java?If Java is plagued by vulnerabilities, should organi-

zations simply stop using it? Some observers have

recommended this approach. But turning off Java

wouldn’t be as easy as it sounds. And it ultimately

wouldn’t solve your security issues.

First, many legitimate business applications require

Java to function properly. If you eradicated Java

from your organization, how many of your users

would launch a needed business application—to

participate in a WebEx conference call, as just one

example—and find it didn’t work? There’s no ques-

tion it could have a negative effect on productivity.

And ironically, some data-security solutions re-

quire Java. In your efforts to avoid vulnerabilities,

turning off Java could actually expose you to other

security threats.

Second, how certain could you be that you had

removed all instances of Java? In today’s dynam-

ic computing environments, where each user is

equipped with multiple endpoint devices, all regular-

ly accessing the Internet and downloading new soft-

ware, do you have a reliable means of monitoring

what’s already running and what’s newly installed?

Finally, eliminating Java does nothing to solve the

ongoing issue of third-party software vulnerabili-

ties. Java is merely a delivery mechanism, one of

many potential attack vectors. In lieu of Java, per-

petrators would simply target the next most popular

third-party software. (See Figure 1.)

Page 4: Lumension 2013Apr Wp TakingtheStingOutofJavaVulnerabilities 0

Taking the Sting out of Java Vulnerabilities

3

Figure 1: Top 10 Most Vulnerable Software Products, 2011-2012

Source: Secunia Vulnerability Review, 2013Among the 50 most popular software products, these 10 had the highest number of common vulnerabilities and exposures (CVEs) in 2011 and 2012.

Adobe Flash Player

Oracle Java JRE SE

0 50 100 150 200 250 300

Google Chrome

Adobe AIR

Microsoft Windows 7

Mozilla Firefox

Apple iTunes

Adobe Reader

Microsoft IE

Apple QuickTime

291

257

243

67

66

56

50

43

41

29

Number of Vulnerabilities

We’ve seen this before. A few years ago, Micro-

soft Windows was the most common target. Then

perpetrators began expanding to widespread third-

party applications such as Adobe Acrobat Reader.

In fact, for the 50 most popular software products

in 2012, 86 percent of vulnerabilities were found

in third-party applications, according to Secunia.

That’s a notable increase over the 57 percent re-

ported in 2007 and the 78 percent noted in 2011.

(See Figure 2.)

Today it’s Java. Tomorrow it could be another ap-

plication, or thumb drives, or smartphones, or

whatever other means perpetrators can find for de-

livering their malicious payloads. If you discarded a

technology every time it was revealed to have vul-

nerabilities, you’d continually erode user satisfac-

tion, hamper productivity and constrain your busi-

ness. By focusing security on delivery mechanisms

such as Java, you’d be locked in an arms race you

couldn’t possibly win.

Continued »

Page 5: Lumension 2013Apr Wp TakingtheStingOutofJavaVulnerabilities 0

Taking the Sting out of Java Vulnerabilities

4

Practical StepsThe solution calls for a more strategic approach

than simply turning off Java. But there are also

practical, near-term steps organizations can take

to address Java vulnerabilities.

First, ensure that all Java plug-in instances are

patched on an aggressive schedule. Next, make

sure your endpoints are appropriately configured

so that only endpoints that truly require Java are

permitted to run it. Third, to the extent possible,

isolate mission-critical systems from the produc-

tion environment.

Finally, for Java, as well as any third-party applica-

tion that’s amassing a history of vulnerabilities, ask

yourself these questions:

1. What’s our business need for the application?

2. How would removing the application affect our

users?

3. How would removing the application affect our

business?

4. Should we remove the application from our

production systems or another mission-critical

or protected environment?

5. What’s our overall appetite for endpoint-secu-

rity risk?

The answer to these questions will guide your deci-

sion making around which applications you allow

on your endpoints.

Figure 2: Share of Vulnerabilities by Source

Source: Secunia Vulnerability Review, 2013For the software most commonly found on endpoints, the lion’s share of vulnerabilities appear in third-party applications.

Continued »

Page 6: Lumension 2013Apr Wp TakingtheStingOutofJavaVulnerabilities 0

Taking the Sting out of Java Vulnerabilities

5

Making a (White) ListThe most effective, long-term solution to Java vul-

nerabilities is not to address the delivery mecha-

nism, but to embrace a layered security strategy.

Central to such a strategy is application control in

the form of application whitelisting.

Realistically, no organization can instantly patch

every new vulnerability or block every new ex-

ploit. You can remove Java where it isn’t needed,

you can remediate Java vulnerabilities as soon as

patches become available and you can deploy an-

tivirus (AV) to block known malware. But, you can’t

avoid every vulnerability and every attack.

The solution is application whitelisting. Whitelisting

prevents unrecognized or unapproved executables

from running, period. Any malware that reaches

your environment won’t be trusted by your whitelist-

ing solution, so it simply won’t be permitted to run.

It doesn’t matter whether you’re attacked through

a Java vulnerability or some other vector is effec-

tively irrelevant, it can’t run.

In the past organizations sometimes rejected

whitelisting because it was too restrictive. The

traditional whitelisting approach was to limit any

change to the environment. No user was permitted

to run any application that wasn’t already on the

approved whitelist.

But more sophisticated whitelisting solutions al-

low for the flexibility often required in today’s more

dynamic IT environments. They do this by imple-

menting a trust engine that allows automated trust.

Such a solution can be configured to trust an ap-

plication based on the vendor that digitally signed

it, the updater that’s attempting to install it, or the

application’s path or location.

For example, you would configure your whitelisting

solution to trust any executable installed by your

centralized patch-management solution. On the

other hand, you might set it not to trust any ap-

plication installed by a browser or an email client.

Such intelligent whitelisting enables you to establish

anything from complete lockdown, to a very open and

flexible model, depending on what meets your needs

and your appetite for risk. You can achieve an ap-

propriate level of automated security without a corre-

sponding impact on the productivity of your business

users and overhead on your security administrators.

Beyond a trust engine, a whitelisting solution should

offer memory or DLL protection. An increasingly

common security exploit is to inject malware directly

into memory or in the address space of a trusted

process, rather than try to write it to disk. Traditional

whitelisting, which only looks at code written to disk,

offers no protection against such an attack.

An effective whitelisting solution should include

a cloud-based service to identify and report new

applications that have been installed on your end-

points. That way you can keep track of what’s

showing up on your endpoints. And you have the

ability to dynamically block an application that

doesn’t deliver business value or that introduces

unacceptable risk.

Page 7: Lumension 2013Apr Wp TakingtheStingOutofJavaVulnerabilities 0

Taking the Sting out of Java Vulnerabilities

6

Deep-Dive DefenseApplication whitelisting is part of a defense-in-depth

approach to endpoint security that also includes AV,

device control, media encryption, and patch and

configuration management. (See Figure 3.)

Defense in depth is a lot like the defensive play-

ers on a soccer team. Midfielders are a first line of

defense. Wingers play the sides of the field. A stop-

per guards against the opponent’s best scorer. Full-

backs protect closer to the goal. A sweeper might

be deployed behind all other defenders. A goal-

keeper is the last line of defense. No single posi-

tion can be expected to block every attempt on

goal. But each position has a crucial role to

play. And together, the defensive unit can

be very effective at keeping the score as

near to zero as possible.

AV—Effective AV quickly and accurately iden-

tifies all known viruses, worms, Trojan horses,

rootkits, keyloggers, spyware and adware. It

also employs multiple detection techniques to

identify and block zero-day exploits. In the con-

text of Java security, it should blacklist outdated

plug-in versions.

AV should combine traditional signature-match-

ing capabilities with newer heuristic-based ap-

proaches such as partial pattern matching, be-

havioral analysis and general exploit detection to

provide the most proactive protection. It should

also enable granular policy management, with

the ability to schedule multiple AV scans per end-

point with various scan settings and times.

Device control—Device control lets you set

rules about what kinds of devices can be con-

nected to an endpoint. Those rules can be gran-

ular, addressing type, brand and even individual

USB drive.

Effective device control centrally automates the

discovery and management of removable de-

vices. It defines and enforces device use and

data-encryption policies by group and by user,

with flexible exception management. By cen-

trally applying encryption, it ensures that lost or

stolen devices or media can’t be accessed. It

should also capture detailed forensic informa-

tion to track data events.

Figure 3: Defense-in-Depth Architecture

A defense-in-depth approach to endpoint security can effec-tively protect against attacks that exploit third-party application vulnerabilities.

Page 8: Lumension 2013Apr Wp TakingtheStingOutofJavaVulnerabilities 0

Taking the Sting out of Java Vulnerabilities

7

Integrate to WinFundamental to good defense in depth is seamless

integration among layers. (See Figure 4.) Siloed

security solutions are less effective, they place

a greater administrative burden on your security

staff, and they can result in a performance hit on

your endpoints.

An integrated security suite ensures a flexible,

modular approach to endpoint security. It gives you

one management console, for a single view of the

enterprise. And it provides interlocking defenses

that enable true risk mitigation.

You can’t control Java’s vulnerabilities, other than

to apply patches as soon as they become avail-

able. Neither can you control the security track re-

cord of any of the third-party applications that pop-

ulate your endpoints. What you can control is your

strategic approach to endpoint security. And with

a defense-in-depth approach built around effective

application whitelisting, you can continue to benefit

from Java while achieving the security profile that’s

right for your organization.

Hard-drive and media encryption—Hard-drive

and media encryption secures all data on end-

point hard drives. IT also provides single sign-on

to Windows and enforces secure, user-friendly

preboot authentication. It quickly recovers for-

gotten passwords and data. And it enables auto-

mated deployment, management and auditing.

Application control—With application control,

executables don’t run unless they come from a

trusted source. Attack vectors, such as Java,

effectively become irrelevant. Even if malware

gets through the perimeter, if it can’t execute,

you remain protected.

Patch and configuration management—Patch

management remains one of the most effec-

tive means of thwarting attacks. The premise

is simple: Reduce the known vulnerabilities in

your environment to minimize the exploitable

surface area. For Java and for all third-party ap-

plications on your endpoints, follow an aggres-

sive patching schedule to minimize exposure to

zero-day exploits.

To that end, centralized patch management is

key. Without a centralized solution, you need to

rely on multiple individual updates from Adobe,

Apple, Oracle and other third-party vendors.

That becomes impossible to manage, it can de-

grade endpoint and network performance, and it

assumes users aren’t turning off auto-updates—

and exposing you to risk.

Continued »

Page 9: Lumension 2013Apr Wp TakingtheStingOutofJavaVulnerabilities 0

Taking the Sting out of Java Vulnerabilities

8

Figure 4: Integrated Defense in DepthThe crux of effective endpoint security is that all safeguarding technology be integrated to achieve truly layered, defense-in-depth security.

Page 10: Lumension 2013Apr Wp TakingtheStingOutofJavaVulnerabilities 0

Taking the Sting out of Java Vulnerabilities

9

About Lumension Security, Inc.Lumension Security, Inc., a global leader in endpoint manage-

ment and security, develops, integrates and markets security

software solutions that help businesses protect their vital infor-

mation and manage critical risk across network and endpoint

assets. Lumension enables more than 5,100 customers world-

wide to achieve optimal security and IT success by delivering a

proven and award-winning solution portfolio that includes Vul-

nerability Management, Endpoint Protection, Data Protection,

Antivirus and Reporting and Compliance offerings. Lumension

is known for providing world-class customer support and servic-

es 24x7, 365 days a year. Headquartered in Scottsdale, Arizona,

Lumension has operations worldwide, including Texas, Florida,

Washington D.C., Ireland, Luxembourg, Singapore, the United

Kingdom, and Australia. Lumension: IT Secured. Success Opti-

mized.™ More information can be found at www.lumension.com.

Lumension, “IT Secured. Success Optimized.”, and the Lu-

mension logo are trademarks or registered trademarks of

Lumension Security, Inc. All other trademarks are the prop-

erty of their respective owners.

Global Headquarters

8660 East Hartford Drive, Suite 300

Scottsdale, AZ 85255 USA

phone: +1.480.970.1025

fax: +1.480.970.6323

www.lumension.comVulnerability Management | Endpoint Protection | Data Protection | Compliance and IT Risk Management