The Internets are full of bad advice. Some is harmless, but some is downright dangerous, especially when it isn’t bad advice per se but rather shall we say, incomplete. Suggesting that you should only provide personal information to sites that use HTTPS is an example of the latter kind, because it implies that as long as a web application is using SSL for transport layer (network) security then it is safe to give up your private, personal, information.

Because miscreants would never set up a phishing site and enable SSL. Because SSL somehow magically strips out malicious SQL injection and other web application attacks from the data. Because SSL is carried right over into the database, where all that personal, private data you just gave up is safely encrypted and even if it is stolen it will be unusable.

This is akin to suggesting that as long as the door is locked, the fact that it’s a glass room makes it secure enough to store the Hope Diamond.

It would almost be amusing if it weren’t for the fact that people less technically inclined will take this advice (which is not all bad) and subsequently trust that their personal, private information is safe (that is bad). They will mistakenly believe that they will not be the victims of identity theft at some nebulous point in the future. They will relax and give up credit card and account numbers, too, because obviously the owner of the web application is serious about security.

This kind of advice without further follow-up generates a false sense of security that will possibly be the cause of much angst in the future when reality rears its ugly head and some poor Internet neophyte learns he’s given up his identity because there was a lock icon on the bottom of the browser.

SSL is a network security solution. It’s designed to keep data in transit secure from prying eyes. Nothing more. Nothing less. What happens to it once it’s on the client or on the server or in the database is a matter for a completely different set of solutions. Database encryption, data leak protection (DLP),  web application security, and secure coding practices are necessary. SSL itself is actually useless against most of the attacks that exploit vulnerabilities and result in the loss of customer data today. An SSL encrypted SQL injection attack is still an SQL injection attack. Wrapping it up with encryption doesn’t change that, and in fact it may impede the ability of security infrastructure to detect it.

Aunt Emma’s ugly ski sweaters are still as unwelcome a gift at Christmas wrapped up in pretty paper as it would be presented without wrapping. An insecure application deployed “in the cloud” is still an insecure application. Wrapping it up in someone else’s pretty infrastructure didn’t change that.

There are many facets to “security” and only one of them involves the transport of data. The others relate to vulnerabilities in the operating system, services, the application platforms, the application, and the database. And don’t forget any potential risks in the newest layer of the security stack: virtualization.

Unfortunately this isn’t a problem peculiar to the consumer (and business user) world. It’s increasingly an issue with seasoned IT professionals implementing cloud computing and virtualization. It’s also apparently a problem with some vendors, too. At least that appears to be the case given Hoff’s latest blog on the subject. A web application firewall on its own is not enough protection. Secure coding practices on their own are not enough protection. Database encryption on its own is not enough protection. No single solution within a single tier can provide the security coverage necessary to ensure data will not be stolen or stop an application from being compromised in some way.

Not even the old standby of a scissors applied to the network cable is enough; portable media and WiFi has put an end to “air gap” theory-based security and made it, too, unreliable. 

The existence of a network security solution does not imply there are similar protections inside the network, and deploying network security solutions is only one prong of what should be a broader, three-pronged security strategy that should include at a minimum:

• NETWORK SECURITY 
• SSL
• IDS / IPS
• Access Control
• DNSSEC
• APPLICATION SECURITY
• Secure coding practices
• Regular vulnerability assessments
• Web application firewall
• Data leak protection
• Access control
• AV / Malware scanning
• DATABASE SECURITY
• Access control
• Encryption of sensitive data
• Secure coding practices (for stored procedures if used)

Excellent application security does not imply the network is secure. Excellent database security does nothing to stop application exploitation. Excellent network security does not ensure data will not be exposed. Without a comprehensive security strategy that takes into consideration the entire ecosystem in which applications are deployed and might be exploited, there continues to be a high risk of compromise.

Should you employ SSL as a security measure? Absolutely. Should you rely upon it as the solution to all your security challenges? Absolutely not. And you shouldn’t give your customers the impression that SSL is enough, either. Unless we educate consumers to be more aware of what “security” on the Internet really means, they’ll continue to operate with a false sense of security. People take risks they wouldn’t normally take when they think it’s safe. That’s one of the reasons why suggesting SSL is an indicator of acceptable security practices is dangerous.

The other reason is simply because it’s not true.