Imperva and Sentryware pad layer 7 security
Hive and SecureSphere deliver enhanced protection to Web applications
Hive is more resilient to changes in the underlying HTML interface than traditional IPSes and application firewalls. It will still secure HTML objects even if, for example, the page layout changes or page names are different.
Hive includes Sanity Checks — optional, built-in, rules-based protection — to make sure no one tries to use an SQL injection attack, cookie poisoning, a shell code exploit, or cross-site scripting against your Web application. Hive will also protect the contents of Web forms and all the fields in the form. Using HTags — proprietary HTML tags you define in Hive and insert in the HTML — you can validate the data entered into a form has a specific format and length.
Using multiple Hives in a load-balanced or fault-tolerant deployment is very easy because there are no state tables to maintain across devices. Although Hive will log to syslog or any SNMP platform, there isn’t a central management built into the system.
Sentryware definitely has come up with a secure and unique method of protecting Web applications and database servers. Overall, however, I’d like for Hive to have built-in centralized management and found configuring Hive to be somewhat time-consuming.
Imperva’s Web application protection takes the essence of an IPS and adds to it advanced heuristics and attack correlation. It doesn’t just rely on a preset list of known application vulnerabilities, and it can protect against unknown attacks on Web servers and database servers.
Unlike Hive, SecureSphere is a reactive form of application security. The solution detects anomalies or outright attacks and, based on your policy, can stop the troublemaker dead in his or her tracks or simply log the occurrence for future analysis.
SecureSphere uses two appliances. The SecureSphere G4 Gateway looks at all the traffic on your LAN and logs each Web page request or database lookup to SecureSphere’s other appliance, the MX Management Server. This appliance stores the collected information in a SQL database where it is sorted and collated, providing a centralized management platform. You can deploy the G4 Gateway alongside the LAN so that it sniffs packets only as they move across the wire, or you can deploy it in line with the LAN so that all traffic has to pass through it.
The gateway is also the point where the SecureSphere console implements and enforces its policies. To stop an attacker, SecureSphere issues a TCP reset based on the session ID and kills the attacker’s session. In my tests, I saw how quickly a TCP reset can kill a user session, even at LAN speeds.
The SecureSphere console is where all the collected traffic is analyzed, sorted, and stored in a provided SQL database engine. In it, you can monitor multiple gateways and push your policies out to them at the same time from a single console.
What I found most innovative about SecureSphere is that it learns what normal traffic patterns are for your Web app and database server. Based on what it learns, SecureSphere can detect attempts to manipulate URL strings or to change field contents. For example, if a form is submitted with some fields containing more than 1,000 characters, SecureSphere will know that this could be a buffer overrun attempt and will then implement your policy for this type of anomaly. You can override the learned values to tailor it to suit your requirements.