Monday, 30 November 2009

Irrational: Why the Snake Oil Flows

It’s only the end of November, but I’m ready to hand out the Snake Oil Security Product of the Year Award to ATSC (UK) Ltd. for their product, the ADE 651. It’s a portable device for detecting all manner of important things (including bombs, drugs, and truffles). It works on the same principle as a divining rod or a Ouija board—that is, it doesn’t work. That hasn't stopped the Iraqi army from spending tens of millions of dollars on hundreds of ADE 651s.

A successful con of this magnitude requires a victim who desperately wants something and who's willing to depart from rational thought in order to believe they can have it. Software security assurance is ripe for snake oil salesmen because measuring security is hard and major loss events are relatively rare. But what are software security practitioners so desperate for that they'll buy even though the product doesn't work? I'll outline two ideas below. Any resemblance to actual commercial offerings is purely coincidental.

The Silver Bullet
This vulnerability detector uses a patented counter-interpolation analysis to apply a vulnerability database derived from the scariest hax0rs around. There are never any false positives. False negatives? We don't even know what that means. Good for analyzing source code, binaries, web sites, services on the network, networks you have only heard about, and iPhone apps. Merely analyzing your software|hardware|network once guarantees a seal of approval from OWASP/SANS/PCI/FISMA/NRA.

The Responsibility Shifter
Buying this product allows you to sit back and relax. Your job as a security professional will now be taken care of by all of the non-security people in your organization. You drop the software off on their desks, they immediately understand how important security has become in the past few years, and they stop doing their jobs in favor of doing yours instead. If anything goes wrong, the software will explain to management that getting security right requires a team effort, and you really can't be held accountable.

Have more product ideas? Post them here or send me email, and I'll do a roundup in a few weeks.

Posted by bchess at 3:13 PM in Fortify

Wednesday, 11 November 2009

BSIMM Europe

BSIMM made it across the Atlantic! Over the last few months, I've traveled with Gary McGraw, Brian Chess, Florence Mottay, and Dave Harper through Europe to companies like Nokia, SWIFT, Standard Life, Telecom Italia, and Thomson Reuters to expand the original BSIMM study with data from Europe. While we were expecting that European companies are tackling software security completely different, we were surprised to find out that the studied European companies are doing software security not terribly different from the original nine US companies in the BSIMM study. European companies tend to focus more on Compliance and Policy, Penetration Testing, and Software Environment while Training and Security Testing and assurance activities (like Code Review) seem to be behind. Our full analysis is here
Posted by mmadou at 9:06 AM in Fortify

Monday, 9 November 2009

Cross-Origin Resource Sharing

A few days ago Facebook and MySpace fixed some bugs in their crossdomain.xml files that could have allowed malicious apps to steal user data or do other nefarious things. The crossdomain.xml file allows a site to specify which third party sites are allowed to make cross-domain Flex based AJAX request to that site. This basically disables the same origin policy for allowed sites. Chris Shiflett has a nice write up about the dangers that come along with allowing cross domain AJAX and Flash.

I wanted to take this opportunity to remind our readers of the lesser known Cross-Origin Resource Sharing (CORS) standard that allows similar behavior. Most new browsers support this standard, so the associated cross-site manipulation vulnerabilities are not limited to Flash. It is a little harder to detect if a site is vulnerable since you can't just request crossdomain.xml. Instead you need to find a resource that uses certain access control headers (See Ajaxian and Mozilla for examples). Now I'm pretty sure only a few sites have adopted this standard, but once the adoption picks up, it's only a matter of time before we see a bunch of advisories about CORS.
Posted by elee at 1:08 PM in Fortify