Attack-driven defense | Hacker News Reader

Attack-driven defense

slideshare.net

96 pointsaustengary12 comments

A couple of points:

a) "Java is not secure in the browser" -- I think that this is disingenuous. There is a lot of high-grade corporate software being written in Java for the browser without any security issues (IBM does this a lot). I don't think Java is inherently any more insecure than something like Javascript XSS or plain-old HTML injection attacks. As a matter of fact, Java tends to jump through many annoying hoops (see security policies[0]) that further remedy this problem. I'm not saying you should be using Java in web-apps, but that singling out (Java == insecure) is simply not true from a pragmatic point of view.

b) Phishing not really covered enough[1]. I think that this is one of the major (MAJOR) problems that larger companies have security-wise. It's not that the IT guys aren't setting up firewalls properly, but rather that some marketing ding-dong is voluntarily giving away his passwords.

c) This is related to (b), but social engineering, much like phishing, is a bigger problem than "iterating attack patterns" (yawn). The run-of-the mill non-techie people need to be educated and trained into how to be vigilant and security-conscious. You can do all the drills you want, if Bob from accounting simply hands over his credentials to bad guy X, it's all for naught.

I really do like the anomaly awareness idea though. I think that might even be a great start-up idea. Have a service that logs "anomalies" -- it simply does statistical analysis on various information (like login patterns), and when something "weird" happens (i.e. exceeding some set deviation), it alerts the security people.

[0]: http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?top...

[1]: http://slashdot.org/topic/bi/brute-force-and-social-engineer...

"There is a lot of high-grade corporate software being written in Java for the browser..."

The problem is the less than stellar sandboxing which allows non-high-grade software of dubious origin and function to run arbitrary code via the plugin on the underlying system. That puts it somewhat outside the spectrum of damage the typical XSS or HTML injection does; usually phishing or session hijacking.

Aside from security, users hate (including myself) if a webapp requires Java on the client side. That's just obsolete, inconvenient, slow, and problematic. but that's off topic...

Agreed. Java could be secured, but since it's generally disliked and unnecessary these days, it's easier to get rid of the legacy stuff that still uses it.

> but since it's generally disliked and unnecessary these days,

Maybe its disliked by start ups running the latest and greatest flavor of X, but enterprise isn't letting up any time soon on Java. Especially if there already using Oracle and its not easy to get rid of legacy stuff that costs money to rebuild. There are also people who adamantly protect the legacy stuff because that is where there job security lies.

From a pragmatic point of view, you want to map the number of days of publicly known zero days in the Java plugin vs. the popular browsers in the last year or so. If you do that, you'll find the Java plugin poses a much bigger risk then the big browsers. This isn't related to the quality of the applets written in Java, maybe (I'm not sure) it isn't even related to the Java specification but only to Oracle's implementation of that spec. But all that doesn't matter from a pragmatic point of view.

In terms of b), one of the messages of the presentation was a shift away from focusing too much on perimeter defense (which would include phishing, probably), and making the inside of the network more resilient and costly to attack. It's a counter to the hard shell / soft inside situation which most networks are currently geared towards. In that sense, I don't think it was missed in the presentation, their entire strategy is to deal with what happens when (not if) the marketing guy gives out his password.

Re: social engineering, do you think it'd be helpful to have part of your security team try, on an ongoing basis, to socially-engineer credentials out of the rest of your organization? Maybe reward the employees who figure out what's going on with a little tiny bonus, to give them a Pavlovian instinct to notice social engineering in the future?

In this slidedeck there is a interesting reference to another one from the FB Sec Team in case you missed it. http://www.slideshare.net/mimeframe/ruxcon-2012-15195589

There's a section on "running effective attack simulations" starting on slide 104. Where are you supposed to find the (simulated) attackers, within your own organization ? External contractors ?

My guess would be the same professional pentesters as usual but give them different marching orders rather than "See what you can break".

An interesting point is their recomendation of putting ad-blockers on all corporate user machines as a security precaution - since a common malware entrypoint is users clicking on misleading links/popups provided by ads.

Reply on news.ycombinator.com