Cover Your Apps
5 Security Myths 
By Jeremiah Grossman, VARBusiness 
9:00 AM EDT Wed. Jul. 07, 2004 
Like water, hackers take the path of least resistance. Today, this path leads over Secure Sockets Layer (SSL) to get past most corporate firewalls, where nothing exists between a hacker, a Web site and the information it holds. Using a browser and a few simple tricks, hackers can penetrate a Web site, access its credit-card database and make off with the goods unseen. With firewalls and patch management now being standard practices, the network perimeter has become increasingly secure. Determined to stay a step ahead, hackers have moved up the software stack, focusing on the Web site itself. According to a Gartner analyst, more than 70 percent of cyberattacks occur at the application layer. So what's a solution provider to do? To improve the security of the Web, you must dispel five largely held misconceptions. 
1. "The Web site uses SSL, so it's secure."
SSL by itself does not secure a Web site. The tiny SSL lock symbol located at the bottom of a Web browser indicates that the information sent to and from a site is encrypted. Nothing more. SSL does not protect the information stored on the site once it arrives. Many sites using strong 128-bit SSL have been hacked just the same as those that do not. In addition, SSL has nothing to do with how a user's private information is safeguarded. When private data is stored on the Web site, the risk is at the server, not in between. 
2. "A firewall protects the Web site, so it's safe."
Firewalls allow traffic to pass through to a Web site but lack the ability to protect the site itself from malicious activity. Meanwhile, Web applications that turn a site into an e-commerce bank, store, auction, credit union, message board, etc., remain vulnerable to attack. In the traditional network-security mindset, the idea has been to let the good guys in and keep the bad guys out through the use of firewall access-control lists (ACLs). Securely configured ACLs will deny everything from passing into a network except an allowed set of activities, such as Web traffic and e-mail. Generally speaking, all other traffic is blocked by the firewall. But after an ACL has allowed a visitor to the site, all security protections provided become meaningless. 
3. "The vulnerability scanner reported no security issues, so the web site is secure."
Vulnerability scanners have been used since the early '90s to point out well-known network security flaws. However, they neglect the security of custom Web applications running on the Web server, which usually remain full of holes. 
Vulnerability scanners transmit specially crafted network traffic to target servers and collect responses, which are analyzed and compared to thousands of well-known security vulnerability signatures (a.k.a. "checks"). When a match is made, a security issue is reported. Up-to-date vulnerability scanners now achieve more than 90 percent vulnerability coverage on the average network--but they sparsely target the Web-application layer because there are no well-known security issues present in custom-written Web code. A vulnerability security scanner is incapable of identifying flaws other than those within its signature database. 
4. "Web application security is a developer problem."
Sure, developers are part of the problem, but many factors beyond their control contribute to software security. 
For example, source code can originate from a variety of locations besides in-house. A company might have code developed by an offshore firm to intermingle with existing code. Developers may even use example or open-source code. It's never clear that the entire code base for a software project is unique or their combined interaction is safe and secure. Let's say two developers independently create two completely secure software modules. They are secure in and of themselves, but their combined interaction with each other may not be. Now multiply this interactivity with hundreds of thousands of lines of code all intermingling. The possibility of a security loophole in business logic becomes likely. 
Realistically, software has bugs. We witness this fact every day. Security vulnerabilities are nothing more than a type of bug. Training staff to develop secure code makes a marked improvement in code quality. But remember, everyone makes mistakes and sometimes they remain undiscovered for years. 
5. "Security assessments are performed on the Web site every year, so it's secure."
The high rate of change in normal Web-site code rapidly decays the accuracy of even the most recent of security reports. It is responsible, and often required, to have yearly security assessments performed on a site, although the common Web-application life cycle requires more frequent reviews. As each new revision of a Web application is developed and pushed, the potential for new security issues increases. 
Holidays are an especially significant time for site updates. For example, Christmas specials are backed with new code-facilitating business. New features are hurried in, regardless of security considerations. If the business does not publish functioning code, it suffers a financial loss. This is why security personnel must be involved at all stages of development.