5 reasons why network security is not like website security

Firewalls allow access to insecure websites

Over 1 billion people online may visit any of the 140+ million websites simply using a Web browser. When they do they’ll undoubtedly cross over several network firewalls, none of which will block them from doing much of anything. And there’s a reason for this. Firewalls that protect a network underneath a website are specifically configured to block just about all forms of traffic, except Web traffic! The problem is this traditional castle fortress network security model doesn’t help the Web application layer because the business functions more like an ecommerce bazaar than anything else. Firewalls allow Web attacks through to a website. Most of the time the only thing standing between a hacker and the confidential information on a website is the security of the code. 

Vulnerability remediation comes from within

Patches to remediate vulnerabilities in commercial and open source products (operating systems, web server, web application packages, etc.) are regularly released by software vendors. Network vulnerability scanners, which are designed to locate any missing patches and weak configuration, only go as far as identifying the “well-known” issues (Windows, Linux, etc.) using a large signature database.  But when it comes to custom web application there are no well-known vulnerabilities, only “unknown”. That’s because no other website is likely to share identical code because it was developed internally. This means that no patch will be released to fix flawed web application code. The organization who owns the website and developed the code is solely responsible for create a patch and rolling it out.

SSL only protects data in transit, not when its at rest

Eugene Spafford from Purdue University said of using SSL on the Internet, “the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench.” This quote perfectly illustrates the context of what is going on with web application security. Bad guys are perfectly capable of penetrating a website directly and compromising its data despite how data might be protected when users communicate with it.

Security personnel lack control

An InfoSec group typically maintains network control using restrictive firewall rules, promptly installed patches, encrypted connections, and hardened system configuration. These solutions are all well and good, but as we’ve learned earlier, they do little to protect an insecure web application and remediation must come from the development group. The dilemma is that developers don’t work for the InfoSec group and they often have a different set of tasks and priorities. InfoSec’s lack of control forces them into a position of responsibility without authority. Short of installing a Web Application Firewall, develop managers must be convinced to schedule in fixes typically by communicating organizational risk.

Code that’s secure today, won’t necessarily secure tomorrow

While we know each code change has the possibility of introducing new security vulnerabilities, that doesn’t mean static code gets a free pass. There are many external forces that impact the tactical security strategies of the SDLC. Research into new web application attacks is evolving faster than ever before. Even the experts are challenged to keep up.