5 ms·

Attack-driven defense

96 points by austengary 13y ago

philsnow 13y ago
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 ?
- rurounijones 13y ago
  My guess would be the same professional pentesters as usual but give them different marching orders rather than "See what you can break".
dvt 13y ago
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?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftsec_dynamic.html http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?top... [1]: http://slashdot.org/topic/bi/brute-force-and-social-engineering-data-breaches-in-2012/ http://slashdot.org/topic/bi/brute-force-and-social-engineer...
- integricho 13y ago
  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...
  - alextingle 13y ago
    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.
    - wil421 13y ago
      > 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.
- eksith 13y ago
  "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.
- Eiwatah4 13y ago
  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.
Bjoern 13y ago
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 http://www.slideshare.net/mimeframe/ruxcon-2012-15195589
dgroves 13y ago
OWASP AppSensor is an OWASP project that defines a number of anomaly based patterns common to all web applications, as well as a frame work for detection and response.
PeterisP 13y ago
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.

96 points by austengary 13y ago

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 ?

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

dvt 13y ago

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?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftsec_dynamic.html http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?top... [1]: http://slashdot.org/topic/bi/brute-force-and-social-engineering-data-breaches-in-2012/ http://slashdot.org/topic/bi/brute-force-and-social-engineer...

integricho 13y ago
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...
- alextingle 13y ago
  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.
  - wil421 13y ago
    > 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.
eksith 13y ago
"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.
Eiwatah4 13y ago
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.

Bjoern 13y ago

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 http://www.slideshare.net/mimeframe/ruxcon-2012-15195589

dgroves 13y ago

OWASP AppSensor is an OWASP project that defines a number of anomaly based patterns common to all web applications, as well as a frame work for detection and response.

PeterisP 13y ago

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.