Sorry for the extended absence folks, we’ve had our noses to the grindstone recently.
You may have seen some headlines recently about PayPal getting some bad publicity over a Cross-Site Scripting exploit, and this supposedly “calling into doubt” the security of the newly introduced EV-SSL. This shows that some basic concepts of security are still badly misunderstood in the public arena, and that the press and corporations are swallowing the associated FUD hook, line and sinker.
The idea behind EV-SSL is that the certified entity supposedly has been researched more strongly than for a normal cert, AND the website has been through an audit. Thus, the consumer, upon seeing a site identified by EV-SSL should be more confident about the security of their interaction with that website. It’s a nice idea, but without real teeth behind it, it’s really just a marketing ploy . . . and a process that really verifies sites deeply and regularly enough is not going to be something that you can buy at simple “product” prices from Verisign.
What seems to have happened is that PayPal has deployed EV-SSL (even having gone so far as to discuss blocking browsers that do not support EV-SSL or other anti-phish measures) . . . and regardless still had someone execute an XSS against them. This really isn’t all that surprising, as what people are hoping for is a panacea when you really can’t simplify the problem that much. Instead, unwittingly, they are buying into exactly what Verisign is selling:
“If your site has the “green bar” in IE 7 and your competitor’s site does not, you appear to be more trusted and more legitimate. That’s a competitive advantage in the world of e-commerce.”
Unwittingly, those words from Verisign’s own FAQ (emphasis mine) sum things up nicely: Companies, both buying and selling “security,” as well as consumers, all want a simple, one stop solution — something that in the modern internet environment can’t really exist. How can things like the oft-failed “Hacker Safe” and other shallow scans and audits be a true barometer of a site’s trustworthiness, when even in depth analysis by trained professionals can’t always catch everything? (or if they do, then there’s a new code revision pushed two days later).
The mantras bear repeating again: SSL and TLS != security on their own. And if someone can execute their code on your site/server/browser, you have lost. And (corollary of above) having “better” SSL definitely does not make better security.
I believe the answer is NOT simple — but if companies want to start gaining trust, they need to follow the model of other areas where they have gotten their noses bloodied and made (some) progress in.
Consider: most websites of note will have a privacy policy (wait for it . . . yes, I know there is an inherent irony of a site having a privacy policy telling you how they are protecting your information, but then they don’t have good security in their application), and terms of use prominently stated, both of which are the result of nearly parallel issues in similar legal quagmires.
I propose that companies also have a specific online security statement as well, to go along with the other (now seemingly compulsory) fine print. This could be a part or extension of an organization’s security policy, or a stand alone document, but it would describe the practices and procedures of the company in terms of their web application, AND how diligently these rules are being followed. Do you have a monthly assessment scheduled? Did it get done this month?
I’m sure this would go over like a ton of bricks with most corporations, but I think that it could yield a very interesting set of measures for a savvy consumer to look against. If a corporation has no procedures, that tells you something. If they do have procedures, that can tell you a lot as well — if they are lip service and BS, take your business elsewhere. If they are serious, it will show. If they then are not regularly following these procedures, even if they are good ones, it would show a company that was slacking in its priorities.
There is a potential for heading down a slippery slope with this, as I am sure the first thing a lot of vendors who engage in services that would support this will do is try to tie into it, by doing their own independent verification that people really are doing what they say they are doing — and how else would you really be able to tell if people were doing regular checks, or if they were just bluffing?
This could really work for good if done correctly, but I realize it also has the potential to create a larger much larger BS quotient, with more “scanned by so and so” or “something-safe” popping up as a way of doing these easily.
The safeguard and/or saving grace would be the two-pronged approach. I’d feel a lot safer dealing with a large online company that had a page that spelled out how they were doing code review in their SDLC and that they were up to date on monthly assessments by White Hat Security versus someone who had just been rated “Hacker Safe” that afternoon.