Product Group Tests
Web content management (2009)
A comprehensive appliance with a great amount of flexibility makes Phantom Technologies iBoss Web Filter this month's Best Buy.
A capable web and application filter, with protection from malware at an affordable price make Barracuda Web Filter 310 our Recommended product.
Full Group Summary
Policy is key to content management. We put 12 products to the test. By Peter Stephenson.
The notion of web content management is a bit confused. When you look for a solid definition, you find that it is focused at the server end. So what we really have at the client end is content filtering. In that regard, the purpose has not changed much since we first started discussing content filtering years ago. And, ironically, when Mike Lipinski ran the web products through the lab, his major comment was that we saw all of this last year, with the exception of some new protocols. An example of that is the increasing emphasis on peer-to-peer traffic, especially such protocols as Skype.
Most of the products we saw were appliances. Generally, we like that because setup and administration usually are easier than with software-based products. This year we saw most of the same players we have seen in the past, with some interesting exceptions that gave the old-timers a run for their money.
What we looked for
The key to content management is policy and we looked hard at that. Policy, however, is of little use unless it translates organisational policy into configuration easily and quickly. We are very picky about how products make that translation. The old days of needing to programme filters in what feels like a scripting language are over. Time is money and precision counts for a lot. We look for precise, easy-to-configure, hard-to-fool policy engines.
Apart from protocols, most of the improvements over the last year were cosmetic. User interfaces are becoming easier and more intuitive to use, a trend we applaud. We also like products that integrate nicely with existing infrastructure. Ability to hook into Active Directory and take advantage of user management that is already in place in the enterprise is a key benefit, especially during deployment.
We looked for ease of use - which certainly includes the user interface - and ease of implementation and management. Straightforward management is a key feature that helps security administrators be more efficient and effective.
What you should look for
As with any product, especially products that can have a potential impact on network performance and user satisfaction, web content filters need to do the job as unobtrusively as possible. A web-filtering product should not be noticed unless it has to do something such as block a website. Additionally, it should not materially slow network performance. It should be easy to update and it should fit well into your enterprise.
Fitting into the enterprise is important and what that means is not obvious. I have seen products that do what they do very well, but drive their people nuts with interruptions and pop-up messages that many of the users don't fully understand.
Not all enterprises are the same. For example, enterprises in organisations that have a culture of high security are often more tolerant of severe restrictions, while more open enterprises, such as universities, have a culture of low tolerance for restrictions. The product you select should allow you to match it to the culture of your organisation - while offering adequate protection.
How we tested
We set up each system, attempting to rely as little as possible on the manuals initially to get a feel for the product's intuitiveness. We completed the implementation according to quick-start guides and manuals to ensure that we had the configuration correct for our test bed. That included integrating with our Active Directory in the test bed. We then browsed through the user interface, especially the administration sections, looking for ease of use and administration.
Our next stop was the policy engine; here we started with the default policy set, if there was one. We used a series of tests that attempted to defeat the policies in place as a default. Then we created a policy and attempted to defeat it. We were interested especially in the number of ways that the product accomplished its filtering. We looked for URL, key word and protocol filtering.
Finally, we looked at how well the product was documented relative to its complexity. More complicated products - and a product may legitimately be complicated, depending upon its functions - require more complete documentation. Some products require very little because they are intuitive. In addition to documentation, we are concerned about support options and the support website.