Friday, January 11, 2013

“Experts” who tell you to do dumb things…

…are not experts.

We have just had another round of Internet Explorer and Java bugs announced in the past weeks, followed by another rounds of so-called experts telling everyone to stop using IE and Java.  This is pointless, and counterproductive, and an indication that these “experts” probably have no practical experience in a business environment.

I doubt that anyone who pays attention to security advice is running Java, IE 6/7/8, et. al. because they want to- we run these things because we have to, and the decision is out of our control.  Anyone who doesn’t understand this doesn’t understand enough to give advice.

Yes, there are a lot of people running old, vulnerable crap they don’t need.  They aren’t listening to the InfoSec echo chamber, so don’t bother trying to reach them there (here).

It’s like the folks who dumped Adobe Reader in favor of Foxit for security reasons- now scrambling to patch the latest critical vulnerability in Foxit.  I dumped Adobe Reader in favor of Foxit because I find it faster and lighter, and because of a general loathing of Adobe.  I do have to update it less frequently, but I believe that is largely due to the reduced market share relating to reduced value to attackers- much like OS X has never been “secure”, but historically it hasn’t been as targeted as Windows.

I see two central problems feeding this issue: “dump X” is a compelling headline, reality isn’t; and the ever-present quest for simple solutions to complex problems.

Here’s my advice, which you probably already know:

Dump *anything* you don’t use.  Dump anything with a proven track record of failure which you don’t need (for example, if you don’t need Java, uninstall it).  That’s the easy bit, the rest requires thought and effort. If you need Java for desktop apps, but don’t need Java in your browser- disable the browser plugins. 

If you have to support vulnerable browsers or other apps- restrict their access to only the resources which require them and use other apps or browsers for “normal” use.  Or have limited use systems if you can get away with it.  These introduce pain of their own, but can be done.  Configuring proxy settings in the browsers (or possibly mis-configuring) may be a relatively easy way to control browsers depending on the situation (or it may completely break networking for the systems).

And all the other stuff you already know:

Reduce use of admin-level permissions wherever possible, especially domain admin, and especially where you know you are supporting insecure systems.

Improve authentication- this may mean using all eight characters the crappy app allows, or maybe you can move to two-factor, or something in-between.

Crank up the logging.  Crank it up to eleven on the likely targets, and then (here’s the tricky part) actually look at those logs.

And finally, my comment to those who propose naïve and stupid things like this:

“Shut up. Just shut up.  If this were easy, even you could do it.”

 

Jack

9 comments:

Robert Graham said...

I'm not sure, because the same applies to smart advice. Any security advice telling people what to "do" ignores a subset who cannot comply. Better advice is about what's happening.

Take "don't open unsolicited attachments", for example. Some people have to. A better tip would be "infectious emails often come from people you know and trust", thus educating people about the problem, leaving it open-ended what to do about it.

Thus, good Java advice would be something like "Java browser 0days have been in constant circulation for years, even when the current one is patched, there's likely an unpatched 0day in use". Leave it up to the defender to decide how to respond.

...except for the fact that defenders don't want to be educated. They don't want to think. They want to be told what to do. Thus, we've gone full circle back to where we've started: the only advice that can make a difference is where I tell people what to do, even though I know full well many (if not most) can't actually do it.

Thus, I'll freely tell people "disable Java (in the browser)" even though I've never had a customer that can follow that advice. It's the easiest way I can communicate the danger without their eyes glazing over. And what I hope from this is that the next time they have to decide on a product, they avoid the one that requires desktop users to have Java enabled.

BTW, I disable Java and Flash in my default browser (Chrome) that I use to browse the Internet. I have it enabled in Internet Explorer, which I use only when confronted with a site that requires Java, Flash, or IE.




Jack Daniel said...

Sure, show me up with all your "reason" and such...

Great comments Robert, thank you.

Robert Graham said...

But I agree 100% with your blog post. "Expert" should mean having experience in the real world and not just opining from an ivory tower like so many do.


rudehimself said...

I've spouted off about Java plenty. Today as a matter of fact. And some people might be giving an over simplified perspective that doesn't apply necessarily to the enterprise. In those cases I would recommend a responsible (not instant) migration away from development and deployment of applications that depend on something with the exploit and remediation track record that Java has. That would also mean that someone would have to evaluate those similar pieces of software in that fashion: quality of code, vendor responsiveness, etc. It makes sense to me to start the discussion and take those baby steps, sometimes the patient needs shock therapy to get started.

D0n Quix0te said...

I suspect that these "experts" that recommend simply disabling or uninstalling JAVA in the enterprise have no idea what it actually takes to do that, or the incredible disruption and fallout it causes.

I am tempted to think that these are the same class of "experts" that have also at various times recommended getting rid of A/V, Firewalls, and Defense In Depth. It's hard for me to imagine that a person who recommends those actions actually has to defend a network.

Don't get me wrong, those things DO all have various and sundry problems. They DO NOT work 100% of the time, and there are cases that can make them innefective. But when their strengths and weaknesses are understood and they are leveraged for for their strengths, they DO absolutely stop attacks.

This is the nature of the security arms race we are in. The fact is, that as soon as an effective defense can be created for a vuln, the bad guys simply invent another way to effect a compromise. I think there are some clear reasons why that is - and if you have insomnia, you can read about my thoughts on that at:

http://musectech.com/CompSec.html

Security is not an on off switch. The issues cannot simply be solved by doing some set of defined actions. We have learned that lesson all to well already in the shortcomings of compliance regimes. Yet, when used as a starting point, compliance can be extremely useful.

As long as we understand that defending networks is an evolving process that requires defenders to understand their attackers, and the attack methods, and CONSTANTLY adjust accordingly.

We cannot simply push a button and be secure, because security is ever evolving - where we loose a battle and win another. The trick is to find a way to keep the ground we gain, not to simply give up when we lose a battle.

Just my $0.02
YMMV
MSRP

Martin D Zimmermann said...

Well, I completely agree that come monday morning just "pulling the plug", and think that will solve anything in unrealistic. And yes the other newer alternatives will naturally also in turn be vulnerable to exploitations. Nobody's perfect, nothing is 100% safe. There are no easy solutions to either Java, Flash or in some cases IE (or pdf's etc.).


But I so think that we should perhaps take into consideration, a few things regarding Jave. Oracle is a "repeat offender" in terms of security, and I honestly do not think that it bothers them? Their 'security culture & awareness" is in my own, and many other Info-Sec professionals simply not doing very well. And it has been "ill" for a long time, and show no signs of improving!

I must admit that I for long, has held the opinion that their approach to security and the safety of their clients, just do not appear to be seriously addressed. Today we (once again) learnt, that Oracle has been aware of the current vulnerability since May 2012. This is not the exception for Oracle, but the norm.

So I am afraid I belive it is not a wise decision to implememt Java in _new_ builds. I naturally understand, that my current online banking system rely's on it. And I am not calling for the termination of Java's lifecycle on Monday morning! That is as you say, unrealistic.

But choosing to utilize Java in your _next_ build/project, would be a mistake and I feel unwise! Why would you? It is a flawed technology, and unfortunately it's also in the wrong 'hands/place' (Oracle!). and I believe that the time to move on and discontinue Java's life-cycle has come.

It was a important part of the beginning, but are now not contributing but detracting to the "common good". And Java has as other technologies before in human history, served it's purpose and we should move on to the new and better alternatives.

Jack Daniel said...

Some great comments, thank you all.

A common thread in these and other comments is that with the track record of some project (Java in this case, but it applies to others as well), those creating or updating systems need to consider better alternatives- and I could not agree more.

Mr. Himself- indeed, shock therapy is frequently needed. I enjoy applying it myself- but as you imply, after the jolt the patient needs ongoing care

Matthew Conley said...

Like how our military uses OWA for its email. I have to log in every once in a while with IE, so I can clear out my inbox. Such a pain.

PS I hate these capcha's.

Clive Robinson said...

The first problem is business (as in walnut corridor) want's simple, fast, and zero cost infrastructure that acts as an enabler today.

The second problem is that the users likewise want simple but they also want what they know, they don't like change, it's unsettling, by and large all they realy want to do is come to work, do their job go home at a reasonable time and meet their targets at the end of the month etc.

Somewhere in the middle are those providing the technology and whos various jobs are to meet the expectations of managment aspirations and workers "just leave me to do my job" pleas.

The only thing the workers and managment appear to have in common in their requirments is "simple", that word generaly does not appear in the requirments of those in the middle, but as we know they/we crave a little of it along with peace, tranquility and the occasional thank you...

Thus simple is one of our weakness that amongst others sales people play upon and like the mole we fall for it every time and put our heads up and low and behold get whacked...

The "simple" fact is there is no simple way to solve the problems of all the parties concerned. And worse the attackers are more fleet of foot than the defenders, because the reality is the defenders are outnumbered.

It's a bit like the Viking marauders there might only be a boat load or two of them at most but they only attack small villages and then disapear to attack somewhere else before defenders can organise themselves.

So it's a numbers game you will be attacked you don't know when or how and you know that at some point they are going to get through your defences.

The only sensible thing to do is work out how to mitigate the potential damage, that is how to contain it and minimise it's impact.

A sensible strategy would be to migrate away from risky technology, many would regard the products of Oracle and Adobe to be "to risky" these days. The problem is you cann't migrate away from them because the users don't want to change what works for them and managment want new ways that unfortunatly the developers of which are going to use these risky products to keep their costs down.

This is always going to be the case thus other routes need to be followed.

The problem is applications have become multitasking operating systems in their own right but without the operating system security. The attackers thus mainly don't bother with attacking the underlying OS it's the OS like Apps they attack such as browsers.

I've effectivly ruled out migration as a defensive strategy and "turn it off" is the part of migration that just does not work. I did however mention two other words "contain" and "minimise".

You can do both by stopping apps behaving like 1980's OS's.

One way that works was mentioned by Robert Graham above with how he configures his browsers. But it is only a small step in the direction I hope people will start to look.

Think about running each app in it's own VM with the VM OS locked down hard to not just that app but the specific task it's doing.

That is in many businesses the web browser is the portal to not just internal databases and applications but to external ones as well as personal ones. Why use one browser that has to have everything enabled in an OS that's effectivly open to the world?

As Robert suggests use multiple browsers configured for each app, but also run them in their own VM where the OS is also shutdown for just that app.

I could go on and sell other advantages of doing things this way, but I will also say it's not for everyone it has it's issues but it does contain and it does minimise impact when attacked, which makes clearing up the mess that much easier.