Over 80% of reported attacks are perpetrated through TCP port 80, the standard Web port.

http://www.incidents.org.

Worms spread like lightning!

Worms like Code Red and Nimda take between 40 and 90 minutes to propagate and infect enough servers to have significant worldwide impact. Even though patches are generally available shortly after a new worm is launched, it makes much more sense to have proactive prevention measures - rather than reactive recovery measures - in place before the next inevitable worm. You can avoid future incidents altogether with webApp.secure!

Simple tools, sophisticated attacks.

A widely-known hacker lists a laptop and Web browser as his tools of choice to perpetrate intrusions.

Security products that use signature-recognition can only protect against known threats.

The Code Red and Nimda worms were able to successfully exploit known software vulnerabilities because the Web server blindly attempted to fulfill a request for a resource (by way of a carefully-crafted URL specifically designed to exploit the vulnerability) that was simply not a legitimate part of the Web site to begin with. Now that we know what Code Red and Nimda "look like" (their respective signatures), nearly every firewall, intrusion-detection system, and anti-virus product is able to provide protection. But then again, so does applying the vendor patch that fixes the vulnerability that led to the problem in the first place. :) By blocking all requests for resources (URL's) that are not legitimately part of the Web site (avoiding signature-recognition), webApp.secure not only guarantees 100% immunity to both current and future worms, but also renders attempts to exploit server misconfigurations completely impotent.

99% of all attacks exploit known vulnerabilities.

IT personnel are too overloaded to keep up with the sheer volume of operating system updates, application upgrades, and security patches. Manual updates simply demand too much time and are therefore usually out-of-date and inconsistent across an organization's servers - making it relatively easy for "script-kiddies" to compromise a system.

More than 19 million people have the skills to hack.

Over 6% of the US population has the ability to perpetrate attacks against our systems. The myriad of automated, readily available, and easy-to-use attack tools are a large contributor to this statistic.

A Web (HTTP) server is - by design - a general purpose piece of software.

HTTP servers like Apache and IIS are "general purpose" software. They have a well-defined set of functions they perform, but are intentionally generic in nature to facilitate a large variety of implementations. At their most fundamental level, they fulfill requests for resources without any framework or context. A resource may be a simple file, CGI script, or a more complex process. HTTP servers on the Web "blindly" attempt to service any request from any client - anywhere in the world. Without meticulous server hardening, this is obviously enormous exposure! webApp.secure provides a context for the HTTP server. Unless a request is a legitimate part of the Web site, the server will never see it and therefore never execute anything that could cause harm.

Applications are the weakest link.

Network level security has matured and advanced to the point that it is nearly impossible to penetrate. As a result, attackers see the open path through network security measures (commonly port 80) as an opportunity to significantly decrease the effort required to cause harm. All they have to do is run a script to efficiently execute a series of attacks (literally thousands at a time) seeking to take advantage of configuration oversights and/or known software vulnerabilities. webApp.secure makes it virtually impossible for any of these attacks to succeed because -

"if it isn't part of the site, it doesn't get processed by the Web server!"